Ik stel voor om het transcript van het rapport van Alexander Sigachev van Inventos "Ontwikkelings- en testproces met Docker + Gitlab CI" te lezen
Degenen die net beginnen met het implementeren van het ontwikkel- en testproces op basis van Docker + Gitlab CI, stellen vaak basisvragen. Waar te beginnen? Hoe te organiseren? Hoe testen?
Dit rapport is goed omdat het op een gestructureerde manier vertelt over het ontwikkel- en testproces met behulp van Docker en Gitlab CI. Het rapport zelf is uit 2017. Ik denk dat je uit dit rapport de basis, methodologie, idee, gebruikservaring kunt leren.
Wat maakt het uit, alsjeblieft onder de kat.
Mijn naam is Alexander Sigachev. Ik werk voor Inventos. Ik zal je vertellen over mijn ervaring met het gebruik van Docker en hoe we het geleidelijk implementeren in projecten in het bedrijf.
Presentatieonderwerp: Ontwikkelingsproces met behulp van Docker en Gitlab CI.
Dit is mijn tweede lezing over Docker. Ten tijde van het eerste rapport gebruikten we Docker in Development alleen op ontwikkelaarsmachines. Het aantal werknemers dat Docker gebruikte, was ongeveer 2-3 personen. Gaandeweg werd er ervaring opgedaan en schoven we een stukje verder. Link naar onze .
Wat komt er in dit rapport? We zullen onze ervaring delen over welke rake we hebben verzameld, welke problemen we hebben opgelost. Niet overal was het mooi, maar verder mogen.
Ons motto is: leg alles vast wat we te pakken kunnen krijgen.
Welke problemen lossen we op?
Als er meerdere teams in een bedrijf zijn, is de programmeur een gedeelde hulpbron. Er zijn fasen waarin een programmeur uit het ene project wordt gehaald en voor een tijdje aan een ander project wordt gegeven.
Om ervoor te zorgen dat de programmeur het snel begrijpt, moet hij de broncode van het project downloaden en de omgeving zo snel mogelijk starten, zodat hij verder kan gaan met het oplossen van de problemen van dit project.
Als u helemaal opnieuw begint, is er meestal weinig documentatie in het project. Informatie over het instellen is alleen beschikbaar voor oldtimers. Medewerkers richten in één of twee dagen zelfstandig hun werkplek in. Om dit te versnellen, hebben we Docker gebruikt.
De volgende reden is de standaardisatie van instellingen in Ontwikkeling. In mijn ervaring nemen ontwikkelaars altijd het initiatief. In elk vijfde geval wordt een aangepast domein ingevoerd, bijvoorbeeld vasya.dev. Naast hem zit zijn buurman Petya, wiens domein petya.dev is. Ze ontwikkelen een website of een onderdeel van het systeem met behulp van deze domeinnaam.
Wanneer het systeem groeit en deze domeinnamen in configuraties beginnen te komen, ontstaat er een conflict in de ontwikkelomgeving en wordt het sitepad herschreven.
Hetzelfde gebeurt met database-instellingen. Iemand doet geen moeite met beveiliging en werkt met een leeg root-wachtwoord. Tijdens de installatiefase vroeg MySQL iemand om een wachtwoord en het wachtwoord bleek 123 te zijn. Het komt vaak voor dat de databaseconfiguratie voortdurend verandert, afhankelijk van de commit van de ontwikkelaar. Iemand corrigeerde, iemand corrigeerde niet de config. Er waren trucs toen we een soort testconfiguratie eruit haalden .gitignore en elke ontwikkelaar moest de database installeren. Dit maakte het moeilijk om op gang te komen. Het is onder andere noodzakelijk om te onthouden over de database. De database moet worden geïnitialiseerd, er moet een wachtwoord worden ingevoerd, er moet een gebruiker worden geregistreerd, er moet een tabel worden gemaakt, enzovoort.
Een ander probleem zijn de verschillende versies van bibliotheken. Het komt vaak voor dat een ontwikkelaar met verschillende projecten werkt. Er is een Legacy-project dat vijf jaar geleden is gestart (uit 2017 - red. noot). Ten tijde van de lancering zijn we begonnen met MySQL 5.5. Er zijn ook moderne projecten waarbij we modernere versies van MySQL proberen te implementeren, bijvoorbeeld 5.7 of ouder (in 2017 - red. noot)
Iedereen die met MySQL werkt, weet dat deze bibliotheken afhankelijkheden met zich meebrengen. Het is nogal problematisch om 2 honken samen te lopen. Tenminste, oude clients zijn problematisch om verbinding te maken met de nieuwe database. Dit veroorzaakt op zijn beurt verschillende problemen.
Het volgende probleem is dat wanneer een ontwikkelaar op een lokale computer werkt, hij lokale bronnen, lokale bestanden en lokaal RAM gebruikt. Alle interactie bij het ontwikkelen van een oplossing voor problemen wordt uitgevoerd in het kader van het feit dat het op één machine werkt. Een voorbeeld is wanneer we backend-servers hebben in productie 3 en de ontwikkelaar bestanden opslaat in de hoofdmap en van daaruit neemt nginx bestanden om op het verzoek te reageren. Wanneer zo'n code in Productie komt, blijkt het bestand aanwezig te zijn op één van de 3 servers.
De richting van microservices ontwikkelt zich nu. Wanneer we onze grote applicaties opdelen in enkele kleine componenten die met elkaar communiceren. Hiermee kunt u technologieën selecteren voor een specifieke stapel taken. Het stelt je ook in staat om werk en verantwoordelijkheden tussen ontwikkelaars te delen.
Frondend-ontwikkelaar, ontwikkelend op JS, heeft bijna geen invloed op Backend. De backend developer ontwikkelt op zijn beurt, in ons geval, Ruby on Rails en bemoeit zich niet met Frondend. De interactie wordt uitgevoerd met behulp van de API.
Als bonus konden we met de hulp van Docker bronnen recyclen op Staging. Elk project vereiste vanwege zijn specifieke kenmerken bepaalde instellingen. Fysiek was het nodig om ofwel een virtuele server toe te wijzen en deze afzonderlijk te configureren, ofwel een soort variabele omgeving te delen en projecten konden, afhankelijk van de versie van de bibliotheken, elkaar beïnvloeden.
Hulpmiddelen. Wat gebruiken we?
- Docker zelf. De Dockerfile beschrijft de afhankelijkheden van een enkele applicatie.
- Docker-compose is een bundel die enkele van onze Docker-applicaties samenbrengt.
- We gebruiken GitLab om de broncode op te slaan.
- We gebruiken GitLab-CI voor systeemintegratie.
Het rapport bestaat uit twee delen.
Het eerste deel gaat over hoe Docker werd uitgevoerd op de machines van ontwikkelaars.
Het tweede deel gaat over hoe we met GitLab kunnen omgaan, hoe we tests uitvoeren en hoe we uitrollen naar Staging.
Docker is een technologie die het mogelijk maakt (met behulp van een declaratieve benadering) om de benodigde componenten te beschrijven. Dit is een voorbeeld Dockerfile. Hier verklaren we dat we erven van de officiële Ruby:2.3.0 Docker-afbeelding. Het bevat Ruby versie 2.3 geïnstalleerd. We installeren de benodigde buildbibliotheken en NodeJS. We beschrijven dat we een directory maken /app. Stel de app-directory in als de werkdirectory. In deze directory plaatsen we de benodigde minimale Gemfile en Gemfile.lock. Vervolgens bouwen we de projecten die deze afhankelijkheidsafbeelding installeren. We geven aan dat de container klaar zal zijn om te luisteren op externe poort 3000. Het laatste commando is het commando waarmee onze applicatie direct wordt gestart. Als we de projectstartopdracht uitvoeren, zal de applicatie proberen de opgegeven opdracht uit te voeren en uit te voeren.
Dit is een minimaal voorbeeld van een docker-compose-bestand. In dit geval laten we zien dat er een verbinding is tussen twee containers. Dit is rechtstreeks in de databaseservice en de webservice. Onze webapplicaties hebben in de meeste gevallen een soort database nodig als backend voor het opslaan van gegevens. Aangezien we MySQL gebruiken, is het voorbeeld met MySQL - maar niets belet ons om een andere database te gebruiken (PostgreSQL, Redis).
We nemen van de officiële bron van de Docker-hub de afbeelding van MySQL 5.7.14 zonder wijzigingen. We verzamelen de afbeelding die verantwoordelijk is voor onze webapplicatie uit de huidige directory. Het verzamelt een afbeelding voor ons tijdens de eerste lancering. Vervolgens voert het de opdracht uit die we hier uitvoeren. Als we teruggaan, zullen we zien dat het startcommando via Puma is gedefinieerd. Puma is een service geschreven in Ruby. In het tweede geval overschrijven we. Deze opdracht kan willekeurig zijn, afhankelijk van onze behoeften of taken.
We beschrijven ook dat we een poort op onze ontwikkelaar-hostmachine moeten doorsturen van 3000 naar 3000 op de containerpoort. Dit gebeurt automatisch met behulp van iptables en zijn mechanisme, dat rechtstreeks is ingebed in Docker.
De ontwikkelaar heeft ook, zoals voorheen, toegang tot elk beschikbaar IP-adres, bijvoorbeeld 127.0.0.1 is het lokale of externe IP-adres van de machine.
De laatste regel zegt dat de webcontainer afhankelijk is van de db-container. Wanneer we de start van de webcontainer aanroepen, zal docker-compose eerst de database voor ons starten. Reeds bij de start van de database (in feite na de lancering van de container! Dit is geen garantie voor de gereedheid van de database) zal de applicatie, onze backend, opstarten.
Dit voorkomt fouten wanneer de database niet actief is en bespaart resources wanneer we de databasecontainer stoppen, waardoor resources worden vrijgemaakt voor andere projecten.
Wat geeft ons het gebruik van database-dockerisatie op het project. We repareren de versie van MySQL voor alle ontwikkelaars. Dit voorkomt enkele fouten die kunnen optreden wanneer versies uiteenlopen, wanneer de syntaxis, configuratie en standaardinstellingen veranderen. Hiermee kunt u een gemeenschappelijke hostnaam voor de database, login en wachtwoord specificeren. We gaan weg van de dierentuin van namen en conflicten in de configuratiebestanden die we eerder hadden.
We hebben de mogelijkheid om een meer optimale configuratie voor de ontwikkelomgeving te gebruiken, die zal verschillen van de standaard. MySQL is standaard geconfigureerd voor zwakke machines en de prestaties out of the box zijn erg slecht.
Met Docker kunt u de Python-, Ruby-, NodeJS-, PHP-interpreter van de gewenste versie gebruiken. We verlossen de noodzaak om een soort versiebeheerder te gebruiken. Voorheen gebruikte Ruby een rpm-pakket waarmee je de versie afhankelijk van het project kon wijzigen. Het maakt het ook mogelijk, dankzij de Docker-container, om de code soepel te migreren en samen met de afhankelijkheden te versieren. We hebben geen probleem om de versie van zowel de tolk als de code te begrijpen. Om de versie bij te werken, laat u de oude container zakken en brengt u de nieuwe container omhoog. Als er iets mis is gegaan, kunnen we de nieuwe container laten zakken, de oude container omhoog brengen.
Na het bouwen van de afbeelding zijn de containers in zowel ontwikkeling als productie hetzelfde. Dit geldt met name voor grote installaties.
Op Frontend gebruiken we JavaScipt en NodeJS.
Nu hebben we het laatste project op ReacJS. De ontwikkelaar heeft alles in de container uitgevoerd en ontwikkeld met behulp van hot-reload.
Vervolgens wordt de JavaScipt-assembly-taak gestart en wordt de in statics gecompileerde code gegeven via nginx-besparingsbronnen.
Hier heb ik het schema van ons laatste project gegeven.
Welke taken zijn opgelost? We hadden de behoefte om een systeem te bouwen waarmee mobiele apparaten communiceren. Ze ontvangen gegevens. Een mogelijkheid is om pushmeldingen naar dit apparaat te sturen.
Wat hebben we hiervoor gedaan?
We verdeelden in de applicatie componenten zoals: het admin-gedeelte op JS, de backend, die werkt via de REST-interface onder Ruby on Rails. De backend communiceert met de database. Het resultaat dat wordt gegenereerd, wordt aan de klant gegeven. Het beheerderspaneel communiceert met de backend en de database via de REST-interface.
We hadden ook behoefte aan het versturen van pushmeldingen. Daarvoor hadden we een project dat een mechanisme implementeerde dat verantwoordelijk is voor het leveren van meldingen aan mobiele platforms.
We hebben het volgende schema ontwikkeld: een operator van de browser communiceert met het admin-paneel, het admin-paneel communiceert met de backend, de taak is om pushmeldingen te verzenden.
Pushmeldingen werken samen met een ander onderdeel dat is geïmplementeerd in NodeJS.
Wachtrijen worden gebouwd en vervolgens worden meldingen verzonden volgens hun mechanisme.
Hier worden twee databases getekend. Op dit moment gebruiken we met behulp van Docker 2 onafhankelijke databases die op geen enkele manier aan elkaar gerelateerd zijn. Bovendien hebben ze een gemeenschappelijk virtueel netwerk en worden fysieke gegevens opgeslagen in verschillende mappen op de machine van de ontwikkelaar.
Hetzelfde maar dan in cijfers. Dit is waar hergebruik van code belangrijk is.
Hadden we het eerder over hergebruik van code in de vorm van bibliotheken, dan wordt in dit voorbeeld onze service die reageert op pushmeldingen hergebruikt als een complete server. Het biedt een API. En onze nieuwe ontwikkeling heeft er al interactie mee.
Op dat moment gebruikten we versie 4 van NodeJS. Nu (in 2017 - red. noot) gebruiken we in recente ontwikkelingen versie 7 van NodeJS. Er is geen probleem in nieuwe componenten om nieuwe versies van bibliotheken te betrekken.
Indien nodig kunt u de NodeJS-versie refactoren en verhogen vanuit de Push-notificatieservice.
En als we de API-compatibiliteit kunnen behouden, is het mogelijk om deze te vervangen door andere projecten die eerder werden gebruikt.
Wat heb je nodig om Docker toe te voegen? We voegen een Dockerfile toe aan onze repository, die de nodige afhankelijkheden beschrijft. In dit voorbeeld zijn de componenten logisch opgesplitst. Dit is de minimale set van een backend-ontwikkelaar.
Bij het aanmaken van een nieuw project maken we een Dockerfile aan, beschrijven het gewenste ecosysteem (Python, Ruby, NodeJS). In docker-compose beschrijft het de noodzakelijke afhankelijkheid - de database. We beschrijven dat we een database nodig hebben van die en die versie, daar en daar gegevens opslaan.
We gebruiken een aparte derde container met nginx om statisch te dienen. Het is mogelijk om foto's te uploaden. Backend plaatst ze in een vooraf voorbereid volume, dat ook is gemonteerd in een container met nginx, wat de statische geeft.
Om de nginx, mysql-configuratie op te slaan, hebben we een Docker-map toegevoegd waarin we de benodigde configuraties opslaan. Wanneer een ontwikkelaar een git-kloon van een repository op zijn machine doet, heeft hij al een project klaar voor lokale ontwikkeling. Er is geen twijfel over welke poort of welke instellingen moeten worden toegepast.
Vervolgens hebben we verschillende componenten: admin, inform-API, pushmeldingen.
Om dit alles te starten, hebben we een andere repository gemaakt, die we dockerized-app hebben genoemd. Op dit moment gebruiken we verschillende repositories voor elk onderdeel. Ze zijn gewoon logisch anders - in GitLab lijkt het op een map, maar op de machine van de ontwikkelaar is het een map voor een specifiek project. Een niveau lager zijn de componenten die gecombineerd zullen worden.
Dit is een voorbeeld van alleen de inhoud van gedockeriseerde app. We brengen hier ook de Docker-directory, waarin we de configuraties invullen die nodig zijn voor de interacties van alle componenten. Er is een README.md die in het kort beschrijft hoe het project moet worden uitgevoerd.
Hier hebben we twee docker-compose-bestanden toegepast. Dit wordt gedaan om in stappen te kunnen lopen. Wanneer een ontwikkelaar met de kern werkt, heeft hij geen pushmeldingen nodig, hij start gewoon een docker-compose-bestand en dienovereenkomstig wordt de bron opgeslagen.
Als integratie met pushmeldingen nodig is, worden docker-compose.yaml en docker-compose-push.yaml gestart.
Aangezien docker-compose.yaml en docker-compose-push.yaml zich in een map bevinden, wordt er automatisch één virtueel netwerk gemaakt.
Beschrijving van componenten. Dit is een meer geavanceerd bestand dat verantwoordelijk is voor het verzamelen van componenten. Wat is hier opmerkelijk? Hier introduceren we de balancer-component.
Dit is een kant-en-klare Docker-image die nginx draait en een applicatie die luistert op de Docker-socket. Dynamisch, terwijl containers worden in- en uitgeschakeld, regenereert het de nginx-configuratie. We verdelen de afhandeling van componenten door domeinnamen op het derde niveau.
Voor de ontwikkelomgeving gebruiken we het .dev-domein - api.informer.dev. Applicaties met een .dev-domein zijn beschikbaar op de lokale computer van de ontwikkelaar.
Verder worden configuraties naar elk project overgebracht en worden alle projecten tegelijkertijd gelanceerd.
Grafisch blijkt dat de client onze browser is of een tool waarmee we verzoeken doen aan de balancer.
De domeinnaambalancer bepaalt met welke container contact moet worden opgenomen.
Het kan nginx zijn, wat de admin JS geeft. Dit kunnen nginx zijn, die de API geeft, of statische bestanden, die aan nginx worden gegeven in de vorm van uploads van afbeeldingen.
Het diagram laat zien dat de containers zijn verbonden door een virtueel netwerk en verborgen achter een proxy.
Op de machine van de ontwikkelaar heb je toegang tot de container met het IP-adres, maar in principe gebruiken we dit niet. Directe toegang is praktisch niet nodig.
Naar welk voorbeeld moet u kijken om uw toepassing te dockeriseren? Naar mijn mening is een goed voorbeeld de officiële docker-image voor MySQL.
Het is behoorlijk uitdagend. Er zijn vele versies. Maar dankzij de functionaliteit kunt u veel behoeften dekken die zich kunnen voordoen tijdens het verdere ontwikkelingsproces. Als je tijd besteedt en uitzoekt hoe het allemaal op elkaar inwerkt, dan denk ik dat je geen problemen zult hebben met zelfimplementatie.
Hub.docker.com bevat meestal links naar github.com, die direct onbewerkte gegevens bevat waaruit u zelf de afbeelding kunt bouwen.
Verderop in deze repository bevindt zich een docker-endpoint.sh-script, dat verantwoordelijk is voor de initiële initialisatie en voor de verdere verwerking van het starten van de applicatie.
Ook in dit voorbeeld is er de mogelijkheid om te configureren met behulp van omgevingsvariabelen. Door een omgevingsvariabele te definiëren bij het uitvoeren van een enkele container of via docker-compose, kunnen we zeggen dat we een leeg wachtwoord moeten instellen voor docker om te rooten op MySQL of wat we maar willen.
Er is een optie om een willekeurig wachtwoord aan te maken. We zeggen dat we een gebruiker nodig hebben, we moeten een wachtwoord instellen voor de gebruiker en we moeten een database maken.
In onze projecten hebben we de Dockerfile enigszins verenigd, die verantwoordelijk is voor initialisatie. Daar hebben we het aangepast aan onze behoeften om het slechts een uitbreiding te maken van de gebruikersrechten die de applicatie gebruikt. Hierdoor konden we later eenvoudig een database maken vanuit de applicatieconsole. Ruby-applicaties hebben een opdracht voor het maken, wijzigen en verwijderen van databases.
Dit is een voorbeeld van hoe een specifieke versie van MySQL eruitziet op github.com. U kunt de Dockerfile openen en zien hoe de installatie daar verloopt.
docker-endpoint.sh is het script dat verantwoordelijk is voor het ingangspunt. Tijdens de initiële initialisatie zijn enkele voorbereidingsstappen vereist en al deze acties worden alleen in het initialisatiescript uitgevoerd.
Laten we verder gaan met het tweede deel.
Om de broncodes op te slaan, zijn we overgestapt op gitlab. Dit is een vrij krachtig systeem met een visuele interface.
Een van de componenten van Gitlab is Gitlab CI. Hiermee kunt u een reeks opdrachten beschrijven die later zullen worden gebruikt om een codeleveringssysteem te organiseren of automatische tests uit te voeren.
Gitlab CI 2 praten - rapport van Ruby Russia club - vrij gedetailleerd en misschien zal het je interesseren.
Nu gaan we kijken wat er nodig is om Gitlab CI te activeren. Om Gitlab CI te starten, hoeven we alleen maar het .gitlab-ci.yml-bestand in de hoofdmap van het project te plaatsen.
Hier beschrijven we dat we een reeks statussen willen uitvoeren, zoals een test, deploy.
We voeren scripts uit die docker-compose rechtstreeks aanroepen om onze applicatie te bouwen. Dit is slechts een backend-voorbeeld.
Vervolgens zeggen we dat het nodig is om migraties uit te voeren om de database te wijzigen en tests uit te voeren.
Als de scripts correct worden uitgevoerd en geen foutcode retourneren, gaat het systeem door naar de tweede fase van de implementatie.
De implementatiefase wordt momenteel geïmplementeerd voor staging. We hebben geen zero-downtime herstart georganiseerd.
We blussen met geweld alle containers, en dan heffen we alle containers weer op, verzameld in de eerste fase tijdens het testen.
We voeren al voor de huidige omgevingsvariabele de databasemigraties uit die door de ontwikkelaars zijn geschreven.
Er is een opmerking dat dit alleen van toepassing is op de master branch.
Bij het wijzigen van andere takken wordt niet uitgevoerd.
Het is mogelijk om uitrol per vestiging te organiseren.
Om dit verder te organiseren, moeten we Gitlab Runner installeren.
Dit hulpprogramma is geschreven in Golang. Het is een enkel bestand, zoals gebruikelijk is in de Golang-wereld, waarvoor geen afhankelijkheden nodig zijn.
Bij het opstarten registreren we de Gitlab Runner.
We krijgen de sleutel in de Gitlab-webinterface.
Vervolgens noemen we het initialisatiecommando op de commandoregel.
Gitlab Runner interactief opzetten (Shell, Docker, VirtualBox, SSH)
De code op Gitlab Runner wordt bij elke commit uitgevoerd, afhankelijk van de instelling van .gitlab-ci.yml.
Hoe het er visueel uitziet in Gitlab in de webinterface. Nadat we GItlab CI hebben aangesloten, hebben we een vlag die de staat van de build op dit moment weergeeft.
We zien dat er 4 minuten geleden een commit is gemaakt, die alle tests heeft doorstaan en geen problemen heeft veroorzaakt.
We kunnen de bouwwerken nader bekijken. Hier zien we dat er al twee staten zijn gepasseerd. Teststatus en implementatiestatus bij staging.
Als we op een specifieke build klikken, zal er een console-uitvoer zijn van de opdrachten die tijdens het proces zijn uitgevoerd volgens .gitlab-ci.yml.
Zo ziet onze productgeschiedenis eruit. We zien dat er succesvolle pogingen waren. Wanneer tests worden ingediend, gaat het niet door naar de volgende stap en wordt de staging-code niet bijgewerkt.
Welke taken hebben we opgelost tijdens de staging toen we docker implementeerden? Ons systeem bestaat uit componenten en we moesten opnieuw opstarten, slechts een deel van de componenten die in de repository waren bijgewerkt, en niet het hele systeem.
Om dit te doen, moesten we alles in aparte mappen stoppen.
Nadat we dit hadden gedaan, hadden we een probleem met het feit dat Docker-compose voor elke papa zijn eigen netwerkruimte creëert en de componenten van de buren niet ziet.
Om ons te verplaatsen, hebben we het netwerk handmatig in Docker gemaakt. In Docker-compose is geschreven dat je voor dit project zo'n netwerk gebruikt.
Elke component die met deze mesh begint, ziet dus componenten in andere delen van het systeem.
Het volgende probleem is het splitsen van staging over meerdere projecten.
Omdat om dit alles er mooi uit te laten zien en zo dicht mogelijk bij de productie te komen, is het goed om poort 80 of 443 te gebruiken, die overal in het WEB wordt gebruikt.
Hoe hebben we het opgelost? Voor alle grote projecten hebben we één Gitlab Runner toegewezen.
Gitlab stelt je in staat om verschillende gedistribueerde Gitlab Runners uit te voeren, die eenvoudigweg alle taken achtereenvolgens op een chaotische manier overnemen en uitvoeren.
Zodat we geen huis hebben, hebben we de groep van onze projecten beperkt tot één Gitlab Runner, die zonder problemen met onze volumes omgaat.
We hebben nginx-proxy naar een apart opstartscript verplaatst en daarin rasters voor alle projecten toegevoegd.
Ons project heeft één raster en de balancer heeft verschillende rasters met projectnamen. Het kan verder proxy door domeinnamen.
Onze verzoeken komen via het domein op poort 80 binnen en worden omgezet in een containergroep die dit domein bedient.
Welke andere problemen waren er? Dit is wat alle containers standaard als root uitvoeren. Dit is root ongelijk aan de roothost van het systeem.
Als u echter de container invoert, wordt deze root en krijgt het bestand dat we in deze container maken rootrechten.
Als de ontwikkelaar de container is binnengegaan en daar enkele opdrachten heeft gemaakt die bestanden genereren, en vervolgens de container heeft verlaten, heeft hij een bestand in zijn werkmap waartoe hij geen toegang heeft.
Hoe kan het worden opgelost? U kunt gebruikers toevoegen die zich in de container bevinden.
Welke problemen deden zich voor toen we de gebruiker toevoegden?
Bij het aanmaken van een gebruiker hebben we vaak niet dezelfde groeps-ID (UID) en gebruikers-ID (GID).
Om dit probleem in de container op te lossen, gebruiken we gebruikers met ID 1000.
In ons geval viel dit samen met het feit dat bijna alle ontwikkelaars het Ubuntu-besturingssysteem gebruiken. En op Ubuntu heeft de eerste gebruiker een ID van 1000.
Hebben we plannen?
Lees de Docker-documentatie. Het project ontwikkelt zich actief, de documentatie verandert. De gegevens die twee of drie maanden geleden binnenkwamen, raken nu al langzaam achterhaald.
Sommige van de problemen die we hebben opgelost, zijn mogelijk al opgelost met standaardmiddelen.
Dus ik wil al verder gaan om direct naar de orkestratie te gaan.
Een voorbeeld is het ingebouwde mechanisme van Docker, genaamd Docker Swarm, dat uit de doos komt. Ik wil iets in productie laten gaan op basis van Docker Swarm-technologie.
Het uitzetten van containers maakt het lastig om met logs te werken. Nu zijn de logboeken geïsoleerd. Ze liggen verspreid over containers. Een van de taken is om gemakkelijk toegang te krijgen tot de logs via de webinterface.
Bron: www.habr.com