Het onderwerp van een mono-repository is meer dan eens besproken en veroorzaakt in de regel zeer actieve controverse. Door te maken als een open source-tool die is ontworpen om het proces van het bouwen van applicatiecode van Git naar Docker-images te verbeteren (en ze vervolgens aan Kubernetes te leveren), denken we niet veel na over welke keuze de beste is. Voor ons is het primair om al het nodige te bieden aan aanhangers van verschillende meningen (als dit natuurlijk niet in tegenspraak is met het gezond verstand).
De recente mono-repo-ondersteuning van werf is hier een goed voorbeeld van. Maar laten we eerst eens kijken hoe deze ondersteuning in het algemeen verband houdt met het gebruik van werf en wat de Docker Registry ermee te maken heeft ...
Problemen
Laten we ons zo'n situatie voorstellen. Het bedrijf heeft veel ontwikkelingsteams die aan onafhankelijke projecten werken. De meeste applicaties draaien op Kubernetes en zijn dus gecontaineriseerd. Om containers, afbeeldingen op te slaan, hebt u een register (register) nodig. Als zo'n register gebruikt het bedrijf Docker Hub met één account COMPANY. Net als bij de meeste opslagsystemen voor broncode, Docker Hub staat geen geneste repository-hiërarchie toe, zoals COMPANY/PROJECT/IMAGE. In dat geval… hoe kun je met deze beperking niet-monolithische applicaties in het register opslaan zonder voor elk project een apart account aan te maken?
Misschien is iemand uit de eerste hand bekend met de beschreven situatie, maar laten we eens kijken naar het probleem van het organiseren van applicatieopslag in het algemeen, d.w.z. zonder verwijzing naar het bovenstaande voorbeeld en Docker Hub.
Oplossingen
Als de toepassing monolithisch, komt in één afbeelding, dan zijn er geen vragen en slaan we de afbeeldingen gewoon op in het containerregister van het project.
Wanneer een applicatie wordt gepresenteerd als meerdere componenten, microservices, dan is een bepaalde aanpak vereist. Op het voorbeeld van een typische webapplicatie bestaande uit twee afbeeldingen: frontend и backend - de mogelijke opties zijn:
- Sla afbeeldingen op in afzonderlijke geneste opslagplaatsen:
- Bewaar alles in één repository en beschouw de afbeeldingsnaam in de tag bijvoorbeeld als volgt:
NB: Eigenlijk is er nog een andere optie met opslaan in verschillende repositories, PROJECT-frontend и PROJECT-backend, maar we zullen het niet overwegen vanwege de complexiteit van ondersteuning, organisatie en verdeling van rechten tussen gebruikers.
werf ondersteuning
Aanvankelijk beperkte werf zich tot geneste repositories - gelukkig ondersteunen de meeste registers deze functie. Vanaf versie , toegevoegd werk met registers waarin nesten wordt niet ondersteund, en Docker Hub is er een van. Vanaf dat moment heeft de gebruiker de keuze hoe de applicatie-images worden opgeslagen.
Uitvoering mogelijk onder optie --images-repo-mode=multirepo|monorepo (standaard multirepo, d.w.z. opslag in geneste opslagplaatsen). Het definieert de patronen waarmee afbeeldingen in het register worden opgeslagen. Het volstaat om de gewenste modus te selecteren bij het gebruik van de basiscommando's en al het andere blijft ongewijzigd.
Omdat de meeste werfopties kunnen worden ingesteld omgevingsvariabelen, in CI / CD-systemen is de opslagmodus meestal eenvoudig globaal in te stellen voor het hele project. Bijvoorbeeld, in het geval van GitLab voeg gewoon een omgevingsvariabele toe aan de projectinstellingen: Instellingen -> CI / CD -> Variabelen: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Als we het hebben over het publiceren van afbeeldingen en het uitrollen van applicaties (u kunt in detail over deze processen lezen in de relevante documentatie-artikelen: и ), dan bepaalt de modus alleen het sjabloon waarmee u met de afbeelding kunt werken.
De duivel is in de details
Het verschil en de grootste moeilijkheid bij het toevoegen van een nieuwe opslagmethode is het opschonen van het register (voor zuiveringsfuncties ondersteund door werf, zie ).
Bij het opschonen houdt werf rekening met de afbeeldingen die worden gebruikt in Kubernetes-clusters, evenals met het beleid dat door de gebruiker is geconfigureerd. Beleid is gebaseerd op de verdeling van tags in strategieën. Momenteel ondersteunde strategieën:
- 3 strategieën gekoppeld door Git-primitieven zoals tag, branch en commit;
- 1 strategie voor willekeurige aangepaste tags.
We slaan informatie over de tagstrategie op bij het publiceren van de afbeelding in de labels van de uiteindelijke afbeelding. De betekenis zelf is de zogenaamde meta-tag - Vereist om sommige beleidsregels toe te passen. Bij het verwijderen van bijvoorbeeld een branch of tag uit een Git-repository is het logisch om related ongebruikt afbeeldingen uit het register, dat onder een deel van ons beleid valt.
Wanneer opgeslagen in één repository (monorepo), in de afbeeldingstag kan naast de metatag ook de naam van de afbeelding worden opgeslagen: PROJECT:frontend-META-TAG. Om ze te scheiden, hebben we geen specifiek scheidingsteken geïntroduceerd, maar gewoon de nodige waarde toegevoegd aan het label van de uiteindelijke afbeelding bij publicatie.
NB: Als je geïnteresseerd bent om alles te bekijken wat in de werf-broncode wordt beschreven, dan kan het startpunt zijn .
In dit artikel zullen we niet meer aandacht besteden aan de problemen en rechtvaardiging van onze aanpak: over tagstrategieën, het opslaan van gegevens in labels en het publicatieproces als geheel - dit alles wordt in detail beschreven in een recent rapport van Dmitry Stolyarov: “.
Samenvattend
Het ontbreken van ondersteuning voor niet-geneste registers was voor ons of de ons bekende werf-gebruikers geen blokkerende factor - je kunt immers altijd een apart image-register opzetten (of overstappen naar een voorwaardelijk Container Registry in Google Cloud)... Echter, het verwijderen van een dergelijke beperking leek logisch om de tool handiger te maken voor de bredere DevOps-gemeenschap. Toen we het implementeerden, stuitten we op de grootste moeilijkheid bij het herwerken van het mechanisme voor het opschonen van het containerregister. Nu alles klaar is, is het fijn om te beseffen dat het voor iemand gemakkelijker is geworden, en wij (als hoofdontwikkelaars van het project) zullen geen merkbare problemen hebben om deze functie verder te ondersteunen.
Blijf bij ons en binnenkort vertellen we je over andere innovaties in !
PS
Lees ook op onze blog:
- «";
- «.
Bron: www.habr.com