Me gustaría compartir mi historia sobre la migración de una aplicación a Openshift. Además, como resultado, compararé algunas de las soluciones y herramientas más populares para administrar su aplicación dentro de Openshift. Es la transcripción de mi presentación en la reunión # 3 de Kubernetes SPB .
Implementemos en Openshift
Que debemos hacer
Antes que nada, hablemos de nuestra aplicación. Es una solución empresarial lista para usar, admite diferentes bases de datos, servidores de aplicaciones e interfaces de integración con sistemas de terceros. Por lo general, nuestros clientes estaban instalando en servidores dedicados, sin embargo, enfrentamos el problema. Tuvimos que ajustar la aplicación dentro de Openshift.
Prerrequisitos
La aplicación es el producto con una larga historia, debe funcionar de forma inmediata en entornos completamente diferentes. Como resultado, hay muchas páginas en nuestras guías de instalación. Sin embargo, el esquema de nivel superior es fácil, solo debe:
- Aplicar esquema de base de datos.
- Prepare la configuración del servidor de aplicaciones.
- Instala tu licencia.
- Inicializa la aplicación.
Desafortunadamente, el mundo es cruel, había algunos requisitos previos importantes.
- Podríamos construir la aplicación solo en un esclavo especial de Jenkins, debido a restricciones de seguridad
- No hubo acceso desde la instalación Openshift del cliente al registro de docker de desarrolladores privados.
- No pudimos reutilizar las imágenes acopladas existentes, porque fueron creadas solo para desarrollar y probar necesidades.
- Había libros de jugadas ansibles para el despliegue de aplicaciones en máquinas virtuales.
Demostración de contenedor de Ansible
Ansible Container es un proyecto de código abierto que tiene como objetivo permitir la automatización de todo el proceso de construcción, implementación y administración de contenedores. Lo mejor de todo es que utiliza el mismo lenguaje de automatización Ansible simple, potente y sin agentes que ya está utilizando, lo que garantiza que pueda automatizar todo el ciclo de vida de la aplicación.
Ya habíamos escrito algunos roles de Ansible para instalar la aplicación en máquinas virtuales, por lo que los reutilizamos con ansible-container . Ansible container es un conjunto de herramientas para construir contenedores. No estoy seguro de que sea realmente un buen conjunto de herramientas, sin embargo, permite:
- Cree contenedores de la misma manera que implementamos nuestros servidores.
- Deje de encadenar juntos los comandos de shell en Dockerfiles.
No hubo ningún problema importante con ansible-container porque Openshift creando guidlines de imágenes es increíble. Sin embargo, me gustaría notar:
- Modificamos nuestros roles ansibles, porque
Docker + systemd = pain . - No hay posibilidad de usar chroot, sudo dentro de Openshift por defecto, debido a la seguridad. Solo lea CVE-2019-5736 .
- Por razones de seguridad, Openshift por defecto también genera UID aleatorio para cada contenedor, en otras palabras, openshift ignora la opción USER de un Dockerfile.
El punto principal es que ansible-container nos ayudó a crear una demostración muy rápido, debido a la reutilización.
Demo de contenedores múltiples
El primer contenedor de demostración se creó a través de ansible-container. Fue lo suficientemente bueno para la demostración, sin embargo, decidimos no usarlo. Dividimos el contenedor monolítico en diferentes:
- Usamos el contenedor original Openshift PostgreSQL sin ninguna modificación.
- Construimos la aplicación contenedor sin estado.
Sin embargo, ¿no estaba claro inicializar la base de datos? Encontramos un gran artículo sobre la vida de los PODs dentro de los kubernetes. Entonces, decidimos usar el contenedor init para la inicialización de la base de datos.
Inicializa la aplicación
Como mencioné antes, la aplicación debería funcionar de manera predeterminada en entornos completamente diferentes, admitir diferentes servidores de aplicaciones / bases de datos e interfaces de integración con sistemas de terceros.
Hay muchas formas de inicializar la aplicación:
- Pase la configuración a través de variables de entorno. Esto significa agregar toda nuestra documentación / conocimiento sobre cómo inicializar la aplicación para cada caso de uso en cada contenedor. No suena bien
- Use el gancho de inicio, esto es aproximadamente lo mismo que el primero.
- Inicializar durante la provisión a Openshift.
- Utilice un contenedor externo con configuración individual para cada caso de uso.
Elegimos el último, creamos un controlador de replicación adicional para inicializar la aplicación. Enserio?
Leemos la documentación nuevamente.
Una vaina (como en una vaina de ballenas o vaina de guisantes) es un grupo de uno o más contenedores (como los contenedores Docker), con almacenamiento / red compartidos y una especificación sobre cómo ejecutar los contenedores.
POD es un grupo de contenedores. Como resultado, decidimos ejecutar 3 contenedores en una aplicación POD
- Contenedor de inicialización para una inicialización de PostgreSQL.
- El contenedor de la aplicación.
- Contenedor de inicialización de aplicaciones.
Este enfoque permite almacenar nuestra configuración como un código, hay dos resultados interesantes: la configuración de la aplicación es comprobable y reproducible.
Ya existen muchas cosas para administrar OpenShift.
Durante la migración, probé algunos de ellos. Me gustaría compartir mis resultados.
Plantillas OpenShift
Plantillas OpenShift
Pros:
- Nativa Tiene una documentación asombrosa.
Contras:
- Sin embargo, otras plantillas de YAML.
- Registro horrible archivo YAML.
- Te interesan las dependencias de servicios.
Guiones y plantilla
Pros:
Contras:
Proveedor de Terraform k8s
Pros:
- No te preocupes por crear orden.
- Reutilice el código como módulos.
- Puede agregar lógica de inicialización.
Contras:
- No es compatible con OpenShift, solo k8s.
- A veces anticuado.
- Otra herramienta más.
Contenedor Ansible
Contenedor Ansible
Pros:
- Hacer CM, no bash
- Reutilice los roles existentes. rol = imagen.
- Un conjunto de herramientas para todo.
Contras:
- Enormes imágenes, debido a una sola capa.
- Parece abandonada y desactualizada.
Ansible contenedor fue reemplazado por Ansible bender .
Ansible k8s module
Módulo Ansible + k8s
Pros:
- Libro de jugadas único para todos.
- Reutilice el código como roles.
- Puede agregar lógica de inicialización.
Contras:
- No hay soporte de proxy.
- Te importa eliminar. Si desea eliminar algo, debe declararlo.
- Te importa crear orden. Debe implementar la aplicación antes de la inicialización.
Paquete de libro de jugadas ansible
Un Ansible Playbook Bundle (APB) es una definición de aplicación ligera (metacontenedor). Se utilizan para definir e implementar grupos complejos de aplicaciones, configuraciones de implementación, implementaciones y servicios en un clúster de OpenShift Origin que ejecuta Ansible Service Broker. Los APB ofrecen más potencia y configuración simple al aprovechar el poder de Ansible. Los APB tienen las siguientes características:
La idea principal es empacar todo lo necesario en un contenedor y ejecutar el contenedor dentro de Openshift. Paquete de libro de jugadas ansible
Pros:
- Agrupa todo.
- Probable y reproducible.
- Integración del catálogo de servicios.
Contras:
- Necesitas permisos de administrador.
- La documentación a veces está desactualizada.
Resultado
Por un lado, no quiero ser la autoridad final, pero por otro lado, me gustaría compartir mi punto de vista. No existe una bala de plata.
PS