és la nostra utilitat GitOps CLI de codi obert per crear i lliurar aplicacions a Kubernetes. Com havia promès, va marcar l'inici d'afegir noves característiques a werf i revisar els enfocaments tradicionals. Ara ens complau presentar la versió 1.1, que és un gran pas en el desenvolupament i una base per al futur col·leccionista werf. La versió està disponible actualment en .
La base del llançament és la nova arquitectura de l'emmagatzematge escènic i l'optimització del treball d'ambdós col·leccionistes (per a Stapel i Dockerfile). La nova arquitectura d'emmagatzematge obre la possibilitat d'implementar conjunts distribuïts des de diversos hosts i conjunts paral·lels al mateix host.
L'optimització del treball inclou desfer-se de càlculs innecessaris en l'etapa de càlcul de signatures d'etapa i canviar els mecanismes per calcular les sumes de verificació dels fitxers per altres més eficients. Aquesta optimització redueix el temps mitjà de construcció del projecte amb werf. I les compilacions inactives, quan existeixen totes les etapes a la memòria cau etapes-emmagatzematge, ara són molt ràpids. En la majoria dels casos, reiniciar la compilació trigarà menys d'1 segon! Això també s'aplica als procediments de verificació de les etapes del procés de treball dels equips. werf deploy и werf run.
També en aquesta versió, va aparèixer una estratègia per etiquetar imatges per contingut: etiquetatge basat en contingut, que ara està habilitat per defecte i l'únic recomanat.
Fem una ullada més de prop a les innovacions clau de werf v1.1 i, al mateix temps, us expliquem els plans per al futur.
Què ha canviat a werf v1.1?
Nou format de noms d'etapa i algorisme per seleccionar etapes de la memòria cau
Nova regla de generació de noms artístics. Ara cada construcció d'etapa genera un nom d'etapa únic, que consta de 2 parts: una signatura (com era a la v1.0) més un identificador temporal únic.
Per exemple, el nom complet de la imatge de l'escenari podria semblar així:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...o en general:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aquí:
-
SIGNATUREés una signatura d'etapa, que representa l'identificador del contingut de l'etapa i depèn de l'historial d'edicions a Git que han conduït a aquest contingut; -
TIMESTAMP_MILLISECés un identificador d'imatge únic garantit que es genera en el moment en què es crea una nova imatge.
L'algorisme per seleccionar les etapes de la memòria cau es basa en comprovar la relació de les confirmacions de Git:
- Werf calcula la signatura d'una etapa determinada.
- В etapes-emmagatzematge Hi pot haver diverses etapes per a una signatura determinada. Werf selecciona totes les etapes que coincideixen amb la signatura.
- Si l'etapa actual està enllaçada a Git (git-archive, etapa personalitzada amb pedaços de Git:
install,beforeSetup,setup; o git-latest-patch), aleshores werf selecciona només aquelles etapes associades a un commit que és un avantpassat del commit actual (per al qual es crida la compilació). - De les etapes adequades restants, se'n selecciona una: la més antiga per data de creació.
Una etapa per a diferents branques de Git pot tenir la mateixa signatura. Però werf evitarà que la memòria cau associada a diferents branques s'utilitzi entre aquestes branques, fins i tot si les signatures coincideixen.
.
Nou algorisme per crear i desar etapes a l'emmagatzematge d'escenaris
Si, en seleccionar etapes de la memòria cau, werf no troba una etapa adequada, s'inicia el procés de muntatge d'una nova etapa.
Tingueu en compte que diversos processos (en un o més hosts) poden començar a construir la mateixa etapa aproximadament al mateix temps. Werf utilitza un algorisme de bloqueig optimista etapes-emmagatzematge en el moment de desar la imatge recentment recollida etapes-emmagatzematge. D'aquesta manera, quan la nova construcció de l'etapa estigui llesta, werf es bloqueja etapes-emmagatzematge i hi desa una imatge recentment recollida només si ja no existeix una imatge adequada (per signatura i altres paràmetres - vegeu el nou algorisme per seleccionar etapes de la memòria cau).
Es garanteix que una imatge acabada de muntar té un identificador únic TIMESTAMP_MILLISEC (vegeu el nou format de denominació escènica). En cas que en etapes-emmagatzematge es trobarà una imatge adequada, werf descartarà la imatge recentment compilada i utilitzarà la imatge de la memòria cau.
En altres paraules: el primer procés per acabar de construir la imatge (el més ràpid) tindrà dret a emmagatzemar-la en etapes-emmagatzematge (i després serà aquesta imatge única la que s'utilitzarà per a totes les compilacions). Un procés de compilació lent mai bloquejarà un procés més ràpid de desar els resultats de compilació de l'etapa actual i passar a la següent compilació.
.
Rendiment millorat del creador de Dockerfile
De moment, el pipeline d'etapes per a una imatge construïda a partir d'un Dockerfile consta d'una etapa: dockerfile. Quan es calcula la signatura, es calcula la suma de control dels fitxers context, que s'utilitzarà durant el muntatge. Abans d'aquesta millora, werf va recórrer de manera recursiva tots els fitxers i va obtenir una suma de verificació sumant el context i el mode de cada fitxer. A partir de la v1.1, werf pot utilitzar sumes de control calculades emmagatzemades en un dipòsit de Git.
L'algorisme es basa en . L'algorisme té en compte els registres en .dockerignore i travessa l'arbre de fitxers de forma recursiva només quan sigui necessari. Així, hem desacoblat la lectura del sistema de fitxers i la dependència de l'algorisme de la mida context no és significatiu.
L'algorisme també verifica els fitxers sense seguiment i, si cal, els té en compte a la suma de control.
Rendiment millorat en importar fitxers
Les versions de werf v1.1 utilitzen un servidor rsync quan . Anteriorment, la importació es feia en dos passos mitjançant un muntatge de directoris des del sistema amfitrió.
El rendiment de les importacions a macOS ja no està limitat pels volums de Docker i les importacions es completen en el mateix temps que Linux i Windows.
Etiquetatge basat en contingut
Werf v1.1 admet l'anomenat etiquetatge per contingut d'imatge - etiquetatge basat en contingut. Les etiquetes de les imatges Docker resultants depenen del contingut d'aquestes imatges.
En executar l'ordre werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature imatges publicades de l'anomenada signatura escènica imatge. Cada imatge està etiquetada amb la seva pròpia signatura de les etapes d'aquesta imatge, que es calcula segons les mateixes regles que la signatura normal de cada etapa per separat, però és un identificador general de la imatge.
La signatura de les etapes de la imatge depèn de:
- el contingut d'aquesta imatge;
- històries dels canvis de Git que van donar lloc a aquest contingut.
Un dipòsit de Git sempre té confirmacions simulades que no canvien el contingut dels fitxers d'imatge. Per exemple, les confirmacions només amb comentaris o les confirmacions de combinació, o les confirmacions que canvien els fitxers de Git que no s'importaran a la imatge.
Quan s'utilitza l'etiquetatge basat en contingut, es resolen els problemes de reinicis innecessaris dels pods d'aplicacions a Kubernetes a causa dels canvis en el nom de la imatge, encara que el contingut de la imatge no hagi canviat. Per cert, aquesta és una de les raons que impedeix emmagatzemar molts microserveis d'una aplicació en un únic repositori Git.
A més, l'etiquetatge basat en el contingut és un mètode d'etiquetatge més fiable que l'etiquetatge a les branques de Git, perquè el contingut de les imatges resultants no depèn de l'ordre en què s'executen les canalitzacions al sistema CI per muntar múltiples commits de la mateixa branca.
És important: a partir d'ara etapes-signatura - És l'única estratègia d'etiquetatge recomanada. S'utilitzarà per defecte a l'ordre werf ci-env (tret que especifiqueu explícitament un esquema d'etiquetatge diferent).
. També es dedicarà una publicació a part a aquesta funció. ACTUALITZAT (3 d'abril): article amb detalls .
Nivells de registre
L'usuari ara té l'oportunitat de controlar la sortida, establir el nivell de registre i treballar amb la informació de depuració. S'han afegit opcions --log-quiet, --log-verbose, --log-debug.
Per defecte, la sortida conté la informació mínima:
Quan utilitzeu una sortida detallada (--log-verbose) podeu veure com funciona werf:
Sortida detallada (--log-debug), a més de la informació de depuració de werf, també conté registres de biblioteques utilitzades. Per exemple, podeu veure com es produeix la interacció amb el registre Docker i també registrar els llocs on es passa una quantitat significativa de temps:
Altres plans
Atenció! Les opcions que es descriuen a continuació estan marcades v1.1 estarà disponible en aquesta versió, molts d'ells en un futur proper. Les actualitzacions es faran mitjançant actualitzacions automàtiques . Aquestes característiques no afecten la part estable de les funcions v1.1; el seu aspecte no requerirà la intervenció manual de l'usuari en les configuracions existents.
Suport complet per a diverses implementacions de Docker Registry (NOVETAT)
- Versió: v1.1
- Dates: març
L'objectiu és que l'usuari utilitzi una implementació personalitzada sense restriccions quan utilitza werf.
Actualment, hem identificat el següent conjunt de solucions per a les quals garantirem un suport total:
- Per defecte (biblioteca/registre)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Paquets GitHub
- Registre de GitLab*,
- Port*,
- Moll.
Les solucions que actualment són totalment compatibles amb werf estan marcades amb un asterisc. Per als altres hi ha suport, però amb limitacions.
Es poden identificar dos problemes principals:
- Algunes solucions no admeten l'eliminació d'etiquetes mitjançant l'API del registre de Docker, la qual cosa impedeix als usuaris utilitzar la neteja automàtica de werf. Això és cert per als paquets AWS ECR, Docker Hub i GitHub.
- Algunes solucions no admeten els anomenats repositoris imbricats (Docker Hub, GitHub Packages i Quay) o sí, però l'usuari ha de crear-los manualment mitjançant la UI o l'API (AWS ECR).
Anem a resoldre aquests i altres problemes utilitzant les API natives de les solucions. Aquesta tasca també inclou cobrir tot el cicle de funcionament del werf amb proves per a cadascun d'ells.
Creació d'imatges distribuïdes (↑)
- Versió: v1.2 v1.1 (s'ha augmentat la prioritat per implementar aquesta funció)
- Dates: març-abril març
De moment, werf v1.0 i v1.1 només es poden utilitzar en un amfitrió dedicat per a operacions de creació i publicació d'imatges i desplegament de l'aplicació a Kubernetes.
Per obrir les possibilitats de treball distribuït de werf, quan la creació i el desplegament d'aplicacions a Kubernetes s'inicien en diversos amfitrions arbitraris i aquests amfitrions no guarden el seu estat entre les compilacions (executors temporals), werf és necessari per implementar la capacitat d'utilitzar. el Docker Registry com a magatzem escènic.
Anteriorment, quan el projecte werf encara es deia dapp, tenia una oportunitat així. Tanmateix, ens hem trobat amb una sèrie de problemes que cal tenir en compte a l'hora d'implementar aquesta funcionalitat a werf.
Nota. Aquesta característica no requereix que el col·lector treballi dins dels pods de Kubernetes, perquè Per fer-ho, cal desfer-se de la dependència del servidor Docker local (al pod de Kubernetes no hi ha accés al servidor Docker local, perquè el procés en si s'està executant en un contenidor i werf no és compatible ni admetrà). treballant amb el servidor Docker a la xarxa). El suport per executar Kubernetes s'implementarà per separat.
Suport oficial per a les accions de GitHub (NOVETAT)
- Versió: v1.1
- Dates: març
Inclou documentació werf (seccions referència и orientar), així com l'acció oficial de GitHub per treballar amb werf.
A més, permetrà que werf treballi en corredors efímers.
La mecànica d'interacció de l'usuari amb el sistema CI es basarà a col·locar etiquetes a les sol·licituds d'extracció per iniciar determinades accions per crear/desplegar l'aplicació.
Desenvolupament local i desplegament d'aplicacions amb werf (↓)
- Versió: v1.1
- Dates: gener-febrer abril
L'objectiu principal és aconseguir una única configuració unificada per desplegar aplicacions tant a nivell local com en producció, sense accions complexes, fora de la caixa.
werf també ha de tenir un mode de funcionament en el qual serà convenient editar el codi de l'aplicació i rebre instantàniament comentaris de l'aplicació en execució per a la depuració.
Nou algorisme de neteja (NOU)
- Versió: v1.1
- Dates: abril
A la versió actual de werf v1.1 en el procediment cleanup No hi ha cap disposició per a la neteja d'imatges per a l'esquema d'etiquetatge basat en contingut; aquestes imatges s'acumularan.
A més, la versió actual de werf (v1.0 i v1.1) utilitza diferents polítiques de neteja per a imatges publicades sota esquemes d'etiquetatge: branca Git, etiqueta Git o Git commit.
S'ha inventat un nou algorisme per netejar imatges basat en l'historial de commits a Git, unificat per a tots els esquemes d'etiquetatge:
- No deseu més de les imatges N1 associades a les commits N2 més recents per a cada git HEAD (branques i etiquetes).
- No emmagatzemeu més de les imatges d'escenari N1 associades a les commits més recents N2 per a cada git HEAD (branques i etiquetes).
- Emmagatzemeu totes les imatges que s'utilitzen en qualsevol recurs de clúster de Kubernetes (s'escanegen tots els contextos kube del fitxer de configuració i els espais de noms; podeu limitar aquest comportament amb opcions especials).
- Emmagatzemeu totes les imatges que s'utilitzen als manifests de configuració de recursos desats a les versions d'Helm.
- Es pot suprimir una imatge si no està associada a cap HEAD de git (per exemple, perquè s'ha suprimit el mateix HEAD corresponent) i no s'utilitza en cap manifest del clúster de Kubernetes i de les versions de Helm.
Construcció d'imatges paral·leles (↓)
- Versió: v1.1
- Dates: gener-febrer abril*
La versió actual de werf recull les imatges i els artefactes descrits a werf.yaml, seqüencialment. Cal paral·lelitzar el procés de muntatge d'etapes independents d'imatges i artefactes, així com proporcionar una sortida còmoda i informativa.
* Nota: la data límit s'ha canviat a causa de l'augment de la prioritat per implementar el muntatge distribuït, que afegirà més capacitats d'escalat horitzontal, així com l'ús de werf amb accions de GitHub. El muntatge en paral·lel és el següent pas d'optimització, proporcionant escalabilitat vertical en muntar un projecte.
Transició a Helm 3 (↓)
- Versió: v1.2
- Dates: febrer-març maig*
Inclou la migració a una base de codi nova i una manera provada i còmoda de migrar les instal·lacions existents.
* Nota: canviar a Helm 3 no afegirà característiques significatives a werf, perquè totes les característiques clau de Helm 3 (fusion de 3 vies i sense tiller) ja estan implementades a werf. A més, werf té a més dels indicats. Tanmateix, aquesta transició continua en els nostres plans i s'implementarà.
Jsonnet per descriure la configuració de Kubernetes (↓)
- Versió: v1.2
- Dates: gener-febrer abril-maig
Werf admetrà descripcions de configuració per a Kubernetes en format Jsonnet. Al mateix temps, werf seguirà sent compatible amb Helm i hi haurà una selecció de format de descripció.
El motiu és que les plantilles Go, segons moltes persones, tenen una gran barrera d'entrada, i la comprensió del codi d'aquestes plantilles també es ressent.
També s'està considerant la possibilitat d'introduir altres sistemes de descripció de configuració de Kubernetes (per exemple, Kustomize).
Treballant dins de Kubernetes (↓)
- Versió: v1.2
- Dates: abril-maig maig-juny
Objectiu: assegurar-se que les imatges es creen i que l'aplicació s'entrega mitjançant runners a Kubernetes. Aquells. Les imatges noves es poden crear, publicar, netejar i desplegar directament des dels pods de Kubernetes.
Per implementar aquesta capacitat, primer heu de poder crear imatges distribuïdes (vegeu el punt anterior).
També requereix suport per al mode operatiu del constructor sense un servidor Docker (és a dir, una construcció semblant a Kaniko o a l'espai d'usuari).
Werf donarà suport a la creació de Kubernetes no només amb Dockerfile, sinó també amb el seu creador Stapel amb reconstruccions incrementals i Ansible.
Un pas cap al desenvolupament obert
Ens encanta la nostra comunitat (, ) i volem que cada cop més persones ajudin a millorar el werf, a entendre la direcció en què ens estem movent i a participar en el desenvolupament.
Fa poc es va decidir canviar a per tal de donar a conèixer el procés de treball del nostre equip. Ara podeu veure els plans immediats, així com el treball actual en les següents àrees:
- ;
- ;
- ;
- .
S'ha treballat molt amb temes:
- S'han eliminat els irrellevants.
- Les existents es porten a un únic format, amb un nombre suficient de detalls i detalls.
- S'han afegit nous temes amb idees i suggeriments.
Com habilitar la versió v1.1
La versió està disponible actualment en (en canals estable и Solid com una roca Tanmateix, els llançaments apareixeran a mesura que es produeixi l'estabilització ea ja és prou estable per al seu ús, perquè passava pels canals alfa и beta). Activat de la següent manera:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusió
La nova arquitectura d'emmagatzematge en fase i les optimitzacions de constructors per als creadors de Stapel i Dockerfile obren la possibilitat d'implementar compilacions distribuïdes i paral·leles a werf. Aquestes funcions apareixeran aviat a la mateixa versió v1.1 i estaran disponibles automàticament mitjançant el mecanisme d'actualització automàtica (per als usuaris ).
En aquesta versió, s'ha afegit una estratègia d'etiquetatge basada en el contingut de la imatge: etiquetatge basat en contingut, que s'ha convertit en l'estratègia per defecte. També s'ha reelaborat el registre d'ordres principal: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
El següent pas significatiu és afegir assemblatges distribuïts. Les compilacions distribuïdes s'han convertit en una prioritat més alta que les compilacions paral·leles des de la v1.0 perquè afegeixen més valor a werf: escala vertical de constructors i suport per a constructors efímers en diversos sistemes CI/CD, així com la capacitat de fer suport oficial per a les accions de GitHub. . Per tant, es van canviar els terminis d'implantació de muntatges paral·lels. Tanmateix, estem treballant per implementar ambdues possibilitats el més aviat possible.
Segueix les notícies! I no us oblideu de visitar-nos a per crear un problema, trobar-ne un existent i afegir un plus, crear un PR o simplement veure el desenvolupament del projecte.
PS
Llegeix també al nostre blog:
- «»
- «»;
- Una sèrie de notes sobre les innovacions en werf:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com