‫In deze sectie hebben we veel over Swarm behandeld. Swarm, Stacks en Secrets zijn een soort trilogie van
‫geweldige functies die de productie voor ons echt veel gemakkelijker kunnen maken.
‫Ik wil je laten zien hoe het zou zijn als je je Compose-bestanden daadwerkelijk zou nemen, ze op een
‫aantal manieren zou ordenen, en
‫dit is wat ik eigenlijk de droom noem.
‫Het blijkt dat je eigenlijk een enkel bestand kunt gebruiken om veel dingen te doen, maar soms
‫wordt je complexiteit groter en heb je meerdere Compose-bestanden nodig.
‫Ik wil er gewoon heel snel doorheen rennen.
‫U hoeft dit eigenlijk niet zelf te doen als u dat niet wilt. Ik ga u alleen een voorbeeld laten
‫zien van hoe deze Compose-bestanden kunnen samenwerken om uw omgeving op te bouwen terwijl u bezig bent.
‫In dit scenario gaan we docker componeren gebruiken voor onze lokale ontwikkelomgeving.
‫We gaan een configuratie en bestand voor het samenstellen van een docker gebruiken voor onze CI-omgeving om integratietests uit te voeren.
‫Als we dan in productie zijn, gaan we die bestanden gebruiken voor docker-stack-implementatie om
‫de productieomgeving daadwerkelijk met een stack te implementeren. Dus ik zit op mijn lokale computer en we gaan
‫het eerdere voorbeeld van het Drupal-scenario gebruiken, met een databaseserver en een webfrontend.
‫We hebben de Dockerfile die we in onze vorige opdrachten hebben gebruikt. We bouwen een aangepaste, maar eenvoudige, drupal-configuratie
‫opnieuw op met een sjabloon.
‫Dan hebben we dit standaard samengestelde bestand.
‫Dit heet
‫een override, wat we gaan doen. Een overschrijving is waar ik het standaard Docker Compose-bestand heb
‫en het stelt de standaardwaarden in die in al mijn omgevingen hetzelfde zijn.
‫Dan heb ik dit override-bestand dat standaard Docker Compose is, als het deze exacte naam
‫heeft, docker compose. overschrijven. yml, het zal dit automatisch binnenbrengen wanneer ik een docker opstel.
‫Je zult zien dat we in dit scenario uitgaan van lokale ontwikkeling omdat we echt willen dat de handgetypte
‫commando's die we gaan typen, lokaal het gemakkelijkst zijn.
‫Normaal gesproken is het in uw CI-omgeving allemaal geautomatiseerd, dus het maakt ons niet echt uit of die
‫opdrachten wat langer zijn.
‫Maar we willen echt lokaal de makkelijke docker samenstellen.
‫Het leuke is dat Docker Compose dit bestand automatisch zal lezen
‫en dit zal toepassen op, of overschrijven, alle instellingen in het Docker Compose yml-bestand.
‫En dus hier, merk
‫op dat ik de naam van de afbeelding niet heb, want die is hier al gespecificeerd. In dit override-bestand overschrijf ik door te
‫zeggen dat ik de afbeelding lokaal wil bouwen met behulp van de Dockerfile in deze huidige map.
‫Ik wil een poort maken op 8080 voor lokale ontwikkeling. En ik ben wat volumes aan het opzetten, en je zult zelfs merken dat ik je hier een
‫voorbeeld heb gegeven van een bind-mount, waar ik misschien een aangepast thema aan het doen ben. En ik wil mijn thema op mijn host in
‫de container mounten zoals we in vorige secties hebben gedaan, zodat ik het lokaal kan wijzigen en het
‫dan meteen op de server kan zien.
‫En trouwens, voor dit voorbeeld weet ik eigenlijk niet hoe ik thema's in Drupal moet ontwikkelen.
‫Ik weet niet precies of als ik daar een bestand wijzig, dit automatisch wordt weergegeven.
‫Ik wilde alleen een voorbeeld laten zien van hoe je, wanneer je aan webontwikkeling doet, dit meestal de manier is waarop je het
‫zou doen zonder elke keer te moeten stoppen en Compose te starten. Hier beneden, onder postgres, hebben we de omgevingsvariabele
‫en de geheime instellingen zoals eerder. We hebben de gedefinieerde volumes en je zult onderaan
‫zien dat
‫ik eigenlijk het op bestanden gebaseerde geheim heb, want als we lokale ontwikkeling doen, moeten we het op bestanden
‫gebaseerde geheim gebruiken.
‫Dingen worden een beetje interessant als ik naar deze prod kijk, of testbestanden. De manier waarop dit gaat werken
‫is, onthoud dat de . overschrijven. yml wordt automatisch opgepikt door
‫de Docker Compose-opdrachtregel. In prod
‫of test moet ik ze handmatig specificeren.
‫Dus voor de test moeten we de opdracht -f gebruiken.
‫Als je je herinnert uit eerdere secties, is de -f wanneer we een docker opstellen dat we een
‫aangepast bestand willen specificeren. Ik zal je dat zo laten zien.
‫In productie, aangezien we niet echt de Docker Compose-opdrachtregel op een productieserver
‫zullen hebben, wat we hier gaan doen, is dat we een docker compose-configuratieopdracht gaan gebruiken.
‫Het config-commando gaat eigenlijk een uitvoer doen door de uitvoer van meerdere configuratiebestanden samen te persen
‫of te combineren.
‫Dus dat wordt echt gaaf.
‫Heel snel, het testbestand heeft alleen de drupal en de postgres.
‫Stel je voor dat dit je Jenkins CI- of Codeship CI-oplossing was, waarbij ik wil dat het de afbeelding bouwt
‫elke keer dat ik mijn code commit, en ik wil het zo noemen, en ik wil dat het
‫op deze poort staat voor testdoeleinden. Dan ga ik een vals wachtwoord gebruiken. Maar ik hoef geen van de volumes te
‫definiëren, want ik ga niet echt proberen om benoemde volumegegevens te behouden, want nogmaals, het is gewoon een CI-platform.
‫Zodra het tests doorstaat of niet slaagt, zal het alles kwijtraken.
‫Dan zou je in dit scenario kunnen zien dat ik dit voorbeeldgegevensscenario heb
‫waar je misschien in je CI-oplossing gewoon databases hebt die afkomstig zijn van een aangepaste
‫Git-repository of misschien een FTP-download. Of er gebeurt iets tijdens de initialisatie
‫van uw CI, waarbij het daadwerkelijk een databasebestand downloadt. En in plaats van dat we elke keer dat we CI-testen
‫doen onze database moeten maken, zouden we deze map met voorbeeldgegevens gewoon monteren op de plaats waar onze postgres-gegevens zouden moeten
‫zijn.
‫En op die manier konden we garanderen dat we elke keer dat we een CI-test deden dezelfde voorbeeldgegevens hadden.
‫Ik ga daar niet verder op in. Ik wilde alleen laten zien dat dit bestand voor
‫CI er misschien anders uit zou zien.
‫Dan hebben we in de productie al onze normale productieproblemen. We specificeren volumes voor onze
‫specifieke gegevens. We specificeren ons geheim. En merk op dat we onderaan het externe geheim hebben.
‫Omdat we het geheim al via de opdrachtregel hebben ingevoerd, zoals we deden in
‫de eerdere opdracht.
‫Het punt hier is dat alle drie deze configuraties op de een of andere manier anders
‫zijn, maar ze hebben allemaal betrekking op de kernconfiguratie, of de basisconfiguratie, die alleen de twee services en hun afbeeldingen definieert.
‫U kunt hier zien. Hier is een herinnering van hoe het eruit ziet.
‫Laten we dit afsluiten en een paar commando's uitvoeren.
‫Als ik in deze map kijk, zie je dat ik het basisbestand heb en vervolgens de drie override-bestanden.
‫Nogmaals, onthoud dat de override. yml is de standaard.
‫Als ik een docker-compose maak, zal het hier feitelijk de docker-compose gebruiken. yml eerst, en dan zal het
‫de override overlappen. yml één bovenop. Ik wil een -d invoegen
‫zodat we snel kunnen kijken nadat het is begonnen. Ik ga een havenarbeider inspecteren op de drupal-afbeelding.
‫En wat ik je wilde laten zien was hier, het heeft alle rijdieren vermeld.
‫We weten dus dat het override-bestand nodig was, omdat we in het override-bestand al deze koppelingen
‫hebben gedefinieerd.
‫Dus we weten dat het dat heeft opgepikt.
‫Het is duidelijk dat als het de basis niet zou oppikken, het niet eens zou weten welke afbeeldingen
‫hij moest gebruiken, dus zou het eigenlijk tegen ons klagen en zeggen dat het Compose-bestand onvolledig was.
‫Die werkte.
‫Laten we snel naar beneden gaan.
‫Als we het commando zouden uitvoeren dat we nodig hadden voor onze CI-oplossing,
‫moesten we ervoor zorgen dat Docker Compose er was, geïnstalleerd en beschikbaar was, zodat
‫we docker-compositie-commando's konden uitvoeren. Dan kunnen we de -f specificeren, en
‫dan is de volgorde van de f's dat het basisbestand altijd eerst moet zijn.
‫Dus docker compose yml, dan docker compose-test.
‫Als we dit deden met een up aan het einde en een -d, en ik ging diezelfde drupal inspecteren, dan zul je
‫merken dat er geen binding mounts zijn.
‫Ze ontbreken volledig omdat we die in het testbestand niet hebben gespecificeerd.
‫We hadden Drupal niet echt nodig om informatie op te slaan, omdat het aan het einde van
‫onze CI-run zou worden weggegooid.
‫En ten derde hebben we de productieconfiguratie.
‫De productieconfiguratie zal een beetje anders zijn.
‫Ik ga de Pijl omhoog raken, en dan ga ik hier de prik doen. In plaats van een omhoog-commando, wat
‫ik hier wil doen, is een config.
‫Als je gewoon heel snel naar de hulp voor de configuratie kijkt, heeft deze slechts twee opties en geen van
‫beide is echt relevant in deze situatie.
‫Wat we willen doen, is gewoon config alleen uitvoeren. Wat het daadwerkelijk gaat doen,
‫is naar beide bestanden kijken en ze samenvoegen tot een enkel Compose-bestandsequivalent.
‫Dus wat we hier zouden kunnen doen, is deze opdracht ergens in onze CI-oplossing uitvoeren. Laat het dan uitvoeren naar
‫een bestand, misschien met je weet wel, zoiets. Dat uitvoerbestand zou het bestand zijn dat we officieel in
‫productie zouden gebruiken om onze stapel te maken of bij te werken.
‫Ik wil hier echter een klein voorbehoud maken.
‫Dit zijn allemaal relatief nieuwe dingen.
‫We weten dat Secrets en Swarm Stacks relatief nieuw zijn.
‫Ze zijn pas een paar maanden oud.
‫Vanaf deze opname.
‫Er zijn dus een paar ruwe randen.
‫We hebben net dat configuratiecommando uitgevoerd en je zult merken dat de geheimen daar niet werden vermeld.
‫Dat is momenteel een bug.
‫Ik werk eigenlijk samen met het Docker-team om te zien of we die bug niet kunnen pletten.
‫Dus tegen de tijd dat u dit leest, is het mogelijk al opgelost.
‫Zorg ervoor dat u die uitvoer van de configuratieregel inspecteert voordat u in
‫productie gaat implementeren.
‫Ten tweede is de Compose Extends-optie, die ik hier niet heb besproken, een andere manier om deze
‫Compose-bestanden te overschrijven, waarbij u het override-bestand daadwerkelijk gebruikt en u daarin een uitgebreide sectie
‫definieert.
‫Het is een beetje meer declaratief, dus het is gemakkelijker te begrijpen. Ik zal een link geven in
‫de referenties voor deze sectie. Weet alleen dat die Extends-optie nog niet werkt in Swarms-stacks.
‫Ik heb het hier niet genoemd omdat het je niet echt de volledige app-levenscyclus geeft waar we op hoopten, maar
‫ik verwacht wel dat ze daar op een gegeven moment iets aan zullen doen.
‫Zoals het toevoegen aan Swarm of een betere workflow creëren. Want dat is echt het idee dat
‫we met al deze tools proberen te bereiken, is om een complete en gemakkelijke levenscyclus te hebben
‫van ontwikkeling tot test, tot productie, met dezelfde set configuraties, in dezelfde set afbeeldingen .
‫Ik hoop dat dit je aan het denken heeft gezet over hoe je je apps op deze manier kunt
‫maken en hoe je je eigen Compose-bestanden kunt uitbreiden voor complexe scenario's.
‫Omdat niets sneller een glimlach op mijn gezicht tovert met Docker dan wanneer ik iemand een eenregelig commando zie uitvoeren om
‫iets te doen waarvoor voorheen meerdere scripts nodig waren om uit te voeren.