Share
Folk som gjør Docker like å beskrive det ved hjelp av en metafor til et ganske gammelt stykke teknologi: fraktbeholderen.
Mens vi ikke engang tenker på eller legger merke til dem mye nå, var fraktbeholderen faktisk et ganske revolusjonerende stykke teknologi i sin tid. Uansett hvilken form eller størrelse det opprinnelige elementet var, kunne du ved å bruke en standardisert container, eieren av båten / flyet / lastebilen / hva-du-du, enkelt finne ut hvor mange ressurser de måtte tildele.
Docker forsøker å ta det samme nivået av bekvemmelighet og bringe det til serververdenen. Det er den naturlige utvidelsen av verktøy som Vagrant som lar deg distribuere den samme virtuelle maskinen du bruker i utvikling til produksjonsmiljøer. Vagrant stil virtuelle maskiner er flotte, men de er tungvektige. De tar mye ressurser å løpe, hvorav mye er overflødig: et Vagrant-bilde laster en helt ny kopi av Linux inne i en eksisterende. Ville det ikke vært bedre hvis du kunne bruke Vagrants bekvemmelighet og enhetlighet, men ikke å laste på hele operativsystemet? Vel, det er akkurat hva Docker gjør.
I denne veiledningen vil jeg gå gjennom hele Docker-arbeidsflyten. Vi går først gjennom trinnene for å få en enkel Python webapp som har et par Python-avhengigheter og avhenger av en Redis-database for utholdenhet oppe og kjøring. Deretter installerer vi Docker og installerer alle webapps krav (Redis, Python og Python's avhengigheter) til ett Docker-bilde. Vi bruker da bildet og distribuerer det til en annen server.
Vi skal bare distribuere en lekeapplikasjonsapp, men trinnene for å distribuere dine egne virkelige apper vil være svært like.
For å komme i gang, trenger du enten en Linux-boks som kjører en nylig versjon av Ubuntu eller en virtuell maskin som kjører en nylig versjon av Ubuntu. Hvis du vil følge opp veiledningen fullt ut og distribuere appen, må du også ha en andre maskin (eller andre virtuelle maskin) for å distribuere til.
Det første trinnet er å installere Docker selv. Docker er under veldig rask utvikling, slik at den enkleste måten å installere det ofte endres ganske raskt. Sjekk ut Dockerens start-seksjon hvis du vil sjekke ut kanten.
Ellers følger du trinnene nedenfor, og vi oppretter en Vagrant virtuell maskinbasert installasjon av Docker som vil fungere på noen av de store operativsystemene. Først går du over til Vagrant nettside og installerer den nyeste Vagrant og VirtualBox for ditt operativsystem.
Når Vagrant er installert, lag en ny mappe, åpne en kommandoprompt der og gjør følgende:
vagrant init hashicorp / precise64 (... vent litt ...) vagrant up vagrant ssh
Vagrant bare tok seg av å lage en virtuell maskin som kjører Ubuntu 12.04 for deg, og du er nå SSH'd inn i sin ledetekst. Vi kan nå følge Dockers Ubuntu installasjonsanvisninger. Sjekk nettsiden dersom det har skjedd noen endringer siden dette ble skrevet, men mest sannsynlig kan du direkte lime inn følgende kommandoer i terminalen:
# installere backported kjernen sudo apt-get oppdatering sudo apt-get install linux-image-generic-lts-raring linux-headers-generisk-lts-raring # reboot sudo reboot
Du vil bli droppet tilbake til din lokale maskinens spørsmål når VM starter på nytt, så vent et øyeblikk og gjør et annet:
vagrant ssh
... til SSH tilbake i VM. Nå da Dockers forutsetninger er installert, må vi fortsette å installere Docker selv. Lim inn i følgende kommando:
krølle-er https://get.docker.io/ubuntu/ | sudo sh
... som vil ta tak i et enkelt Docker installeringsskript fra Dockers nettsted og kjøre det. Docker skal nå installeres med hell, så la oss begynne å spille med den.
En gang apt-get har avsluttet sin magi, gjør følgende:
sudo Docker run -i -t ubuntu / bin / bash
... for å sjekke og se at installasjonen var vellykket. Hvis det virker, fortsetter Docker å laste ned et Ubuntu Docker-bilde, og etter en tid vil du ende opp med hva som ser ut som en rotprompt. Føl deg fri til å leke for litt, og du vil merke at du er i et miljø som er helt skilt fra din vertsmaskin. Du har sikkert lagt merke til rot og # logg inn ledeteksten. Du kjører som roten brukeren i et nytt virtuelt miljø. Hvis du utsteder en brukere kommando, ser du at de andre brukerne dine ikke lenger er til stede.
Det er verdt å ta et minutt å forklare hva Docker kommandoen du bare skrev, gjorde og hvordan denne magien skjedde.
Accentsconagua
løpe KommandoDockerverktøyet synes å ha tatt mye inspirasjon fra gits kommandolinje grensesnitt og som et resultat, det gjør bruk av subkommandoer. I dette tilfellet løp vi løpe delkommando. De løpe kommandoen krever to argumenter: et bilde og en kommando.
Det er også smart, så hvis (som i dette tilfellet) du ikke har det bildet installert, vil det spørre det sentrale Docker-depotet og laste ned en for deg. Her fortalte vi det å kjøre en ubuntu bilde og informert Docker at den skal starte / Bin / bash inne i bildet. De -t og -Jeg Fortell Docker å tilordne en TTY og kjøre i "Interaktiv modus", med andre ord, for å få deg en ledetekst. Årsaken til dette er at Docker virker litt annerledes enn andre virtualiseringsprogrammer du kanskje er kjent med. Dockerbilder ikke "boot", de løper bare. De bruker den eksisterende Linux-installasjonen, slik at du kan starte et Docker-bilde umiddelbart. På noen måter er Docker nærmere Linux chroot kommandoen enn til mer tradisjonelle virtualiseringsverktøy som VMWare eller VirtualBox.
Det er noen andre viktige forskjeller fra standard virtualiseringsverktøy. La oss gjøre et raskt eksperiment og lage en fil og skrive ut innholdet av det:
ekko Et eksperiment> experiment.txt
Nå når du gjør:
katteksperiment.txt
Det vil gjerne skrive ut:
Et eksperiment
Så langt så bra fungerer vårt dumme eksperiment akkurat som forventet. La oss avslutte Docker og komme tilbake til vår maskinens kommandoprompt:
exit
Hvis du starter om igjen Docker med samme kommando du brukte før:
sudo Docker run -i -t ubuntu / bin / bash
... du vil legge merke til at ting ikke lenger oppfører deg som du ville forvente. Hvis du prøver å katte filen vi opprettet forrige gang, får du en feilmelding:
root @ e97acdf4160c: / # cat experiment.txt cat: experiment.txt: Ingen slik fil eller katalog
Så hva skjer? Endringer i Docker-bilder vedvarer ikke som standard. For å lagre endringene i et Docker-bilde må du begå dem, git stil. Dette kan ta litt å bli vant til, men det er ganske kraftig fordi det betyr at du også kan "forgrene" dem git stil (mer om det senere).
For nå, la oss gjøre noe litt mer nyttig. La oss installere python, Redis og noen få andre verktøy som vi vil bruke til å kjøre vår demo-app snart. Etterpå vil vi begå å fortsette våre endringer. Start en kopi av Docker opp på det nyeste Ubuntu-bildet:
docker -t -i ubuntu / bin / bash
Ubuntu-basen kan ikke inneholde Python, så sjekk om du har en kopi ved å skrive python på spørsmålet. Hvis du får en feilmelding, la oss installere den:
apt-get oppdatering apt-get install python
Så langt så bra. Det er mulig at vi senere vil gjøre andre prosjekter som bruker Python, så la oss gå videre og lagre disse endringene. Åpne en annen kommandoprompt (hvis du bruker Vagrant-installasjonen som anbefales ovenfor, må du vagrant ssh igjen fra en separat spørsmål) og gjør følgende:
docker ps
Du får en liste som nedenfor, av alle Docker-containere som kjører:
ID IMAGE COMMAND CREATED STATUS PORTS 54a11224dae6 ubuntu: 12.04 / bin / bash 6 minutter siden Opp 6 minutter
Nummeret under ID-kolonnen er viktig: dette er IDen til containeren din. Disse er unike, hvis du forlater containeren din og kjører det samme bildet igjen, ser du et nytt nummer der.
Så nå at vi har Python installert, la oss lagre endringene våre. For å gjøre dette bruker du begå kommando som tar to argumenter: beholderen hvis endringer du vil lagre og bildenavnet. Docker-konvensjonen er å bruke en userid etterfulgt av a / og kortnavnet på bildet. Så i dette tilfellet, la oss kalle det Tuts / python. Utsted følgende kommando for å lagre Python-installasjonen, pass på at du erstatter ID-en for containeren fra det siste trinnet
dockerforetak / python
Etter noen sekunder kommer den tilbake med en rekke bokstaver og tall. Dette er IDen til bildet du nettopp har lagret. Du kan kjøre dette bildet når du vil og referere til det enten med dette ID-nummeret eller ved det enklere å huske Tuts / python navn vi tilordnet det.
La oss kjøre en kopi av bildet vi nettopp har laget:
docker løp -t -i tuts / python / bin / bash
På dette tidspunktet bør du ha to terminale vinduer åpne som kjører to separate Docker-økter.
Du vil legge merke til det hvis du skriver python I begge deler vil du ikke få en feilmelding lenger. Prøv å lage en fil i det andre vinduet:
touch / testfil
Bytt nå tilbake til det opprinnelige Docker-vinduet og prøv å se på filen:
katt / testfil
Du får en feilmelding. Dette skyldes at du kjører en helt annen "virtuell maskin" basert på bildet du opprettet med docker commit kommando. Filsystemene dine er helt separate.
Hvis du åpner en annen terminal (igjen, må du løpe vagrant ssh hvis du bruker Vagrant) og gjør følgende:
docker ps
... du vil se det Docker Nå listes to løpende bilder, ikke bare en. Du kan forplikte seg til hver av disse bildene. For å fortsette med git metafor, du jobber nå med to grener og de er fri til å "avvike".
La oss gå videre og lukke det siste vinduet vi åpnet. Hvis du kjører docker ps igjen, det vil nå bare være en ID oppført. Men hva om du vil komme tilbake til en tidligere container? Hvis du skriver inn:
docker ps -a
Docker vil også liste ut alle tidligere containere. Du kan ikke kjøre en container som har gått ut, men du kan bruke tidligere containers ID til å begå nye bilder. Kjører det nye bildet vil da effektivt komme deg tilbake til den tidligere beholderens tilstand.
La oss lukke de nye vinduene vi åpnet og bytte tilbake til terminalen for den første Dockersøkten vi startet. En gang tilbake, gå videre og installer noen flere verktøy for vår lille app. I dette tilfellet må vi installere Python-pakkebehandleren, to Python-moduler for å la Python fungere som en webserver og samhandle med Redis, og selve Redis-serveren.
apt-install install python-pip redis-server pip installer redis flaske
Når disse er ferdig, la oss begå dette bildet. Fra et annet terminalvindu, kjør følgende kommando:
docker ps
... og noter ID og legg det under navnet Tuts / pyredis:
dockerforetak / pyredis
Så vi har nå et Docker-bilde som inneholder de nødvendige verktøyene for å kjøre en liten Python webapp med Redis som fungerer som backend. Hvis du har noen fremtidige prosjekter som vil bruke samme stack, er alt du trenger å gjøre for å få dem startet: docker løp -t-tuts / pyredis / bin / bash og begå når du har lagt til kildekoden din.
Ok, så er vår backend satt opp. Nå for å sette opp selve appen!
Jeg har laget en liten prøveapp som bruker Redis og Python-modulene vi har installert så langt. Appen er ganske enkel, alt det gjør er å vise en liste over Redis-tastene og gir et rudimentært grensesnitt for å legge til og redigere dem. La oss få kildekoden på din vertsmaskin (den vagrant ssh økt) først:
cd git klone https://github.com/nikvdp/tuts-docker.git pyredis
I vertsmaskinens hjemmekatalog har du nå en pyredis mappe som inneholder Python-skriptet vi skal bruke. Så, hvordan går vi om å kopiere denne appen til vårt Docker-bilde?
Vel, Docker har en fin funksjon som lar deg montere en lokal katalog inne i containeren din. La oss kjøre et annet Docker-bilde og montere mappen:
docker kjøre -v ~ / pyredis: / tuts: rw -t -i tuts / pyredis / bin / bash
Dette er akkurat som vår løpe kommandoer fra før, med tillegg av -v parameter.
Denne kommandoen lar deg i virkeligheten dele en mappe mellom Docker og vertsmaskinen din. De :Indikerer stiene å dele. I vårt tilfelle deler vi vår pyredis mappe, lokalisert på ~ / Pyredis på maskinen vår, og monter den på / Tuts inne i Docker-bildet. De rw på slutten er det for "read-write" og betyr at endringer som gjøres på Docker-bildet, også kommer opp på maskinen vår.
På Docker-spørringen kan du nå:
cd / tuts ls
... og se innholdet i ~ / Pyredis mappe på maskinen din.
Denne delen er midlertidig, men hvis du kjører dette Docker-bildet på en annen datamaskin, eller kjøre dette bildet utenom -v alternativet, vil bildet ikke lenger ha tilgang til det. La oss kopiere den til et annet sted inne i selve Docker-bildet:
cp -R / tuts / / pyredis
Siden endringer i Docker-filsystemer er standard som standard, la oss lagre dette til bildet ved å gjøre det igjen docker ps for å få vår container ID og begå våre endringer:
dockerforetak / pyredis
Du vil legge merke til at vi har forpliktet oss til det samme bildenavnet vi har forpliktet oss til sist, Tuts / pyredis. Docker vil oppdatere bildet, og det vil holde en logg over alle endringene dine for deg. Som git, Hvis du søler, kan du gå tilbake til en god versjon bare ved docker kjøremed sin ID For å se historien til et bilde, kan du prøve følgende:
Docker History Tuts / Pyredis
Du ser noe slikt:
ID CREATED CREATED BY tuts / pyredis: siste 17 sekunder siden / bin / bash 4c3712e7443c 25 timer siden / bin / bash ubuntu: 12.10 6 måneder siden / bin / bash 27cf78414709 6 måneder siden
Dette er en historie om alle de forpliktelsene vi har gjort i prosessen med å skape Tuts / pyredis bilde, inkludert de vi har forpliktet oss til forskjellige navn som Tuts / python. Hvis du vil gå tilbake til forpliktelsen rett før vi kopierte vår pyredis app inn / pyredis du kan prøve (endre ID-ene for å matche det du ser):
docker kjøre -t -i 4c3712e7443c / bin / bash
... og du finner det er nei / pyredis katalog.
Så nå har vi alle brikkene på plass. Det neste trinnet er å faktisk kjøre appen fra innsiden av beholderen. Siden vi distribuerer en web-app, skal vi også spesifisere noen måte for å få tilgang til appen over nettet. De løpe kommandoen har fått deg dekket (igjen). Dockers kjørkommando støtter a -p alternativet som lar deg spesifisere hvordan portene skal kartlegges.
Hvis du bruker Vagrant til å kjøre Docker, må du sette opp Vagrant's port forwarding før vi kan gjøre noen meningsfulle tester. Hvis du ikke bruker Vagrant, så bare hopp over dette trinnet.
Hvis du bruker Vagrant for å teste dette, må du sette opp videresending av port, slik at den lokale maskinens nettleser kan få tilgang til porter på Vagrant VM, som igjen vil videresende til Docker-instansens port. Så i vårt tilfelle vil vi sette opp vår lokale maskinens port 9000 for å videresende til Vagrant VM 9000, som igjen videresender til vår Tuts / pyredis Docker-instansens port 8080.
På din lokale maskin, gå tilbake til mappen der du først skrev inn vagrant init. Du finner en tekstfil der det kalles ganske enkelt Vagrantfile. Åpne den i din favoritt tekstredigerer og se etter følgende del:
# Opprett en videresendt portkartlegging som gir tilgang til en bestemt port # i maskinen fra en port på vertsmaskinen. I eksemplet nedenfor vil # tilgang til "localhost: 8080" få tilgang til port 80 på gjestemaskinen. # config.vm.network "forwarded_port", gjest: 80, vert: 8080
Uncomment den endelige linjen og endre portene fra 80 og 8080 til 8080 og 9000. Resultatet skal se slik ut:
# Opprett en videresendt portkartlegging som gir tilgang til en bestemt port # i maskinen fra en port på vertsmaskinen. I eksemplet nedenfor vil # tilgang til "localhost: 8080" få tilgang til port 80 på gjestemaskinen. config.vm.network "forwarded_port", gjest: 8080, vert: 9000
Kjør nå:
vagrant reload
... som vil føre til at Vagrant VM starter på nytt med riktig port fremover. Når dette er fullført, kan du kjøre vagrant ssh igjen og fortsett opplæringen.
Vår lille pyredis app som standard åpner en liten webserver på port 8080. Følgende kommando gir deg tilgang til port 8080 via port 9000 på vertsmaskinen din:
docker kjøre -t-i-9000: 8080 tuts / pyredis / bin / bash
Du får en Docker-rotetekst, så la oss starte vår app:
redis-server 2> & 1> / dev / null & python /pyredis/app.py
Hvis alt går bra, ser du følgende:
Flaske v0.11.6 server starter opp (bruker WSGIRefServer ()) ... Lytte på http: // localhost: 8080 / Hit Ctrl-C for å slutte.
Dette betyr at serveren kjører. På din lokale maskin, brann opp en nettleser og pek på den localhost: 9000 (hvis du gjør denne opplæringen på en ekstern server, så sørg for at du har nettverkstilgang til port 9000 og erstatt lokal vert med adressen til din webserver).
Med litt hell, bør du se hovedskjermbildet for vår lille app. Gå videre og legg til noen få nøkler og endre noen verdier. Dataene skal fortsette. Men hvis du går ut av Docker-spørringen din og starter Docker igjen, blir databasen tom igjen, noe som er noe å huske på hvis du planlegger å være vert for databasen din inne i en Docker-container.
Så dette er alt bra for testing, men målet her er å kunne distribuere appen din. Du vil ikke måtte skrive inn kommandoene for å starte appen manuelt hver gang.
Docker kommer igjen til redning. Når du forplikter deg, kan Docker automatisk lagre litt kjøreinformasjon, for eksempel hvilke porter som skal kartet, og hvilke kommandoer som skal kjøres når bildet starter. På denne måten er alt du trenger å gjøre, å skrive Docker og Docker vil ta vare på resten. Sann containerisering.
For vårt skript har vi bare to kommandoer som skal kjøres ved oppstart:
redis-server 2> & 1> / dev / null & python /pyredis/app.py
Den enkleste måten å gjøre det på er å lage et lite lanseringsskript som kjører disse to kommandoene. La oss starte vår Tuts / pyredis igjen og legg til et lite lanseringsskript (bare kopier og lim inn det nedenfor, i Docker-spørringen):
docker løp -t-tuts / pyredis / bin / bash cat> /pyredis/launch.sh <&1 > / dev / null & #! / bin / sh python /pyredis/app.py EOF chmod + x /pyredis/launch.sh
Dette lagret kommandoene vi bruker til å starte vår Python-server i et lite bash-skript som heter launch.sh og setter kjørbar brikke slik at det er lettere å kjøre.
Nå som skriptet er i bildet med hell, fra en annen terminal, forplikter den slik at den vil fortsette (husk å gjøre en docker ps for å få den nyeste beholderens ID først):
dockerforbindelser / pyrdis
La oss teste dette. Hvis du går ut av Docker-spørringen din og kjører den igjen med følgende kommando, bør du kunne få tilgang til Pyredis web-appen på localhost: 9000, akkurat som forrige gang.
docker løp -t -i -p 8000: 8080 tuts / pyredis / bin / bash /pyredis/launch.sh
Ok, så nå kan vi kjøre vår lille app med en enkelt kommando. Men det er mer! Docker lar deg lagre standard konfigurasjonsinformasjon med dine forpliktelser. På den måten behøver vi ikke å huske å skrive inn portportalisering og starte kommandolinjeinformasjon hver gang, og du kan bare gi et Docker-bilde til noen andre. De kan deretter kjøre det med en enkel docker kjøre og Docker tar vare på resten.
For å konfigurere dette må du passere i noen JSON-informasjon til commit-kommandoen. Det er mange parametere du kan bruke, men for nå skal vi bare bekymre oss om kartlegging av porter og initialiseringsskript. Brann opp din favoritt tekstredigerer og lim inn følgende:
"cmd": ["/ bin / bash", "/pyredis/launch.sh"), "PortSpecs": ["9000: 8080"]
Dette representerer informasjonen vi skrev inn i -p alternativet samt banen til lanseringsskriptet. En viktig ting å merke seg er at for cmd alternativ, vil hvert sted hvor du normalt bruker et mellomrom, faktisk overføres som en egen parameter.
Lagre den JSON-koden til en fil som heter runconfig.json og la oss oppdatere Docker for å bruke den.
docker commit-run = $ (cat runconfig.json) tuts / pyredis
Nå hvis du gjør det:
docker kjøre tuts / pyredis
Du vil se flaske starte opp og du kan få tilgang til appen via nettleseren.
Dockers skapere har opprettet et offentlig register som alle kan skyve og trekke Docker-bilder fra. Dette betyr at distribusjon av den nye appen til en ekstern server er like enkelt som å skyve den til Dockers sentrale register og deretter trekke den fra en server der du har Docker installert.
Dette er ganske greit, så jeg skal henvise til Dockers egen dokumentasjon. Hvis du i stedet vil distribuere privat, så les videre til neste seksjon (er).
Flott, så nå har vi et brukervennlig Docker-bilde som kjører på maskinen din. Det neste trinnet er å distribuere det til en server!
Denne delen er litt komplisert. Dockers distribusjonsmodell er basert på ideen om repositorier. Du kan skyve og trekke Docker-bildene dine til et Docker-arkiv så mye du vil, og forskjellige servere kan alle gjerne trekke forskjellige bilder. Dette er flott, men det er dessverre nødvendig med litt arbeid for å være vert for ditt eget lager. Hvis du er vert for eller oppretter åpen kildekode, kan du bare bruke det offentlige Docker-depotet direkte til å lagre bildene dine. Men hvis du distribuerer proprietær kode, vil du sannsynligvis ikke gjøre det. Dette gir deg to valg:
Den første er enklere, men mister mange av Dockers kjøligere funksjoner, for eksempel å holde historiene til bildene dine og muligheten til å lagre portkartlegging og kjøre konfigurasjon inne i bildet. Hvis dette er viktig for deg, så gå til neste avsnitt for å lære å sette opp ditt eget (private) Docker-depot. Hvis du bare vil kunne distribuere bildene dine til serverne dine, kan du bruke denne metoden.
Det første trinnet er å eksportere beholderen til en .tjære arkivet. Du kan gjøre dette via Docker eksport kommando. For å distribuere eksempelappen vi har brukt i denne opplæringen, ville du gjøre noe slikt:
docker eksport> pyredis.tar
Docker vil sitte og behandle en stund, men etterpå vil du ha en pyredis.tar fil som inneholder bildet du opprettet. Du kan da kopiere pyredis.tar til serveren din og kjøre følgende:
katt pyredis.tar | Docker import -
Docker vil igjen sitte en stund og til slutt spytte ut IDen til det nye bildet det har opprettet. Du kan begå dette til et mer minneverdig navn ved å gjøre dette:
dockerforetak / pyredis
Vår opplæringsapp er nå distribuert, og du kan kjøre den med samme løpekommando som før:
docker løp -t -i -p 8000: 8080 tuts / pyredis / bin / bash /pyredis/launch.sh
Den enklere måten å distribuere appen på er å være vert for ditt eget Docker-depot. Få Docker installert på en maskin og kjør følgende kommando:
docker kjøre -p 5000: 5000 samalba / docker-register
Vent litt for å laste ned bitene, og du bør snart se noen meldinger om å starte enhjørning og oppstart av arbeidere.
Dette betyr at Docker-registeret ditt er oppe (inne i sin egen Docker-beholder), og er tilgjengelig for din lokale maskin i port 5000. Litt mindbøyende, men fantastisk. La oss sette innloggingsinformasjonen først og deretter trykke på Docker-bildet vi opprettet tidligere i opplæringen til vårt nye register. I en ny terminal, kjør følgende
Docker login localhost: 5000
Gå videre og skriv inn brukernavnet, passordet og e-posten du vil bruke med Docker-depotet ditt.
For å presse Tuts / pyredis app inn i repo, må vi først "merke" den med den private repository adressen informasjon som så:
docker tag tuts / pyredis localhost: 5000 / tuts / pyredis
Dette forteller Docker å lage en ny "tag" av Tuts / pyredis og knytte den sammen med repoen som kjører på localhost: 5000. Du kan tenke på denne taggen som dette bildetes navn i depotet. For konsistens har jeg holdt navnene det samme og merket det localhost: 5000 / tuts / pyredis, men dette navnet kan lett være noe helt annet (som localhost: 5000 / pyredis_prod.)
Hvis du kjører docker bilder Nå vil du se at det er et nytt bilde som er oppført med navnet localhost: 5000 / tuts / pyredis. Dockers mekanisme for å spesifisere arkiver er nært knyttet til mekanismen for navngiving (eller merking som Docker setter det), så dette er alt du trenger.
For å skyve bildet vi har opprettet i vårt lager, gjør du bare docker push og fullstendig merket bilde navn (inkludert adressen):
docker push localhost: 5000 / tuts / pyredis
Docker vil koble til lagringsplassen din på localhost: 5000 og begynn å presse endringene dine. Du får se mange meldinger om de forskjellige HTTP-forespørgene som er involvert, som vises i det andre terminalvinduet (den ene som kjører samalba / Docker-registret), og informasjon om opplastingen vil fortsette i denne. Dette vil ta en stund, så du vil kanskje ta en kaffe.
En advarsel, siden Docker-depotet selv kjører inne i en Docker-beholder, må vi forplikte arkivets bilde etter at vi er ferdig med å trykke. Ellers, siden Docker-filsystemet endres, er ephemeral, vil bildet som vi presset til repo, som standard forsvinne så snart vi slår av vår lokale samalba / Docker-registret Dockerbeholder.
For å gjøre dette, gjør det vanlige docker ps for å få IDen til løpingen samalba / Docker-registret beholder og deretter forplikte den til en ny container. Dette er ikke ideelt, hvis du gjør dette i produksjon, vil du ønske å konfigurere Docker-volumer eller bruke -v alternativ fra ovenfor for å fortsette repo-filen direkte til serveren, i stedet for inne i containeren, men det er utenfor omfanget av denne opplæringen.
Nå for den morsomme delen: distribuere vårt nye Docker-bilde på en ny server. Siden dokumentselskapene ikke har noen sikkerhets- eller autentiseringsmekanismer, vil vi gjøre vårt arbeid over sikre SSH-tunneler. Fra den virtuelle maskinen hvor du setter opp Tuts / pyredis opplæringen, ssh inn i produksjonsserveren og videresend port 5000 slik:
ssh-r 5000: localhost: 5000 -l
De -R flagg til ssh betyr at når du kobler til localhost: 5000 På produksjonsserveren vil SSH videresende tilkoblingen tilbake til port 5000 på din virtuelle maskin, som igjen blir videresendt til samalba / Docker-registret container der vår repo lever.
Hvis Docker ikke er installert på denne serveren, fortsett og installer den i henhold til installeringsanvisningene. Når du har Docker kjørt, er implementering av bildet ditt så enkelt som:
dokkingstasjon lokalhost: 5000 / tuts / pyredis
Siden vi opprettet en tunnel via SSH, vil Docker tro at det trekker fra den eksterne serverens lokalehost: 5000, men dette vil faktisk bli tunnelert til ditt lokale VMs lokalehost: 5000, som igjen blir omdirigert til Docker. Gi det litt tid til å laste ned, men når det er gjort, bør du kunne kjøre vår pyredis-app på nøyaktig samme måte som vi kjørte den på den opprinnelige VM, inkludert den lagrede konfigurasjonen og porter:
docker kjøre tuts / pyredis
Så det er grunnlaget for Docker. Med denne informasjonen kan du nå opprette og administrere Docker-bilder, skyve og trekk dem til offentlige og private repos og distribuere dem til separate servere.
Dette er en introduksjonsoppgave, så det er mange Docker-funksjoner som ikke ble dekket her. To av de mest bemerkelsesverdige er Dockerfiles og volumer.
Dockerfiles er tekstfiler som Docker kan kjøre for å initialisere og tilveiebringe Docker-bilder. De kan gjøre prosessen med å lage mange Docker-bilder betydelig raskere, men siden fokuset her handlet om å skape og distribuere ett enkelt bilde, ble de ikke dekket. Hvis du vil lære mer om dem, sjekk ut Dockers egen dokumentasjon.
Den andre funksjonen er volumer. Volumer fungerer litt som de delte mappene vi dekket med -v alternativ, ved at de tillater Docker-beholdere å vedvare sine data. I motsetning til mappedeling med -v, de deler ikke med vertssystemet, men de kan deles mellom bilder. Du kan sjekke ut denne opplæringen for en god introduksjon.
