Het onderwerp van monorepositories is al meerdere keren besproken en roept doorgaans zeer actieve discussies op. Wanneer we creëren als een Open Source-tool, bedoeld om de bouwprocessen van applicatiecode uit Git in Docker-images (en hun daaropvolgende levering in Kubernetes) te verbeteren, denken we weinig na over welke keuze het beste is. Voor ons is het primair om alles te bieden wat nodig is voor aanhangers van verschillende meningen (tenzij het natuurlijk in strijd is met gezond verstand).
De recent geïntroduceerde ondersteuning voor mono-repo in werf is daar een goed voorbeeld van. Maar laten we eerst bekijken hoe deze ondersteuning eigenlijk verband houdt met het gebruik van werf en wat Docker Registry hiermee te maken heeft…
Problemen
Stel je de volgende situatie voor. In het bedrijf zijn er veel ontwikkelteams die aan onafhankelijke projecten werken. De meeste applicaties draaien in Kubernetes en zijn daarom gecontaineriseerd. Voor het opslaan van containers, images, is er een registry nodig. In het bedrijf wordt Docker Hub gebruikt met één enkel account COMPANY. In lijn met de meeste systemen voor het opslaan van broncode, stelt Docker Hub niet in staat om een geneste hiërarchie van repositories te creëren, zoals COMPANY/PROJECT/IMAGE. In dit geval… hoe moeten we met deze beperking niet-monolithische applicaties in de registry opslaan zonder een apart account voor elk project te creëren?
Misschien komt de beschreven situatie iemand bekend voor, maar laten we de kwestie van het organiseren van de opslag van applicaties in het algemeen bekijken, dus zonder verwijzing naar het eerdere voorbeeld en Docker Hub.
Oplossingsmethoden
Als de applicatie monolithisch, wordt geleverd in één image, zijn er geen vragen en slaan we gewoon de images op in de containerregistry van het project.
Wanneer de applicatie bestaat uit meerdere componenten, microservices, is het nodig om een bepaalde aanpak te kiezen. Aan de hand van een typisch webapplicatie, bestaande uit twee images: frontend en backend — mogelijke opties zijn:
- Sla de images op in aparte geneste repositories:
- Sla alles in één repository op en neem de naam van de image mee in de tag, bijvoorbeeld als volgt:
NB: Er is eigenlijk ook een optie om op te slaan in verschillende repositories, PROJECT-frontend en PROJECT-backend, maar die zullen we niet bespreken vanwege de complexiteit van ondersteuning, organisatie en verdeling van rechten tussen gebruikers.
Ondersteuning in werf
Aanvankelijk beperkte werf zich tot geneste repositories - gelukkig ondersteunt het merendeel van de registries deze mogelijkheid. Vanaf versie , is de ondersteuning voor registries toegevoegd waarin nesten niet wordt ondersteund, waaronder Docker Hub. Vanaf dat moment had de gebruiker de keuze hoe applicatie-afbeeldingen op te slaan.
De implementatie is beschikbaar binnen de optie --images-repo-mode=multirepo|monorepo (standaard multirepo, d.w.z. opslag in geneste repositories). Het definieert de sjablonen volgens welke afbeeldingen in de registry worden opgeslagen. Het is voldoende om de gewenste modus te kiezen bij het gebruik van de basiscommando's, en de rest blijft ongewijzigd.
Aangezien de meeste opties van werf kunnen worden ingesteld via omgeving variabelen, is de opslagmodus in CI/CD-systemen doorgaans makkelijk globaal voor het hele project in te stellen. Bijvoorbeeld, in het geval van GitLab is het voldoende om een omgevingsvariabele toe te voegen in 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 (over deze processen is meer te lezen in de relevante documenten: en ), dan bepaalt de modus uitsluitend het sjabloon waarmee kan worden gewerkt met de afbeelding.
Het zit hem in de details
Het verschil en de belangrijkste uitdaging bij het toevoegen van een nieuwe opslagmethode is het opschonen van de registry (de opschoonmogelijkheden ondersteund in werf, zie in ).
Bij het opschonen houdt werf rekening met de in Kubernetes-clusters gebruikte afbeeldingen, evenals met de door de gebruiker ingestelde beleidsregels. De basis van de beleidsregels ligt in de opsplitsing van tags in strategieën. Momenteel ondersteunde strategieën zijn:
- 3 strategieën gerelateerd aan Git-primitieven, zoals tag, branch en commit;
- 1 strategie voor willekeurige door de gebruiker gedefinieerde tags.
Informatie over de tagstrategie wordt opgeslagen bij het publiceren van de afbeelding in de labels van de eindafbeelding. De waarde zelf - de zogenaamde metatag - is nodig voor de toepassing van een deel van de beleidsregels. Bijvoorbeeld, bij het verwijderen van een branch of tag uit de Git-repository is het logisch om ook de bijbehorende ongebruikte afbeeldingen uit de registry te verwijderen, wat dekt een deel van onze beleidsregels.
Bij opslag in één repository (monorepo), kan naast de metatag ook de naam van de afbeelding worden opgeslagen in de tag van de afbeelding: PROJECT:frontend-META-TAG. Voor hun scheiding hebben we geen specifieke scheidingstekens geïntroduceerd, maar gewoon de nodige waarde aan het label van de uiteindelijke afbeelding toegevoegd bij publicatie.
NB: Als je geïnteresseerd bent in alles wat in de broncode van werf is beschreven, kan het startpunt zijn .
In dit artikel zullen we niet verder ingaan op de problematiek en het onderbouwen van onze aanpak: over taggingstrategieën, gegevensopslag in labels en het publicatieproces in het algemeen — hierover is uitgebreid gesproken in het recente verslag van Dmitry Stolyarov: «».
Samenvattend
Het gebrek aan ondersteuning voor register zonder genestelde structuren was geen blokkade voor ons of de bekende gebruikers van werf — het is immers altijd mogelijk om een afzonderlijk image-register op te zetten (of over te stappen op een zogeheten Container Registry in Google Cloud)... Echter, het verwijderen van zo'n beperking leek logisch om het gereedschap gebruiksvriendelijker te maken voor een breder DevOps-gemeenschap. Bij de implementatie ervan stuitten we op de grootste uitdaging in het herzien van het mechanisme voor het opruimen van het containerregister. Nu alles klaar is, is het fijn om te beseffen dat het voor iemand gemakkelijker is geworden, en voor ons (als de belangrijkste ontwikkelaars van het project) zijn er geen noemenswaardige moeilijkheden te verwachten bij de verdere ondersteuning van deze functie.
Blijf bij ons en binnenkort vertellen we je over andere innovaties in de !
P.S.
Lees ook op onze blog:
- «»;
- «».
Bron: habr.com
