Millor tard que mai. O com gairebé vam cometre un greu error en no tenir suport per a Dockerfiles habituals per crear imatges d'aplicacions.
Es tractarà de — Una utilitat GitOps que s'integra amb qualsevol sistema CI/CD i gestiona tot el cicle de vida de l'aplicació, que us permet:
- recopilar i publicar imatges,
- desplegar aplicacions a Kubernetes,
- suprimir imatges no utilitzades mitjançant polítiques especials.
La filosofia del projecte és recollir eines de baix nivell en un únic sistema unificat que ofereix als enginyers de DevOps el control de les aplicacions. Si és possible, s'han d'utilitzar les utilitats existents (com Helm i Docker). Si no hi ha solució a un problema, podem crear i mantenir tot el necessari per a això.
Fons: el teu propi col·leccionista d'imatges
Això és el que va passar amb el creador d'imatges a werf: ens faltava el Dockerfile habitual. Si us endinseu breument en la història del projecte, aquest problema ja es va manifestar a les primeres versions de werf (aleshores ).
Mentre creàvem una eina per crear aplicacions a les imatges de Docker, ràpidament ens vam adonar que el Dockerfile no era adequat per a algunes tasques molt específiques:
- La necessitat de muntar aplicacions web petites típiques d'acord amb el següent esquema estàndard:
- instal·lar les dependències a tot el sistema de l'aplicació,
- instal·lar un paquet de biblioteques de dependència d'aplicacions,
- recollir actius,
- i el més important, actualitzar el codi de la imatge de manera ràpida i eficient.
- Quan es fan canvis als fitxers del projecte, el creador ha de crear ràpidament una nova capa aplicant pedaços als fitxers modificats.
- Si alguns fitxers han canviat, s'ha de reconstruir l'etapa dependent corresponent.
Avui dia, hi ha moltes altres possibilitats a la nostra aixeta, però els desitjos i impulsos inicials eren els següents.
En general, sense pensar-ho dues vegades, ens vam armar amb el llenguatge de programació utilitzat (mirar abaix) i sortir a la carretera - per implementar DSL propi! D'acord amb les tasques establertes, es pretenia descriure el procés de construcció per etapes i determinar les dependències d'aquestes etapes als fitxers. I el complementava aixeta pròpia, que va convertir DSL en l'objectiu final: la imatge muntada. Al principi DSL estava en Ruby, però com - La configuració del nostre col·lector es va començar a descriure al fitxer YAML.
Configuració antiga per a dapp a Ruby
Configuració real per a werf a YAML
El mecanisme del col·lector també va canviar amb el temps. Al principi, només vam generar un Dockerfile temporal a partir de la nostra configuració sobre la marxa, i després vam començar a executar instruccions de compilació en contenidors temporals i a fer una confirmació.
NB: De moment, el nostre constructor, que funciona amb la seva pròpia configuració (en YAML) i s'anomena Stapel builder, ja s'ha convertit en una eina força potent. La seva descripció detallada mereix articles separats, i els detalls principals es poden trobar a .
Consciència del problema
Però ens vam adonar, i no immediatament, que havíem comès un error: no vam afegir l'habilitat crear imatges mitjançant un Dockerfile estàndard i integrar-los a la mateixa infraestructura de gestió d'aplicacions d'extrem a extrem (és a dir, recopilar imatges, desplegar-les i netejar-les). Com podeu fer una eina de desplegament a Kubernetes i no implementar el suport de Dockerfile, és a dir. una manera estàndard de descriure imatges per a la majoria de projectes?...
En lloc de respondre aquesta pregunta, oferim la seva solució. Què passa si ja teniu un Dockerfile (o un conjunt de Dockerfiles) i voleu utilitzar werf?
NB: Per cert, per què voldríeu fer servir werf? Les principals característiques es redueixen a les següents:
- cicle complet de gestió d'aplicacions, incloent imatges de neteja;
- la capacitat de gestionar el muntatge de diverses imatges alhora des d'una única configuració;
- procés de desplegament millorat per a gràfics compatibles amb Helm.
Podeu trobar una llista més completa a .
Per tant, si abans suggeriríem reescriure el Dockerfile a la nostra configuració, ara ens complau dir: "Deixa que werf creï els teus Dockerfiles!"
Com s'utilitza?
La implementació completa d'aquesta característica va aparèixer al llançament . El principi general és senzill: l'usuari especifica el camí a un Dockerfile existent a la configuració de werf i, a continuació, executa l'ordre werf build... i això és tot - werf construirà la imatge. Considerem un exemple abstracte.
Anunciarem el següent Dockerfile a l'arrel del projecte:
FROM ubuntu:18.04
RUN echo Building ...
I ho anunciarem werf.yamlque utilitza això Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Tot! Esquerra correr werf build:
A més, podeu declarar el següent werf.yaml per crear diverses imatges alhora a partir de diferents Dockerfiles:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Finalment, també s'admet passar paràmetres de compilació addicionals, com ara --build-arg и --add-host - mitjançant la configuració de werf. Hi ha disponible una descripció completa de la configuració de la imatge Dockerfile a .
Com funciona?
Durant el procés de creació, la memòria cau estàndard de les capes locals a Docker funciona. Tanmateix, el que és important, werf també integra la configuració de Dockerfile a la seva infraestructura. Què vol dir això?
- Cada imatge construïda a partir d'un Dockerfile consta d'una única etapa anomenada
dockerfile(Podeu llegir més informació sobre quines etapes hi ha a werf ). - Per escenari
dockerfilewerf calcula una signatura que depèn del contingut de la configuració de Dockerfile. Si canvieu la configuració de Dockerfile, es canvia la signatura de l'etapadockerfilei werf iniciarà una reconstrucció d'aquesta etapa amb la nova configuració de Dockerfile. Si la signatura no canvia, werf agafa la imatge de la memòria cau (es va descriure més sobre l'ús de signatures a werf a ). - A més, les imatges recollides es poden publicar amb l'ordre
werf publish(Owerf build-and-publish) i utilitzeu-lo per implementar-lo a Kubernetes. Les imatges publicades al registre Docker es netejaran amb eines de neteja estàndard de werf, és a dir. hi haurà una neteja automàtica d'imatges antigues (més de N dies), imatges associades a branques de Git inexistents i altres polítiques.
Podeu trobar més detalls sobre els punts descrits aquí a la documentació:
- ;
- ;
- .
Notes i precaucions
1. L'URL extern a ADD no és compatible
Actualment no s'admet l'ús d'un URL extern en una directiva. ADD. Werf no activarà una reconstrucció quan canviï un recurs a l'URL especificat. Està previst que aquesta funció s'afegeixi aviat.
2. No pots afegir .git a una imatge
En general, afegir un directori .git en una imatge és una mala pràctica viciosa, i aquí teniu el perquè:
- Si
.gitroman a la imatge final, això vulnera els principis : com que la imatge resultant s'ha d'associar amb una única confirmació, no hauria de ser possible fer-hogit checkoutcompromís arbitrari. -
.gitaugmenta la mida de la imatge (el dipòsit pot ser gran a causa del fet que un cop s'hi van afegir fitxers grans i després es van suprimir). La mida de l'arbre de treball associat només amb una confirmació concreta no dependrà de l'historial d'operacions a Git. En aquest cas, l'addició i posterior eliminació.gitde la imatge final no funcionarà: la imatge encara adquirirà una capa addicional; així és com funciona Docker. - Docker pot desencadenar una reconstrucció innecessària fins i tot si s'està construint el mateix commit però des d'arbres de treball diferents. Per exemple, GitLab crea directoris clonats separats
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectamb el muntatge paral·lel habilitat. Una reconstrucció addicional es deu al fet que el directori.gitdiferents en diferents versions clonadas del mateix dipòsit, fins i tot si es construeix la mateixa confirmació.
L'últim punt també té conseqüències quan s'utilitza werf. Werf requereix que la memòria cau creada estigui present quan s'executen algunes ordres (per exemple, werf deploy). Durant l'execució d'aquestes ordres, werf calcula les signatures d'etapa per a les imatges especificades a werf.yaml, i han d'estar a la memòria cau de compilació, en cas contrari l'ordre no podrà continuar. Si la signatura de les etapes depèn del contingut .git, aleshores obtenim una memòria cau que és inestable als canvis en fitxers irrellevants i werf no podrà perdonar aquest descuit (per a més detalls, vegeu ).
En general afegint només alguns fitxers necessaris mitjançant instruccions ADD en tot cas augmenta l'eficiència i la fiabilitat de l'escrit Dockerfile, i també millora l'estabilitat de la memòria cau recollida per aquest Dockerfile, als canvis irrellevants a Git.
Total
El nostre camí inicial per escriure el nostre propi constructor per a necessitats específiques va ser dur, honest i senzill: en comptes d'utilitzar crosses a sobre del Dockerfile estàndard, vam escriure la nostra pròpia solució amb una sintaxi personalitzada. I això donava els seus avantatges: el col·leccionista Stapel fa la seva feina perfectament.
Tanmateix, en el procés d'escriure el nostre propi constructor, vam perdre de vista el suport dels Dockerfiles ja existents. Ara s'ha corregit aquesta deficiència i, en el futur, tenim previst desenvolupar el suport de Dockerfile juntament amb el nostre creador personalitzat de Stapel per a compilacions distribuïdes i per construir amb Kubernetes (és a dir, construir sobre corredors dins de Kubernetes, com es fa a kaniko).
Per tant, si de sobte teniu un parell de Dockerfiles per aquí... proveu !
PS Llista de documentació sobre el tema
- ;
- ;
- ;
- ;
- ;
- ;
- .
Llegeix també al nostre blog:».
Font: www.habr.com