Hoe u een Docker-image-repository host en Docker-images bouwt met een GitLab Self-Managed-instantie op Ubuntu 20.04

Containerisatietechnologie is sterk vooruitgegaan in de technologiesector voor softwareontwikkeling als de meest geaccepteerde methode voor het verpakken en implementeren van applicaties in cloudomgevingen. Dit is noodzakelijk geworden door de behoefte aan continuous integration (CI) en continuous deployment (CD), wat bepalende aspecten zijn van DevOps. Softwareontwikkelaars en engineers maken gebruik van containers om het CI/CD-aspect van softwarearchitectuur te realiseren. Een container is in wezen een volledig verpakt, draagbaar en onafhankelijk computerplatform. Hoewel er verschillende containerplatforms op het web te vinden zijn, is Docker toevallig de meest gebruikte.

Docker is een open-source containerplatform dat ontwikkeling efficiënt en voorspelbaar maakt. Docker biedt een openbare Docker-image-repository die beschikbaar is op Docker Hub. Het bevat veel open-source Docker-images voor de meest voorkomende implementaties die je kunt downloaden en gebruiken. Omdat het een openbare repository is, staat het je ook vrij om je eigen Docker-images toe te voegen om met het publiek te delen. Als je echter private/gepatenteerde code hebt, moet je mogelijk betalen voor een private image-repository of je eigen image-repositoryservice bouwen. Dit is waar GitLab in beeld komt.

GitLab is een webgebaseerde Git repository die meer is dan alleen een tool voor versiebeheer. Het biedt DevOps-tools voor continuous integration en deployment, issue-tracking, Docker-imageregistries en meer. Het biedt drie opties: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) en GitLab SaaS. GitLab CE en GitLab EE zijn zelfbeheerde oplossingen waarmee je de GitLab-instantie zelf kunt downloaden, installeren en beheren. GitLab SaaS wordt gehost door GitLab Inc., en je hoeft je geen zorgen te maken over het installeren van wat dan ook om het te gebruiken.

In een eerdere handleiding hebben we je laten zien hoe je een GitLab-instantie opzet op een CloudSigma-server en je eigen Git-repository host. We hebben je ook laten zien hoe je continuous integration-pipelines met GitLab Runner implementeert om automatisch je tests te bouwen en uit te voeren telkens wanneer er een nieuwe commit is. Als je de genoemde handleidingen nog niet hebt doorgenomen, doe dat dan alsnog, want ze vormen de bouwstenen voor deze handleiding.

In deze handleiding laten we zien hoe je een eenvoudige Docker-image bouwt en host met een zelfgehoste GitLab-instantie (of je nu de Community Edition of de Enterprise Edition gebruikt – de stappen zijn hetzelfde).

Prerequisites

Om elke stap van deze handleiding te kunnen volgen, moet je ervoor zorgen dat je beschikt over een GitLab CI-runner en een zelfgehoste GitLab-server zoals hieronder uitgelegd.

1. Een beveiligde GitLab-server

We zullen dit gebruiken om de broncode op te slaan, CI/CD-taken uit te voeren en de Docker-imageregistry te hosten. Je moet een server hebben met ten minste 2 CPU cores en 4GB aan RAM zoals aanbevolen door GitLab om een zelfbeheerde GitLab-instantie te installeren. Je hebt ook een geregistreerde domeinnaam nodig die naar de server verwijst, omdat we deze zullen gebruiken om een SSL-certificaat van Let’s Encrypt te verkrijgen om de server te beveiligen. Hieronder vind je enkele links die je kunt volgen om een zelfgehoste GitLab-instantie op te zetten.

• Registreer een domeinnaam bij een domeinnaamregistrar naar keuze en verwijs deze naar CloudSigma.
• Volg deze handleiding voor de initiële installatie van de Ubuntu-server, het toevoegen van een niet-rootgebruiker, en het inschakelen van de UFW-firewall van Ubuntu.
• Volg ten slotte deze handleiding om een zelfgehoste GitLab-instantie te installeren en te configureren.

2. Een GitLab CI-runner

Een GitLab CI-runner is nodig om geautomatiseerde taken uit te voeren voor je testcases. De handleiding over hoe je GitLab Continuous Integration-pipelines instelt op Ubuntu 20.04 geeft je een overzicht van de GitLab CI-server en laat zien hoe je taken activeert. Volg de stappen in de handleiding om de GitLab CI-runnerservice in te stellen als je dat nog niet hebt gedaan. De handleiding bevat een Node.js-demo-app met testcases – we zullen deze in deze handleiding gebruiken.

Laten we nu beginnen!

Stap 1: Een geprivilegieerde GitLab CI-runner configureren

In de handleiding over het instellen van een GitLab CI-runner hebben we een GitLab-runner geconfigureerd met behulp van de sudo gitlab-runner register-commando waarmee we interactief de vereiste parameters konden toevoegen. Hoewel dit werkte voor onze vorige use-case, namelijk het uitvoeren van builds en tests in geïsoleerde Docker-containers, is het mogelijk niet geschikt voor het bouwen van Docker-images. Het bouwen van Docker-images vereist dat de runner volledige toegang heeft tot de Docker-service. Je kunt deze configuratie bereiken door gebruik te maken van de officiële docker-in-docker-image om de taken uit te voeren. Een dergelijke configuratie houdt in dat de runner een geprivilegieerde uitvoeringsmodus krijgt.

Hoewel het verlenen van de geprivilegieerde uitvoeringsmodus noodzakelijk is voor het bouwen van Docker-images, brengt dit beveiligingsrisico's met zich mee. Dat komt omdat hierbij de beveiligingsvoordelen van containers teniet worden gedaan. Je denkt misschien dat de andere Docker-runners veilig zijn, maar zij blijken dezelfde problemen te hebben als uitgelegd in de officiële Docker-documentatie.

We zullen nog een runner maken met de geprivilegieerde uitvoeringsmodus. Dit wordt een projectspecifieke runner vanwege de hierboven genoemde beveiligingsrisico's. Deze zal taken accepteren van het Node Pipeline-project dat we hebben gemaakt in de handleiding over hoe je continue CI-pipelines opzet met GitLab.

Het eerste wat je moet doen is controleren of Shared Runners zijn uitgeschakeld voor het project. Klik op de projectpagina van het Node Pipeline-project op Settings in het menu linksonder en selecteer CI/CD in het submenu:

Find the Expand button at the Runners section and click it to reveal details about the available runners:

Klik op de schakelaar om Shared Runners uit te schakelen voor dit project. Als je in de vorige sectie een projectspecifieke runner had toegevoegd, schakel deze dan ook uit. We zullen een geprivilegieerde projectspecifieke runner toevoegen om taken voor dit project uit te voeren. Dit garandeert dat we niet eindigen met build-fouten in het geval dat GitLab willekeurig taken toewijst aan runners die niet zijn geregistreerd met een geprivilegieerde uitvoeringsmodus. In de bovenstaande schermafbeelding, onder het tabblad Specific runners, zou je de registratie token van je project moeten zien. Noteer deze, want je zult deze hieronder gebruiken.

Note: Een projectspecifieke runner kan ook aan andere projecten worden toegewezen vanuit de sectie Admin panel > Runners. Wanneer je een runner selecteert uit de lijst met runners, kom je op de configuratiepagina van de runner. Scrol omlaag om de sectie Restrict projects for this runner:

Het is tijd om je terminal te openen. Als je de stappen in de handleiding over hoe je GitLab Continuous Integration Pipelines opzet op Ubuntu 20.04 nog niet hebt uitgevoerd, neem dan even pauze van deze handleiding en volg die stappen, zodat je een server hebt met de GitLab CI-runnerservice. Zo niet, SSH dan in op de GitLab CI runner server met je sudo-gebruiker voor de volgende stappen.

To set up the privileged project-specific runner, enter the following command on your terminal, replacing your domain name and registration token copied above:

Deze uitvoer toont een succesvolle registratie:

To verify that your GitLab instance picked up the runner, go back to the browser, and refresh the Settings > CI/CD page. Vouw de sectie Runners uit en je zou je runner moeten zien onder Specific Runners:

Optioneel, als je naar het Admin Panel gaat (door op de knop Menu in de bovenste balk te klikken en Admin te selecteren), selecteer dan Runners in de menu-opties:

Je zou op deze pagina moeten uitkomen, die alle beschikbare runners toont die verbonden zijn met je GitLab-instantie, zowel gedeelde als projectspecifieke runners:

Tot zover heb je met succes een runner ingesteld die Docker-images kan bouwen.

Step 2: Configuring GitLab’s Docker Registry

Sommige cruciale workflows vereisen onafhankelijkheid van externe diensten. Dat is waar GitLab's zelfbeheerde Docker Registry om de hoek komt kijken. Het is niet alleen veilig, maar zorgt er ook voor dat u de flexibiliteit hebt om uw taken en pijplijnen aan te passen aan uw behoeften. Om de Docker Registry in te stellen, gaat u het configuratiebestand van GitLab aanpassen. Maak eerst via SSH verbinding met de GitLab-instantie en open vervolgens het bestand met de volgende opdracht:

Scrol omlaag tot u de Container Registry Settings:

Haal de regel met de registry_external_url uit het commentaar en stel deze in op de domeinnaam van uw GitLab-instantie, waarbij u poort 8888 aan het einde opgeeft:

Vervolgens moeten we specificeren waar het register de Let's Encrypt-certificaten kan vinden door de volgende regels toe te voegen. Vergeet niet om dit aan te passen met uw daadwerkelijke GitLab-instantiedomeinnaam:

Sla het bestand op en sluit het wanneer u klaar bent. Voer de volgende opdracht in uw terminal in om GitLab opnieuw te configureren:

Wacht vervolgens een paar seconden tot de uitvoering van de opdracht is voltooid. Als dit is gelukt, zou u de volgende uitvoer moeten zien:

Vervolgens moeten we ervoor zorgen dat de firewall (ufw) verkeer toestaat naar de registerpoort die we hebben toegewezen met behulp van de opdracht:

Vervolgens moet u testen of de Docker Registry actief is door er vanaf een andere machine waarop Docker is geïnstalleerd op in te loggen met de opdracht docker login. Als u Docker nog niet op uw lokale omgeving had ingesteld, kunt u via SSH verbinding maken met de GitLab CI-runner-server, aangezien daar Docker al op is geïnstalleerd. Voer vervolgens de volgende opdracht uit, waarbij u uiteraard uw GitLab-instantiedomeinnaam opgeeft:

Uw uitvoer zal het bericht Login Succeeded tonen, zoals dit:

Dit betekent dat het register succesvol is geconfigureerd en werkt. Wanneer u images maakt, worden deze lokaal opgeslagen in het bestandssysteem van de GitLab-server. Dit is prima voor een priveregister van een bedrijf. Als u echter van plan bent uw register open te stellen voor het publiek, hebt u mogelijk grotere opslagruimte nodig. Gelukkig biedt GitLab opties om verbinding te maken met storage buckets. U kunt meer lezen in de officiële GitLab container registry-documentatie om te zien hoe u een storage bucket voor uw GitLab-instantie kunt configureren.

Stap 3: Wijzig het gitlab-ci.yml-bestand en bouw een Docker-image

Om met deze stap door te gaan, moet u het project Node Pipeline op uw GitLab-instantie hebben. Hier is de weergave van het project op GitLab:

We hebben gesproken over gitlab-ci.yml als het bestand dat de GitLab CI-runner leest wanneer deze wordt geactiveerd om te weten hoe uw applicatie moet worden gebouwd en geautomatiseerde tests moeten worden uitgevoerd. We moeten dit bestand aanpassen om instructies toe te voegen voor het bouwen van Docker-images. U kunt ervoor kiezen om dit bestand rechtstreeks in de GitLab-interface te bewerken. U kunt het ook klonen naar uw lokale machine en bewerken met uw favoriete editor, en vervolgens een commit en git push terug naar GitLab uitvoeren. Kortheidshalve zullen we de GitLab-instantie gebruiken.

Klik op het bestand om het te openen en klik vervolgens op de Bewerken-knop:

Dit opent het bestand, klaar om te worden bewerkt. Verwijder alles uit het bestand en voeg de volgende code toe:

Tijdens het toevoegen van het bovenstaande codefragment, vergeet niet om het gemarkeerde deel bij te werken met je werkelijke gegevens. Wanneer je klaar bent, sla de wijzigingen op door te drukken op de Commit changes-knop. Als je buiten GitLab hebt gewerkt, commit en push dan je wijzigingen.

Laten we begrijpen wat de code die we hebben toegevoegd aan het .gitlab-ci.yml-bestand doet. De eerste regel vertelt GitLab om de officiële Docker-in-Docker-image te gebruiken en koppelt deze aan de docker-in-docker-service (docker:dind). We definiëren vervolgens de fasen voor build, test, en release. De build-fase bouwt de image met behulp van de instructies in de Dockerfile en uploadt deze vervolgens naar de Docker Registry die we in een eerdere stap hebben ingesteld.

Wanneer de build-fase slaagt, downloadt de test-fase de image, voert deze uit als een container en voert het npm test-commando uit om er geautomatiseerde testen in uit te voeren. Als de test-fase slaagt, neemt de release-fase het over. In de release-fase wordt de image gedownload en getagd als node_pipeline:latest. Vervolgens wordt deze teruggezet naar de registry.

Dit is slechts een basisconfiguratie voor een demoproject. Voor je echte projecten zou je andere fasen kunnen hebben, bijvoorbeeld staging, production, etc. Wanneer je het bestand opslaat na het bewerken, wordt er een pipeline geactiveerd. Deze begint dan met het uitvoeren van de taken. Keer terug naar de Node Pipeline-pagina. Je zou moeten zien dat de taak momenteel wordt uitgevoerd:

Klik op het CI-indicatorpictogram om de verschillende fasen van de taak te bekijken:

Zoals je in de bovenstaande schermafbeelding kunt zien, waren alle fasen succesvol volgens de groene vinkjes. Je kunt op elke fase klikken om de taakuitvoer te bekijken:

On the left-hand menu, click on Packages & Registries en selecteer Container Registry:

Dit opent een pagina met de beschikbare Docker-images voor het geselecteerde project. De image die we hebben gebouwd en vrijgegeven, zou in de lijst moeten verschijnen met de tag toegewezen:

Klik om de verschillende tags voor de image te onthullen:

Als je Docker in je lokale omgeving hebt geïnstalleerd, kun je de image pullen en testen of deze naar verwachting werkt. Klik op het Kopiëren-pictogram naast de naam van de image-tag. Hiermee wordt de volledige image-naam naar je klembord gekopieerd die je kunt gebruiken met het docker pull-commando:

De bovenstaande commando's zullen de image pullen en deze in een container uitvoeren:

De app wordt nu aangeboden op poort 8090. Als je je browser opent en navigeert naar your-IP-address:8090 zou je de pagina moeten zien:

Als je een dergelijke pagina in je browser kunt zien, dan heb je met succes een Docker-image gebouwd en gedeeld op een privé Docker Registry. Als je in de toekomst wijzigingen aanbrengt in de master branch, zullen de stages gedefinieerd in het .gitlab-ci.yml bestand worden uitgevoerd, en als ze slagen zal een nieuwe Docker-image met de tag latest opnieuw worden gebouwd en naar de registry worden gepusht.

Conclusie

In dit project heb je geleerd hoe je een privileged GitLab-runner toevoegt aan je zelfbeheerde GitLab-instantie, zodat je Docker-images kunt bouwen. Je hebt ook een privé Docker-image-registry geconfigureerd om je images te hosten. Met behulp van het Node pipeline project kon je elk component van de installatie testen en controleren of ze verbinding maakten en communiceerden zoals verwacht. Zodra je image beschikbaar was in de registry, kon je deze pullen en bevestigen dat deze in een container draaide.

Dit is een inleidende handleiding die je de basis biedt om op voort te bouwen. Volg de officiële GitLab-documentatie om meer te leren over GitLab. Deze link kan informatie bieden over GitLab Container Registry.

Voor meer informatie over het gebruik van Docker kun je andere handleidingen bekijken op onze blog:

• Gegevens delen tussen Docker-containers
• Een privé Docker-registry instellen op Ubuntu 18.04
• Gegevens delen tussen een Docker-container en een host
• Docker-bronnen opschonen – Images, containers en volumes

Veel plezier met computeren!