>> [Musik spiller]
DAVID MALAN: Okay.
Tak så meget for at komme.
Dette er CS50 seminar om Docker, en teknologi, som vi selv og CS50
er begyndt at bruge i et stykke tid nu.
Så mit navn er David Malan, jeg undervise Harvards Introduktion
til datalogi.
For en hel del år, Vi har været at give de studerende
downloades klientsiden virtuelle maskiner
som de gør deres problemer sæt.
At vi nu har skiftet til en Cloud miljø
der faktisk anvender denne teknologi kaldes Docker, således at alle de CS50
studerende har nu deres egne Docker containere
at du snart vil høre om.
>> Desuden er der på CS50 server side klynge, i mange år
vi bruger Amazons Cloud server.
Vi kørte individuel virtuelle maskiner.
Også det har vi begyndt at overgangen til disse ting kaldet Docker containere
således at alle vores applikationer er nu perfekt isoleret fra hinanden.
Så for dette og meget mere, tillad mig at introducere vores venner, Nico og Mano,
fra Docker selv.
NICOLA KABAR: Tak, David.
Hej allesammen.
Mit navn er Nico, og dette er Mano.
Vi er fra Docker.
Vi kommer til at tale om-- hvilket giver jer en intro til Docker,
og forhåbentlig, mod slutningen af denne snak, du kan realisere
hvor meget du kan bruge lægen til oxalat din ansøgning udvikling
og implementering.
>> Så vi kommer til at starte virkelige hurtig med nogle baggrundsoplysninger.
Beskriv hvad Docker handler om.
Hvordan virker det?
Hvordan er det architected?
Jeg vil gøre nogle demoer.
Og Mano bliver beskriver, hvordan du kan bruge Docker
og giver dig specifikke skridt hvordan du kan komme i gang.
>> Jeg ville sætte pris på hvis du fyre kan holde ud for dine spørgsmål i slutningen.
På den måde kunne jeg komme ind dem spørgsmål i hele præsentationen.
Så vi vil forlade nogen tid mod slutningen for spørgsmål.
>> Så bare rigtig hurtig, der har faktisk nogensinde arbejdet på Docker,
ligesom spillet med det?
Awesome.
Afkøle.
Alle tiders.
Så jeg har tænkt mig at starte med nogle historie.
Så tilbage i 90'erne og begyndelsen af ​​2000'erne, dybest set
som web-udviklere, app udviklere, når de gik til at installere et program
det var bundet til bart metal.
Det var en server.
Det var én ansøgning.
>> Traditionelt et eksempel ville være som en LAMP stack,
hvor man faktisk havde til opdrage puljen af ​​ressourcer.
CPU, hukommelse, disk, netværk, installation operativsystem på toppen af ​​det.
Hvis du tjener noget, hvis du faktisk have webserver,
du har brug for noget lignende Apache til at tjene det.
>> Hvis din ansøgning behov database, baghånd,
du ville installere noget som MySQL, og så videre.
Og hvis du har brug for køretid, PHPs og PHP Python arbejde var der.
Og så vi faktisk havde til tage de skridt i orden
at få din ansøgning op at køre.
>> Hvis du har brug for mere computerkraft, du dybest set måtte kalde din Ops fyr
eller gal at gå og rack op en ny stykke hardware, tilslut den,
og du er nødt til at gentage dem, processer igen og igen.
Så denne proces var relativt dyre.
Var helt sikkert meget langsom.
>> Det var ineffektivt.
Og i mange tilfælde, din hardware blev underudnyttet.
Så i slutningen af ​​90'erne og begyndelsen af ​​2000'erne, hardware virtualisering kom på tværs.
Og som du kan se her i billede, dybest set, hvad de gjorde
indvindes puljen af gratis hardware ressourcer
og art tjente dem til de øvre lag,
i dette tilfælde en gæst operativsystem.
>> Og hele idéen om virtuelle maskiner kom på tværs
og der virkelig hjalp Cloud computing, som vi kender det i dag.
Så hvad det betød er dig kan køre flere VM'er, der
betød flere stakke, multipel program på en samme fysiske maskine.
>> Dette afgjort hjulpet med hastighed på udrulning.
Bestemt med udgifter.
Du behøver ikke at gå og tilbringe energi, tid og ressourcer til rack
flere servere for at komme til mere Compute.
Og hastigheden af ​​faktisk bringe disse ressourcer op er meget hurtigere.
Alle tiders.
>> Så vi løste sult i verden, ikke?
Nej, ikke rigtigt.
Så virtualisering så meget som det er faktisk hjulpet, løse problemet,
det faktisk indført en masse udfordringer.
Hypervisor afgjort indført en masse kompleksitet,
håndtering dem, der ligger til grund pulje af ressourcer.
>> Det er tungere i den forstand, at før du havde et enkelt operativsystem, som
er ligesom tre, fire shows på disken.
Nu, hvis du har 10 maskiner på en enkelt hardware
du nødt til at formere sig, at antallet af maskiner.
Det er helt sikkert mere dyre i en vis forstand du stadig
nødt til at få licens til den virtualiseringsteknologi
hvis det ikke er open source.
>> Men, lad os ikke tage hele kredit fra virtualisering.
Fordi det, der skete, er der er en masse stakke og masser af software
teknologier, der er blevet aktiveret af, hvor hurtigt du var i stand til at få
til ressourcer med Cloud boom.
>> Så i dag en enkelt app eller service kan bruge en af ​​følgende runtime
eller databaser.
PHP, Python, MySQL, Redis, whatnot.
Så der er en masse kompleksitet på denne antal stakke til rent faktisk at bringe
en enkelt ydelse.
Og sammen med det, du havde en masse underliggende ressourcer eller infrastruktur
typer til at teste installere og dybest set tage produktionen disse ansøgninger
at du udvikler.
>> Især fordi dine hold har vokset arbejder på disse apps,
der er en masse kompleksitet og udfordringer
der blev bragt til at den cycle-- dybest ansøgning
udvikling cyklus, er faktisk lykkedes.
Så det faktum, at din ansøgning arbejder lokalt på din lokale VM
garanterer ikke, at din kollega kommer til at forvente de samme resultater.
>> Og når operationer holdet er involveret i at tage, hvad du har
og implementering det i produktionen skala, også er der ingen garanti
at der rent faktisk kommer til at ske.
Så dette efterlader os med en virkelig big-- en masse spørgsmålstegn,
en masse udfordringer faktisk står ligeledes tilbage i de dage.
Og det mindede os om shippingbranchen.
>> Så skibsindustrien havde en masse varer,
som du kan se på venstre kanten.
Og på den højre side, der er en masse, dybest set,
måder at sende disse varer.
Og hvad sker som et par folk kom sammen og sagde:
vi nødt til at standardisere, hvordan vi faktisk sende disse varer.
Og boom, har du intermodal shipping container.
>> Så de blev enige om de mest almindelige størrelser for beholderen.
Hvordan man håndterer dem.
Hvad præcis metode, du har brug for at indlæse dem og losse dem.
Og derfor, som virkelig hjalp shippingbranchen.
Nu mere end 90% fokus transporteres globalt bruger disse containere.
Og det helt sikkert falder de omkostninger samt
de på grund af forsendelse skader.
>> Så vi tager den samme model, og vi anvende de to app udvikling software
arkitektur i den forstand, at containere
tog virtualisering et niveau op.
Så i stedet for at gøre det på hardware-niveau,
blev det mere af et operativsystem systemniveau virtualisering.
>> Og vi gør det ved at give hver ansøgning i sin egen let,
isoleret, runnable, og bærbare, vigtigst af alt,
en måde at pakke rent faktisk alt det, den har brug for at køre.
Overalt det kan køres.
Så uanset om du kører den på lokal dev miljø, din produktion
miljø, din iscenesættelse eller undersøgelser.
Uanset hvad der ligger til grund infrastrukturen er der,
du havde en funktionel arbejder app.
>> Så det er præcis, hvad grunden containere gør på dette problem.
De løse det ved emballage, på en sådan måde,
at det kan garantere, at den bliver anvendt succes uanset hvor den lever.
Så hvis du vil lignende, Bob er det stadig OK.
Hvis du forveksles med, hvad jeg siger, Jeg har tænkt mig at være uddybe det.
>> Så hvordan gør Docker selv passer ind i dette billede?
Så Docker er en åben platform mulighed for nemt at understrege let,
at bygge skibet, køre, letvægts bærbare self
tilstrækkelige app containere overalt.
Så hvis du tager noget fra dette tale, skal du tage følgende.
>> Hvis du har din app kørende lokalt, og du har udviklet det
i at bruge Docker platformen, forventer det med held skal sættes ind.
Ligegyldigt hvad er den underliggende infrastruktur.
Så hvis du har en Docker beholder og det virker, så
så længe der er en Docker motor på den anden side--
Hvis din operation infrastruktur er ved hjælp af en Cloud, om det
er AWS, eller Googles eller Microsoft, eller et af de offentlige skyer,
eller din egen Cloud, eller dine åbne stak Cloud, eller dit lokale miljø.
>> Hvis du har en motor kører, betyder
det vil være held indsat der.
Det kommer til at køre nøjagtig den samme adfærd
som du architected det skal være.
Så hvis vi ser at-- jeg har tænkt mig gå gennem hvad der faktisk
er i de vigtigste komponenter i Docker.
>> Så Engine er kernen i Docker.
Det er hjernens.
Det orkestrerer bygning, shipping, og implementering og styring
selve beholderne.
Jeg vil grave i, hvad Engine gør i flere detaljer i et sekund.
Dybest set, fordi Doctor blev bygget omkring klientserveren arkitekturer,
så med henblik på at interagere med Motor du har brug for en form for en klient.
>> Billeder er skabelonerne i hvilke beholdere er bygget fra.
Så billeder er dybest set bare statiske filer.
Skabeloner og containere er faktisk, hvad der er
kører på runtime, der afsoner din ansøgning
eller gøre noget med dataene.
>> Registry behandles som et problem med hvordan du rent faktisk distribuere billeder.
Så hvis du har brug for at dele et billede at du har arbejdet på din kollega
eller til den ops team, du bruge det ved hjælp Registry.
Du kan downloade en open source version af det, at Docker arbejdede på
og åbne fremskaffede.
>> Eller du kan bruge Docker hjælp, som er Cloud-version
at skubbe og trække billeder derude.
Det er en kæmpe ting.
Fordi der er en enorm økosystem omkring Docker, og det er
virkelig stærkt udnytte navet.
>> Så for at opsummere her, det er sådan det minimalistisk Docker workflow klient.
Du interagerer med værten, i dette tilfælde er det de Docker dæmoner.
Det er det samme som Engine.
Du gør kommandoer som Docker bygge, træk, køre.
Og motoren selv går og gør disse ting.
>> Så enten det interagerer med Registry til at trække disse billeder
og lagene af billederne.
Uanset om du ønsker at installere, køre beholdere, dræbe dem, smide dem ned,
whatnot.
Så dette opsummerer arbejdsgangen af alle disse komponenter.
>> Så hvis du tager alle komponent af sig selv.
Så Engine, det er bare en dæmon.
Det vil slags spille det for at støtte det på Linux, fordi det gør
kræver visse Linux kerne funktioner.
Men Windows arbejder på at gøre det samme.
Det er meningen, der skal støttes af Windows Server 2016.
>> Så igen, det ansvar med Motoren er at, eller skal, bygge billeder.
Træk billederne fra Docker Hub eller din egen Registry.
Hvis du er færdig med disse billeder eller du oprette en ny billeder,
du kan skubbe dem tilbage til registreringsdatabasen at distribuere dem til andre hold.
>> Og forsøger at indeholde det lokalt og styre containere livscyklus
lokalt.
Det er bygget op omkring HTTP REST API.
Så teknisk set kan du skriv din egen klient
så længe det bruger HTTP, som er en meget standard mekanisme til at tale med motor
og en masse andre tjenester.
Og du kan se fra her, at uanset
af, hvad infrastruktur er, så længe du can-- alle
du behøver, er et operativsystem systemet, Linux specifikt.
>> Og du kan installere Docker Engine oven i købet, og har det kørende
og det orkestrerer, dybest set, alle disse app en, to,
og tre er faktiske beholdere.
Så det er Engine.
Som jeg nævnte tidligere, fordi du har brug for at interagere med motor,
der er kunden.
>> Men faktisk, når du installerer Docker, det skibe med det.
Så det bliver installeret, så det er en enkelt binær.
Og du kan gøre lokale opkald til din Docker Engine.
Eller fjerntliggende opkald til fjerntliggende motorer.
Det gør brug HTTP, som Jeg nævnte tidligere.
Der er en GUI klient kaldet Kitematic fra Docker.
Og der er absolut en masse andre folk
der er ved at opbygge en masse GUI, der dybest set gennemføre
nogle HTTP opkald til at tale med motor.
>> Blot nogle eksempler kommandoer.
Hvis du gør Docker versionen, ville det vise dig klientversionen samt
serveren version.
Hvis du gør Docker info det vil fortælle dig alle de oplysninger,
om hvor mange beholdere der kører eller oprettet, hvor mange billeder, du har,
og så videre og så videre.
>> Her har jeg, i siden sidste boks, jeg har Læge køre.
Så det er sådan jeg er faktisk skabe container.
Og jeg giver det til echo Hello World og sove for en anden og whatnot.
Og du kan se den resultat. Så det er i gang.
Og ligner Linux ps, kan du se alle de processer, og i dette tilfælde,
alle de kørende containere.
Denne ens henvise tilbage til containeren jeg lige har oprettet.
>> Så det er virkelig vigtigt, fordi, lignende, kan det være en smule forvirrende.
Så billeder er det kun læse samling af filer, ikke?
De er, hvad vores container er baseret på.
Men de er kun skrivebeskyttet.
Så du starter med en base billede.
Det har tendens til at efterligne OS-lignende, så Ubuntu, CentOS, whatnot basen billede.
Og så skal du begynde at bygge oven på at visse lag, der vil gøre op
din ende billede, i slutningen resultere her.
>> Og hver af disse lag skal have en forælder billede
som den refererer, når det faktisk ønsker at skabe.
De er uforanderlige, i den forstand, at fordi de er read-only,
du kan faktisk ikke foretage ændringer i dem.
Du kan bruge dem til at skabe en container fra et billede, som
vil kalde alle de efterfølgende nødvendige billeder under den.
>> Du kan foretage ændringer til et andet lag,
det er en omskrivning lag jeg vil tale om i en anden.
Men hver af disse lag er aldrig ændret.
Dybest set billeder bruge noget kaldet EU File System, UFS.
Og der er forskellige opbevaring backends, der udnytter denne teknologi.
Og hvad det betyder er, at det samler forskellige filsystemer
at få dem til at ligne en.
>> Så du kan faktisk, fra en ansøgning perspektiv
du har en top af en visning, der viser alle de forskellige filsystem nødvendig
til det pågældende program til at køre.
Men de er faktisk, om dette, de er faktisk i separate steder
og bliver udnyttet af andre beholdere samt.
>> Så som du kan se i her, at hvis vi starter med daemon billede
som en base billedet og derefter vi gå ind og tilføje [? Emacs?]
og så det er en anden lag.
Og derefter tilføje Apache.
Det er en anden lag.
Og så bruger vi den beholderen fra det.
Hver af disse billeder, hver af disse lag,
adskiller sig og kan være genbruges af andre beholdere.
>> Hvis man ser på containere selv, de er en eller anden måde ligesom VM-lignende,
men ikke behandles på samme tid.
Så har de ikke, teknisk, den fuld operativsystem under dem.
De bruger den fælles kerne af værtens operativsystem.
Og de bygger oven i købet.
De efterligner, hvordan de ser ud.
De efterligner deres rod-fil Systemet af operativsystemet.
Men de faktisk ikke replikere.
>> Så i stedet for at have uforanderlige lag, det sidste lag, som er beholderen
selv, det er en read-write lag.
Det kører også processerne af din ansøgning.
Og det afhænger af de underliggende lag.
Hver container er skabt ud fra et billede.
Og at billedet kan være en enkelt lag eller flerlags billede.
>> Og jeg vil gerne bemærke her at Docker stærkt bruger,
eller er baseret på Copy-On-Write mekanisme.
Så det, faktisk, hvis du ikke er at foretage ændringer til beholderen,
Det kommer ikke til at tage ekstra plads.
Så det er dybest set, hvordan du opsummere en Copy-On-Write.
Det kommer til at helt sikkert fremskynde boot tid til beholderen.
For hvis du ikke gør ændringer i beholderen,
det er at udnytte, hvad der er allerede er der.
>> Så, hvordan det rent faktisk virker.
En del af det er ligesom, lige nu, er det udnytter mindst to centrale kerne
funktioner.
Og det er det dybest set skabte dette niveau af isolation
for selve beholderne.
Disse funktioner er namespaces og cgroups.
Så namespaces er en måde at skabe isolerede ressourcer,
så inden selve beholderen, kun du kan se visse ressourcer.
Såsom netværk grænseflade eller bestemte brugere eller whatnot.
>> Og dem er kun synlige og kun tilgængelige inden i beholderen.
Cgroup på den anden side grænser hvordan du bruger disse ressourcer.
CPU, hukommelse og disk.
Når du kan gå i, jeg betyder de er faktisk
funktioner, der blev udviklet by-- de er en del af Linux-kernen.
Så de var ikke genopfundet af eller genskabes ved Docker.
Docker bruger dem.
>> Hvad Læge virkelig her er faktisk det
Orchestrated skabe namespaces for hver beholder
og skabe de cgroups så det er latterligt nemt at oprette containere
bruge disse funktioner.
Selvfølgelig, som jeg beskrev tidligere, Union File Systems og Copy-On-Skriv virkelig
hjælpe hastighed og disken brug af containere.
>> Og når du får din hænder omkring Docker,
du kommer til at se, hvor hurtigt det er at faktisk spin op containere og tåre
dem ned.
Så hvis du kan spørge, hvordan kan du faktisk bygge billeder?
Vi bygger billeder ved en proces med at skabe containere og foretage ændringer, ændre
dem, og forpligter dem til at blive et billede.
>> Så det er en kylling og æg henvisning her,
fordi alle beholdere kommer fra billeder og billeder kommer
fra begået beholdere, for det meste.
Der er tre muligheder at skabe billeder.
Jeg har tænkt mig at beskrive den første og sidste.
Du kan enten manuelt gå og køre beholderen
og foretage disse ændringer, ligesom du ville gøre på en hvilken som helst VM
eller ethvert operativsystem, f.eks som installerer nye binære filer,
tilføjer filsystemer, og whatnot.
>> Og så afslutter, som du kan se deroppe.
Jeg afslutter min beholder.
Og så er jeg gør Docker begå.
Og jeg begår det.
Du kan se, at antallet her er bare en UUID, eller den første 12
bits af UUID.
Eller bytes af UUID.
Og så er jeg kalder det mit billede.
Så nu Docker tager sig af optage alt, hvad jeg gjorde det
og skabe den nye billede baseret på det.
>> Jeg har ikke tænkt mig at tale om tarball, men der er en måde du kan få en enkelt,
skabe en enkelt, eller lave en enkelt lag billedet ved hjælp tarballs.
Hvad jeg har tænkt mig at tale om dette og hvad der er mest brugt i dag,
er Dockerfile.
Hvilket er teknisk den første trin automatiseres ved Docker selv.
Så Dockerfiles er ting, som du er kommer til at se i en masse GitHub repoer
i dag.
Det er dybest set bare en tekstfil, der beskriver
nøjagtigt, hvordan man opbygger et billede.
>> Og for hver linje, er det faktisk skaber beholderen, udfører denne linje,
tilsagn om, at beholderen i en nyt billede, og du, dybest set,
bruge det til alle efterfølgende operationer indtil du kommer til det sidste billede.
Hvilket er dybest set den ende mål her, i slutningen.
Og efter du exec-- efter du skriv din Dockerfile, som
er rent i tekst, du gør en Docker opbygge og navnet på billedet.
>> Og du peger på, at det er hvor Dockerfile er på.
Og du kan forvente at se mit billede som et billede, som du har lokalt.
Så det er bare en visuel eksempel på, hvad der foregår.
Du starter med en base billede.
Du kører det i en beholder, der ændrer ikke basen selve billedet.
Men i stedet skaber en omskrive lag oven på det
hvor du foretage ændringerne, hvor du begår
og du gentage processen, indtil du kommer til dit endelige billede.
>> Og ved at gøre det, hver anden build proces kan bruge de samme lag
og same-- grundlæggende Docker cacher disse lag.
Så hvis jeg gør nøjagtig de samme proces, men i stedet for at installere PHP,
Jeg installere Python.
Det kommer til at bruge Apache og Ubuntu.
Så på den måde du udnytter din disk.
Det er at udnytte cachen og tilgængelige billeder der.
>> Den sidste brik er Registry, som er, hvordan du distribuerer dine billeder.
Og som jeg nævnte tidligere, der er en Cloud-version af det,
som er Docker Hub.
Du kan gå og udforske en masse, dybest set
Det er en offentlig SAS produkt, kan du stadig har private billeder,
men der er en masse af offentlige billeder.
Det er faktisk ubegrænset, kan du skubbe ubegrænset offentlige billeder der.
Og dette er, hvordan du kan samarbejde med dit team.
>> Du kan bare pege dem på dig repo og de kan hente det eller dit billede
og de kan hente det.
Så nok med snak.
Hvem ønsker at se nogle demoer reelle hurtig?
Okay.
Så her jeg har.
Ca du fyre se min skærm?
Okay.
>> Så jeg har Docker kører her, så jeg kan kontrollere it's-- Dette er den version
af Docker, der kører.
Kan gøre Docker info.
Check alle oplysninger om, hvor mange billeder, som de har, og så videre og så videre.
Docker PS, der er ikke noget kørende.
Sammenkædet dem.
>> Så det første, jeg vil gøre, er show dig, hvordan du nemt kan køre en container.
Så skønheden om Læge køre, hvis det rent faktisk
ikke finde et billede lokalt, som standard den taler til Doctor Hub
og forsøger at finde det der og downloads det for dig.
Så det indeholder en Docker pull-kommando, naturligt.
>> Så hvis jeg gør en Docker køre, hej-verden.
Så først det går at forsøge at finde den.
Ellers som du kan se her, det kunne ikke finde det lokalt.
Lige nu er det bare trukket to lag der gjorde, at billede og jeg kørte det.
Den hello-verden er bare dybest set udgange, hvad du har gjort.
Så dette er den nemmeste, én de nemmeste eksempler.
Så faktisk jeg bare løb og opsagt beholderen virkelig hurtig.
>> Hvis jeg ønsker at run-- og af den måde, hvis Jeg ønsker at tid, der, bare så du ved,
dette er, hvor lang tid det tager at faktisk spin op og indeholder det.
Vi måler det i millisekunder.
Så du kan se, hvor meget det kan faktisk hjælpe dig ikke kun i test,
men også selv implementering.
Så det er en hurtig bemærkning om det.
Den næste ting jeg kommer til at gøre er faktisk
køre et billede jeg har allerede forberedt.
Så Docker løb.
-d er blot et flag for at fortælle den til at køre i baggrunden.
Og -p tildeler visse havne.
Fordi som standard, den beholdere isoleres,
så du er nødt til at specificere præcis hvordan det kan få adgang til dem.
Og i dette tilfælde, jeg fortæller Docker at kortlægge en tilfældig port på værten
til en specificeret port inden selve beholderen.
Og det er dybest set, hvor image-- forhåbentlig er den rigtige.
>> Så det gør parallelle downloads hver af disse lag, som du kan se her.
Det er af lagene gør slutningen billede, jeg byggede.
Det kommer til at tage en anden.
Og voila.
>> Så nu hvis jeg gør en havnearbejder ps, jeg bør se noget, der kører.
Jeg skulle se ID, billedet at dette var det baseret ud,
og kommandoen, der blev henrettet.
Og hvordan man kan få adgang til det er dybest set du går til denne port.
Så jeg har tænkt mig at gå at-- dette er jeg kører det på AWS.
Jeg har tænkt mig at gå til 32.769.
Ups.
Og her går vi.
>> Så dette er faktisk bare en web-tjeneste, der viser
som beholder det bliver serveret fra.
Så du kan se, at det er fra beholderen a9f.
Og her er dette den navn på beholderen.
Så du fyre kan se, hvor hurtigt det var faktisk ikke blot trække, men også
implementere denne beholder.
>> Nu det næste skridt er at undersøge Dockerfiles
og hvordan vi rent faktisk kan bygge nye billeder.
Jeg er bare kommer til at gå få klon, en Prøven Dockerfile bygger på den tidligere
diagram, den ene til Apache og PHP.
Forhåbentlig Jeg husker min repo.
>> Så jeg har mit repository lige nu.
Og du kommer til at se dette meget faktisk.
Jeg har ikke installeret træ.
>> Så dybest set du kommer til at se, hvordan din kildekode dokumentation omkring
det, og derefter en Dockerfile på hvordan man rent faktisk pakke det.
Så det er blot et udsnit PHP der ekko hej CS50.
>> Så hvis jeg vil køre det, Jeg vil gøre havnearbeider build.
Jeg er nødt til at bygge det første.
Jeg har tænkt mig at nævne det demo_cs50.
Og du har brug for et tag til det også.
Så lad os kalde det V1 dot.
Så som jeg beskrev tidligere, hvad jeg laver i dag
er jeg fortæller Docker at gå brug at-- faktisk, undskyld, min dårlige.
Vi har ikke tage et kig på Dockerfile selv.
Så de eneste ting i her, er index.php samt readme-fil
og en Dockerfile.
>> Så hvis du tager et kig på den Dockerfile, så det er
meget lig, hvad I beskrevet tidligere.
Det er bare en flok trin, Docker udfører
ved at oprette og rive ned containere og [? tælle?] dem i et billede.
>> Og dybest set kan du see-- [uhørligt] det her--
men det er fra den lokale repo.
Det kommer til at gå ud og grab index.php.
Så det er den eneste kilde kode, er faktisk en del af din ansøgning.
Alt dette er grundlæggende operativsystem VVS,
få de rigtige pakker og Apache, og PHP, og whatnot.
Men det er faktisk at tage index.php og forpligte den ind i beholderen,
i billedet.
>> Så hvis du gå videre og køre kommando ved at gøre følgende,
det er going-- faktisk, dette kan tage lidt.
Forhåbentlig er det ikke tager for lang tid.
Så du kan se trinene.
Og jeg vil opfordre dig til at gå hjem i dag og prøve det.
Og Mano vil beskrive hvordan netop du gør det.
Men det er virkelig dejligt at se præcis hvad der sker bag kulisserne.
Men det er latterligt let at bygge billeder og implementere dem ved hjælp Docker.
>> Det tager lidt længere tid end jeg havde forventet.
>> Lad os se hvad der sker, når du-- afkøles.
Så som du kan se, hver af disse trin repræsentere linjer i Dockerfile.
Og det viser sig her, at det succes bygget dette billede.
>> Så hvis jeg gør Docker billeder, vil jeg se alle de billeder, jeg har lokalt.
Og en af ​​dem kaldes min brugernavn, og navnet på billedet,
og tag representing-- hovedsageligt er det en version tag.
>> Så nu, hvis jeg ønsker at køre det, jeg gør havnearbeider køre.
Og jeg vil bare gøre en -d -P. Gør v1.
Så jeg kan se nu, at jeg har to beholdere kører, som jeg bare
oprettet, og goddag Docker en, jeg fik sidst.
>> Og du kan se her, at det tildelt det en anden port.
Så hvis jeg går til den samme IP, men tildeler det en anden port-- forhåbentlig jeg ikke.
Så nu er det program at jeg bare indsat.
>> Hvis jeg ønsker at foretage ændringer, jeg kan hurtigt redigere kildekoden
og gøre følgende.
Lad os gøre goddag Harvard.
Så nu, hvad der sker at ske, er, at jeg er
kommer til at tagge det med en anderledes version-- åh,
dette ikke guy-- tagge det med en anden version.
Og du kommer til at see-- gør du fyre forventer
det at tage den samme mængde tid at bygge det en anden gang, eller ej?
Okay, og nogen ved hvorfor?
Tal.
>> PUBLIKUM: [uhørligt]
>> NICOLA KABAR: Det er dybest set vi ændres kun ét af de senere trin.
Og derfor er det kommer til at bruge cache og bruge hver af disse lag.
Og det er virkelig nogle af de killer funktioner i Docker
er, hvordan det rent faktisk udnytter og genanvendelser tager over
din disk for det samme nøjagtige stykker information.
>> Så hvis vi gør det samme, det tog kun et par sekunder.
Hvis vi ønsker at redeploy-- så nu Jeg skal have tre containere.
Men dette er ved at blive serveret på til-- syv én.
Så nu er det den tredje beholder.
Alle forstår hvad jeg lige gjorde her?
>> Så nu, hvis du ønsker at dele denne beholder rigtig hurtig med dine venner,
du kan bare gøre havnearbejder skubbe navn af beholderen, forhåbentlig.
Så nu er det kommer til at skubbe det at-- Jeg er ikke logget ind her.
Undskyld.
Men jeg har ikke tænkt mig fejlfinding nu.
Men dybest set, at en kommando er bare at gå op skubbe det.
Og du vil være i stand til se det, hvis du går til Docker Hub
Og du logger ind, er du kommer til at være i stand til at se det.
Og så kan du bare pege hvem der foregår
til at bruge billedet til at gå og trække det.
Og de kan bruge det.
>> Med det, forhåbentlig I form af påvist
hvor nemt det er at arbejde med Docker.
Og jeg er bare at gå til give det tilbage til Mano.
Og han vil tage den herfra.
>> MANO MÆRKER: Okay tak, tak Nico.
Hvad så?
Så en af ​​de ting, jeg ønskede at gøre er sat sammen
hvorfor det er en important-- Derfor Docker og hvorfor
beholdere er en sådan vigtig ny udvikling,
en ny måde faktisk gør software.
>> Og før jeg gør det, jeg har tænkt mig at bare indføre et par statistik.
Jeg har ikke tænkt mig at læse alle disse.
Men det viser dig en masse om, hvordan populær dette er i samfundet.
De centrale Docker teknologier er open source.
Så det er Docker Engine, Compose, Swarm, en masse andre ting
er alle open source.
Og vi har, hvad gjorde jeg sige, 1.300 bidragydere.
Du ser nu, hvis man ser på den Antallet af ledige stillinger, sidste gang
vi kiggede, det var omkring 43.000 job åbninger specifikt at nævne
fortrolighed med Docker.
Hundredvis af millioner af billeder har blevet hentet fra Docker Hub.
Og, ja, meget mere store statistik.
>> For dem, der er nysgerrige, det var oprindeligt skrevet i Python
og derefter omskrevet til Go.
Og det har kun været åbne source-- det er kun
blevet frigivet for omkring 2 og 1/2 år, Hvilket betyder, at i 2 og 1/2 år,
vi har set en enorm mængde vækst og betydning
af denne i samfundet.
Og så jeg ønsker at tale lidt om hvorfor.
>> Så bare for at gentage nogle af Nico vigtigste punkter, Docker er hurtig.
Den er bærbar.
Det er reproducerbar.
Og det sætter en standard miljø.
>> Og Hvad-- dette er min crappy udrydde monolitter slide-- hvad
det er at hjælpe folk gør, som en masse af software-industrien
begyndt at gøre i begyndelsen af ​​2000'erne, er i bevægelse
fra disse monolitisk single applikationer
hvor hver afhængighed skulle være testet før hele app havde
skal sættes, hvilket kunne betyde en hjemmeside
kun fik indsat en gang hver tredje måned, eller mere,
til en langt mere tjeneste orienteret arkitektur
eller komponentopdelt anden type Anvendelsesområde arkitektur.
Og så lade disse slags arkitekturer
at drage fordel af Docker til at køre i disse tre
vigtigste områder for udvikling, som er udviklingen skriver din faktiske kode,
teste din kode, og implementering det.
>> Så hvorfor er dette vigtigt?
Hvis du er en-- lad mig give et eksempel.
Hvis du er en hjemmeside enhed udvikler, du er
at udvikle en hjemmeside, der er baseret på database, David produceret over her.
Undskyld David, Jeg ringer dig ud.
Hvis du ønskede at implementere det hele, ville du
nødt til at vente i en traditionel monolitisk softwareudvikling
miljø, ville du nødt til at vente indtil han var færdig med databasen
før du rent faktisk kan gøre eventuelle ændringer på dit websted.
Du er nødt til at omfordele den hele ansøgningen til at gøre det.
>> Og hvad Docker hjælper du gør, er hver person, arbejde med forskellige komponenter
og opdatere dem, når de går, bare at gøre sikker på, at grænsefladerne forbliver de samme.
Så hvad det har gjort er det flyttet folk
fra at gøre disse massive monolitisk Architected software,
indsat hver måned til en kontinuerlig integration og løbende udvikling
miljø.
>> Nu er dette ikke er unik for Docker, men Docker gør det så meget lettere,
hvilket betyder, at du er dybest set konstant implementering.
Vi taler med virksomheder, der er implementering offentlige modstående applikationer
tusindvis af gange om dagen, fordi de ser værdien i bare at gøre
små ændringer, og så længe som det løber gennem testene,
lade det gå ud i produktion.
Nico var altid fortæller mig tidligere, at i mange miljøer,
standard livscyklus container måles i sekunder,
mens en virtuel maskine kunne måles i måneder.
>> Jeg ønskede at tage en lille dreje her, fordi jeg er
på en uddannelsesinstitution.
Jeg ønskede at give et eksempel på, hvordan dette virker i en pædagogisk forskning
situation.
Så der er en organisation kaldet bioboxes.
Bioboxes gør DNA analyse for forskere.
>> Nu, hvad de fandt var, at når en researcher-- og det er ikke
skyld i en bestemt researcher-- men når
en forsker indsat en algoritme til at analysere,
På en bestemt måde, en DNA-prøve, de ville skrive software,
offentliggøre, at måske til GitHub eller et andet sted,
og så de blev gjort.
>> Nå problemet var, at det ikke nødvendigvis var reproducerbar.
Fordi for at forstå software,
de ville blive sat op til nøjagtige udviklingsmiljø
at denne forsker anvendes, normalt deres bærbare computer, eller en server, eller en data-
center, som de brugte.
Og følgelig, det var meget vanskeligt at reproducere forskningsresultater, når
analysere DNA-prøver at se på ting som incidence--
sammenligne forekomsten af ​​hjerteanfald baseret på visse gener er til stede,
for eksempel, eller kræftrisiko, eller nogen af ​​de andre slags ting.
>> Så hvad de gjorde i stedet var de begyndte at skabe containere.
Og du kan gå til bioboxes.org, det er en stor organisation.
Og hvad de gør, er de producerer containere baseret på forskning.
Og så når nogen sender i deres stikprøve, kan de køre den.
Og det har alle miljøet nødvendige for at køre denne algoritme
og producere resultater.
Og de er konstateringen af, at de er langt mere sandsynligt og meget
hurtigere kunne returnere resultater til mennesker.
>> Og i virkeligheden, er, hvad folk gør kører deres egen analyse på DNA,
at fremsende disse på bioboxes og derefter biobox bare tager dataene,
kører den mod de mange forskellige forskellige beholdere
at se forskellige resultater baseret på forskellige forskning.
Så det er en meget kraftfuld måde, hvorpå forskere
kan gøre en enkelt forekomst, der tillader andre mennesker til at forsøge at gengive
resultaterne.
>> Så hvordan kan du komme i gang?
Vi er godt understøttet på Linux.
Så hvis du vil installere noget på Linux,
du bruger din standard pakke manager til at installere.
Hvis du bruger en Debian, er det apt get.
CentOS er yum.
Fedora Red Hat er rpm-- jeg ikke huske.
Anyway, det hele er der.
Vi støtter en lang række af Linux-distributioner.
Du kan tjekke dem ud.
>> Vi har også muligheder, så du kunne køre på Mac eller Windows.
Nu Nico nævnte tidligere, at var det kun understøttet på Linux.
Det er sandt, fordi det har brug for en Linux-kernen.
Men, kan du køre i en virtuel maskine.
Og hvad Docker Toolbox gør, som du kan downloade,
det giver dig den virtuelle maskine.
>> Så bare en hurtig 48 andet, tror jeg, downloade.
Du skal bare søge på Docker Værktøjskasse, downloade den til Mac,
og denne del er Kurset drønede op, fordi der
ønsker at se et download-signal?
Standard Mac installation, og så er du
kommer til at se Jerome sætte i sit password.
Det er meget spændende.
Og så er det installerer en hel masse værktøjer.
Og især vil det installere en kommandolinje.
Og så kunne man se Jerome teste sine billeder.
>> Og derefter er baseret på dette, du kan se, at YouTube
mener, at Nico er interesseret i Star Wars, The Jimmy Kimmel show,
og jeg tror, ​​Ellen.
Jeg tror, ​​at sidste er et klip fra en Ellen show.
>> Så Docker Toolbox selv kommer med mere end blot Docker Machine.
Så Docker Machine er de ting, der hjælper
du oprette en virtuel maskine på din Windows
eller Mac-- din Windows-boks eller din Mac box-- og hjælper dig med at gøre provisionering,
>> Men det kommer også med Swarm og Compose,
der er designet til at hjælpe dig med at gøre store skala implementeringer af din ansøgning.
Så hvis du ønsker at administrere klynger af knudepunkter,
klynger af containere, Komponer og Swarm er vejen at gå om det.
>> Og selvfølgelig det kommer med Docker Motor og Kitematic,
som er denne desktop GUI.
Jeg bør også nævne Docker Registry, som ikke er inkluderet i værktøjskassen,
men det er en måde for dig at køre din egen registre over Docker billeder som Docker
Hub, men du kan også bare bruge Docker Hub som en måde at gøre det.
>> Og, plot twist, du ser det kører i en container.
Og det er, hvordan vi er distribuere vores dias.
Hele denne præsentation er faktisk en HTML slide dæk.
Og det kører i et container, som du kan få by--
>> NICOLA KABAR: Ja, så det er kører fuld tid på min Max.
Og jeg præsentere fra det.
Og du bare gøre Docker efter du installerer din værktøjskasse.
Du kan bare gøre en havnearbejder køre og få det, og bruge dias.
>> MANO MÆRKNING: Og det er det.
Så vi takker jer alle for at komme.
Og vi er glade for at besvare spørgsmål.
Jeg bør nævne før nogen blade der er T-shirts derovre.
Ked nogen, der holder øje dette på Livestream eller video,
men vi har Docker T-shirts derovre.
Og vi ved Docker studerende, og i min erfaring,
professorer også, ligesom gratis tøj.
>> Så tak alle for at komme ud.
Og følg os på Twitter hvis du vil, eller ikke.
Jeg er ligeglad.
Følg også Docker på Twitter.
Det er også interessant.
Og så det er det.
Docker.com.
Tak.
>> [BIFALD]