El tema d'un mono-repositori s'ha tractat més d'una vegada i, per regla general, provoca una controvèrsia molt activa. En crear com a eina de codi obert dissenyada per millorar el procés de creació de codi d'aplicació des de Git fins a imatges de Docker (i després lliurar-les a Kubernetes), no pensem gaire en quina és la millor opció. Per a nosaltres, és primordial oferir tot el necessari per als partidaris de diferents opinions (si això no contradiu el sentit comú, és clar).
El recent suport mono-repo de werf és un bon exemple d'això. Però primer, anem a esbrinar com aquest suport està generalment relacionat amb l'ús de werf i què hi té a veure el registre Docker...
Problemes
Imaginem una situació així. L'empresa compta amb molts equips de desenvolupament que treballen en projectes independents. La majoria de les aplicacions s'executen a Kubernetes i, per tant, estan en contenidors. Per emmagatzemar contenidors, imatges, cal un registre (registre). Com a tal registre, l'empresa utilitza Docker Hub amb un sol compte COMPANY. Similar a la majoria de sistemes d'emmagatzematge de codi font, Docker Hub no permet la jerarquia de dipòsits imbricats, tal com COMPANY/PROJECT/IMAGE. En aquest cas... com es poden emmagatzemar aplicacions no monolítices al registre amb aquesta limitació sense crear un compte separat per a cada projecte?
Potser, la situació descrita és familiar per a algú de primera mà, però considerem la qüestió de l'organització de l'emmagatzematge d'aplicacions en general, és a dir. sense fer referència a l'exemple anterior i a Docker Hub.
Solucions
Si l'aplicació monolític, ve en una imatge, llavors no hi ha preguntes i simplement desem les imatges al registre de contenidors del projecte.
Quan una aplicació es presenta com a diversos components, microserveis, llavors cal un cert enfocament. En l'exemple d'una aplicació web típica que consta de dues imatges: frontend и backend - les opcions possibles són:
- Emmagatzema les imatges en dipòsits imbricats separats:
- Emmagatzemeu-ho tot en un dipòsit i considereu el nom de la imatge a l'etiqueta, per exemple, de la següent manera:
NB: De fet, hi ha una altra opció amb desar en diferents repositoris, PROJECT-frontend и PROJECT-backend, però no ho tindrem en compte per la complexitat de suport, organització i distribució de drets entre usuaris.
suport werf
Inicialment, werf es limitava als dipòsits imbricats; afortunadament, la majoria de registres admeten aquesta funció. A partir de la versió , treball afegit amb registres en què la nidificació no és compatible, i Docker Hub és un d'ells. A partir d'aquest moment, l'usuari pot triar com emmagatzemar les imatges de l'aplicació.
Implementació disponible sota opció --images-repo-mode=multirepo|monorepo (per defecte multirepo, és a dir emmagatzematge en repositoris imbricats). Defineix els patrons pels quals s'emmagatzemen les imatges al registre. N'hi ha prou amb seleccionar el mode desitjat quan utilitzeu les ordres bàsiques, i tota la resta es mantindrà sense canvis.
Perquè la majoria d'opcions de werf es poden configurar Variables del mediambient, als sistemes CI/CD, el mode d'emmagatzematge sol ser fàcil de configurar globalment per a tot el projecte. Per exemple, en el cas de GitLab només cal afegir una variable d'entorn a la configuració del projecte: Configuració -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Si parlem de la publicació d'imatges i el desplegament d'aplicacions (podeu llegir detalladament aquests processos als articles de documentació rellevants: и ), llavors el mode només determina la plantilla amb la qual podeu treballar amb la imatge.
El diable està en els detalls
La diferència i la principal dificultat a l'hora d'afegir un nou mètode d'emmagatzematge està en el procés de neteja del registre (per a les funcions de purga admeses per werf, vegeu ).
A l'hora de netejar, werf té en compte les imatges utilitzades als clústers de Kubernetes, així com les polítiques configurades per l'usuari. Les polítiques es basen en la divisió de les etiquetes en estratègies. Estratègies suportades actualment:
- 3 estratègies enllaçades per primitives de Git com ara tag, branch i commit;
- 1 estratègia per a etiquetes personalitzades arbitràries.
Desem informació sobre l'estratègia de l'etiqueta quan publiquem la imatge a les etiquetes de la imatge final. El significat en si és l'anomenat metaetiqueta - Obligatori per aplicar algunes de les polítiques. Per exemple, quan s'elimina una branca o una etiqueta d'un repositori de Git, és lògic suprimir-ne una sense utilitzar imatges del registre, que està cobert per part de les nostres polítiques.
Quan es desa en un dipòsit (monorepo), a l'etiqueta d'imatge, a més de la metaetiqueta, també es pot emmagatzemar el nom de la imatge: PROJECT:frontend-META-TAG. Per separar-los, no hem introduït cap separador específic, sinó que simplement hem afegit el valor necessari a l'etiqueta de la imatge final a l'hora de publicar-la.
NB: Si us interessa mirar tot el que es descriu al codi font werf, el punt de partida pot ser .
En aquest article, no prestarem més atenció als problemes i la justificació del nostre enfocament: sobre les estratègies d'etiquetatge, l'emmagatzematge de dades a les etiquetes i el procés de publicació en conjunt, tot això es descriu en detall en un informe recent de Dmitry Stolyarov: "».
Resumint
La manca de suport per als registres no imbricats no va ser un factor de bloqueig per a nosaltres o els usuaris werf coneguts per nosaltres; després de tot, sempre podeu crear un registre d'imatges independent (o canviar a un registre de contenidors condicional a Google Cloud)... Tanmateix, eliminar aquesta restricció semblava lògic perquè l'eina fos més convenient per a la comunitat DevOps més àmplia. En implementar-lo, ens hem enfrontat a la principal dificultat per reelaborar el mecanisme de neteja del registre de contenidors. Ara que tot està preparat, és agradable adonar-se que s'ha tornat més fàcil per a algú i nosaltres (com a principals desenvolupadors del projecte) no tindrem cap dificultat notable per donar suport a aquesta funció.
Queda't amb nosaltres i molt aviat t'informarem d'altres novetats a !
PS
Llegeix també al nostre blog:
- «»;
- «».
Font: www.habr.com