En una empresa grande, a menudo es muy difícil coordinar la asignación de recursos para tareas laborales. Todos Agile crujiendo contra la pared de un acuerdo de tres semanas con el IS de una nueva infraestructura. Por lo tanto, a menudo recibimos solicitudes para transferir infraestructura a contenedores para implementar los cambios no una vez cada tres meses, y cuando la empresa lo necesita. Al mismo tiempo, solicitan configurar / implementar Kubernetes como el instrumento de orquestación más popular, aunque, como muestra la práctica, de 10 proyectos, se necesitan un máximo de tres. Pero, de hecho, vale la pena usar Kubernetes, pero OpenShift, o trabajar con él no en su infraestructura, sino en una nube pública, por ejemplo. Trataré de hablar sobre los casos comerciales reales que decidimos, describiré las principales diferencias entre Kubernetes y OpenShift. Y también sobre cómo redujimos la coordinación de la seguridad de la información a 30 minutos, y todo siguió vivo.
Tuvimos varias implementaciones interesantes en las que acumulamos los problemas acumulados del cliente. Por ejemplo, nos llegó una empresa minorista que necesitaba lanzar nuevos chips continuamente. ¡La competencia es salvaje! Y solo tienen la infraestructura para el desarrollo cada vez que demora de seis a diez días, lo que causa tiempo de inactividad. Resolver el problema comprando nuevo hardware para pruebas y desarrollo es costoso y el camino a la nada. Como resultado, transferimos la infraestructura de TI a la virtualización de contenedores. Como resultado, gracias a los contenedores, la carga se redujo en un 40%, y la infraestructura para el nuevo desarrollo ahora se está preparando de una a cuatro horas. La bonificación es el ahorro, ya que todos los procesos podrían continuar realizándose en función de las capacidades existentes sin comprar otras nuevas.
¿Qué vamos a hacer con la seguridad de la información?
IB son personas muy necesarias. A menudo van demasiado lejos en sus requisitos internos para proyectos, pero esto es mucho mejor que ver que un día los hackers rumanos han rodeado su servidor SFTP externo.
Pero hay un problema con ellos. Si consideramos el proceso comercial como un transportador, su división a menudo se convierte en el cuello de botella en el que todos los demás descansan. Por un lado, son responsables de todos los riesgos asociados con la seguridad, por otro, simplemente no logran ver físicamente el código y todos los detalles de la arquitectura del nuevo producto.
La situación es muy similar a los servicios de seguridad en áreas con un gran flujo de personas. Podemos organizar una inspección total de cada pasajero en el metro, alumbrándolo en escáneres, girando bolsillos e inspeccionando el teléfono. Como resultado, sin embargo, en lugar de seguridad, obtendrá un colapso total del transporte y una parálisis del sistema. La única opción en esta situación es la organización de sistemas automatizados que respondan, por ejemplo, a individuos, identificando personas buscadas o reaccionando ante algún comportamiento anormal.
En nuestro contexto, dichos sistemas automatizados son procesos CI / CD organizados adecuadamente con analizadores de código en etapas intermedias, soluciones como JFrog Xray para Artifactory y tuercas Kubernetes / OpenShift correctamente ajustadas que no permiten enfoques inseguros como lanzar un contenedor desde el usuario raíz. Ahora estamos preparando una solución en caja que proporcionará todo esto.
El objetivo es pasar del concepto de "no entrará en la venta hasta que miremos" a "si no hay objeciones, se implementará automáticamente". No tiene sentido la automatización si los procesos organizacionales siguen siendo los mismos.
En uno de los proyectos, logramos reducir el tiempo de falla de IS a 30 minutos. En otras palabras, si dentro de media hora el "guardia de seguridad" no rechaza la acción, entonces se acuerda automáticamente y los cambios se ponen en producción. Ahora estamos tratando de alcanzar un plazo de 60 minutos para todos los coordinadores del proyecto sin comprometer la seguridad.
¿Cuál es la diferencia entre los sistemas de gestión de contenedores?
Kubernetes y OpenShift son las principales soluciones para la orquestación de contenedores. Analicemos las principales diferencias y ventajas para el negocio.
AperturaKubernetes es un producto totalmente abierto que se puede implementar de forma independiente y recibir servicio de forma independiente o con soporte externo. La situación en el mercado laboral ya se ha estabilizado más o menos, y encontrar expertos en este tema ya no es un problema.
OpenShift es un producto semicerrado con un sofisticado sistema de licencias de RedHat. De hecho, contiene Kubernetes, pero tiene un montón de enlaces adicionales que simplifican muchas tareas. El vendedor proporciona soporte completo pagado para su producto.
Aquí la elección depende de lo que más le convenga: el apoyo de las fuerzas de sus especialistas o proveedor.
PlataformasKubernetes funciona en casi cualquier plataforma Linux y en la mayoría de los proveedores de la nube.
OpenShift no funciona en ningún lugar excepto en RHEL, Red Hat Atomic, Red Hat CoreOS. Hay una versión de la comunidad: OKD, pero está estrechamente vinculada a las distribuciones. La única excepción es que se puede instalar en CentOS. Y tenga en cuenta que oficialmente Red Hat no garantiza el soporte pagado.
Políticas de seguridadOpenShift listo para usar tiene configuraciones de seguridad más estrictas. Esto es una ventaja cuando se despliega infraestructura desde cero, pero puede ser un problema debido a la incompatibilidad de algunas imágenes con los políticos. Por ejemplo, en OpenShift, está prohibido ejecutar el contenedor desde la raíz, lo que rompe la compatibilidad con imágenes antiguas. Por otro lado, este enfoque, combinado con una integración conveniente con AD, un registro conveniente basado en la pila EFK (ElasticSearch, Fluentd, Kibana) nos brinda la seguridad inmediata que se necesita para descargar la unidad IS.
Kubernetes también se puede terminar a este nivel, pero requerirá mucho esfuerzo y tiempo por parte de los ingenieros.
PatronesLas plantillas OpenShift son menos flexibles que los gráficos de Kubernetes Helm. Debido a políticas de seguridad más estrictas, Red Hat no puede proporcionar la flexibilidad de los gráficos Helm en este momento. Sin embargo, en OpenShift 4, la situación se ha estabilizado gracias al
OperatorHub integrado.
Tener plantillas bien diseñadas listas para usar hace la vida mucho más fácil. De hecho, esta es una opción de administrador de paquetes para construir y configurar varios servicios.
Un comando condicional "helm install prometheus-operator" despliega un sistema bastante complejo, que lleva mucho tiempo desplegarse. Kubernetes está liderando el camino.
Conclusiones generalesComo la mayoría de los productos, Red Hat OpenShift es una solución más en caja, pero arquitectónicamente más resistente. Requiere menos personal de ojos rojos y más experiencia para trabajar. Escenarios de implementación más convenientes, excelente integración con soluciones CI / CD, en particular, con Jenkins. OpenShift es ideal para compañías que son más fáciles de pagar para respaldar un producto terminado que contratar a sus propios especialistas.
Para las empresas con fuertes especialistas en este campo, Kubernetes puede ser una solución más flexible e interesante. También puede ser adecuado para una empresa relativamente pequeña que quiere ahorrar en licencias de Red Hat, pero no tiene tareas complejas que requieren expertos altamente calificados.
Casos reales
Trataré de mostrar cómo las tecnologías de contenedorización ayudaron a resolver problemas comerciales, guardaron licencias y aseguraron la suavización de las cargas máximas durante las redadas masivas de usuarios.
Estudio de caso: comercio electrónico
El problemaEl cliente tenía más de 100 servicios activos que ejecutaban la base de la nube de VMware. Y todo este parque tuvo varios problemas diferentes:
- 12 servicios que demandan recursos y que no requieren margen giraron en VMware, consumiendo un presupuesto de aproximadamente $ 408,000 al año.
- Tres servicios (un portal y dos aplicaciones móviles) comenzaron a desarrollarse activamente: en el transcurso de siete meses, la cantidad de recursos necesarios para el trabajo aumentó 4.5 veces y continúa creciendo.
- Varios servicios al cliente tienen cargas máximas, durante las cuales se necesitan recursos de seis a siete veces más que durante los tiempos normales. En consecuencia, el equipo se asignó para su correcto funcionamiento, que la mayoría de las veces se utilizó en menos del 15%.
Además de todo esto, el cliente tiene el deseo de evitar vincularse a un proveedor de virtualización.
Nuestra decisionLa primera y más simple solución: transferimos servicios con picos a la
nube pública CROC . Con facturación por los recursos consumidos. Todo es lo más simple y aburrido posible. Pasar del VMware de alguien a nuestro KVM es uno de los casos más frecuentes para los ingenieros de la nube.
Como el cliente ya compró el hardware para escalar, solo tuvimos que calcular las licencias. Para los nuevos hosts de VMware, cuestan alrededor de $ 2,100,000, lo que no fue muy adecuado para el cliente. Propusimos transferir algunos de los servicios a KVM con OpenStack. Y para no perderse, integre la gestión de ambas infraestructuras mediante CloudForms (y al mismo tiempo OpenShift).
Como resultado, el cliente recibió el segundo hombro de una nube privada basada en OpenStack, que cerró la pregunta de proveedor. Al trasladar algunos de los servicios de uso intensivo de recursos a un nuevo hombro, resultó reducir el costo de las licencias de VMware (el soporte 24 x 7 de CROC resultó ser más barato).
Caso: Minorista
El problemaDurante la auditoría, resultó que algo terrible estaba sucediendo con el cliente con respecto a la asignación de infraestructura. Proyectos: más de 250 equipos de desarrollo: más de 150 medios contenedores en Kubernetes. Los recursos para cada nuevo proyecto se compran y permanecen asignados a él sin la posibilidad de seleccionar, incluso si no se utilizan. No hay facturación en absoluto, no hay un portal único. Enormes costos para entornos de prueba y preproducción, ya que también giran en VMware.
Al mismo tiempo, el cliente no quiere cambiar completamente a una nueva plataforma y quiere ensamblar todo bajo un único portal de administración. Además, "todo" no es solo VMware, sino también PaaS, contenedores y una sola facturación.
Nuestra decisionComo resultado, dentro de la solución resultó ser bastante abundante, pero afuera para el cliente todo parece extremadamente simple.
El directorio en el que el usuario selecciona los parámetros de la máquina virtual y el circuito necesario: DevTest, PreProd, Prod. Y luego CloudForms elige dónde implementar el recurso solicitado: en VMware o en OpenShift. Todavía estamos trabajando en la facturación única, ya que la solución híbrida VMware + OpenShift es bastante difícil de armar.
De hecho, de esta manera ponemos las cosas en orden en la infraestructura, clasificando los escombros que el cliente amontonó.
Caso: Industria
El problemaCopiar máquinas virtuales en varios entornos (prueba, desarrollo, producción, preprod.) Lleva más de tres días y requiere la ejecución manual de 15 operaciones diferentes, cada una de las cuales lleva hasta 30 minutos. Una auditoría más profunda mostró que antes llevó dos semanas asignar recursos para un nuevo proyecto, y que había entre 10 y 20 solicitudes por mes. Ahora hay más de diez solicitudes de recursos por día, lo que, sin automatización, condujo a un colapso.
Nuestra decisionDe hecho, el cliente necesitaba transferir la infraestructura de TI a un modelo de servicio, reconstruir y automatizar el proceso de realizar cambios en la infraestructura, crear un portal de autoservicio, llenarlo con un catálogo de servicios e implementar un entorno para administrar aplicaciones en contenedores. Automatizamos el proceso de copia de VM, pero aún así nos llevó mucho tiempo: 40-60 minutos, esto no fue adecuado para el cliente. Como resultado, propusimos cambiar a contenedores, lo que redujo el tiempo de copia de tres a cinco minutos.
Conclusiones
La contenedorización y los microservicios no son indulgencias para un código incorrecto que se escribirá con el pie izquierdo e inmediatamente se pondrá en producción. Por el contrario, este es un concepto completo, que implica un montón de mejoras debido a la profunda automatización de todos los procesos:
- El código se vuelve más limpio: linter, analizadores de código, pruebas automatizadas.
- El código y la arquitectura son cada vez más seguros: herramientas de seguridad con amplias capacidades, hasta el bloqueo automático de la implementación de código inseguro.
- Los servicios se están volviendo más flexibles y móviles: los ciclos de desarrollo ahora son extremadamente cortos y responden rápidamente a los cambios.
- Escalado automático bajo carga: su recurso ya no se hunde durante las horas pico, perdiendo ventas y clientes.
- Asignación simple de recursos para nuevos proyectos, reducción del tiempo dedicado a la coordinación.
- A menudo, la contenedorización puede reducir significativamente el tiempo de comercialización.
Y a veces no se necesita la contenedorización en absoluto, y el problema se puede resolver migrando a una nube externa. Pero para tomar una decisión, en cualquier caso, necesitamos una buena auditoría externa y un análisis de lo que está sucediendo. En resumen, los contenedores son solo una de las herramientas para resolver problemas de negocios, aunque muy interesantes.