Share
De mensen die Docker maken beschrijven het graag met een metafoor voor een vrij oud stukje technologie: de zeecontainer.
Hoewel we ze niet eens bedenken of opmerken, was de verzendcontainer in die tijd eigenlijk een vrij revolutionair stukje technologie. Ongeacht de vorm of de grootte van het oorspronkelijke item, kon de eigenaar van de boot / vliegtuig / vrachtwagen / wat-heb-je gemakkelijk berekenen hoeveel middelen ze nodig hadden om te verdelen, door een gestandaardiseerde container te gebruiken.
Docker probeert hetzelfde gemaksniveau te nemen en het naar de serverwereld te brengen. Het is de natuurlijke uitbreiding van tools zoals Vagrant waarmee u dezelfde virtuele machine kunt gebruiken die u in ontwikkeling gebruikt voor productieomgevingen. Vagrant-achtige virtuele machines zijn geweldig, maar ze zijn zwaargewicht. Ze nemen veel resources in beslag, waarvan een groot deel overbodig is: een Vagrant-image laadt een hele nieuwe kopie van Linux in een bestaande. Zou het niet beter zijn als u het gemak en de uniformiteit van Vagrant zou kunnen gebruiken, maar niet het hele besturingssysteem opnieuw hoeft te laden? Welnu, dat is precies wat Docker doet.
In deze zelfstudie doorloop ik de gehele Docker-werkstroom. We zullen eerst de stappen doorlopen om een eenvoudige Python-webapp te krijgen die een paar Python-afhankelijkheden heeft en afhankelijk is van een Redis-database voor persistentie die actief is. Daarna installeren we Docker en installeren we alle vereisten van de webapp (Redis, Python en afhankelijkheden van Python) in één Docker-image. We zullen die afbeelding vervolgens gebruiken en op een andere server implementeren.
We zullen gewoon een voorbeeldtoepassing voor speelgoed inzetten, maar de stappen om je eigen echte apps te implementeren lijken erg op elkaar.
Om te beginnen, heb je een Linux-box nodig met een recente versie van Ubuntu of een virtuele machine waarop een recente versie van Ubuntu draait. Als u de zelfstudie volledig wilt volgen en de app wilt implementeren, hebt u ook een tweede computer (of tweede virtuele machine) nodig om te implementeren naar.
De eerste stap is om Docker zelf te installeren. Docker is in een zeer snelle ontwikkeling, dus de gemakkelijkste manier om het te installeren verandert vaak vrij snel. Bekijk de sectie Aan de slag van Docker als je de nieuwste snufjes wilt bekijken.
Volg anders de onderstaande stappen en we zullen een Vagrant op virtuele machine gebaseerde installatie van Docker instellen die werkt op een van de belangrijkste besturingssystemen. Ga eerst naar de website van Vagrant en installeer de nieuwste Vagrant en VirtualBox voor uw besturingssysteem.
Nadat Vagrant is geïnstalleerd, maakt u een nieuwe map, opent u daar een opdrachtprompt en doet u het volgende:
vagrant init hashicorp / precision64 (... wait a while ...) vagrant up vagrant ssh
Vagrant zorgde gewoon voor het maken van een virtuele machine met Ubuntu 12.04 voor jou en je bent nu SSH'd in zijn prompt. We kunnen nu de installatie-instructies van Docker voor Ubuntu volgen. Controleer de website voor het geval er wijzigingen zijn opgetreden sinds deze is geschreven, maar hoogstwaarschijnlijk kunt u de volgende opdrachten direct in de terminal plakken:
# installeer de backported kernel sudo apt-get update sudo apt-get installeer linux-image-generic-lts-raring linux-headers-generic-lts-raring # reboot sudo reboot
U wordt teruggestuurd naar de prompt van uw lokale machine wanneer de VM opnieuw opstart, dus wacht even en doe nog een:
zwervende ssh
... naar SSH terug naar uw VM. Nu de vereisten van Docker met succes zijn geïnstalleerd, moeten we doorgaan en Docker zelf installeren. Plak in de volgende opdracht:
curl -s https://get.docker.io/ubuntu/ | sudo sh
... die een eenvoudig Docker-installatiescript van de Docker-site pakken en uitvoeren. Docker zou nu met succes geïnstalleerd moeten zijn, dus laten we beginnen ermee te spelen.
Een keer apt-get is klaar met zijn magie, doe het volgende:
sudo Docker run -i -t ubuntu / bin / bash
... om te controleren en te zien dat de installatie succesvol was. Als het werkt, zal Docker doorgaan met het downloaden van een Ubuntu Docker-image en na verloop van tijd kom je uit bij wat lijkt op een rootprompt. Voel je vrij om een beetje rond te spelen, je zult merken dat je in een omgeving bent die volledig losstaat van je hostmachine. U hebt waarschijnlijk het wortel en # meld de prompt aan. Je loopt als root-gebruiker in een nieuwe virtuele omgeving. Als u een gebruikers opdracht, ziet u dat uw andere gebruikers niet meer aanwezig zijn.
Het is de moeite waard om even uit te leggen wat het is havenarbeider commando dat je net hebt ingetypt deed en hoe deze magie gebeurde.
Accentsconagua
rennen CommandoHet hulpprogramma Docker lijkt veel inspiratie te hebben getrokken git's command line interface en als gevolg daarvan maakt het gebruik van subcommando's. In dit geval hebben we de rennen subopdracht. De rennen opdracht vereist twee argumenten: een afbeelding en een opdracht.
Het is ook slim, dus als (zoals in dit geval) die afbeelding niet is geïnstalleerd, zal deze de centrale Docker-repository bevragen en er een voor je downloaden. Hier hebben we het verteld om een ubuntu afbeelding en op de hoogte Docker dat het zou moeten beginnen / Bin / bash in dat beeld. De -t en -ik vertel Docker om een TTY toe te kennen en uit te voeren in "interactieve modus", met andere woorden, om een opdrachtprompt te krijgen. De reden hiervoor is dat Docker een beetje anders werkt dan andere virtualisatiesoftware waarmee je bekend bent. Docker-afbeeldingen "starten" niet, ze worden gewoon uitgevoerd. Ze gebruiken de bestaande Linux-installatie, dus het starten van een Docker-afbeelding kan onmiddellijk zijn. In sommige opzichten is Docker dichter bij Linux chroot commando dan naar meer traditionele virtualisatie tools zoals VMWare of VirtualBox.
Er zijn enkele andere belangrijke verschillen met standaard virtualisatietools. Laten we een snel experiment uitvoeren en een bestand maken en de inhoud ervan afdrukken:
echo Een experiment> experiment.txt
Nu als u:
cat experiment.txt
Het zal graag afdrukken:
Een experiment
Tot zover gaat het goed, ons domme experiment werkt precies zoals verwacht. Laten we Docker afsluiten en terugkeren naar de opdrachtprompt van onze hostcomputer:
Uitgang
Als u Docker herstart met dezelfde opdracht die u eerder hebt gebruikt:
sudo Docker run -i -t ubuntu / bin / bash
... u zult merken dat dingen zich niet langer gedragen zoals u zou verwachten. Als u het bestand probeert te cateren dat we de vorige keer hebben gemaakt, krijgt u nu een foutmelding:
root @ e97acdf4160c: / # cat experiment.txt cat: experiment.txt: geen bestand of directory
Dus wat is er aan de hand? Wijzigingen in Docker-afbeeldingen zijn standaard niet aanwezig. Om uw wijzigingen in een Docker-afbeelding op te slaan, moet u dit doen plegen hen, git stijl. Dit kan even wennen zijn, maar het is vrij krachtig omdat het betekent dat je ze ook kunt "vertakken" git stijl (daarover later meer).
Laten we voorlopig iets nuttigers doen. Laten we installeren Python, redis en een paar andere hulpprogramma's die we gebruiken om onze demo-app binnenkort uit te voeren. Daarna zullen we plegen om onze veranderingen aan te houden. Start een kopie van Docker op de nieuwste Ubuntu-afbeelding:
docker -t -i ubuntu / bin / bash
De Ubuntu-basisafbeelding bevat mogelijk geen Python, dus controleer of je een kopie hebt gekregen door te typen Python op de vraag. Als u een foutmelding krijgt, laten we het dan installeren:
apt-get update apt-get install python
Tot nu toe, zo goed. Het is mogelijk dat we later andere projecten willen maken die gebruikmaken van Python, dus laten we doorgaan en deze wijzigingen opslaan. Open een andere opdrachtprompt (als u de hierboven aanbevolen Vagrant-installatie gebruikt, moet u dit doen zwervende ssh nogmaals vanuit een aparte prompt) en doe het volgende:
koppelaar ps
U krijgt een lijst zoals hieronder, van alle Docker-containers die momenteel worden uitgevoerd:
ID BEELDBESCHRIJVING GECREËERDE STATUSPOORTEN 54a11224dae6 ubuntu: 12.04 / bin / bash 6 minuten geleden Omhoog 6 minuten
Het nummer onder de ID-kolom is belangrijk: dit is de ID van uw container. Deze zijn uniek, als u uw container afsluit en dezelfde afbeelding opnieuw uitvoert, ziet u daar een nieuw nummer.
Laten we onze wijzigingen opslaan nu we Python hebben geïnstalleerd. Om dit te doen gebruikt u de plegen opdracht die twee argumenten vereist: de container waarvan u de wijzigingen wilt opslaan en de naam van de afbeelding. De Docker-conventie is om een userid te gebruiken gevolgd door een / en de korte naam van de afbeelding. Dus in dit geval, laten we het noemen tuts / python. Voer de volgende opdracht uit om uw Python-installatie op te slaan en zorg ervoor dat u de ID voor uw container uit de laatste stap vervangt
koppelaar commit tuts / python
Na een paar seconden keert het terug met een reeks letters en cijfers. Dit is de ID van de afbeelding die u zojuist hebt opgeslagen. U kunt deze afbeelding altijd uitvoeren wanneer u maar wilt en deze naar dit ID-nummer of naar het gemakkelijk te onthouden nummer verwijzen tuts / python naam die we eraan hebben gegeven.
Laten we een kopie van de afbeelding die we net hebben gemaakt uitvoeren:
docker run -t -i tuts / python / bin / bash
Op dit moment moet u twee terminalvensters open hebben die twee afzonderlijke Docker-sessies uitvoeren.
Je zult nu merken dat als je typt Python in een van beide ontvang je geen foutmelding meer. Probeer een bestand aan te maken in het tweede venster:
touch / testbestand
Schakel nu terug naar uw originele Docker-venster en probeer het bestand te bekijken:
kat / testbestand
U krijgt een foutmelding Dit komt omdat u een geheel andere "virtuele machine" gebruikt op basis van de afbeelding die u hebt gemaakt met de koppelaar commit commando. Uw bestandssystemen zijn volledig gescheiden.
Als je nog een andere terminal opent (opnieuw, zul je moeten uitvoeren zwervende ssh bij gebruik van Vagrant) en doe het volgende:
koppelaar ps
... dat zie je havenarbeider bevat nu twee lopende afbeeldingen, niet slechts één. U kunt zich apart verbinden met elk van die afbeeldingen. Om door te gaan met de git metafoor, je werkt nu met twee takken en ze zijn vrij om te "divergeren".
Laten we doorgaan en het laatste venster sluiten dat we hebben geopend. Als je rent koppelaar ps nogmaals, er zal nu slechts één ID worden vermeld. Maar wat als u terug wilt naar een vorige container? Als u typt:
koppelaar ps -a
Docker geeft ook alle eerdere containers weer. U kunt geen container uitvoeren die is afgesloten, maar u kunt de ID's van de vorige container gebruiken om nieuwe afbeeldingen te maken. Als u de nieuwe afbeelding uitvoert, wordt u effectief teruggebracht naar de staat van uw vorige container.
Laten we de nieuwe vensters sluiten die we hebben geopend en terugschakelen naar de terminal voor de eerste Docker-sessie die we gestart hebben. Eenmaal terug, ga je gang en installeer wat meer tools voor onze kleine app. In dit geval moeten we de Python-pakketbeheerder installeren, twee Python-modules om Python te laten fungeren als een webserver en te communiceren met redis, en de Redis-server zelf.
apt-get install python-pip redis-server pip installatie redis fles
Eens deze afwerking, laten we dit plaatje vastleggen. Voer vanuit een ander terminalvenster de volgende opdracht uit:
koppelaar ps
... en noteer de ID en leg deze vast onder de naam tuts / pyredis:
havenarbeider begaat tuts / pyredis
We hebben nu dus een Docker-afbeelding die de nodige hulpmiddelen bevat om een kleine Python-webapp uit te voeren met Redis als backend. Als u toekomstige projecten heeft die dezelfde stapel zullen gebruiken, hoeft u alleen maar te doen om ze op gang te krijgen: koppelaar uitvoeren -t -i tuts / pyredis / bin / bash en commit zodra u uw broncode heeft toegevoegd.
Ok, dus onze backend is opgezet. Nu om de app zelf in te stellen!
Ik heb een kleine voorbeeldapp gemaakt die gebruikmaakt van de Redis- en Python-modules die we tot nu toe hebben geïnstalleerd. De app is vrij eenvoudig, het geeft alleen een lijst weer met de Redis-toetsen en biedt een rudimentaire interface om ze toe te voegen en te bewerken. Laten we de broncode op je hostcomputer zetten (de zwervende ssh sessie) als eerste:
cd git clone https://github.com/nikvdp/tuts-docker.git pyredis
In de hoofddirectory van je hostmachine heb je nu een pyredis map die het Python-script bevat dat we zullen gebruiken. Dus, hoe gaan we over het kopiëren van deze app naar onze Docker-afbeelding?
Nou, Docker heeft een leuke functie waarmee je een lokale map in je container kunt mounten. Laten we een andere Docker-afbeelding uitvoeren en de map koppelen:
koppelaar run -v ~ / pyredis: / tuts: rw -t -i tuts / pyredis / bin / bash
Dit is net zoals ons rennen commando's van vóór, met de toevoeging van de -v parameter.
In feite kunt u met deze opdracht een map delen tussen Docker en uw hostcomputer. De :geeft de paden aan om te delen. In ons geval delen we onze pyredis map, gelegen op ~ / Pyredis op onze machine en deze monteren op / tuts in de Docker-afbeelding. De rw aan het einde is voor 'lezen-schrijven' en betekent dat wijzigingen die op de Docker-afbeelding worden aangebracht ook op onze machine worden weergegeven.
Op uw Docker-prompt kunt u nu doen:
cd / tuts ls
... en bekijk de inhoud van de ~ / Pyredis map op uw computer.
Deze share is echter tijdelijk, als u deze Docker-afbeelding op een andere computer uitvoert of deze afbeelding opnieuw uitvoert zonder de -v optie heeft de afbeelding er geen toegang meer toe. Laten we het kopiëren naar een andere locatie binnen de daadwerkelijke Docker-afbeelding:
cp -R / tuts / / pyredis
Aangezien wijzigingen in Docker-bestandssystemen standaard tijdelijk zijn, kunnen we dit in de afbeelding opslaan door het opnieuw te doen koppelaar ps om onze container-ID te verkrijgen en onze wijzigingen door te voeren:
havenarbeider begaat tuts / pyredis
U zult opmerken dat we ons hebben gecommitteerd aan dezelfde beeldnaam die we de vorige keer hebben vastgelegd, tuts / pyredis. Docker werkt de afbeelding bij en houdt een log bij van al uw wijzigingen voor u. Net zoals git, als je het verknoeit, kun je eenvoudig teruggaan naar een goede versie koppelingsrunzijn ID. Probeer het volgende om de geschiedenis van een afbeelding te bekijken:
geschiedenistanden / pyredis van de docker
Je ziet zoiets als dit:
ID CREATED GEMAAKT DOOR tuts / pyredis: laatste 17 seconden geleden / bin / bash 4c3712e7443c 25 uren geleden / bin / bash ubuntu: 12.10 6 maanden geleden / bin / bash 27cf78414709 6 maanden geleden
Dit is een geschiedenis van alle commits die we hebben gemaakt tijdens het maken van de tuts / pyredis afbeelding, inclusief de afbeeldingen die we hebben gemaakt voor verschillende namen, zoals tuts / python. Als je terug wilt gaan naar de commit vlak voordat we onze hebben gekopieerd pyredis app in / pyredis je zou het kunnen proberen (verander de ID's zodat deze overeenkomen met die van jou):
koppelaar run -t -i 4c3712e7443c / bin / bash
... en je zult zien dat er geen is / pyredis directory.
Dus nu hebben we alle stukken op hun plaats. De volgende stap is om de app vanuit de container daadwerkelijk uit te voeren. Aangezien we een web-app implementeren, moeten we ook een manier opgeven om de app via internet te openen. De rennen commando heeft je (opnieuw) gedekt. Docker's run-opdracht ondersteunt a -p optie waarmee u kunt opgeven hoe poorten worden toegewezen.
Als u Vagrant gebruikt om Docker uit te voeren, moet u de port forwarding van Vagrant instellen voordat we zinvolle tests kunnen uitvoeren. Als u Vagrant niet gebruikt, slaat u deze stap gewoon over.
Als u Vagrant gebruikt om dit te testen, moet u poort doorsturen instellen zodat de webbrowser van uw lokale computer toegang heeft tot de poorten op de Vagrant VM, die op zijn beurt wordt doorgestuurd naar de poort van de Docker-instantie. Dus in ons geval zullen we de poort 9000 van onze lokale machine instellen om door te sturen naar de 9000 van onze Vagrant VM, die op zijn beurt weer door gaat naar onze tuts / pyredis Havenpoort 8080 van Docker.
Ga op uw lokale computer terug naar de map waar u het eerst hebt getypt vagrant init. Je zult daar een tekstbestand vinden dat eenvoudigweg wordt genoemd Vagrantfile. Open het in je favoriete teksteditor en zoek het volgende gedeelte:
# Maak een doorgestuurde poorttoewijzing die toegang geeft tot een specifieke poort # in de machine vanaf een poort op de hostcomputer. In het onderstaande voorbeeld krijgt # toegang tot "localhost: 8080" toegang tot poort 80 op de gastmachine. # config.vm.network "forwarded_port", gast: 80, host: 8080
Maak de laatste regel uncomment en verander de poorten van 80 en 8080 in 8080 en 9000. Het resultaat zou er als volgt uit moeten zien:
# Maak een doorgestuurde poorttoewijzing die toegang geeft tot een specifieke poort # in de machine vanaf een poort op de hostcomputer. In het onderstaande voorbeeld krijgt # toegang tot "localhost: 8080" toegang tot poort 80 op de gastmachine. config.vm.network "forwarded_port", gast: 8080, host: 9000
Nu uitvoeren:
vagrant herladen
... waardoor de VM van Vagrant zichzelf herstart met de juiste poort naar voren. Zodra dit is voltooid, kunt u uitvoeren zwervende ssh opnieuw en ga door met de zelfstudie.
Onze kleine pyredis app standaard opent een kleine webserver op poort 8080. Met de volgende opdracht kunt u poort 8080 openen via poort 9000 op uw hostcomputer:
docker run -t -i -p 9000: 8080 tuts / pyredis / bin / bash
U krijgt een Docker-rootprompt, dus laten we onze app opstarten:
redis-server 2> & 1> / dev / null & python / pyredis/app.py
Als alles goed gaat, ziet u het volgende:
Fles v0.11.6 server opstarten (met WSGIRefServer ()) ... Luisteren op http: // localhost: 8080 / druk Ctrl-C om te stoppen.
Dit betekent dat de server actief is. Open een webbrowser op uw lokale computer en wijs ernaar localhost: 9000 (als u deze zelfstudie op een externe server uitvoert, zorg er dan voor dat u netwerktoegang hebt tot poort 9000 en vervang deze localhost met het adres van uw webserver).
Met een beetje geluk zou je het hoofdscherm van onze kleine app moeten zien. Ga je gang en voeg een paar sleutels toe en verander een aantal waarden. De gegevens moeten blijven bestaan. Als u echter uw Docker-prompt afsluit en Docker opnieuw start, is de database weer leeg. Dit is iets om rekening mee te houden als u van plan bent uw database in een Docker-container te hosten..
Dit is dus geweldig om te testen, maar het doel is om je app te kunnen implementeren. U wilt niet elke keer de opdrachten invoeren om uw app handmatig te starten.
Docker komt opnieuw te hulp. Wanneer u zich commit, kan Docker automatisch enkele run-info opslaan, zoals welke poorten moeten worden toegewezen en welke opdrachten moeten worden uitgevoerd wanneer de afbeelding wordt gestart. Op deze manier hoef je alleen maar te typen havenarbeider en Docker zorgt voor de rest. Echte containerisatie.
Voor ons script hebben we slechts twee opdrachten die bij het opstarten moeten worden uitgevoerd:
redis-server 2> & 1> / dev / null & python / pyredis/app.py
De eenvoudigste manier om dat te doen is om een klein startscript te maken dat deze twee opdrachten uitvoert. Laten we beginnen met onze tuts / pyredis opnieuw en voeg een klein startscript toe (kopieer en plak gewoon het onderstaande in de Docker-prompt):
koppelaar uitvoeren -t -i tuts / pyredis / bin / bash cat> /pyredis/launch.sh <&1 > / dev / null & #! / bin / sh python /pyredis/app.py EOF chmod + x /pyredis/launch.sh
Hierdoor werden de commando's opgeslagen die we gebruiken om onze Python-server in een klein bash-script te starten launch.sh en stelt het uitvoerbare bit zo in dat het gemakkelijker kan worden uitgevoerd.
Nu het script met succes in de afbeelding staat, vanaf een andere terminal, commit het zodat het blijft bestaan (vergeet niet om een a te doen koppelaar ps om als eerste de ID van je nieuwste container te ontvangen):
havenarbeider begaat tuts / pyrdis
Laten we dit testen. Als u de Docker-prompt afsluit en opnieuw uitvoert met de volgende opdracht, moet u toegang hebben tot de pyredis-web-app op localhost: 9000, net als de vorige keer.
docker run -t -i -p 8000: 8080 tuts / pyredis / bin / bash /pyredis/launch.sh
Oké, dus nu kunnen we onze kleine app uitvoeren met een enkele opdracht. Maar er is meer! Met Docker kunt u wat standaardconfiguratiegegevens opslaan met uw commits. Op die manier hoeven we niet te onthouden om elke keer onze poorttoewijzing in te voeren en opdrachtinformatie te starten en kunt u een Docker-afbeelding aan iemand anders geven. Ze kunnen het dan eenvoudig uitvoeren koppelingsrun en Docker zorgt voor de rest.
Om dit te configureren, moet u wat JSON-informatie doorgeven aan de commit-opdracht. Er zijn veel parameters die u kunt gebruiken, maar voor nu houden we ons alleen bezig met mappingpoorten en initialisatiescripts. Start je favoriete teksteditor en plak het volgende in:
"cmd": ["/ bin / bash", "/pyredis/launch.sh"], "PortSpecs": ["9000: 8080"]
Dit vertegenwoordigt de informatie die we hebben getypt in de -p optie en het pad naar het startscript. Een belangrijk aandachtspunt is dat voor de cmd optie, elke plaats waar u normaal gesproken een spatie zou gebruiken, wordt eigenlijk doorgegeven als een afzonderlijke parameter.
Sla dat JSON-fragment op naar een bestand met de naam runconfig.json en laten we Docker updaten om het te gebruiken.
koppelaar commit -run = $ (cat runconfig.json) tuts / pyredis
Nu als u:
havenarbeider laat tuts / pyredis
Je zult het zien fles start en je hebt toegang tot de app via de browser.
De makers van Docker hebben een openbaar register gemaakt waarop iedereen Docker-afbeeldingen kan pushen en ophalen. Dit betekent dat de implementatie van uw nieuwe app op een externe server net zo eenvoudig is als het naar het centrale register van Docker te duwen en het vervolgens van een server te halen waarop Docker is geïnstalleerd.
Dit is vrij eenvoudig, dus ik verwijs u naar de eigen documentatie van Docker. Als u in plaats daarvan privé wilt implementeren, lees dan verder naar de volgende sectie (s).
Geweldig, dus nu hebben we een gebruiksvriendelijke Docker-afbeelding die op uw computer wordt uitgevoerd. De volgende stap is om het op een server te implementeren!
Dit deel is een beetje ingewikkeld. Het distributiemodel van Docker is gebaseerd op het idee van opslagplaatsen. U kunt uw Docker-afbeeldingen zo vaak duwen en naar een opslagplaats in Docker slepen als u wilt en verschillende servers kunnen allemaal verschillende afbeeldingen gebruiken. Dit is geweldig, maar helaas is een beetje werk vereist om je eigen repository te hosten. Als u hosting of open source-software host, kunt u de openbare Docker-repository gewoon rechtstreeks gebruiken om uw afbeeldingen op te slaan. Als u echter eigen code implementeert, wilt u dat waarschijnlijk niet doen. Dit laat je met twee keuzes:
De eerste is eenvoudiger, maar verliest veel van de koelere functies van Docker, zoals het bijhouden van de geschiedenis van uw afbeeldingen en de mogelijkheid om de poorttoewijzing op te slaan en de configuratie binnen de afbeelding uit te voeren. Als dit belangrijk voor je is, ga je naar het volgende gedeelte om te leren hoe je je eigen (privé) Docker-repository kunt instellen. Als u alleen uw afbeeldingen op uw servers wilt kunnen implementeren, kunt u deze methode gebruiken.
De eerste stap is om uw container te exporteren naar een .teer archief. U kunt dit doen via Docker's exporteren commando. Als u de voorbeeld-app wilt implementeren die we in deze zelfstudie hebben gebruikt, doet u zoiets als dit:
haven exporteren> pyredis.tar
Docker zal een tijdje zitten en verwerken, maar daarna heb je een pyredis.tar bestand dat de afbeelding bevat die u hebt gemaakt. U kunt dan kopiëren pyredis.tar naar uw server en voer het volgende uit:
kat pyredis.tar | Docker-import -
Docker zal weer een tijdje blijven zitten en uiteindelijk de ID uitspelen van de nieuwe afbeelding die hij heeft gemaakt. Jij kan plegen Dit om een meer memorabele naam te maken door dit te doen:
havenarbeider begaat tuts / pyredis
Onze zelfstudie-app is nu geïmplementeerd en je kunt hem uitvoeren met dezelfde run-opdracht als hiervoor:
docker run -t -i -p 8000: 8080 tuts / pyredis / bin / bash /pyredis/launch.sh
De coolere manier om je app te implementeren, is om je eigen Docker-repository te hosten. Docker op een computer laten installeren en de volgende opdracht uitvoeren:
docker run -p 5000: 5000 samalba / docker-register
Wacht een beetje om de stukken te downloaden en je zult snel wat berichten zien over het starten van eenhoorn en het opstarten van werkers.
Dit betekent dat uw Docker-register actief is (in zijn eigen docker-container) en toegankelijk is voor uw lokale machine in poort 5000. Iets mind-buigend, maar geweldig. Laten we eerst onze inloggegevens instellen en vervolgens de Docker-afbeelding die we eerder in de zelfstudie hebben aangemaakt, naar ons nieuwe register pushen. Voer in een nieuwe terminal het volgende uit
docker login localhost: 5000
Ga je gang en voer de gebruikersnaam, het wachtwoord en de e-mail in die je wilt gebruiken met je Docker-repository.
Om de tuts / pyredis app in de repo, we moeten deze eerst "taggen" met de adresgegevens van de privé repository, zoals:
docker-tag tuts / pyredis localhost: 5000 / tuts / pyredis
Dit vertelt Docker om een nieuwe "tag" van te maken tuts / pyredis en associeer het met de repo die draait op localhost: 5000. Je kunt deze tag zien als de naam van deze afbeelding in de repository. Voor consistentie heb ik de namen hetzelfde gehouden en getagged localhost: 5000 / tuts / pyredis, maar deze naam kan gemakkelijk iets compleet anders zijn (zoals localhost: 5000 / pyredis_prod.)
Als je rent docker-afbeeldingen nu ziet u dat er een nieuwe afbeelding wordt weergegeven met de naam localhost: 5000 / tuts / pyredis. Docker's mechanisme voor het specificeren van repositories is nauw verbonden met het mechanisme voor naamgeving (of taggen zoals Docker het noemt), dus dit is alles wat je nodig hebt.
Om de afbeelding die we hebben gemaakt in onze repository te pushen, doe het gewoon docker push en de volledige gelabelde afbeeldingnaam (inclusief het adres):
docker push localhost: 5000 / tuts / pyredis
Docker maakt verbinding met uw huidige repository localhost: 5000 en begin met het pushen van je wijzigingen. U zult zien dat veel berichten over de verschillende HTTP-verzoeken in het andere terminalvenster (degene die wordt uitgevoerd) verschijnen samalba / docker-registry), en hier gaat informatie over de upload voorbij. Dit duurt een tijdje, dus u wilt misschien een kopje koffie pakken.
Een waarschuwing, aangezien onze Docker-repository zelf in een Docker-container draait, moeten we de afbeelding van de repository binden nadat we klaar zijn met duwen. Anders, omdat het Docker-bestandssysteem tijdelijk verandert, verdwijnt standaard de afbeelding die we naar de repo hebben geduwd zodra we onze lokale samalba / docker-registry Docker-container.
Om dit te doen, doet u het gebruikelijke koppelaar ps om de ID van de running te krijgen samalba / docker-registry container en verbind het vervolgens met een nieuwe container. Dit is niet ideaal, als u dit in de productie doet, wilt u Docker-volumes configureren of de -v optie van boven om het bestand van de repo direct op de server aan te houden, in plaats van in de container, maar dat valt buiten het bestek van deze tutorial.
Nu voor het leuke gedeelte: het implementeren van onze nieuwe Docker-afbeelding op een nieuwe server. Omdat Docker-opslagplaatsen ten tijde van dit schrijven geen beveiligings- of authenticatiemechanismen hebben, zullen we ons werk doen met beveiligde SSH-tunnels. Van de virtuele machine waar u de tuts / pyredis zelfstudie, ssh in uw productieserver en stuur poort 5000 door zoals:
ssh -R 5000: localhost: 5000 -l
De -R vlag naar ssh betekent dat wanneer u verbinding maakt met localhost: 5000 op uw productieserver stuurt SSH de verbinding terug naar poort 5000 op uw virtuele machine, die op zijn beurt wordt doorgestuurd naar de samalba / docker-registry container waarin onze repo leeft.
Als Docker niet op deze server is geïnstalleerd, kunt u het installeren volgens de installatie-instructies. Zodra Docker actief is, is het implementeren van uw afbeelding net zo eenvoudig als:
docker pull localhost: 5000 / tuts / pyredis
Omdat we een tunnel via SSH hebben gemaakt, zal Docker denken dat het de lokale host van de externe server: 5000 afhaalt, maar dit wordt in feite getunneld naar de lokale host van je lokale VM: 5000, die op zijn beurt wordt omgeleid naar Docker. Geef het wat tijd om te downloaden, maar als het klaar is, zou je onze pyredis-app op precies dezelfde manier moeten kunnen gebruiken als waarop we het hebben uitgevoerd op de originele VM, inclusief de opgeslagen run-configuratie en poorten:
havenarbeider laat tuts / pyredis
Dat is dus de basis van Docker. Met deze informatie kunt u nu Docker-afbeeldingen maken en beheren, pushen en trekken naar openbare en persoonlijke repos en deze implementeren op afzonderlij
