Mellor tarde que nunca. Ou como case cometemos un grave erro ao non ter soporte para Dockerfiles habituais para crear imaxes de aplicacións.
Xa falaremos — Utilidade GitOps que se integra con calquera sistema CI/CD e ofrece xestión de todo o ciclo de vida da aplicación, permitindo:
- recoller e publicar imaxes,
- implementar aplicacións en Kubernetes,
- eliminar imaxes non utilizadas mediante políticas especiais.
A filosofía do proxecto é recoller ferramentas de baixo nivel nun único sistema unificado que ofreza aos enxeñeiros de DevOps control sobre as aplicacións. Se é posible, deberían utilizarse as utilidades existentes (como Helm e Docker). Se non hai solución a un problema, podemos crear e apoiar todo o necesario para iso.
Fondo: o teu propio colector de imaxes
Isto é o que pasou co colector de imaxes en werf: o habitual Dockerfile non nos abondaba. Se botas unha ollada rápida á historia do proxecto, este problema xa apareceu nas primeiras versións de werf (entón aínda ).
Ao crear unha ferramenta para crear aplicacións en imaxes de Docker, axiña nos decatamos de que Dockerfile non era axeitado para nós para algunhas tarefas moi específicas:
- A necesidade de construír pequenas aplicacións web típicas segundo o seguinte esquema estándar:
- instalar dependencias de aplicacións en todo o sistema,
- instalar un paquete de bibliotecas de dependencia de aplicacións,
- recoller activos,
- e o máis importante, actualizar o código da imaxe de forma rápida e eficiente.
- Cando se fan cambios nos ficheiros do proxecto, o creador debe crear rapidamente unha nova capa aplicando un parche aos ficheiros modificados.
- Se determinados ficheiros cambiaron, entón é necesario reconstruír a etapa dependente correspondente.
Hoxe o noso coleccionista ten moitas outras posibilidades, pero estes foron os desexos e impulsos iniciais.
En xeral, sen pensalo dúas veces, armámonos coa linguaxe de programación que utilizamos (Ver abaixo) e emprender o camiño para implementar DSL propio! De acordo cos obxectivos, pretendíase describir o proceso de montaxe por etapas e determinar as dependencias destas etapas dos expedientes. E complementouno coleccionista propio, que converteu o DSL no obxectivo final: unha imaxe ensamblada. Ao principio o DSL estaba en Ruby, pero como — a configuración do noso colector comezou a describirse nun ficheiro YAML.
Configuración antiga para dapp en Ruby
Configuración actual para werf en YAML
O mecanismo do colector tamén cambiou co paso do tempo. Nun primeiro momento, simplemente xeramos un Dockerfile temporal sobre a marcha a partir da nosa configuración, e despois comezamos a executar instrucións de montaxe en contedores temporais e confirmar.
NB: Polo momento, o noso colector, que funciona coa súa propia configuración (en YAML) e que se chama colector Stapel, xa se converteu nunha ferramenta bastante poderosa. A súa descrición detallada merece artigos separados, e os detalles básicos pódense atopar en .
Conciencia do problema
Pero decatámonos, e non inmediatamente, de que cometemos un erro: non sumamos a habilidade crear imaxes mediante Dockerfile estándar e intégralas na mesma infraestrutura de xestión de aplicacións de extremo a extremo (é dicir, recompilar imaxes, implantalas e limpalas). Como podería ser posible facer unha ferramenta para a súa implantación en Kubernetes e non implementar o soporte de Dockerfile, é dicir. forma estándar de describir imaxes para a maioría dos proxectos?...
En lugar de responder a esta pregunta, ofrecemos unha solución. E se xa tes un Dockerfile (ou un conxunto de Dockerfiles) e queres usar werf?
NB: Por certo, por que quererías usar werf? As principais características redúcense nas seguintes:
- ciclo completo de xestión de aplicacións incluída a limpeza de imaxes;
- a capacidade de xestionar a montaxe de varias imaxes á vez desde unha única configuración;
- Proceso de implantación mellorado para gráficos compatibles con Helm.
Pódese atopar unha lista máis completa deles en .
Entón, se antes nos ofreceramos reescribir o Dockerfile na nosa configuración, agora diremos: "Deixa que werf constrúa os teus Dockerfiles!"
Como usar?
A implementación completa desta función apareceu na versión . O principio xeral é sinxelo: o usuario especifica o camiño a un Dockerfile existente na configuración de werf e, a continuación, executa o comando werf build... e iso é todo: werf ensamblará a imaxe. Vexamos un exemplo abstracto.
Anunciamos o seguinte Dockerfile na raíz do proxecto:
FROM ubuntu:18.04
RUN echo Building ...
E anunciaremos werf.yamlque usa isto Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Todo! Esquerda correr werf build:
Ademais, pode declarar o seguinte werf.yaml para construír varias imaxes de diferentes Dockerfiles á vez:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Finalmente, tamén admite pasar parámetros de compilación adicionais, como --build-arg и --add-host - mediante werf config. Unha descrición completa da configuración da imaxe de Dockerfile está dispoñible en .
Como funciona isto?
Durante o proceso de compilación, funciona a caché estándar das capas locais en Docker. Non obstante, o importante é que tamén werf integra a configuración de Dockerfile na súa infraestrutura. Que significa isto?
- Cada imaxe construída a partir dun Dockerfile consta dunha etapa chamada
dockerfile(podes ler máis sobre que etapas hai en werf ). - Para escenario
dockerfilewerf calcula unha sinatura que depende do contido da configuración de Dockerfile. Cando a configuración de Dockerfile cambia, a sinatura do escenario cambiadockerfilee werf inicia unha reconstrución desta etapa cunha nova configuración de Dockerfile. Se a sinatura non cambia, entón werf toma a imaxe da caché (describíronse máis detalles sobre o uso de sinaturas en werf en ). - A continuación, as imaxes recollidas pódense publicar co comando
werf publish(Ouwerf build-and-publish) e utilízao para a súa implantación en Kubernetes. As imaxes publicadas no Rexistro de Docker limparanse mediante ferramentas de limpeza estándar de werf, é dicir. As imaxes antigas (máis de N días), as imaxes asociadas a ramas de Git inexistentes e outras políticas limparanse automaticamente.
Podes atopar máis detalles sobre os puntos descritos aquí na documentación:
- ;
- ;
- .
Notas e precaucións
1. O URL externo non é compatible con ADD
Actualmente non se admite o uso dun URL externo nunha directiva ADD. Werf non iniciará unha reconstrución cando cambie o recurso no URL especificado. Pensamos engadir esta función en breve.
2. Non podes engadir .git á imaxe
En xeral, engadindo un directorio .git na imaxe - unha mala práctica viciosa e aquí tes por que:
- Se
.gitpermanece na imaxe final, isto viola os principios : Dado que a imaxe final debe estar ligada a un único commit, non debería ser posiblegit checkoutcompromiso arbitrario. -
.gitaumenta o tamaño da imaxe (o repositorio pode ser grande debido ao feito de que unha vez se lle engadiron ficheiros grandes e despois elimináronse). O tamaño dunha árbore de traballo asociada só a unha confirmación específica non dependerá do historial de operacións en Git. Neste caso, a adición e posterior eliminación.gitda imaxe final non funcionará: a imaxe aínda adquirirá unha capa adicional - así funciona Docker. - Docker pode iniciar unha reconstrución innecesaria, aínda que se estea construíndo a mesma confirmación, pero desde diferentes árbores de traballo. Por exemplo, GitLab crea directorios clonados separados
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectcando se activa a montaxe paralela. A montaxe extra será debido ao feito de que o directorio.gité diferente en diferentes versións clonadas do mesmo repositorio, aínda que se constrúa a mesma confirmación.
O último punto tamén ten consecuencias ao usar werf. Werf require que a caché creada estea presente ao executar algúns comandos (p. ex. werf deploy). Cando se executan estes comandos, werf calcula sinaturas de etapa para as imaxes especificadas en werf.yaml, e deben estar na caché de montaxe; se non, o comando non poderá seguir traballando. Se a sinatura do escenario depende do contido .git, entón obtemos unha caché que é inestable aos cambios en ficheiros irrelevantes e werf non poderá perdoar tal descoido (para máis detalles, consulte ).
En xeral, engadindo só certos ficheiros necesarios a través das instrucións ADD en todo caso aumenta a eficacia e fiabilidade do escrito Dockerfile, e tamén mellora a estabilidade da caché recollida para iso Dockerfile, a cambios irrelevantes en Git.
Total
O noso camiño inicial para escribir o noso propio constructor para necesidades específicas foi duro, honesto e sinxelo: en lugar de usar muletas enriba do Dockerfile estándar, escribimos a nosa solución cunha sintaxe personalizada. E isto tiña as súas vantaxes: o coleccionista Stapel afronta perfectamente a súa tarefa.
Non obstante, no proceso de escribir o noso propio constructor, perdemos de vista a compatibilidade dos Dockerfiles existentes. Este fallo foi solucionado e, no futuro, pensamos desenvolver soporte para Dockerfile xunto co noso creador personalizado Stapel para a montaxe distribuída e para a montaxe mediante Kubernetes (é dicir, a montaxe en corredores dentro de Kubernetes, como se fai en kaniko).
Entón, se de súpeto tes un par de Dockerfiles por aí... probar !
PS Lista de documentación sobre o tema
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lea tamén no noso blog: "».
Fonte: www.habr.com