A True Engineering hem establert un procés per al lliurament continu d'actualitzacions als servidors dels clients i volem compartir aquesta experiència.
Per començar, vam desenvolupar un sistema en línia per al client i el vam desplegar al nostre propi clúster de Kubernetes. Ara la nostra solució d'alta càrrega s'ha traslladat a la plataforma del client, per a la qual cosa hem configurat un procés de desplegament continu totalment automàtic. Gràcies a això, vam accelerar el temps de llançament al mercat: el lliurament de canvis a l'entorn del producte.
En aquest article parlarem de totes les etapes del procés de Desplegament Continu (CD) o lliurament d'actualitzacions a la plataforma del client:
- Com comença aquest procés?
- sincronització amb el repositori Git del client,
- muntatge de backend i frontend,
- desplegament automàtic d'aplicacions en un entorn de prova,
- desplegament automàtic a Prod.
Compartirem els detalls de la configuració al llarg del camí.
1. Inicieu el CD
El desplegament continu comença amb el desenvolupador que impulsa els canvis a la branca de llançament del nostre dipòsit de Git.
La nostra aplicació s'executa en una arquitectura de microservei i tots els seus components s'emmagatzemen en un sol dipòsit. Gràcies a això, es recullen i s'instal·len tots els microserveis, encara que un d'ells hagi canviat.
Hem organitzat el treball a través d'un dipòsit per diversos motius:
- Facilitat de desenvolupament: l'aplicació s'està desenvolupant activament, de manera que podeu treballar amb tot el codi alhora.
- Un únic pipeline CI/CD que garanteix que l'aplicació com a sistema únic supera totes les proves i es lliura a l'entorn de producció del client.
- Eliminem la confusió en les versions: no hem d'emmagatzemar un mapa de versions dels microserveis i descriure la seva configuració per a cada microservei en scripts Helm.
2. Sincronització amb el repositori Git del codi font del client
Els canvis realitzats es sincronitzen automàticament amb el repositori Git del client. Allà es configura el conjunt de l'aplicació, que s'inicia després d'actualitzar la branca, i el desplegament a continuació. Tots dos processos s'originen al seu entorn a partir d'un repositori Git.
No podem treballar directament amb el repositori del client perquè necessitem els nostres propis entorns per al desenvolupament i les proves. Utilitzem el nostre repositori Git per a aquests propòsits: està sincronitzat amb el seu repositori Git. Tan bon punt un desenvolupador publica canvis a la branca adequada del nostre repositori, GitLab envia immediatament aquests canvis al client.
Després d'això, cal fer el muntatge. Consta de diverses etapes: muntatge de backend i frontend, proves i lliurament a producció.
3. Muntatge del backend i el frontend
Construir el backend i el frontend són dues tasques paral·leles que es realitzen al sistema GitLab Runner. La seva configuració de muntatge original es troba al mateix dipòsit.
.
GitLab Runner agafa el codi del repositori requerit, l'assembla amb l'ordre de creació d'aplicacions Java i l'envia al registre de Docker. Aquí muntem el backend i el frontend, obtenim imatges de Docker, que posem en un dipòsit al costat del client. Per gestionar les imatges de Docker que fem servir .
Sincronitzem les versions de les nostres imatges amb la versió de llançament que es publicarà a Docker. Per a un bon funcionament hem fet diversos ajustaments:
1. Els contenidors no es reconstrueixen entre l'entorn de prova i l'entorn de producció. Vam fer parametritzacions perquè el mateix contenidor pogués funcionar amb tots els paràmetres, variables d'entorn i serveis tant a l'entorn de prova com en producció sense reconstruir.
2. Per actualitzar una aplicació mitjançant Helm, n'heu d'especificar la versió. Creem el backend, el frontend i actualitzem l'aplicació: són tres tasques diferents, per la qual cosa és important utilitzar la mateixa versió de l'aplicació a tot arreu. Per a aquesta tasca, utilitzem dades de l'historial de Git, ja que la nostra configuració de clúster K8S i les aplicacions es troben al mateix dipòsit de Git.
Obtenim la versió de l'aplicació dels resultats de l'execució de l'ordre
git describe --tags --abbrev=7.
4. Desplegament automàtic de tots els canvis a l'entorn de prova (UAT)
El següent pas en aquest script de compilació és actualitzar automàticament el clúster K8S. Això passa sempre que s'hagi construït tota l'aplicació i tots els artefactes s'hagin publicat al registre Docker. Després d'això, s'inicia l'actualització de l'entorn de prova.
S'ha començat a utilitzar l'actualització del clúster . Si, com a resultat, alguna cosa no ha anat d'acord amb el previst, Helm revertirà automàticament i de manera independent tots els seus canvis. La seva feina no necessita ser controlada.
Subministrem la configuració del clúster K8S juntament amb el muntatge. Per tant, el següent pas és actualitzar-lo: configMaps, desplegaments, serveis, secrets i qualsevol altra configuració de K8S que hem canviat.
Aleshores, Helm executa una actualització RollOut de la pròpia aplicació a l'entorn de prova. Abans de desplegar l'aplicació a producció. Això es fa perquè els usuaris puguin provar manualment les funcions empresarials que posem a l'entorn de prova.
5. Desplegament automàtic de tots els canvis a Prod
Per implementar una actualització a l'entorn de producció, només cal que feu clic a un botó a GitLab i els contenidors s'entreguen immediatament a l'entorn de producció.
La mateixa aplicació pot funcionar en diferents entorns (prova i producció) sense reconstruir-la. Utilitzem els mateixos artefactes sense canviar res a l'aplicació i establim els paràmetres externament.
La parametrització flexible de la configuració de l'aplicació depèn de l'entorn en què s'executarà l'aplicació. Hem mogut tots els paràmetres de l'entorn a l'exterior: tot es parametritza mitjançant la configuració K8S i els paràmetres Helm. Quan l'Helm desplega un conjunt a l'entorn de prova, la configuració de prova s'hi aplica i la configuració del producte s'aplica a l'entorn de producció.
El més difícil va ser parametritzar tots els serveis i variables utilitzats que depenen de l'entorn, i traduir-los en variables d'entorn i descripció-configuracions de paràmetres d'entorn per a Helm.
La configuració de l'aplicació utilitza variables d'entorn. Els seus valors s'estableixen en contenidors mitjançant el mapa de configuració K8S, que es modela amb plantilles Go. Per exemple, establir una variable d'entorn al nom de domini es pot fer així:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Valors.global.env – aquesta variable emmagatzema el nom de l'entorn (prod, stage, UAT).
.Valors.propietats.aplicacions.domini_extern_a_aplicació – en aquesta variable establim el domini desitjat al fitxer .Values.yaml
Quan actualitza una aplicació, Helm crea un fitxer configmap.yaml a partir de plantilles i omple el valor APP_EXTERNAL_DOMAIN amb el valor desitjat en funció de l'entorn en què s'inicia l'actualització de l'aplicació. Aquesta variable ja està establerta al contenidor. S'hi pot accedir des de l'aplicació, de manera que cada entorn d'aplicació tindrà un valor diferent per a aquesta variable.
Fa relativament poc, el suport K8S va aparèixer a Spring Cloud, inclòs el treball amb configMaps: . Tot i que el projecte es desenvolupa activament i canvia radicalment, no podem utilitzar-lo en producció. Però controlem activament el seu estat i l'utilitzem en configuracions DEV. Tan bon punt s'estabilitzi, passarem d'utilitzar variables d'entorn a ell.
En total
Per tant, el desplegament continu està configurat i funciona. Totes les actualitzacions es produeixen amb una sola tecla. El lliurament dels canvis a l'entorn del producte és automàtic. I, sobretot, les actualitzacions no aturen el sistema.
Plans de futur: migració automàtica de bases de dades
Hem pensat en actualitzar la base de dades i en la possibilitat de revertir aquests canvis. Al cap i a la fi, s'executen dues versions diferents de l'aplicació al mateix temps: l'antiga s'està executant i la nova. I desactivarem l'antiga només quan estiguem segurs que la nova versió funciona. La migració de la base de dades us hauria de permetre treballar amb les dues versions de l'aplicació.
Per tant, no podem canviar simplement el nom de la columna o altres dades. Però podem crear una columna nova, copiar-hi dades de la columna antiga i escriure activadors que, en actualitzar dades, les copiaran i actualitzaran simultàniament en una altra columna. I després del desplegament satisfactori de la nova versió de l'aplicació, després del període de suport posterior al llançament, podrem suprimir la columna antiga i el disparador que s'ha convertit en innecessari.
Si la nova versió de l'aplicació no funciona correctament, podem tornar a la versió anterior, inclosa la versió anterior de la base de dades. En resum, els nostres canvis us permetran treballar simultàniament amb diverses versions de l'aplicació.
Tenim previst automatitzar la migració de la base de dades mitjançant el treball K8S, integrant-lo al procés del CD. I sens dubte compartirem aquesta experiència a Habré.
Font: www.habr.com