Ik bied u de mogelijkheid om de presentatie van Alexander Sigachev van Inventos "Het ontwikkelings- en testproces met Docker + Gitlab CI" te bekijken.
Degenen die net beginnen met het implementeren van het ontwikkelings- en testproces met Docker + Gitlab CI, stellen vaak basisvragen. Waar te beginnen? Hoe te organiseren? Hoe te testen?
Deze presentatie is goed omdat hij gestructureerd vertelt over het ontwikkelings- en testproces met Docker en Gitlab CI. De presentatie is uit 2017. Ik denk dat je uit deze presentatie de basis, de methodologie, het idee en de ervaring met gebruik kunt halen.
Wie geĆÆnteresseerd is, kan verder lezen.
Mijn naam is Alexander Sigachev. Ik werk bij het bedrijf Inventos. Ik zal vertellen over mijn ervaringen met Docker en hoe we het geleidelijk aan implementeren in projecten binnen ons bedrijf.
Onderwerp van de presentatie: Het ontwikkelingsproces met Docker en Gitlab CI.
Dit is mijn tweede presentatie over Docker. Op het moment van de eerste presentatie gebruikten we Docker alleen in de ontwikkeling op de machines van ontwikkelaars. Het aantal medewerkers dat Docker gebruikte was ongeveer 2-3 mensen. Geleidelijk aan is er ervaring opgebouwd en zijn we iets verder gekomen. Link naar onze .
Wat zal er in deze presentatie zijn? We zullen onze ervaringen delen over welke problemen we tegenkwamen en hoe we deze hebben opgelost. Het was niet overal mooi, maar het stelde ons in staat om verder te komen.
Onze slogan: dockerize alles wat binnen ons bereik komt.
Welke problemen lossen we op?
Wanneer er meerdere teams in het bedrijf zijn, is een programmeur een gedeelde hulpbron. Er zijn momenten waarop een programmeur uit het ene project wordt gehaald en voor een bepaalde tijd aan een ander project wordt toegewezen.
Om ervoor te zorgen dat de programmeur snel in het project kan duiken, moet hij de broncode van het project downloaden en de omgeving zo snel mogelijk opzetten, zodat hij verder kan werken aan de taken van dat project.
Gewoonlijk, als je vanaf nul begint, is er weinig documentatie in het project. Informatie over hoe in te stellen is alleen beschikbaar bij de oude rot. Medewerkers stellen zelfstandig hun werkplek in Ć©Ć©n of twee dagen in. Om dit te versnellen, hebben we Docker toegepast.
Een volgende reden is de standaardisatie van instellingen in de ontwikkeling. Uit mijn ervaring blijkt dat ontwikkelaars altijd initiatief tonen. In elk vijfde geval wordt er een aangepaste domeinnaam geĆÆntroduceerd, bijvoorbeeld vasya.dev. De buurman Petya, heeft het domein petya.dev. Zij ontwikkelen een website of een component van het systeem met deze domeinnaam.
Wanneer het systeem groeit en deze domeinnamen in de configuraties terechtkomen, ontstaat er een conflict tussen ontwikkelomgevingen en wordt het pad van de site overschreven.
Hetzelfde gebeurt met de database-instellingen. Iemand maakt zich geen zorgen over de veiligheid en werkt met een leeg rootwachtwoord. Bij de installatie vroeg MySQL om een wachtwoord en bleek het wachtwoord '123' te zijn. Vaak gebeurt het dat de databaseconfiguratie constant veranderde, afhankelijk van de commits van de ontwikkelaar. De Ć©Ć©n heeft de configuratie aangepast, de ander niet. Er waren middelen waarbij we een testconfiguratie naar buiten brachten in .gitignore en elke ontwikkelaar zijn eigen database moest instellen. Dit bemoeilijkte het opstartproces. Naast al het andere moet je ook aan de database denken. De database moet worden geĆÆnitialiseerd, je moet een wachtwoord opgeven, een gebruiker opgeven, een tabel creĆ«ren, enzovoort.
Een ander probleem is de verschillende versies van bibliotheken. Vaak werkt een ontwikkelaar met verschillende projecten. Er is een Legacy-project dat vijf jaar geleden is begonnen (vanaf 2017 ā redactieopmerking). Bij de start begonnen ze met MySQL 5.5. Er zijn ook moderne projecten waarin we proberen modernere versies van MySQL te implementeren, zoals 5.7 of hoger (in 2017 ā redactieopmerking).
Iedereen die met MySQL werkt, weet dat deze bibliotheken afhankelijkheden met zich meebrengen. Het is behoorlijk problematisch om 2 databases samen te laten draaien. Tenminste, het is problematisch om oude clients aan een nieuwe database te koppelen. Dit leidt op zijn beurt weer tot verschillende problemen.
Het volgende probleem is wanneer een ontwikkelaar op een lokale machine werkt; hij gebruikt lokale bronnen, lokale bestanden, lokaal RAM. Alle interactie tijdens de ontwikkeling van de oplossing vindt plaats binnen het kader dat het werkt op Ć©Ć©n machine. Een voorbeeld is dat we in productie 3 backend-servers hebben, terwijl de ontwikkelaar bestanden in de rootdirectory opslaat en van daaruit nginx de bestanden voor de verzoeken haalt. Wanneer dergelijke code in productie komt, blijkt dat het bestand slechts op een van de 3 servers aanwezig is.
Momenteel is er een opkomende richting in microservices. Wanneer we onze grote applicaties onderverdelen in kleinere componenten die met elkaar communiceren. Dit stelt ons in staat om technologieƫn te kiezen die passen bij de specifieke taakstack. Het maakt ook het delen van werk en verantwoordelijkheidszones tussen ontwikkelaars mogelijk.
Een frontend-ontwikkelaar, die met JS werkt, heeft nauwelijks invloed op de backend. De backend-ontwikkelaar ontwikkelt, in ons geval, Ruby on Rails en bemoeit zich niet met de frontend. De interactie gebeurt via API.
Als bonus hebben we met Docker onze middelen op Staging weten te optimaliseren. Elk project vereiste bepaalde instellingen vanwege zijn specifieke kenmerken. Fysiek moesten we ofwel een virtuele server toewijzen en deze afzonderlijk configureren, ofwel een variabele omgeving delen, waardoor projecten elkaar konden beĆÆnvloeden, afhankelijk van de versie van de bibliotheken.
Tools. Wat gebruiken we?
- Direct Docker zelf. In de Dockerfile worden de afhankelijkheden van Ć©Ć©n applicatie beschreven.
- Docker-compose is de koppeling die onze verschillende Docker-applicaties verenigt.
- We gebruiken GitLab voor het opslaan van de broncode.
- We gebruiken GitLab-CI voor systemintegration.
De presentatie bestaat uit twee delen.
Het eerste deel vertelt hoe we Docker op de machines van ontwikkelaars hebben uitgevoerd.
Het tweede deel vertelt hoe te interageren met GitLab, hoe we tests uitvoeren en hoe we op Staging uitrollen.
Docker is een technologie die het mogelijk maakt (met een declaratieve aanpak) de benodigde componenten te beschrijven. Dit is een voorbeeld van een Dockerfile. Hier verklaren we dat we afstammen van de officiĆ«le Docker-image Ruby:2.3.0. Deze bevat de geĆÆnstalleerde Ruby-versie 2.3. We installeren de noodzakelijke bouwbibliotheken en NodeJS. We beschrijven dat we een map aanmaken. /appWe wijzen de map app aan als de werkdirectory. In deze map plaatsen we het noodzakelijke minimale Gemfile en Gemfile.lock. Vervolgens bouwen we projecten die deze afbeelding van afhankelijkheden installeren. We geven aan dat de container klaar is om te luisteren op de externe poort 3000. De laatste opdracht is de opdracht die onze applicatie daadwerkelijk start. Als we de startopdracht van het project uitvoeren, probeert de applicatie te draaien en voert de opgegeven opdracht uit.
Dit is een minimaal voorbeeld van een docker-compose bestand. In dit geval laten we zien hoe twee containers met elkaar verbonden zijn. Dit betreft direct de database service en de web service. Onze webapplicaties vereisen in de meeste gevallen een backend om gegevens op te slaan in een database. Aangezien we MySQL gebruiken, is dit voorbeeld met MySQL ā maar er staat niets in de weg om een andere database te gebruiken (PostgreSQL, Redis).
We nemen het MySQL 5.7.14 beeld zonder wijzigingen van de officiĆ«le bron op Docker Hub. Het beeld dat verantwoordelijk is voor onze webapplicatie bouwen we vanuit de huidige directory. Tijdens de eerste uitvoering bouwt het voor ons een beeld. Vervolgens voert het de opdracht uit die we hier uitvoeren. Als we terugkijken, zien we dat een opstartcommando is gedefinieerd via Puma. Puma ā een service geschreven in Ruby. In het tweede geval overschrijven we dit. Deze opdracht kan willekeurig zijn afhankelijk van onze behoeften of taken.
Ook beschrijven we dat we de poort van onze ontwikkelaars host-machine van 3000 naar de 3000 poort van de container moeten doorsturen. Dit gebeurt automatisch met behulp van iptables en het mechanisme dat direct in Docker is ingebouwd.
De ontwikkelaar kan, net als eerder, een beetje elke beschikbare IP-adres aanspreken, bijvoorbeeld 127.0.0.1 lokaal of het externe IP-adres van de machine.
De laatste regel geeft aan dat de web container afhankelijk is van de db container. Wanneer we de web container starten, zal docker-compose vooraf de database voor ons starten. Pas na de opstart van de database (eigenlijk ā na de opstart van de container! De gereedheid van de DB is niet gegarandeerd) zal de applicatie, onze backend, worden gestart.
Dit helpt om fouten te voorkomen, wanneer de database niet is opgestart en bespaart middelen wanneer we de database container stoppen, zodat deze middelen beschikbaar komen voor andere projecten.
Wat het gebruik van dockerisatie van de database in het project ons biedt. We stellen voor alle ontwikkelaars de versie van MySQL vast. Dit helpt om enkele fouten te voorkomen die kunnen optreden bij afwijkingen in versies, wanneer de syntaxis, configuratie of standaardinstellingen veranderen. Dit maakt het mogelijk om gemeenschappelijke hostnamen voor de database, login, en wachtwoord aan te geven. We gaan af van de chaos van namen en conflicten in de config-bestanden die eerder bestonden.
We hebben de mogelijkheid om een meer geoptimaliseerde configuratie voor de ontwikkelomgeving te gebruiken, die zal verschillen van de standaardconfiguratie. MySQL is standaard ingesteld voor zwakkere machines en de prestaties zijn uit de doos erg laag.
Docker maakt het mogelijk om de gewenste versie van de Python, Ruby, NodeJS en PHP-interpreters te gebruiken. We ontslaan ons van de noodzaak om een versiebeheerder te gebruiken. Eerder gebruikten we een rpm-pakket voor Ruby, waarmee we de versie afhankelijk van het project konden wijzigen. Ook maakt dit het mogelijk om met behulp van de Docker-container de code soepel te migreren en deze samen met de afhankelijkheden te versioneren. We hebben geen problemen om de versie van zowel de interpreter als de code te begrijpen. Voor het updaten van de versie moeten we de oude container stoppen en de nieuwe container starten. Als er iets misgaat, kunnen we de nieuwe container stoppen en de oude container opnieuw starten.
Na het samenstellen van de afbeelding zullen de containers zowel in de ontwikkel- als in de productieomgeving identiek zijn. Dit is bijzonder relevant voor grote installaties.
Aan de frontend gebruiken we JavaScript en NodeJS.
Momenteel is ons laatste project op ReactJS. De ontwikkelaar startte alle containers en ontwikkelde met behulp van hot-reload.
Vervolgens wordt de taak voor het samenstellen van JavaScript gestart en wordt de statische code via nginx geleverd, wat middelen bespaart.
Hier heb ik het diagram van ons laatste project weergegeven.
Welke taken zijn opgelost? We moesten een systeem opbouwen waarmee mobiele apparaten kunnen communiceren. Zij ontvangen gegevens. Een van de mogelijkheden is om pushmeldingen naar dit apparaat te sturen.
Wat hebben we hiervoor gedaan?
We hebben de applicatie opgedeeld in de volgende componenten: een admin-gedeelte op JS, backend dat via een REST API onder Ruby on Rails werkt. De backend communiceert met de database. Het resultaat dat wordt gegenereerd, wordt aan de client geleverd. De admin interface communiceert met de backend en de database via de REST API.
Ook hadden we de noodzaak om pushmeldingen te verzenden. Voorheen hadden we een project waarin een mechanisme werd gerealiseerd dat verantwoordelijk was voor de aflevering van meldingen op mobiele platformen.
We hebben het volgende schema ontwikkeld: de operator vanuit de browser communiceert met de admin interface, de admin interface communiceert met de backend en er wordt een taak ingesteld om pushmeldingen te verzenden.
Pushmeldingen communiceren met een andere component die is gerealiseerd op NodeJS.
Er worden wachtrijen opgebouwd en de notificaties worden verder verzonden volgens hun eigen mechanisme.
Hier zijn twee databases weergegeven. Momenteel gebruiken we met Docker 2 onafhankelijke databases die niet met elkaar verbonden zijn. Behalve dat ze een gezamenlijk virtueel netwerk hebben, worden de fysieke gegevens in verschillende mappen op de machine van de ontwikkelaar opgeslagen.
Hetzelfde, maar in cijfers. Hier is hergebruik van code belangrijk.
Als we eerder spraken over het hergebruik van code in de vorm van bibliotheken, dan wordt in dit voorbeeld onze service die Push-notificaties afgeeft, hergebruikt als een volledige server. Het biedt een API, waarmee onze nieuwe ontwikkeling communiceert.
Op dat moment gebruikten we versie 4 van NodeJS. Nu (in 2017 - red. opmerking) gebruiken we in nieuwe ontwikkelingen versie 7 van NodeJS. Er zijn geen problemen om nieuwe versies van bibliotheken aan te trekken in nieuwe componenten.
Indien nodig kan er een herstructurering plaatsvinden en kan de versie van NodeJS bij de Push-notificatieservice worden verhoogd.
Als we de compatibiliteit van de API kunnen behouden, kan deze worden vervangen in andere projecten die eerder zijn gebruikt.
Wat is er nodig om Docker toe te voegen? We voegen een Dockerfile toe aan onze repository die de benodigde afhankelijkheden beschrijft. In dit voorbeeld zijn de componenten logisch verdeeld. Dit is de minimale set voor een backend-ontwikkelaar.
Bij het maken van een nieuw project creƫren we een Dockerfile en beschrijven we het benodigde ecosysteem (Python, Ruby, NodeJS). In de docker-compose beschrijven we de benodigde afhankelijkheid - de database. We geven aan welke database van welke versie nodig is en waar de gegevens moeten worden opgeslagen.
We gebruiken een aparte derde container met nginx voor het leveren van statische bestanden. Er is een mogelijkheid voor het uploaden van afbeeldingen. De backend plaatst deze in een voorbereid volume dat ook is gemonteerd in de container met nginx, die de statische bestanden levert.
Om de configuratie van nginx en MySQL op te slaan, hebben we een map Docker toegevoegd waarin we de benodigde configuraties opslaan. Wanneer een ontwikkelaar de git repository op zijn machine clone, heeft hij al een project klaar voor lokale ontwikkeling. Er rijst geen vraag over welke poort of welke instellingen moeten worden toegepast.
Daarna hebben we verschillende componenten: admin, info-API, push-notificaties.
Om alles te starten, hebben we een andere repository aangemaakt genaamd dockerized-app. Op dit moment gebruiken we meerdere repositories voor elk component. Ze verschillen gewoon logisch ā in GitLab verschijnt het als een map, terwijl op de machine van de ontwikkelaar het een map voor een specifiek project is. Op een lager niveau liggen de componenten die samengevoegd zullen worden.
Dit is een voorbeeld van de inhoud van dockerized-app. We verplaatsen ook hier de Docker-map, waarin we de configuraties plaatsen die nodig zijn voor de interactie tussen alle componenten. Er is een README.md waarin kort wordt beschreven hoe het project gestart kan worden.
Hier hebben we twee docker-compose-bestanden toegepast. Dit is gedaan om de mogelijkheid te hebben om gefaseerd te starten. Wanneer een ontwikkelaar met de kern werkt en geen Push-meldingen nodig heeft, start hij eenvoudig het docker-compose-bestand en bespaart zo middelen.
Als er behoefte is aan integratie met Push-meldingen, wordt docker-compose.yaml en docker-compose-push.yaml gestart.
Aangezien docker-compose.yaml en docker-compose-push.yaml in dezelfde map staan, wordt er automatisch een enkele virtuele netwerk aangemaakt.
Beschrijving van de componenten. Dit is een uitgebreid bestand dat verantwoordelijk is voor de samenstelling van de componenten. Wat hier opvalt? Hier introduceren we het component load balancer.
Dit is een kant-en-klaar Docker-image waarin nginx en een applicatie draaien die naar de Docker-socket luistert. Het genereert dynamisch, naarmate containers worden in- en uitgeschakeld, de configuratie van nginx opnieuw. De interactie met de componenten wordt verdeeld over derde-niveau domeinnamen.
Voor de ontwikkelomgeving gebruiken we het domein .dev ā api.informer.dev. Applicaties met het domein .dev zijn beschikbaar op de lokale machine van de ontwikkelaar.
Vervolgens worden de configuraties doorgestuurd naar elk project en worden alle projecten samen tegelijkertijd gestart.
Grafisch weergegeven is de klant onze browser of een ander hulpmiddel waarmee we verzoeken naar de load balancer sturen.
De load balancer bepaalt op basis van de domeinnaam naar welke container moet worden verwezen.
Dit kan nginx zijn, dat de JS-adminpanel levert. Dit kan nginx zijn, dat de API geeft, of statische bestanden, die door nginx worden geleverd als het om het uploaden van afbeeldingen gaat.
In het schema is te zien dat de containers zijn samengevoegd in een virtueel netwerk en achter een proxy zijn verborgen.
Op de ontwikkelingsmachine kan men het container aanspreken door de IP te kennen, maar we passen dit in principe niet toe. Directe toegang is in de meeste gevallen niet nodig.
Welk voorbeeld kunnen we bekijken om onze applicatie te dockeriseren? Naar mijn mening is de officiƫle Docker-image voor MySQL een goed voorbeeld.
Het is behoorlijk complex. Er zijn veel versies. Maar de functionaliteit is in staat om veel behoeften te dekken die zich kunnen voordoen tijdens verdere ontwikkeling. Als je de tijd neemt om te begrijpen hoe alles samenwerkt, denk ik niet dat je problemen zult ondervinden bij het zelfstandig implementeren.
Op hub.docker.com staan meestal links naar github.com, waar de ruwe gegevens worden verstrekt waarvan je zelf een image kunt samenstellen.
Verder bevat deze repository het script docker-endpoint.sh, dat verantwoordelijk is voor de initiƫle initialisatie en voor de verdere verwerking van de applicatiestart.
Ook in dit voorbeeld is er de mogelijkheid tot configuratie via omgevingsvariabelen. Door omgevingsvariabelen te definiƫren bij het starten van een enkele container of via docker-compose, kunnen we aangeven dat we een leeg wachtwoord voor Docker voor de root in MySQL willen instellen, of een wachtwoord naar keuze.
Er is een optie om een random wachtwoord te genereren. We geven aan dat we een gebruiker nodig hebben, dat we een wachtwoord voor deze gebruiker moeten instellen en dat we een database moeten aanmaken.
In onze projecten hebben we de Dockerfile enigszins gestandaardiseerd, die verantwoordelijk is voor de initiatie. We hebben deze aangepast voor onze behoeften om eenvoudig de gebruikersrechten uit te breiden die de applicatie gebruikt. Dit maakte het later mogelijk om simpelweg een database vanuit de console van de applicatie te creƫren. In Ruby-applicaties zijn er commando's voor het maken, wijzigen en verwijderen van databases.
Dit is een voorbeeld van hoe een specifieke versie van MySQL eruitziet op github.com. De Dockerfile kan worden geopend om te bekijken hoe de installatie plaatsvindt.
docker-endpoint.sh is het script dat verantwoordelijk is voor het ingangspunt. Tijdens de initiƫle initiatie zijn er enkele voorbereidingshandelingen nodig, en al deze handelingen zijn als het ware in het initialisatiescript ondergebracht.
Laten we doorgaan naar het tweede deel.
Voor het opslaan van de broncodes zijn we overgestapt op GitLab. Dit is een krachtig systeem dat een visuele interface heeft.
Een van de componenten van Gitlab is Gitlab CI. Dit stelt ons in staat om een reeks opdrachten te beschrijven die vervolgens gebruikt zullen worden om een systeem voor codelevering of automatische testuitvoering te organiseren.
Presentatie over Gitlab CI 2 ā presentatie van de Ruby Russia club ā vrij gedetailleerd en wellicht interessant voor u.
Laten we nu bekijken wat nodig is om Gitlab CI te activeren. Om Gitlab CI te starten, hoeven we alleen maar een bestand .gitlab-ci.yml in de hoofdmap van het project te plaatsen.
Hier beschrijven we wat we willen uitvoeren in een reeks staten zoals testen of deployen.
We voeren scripts uit die de docker-compose build van onze applicatie direct aanroepen. Dit is een voorbeeld van backend.
Vervolgens geven we aan dat we migraties voor de databasewijzigingen moeten uitvoeren en de tests moeten uitvoeren.
Als de scripts correct worden uitgevoerd en geen foutcode retourneren, gaat het systeem door naar de tweede fase van de deployment.
De huidige fase van deployment is geĆÆmplementeerd voor staging. We hebben geen foutloze herstart georganiseerd.
We stoppen alle containers gedwongen en starten vervolgens alle containers opnieuw op, opgebouwd in de eerste fase tijdens de tests.
We voeren migraties uit voor de huidige variabele omgeving, die door de ontwikkelaars zijn geschreven.
Er is een opmerking dat dit alleen voor de master branch moet worden toegepast.
Bij wijzigingen in andere branches wordt dit niet uitgevoerd.
Er is een mogelijkheid om releases per branch te organiseren.
Om dit verder te organiseren, moeten we Gitlab Runner installeren.
Deze tool is geschreven in Golang. Het is een enkel bestand zoals gebruikelijk in de wereld van Golang, zonder dat er afhankelijkheden nodig zijn.
Bij de start registreren we Gitlab Runner.
We verkrijgen een sleutel in de webinterface van Gitlab.
Daarna roepen we het initialisatiecommando aan in de opdrachtregel.
We configureren Gitlab Runner in dialoogmodus (Shell, Docker, VirtualBox, SSH)
De code op Gitlab Runner wordt bij elke commit uitgevoerd, afhankelijk van de configuratie in .gitlab-ci.yml.
Hoe dit er visueel uitziet in Gitlab in de webinterface. Nadat we Gitlab CI hebben aangesloten, verschijnt er een vlag die aangeeft in welke toestand de build zich momenteel bevindt.
We zien dat er 4 minuten geleden een commit is gemaakt die alle tests heeft doorstaan en geen problemen heeft veroorzaakt.
We kunnen dieper ingaan op de builds. Hier zien we dat er al twee toestanden zijn geweest. De testfase en de deployfase op staging.
Als we op een specifieke build klikken, zien we de console-uitvoer van de commando's die zijn uitgevoerd tijdens het proces volgens .gitlab-ci.yml.
Zo ziet de geschiedenis van ons product eruit. We zien dat er succesvolle pogingen zijn geweest. Wanneer tests falen, gaat het niet door naar de volgende stap en wordt de code op staging niet bijgewerkt.
Welke problemen hebben we opgelost op staging toen we docker implementeerden? Ons systeem bestaat uit componenten en we hadden de noodzaak om alleen de onderdelen die waren bijgewerkt in de repository opnieuw op te starten, niet het hele systeem.
Daarom moesten we alles in aparte mappen scheiden.
Nadat we dit hadden gedaan, hadden we een probleem omdat Docker-compose voor elke map zijn eigen netwerkruimte creƫert en de componenten van de buren niet ziet.
Om dit te omzeilen, hebben we handmatig een netwerk in Docker aangemaakt. In Docker-compose hebben we aangegeven dat deze netwerkruimte voor dit project gebruikt moet worden.
Op deze manier ziet elke component die met dit netwerk opstart, de componenten in de andere delen van het systeem.
Het volgende probleem is de splitsing van staging tussen meerdere projecten.
Om alles er netjes en zo dicht mogelijk bij productie uit te laten zien, is het goed om poort 80 of 443 te gebruiken, die algemeen in het WEB wordt gebruikt.
Hoe hebben we dit opgelost? We hebben Ć©Ć©n GitLab Runner toegewezen aan alle grote projecten.
GitLab stelt ons in staat om meerdere gedistribueerde GitLab Runners te starten, die gewoon om de beurt alle taken in een chaotische volgorde kunnen ophalen en uitvoeren.
Om zoveel mogelijk chaos te voorkomen, hebben we de groep van onze projecten beperkt tot Ć©Ć©n GitLab Runner, die met onze workloads geen problemen ondervindt.
We hebben de nginx-proxy naar een apart startup-script verplaatst en daarin de netwerken van alle projecten gedefinieerd.
Ons project heeft ƩƩn netwerk, terwijl de load balancer meerdere netwerken heeft die gebaseerd zijn op projectnamen. Hij kan verder proxieƫn op basis van domeinnamen.
Onze verzoeken komen binnen op het domein op poort 80 en worden geleid naar een groep containers die dit domein bedient.
Welke andere problemen waren er? Dit is dat standaard alle containers draaien onder de gebruiker root. Dit root is niet gelijk aan de root van het hostsysteem.
Maar als je in de container inlogt, dan ben je root en het bestand dat we in deze container aanmaken, krijgt root-rechten.
Als de ontwikkelaar in de container is ingelogd en daar enkele commando's heeft uitgevoerd die bestanden genereren, en vervolgens de container verlaat, heeft hij in zijn werkdirectory een bestand waar hij geen toegang toe heeft.
Hoe kunnen we dit oplossen? We kunnen gebruikers toevoegen die in de container aanwezig zijn.
Welke problemen deden zich voor toen we een gebruiker toevoegden?
Bij het aanmaken van een gebruiker komen onze gebruikers-ID (UID) en groeps-ID (GID) vaak niet overeen.
Om dit probleem op te lossen, gebruiken we in de container gebruikers met ID 1000.
In ons geval kwam dit overeen met het feit dat bijna alle ontwikkelaars het besturingssysteem Ubuntu gebruiken. Op Ubuntu heeft de eerste gebruiker ID 1000.
Wat zijn onze plannen?
De documentatie over Docker opnieuw doornemen. Het project ontwikkelt zich actief, de documentatie verandert. Gegevens die twee tot drie maanden geleden zijn verkregen, verouderen langzaam.
Een deel van de problemen die we oplosten, zijn mogelijk al opgelost met standaardmiddelen.
We willen zo graag verdergaan en direct overgaan op orchestratie.
Een van de voorbeelden is de ingebouwde Docker-functionaliteit genaamd Docker Swarm, die standaard is. We willen iets productiefs op basis van Docker Swarm-technologie draaien.
Het genereren van containers maakt het werken met logs ongemakkelijk. Momenteel zijn de logs geĆÆsoleerd. Ze zijn verspreid over containers. Een van de taken is om gemakkelijke toegang tot de logs te creĆ«ren via een webinterface.
Bron: habr.com
