[MUSIC SPILLE] DAVID MALAN: All right. Tusen takk for at du kom. Dette er CS50 seminar om Docker, en teknologi som vi selv og CS50 har begynt å bruke i noen tid nå. Så mitt navn er David Malan, jeg undervise Harvard Introduksjon til Computer Science. For ganske mange år, vi har vært å gi elevene nedlastbar klient-side virtuelle maskiner der de gjør sine problemer sett. At vi nå har gått over til en Cloud miljø som faktisk bruker denne teknologien kalt Docker, slik at all CS50 studenter har nå sin egne Docker containere at du snart høre om. 

Videre på CS50 server sidegruppe, i mange år vi bruker Amazons Cloud server. Vi kjørte individuell virtuelle maskiner. Det også, har vi begynt å gå over til disse tingene kalt Docker beholdere slik at alle våre programmer er nå helt isolert fra hverandre. Så for dette og mer, la meg presentere våre venner, Nico og Mano, fra Docker selv. NICOLA Kabar: Takk, David. Hei alle sammen. Mitt navn er Nico og dette er Mano. Vi er fra Docker. Vi kommer til å snakke om-- til gi dere en intro til Docker, og forhåpentligvis mot slutten av denne talen kan du realisere hvor mye du kan bruke legen til oksalat din applikasjonsutvikling og distribusjon. 

Så skal vi begynne real rask med litt bakgrunnsinformasjon. Beskriv hva Docker handler om. Hvordan fungerer det? Hvordan er det bygd? Jeg skal gjøre noen demoer. Og Mano kommer til å være som beskriver hvordan du kan bruke Docker og gir deg konkrete skritt hvordan du kan komme i gang. 

Jeg ville sette pris på om dere kan holde off for dine spørsmål mot slutten. På den måten kan jeg bli adressering dem spørsmål gjennom hele presentasjonen. Så vi skal la litt tid mot slutten for spørsmål. 

Så bare virkelig rask, som har faktisk noen gang jobbet på Docker, som spilte med det? Awesome. Kjølig. Flott. Så, jeg kommer til å starte med litt historie. Så tilbake på 90-tallet og tidlige 2000-tallet, i utgangspunktet som webutviklere, app utviklere, da de gikk for å distribuere et program det var knyttet til bart metall. Det var én server. Det var ett program. 

Tradisjonelt et eksempel ville være som en LAMP stack, hvor du faktisk måtte få opp pool av ressurser. CPU, minne, disk, nettverk, installasjon operativsystem på toppen av det. Hvis du serverer noe, hvis du faktisk har web server, du trenger noe som Apache å tjene. 

Hvis søknaden trenger database, backhand, du ville installere noe som MySQL, og så videre. Og hvis du trenger det kjøring, PHPs og PHP Python arbeid var der. Og så måtte vi faktisk ta disse trinnene i rekkefølge å få din søknad oppe og går. 

Hvis du trenger mer datakraft, du utgangspunktet måtte ringe Ops fyr eller gal å gå og samle opp en ny stykke maskinvare, koble den, og du må gjenta de prosesser og om igjen. Så denne prosessen var forholdsvis kostbart. Var definitivt veldig treg. 

Det var ineffektive. Og i mange tilfeller, din hardware ble underutnyttet. Så, på slutten av 90-tallet og begynnelsen av 2000-tallet, maskinvarevirtualisering kom over. Og som du kan se her i bilde, i utgangspunktet hva de gjorde er abstrahert pool av gratis hardware ressurser og hva slags servert dem til de øvre lag, i dette tilfellet, en gjest-operativsystem. 

Og hele ideen om virtuelle maskiner kom over og som virkelig hjalp Cloud databehandling slik vi kjenner den i dag. Så hva det betydde er du kan kjøre flere virtuelle maskiner, som mente flere stabler, multippel applikasjon på en samme fysiske maskin. 

Dette definitivt hjulpet med Hastigheten på applikasjons. Definitivt med utgifter. Du trenger ikke å gå og bruke energi, tid og ressurser til rack flere servere for å få til mer beregne. Og hastigheten på faktisk bringe de ressurser up er mye raskere. Flott. 

Så vi løste sult i verden, ikke sant? Nei egentlig ikke. Så, virtualisering så mye som det er faktisk hjulpet, løse problemet, det faktisk introdusert en rekke utfordringer. Hypervisoren definitivt innført en masse av kompleksitet håndtering av de underliggende pool av ressurser. 

Det er tyngre i den forstand at før du hadde et enkelt operativsystem som er som tre, fire konserter på disk. Nå, hvis du har 10 maskiner på en enkelt maskinvare du må multipliserer det med antall maskiner. Det er definitivt mer dyrt på en måte du fortsatt må få lisens for virtualiseringsteknologi hvis det ikke er åpen kildekode. 

Men, la oss ikke ta alle kreditt fra virtualisering. Fordi det som skjedde er at det er en masse stabler og massevis av programvare teknologier som ble aktivert av hvor fort du kunne få til ressurser med Cloud boom. 

Så, i dag en eneste app eller tjeneste kan bruke noen av følgende runtimes eller databaser. PHP, Python, MySQL, Redis, whatnot. Så det er mye av kompleksiteten på dette antall stabler å faktisk få opp en enkelt tjeneste. Og sammen med det, hadde du mye underliggende ressurser eller infrastruktur typer å teste distribuere og i utgangspunktet ta til produksjon disse programmene at du utvikler. 

Særlig ettersom teamene har vokst jobber med disse appene, det er mye av kompleksitet og utfordringer som ble tatt for å sikre at den cycle-- utgangspunktet søknad utviklingen syklus, er faktisk vellykket. Så det faktum at din søknad arbeider lokalt på din lokale VM garanterer ikke at kollegaen din kommer til å forvente de samme resultatene. 

Og når driftsteam er involvert i å ta det du har og distribuere den i produksjon skala, også er det ingen garanti at det er faktisk kommer til å skje. Så dette etterlater oss med en virkelig big-- mye spørsmålstegn, en rekke utfordringer faktisk møtt på samme måte tilbake i dagene. Og det minnet oss om shippingindustrien. 

Så skipsfarten hadde mye varer, som du kan se på venstre side. Og på høyre side, det er mye av, i utgangspunktet, måter å sende disse varene. Og hva skjer med venner folk kom sammen og sa: vi trenger å standardisere hvordan vi faktisk sende disse varene. Og boom, har du intermodal container. 

Så ble de enige om det meste vanligste størrelsene for beholderen. Hvordan man skal håndtere dem. Hva nøyaktig metode du trenger å laste dem og losse dem. Og derfor, som virkelig hjulpet shippingindustrien. Nå mer enn 90% fokus transportert globalt bruker slike containere. Og som definitivt reduserer utgifter samt skader på grunn av frakt. 

Så vi tar den samme modellen og vi gjelder de to app utviklingsprogramvare arkitektur, i den forstand at containerization tok virtualisering opp ett nivå. Så i stedet for å gjøre det på maskinvarenivå, Det ble mer av en drifts systemnivå virtualisering. 

Og vi gjør det ved å gi hver anvendelse i sin egen lette, isolert, kjørbar, og bærbar, viktigst, en måte å faktisk pakke alt som den trenger for å kjøre. Anywhere det kan kjøres. Så uansett om du kjører den på lokal dev miljø, produksjons miljø, din iscenesettelse eller testing. Uansett hva som ligger til grunn Infrastrukturen er der, du hadde en funksjonell arbeids app. 

Så det er akkurat det i utgangspunktet containere gjør på dette problemet. De løse det ved å emballasje på en slik måte det at det kan garantere at det er utplassert vellykket uansett hvor den lever. Så hvis du kommer lignende, Bob det er fortsatt OK. Hvis du er forvirret med hva jeg sier, Jeg kommer til å bli utdype det. 

Så hvordan Docker selv passer inn i dette bildet? Så Docker er en åpen plattform for enkelt å legge vekt lett, å bygge skip, løpe, lett bærbar selv tilstrekkelige app containere hvor som helst. Så hvis du tar noe fra denne snakke, kan du ta følgende. 

Hvis du har din app kjører lokalt, og du utviklet det i å bruke Docker plattformen, forventer det å være vellykket utplassert. Uansett hva som er underliggende infrastruktur. Så hvis du har en Docker container og det fungerer, så så lenge det finnes en Docker Motoren på den andre side-- hvis driften infrastruktur bruker noen Cloud, enten det er AWS, eller Googles eller Microsoft, eller noen av de offentlige Clouds, eller din egen Cloud, eller åpne bunken Cloud, eller ditt lokale miljø. 

Hvis du har en motor løping, det betyr det kommer til å være vellykket utplassert der. Det kommer til å være i gang nøyaktig samme atferd som du bygd den skal være. Så hvis vi ser at-- jeg kommer til å gå gjennom hva som faktisk er i de viktigste komponentene i Docker. 

Så Engine er i kjernen av Docker. Det er hjernens. Det orkestrerer bygning, shipping, og distribuere og administrere beholderne selv. Jeg skal grave i hva Engine gjør i flere detaljer i et sekund. I utgangspunktet, fordi Doctor ble bygget rundt klientserverarkitekturer, så for å samhandle med Motor du trenger noen form for en klient. 

Bildene er malene i som beholdere er bygget fra. Så bilder er i utgangspunktet bare statiske filer. Maler og beholdere er faktisk hva som er kjører under kjøring som tjener din søknad eller gjøre noe med dataene. 

Registry er adressert som et problem av hvordan du faktisk distribuere bilder. Så hvis du trenger å dele et bilde at du jobbet på din kollega eller til ops team, du bruke den ved hjelp av registeret. Du kan laste ned en åpen kildekode versjon av det som Docker jobbet på og åpne hentet. 

Eller du kan bruke Docker hjelp, som er den Cloud versjon å dytte og dra bilder der ute. Det er en stor ting. Fordi det er en stor økosystem rundt Docker og det er virkelig tungt utnytte navet. 

Så for å oppsummere her, dette er hvordan minimalistisk Docker arbeidsflyt klient. Du samhandler med verten, i dette tilfellet er det de Docker demoner. Det er det samme som Engine. Du gjør kommandoer som Docker bygge, trekke, løpe. Og selve motoren går og gjør de tingene. 

Så enten det samhandler med Registeret for å trekke disse bildene og lagene av bildene. Enten om du ønsker å distribuere, kjøre containere, drepe dem, kaste dem ned, whatnot. Så dette oppsummerer arbeidsflyten av alle disse komponentene. 

Så hvis du tar hver komponent av seg selv. Så Engine, det er bare en daemon. Det vil slags spille det for å støtte det på Linux fordi den gjør krever visse Linux kernel funksjoner. Men Windows fungerer på å gjøre det samme. Det er ment å bli støttet av Windows Server 2 016. 

Så, igjen, ansvar med Motoren er til, eller skal, bygge bilder. Trekk bildene fra Docker Hub eller din egen registeret. Hvis du er ferdig med disse bildene eller du oppretter en nye bilder, du kan presse dem tilbake til register å distribuere dem til andre lag. 

Og prøver å inneholde det lokalt og administrere containere livssyklus lokalt. Det er bygget rundt HTTP REST API. Så teknisk mulig skriv din egen klient så lenge som den bruker HTTP, noe som er en meget standard mekanisme for å snakke med Engine og en rekke andre tjenester. Og du kan se fra her at uansett av det infrastrukturen er, så lenge du can-- alle du trenger er en drifts system, Linux spesielt. 

Og du kan installere Docker Engine på toppen av det og la det kjøre og det arrangerer, i utgangspunktet, alle disse app en, to, og tre er faktiske containere. Så det er Engine. Som jeg nevnte tidligere fordi du trenger å samhandle med Engine, det er klienten. 

Men egentlig når du installerer Docker, den leveres med det. Så det blir installert, så det er en enkel binær. Og du kan gjøre lokale samtaler til Docker Engine. Eller eksterne samtaler til eksterne motorer. Det bruker HTTP, som Jeg nevnte tidligere. Det er en GUI klient kalt Kitematic fra Docker. Og det er definitivt en masse andre folk som bygger mye GUI som i utgangspunktet gjennomføre noen HTTP kaller å snakke med Engine. 

Bare noen eksempler på kommandoer. Hvis du gjør Docker versjon, det ville viser klientversjonen samt serverversjonen. Hvis du gjør Docker info vil det fortelle deg all informasjon om hvor mange containere kjører eller laget, hvor mange bilder du har, og så videre og så videre. 

Her har jeg, i nest siste boksen, jeg har Doctor løp. Så det er sånn jeg er faktisk skape container. Og jeg gir det til ekko Hello World og sove for en andre og whatnot. Og du kan se resultat. Så det er pågående. Og i likhet med Linux ps, kan du se alle prosesser, og i dette tilfellet alle de løpende beholdere. Denne er henvise tilbake til beholderen jeg nettopp opprettet. 

Så dette er veldig viktig fordi, lignende, kan det være litt forvirrende. Så bildene er skrivebeskyttet samling av filer, ikke sant? De er det vår beholder er basert på. Men de er bare beskyttet. Så du starter med en base bilde. Det har en tendens til å etterligne OS-lignende, så Ubuntu, CentOS, whatnot basisbildet. Og så kan du begynne å bygge på toppen av at det enkelte lag, som vil utgjøre sluttbildet, sluttresultatet her. 

Og hvert av disse lagene bør ha en moderbilde som den refererer til når det faktisk ønsker å skape. De er uforanderlig, i den forstand at fordi de er skrivebeskyttet, du kan faktisk ikke gjøre endringer i dem. Du kan bruke dem til å lage en container fra et bilde, som vil kalle all den påfølgende nødvendige bildene under den. 

Du kan gjøre endringer til et annet lag, det er en omskriving lag jeg skal snakke om i et sekund. Men hvert av disse lagene blir aldri endret. I utgangspunktet bilder bruke noe kalt Union File System, UFS. Og det er forskjellige lagrings backends som utnytter denne teknologien. Og hva det betyr er at det bringer sammen forskjellige filsystemer å gjøre dem ser ut som en. 

Så du kan faktisk, fra et program perspektiv, du har en topp av en visning som viser alle de forskjellige filsystem nødvendig for programmet å kjøre. Men de er faktisk, på dette, de er faktisk i separate steder og blir utnyttet av andre beholdere i tillegg. 

Så som du kan se her at hvis vi begynner med daemon bilde som base bilde, og deretter vi gå inn og legge til [? emacs?] og så er det et annet lag. Og deretter legge til Apache. Det er et annet lag. Og da vi tilbringer beholdere fra det. Hver av disse bildene, hvert av disse lagene, er forskjellig og kan være gjenbrukes av andre beholdere. 

Hvis du ser på containere selv, de er liksom som VM-aktig, men ikke behandlet på samme tid. Så, har de ikke, teknisk sett, den komplett operativsystem under dem. De bruker den eneste kernel av vertsoperativsystemet. Og de bygger på toppen av det. De etterligner i hvordan de ser ut. De etterligne sin rot fil system av operativsystemet. Men de faktisk ikke replikere. 

Så i stedet for å ha uforanderlige lag, det siste laget som er beholderen seg selv, det er en lese-skrive lag. Som kjører også prosessene av søknaden din. Og det avhenger av de underliggende lag. Hver container er opprettet fra et bilde. Og at bildet kan være et enkelt lag eller flerlags bilde. 

Og jeg ønsker å merke seg her at Docker bruker tungt, eller er basert på Kopier-On-Write mekanisme. Slik at, faktisk, hvis du ikke er å gjøre endringer i beholderen, det er ikke til å ta ekstra plass. Så det er i utgangspunktet hvordan du oppsummere en Copy-On-Write. Det kommer til å definitivt fremskynde oppstartstiden for beholderen. Fordi hvis du ikke gjør endringer i beholderen, det er å utnytte det som allerede er der. 

Så, hvordan det faktisk fungerer. En del av det er, akkurat nå, det anvender minst to nøkkel-kjernen egenskaper. Og det er stort sett det laget at graden av isolasjon for beholderne selv. Disse funksjonene er navnerom og cgroups. Så navnerom er en måte å skape isolerte ressurser, slik at inne i beholderen selv, bare du kan se visse ressurser. Slik som nettverksgrensesnitt eller noen brukere eller whatnot. 

Og de er bare synlige og bare tilgjengelig inne i beholderen. Cgroup på den andre siden grenser hvordan du bruker disse ressursene. CPU, minne og disk. Når du kan gå inn, jeg mener de er faktisk funksjoner som ble utviklet by-- de er en del av Linux-kjernen. Slik at de ikke ble gjenoppfunnet av eller gjenskapt av Docker. Docker bruker dem. 

Hva Doctor virkelig gjorde her er faktisk det orkestrert skaper navnerom for hver container og skape cgroups slik at det er latterlig enkelt å lage beholdere ved hjelp av disse funksjonene. Selvfølgelig, som jeg beskrev tidligere, Union Filsystemer og Kopier-On-Skriv virkelig hjelpe hastigheten og skiven utnyttelse av beholdere. 

Og når du får din hendene rundt Docker, du kommer til å se hvor fort det er å faktisk spinner opp containere og tåre dem ned. Så, hvis du kan spørre, hvordan kan du faktisk bygge bilder? Vi bygger bilder ved en prosess med å lage containere og gjøre endringer, endring dem, og forplikter dem til å bli et bilde. 

Så det er en kylling og egg referanse her, fordi alle containere kommer fra bilder og bilder kommer fra begått containere, for det meste. Det er tre alternativer for å lage bilder. Jeg kommer til å beskrive den første og siste. Du kan enten manuelt gå og kjøre container og gjøre disse endringene, som du ville gjort på en hvilken som helst VM eller ethvert operativsystem, f.eks som installerer nye binærfiler, legge filsystemer, og whatnot. 

Og så du går ut, som du kan se der oppe. Jeg avslutter min container. Og så jeg gjør Docker begå. Og jeg forplikter det. Du kan se at antall her er bare en UUID, eller den første 12 biter av UUID. Eller byte av UUID. Og så skal jeg kalle det mitt bilde. Så nå Docker tar vare på innspilling alt jeg gjorde det og skape nye image basert på det. 

Jeg kommer ikke til å snakke om tarball, men det er en måte du kan få et enkelt, lage et enkelt, eller lage en enkelt lag bilde ved hjelp tarballs. Hva jeg kommer til å snakke om dette og hva som er mest brukt i dag, er Dockerfile. Som er teknisk den første trinn automatiseres ved Docker selv. Så Dockerfiles er ting som du er kommer til å se i en rekke GitHub repos i dag. Det er i utgangspunktet bare en tekstfil som beskriver nøyaktig hvordan å bygge et bilde. 

Og for hver linje, det faktisk skaper beholderen, utfører den linjen begår at beholderen til et nytt bilde, og du, i utgangspunktet, bruke den for alle påfølgende operasjoner til du kommer til det siste bildet. Som er utgangspunktet ende mål her, slutten. Og etter at du exec-- etter at du skriv din Dockerfile, som er rent i teksten, gjør du en Docker bygge og navnet på bildet. 

Og du peker på at det er hvor Dockerfile er på. Og du kan forvente å se mitt bilde som et bilde som du har lokalt. Så det er bare en visuell eksempel på hva som foregår. Du starter med en base bilde. Du kjører det inn i en container som endrer ikke basen bildet selv. Men i stedet skaper en omskrive lag på toppen av det der du gjør endringene der du forplikte og du gjenta prosessen til du kommer til det endelige bildet. 

Og ved å gjøre det, annenhver build Fremgangsmåten kan bruke de samme lagene og same-- utgangspunktet Docker bufrer disse lagene. Slik at hvis jeg gjør det samme nøyaktige prosess, men i stedet for å installere PHP, Jeg installerer Python. Det kommer til å bruke Apache og Ubuntu. Slik at måten du benytter din disk. Det utnytte cache og tilgjengelige bilder der. 

Den siste delen er registret som er hvordan du distribuerer bildene dine. Og, som jeg nevnte tidligere, det er en Cloud versjon av den, som er Docker Hub. Du kan gå og utforske en masse, i utgangspunktet det er en offentlig SAS produkt som du kan fortsatt ha private bilder, men det er mye av offentlige bilder. Det er faktisk ubegrenset, du kan presse ubegrenset offentlige bilder der. Og dette er hvordan du kan samarbeide med teamet ditt. 

Du kan bare peke dem på deg repo og de kan laste den ned eller ditt bilde og de kan laste den ned. Så nok med snakk. Hvem ønsker å se noen demoer virkelig rask? Greit. Så her jeg har. Ca dere se skjermen min? Greit. 

Så jeg har Docker kjører her, så jeg kan sjekke it's-- Dette er versjonen av Docker som kjører. Kan gjøre Docker info. Sjekk all informasjon om hvor mange bilder de har, og så videre og så videre. Docker PS, det er ikke noe løping. Sammenkjedet de. 

Så det første jeg vil gjøre er å vise deg hvordan du enkelt kan kjøre en container. Så skjønnheten om Doctor løp, hvis det faktisk finner ikke et bilde lokalt, som standard den snakker til Doctor Hub og prøver å finne det der og nedlastinger det for deg. Så det inkluderer en Docker trekke kommando, naturligvis. 

Så hvis jeg gjør en Docker løp, hallo-verden. Så, først det kommer for å prøve å finne den. Ellers, som du kan se her, det ikke kunne finne den lokalt. Akkurat nå er det bare trukket to lag som gjorde det bildet og jeg kjørte den. Hello-world er bare utgangspunktet utganger, hva du har gjort. Så dette er den enkleste, en av de enkleste eksemplene. Så egentlig jeg bare løp og avsluttet beholderen virkelig rask. 

Hvis jeg ønsker å run-- og forresten, hvis Jeg ønsker å tid det, bare så du vet, Dette er hvor lang tid det tar å faktisk spinner opp og inneholder det. Vi måler det i millisekunder. Så du kan se hvor mye dette kan faktisk hjelpe deg ikke bare i testing, men også enda distribusjon. Så det er en rask kommentar på det. Det neste jeg er kommer til å gjøre er faktisk kjøre et bilde jeg har allerede forberedt. Så Docker løp. -d er bare et flagg for å fortelle det å kjøre i bakgrunnen. Og -p tildeler visse porter. Fordi som standard, den containere er isolert, så må du angi nøyaktig hvordan det kan få tilgang til dem. Og i dette tilfellet, jeg forteller Docker å kartlegge en tilfeldig port på verten til en spesifisert port innen selve beholderen. Og det er i utgangspunktet der image-- forhåpentligvis dette er den rette. 

Så det gjør parallelle nedlastinger hver av disse lagene som du kan se her. De er av sjiktene gjør slutten bilde som jeg bygget. Det kommer til å ta et sekund. Og voila. 

Så nå hvis jeg gjør en havnearbeider ps, skal jeg ser noe som er i gang. Jeg burde se ID, bildet at dette det var basert på, og kommandoen som ble utført. Og hvordan du kan få tilgang til det er utgangspunktet du gå til denne porten. Så jeg kommer til å gå to-- dette er jeg kjører den på AWS. Jeg kommer til å gå til 32 769. Oops. Og her går vi. 

Så dette er faktisk bare en web-tjeneste som viser som beholder det blir servert fra. Så du kan se at det er fra container a9f. Og her er dette navn på beholderen. Så dere kan se hvor raskt det var å faktisk ikke bare trekke, men også distribuere denne beholderen. 

Nå er neste skritt er å se inn Dockerfiles og hvordan vi kan faktisk bygge nye bilder. Jeg skal bare gå få klone, en PRØVE Dockerfile basert på tidligere diagram, den ene til Apache og PHP. Forhåpentligvis Jeg husker min repo. 

Så jeg har min depotet akkurat nå. Og du kommer til å se dette mye faktisk. Jeg visste ikke installere treet. 

Så i utgangspunktet du kommer til å se hvordan kildekoden dokumentasjon rundt det, og deretter en Dockerfile på hvordan du faktisk pakke det. Så det er bare et utvalg PHP som reflekterer hallo CS50. 

Så hvis jeg ønsker å kjøre den, Jeg skal gjøre Docker bygge. Jeg har til å bygge det første. Jeg kommer til å nevne det demo_cs50. Og trenger du en kode til den også. Så la oss kalle det V1 dot. Så som jeg beskrev tidligere, hva jeg gjør i dag er jeg forteller Docker å gå bruk at-- faktisk, sorry, my bad. Vi fikk ikke se på Dockerfile selv. Så de eneste ting i her er index.php samt readme-fil og en Dockerfile. 

Så hvis du tar en titt på den Dockerfile, så det er svært likt det Jeg beskrev tidligere. Det er bare en haug med trinn som Docker Utfører ved å skape og å rive ned beholdere og [? telle?] dem inn i et bilde. 

Og i utgangspunktet du kan see-- [uhørbart] det her-- men dette er fra den lokale repo. Det kommer til å gå og hente index.php. Så det er den eneste kildekoden som er faktisk en del av søknaden din. Alt dette er i utgangspunktet operativsystem avløp, få de riktige pakkene og Apache og PHP, og whatnot. Men dette er faktisk tar index.php og forplikter det inn i beholderen, inn i bildet. 

Så hvis du går videre og kjør kommando ved å gjøre følgende, det er going-- faktisk, dette kan ta litt. Forhåpentligvis tar det ikke for lang. Så du kan se trinnene. Og jeg oppfordrer deg til å gå hjem i dag og prøve den. Og Mano vil beskrive hvordan akkurat du gjør det. Men det er virkelig flott å se nøyaktig hva som skjer bak kulissene. Men det er latterlig enkelt å bygge bilder og distribuere dem ved hjelp Docker. 

Det tar litt lenger enn jeg forventet. 

La oss se hva som skjer når you-- kjølig. Så som du kan se, hver av disse trinnene representere linjer i Dockerfile. Og det viser her at det lykkes bygget dette bildet. 

Så hvis jeg gjør Docker bilder, kommer jeg til å se alle bildene som jeg har lokalt. Og en av dem heter min brukernavn, og navnet på bildet, og tag representing-- hovedsak er det en versjon tag. 

Så nå hvis jeg ønsker å kjøre det gjør jeg docker løp. Og jeg vil bare gjøre en -d -P. Gjør v1. Så jeg kan se nå at jeg har to beholdere kjører, en som jeg bare opprettet og hei Docker en som jeg fikk sist. 

Og du kan se her at det tildelt det en annen port. Så hvis jeg går til den samme IP, men tildele den en annen port-- forhåpentligvis gjorde jeg ikke. Så nå er søknad at jeg bare utplassert. 

Hvis jeg ønsker å gjøre endringer, jeg kan raskt endre kildekoden og gjøre følgende. La oss gjøre hallo Harvard. Så nå hva som skjer til å skje er at jeg er kommer til å merke det med en annerledes version-- oh, ikke dette guy-- merke det med en annen versjon. Og du kommer til å see-- gjør dere forvente det å ta samme mengde tid å bygge det en gang eller ikke? Greit, og noen vet hvorfor? Snakk ut. 

PUBLIKUM: [uhørbart] 

NICOLA Kabar: Det er i utgangspunktet vi bare endre en av de senere trinn. Og derfor det kommer til å bruke den cache og bruke hver av disse lagene. Og det er virkelig noen av de killer-funksjoner av Docker er hvordan det faktisk benytter og gjenbruker overtar disken for det samme eksakte opplysninger. 

Så hvis vi gjør det samme, det tok bare et par sekunder. Hvis vi ønsker å redeploy-- så nå Jeg bør ha tre beholdere. Men dette blir servert på the-- sju én. Så nå er det tredje container. Alle forstår hva jeg nettopp gjorde her? 

Så nå hvis du ønsker å dele dette container virkelig rask med dine venner, du kan bare gjøre docker presse navn på beholderen, forhåpentligvis. Så nå kommer det til å skyve den to-- jeg ikke logget på her. Beklager for det. Men jeg kommer ikke til å feilsøke dette nå. Men i utgangspunktet at en kommando er bare å gå opp presse den. Og du kommer til å være i stand til å se den hvis du går til Docker Hub Og du logger deg på, er du skal være i stand til å se det. Og da kan du bare peke den som kommer å bruke det bildet til å gå og trekke den. Og de kan bruke det. 

Med det forhåpentligvis Jeg slags demonstrert hvor lett det er å jobbe med Docker. Og jeg skal bare gi den tilbake til Mano. Og han kommer til å ta det herfra. 

MANO MERKER: All right takk, takk Nico. Hva så? Så en av de tingene jeg ønsket å gjøre er å sette sammen hvorfor dette er en important-- hvorfor Docker og hvorfor containere er en slik viktig utvikling, en ny måte for å faktisk gjøre programvare. 

Og før jeg gjør det, kommer jeg til å bare innføre noen statistikk. Jeg har ikke tenkt å lese alle disse. Men dette viser deg mye om hvordan populært dette er i samfunnet. Kjerne Docker teknologier er åpen kildekode. Så det er Docker Engine, Compose, Swarm, en haug med andre ting er all åpen kildekode. Og vi har, hva gjorde jeg si, 1300 bidragsytere. Du ser nå, hvis du ser på antall ledige stillinger, siste gang vi så, var det ca 43000 jobb åpninger spesielt nevne fortrolighet med Docker. Hundrevis av millioner av bilder har blitt lastet ned fra Docker Hub. Og, vel, mye mer store statistikk. 

For de som er nysgjerrige, det ble opprinnelig skrevet i Python og deretter omskrevet til Go. Og det er bare vært åpne source-- det er bare blitt utgitt for ca 2 og 1/2 år, Hvilket betyr at i 2 og 1/2 år, Vi har sett en enorm mengde av vekst og viktighet av dette i samfunnet. Og så ønsker jeg å snakke litt om hvorfor. 

Så bare for å gjenta noen av Nico viktige punkter, er Docker fort. Det er bærbare. Det er reproduserbar. Og det setter opp en standard miljø. 

Og what-- dette er min crappy utrydde monolitter slide-- hva det er å hjelpe mennesker gjør, som mye av programvareindustrien begynte å gjøre i tidlige 2000-tallet, er i bevegelse fra disse monolittiske enkeltprogrammer hvor hver avhengighet måtte være testet før hele programmet hadde skal settes ut, hvilken kan bety en nettside bare fikk utplassert en gang hver tredje måned, eller mer, til en mye mer tjeneste orientert arkitektur eller komponent annen type av applikasjonsarkitektur. Og så la disse slags arkitekturer som kan dra nytte av Docker å kjøre i disse tre viktigste utviklingsområder, som er utvikling skriver selve koden, teste koden din, og distribuere det. 

Så hvorfor er dette viktig? Hvis du er a-- la meg gi et eksempel. Hvis du er en nettside Enheten utvikler, er du utvikle et nettsted som er basert på database som David produsert over her. Sorry David, jeg ringer deg ut. Hvis du ønsker å distribuere hele greia, ville du nødt til å vente i henhold til en tradisjonell monolittisk programvareutvikling miljø, vil du være nødt til å vente før han var ferdig med databasen før du kan faktisk gjøre eventuelle endringer på nettstedet. Du må omplassere den Hele programmet for å gjøre det. 

Og hva Docker hjelper deg å gjøre er hver person arbeid på ulike komponenter og oppdatere dem som de går, bare å gjøre sikker på at grensesnittene forbli den samme. Så hva det har gjort er det flyttet folk fra å gjøre disse massive monolittisk bygd for programvare som utplassert hver måned til en kontinuerlig integrasjon og kontinuerlig utvikling miljø. 

Nå er dette ikke unikt for Docker, men Docker gjør det så mye enklere, noe som betyr at du er i utgangspunktet stadig distribusjon. Vi snakker med bedrifter som er distribusjon av offentlige klednings applikasjoner tusenvis av ganger om dagen fordi de ser verdien i å bare gjøre små endringer, og så lenge som det går gjennom testene la det gå ut i produksjon. Nico var alltid fortelle meg tidligere at i mange miljøer, standard livssyklus Beholderen er målt i sekunder, mens en virtuell maskin kan måles i måneder. 

Jeg ønsket å ta en liten snu her fordi jeg er ved en utdanningsinstitusjon. Jeg ønsket å gi et eksempel på hvordan dette fungerer i en pedagogisk forskning situasjon. Så det er en organisasjon kalt bioboxes. Bioboxes gjør DNA analyse for forskere. 

Nå hva de fant, var at når en researcher-- og dette er ikke feil av en bestemt researcher-- men når forsker utplassert en algoritme for å analysere, På en bestemt måte, en DNA-prøve, de ville skrive programvaren, publisere det, kanskje til GitHub eller et annet sted, og deretter ble de ferdig. 

Vel problemet var at det var ikke nødvendigvis reproduserbar. Fordi for å forstå programvaren, de ville bli satt opp for eksakt utviklingsmiljø som at forskeren brukt, vanligvis sin laptop, eller en server, eller en data sentrere at de brukte. Og derfor var det svært vanskelig å gjengi forskningsresultater når analysere DNA-prøver for å se på ting som incidence-- sammenligne forekomsten av hjerteinfarkt basert på visse gener er til stede, for eksempel, eller kreftrisiko, eller noen av de andre typer ting. 

Så hva de gjorde i stedet var de begynte å lage beholdere. Og du kan gå til bioboxes.org, det er en stor organisasjon. Og hva de gjør er at de produserer containere basert på forskning. Og så når noen sender i sin prøve, kan de kjøre den. Og det har hele miljøet som trengs for å kjøre denne algoritmen og produsere resultatene. Og de opplever at de er mye mer sannsynlig og mye raskere i stand til å returnere resultatene til folk. 

Og faktisk, er hva folk gjør kjører sin egen analyse på DNA, sending som i å bioboxes, og deretter Biobox tar bare dataene, går det mot variasjon forskjellige containere å se forskjellige resultater basert på annen forskning. Så det er en veldig kraftig Måten forskerne kan gjøre en enkelt forekomst som gjør andre folk til å prøve og reprodusere resultatene. 

Så hvordan kan du komme i gang? Vi er godt støttet på Linux. Så hvis du ønsker å installere noe på Linux, du bruker standard pakkebehandler å installere. Hvis du bruker en Debian, er det apt get. CentOS er yum. Fedora Red Hat er rpm-- jeg ikke husker. Uansett, det er alt der. Vi støtter et stort utvalg av Linux-distribusjoner. Du kan sjekke dem ut. 

Vi har også muligheter slik at du kan kjøres på Mac eller Windows. Nå Nico nevnte tidligere at det var bare støttes på Linux. Det er sant fordi det trenger en Linux-kjernen. Men, kan du kjøre i en virtuell maskin. Og hva Docker Toolbox gjør, som du kan laste ned, det gir deg den virtuelle maskinen. 

Så bare en rask 48 andre, tror jeg, laste ned. Du bare søke på Docker Toolbox, laste den ned til Mac, og denne delen er av Kurset sped opp fordi som ønsker å se en nedlasting signal? Standard Mac installasjon, og da er du kommer til å se Jerome lagt i hans passord. Det er veldig spennende. Og så den installerer en hel haug med verktøy. Og spesielt det vil installere en kommandolinje. Og så kan du se Jerome teste hans bilder. 

Og så basert på dette, du kan se at YouTube mener at Nico er interessert i Star Wars, The Jimmy Kimmel-show, og jeg tror Ellen. Jeg tror det siste er et klipp fra en Ellen showet. 

Så Docker Toolbox kommer selv med mer enn bare Docker Machine. Så Docker Machine er ting som hjelper du sette opp en virtuell maskin på Windows eller Mac-- Windows boks eller Mac box-- og hjelper deg å gjøre klargjøring, 

Men det kommer også med Swarm og Compose, som er laget for å hjelpe deg med å gjøre store utrullinger av søknaden din. Så hvis du ønsker å administrere klynger av noder, klynger av containere, Komponer og Swarm er veien å gå om det. 

Og selvfølgelig den kommer med Docker Motor og Kitematic, som er denne desktop GUI. Jeg bør også nevne Docker Registeret, som ikke er inkludert i verktøykassa men det er en måte for deg å kjøre din egen registre over Docker bilder som Docker Hub, men du kan også bare bruke Docker Hub som en måte å gjøre det. 

Og, vri, du ser det kjører i en container. Og det er slik vi er distribusjon av våre lysbilder. Hele denne presentasjonen er faktisk en HTML lysbilde dekk. Og det kjører i et container, som du kan få by-- 

NICOLA Kabar: Ja, så det er kjører full gang på min Max. Og jeg presenterer fra det. Og du bare gjøre Docker etter du installerer Toolbox. Du kan bare gjøre en havnearbeider run og få det, og bruke lysbildene. 

MANO MERKER: Og det er det. Så vi takker dere alle for å komme. Og vi er glade for å svare på spørsmål. Jeg bør nevne før noen later det er t-skjorter der borte. Beklager alle som ser dette på Livestream eller video, men vi har Docker T-skjorter der borte. Og vi vet Docker studenter, og i min erfaring, professorer også, som gratis klær. 

Så takk alle for å komme ut. Og følg oss på Twitter hvis du vil, eller ikke. Jeg bryr meg ikke. Følg også Docker på Twitter. Det er også interessant. Og så det er det. Docker.com. Takk skal du ha. 

[BIFALL]