En True Engineering establecemos un proceso para a entrega continua de actualizacións aos servidores dos clientes e queremos compartir esta experiencia.
Para comezar, desenvolvemos un sistema en liña para o cliente e implantámolo no noso propio clúster de Kubernetes. Agora a nosa solución de alta carga trasladouse á plataforma do cliente, para o que configuramos un proceso de Implementación Continua totalmente automático. Grazas a isto, aceleramos o tempo de comercialización: a entrega de cambios no entorno do produto.
Neste artigo falaremos de todas as etapas do proceso de Implementación Continua (CD) ou entrega de actualizacións na plataforma do cliente:
- Como comeza este proceso?
- sincronización co repositorio Git do cliente,
- montaxe de backend e frontend,
- implantación automática de aplicacións nun ambiente de proba,
- implantación automática en Prod.
Compartiremos os detalles da configuración ao longo do camiño.
1. Iniciar CD
A implementación continua comeza cando o programador empurra cambios na rama de lanzamento do noso repositorio de Git.
A nosa aplicación execútase nunha arquitectura de microservizos e todos os seus compoñentes almacénanse nun só repositorio. Grazas a isto, recóllense e instálanse todos os microservizos, aínda que un deles cambiou.
Organizamos o traballo a través dun repositorio por varias razóns:
- Facilidade de desenvolvemento: a aplicación está a desenvolverse activamente, polo que podes traballar con todo o código á vez.
- Unha única canalización CI/CD que garante que a aplicación como un único sistema supera todas as probas e se entrega ao entorno de produción do cliente.
- Eliminamos a confusión nas versións: non temos que almacenar un mapa de versións de microservizos e describir a súa configuración para cada microservizo en scripts Helm.
2. Sincronización co repositorio Git do código fonte do cliente
Os cambios realizados sincronizaranse automaticamente co repositorio Git do cliente. Alí confírmase o conxunto da aplicación, que se inicia despois de actualizar a rama e o despregamento á continuación. Ambos os procesos orixínanse no seu entorno a partir dun repositorio Git.
Non podemos traballar co repositorio do cliente directamente porque necesitamos os nosos propios contornos para o desenvolvemento e as probas. Usamos o noso repositorio Git para estes propósitos: está sincronizado co seu repositorio Git. Tan pronto como un desenvolvedor publica cambios na rama apropiada do noso repositorio, GitLab empurra inmediatamente estes cambios ao cliente.
Despois diso, cómpre facer a montaxe. Consta de varias etapas: montaxe de backend e frontend, proba e entrega á produción.
3. Montaxe do backend e do frontend
Construír o backend e o frontend son dúas tarefas paralelas que se realizan no sistema GitLab Runner. A súa configuración de montaxe orixinal está situada no mesmo repositorio.
.
GitLab Runner toma o código do repositorio necesario, reúneo co comando de compilación da aplicación Java e envíao ao rexistro de Docker. Aquí montamos o backend e o frontend, obtemos imaxes de Docker, que poñemos nun repositorio do lado do cliente. Para xestionar as imaxes de Docker usamos .
Sincronizamos as versións das nosas imaxes coa versión de lanzamento que se publicará en Docker. Para un bo funcionamento fixemos varios axustes:
1. Os contedores non se reconstruyen entre o ambiente de proba e o ambiente de produción. Fixemos parametrizacións para que o mesmo contedor puidese funcionar con todas as configuracións, variables de ambiente e servizos tanto no ambiente de proba como na produción sen reconstruír.
2. Para actualizar unha aplicación a través de Helm, debes especificar a súa versión. Construímos o backend, o frontend e actualizamos a aplicación; son tres tarefas diferentes, polo que é importante usar a mesma versión da aplicación en todas partes. Para esta tarefa, usamos datos do historial de Git, xa que a configuración e as aplicacións do noso clúster K8S están no mesmo repositorio de Git.
Obtemos a versión da aplicación a partir dos resultados da execución do comando
git describe --tags --abbrev=7.
4. Implementación automática de todos os cambios no ambiente de proba (UAT)
O seguinte paso deste script de compilación é actualizar automaticamente o clúster K8S. Isto ocorre sempre que se construíu toda a aplicación e todos os artefactos foron publicados no Rexistro de Docker. Despois diso, comeza a actualización do ambiente de proba.
A actualización do clúster comeza a usar . Se, como resultado, algo non saíu segundo o plan, Helm retrotraerá todos os cambios de forma automática e independente. O seu traballo non necesita ser controlado.
Fornecemos a configuración do clúster K8S xunto co conxunto. Polo tanto, o seguinte paso é actualizalo: configMaps, despregamentos, servizos, segredos e calquera outra configuración de K8S que cambiemos.
Helm executa entón unha actualización RollOut da propia aplicación no ambiente de proba. Antes de que a aplicación se despregue en produción. Isto faise para que os usuarios poidan probar manualmente as funcións empresariais que poñemos no ambiente de proba.
5. Implementación automática de todos os cambios en Prod
Para implementar unha actualización no ambiente de produción, só tes que facer clic nun botón en GitLab e os contedores entréganse inmediatamente ao ambiente de produción.
A mesma aplicación pode funcionar en diferentes ambientes (proba e produción) sen reconstruír. Usamos os mesmos artefactos sen cambiar nada na aplicación e configuramos os parámetros externamente.
A parametrización flexible da configuración da aplicación depende do ambiente no que se executará a aplicación. Movemos todas as configuracións do entorno externamente: todo se parametriza a través da configuración K8S e os parámetros Helm. Cando Helm desprega un conxunto no ambiente de proba, aplícanselle a configuración de proba e a configuración do produto aplícase ao ambiente de produción.
O máis difícil foi parametrizar todos os servizos e variables empregados que dependen do entorno, e traducilos en variables de entorno e descrición-configuracións de parámetros de entorno para Helm.
A configuración da aplicación usa variables de ambiente. Os seus valores establécense en contedores mediante o mapa de configuración K8S, que se modela con modelos Go. Por exemplo, establecer unha variable de ambiente para o nome de dominio pódese facer así:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Valores.global.env – esta variable almacena o nome do entorno (prod, stage, UAT).
.Valores.propiedades.aplicación.dominio_externo_aplicación – nesta variable establecemos o dominio desexado no ficheiro .Values.yaml
Ao actualizar unha aplicación, Helm crea un ficheiro configmap.yaml a partir de modelos e enche o valor APP_EXTERNAL_DOMAIN co valor desexado dependendo do entorno no que se inicie a actualización da aplicación. Esta variable xa está definida no contedor. Pódese acceder desde a aplicación, polo que cada contorna de aplicación terá un valor diferente para esta variable.
Fai relativamente pouco tempo, apareceu soporte para K8S en Spring Cloud, incluíndo o traballo con configMaps: . Aínda que o proxecto se está desenvolvendo activamente e cambiando radicalmente, non podemos utilizalo na produción. Pero monitorizamos activamente o seu estado e usámolo nas configuracións de DEV. En canto se estabilice, cambiaremos de usar variables de ambiente a el.
En total
Entón, a implantación continua está configurada e funcionando. Todas as actualizacións prodúcense cunha tecla. A entrega de cambios no contorno do produto é automática. E, o máis importante, as actualizacións non deteñen o sistema.
Plans de futuro: migración automática de bases de datos
Pensamos en actualizar a base de datos e na posibilidade de retrotraer estes cambios. Despois de todo, dúas versións diferentes da aplicación están a executarse ao mesmo tempo: a antiga está a executarse e a nova. E desactivaremos a antiga só cando esteamos seguros de que a nova versión funciona. A migración da base de datos debería permitirche traballar con ambas as versións da aplicación.
Polo tanto, non podemos simplemente cambiar o nome da columna ou outros datos. Pero podemos crear unha nova columna, copiar os datos da columna antiga nela e escribir disparadores que, ao actualizar os datos, copiarán e actualizarán simultáneamente noutra columna. E despois do despregue exitoso da nova versión da aplicación, despois do período de soporte posterior ao lanzamento, poderemos eliminar a columna antiga e o disparador que se fixo innecesario.
Se a nova versión da aplicación non funciona correctamente, podemos volver á versión anterior, incluída a versión anterior da base de datos. En definitiva, os nosos cambios permitirán traballar simultaneamente con varias versións da aplicación.
Planeamos automatizar a migración da base de datos a través do traballo K8S, integrándoo no proceso do CD. E sen dúbida compartiremos esta experiencia en Habré.
Fonte: www.habr.com