O tema dun mono-repositorio foi discutido máis dunha vez e, por regra xeral, causa controversia moi activa. Ao crear como unha ferramenta de código aberto deseñada para mellorar o proceso de creación de código de aplicación desde Git ata imaxes de Docker (e despois entregalas a Kubernetes), non pensamos moito sobre cal é a mellor opción. Para nós, é primordial proporcionar todo o necesario para os partidarios de diferentes opinións (se isto non contradí o sentido común, claro).
O recente soporte mono-repo de werf é un bo exemplo diso. Pero primeiro, imos descubrir como este soporte está xeralmente relacionado co uso de werf e que ten que ver o Rexistro Docker con el...
Problemas
Imaxinemos unha situación así. A empresa ten moitos equipos de desenvolvemento que traballan en proxectos independentes. A maioría das aplicacións execútanse en Kubernetes e, polo tanto, están en contenedores. Para almacenar contedores, imaxes, necesitas un rexistro (rexistro). Como tal rexistro, a empresa usa Docker Hub cunha única conta COMPANY. Similar á maioría dos sistemas de almacenamento de código fonte, Docker Hub non permite a xerarquía de repositorios anidados, como COMPANY/PROJECT/IMAGE. Nese caso... como podes almacenar aplicacións non monolíticas no rexistro con esta limitación sen crear unha conta separada para cada proxecto?
Quizais, a situación descrita sexa familiar para alguén de primeira man, pero consideremos a cuestión de organizar o almacenamento de aplicacións en xeral, é dicir. sen facer referencia ao exemplo anterior e ao Docker Hub.
Solucións
Se a aplicación monolítico, vén nunha imaxe, entón non hai preguntas e simplemente gardamos as imaxes no rexistro de contedores do proxecto.
Cando unha aplicación se presenta como varios compoñentes, microservizos, entón é necesario un certo enfoque. No exemplo dunha aplicación web típica formada por dúas imaxes: frontend и backend - As opcións posibles son:
- Almacenar imaxes en repositorios anidados separados:
- Almacena todo nun repositorio e considera o nome da imaxe na etiqueta, por exemplo, como segue:
NB: En realidade, hai outra opción con gardar en diferentes repositorios, PROJECT-frontend и PROJECT-backend, pero non o consideraremos pola complexidade de soporte, organización e distribución de dereitos entre usuarios.
apoio werf
Inicialmente, werf limitouse a repositorios aniñados; afortunadamente, a maioría dos rexistros admiten esta función. A partir da versión , traballo engadido con rexistros nos que aniñación non é compatible, e Docker Hub é un deles. A partir dese momento, o usuario pode escoller como almacenar as imaxes da aplicación.
Implementación dispoñible baixo a opción --images-repo-mode=multirepo|monorepo (predeterminado multirepo, é dicir. almacenamento en repositorios anidados). Define os patróns polos que se almacenan as imaxes no rexistro. É suficiente seleccionar o modo desexado cando se usan os comandos básicos e todo o demais permanecerá inalterado.
Porque a maioría das opcións de werf pódense configurar variables de ambiente, nos sistemas CI/CD, o modo de almacenamento adoita ser fácil de configurar globalmente para todo o proxecto. Por exemplo, no caso de GitLab basta con engadir unha variable de ambiente na configuración do proxecto: Configuración -> CI/CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Se falamos sobre a publicación de imaxes e o lanzamento de aplicacións (podes ler sobre estes procesos en detalle nos artigos de documentación relevantes: и ), entón o modo só determina o modelo polo que pode traballar coa imaxe.
O demo está nos detalles
A diferenza e a principal dificultade ao engadir un novo método de almacenamento está no proceso de limpeza do rexistro (para as funcións de purga admitidas por werf, consulte ).
Ao limpar, werf ten en conta as imaxes utilizadas nos clústeres de Kubernetes, así como as políticas configuradas polo usuario. As políticas baséanse na división das etiquetas en estratexias. Estratexias soportadas actualmente:
- 3 estratexias ligadas por primitivas de Git como tag, branch e commit;
- 1 estratexia para etiquetas personalizadas arbitrarias.
Gardamos información sobre a estratexia de etiqueta ao publicar a imaxe nas etiquetas da imaxe final. O significado en si é o chamado metaetiqueta - Obrigatorio para aplicar algunhas das políticas. Por exemplo, ao eliminar unha rama ou etiqueta dun repositorio de Git, é lóxico eliminar o relacionado sen usar imaxes do rexistro, que está cuberto por parte das nosas políticas.
Cando se garda nun repositorio (monorepo), na etiqueta da imaxe, ademais da metaetiqueta, tamén se pode almacenar o nome da imaxe: PROJECT:frontend-META-TAG. Para separalos, non introducimos ningún separador específico, senón que simplemente engadimos o valor necesario á etiqueta da imaxe final á hora de publicar.
NB: Se estás interesado en mirar todo o que se describe no código fonte werf, entón o punto de partida pode ser .
Neste artigo, non prestaremos máis atención aos problemas e á xustificación do noso enfoque: sobre as estratexias de etiquetado, o almacenamento de datos en etiquetas e o proceso de publicación no seu conxunto - todo isto descríbese en detalle nun informe recente de Dmitry Stolyarov: "».
Para resumir
A falta de soporte para rexistros non anidados non foi un factor de bloqueo para nós nin para os usuarios de werf coñecidos por nós; despois de todo, sempre pode crear un rexistro de imaxes separado (ou cambiar a un Rexistro de contedores condicional en Google Cloud)... Non obstante, eliminar tal restrición parecía lóxico para que a ferramenta fose máis conveniente para a comunidade DevOps máis ampla. Implementándoo, enfrontámonos á principal dificultade para reelaborar o mecanismo de limpeza do rexistro de contedores. Agora que todo está listo, é agradable darse conta de que se fixo máis doado para alguén, e nós (como os principais desenvolvedores do proxecto) non teremos dificultades notables para seguir apoiando esta función.
Quédese connosco e moi pronto falarémosvos doutras novidades en !
PS
Lea tamén no noso blog:
- «»;
- «».
Fonte: www.habr.com