{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Ondersteuning voor monorepo en multirepo in werf en wat Docker Registry hiermee te maken heeft","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ondersteuning
\n
\nHet onderwerp van monorepositories is al meerdere keren besproken en roept doorgaans zeer actieve discussies op. Wanneer we cre\u00ebren werf<\/a><\/noindex> 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).<\/p>\n

De recent ge\u00efntroduceerde 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\u2026<\/a><\/noindex><\/p>\n

Problemen<\/h2>\n

\nStel 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 \u00e9\u00e9n enkel account COMPANY<\/code>. In lijn met de meeste systemen voor het opslaan van broncode, stelt Docker Hub niet in staat om een geneste hi\u00ebrarchie van repositories te cre\u00ebren<\/b>, zoals COMPANY\/PROJECT\/IMAGE<\/code>. In dit geval\u2026 hoe moeten we met deze beperking niet-monolithische applicaties in de registry opslaan zonder een apart account voor elk project te cre\u00ebren? <\/p>\n

\"Ondersteuning
\n
\nMisschien 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.<\/p>\n

Oplossingsmethoden<\/h3>\n

\nAls de applicatie monolithisch<\/b>, wordt geleverd in \u00e9\u00e9n image, zijn er geen vragen en slaan we gewoon de images op in de containerregistry van het project.<\/p>\n

Wanneer de applicatie bestaat uit meerdere componenten, microservices<\/b>, is het nodig om een bepaalde aanpak te kiezen. Aan de hand van een typisch webapplicatie, bestaande uit twee images: frontend<\/code> en backend<\/code> \u2014 mogelijke opties zijn:<\/p>\n

    \n
  1. Sla de images op in aparte geneste repositories:\n

    \"Ondersteuning<\/li>\n

  2. Sla alles in \u00e9\u00e9n repository op en neem de naam van de image mee in de tag, bijvoorbeeld als volgt:\n

    \"Ondersteuning<\/li>\n<\/ol>\n

    \nNB<\/b>: Er is eigenlijk ook een optie om op te slaan in verschillende repositories, PROJECT-frontend<\/code> en PROJECT-backend<\/code>, maar die zullen we niet bespreken vanwege de complexiteit van ondersteuning, organisatie en verdeling van rechten tussen gebruikers.<\/i><\/p>\n

    Ondersteuning in werf<\/h2>\n

    \nAanvankelijk beperkte werf zich tot geneste repositories - gelukkig ondersteunt het merendeel van de registries deze mogelijkheid. Vanaf versie v1.0.4-alpha.3<\/a><\/noindex>, is de ondersteuning voor registries toegevoegd waarin nesten niet wordt ondersteund<\/b>, waaronder Docker Hub. Vanaf dat moment had de gebruiker de keuze hoe applicatie-afbeeldingen op te slaan.<\/p>\n

    De implementatie is beschikbaar binnen de optie --images-repo-mode=multirepo|monorepo<\/code> (standaard multirepo<\/code>, 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.<\/p>\n

    Aangezien de meeste opties van werf kunnen worden ingesteld via omgeving variabelen<\/b>, is de opslagmodus in CI\/CD-systemen doorgaans makkelijk globaal voor het hele project in te stellen. Bijvoorbeeld, in het geval van GitLab<\/b> is het voldoende om een omgevingsvariabele toe te voegen in de projectinstellingen: Instellingen -> CI \/ CD -> Variabelen: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    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: Publiceerproces<\/a><\/noindex> en Uitrolproces<\/a><\/noindex>), dan bepaalt de modus uitsluitend het sjabloon waarmee kan worden gewerkt met de afbeelding.<\/p>\n

    Het zit hem in de details<\/h3>\n

    \nHet 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 Opschoonproces<\/a><\/noindex>)<\/i>.<\/p>\n

    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\u00ebn. Momenteel ondersteunde strategie\u00ebn zijn:<\/p>\n

      \n
    1. 3 strategie\u00ebn gerelateerd aan Git-primitieven, zoals tag, branch en commit;<\/li>\n
    2. 1 strategie voor willekeurige door de gebruiker gedefinieerde tags.<\/li>\n<\/ol>\n

      \nInformatie over de tagstrategie wordt opgeslagen bij het publiceren van de afbeelding in de labels van de eindafbeelding. De waarde zelf - de zogenaamde metatag<\/b> - 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<\/i> afbeeldingen uit de registry te verwijderen, wat dekt een deel van onze beleidsregels.<\/p>\n

      Bij opslag in \u00e9\u00e9n repository (monorepo<\/code>), kan naast de metatag ook de naam van de afbeelding worden opgeslagen in de tag van de afbeelding: PROJECT:frontend<\/b>-META-TAG<\/code>. Voor hun scheiding hebben we geen specifieke scheidingstekens ge\u00efntroduceerd, maar gewoon de nodige waarde aan het label van de uiteindelijke afbeelding toegevoegd bij publicatie.<\/p>\n

      NB<\/b>: Als je ge\u00efnteresseerd bent in alles wat in de broncode van werf is beschreven, kan het startpunt zijn PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      In dit artikel zullen we niet verder ingaan op de problematiek en het onderbouwen van onze aanpak: over taggingstrategie\u00ebn, gegevensopslag in labels en het publicatieproces in het algemeen \u2014 hierover is uitgebreid gesproken in het recente verslag van Dmitry Stolyarov: \u00abwerf - onze tool voor CI\/CD in Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Samenvattend<\/h2>\n

      \nHet gebrek aan ondersteuning voor register zonder genestelde structuren was geen blokkade voor ons of de bekende gebruikers van werf \u2014 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.<\/p>\n

      Blijf bij ons en binnenkort vertellen we je over andere innovaties in de werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLees ook op onze blog:<\/p>\n