Comenzaremos nuestro blog con publicaciones basadas en las últimas intervenciones de nuestro director técnico. (Dmitri Stoliarov). Todos ellos tuvieron lugar en 2016 en diversos eventos profesionales y estuvieron dedicados al tema de DevOps y Docker. Un vídeo de la reunión de Docker Moscú en la oficina de Badoo, ya lo tenemos En línea. Los nuevos irán acompañados de artículos que transmitan la esencia de los informes. Entonces…
31 de mayo en la conferencia , celebrado en el marco del festival “Tecnologías rusas de Internet” (RIT++ 2016), se inauguró la sección “Despliegue e implementación continua” con el informe “Mejores prácticas de entrega continua con Docker”. Resumió y sistematizó las mejores prácticas para construir un proceso de Entrega Continua (CD) utilizando Docker y otros productos de código abierto. Trabajamos con estas soluciones en producción, lo que nos permite confiar en la experiencia práctica.
Si tienes la oportunidad de pasar una hora. , recomendamos verlo completo. De lo contrario, a continuación se muestra el resumen principal en forma de texto.
Entrega continua con Docker
debajo Entrega Continua entendemos la cadena de eventos como resultado de los cuales el código de la aplicación del repositorio Git primero llega a producción y luego termina en el archivo. Se parece a esto: Git → Construir → Probar → Lanzar → Operar.
La mayor parte del informe está dedicada a la etapa de construcción (ensamblaje de la aplicación), y los temas de lanzamiento y funcionamiento se abordan brevemente. Hablaremos sobre problemas y patrones que le permitirán resolverlos, y las implementaciones específicas de estos patrones pueden ser diferentes.
¿Por qué se necesita Docker aquí? No en vano decidimos hablar sobre las prácticas de Entrega Continua en el contexto de esta herramienta de Código Abierto. Aunque todo el informe está dedicado a su uso, se revelan muchas razones al considerar el patrón principal de implementación del código de la aplicación.
Patrón de despliegue principal
Entonces, cuando lanzamos nuevas versiones de la aplicación, ciertamente nos enfrentamos a problema de tiempo de inactividad, generado durante el cambio del servidor de producción. El tráfico de la versión anterior de la aplicación a la nueva no puede cambiar instantáneamente: primero debemos asegurarnos de que la nueva versión no solo se descargue correctamente, sino que también se "caliente" (es decir, que esté completamente lista para atender solicitudes).
Así, durante algún tiempo ambas versiones de la aplicación (antigua y nueva) funcionarán simultáneamente. Lo que automáticamente lleva a conflicto de recursos compartidos: red, sistema de archivos, IPC, etc. Con Docker, este problema se resuelve fácilmente ejecutando diferentes versiones de la aplicación en contenedores separados, para lo cual se garantiza el aislamiento de recursos dentro del mismo host (servidor/máquina virtual). Por supuesto, puede arreglárselas con algunos trucos sin ningún aislamiento, pero si hay una herramienta conveniente y lista para usar, entonces existe la razón opuesta: no descuidarla.
La contenerización proporciona muchos otros beneficios cuando se implementa. Cualquier aplicación depende de versión específica (o rango de versiones) intérprete, disponibilidad de módulos/extensiones, etc., así como sus versiones. Y esto se aplica no sólo al entorno ejecutable inmediato, sino también a todo el entorno, incluido software del sistema y su versión (hasta la distribución de Linux utilizada). Debido al hecho de que los contenedores contienen no solo el código de la aplicación, sino también el sistema preinstalado y el software de aplicación de las versiones requeridas, puede olvidarse de los problemas con las dependencias.
Resumir patrón de despliegue principal nuevas versiones teniendo en cuenta los siguientes factores:
- Al principio, la versión anterior de la aplicación se ejecuta en el primer contenedor.
- Luego, la nueva versión se despliega y se “calienta” en un segundo contenedor. Cabe destacar que esta nueva versión puede contener no solo el código actualizado de la aplicación, sino también cualquiera de sus dependencias, así como componentes del sistema (por ejemplo, una nueva versión de OpenSSL o la distribución completa).
- Cuando la nueva versión está completamente lista para atender solicitudes, el tráfico cambia del primer contenedor al segundo.
- Ahora se puede detener la versión anterior.
Este enfoque de implementar diferentes versiones de la aplicación en contenedores separados proporciona otra comodidad: retroceso rápido a la versión anterior (después de todo, basta con cambiar el tráfico al contenedor deseado).
La primera recomendación final suena como algo que ni siquiera el Capitán pudo encontrar ningún defecto: “[al organizar la entrega continua con Docker] Usar ventana acoplable [y entender lo que da]" Recuerde, esta no es una solución milagrosa que resolverá todos los problemas, sino una herramienta que proporciona una base maravillosa.
Reproducibilidad
Por "reproducibilidad" nos referimos a un conjunto generalizado de problemas que se encuentran al operar aplicaciones. Estamos hablando de tales casos:
- Los guiones controlados por el departamento de calidad para la puesta en escena deben reproducirse fielmente en producción.
- Las aplicaciones se publican en servidores que pueden recibir paquetes de diferentes espejos del repositorio (con el tiempo se actualizan y con ellos las versiones de las aplicaciones instaladas).
- “¡Todo funciona para mí localmente!” (...y los desarrolladores no pueden entrar en producción).
- Debe verificar algo en la versión anterior (archivada).
- ...
Su esencia general se reduce al hecho de que es necesaria la total conformidad de los entornos utilizados (así como la ausencia del factor humano). ¿Cómo podemos garantizar la reproducibilidad? Hacer imágenes de Docker basados en código de Git, para luego utilizarlos para cualquier tarea: en sitios de prueba, en producción, en máquinas locales de programadores... Al mismo tiempo, es importante minimizar las acciones que se realizan. después montaje de la imagen: cuanto más sencillo sea, menos probabilidades habrá de que haya errores.
La infraestructura es código
Si los requisitos de infraestructura (disponibilidad del software del servidor, su versión, etc.) no están formalizados y “programados”, la implementación de cualquier actualización de la aplicación puede tener consecuencias desastrosas. Por ejemplo, en la fase de prueba ya cambió a PHP 7.0 y reescribió el código en consecuencia; entonces su aparición en producción con algún PHP antiguo (5.5) seguramente sorprenderá a alguien. Quizás no se olvide de un cambio importante en la versión del intérprete, pero “el diablo está en los detalles”: la sorpresa puede estar en una actualización menor de cualquier dependencia.
Un método para resolver este problema se conoce como IaC (Infraestructura como Código, “infraestructura como código”) e implica almacenar los requisitos de infraestructura junto con el código de la aplicación. Al usarlo, los desarrolladores y especialistas en DevOps pueden trabajar con el mismo repositorio de aplicaciones Git, pero en diferentes partes del mismo. A partir de este código se crea una imagen de Docker en Git, en la que se implementa la aplicación teniendo en cuenta todas las particularidades de la infraestructura. En pocas palabras, los scripts (reglas) para ensamblar imágenes deben estar en el mismo repositorio que el código fuente y fusionarse.
En el caso de una arquitectura de aplicación multicapa (por ejemplo, existe nginx, que se encuentra frente a una aplicación que ya se ejecuta dentro de un contenedor Docker), las imágenes de Docker deben crearse a partir del código en Git para cada capa. Luego, la primera imagen contendrá una aplicación con un intérprete y otras dependencias "cercanas", y la segunda imagen contendrá el nginx ascendente.
Imágenes de Docker, comunicación con Git.
Dividimos todas las imágenes de Docker recopiladas de Git en dos categorías: temporales y de lanzamiento. Imágenes temporales etiquetados con el nombre de la rama en Git, se pueden sobrescribir en la siguiente confirmación y se implementan solo para vista previa (no para producción). Esta es su diferencia clave con respecto a los de lanzamiento: nunca se sabe qué confirmación específica hay en ellos.
Tiene sentido recopilar en imágenes temporales: la rama maestra (puede implementarla automáticamente en un sitio separado para ver constantemente la versión actual de la maestra), ramas con lanzamientos, ramas de innovaciones específicas.
Después de que la vista previa de las imágenes temporales surge la necesidad de traducirlas a producción, los desarrolladores ponen una etiqueta determinada. Recopilado automáticamente por etiqueta imagen de lanzamiento (su etiqueta corresponde a la etiqueta de Git) y se implementa en etapa de preparación. Si es verificado exitosamente por el departamento de calidad, pasa a producción.
dapp
Todo lo descrito (implementación, ensamblaje de imágenes, mantenimiento posterior) se puede implementar de forma independiente utilizando scripts Bash y otras herramientas "improvisadas". Pero si hace esto, en algún momento la implementación conducirá a una gran complejidad y poca capacidad de control. Al comprender esto, creamos nuestra propia utilidad de flujo de trabajo especializada para crear CI/CD: dapp.
Su código fuente está escrito en Ruby, es de código abierto y publicado en . Desafortunadamente, la documentación es actualmente el punto más débil de la herramienta, pero estamos trabajando en ello. Y escribiremos y hablaremos sobre el dapp más de una vez, porque... Sinceramente, estamos ansiosos por compartir sus capacidades con toda la comunidad interesada, pero mientras tanto, envíe sus problemas y solicitudes de extracción y/o siga el desarrollo del proyecto en GitHub.
Actualizado el 13 de agosto de 2019: actualmente un proyecto dapp renombrado a , su código se ha reescrito completamente en Go y su documentación se ha mejorado significativamente.
Kubernetes
Otra herramienta de código abierto ya preparada que ya ha recibido un reconocimiento significativo en el entorno profesional es Kubernetes,Un clúster de gestión de Docker. El tema de su uso en el funcionamiento de proyectos construidos en Docker está fuera del alcance del informe, por lo que la presentación se limita a una descripción general de algunas características interesantes.
Para su implementación, Kubernetes ofrece:
- sonda de preparación: verificar la preparación de una nueva versión de la aplicación (para cambiar el tráfico hacia ella);
- actualización continua: actualización secuencial de imágenes en un grupo de contenedores (apagado, actualización, preparación para el lanzamiento, cambio de tráfico);
- actualización sincrónica: actualización de una imagen en un clúster con un enfoque diferente: primero en la mitad de los contenedores, luego en el resto;
- Lanzamientos canarios: lanzamiento de una nueva imagen en un número limitado (pequeño) de contenedores para monitorear anomalías.
Dado que la entrega continua no es solo el lanzamiento de una nueva versión, Kubernetes tiene una serie de capacidades para el mantenimiento posterior de la infraestructura: monitoreo y registro integrados para todos los contenedores, escalado automático, etc. Todo esto ya está funcionando y solo está esperando la respuesta adecuada. implementación en sus procesos.
Recomendaciones finales
- Utilice Docker.
- Cree imágenes Docker de aplicaciones para todas sus necesidades.
- Siga el principio "La infraestructura es código".
- Vincular Git a Docker.
- Regular el orden de lanzamiento.
- Utilice una plataforma ya preparada (Kubernetes u otra).
Vídeos y diapositivas
Vídeo de la actuación (aproximadamente una hora) (el informe en sí comienza desde el minuto 5; siga el enlace para jugar desde este momento).
Presentación del informe:
PS
Otros informes sobre el tema en nuestro blog:
- «» (Dmitry Stolyarov; 27 de mayo de 2019 en DevOpsConf);
- «» (Dmitry Stolyarov; 8 de noviembre de 2018 en HighLoad++);
- «» (Dmitry Stolyarov; 7 de noviembre de 2017 en HighLoad++);
- «» (Dmitry Stolyarov; 6 de junio de 2017 en RootConf).
Fuente: habr.com