Quiero contar una historia de cómo se lanzó la aplicación en Openshift. También en el transcurso de la obra, consideramos utilidades para administrar la aplicación dentro de Openshift. Esta es una transcripción de la actuación en la reunión # 3 de Kubernetes SPB .
Propósito
Por lo general, los clientes se implementan en servidores separados, pero luego surge la tarea, para probar la posibilidad de ejecutar en OpenShift y recoger el rastrillo.
Primero debes hablar sobre nuestra aplicación. Un proyecto con una rica historia. Usado en grandes organizaciones y probablemente cada uno de ustedes se cruza indirectamente. La aplicación admite muchas bases de datos, integraciones, etc., etc.
Prerrequisitos
La aplicación debería funcionar en entornos completamente diferentes. Como resultado, nuestra documentación de instalación es muy extensa. Pero si te menosprecia, entonces no hay nada complicado:
- Aplicar esquema de base de datos.
- Configurar el servidor de aplicaciones.
- Instalar una licencia.
- Personalice la aplicación y la integración con sistemas externos.
Pero el mundo es cruel, tuvimos una serie de restricciones:
- La aplicación solo se puede construir específicamente en Jenkins, que se dedica a la firma. Y solo ahi.
- No hay acceso desde el cliente Openshift al entorno de desarrollo.
- Por una serie de razones ideológicas, no fue posible reutilizar las imágenes existentes de Docker para el desarrollo.
- Tenemos playbooks ansibles para instalar y configurar la aplicación en los servidores.
Demostración de contenedor de Ansible
Ansible container es un software de código abierto que tiene como objetivo automatizar el ensamblaje de contenedores, la implementación y el control de procesos. Como se puede adivinar por el nombre. Ansible se usa para construir contenedores. Ya escribimos roles de Ansible para instalar e implementar aplicaciones en la parte superior de los servidores, por lo que decidimos no reinventar la rueda y reutilizarlos. No solo sería la herramienta perfecta, sino que la reutilización rápida de los roles existentes fue un factor decisivo para la demostración.
En general, para hacer una demostración, tomamos los roles existentes que configuran todo y todo, e hicimos un "contenedor monolítico". No hubo problemas particulares con la recolección del contenedor, ya que OpenShift tiene algunas recomendaciones excelentes , pero mencionaré por separado:
- Los roles necesitaban ser finalizados. Utilizamos systemd.
- De manera predeterminada, por razones de seguridad, está prohibido usar syscall en openshift. Como resultado, habrá matices con chroot, sudo. Hola CVE-2019-5736 .
- Del mismo modo, por razones de seguridad, el contenedor se inicia desde debajo de un usuario con una ID aleatoria, esto también es un comportamiento personalizado.
La idea principal en este punto es que hicimos una demostración muuuy rápido.
Demo de contenedores múltiples
El contenedor de demostración cumplió su función y lo dividimos en componentes separados:
- Nuestra aplicación.
- La base de datos
- Servicios externos, etc.
Lo primero que encontró, ¿cómo inicializar la base de datos? Está claro que usamos migraciones, pero ¿cuándo y cómo aplicarlas? Aquí vale la pena dar un enlace a un maravilloso artículo que describe el dispositivo POD: la vida de los POD . En general, hay varios enfoques:
- Use init-container
- Utilice sistemas de orquestación que determinarán el orden de implementación de los servicios y la migración de rollos cuando sea necesario.
Decidimos seguir la ruta del contenedor de Init. Es decir En el POD de nuestra aplicación, antes del inicio de nuestra aplicación, se inicia un contenedor que realiza las migraciones. Pero, ¿cómo configurar la aplicación en sí y las integraciones externas?
Inicializa la aplicación
Como ya mencioné, nuestra aplicación puede y debe funcionar en entornos completamente diferentes, con diferentes bases de datos e integraciones. Una vez más, la pregunta es cómo configurarlo todo.
- Utilice sistemas de orquestación que determinen el orden en que se implementan los servicios y aplique la configuración después de que se inicie la aplicación.
- Pase a través de las variables de entorno al contenedor cómo configurarlo.
- Use el gancho de inicio.
- Haga un contenedor separado que contenga la configuración y aplíquelo a la aplicación. Migración más o menos analógica para la base de datos.
Elegimos el último enfoque, porque le permite hacer que la configuración sea reproducible y autosuficiente. Pero por alguna razón, inicialmente hicimos este contenedor en un controlador de replicación separado con un factor de 1.
Ok, lea 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, nuestro submarino constaba de 3 contenedores.
- Inicia contenedor para inicializar un PostgreSQL.
- Contenedor con aplicación.
- Contenedor con configuración de la aplicación.
Kit de herramientas
Tenemos un diagrama de cómo se ve la aplicación implementada. Ahora es el momento de discutir las herramientas en la naturaleza, hay muchas cosas que ya están listas, consideraré algunos de la lista a continuación y sacaré conclusiones subjetivas.
Plantillas OpenShift
Plantillas OpenShift
Pros:
- Nativos y tienen excelente documentación.
Contras:
- Otro motor de plantillas.
- Largos y terribles archivos YAML.
- Si tiene dependencias entre los servicios y su orden de inicio, será difícil.
Guiones y plantilla
Pros:
- Puede utilizar excelentes herramientas y todo el poder de OOP.
Contras:
- Muletas que soportan. Y no solo para ti.
Proveedor de Terraform k8s
Pros:
- No te preocupes por la prioridad de crear elementos de infraestructura.
- Puede reutilizar el código de infraestructura como módulos.
- Puede agregar la lógica de inicialización de la aplicación.
Contras:
- No hay soporte para Openshift, solo k8s.
- A veces muelle y módulos obsoletos.
- Otra tula en tu equipo.
Contenedor Ansible
Contenedor Ansible
Pros:
- Hacer CM, no bash
- Puede reutilizar el código como roles.
- En nuestro caso, una herramienta para todo.
Contras:
- Enormes imágenes, porque ir en una capa.
- Parece abandonado y sin apoyo. Ha sido reemplazado por Ansible bender .
Ansible k8s module
Módulo Ansible + k8s
Pros:
- Un libro de jugadas para describir todas las infraestructuras de proyectos dentro de Openshift.
- Reutilizando código en forma de roles.
- Puede agregar la lógica de inicialización de la aplicación.
Contras:
- No hay soporte de proxy.
- Usted se encarga de la eliminación. Si el objeto ya no es necesario, describa su eliminación.
- Usted mismo describe la secuencia de creación de elementos de infraestructura.
Paquete de libro de jugadas ansible
La utilidad Ansible Playbook Bundle (APB) ofrece un enfoque: empaquetemos los roles ansibles para implementar una aplicación dentro de k8s / openshift en un contenedor y ejecutarla dentro de k8s / openshift.
Pros:
- Llevo todo conmigo.
- Probable y reproducible.
- Integración con el catálogo de servicios (interfaz web fácil de usar para iniciar aplicaciones).
Contras:
- Necesita privilegios de nivel de administrador.
- La documentación a veces deja mucho que desear.
Resultado
No quiero ser el último recurso, pero compartiré mis conclusiones:
PS