é a nosa utilidade CLI GitOps de código aberto para crear e entregar aplicacións a Kubernetes. Como prometeu, marcou o inicio de engadir novas funcións ao werf e revisar os enfoques tradicionais. Agora temos o pracer de presentar a versión v1.1, que é un gran paso no desenvolvemento e unha base para o futuro colector werf. A versión está dispoñible actualmente en .
A base do lanzamento é a nova arquitectura do almacenamento escénico e a optimización do traballo de ambos os colectores (para Stapel e Dockerfile). A nova arquitectura de almacenamento abre a posibilidade de implementar conxuntos distribuídos desde varios hosts e conxuntos paralelos no mesmo host.
A optimización do traballo inclúe desfacerse de cálculos innecesarios na fase de cálculo de sinaturas de fase e cambiar os mecanismos para calcular as sumas de verificación de ficheiros por outros máis eficientes. Esta optimización reduce o tempo medio de construción do proxecto usando werf. E as compilacións inactivas, cando todas as fases existen na caché etapas-almacenamento, agora son moi rápidos. Na maioría dos casos, reiniciar a compilación levará menos de 1 segundo. Isto tamén se aplica aos procedementos de verificación das fases do proceso de traballo dos equipos. werf deploy и werf run.
Tamén nesta versión apareceu unha estratexia para etiquetar imaxes por contido: etiquetaxe baseada no contido, que agora está activado por defecto e o único recomendado.
Vexamos con máis detalle as principais innovacións de werf v1.1 e, ao mesmo tempo, falémosche sobre os plans para o futuro.
Que cambiou en werf v1.1?
Novo formato de nomeamento de etapas e algoritmo para seleccionar etapas da caché
Nova regra de xeración de nomes artísticos. Agora cada compilación de etapa xera un nome de etapa único, que consta de dúas partes: unha sinatura (como estaba na versión 2) máis un identificador temporal único.
Por exemplo, o nome completo da imaxe da escena pode verse así:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... ou en xeral:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aquí:
-
SIGNATUREé unha sinatura de etapa, que representa o identificador do contido da etapa e depende do historial de edicións en Git que levaron a este contido; -
TIMESTAMP_MILLISECé un identificador de imaxe único garantido que se xera no momento en que se crea unha nova imaxe.
O algoritmo para seleccionar etapas da caché baséase en comprobar a relación dos commits de Git:
- Werf calcula a sinatura dunha determinada etapa.
- В etapas-almacenamento Pode haber varias etapas para unha determinada sinatura. Werf selecciona todas as fases que coincidan coa sinatura.
- Se a fase actual está ligada a Git (git-archive, fase personalizada con parches de Git:
install,beforeSetup,setup; ou git-latest-patch), entón werf selecciona só aquelas etapas que están asociadas a un commit que é un antepasado do commit actual (para o que se chama a compilación). - Entre as restantes etapas adecuadas, selecciónase unha: a máis antiga por data de creación.
Un escenario para diferentes ramas de Git pode ter a mesma sinatura. Pero werf impedirá que a caché asociada a diferentes ramas se use entre estas ramas, aínda que as sinaturas coincidan.
.
Novo algoritmo para crear e gardar etapas no almacenamento de etapas
Se, ao seleccionar etapas da caché, werf non atopa unha etapa adecuada, iníciase o proceso de montaxe dunha nova etapa.
Teña en conta que varios procesos (nun ou máis hosts) poden comezar a construír a mesma etapa aproximadamente ao mesmo tempo. Werf usa un algoritmo de bloqueo optimista etapas-almacenamento no momento de gardar a imaxe recén recollida etapas-almacenamento. Deste xeito, cando o novo escenario está listo, werf bloques etapas-almacenamento e garda alí unha imaxe recén recollida só se xa non existe alí unha imaxe adecuada (por sinatura e outros parámetros - consulte o novo algoritmo para seleccionar etapas da caché).
Garántese que unha imaxe recén montada terá un identificador único TIMESTAMP_MILLISEC (consulta o novo formato de nomenclatura). No caso en etapas-almacenamento atoparase unha imaxe adecuada, werf descartará a imaxe recentemente compilada e usará a imaxe da caché.
Noutras palabras: o primeiro proceso para rematar de construír a imaxe (o máis rápido) terá dereito a almacenala en etapas-almacenamento (e entón é esta imaxe única a que se utilizará para todas as compilacións). Un proceso de construción lento nunca impedirá que un proceso máis rápido garde os resultados de compilación da fase actual e pase á seguinte compilación.
.
Mellorouse o rendemento do creador de Dockerfile
Polo momento, o pipeline de etapas para unha imaxe construída a partir dun Dockerfile consta dunha etapa: dockerfile. Ao calcular a sinatura, calcúlase a suma de verificación dos ficheiros context, que se utilizará durante a montaxe. Antes desta mellora, werf percorreu todos os ficheiros de forma recursiva e obtivo unha suma de verificación sumando o contexto e o modo de cada ficheiro. A partir da versión 1.1, werf pode usar sumas de verificación calculadas almacenadas no repositorio de Git.
O algoritmo baséase en . O algoritmo ten en conta os rexistros en .dockerignore e percorre a árbore de ficheiros de forma recursiva só cando é necesario. Así, desacoplamos a lectura do sistema de ficheiros e a dependencia do algoritmo do tamaño context non é significativo.
O algoritmo tamén comproba os ficheiros sen rastrexar e, se é necesario, tenos en conta na suma de verificación.
Mellora o rendemento ao importar ficheiros
As versións de werf v1.1 usan un servidor rsync cando . Anteriormente, a importación facíase en dous pasos mediante un montaxe de directorio desde o sistema host.
O rendemento das importacións en macOS xa non está limitado polos volumes de Docker, e as importacións realízanse no mesmo período de tempo que Linux e Windows.
Etiquetaxe baseada no contido
Werf v1.1 admite o chamado etiquetado por contido de imaxe - etiquetaxe baseada no contido. As etiquetas das imaxes de Docker resultantes dependen do contido destas imaxes.
Ao executar o comando werf publish --tags-by-stages-signature ou werf ci-env --tagging-strategy=stages-signature imaxes publicadas do chamado sinatura de escenario imaxe. Cada imaxe está etiquetada coa súa propia sinatura das etapas desta imaxe, que se calcula segundo as mesmas regras que a sinatura normal de cada etapa por separado, pero é un identificador xeral da imaxe.
A sinatura das fases da imaxe depende de:
- o contido desta imaxe;
- historias dos cambios de Git que levaron a este contido.
Un repositorio de Git sempre ten commits ficticios que non cambian o contido dos ficheiros de imaxe. Por exemplo, commit só con comentarios ou commits combinados, ou commits que cambian eses ficheiros en Git que non se importarán á imaxe.
Ao usar a etiquetaxe baseada no contido, resólvense os problemas de reinicios innecesarios dos módulos de aplicacións en Kubernetes debido a cambios no nome da imaxe, aínda que o contido da imaxe non cambiase. Por certo, esta é unha das razóns que impide almacenar moitos microservizos dunha aplicación nun só repositorio de Git.
Ademais, a etiquetaxe baseada no contido é un método de etiquetado máis fiable que o etiquetado nas ramas de Git, porque o contido das imaxes resultantes non depende da orde na que se executan as canalizacións no sistema CI para ensamblar varios commits da mesma rama.
É importante: a partir de agora etapas-sinatura - É a única estratexia de etiquetado recomendada. Usarase por defecto no comando werf ci-env (a menos que especifique explícitamente un esquema de etiquetado diferente).
. Tamén se dedicará unha publicación separada a esta función. ACTUALIZADO (3 de abril): artigo con detalles .
Niveis de rexistro
O usuario agora ten a oportunidade de controlar a saída, establecer o nivel de rexistro e traballar coa información de depuración. Opcións engadidas --log-quiet, --log-verbose, --log-debug.
Por defecto, a saída contén a información mínima:
Cando se usa unha saída detallada (--log-verbose) podes ver como funciona werf:
Saída detallada (--log-debug), ademais da información de depuración de werf, tamén contén rexistros das bibliotecas usadas. Por exemplo, podes ver como se produce a interacción co Rexistro Docker e tamén rexistrar os lugares nos que se pasa unha cantidade significativa de tempo:
Plans de futuro
Atención! As opcións descritas a continuación están marcadas v1.1 estarán dispoñibles nesta versión, moitos deles nun futuro próximo. As actualizacións chegarán a través de actualizacións automáticas . Estas funcións non afectan á parte estable das funcións v1.1; a súa aparencia non requirirá a intervención manual do usuario nas configuracións existentes.
Compatibilidade total con varias implementacións de Docker Registry (NOVO)
- Versión: v1.1
- Datas: marzo
O obxectivo é que o usuario use unha implementación personalizada sen restricións ao usar werf.
Actualmente, identificamos o seguinte conxunto de solucións para as que imos garantir o soporte total:
- Predeterminado (biblioteca/rexistro)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Paquetes GitHub
- Rexistro de GitLab*,
- Porto*,
- peirao.
As solucións que actualmente son totalmente compatibles con werf están marcadas cun asterisco. Para outros hai apoio, pero con limitacións.
Pódense identificar dous problemas principais:
- Algunhas solucións non admiten a eliminación de etiquetas mediante a API do Rexistro de Docker, o que impide que os usuarios utilicen a limpeza automática de werf. Isto é certo para os paquetes AWS ECR, Docker Hub e GitHub.
- Algunhas solucións non admiten os chamados repositorios anidados (Docker Hub, GitHub Packages e Quay) ou si, pero o usuario debe crealos manualmente mediante a IU ou a API (AWS ECR).
Imos resolver estes e outros problemas utilizando as API nativas das solucións. Esta tarefa tamén inclúe cubrir o ciclo completo de funcionamento do werf con probas para cada un deles.
Creación de imaxes distribuídas (↑)
- Versión: v1.2 v1.1 (aumentouse a prioridade para implementar esta función)
- Datas: marzo-abril marzo
Polo momento, werf v1.0 e v1.1 só se poden usar nun servidor dedicado para operacións de creación e publicación de imaxes e implantación da aplicación en Kubernetes.
Para abrir as posibilidades de traballo distribuído de werf, cando a creación e implantación de aplicacións en Kubernetes se inicia en varios hosts arbitrarios e estes hosts non gardan o seu estado entre compilacións (executores temporais), werf é necesario para implementar a capacidade de usar o Rexistro Docker como unha tenda de escenario.
Anteriormente, cando o proxecto werf aínda se chamaba dapp, tiña esa oportunidade. Non obstante, atopamos unha serie de problemas que hai que ter en conta ao implementar esta funcionalidade en werf.
Nota. Esta función non require que o colector traballe dentro dos pods de Kubernetes, porque Para iso, cómpre desfacerse da dependencia do servidor Docker local (no pod de Kubernetes non hai acceso ao servidor Docker local, porque o proceso en si está a executarse nun contedor e werf non é compatible nin admitirá). traballar co servidor Docker a través da rede). O soporte para executar Kubernetes implementarase por separado.
Soporte oficial para GitHub Actions (NOVO)
- Versión: v1.1
- Datas: marzo
Inclúe documentación de werf (seccións referencia и orientar), así como a acción oficial de GitHub para traballar con werf.
Ademais, permitirá que werf traballe en corredores efémeros.
A mecánica da interacción do usuario co sistema CI estará baseada na colocación de etiquetas nas solicitudes de extracción para iniciar determinadas accións para crear/despegar a aplicación.
Desenvolvemento local e despregamento de aplicacións con werf (↓)
- Versión: v1.1
- Datas: xaneiro-febreiro abril
O obxectivo principal é conseguir unha única configuración unificada para a implantación de aplicacións tanto local como en produción, sen accións complexas, fóra da caixa.
werf tamén debe ter un modo operativo no que será conveniente editar o código da aplicación e recibir ao instante comentarios da aplicación en execución para a depuración.
Novo algoritmo de limpeza (NOVO)
- Versión: v1.1
- Datas: abril
Na versión actual de werf v1.1 no procedemento cleanup Non hai ningunha disposición para a limpeza de imaxes para o esquema de etiquetado baseado no contido; estas imaxes acumularanse.
Ademais, a versión actual de werf (v1.0 e v1.1) usa diferentes políticas de limpeza para imaxes publicadas baixo esquemas de etiquetado: rama Git, etiqueta Git ou Git commit.
Inventouse un novo algoritmo para limpar imaxes baseado no historial de commits en Git, unificado para todos os esquemas de etiquetado:
- Non manteña máis de N1 imaxes asociadas aos compromisos N2 máis recentes para cada git HEAD (ramas e etiquetas).
- Non almacenar máis de imaxes de escenario N1 asociadas aos compromisos máis recentes de N2 para cada git HEAD (ramas e etiquetas).
- Almacena todas as imaxes que se usan en calquera recurso do clúster de Kubernetes (escanécanse todos os contextos kube do ficheiro de configuración e espazos de nomes; podes limitar este comportamento con opcións especiais).
- Almacena todas as imaxes que se usan nos manifestos de configuración de recursos gardados nas versións de Helm.
- Pódese eliminar unha imaxe se non está asociada a ningún HEAD de git (por exemplo, porque se eliminou o propio HEAD correspondente) e non se usa en ningún manifesto do clúster de Kubernetes e nas versións de Helm.
Construción de imaxes paralelas (↓)
- Versión: v1.1
- Datas: xaneiro-febreiro abril*
A versión actual de werf recolle as imaxes e artefactos descritos en werf.yaml, secuencialmente. É necesario paralelizar o proceso de montaxe de etapas independentes de imaxes e artefactos, así como proporcionar unha saída cómoda e informativa.
* Nota: o prazo cambiouse debido ao aumento da prioridade para implementar a montaxe distribuída, o que engadirá máis capacidades de escalado horizontal, así como o uso de werf con accións de GitHub. A montaxe en paralelo é o seguinte paso de optimización, proporcionando escalabilidade vertical ao montar un proxecto.
Transición a Helm 3 (↓)
- Versión: v1.2
- Datas: febreiro-marzo maio*
Inclúe a migración a unha nova base de código e unha forma comprobada e cómoda de migrar as instalacións existentes.
* Nota: cambiar a Helm 3 non engadirá características significativas a werf, porque todas as funcións clave de Helm 3 (fusión de 3 vías e sen tiller) xa están implementadas en werf. Ademais, werf ten ademais dos indicados. Non obstante, esta transición permanece nos nosos plans e implementarase.
Jsonnet para describir a configuración de Kubernetes (↓)
- Versión: v1.2
- Datas: xaneiro-febreiro abril-maio
Werf admitirá descricións de configuración para Kubernetes en formato Jsonnet. Ao mesmo tempo, werf seguirá sendo compatible con Helm e haberá unha opción de formato de descrición.
O motivo é que os modelos Go, segundo moitas persoas, teñen unha alta barreira de entrada, e a comprensibilidade do código destes modelos tamén se resente.
Tamén se está considerando a posibilidade de introducir outros sistemas de descrición da configuración de Kubernetes (por exemplo, Kustomize).
Traballando dentro de Kubernetes (↓)
- Versión: v1.2
- Datas: abril-maio maio-xuño
Obxectivo: asegurarse de que as imaxes se crean e que a aplicación se entregue mediante runners en Kubernetes. Eses. As novas imaxes pódense reunir, publicar, limpar e despregarse directamente desde os pods de Kubernetes.
Para implementar esta capacidade, primeiro ten que ser capaz de construír imaxes distribuídas (ver punto anterior).
Tamén require compatibilidade para o modo operativo do creador sen un servidor Docker (é dicir, unha construción tipo Kaniko ou no espazo de usuario).
Werf admitirá a creación de Kubernetes non só con Dockerfile, senón tamén co seu creador Stapel con reconstrucións incrementais e Ansible.
Un paso cara ao desenvolvemento aberto
Amamos a nosa comunidade (, ) e queremos que cada vez máis persoas axuden a mellorar o werf, a comprender a dirección na que nos movemos e a participar no desenvolvemento.
Hai pouco decidiuse cambiar a co fin de revelar o proceso de traballo do noso equipo. Agora podes ver os plans inmediatos, así como o traballo actual nas seguintes áreas:
- ;
- ;
- ;
- .
Traballouse moito con problemas:
- Eliminados os irrelevantes.
- As existentes son levadas a un único formato, cun número suficiente de detalles e detalles.
- Engadíronse novos temas con ideas e suxestións.
Como activar a versión v1.1
A versión está dispoñible actualmente en (en canles estable и sólido como unha roca non obstante, as liberacións aparecerán a medida que se produza a estabilización ea xa é o suficientemente estable para o seu uso, porque pasou polas canles alfa и beta). Activado do seguinte xeito:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusión
A nova arquitectura de almacenamento de escenarios e as optimizacións de creadores para os creadores de Stapel e Dockerfile abren a posibilidade de implementar compilacións distribuídas e paralelas en werf. Estas funcións aparecerán en breve na mesma versión v1.1 e estarán dispoñibles automaticamente mediante o mecanismo de actualización automática (para usuarios ).
Nesta versión, engadiuse unha estratexia de etiquetado baseada no contido da imaxe: etiquetaxe baseada no contido, que se converteu na estratexia predeterminada. O rexistro de comandos principal tamén foi reelaborado: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
O seguinte paso significativo é engadir conxuntos distribuídos. As compilacións distribuídas convertéronse nunha prioridade máis alta que as paralelas desde a versión 1.0 porque engaden máis valor a werf: escalamento vertical dos creadores e compatibilidade con creadores efémeros en varios sistemas CI/CD, así como a posibilidade de facer soporte oficial para as accións de GitHub. . Polo tanto, trasladáronse os prazos de execución das montaxes paralelas. Non obstante, estamos a traballar para implementar ambas posibilidades canto antes.
Segue as noticias! E non esquezas visitarnos en para crear un problema, atopar un existente e engadir un plus, crear un PR ou simplemente ver o desenvolvemento do proxecto.
PS
Lea tamén no noso blog:
- «»
- «»;
- Unha serie de notas sobre innovacións en werf:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com