Cosa hè Docker: una breve escursione in a storia è astrazioni basi

Accuminciau u 10 d'Aostu in Slurm Corso video Docker, in quale l'analizemu cumpletamente - da l'astrazioni basi à i paràmetri di a rete.

In questu articulu avemu da parlà di a storia di Docker è i so astrazioni principali: Image, Cli, Dockerfile. A cunferenza hè destinata à i principianti, per quessa, hè improbabile chì sia d'interessu per l'utilizatori sperimentati. Ùn ci sarà micca sangue, appendice o immersione prufonda. I assai basi.

Cosa hè Docker

Fighjemu a definizione di Docker da Wikipedia.

Docker hè un software per automatizà a implementazione è a gestione di l'applicazioni in ambienti containerizzati.

Nunda hè chjaru da sta definizione. Hè soprattuttu pocu chjaru ciò chì significa "in ambienti chì supportanu a containerizazione". Per sapè, vultemu in u tempu. Cuminciamu cù l'era chì chjamu tradiziunale "Era monolitica".

Era monolitica

L'era monolitica hè u principiu di l'anni 2000, quandu tutte l'applicazioni eranu monolitiche, cù una mansa di dependenzii. U sviluppu hà pigliatu assai tempu. À u listessu tempu, ùn ci era micca assai servitori; tutti i cunnisciamu per nome è i monitoremu. Ci hè un paragone cusì divertente:

L'animali domestici sò animali domestici. In l'era monolitica, avemu trattatu i nostri servitori cum'è animali di l'animali, curati è affettati, sguassate specks di polvera. È per una megliu gestione di e risorse, avemu usatu a virtualizazione: avemu pigliatu un servitore è tagliatu in parechje macchine virtuali, assicurendu cusì l'isulazione di l'ambiente.

Sistemi di virtualizazione basati in ipervisori

Tutti anu prubabilmente intesu parlà di i sistemi di virtualizazione: VMware, VirtualBox, Hyper-V, Qemu KVM, etc. Forniscenu l'isolamentu di l'applicazioni è a gestione di risorse, ma anu ancu svantaghji. Per fà a virtualizazione, avete bisognu di un hypervisor. È l'ipervisore hè una risorsa overhead. È a macchina virtuale stessu hè di solitu un colossu tutale - una maghjina pesante chì cuntene un sistema operatore, Nginx, Apache, è possibbilmente MySQL. L'imaghjini hè grande è a macchina virtuale hè inconveniente per uperà. In u risultatu, u travagliu cù e macchine virtuali pò esse lentu. Per risolve stu prublema, i sistemi di virtualizazione sò stati creati à u livellu di u kernel.

Sistemi di virtualizazione à livellu di kernel

A virtualizazione à livellu di u kernel hè supportata da i sistemi OpenVZ, Systemd-nspawn, LXC. Un esempiu di tali virtualizazione hè LXC (Linux Containers).

LXC hè un sistema di virtualizazione à livellu di u sistema operatore per eseguisce parechje istanze isolate di u sistema operatore Linux in un unicu node. LXC ùn usa micca macchine virtuali, ma crea un ambiente virtuale cù u so propiu spaziu di prucessu è stack di rete.

Essenzialmente LXC crea cuntenituri. Chì ghjè a diffarenza trà e macchine virtuali è i cuntenituri ?

U cuntinuu ùn hè micca adattatu per i prucessi di isolamentu: i vulnerabili si trovanu in i sistemi di virtualizazione à u livellu di u kernel chì li permettenu di scappà da u cuntinuu à l'ospite. Dunque, sè avete bisognu di isolà qualcosa, hè megliu aduprà una macchina virtuale.

I diffirenzii trà virtualizazione è containerizazione ponu esse vistu in u diagramma.
Ci sò ipervisori hardware, ipervisori in cima à u SO, è cuntenituri.

L'ipervisori di hardware sò cool se vulete veramente isolà qualcosa. Perchè hè pussibule isolà à u livellu di pagine di memoria è processori.

Ci sò ipervisori cum'è un prugramma, è ci sò cuntenituri, è avemu da parlà più. I sistemi di containerizazione ùn anu micca un ipervisore, ma ci hè un Container Engine chì crea è gestisce cuntenituri. Questa cosa hè più ligera, cusì per via di travaglià cù u core ùn ci hè menu sopra o nimu.

Ciò chì hè utilizatu per a containerizazione à u livellu di u kernel

I tecnulugii principali chì permettenu di creà un containeru isolatu da altri prucessi sò Namespaces è Control Groups.

Namespaces: PID, Networking, Mount and User. Ci sò più, ma per facilità di capiscenu ci focalizeremu nantu à questi.

U PID Namespace limita i prucessi. Quandu, per esempiu, creamu un PID Namespace è postu un prucessu quì, diventa cù PID 1. Di solitu in i sistemi PID 1 hè systemd o init. In cunsiquenza, quandu pusemu un prucessu in un novu spaziu di nomi, riceve ancu PID 1.

Networking Namespace permette di limità / isolà a reta è di mette e vostre interfacce in l'internu. Mount hè una limitazione di u sistema di fugliale. User-restrizzione à l'utilizatori.

Gruppi di cuntrollu: Memoria, CPU, IOPS, Rete - circa 12 paràmetri in totale. Altrimenti sò ancu chjamati Cgroups ("C-gruppi").

Gruppi di cuntrollu gestisce e risorse per un containeru. Per mezu di i Gruppi di cuntrollu pudemu dì chì u cuntinuu ùn deve micca cunsumà più di una certa quantità di risorse.

Per a cuntainerizazione per travaglià cumplettamente, tecnulugie supplementari sò aduprate: Capacità, Copy-on-write è altri.

E capacità sò quandu dicemu à un prucessu ciò chì pò è ùn pò micca fà. À u livellu di u kernel, sò solu bitmaps cù parechji parametri. Per esempiu, l'utilizatore root hà privileggi pienu è pò fà tuttu. U servitore di u tempu pò cambià u tempu di u sistema: hà capacità nantu à a Capsula di u Tempu, è questu hè. Utilizendu privilegi, pudete cunfigurà in modu flessibile e restrizioni per i prucessi, è cusì prutegge.

U sistema Copy-on-write ci permette di travaglià cù l'imaghjini di Docker è l'utilizanu in modu più efficace.

Docker hà attualmente prublemi di cumpatibilità cù Cgroups v2, cusì questu articulu si cuncentra specificamente in Cgroups v1.

Ma vultemu à a storia.

Quandu i sistemi di virtualizazione apparsu à u livellu di u kernel, cuminciaru à esse attivamente utilizati. L'overhead nantu à l'hypervisor hè sparitu, ma alcuni prublemi sò stati:

• imaghjini grandi: spinghjenu un sistema operatore, biblioteche, una mansa di software diffirenti in u stessu OpenVZ, è à a fine l'imaghjina hè sempre abbastanza grande;
• Ùn ci hè micca un standard normale per l'imballu è a spedizione, cusì u prublema di dependenzii resta. Ci sò situazioni quandu dui pezzi di codice utilizanu a listessa biblioteca, ma cù diverse versioni. Ci pò esse un cunflittu trà elli.

Per risolve tutti questi prublemi, hè ghjunta a prossima era.

Era di u containeru

Quandu l'era di i Containers ghjunse, a filusufìa di travaglià cun elli hà cambiatu:

• Un prucessu - un containeru.
• Trasmettimu tutte e dipendenze chì u prucessu hà bisognu à u so containeru. Questu hè bisognu di taglià monoliti in microservizi.
• A più chjuca l'imaghjini, u megliu - ci sò menu vulnerabili pussibuli, si stende più veloce, è cusì.
• I casi diventanu effimeri.

Ricurdativi di ciò chì aghju dettu di l'animali di l'animali versu u vacche? Prima, i casi eranu cum'è animali domestici, ma avà sò diventati cum'è vacche. Prima, ci era un monolitu - una applicazione. Avà hè 100 microservices, 100 containers. Certi cuntenituri ponu avè 2-3 repliche. Diventa menu impurtante per noi di cuntrullà ogni cuntainer. Ciò chì hè più impurtante per noi hè a dispunibilità di u serviziu stessu: ciò chì face stu settore di cuntenituri. Questu cambia l'approcciu di u monitoraghju.

In 2014-2015, Docker fiurisce - a tecnulugia chì avemu da parlà avà.

Docker hà cambiatu a filusufìa è l'imballazione standardizata di l'applicazione. Utilizendu Docker, pudemu imballà una applicazione, mandà à un repository, scaricallu da quì, è implementà.

Pudemu tuttu ciò chì avemu bisognu in u containeru Docker, cusì u prublema di dependenza hè risolta. Docker garantisce a riproducibilità. Pensu chì parechje persone anu scontru l'irreproducibilità: tuttu u travagliu per voi, l'avete spintu à a produzzione, è quì si ferma di travaglià. Cù Docker, stu prublema si sparisce. Se u vostru containeru Docker principia è faci ciò chì deve fà, allora cun un altu gradu di probabilità principiarà in a produzzione è fà u listessu.

Digressione nantu à u sopra

Ci sò sempre disputi nantu à i costi generali. Qualchidunu crede chì Docker ùn porta micca una carica addiziale, postu chì usa u kernel Linux è tutti i so prucessi necessarii per a containerizazione. Comu, "se dite chì Docker hè sopra, allora u kernel Linux hè sopra".

Per d 'altra banda, s'è vo andate più in fondu, ci sò veramente parechje cose in Docker chì, cù un trattu, si pò dì chì sò sopra.

U primu hè u spaziu di nomi PID. Quandu avemu postu un prucessu in un namespace, hè assignatu PID 1. À u stessu tempu, stu prucessu hà un altru PID, chì si trova nantu à u namespace host, fora di u cuntinuu. Per esempiu, avemu lanciatu Nginx in un containeru, hè diventatu PID 1 (prucessu maestru). È nantu à l'ospitu hà u PID 12623. È hè difficiule di dì quantu di sopra hè.

A seconda cosa hè Cgroups. Pigliemu Cgroups per memoria, vale à dì a capacità di limità a memoria di un containeru. Quandu hè attivatu, i cuntatori è a cuntabilità di memoria sò attivati: u kernel hà bisognu di capisce quante pagine sò state attribuite è quante sò sempre libere per stu containeru. Questu hè possibbilmente un overhead, ma ùn aghju micca vistu studii precisi nantu à cumu affetta u rendiment. È eiu stessu ùn aghju micca nutatu chì l'applicazione in esecuzione in Docker hà subitu subitu una forte perdita di rendiment.

È una nota più nantu à u rendiment. Certi paràmetri di u kernel sò passati da l'ospite à u containeru. In particulare, certi paràmetri di rete. Dunque, sè vo vulete eseguisce qualcosa d'altu rendimentu in Docker, per esempiu, qualcosa chì aduprà attivamente a reta, allora almenu avete bisognu di aghjustà sti paràmetri. Certi nf_conntrack, per esempiu.

Circa u cuncettu di Docker

Docker hè custituitu da parechji cumpunenti:

1. Docker Daemon hè u listessu Container Engine; lancia containeri.
2. Docker CII hè una utilità di gestione Docker.
3. Dockerfile - struzzioni nantu à cumu custruisce una maghjina.
4. Image - l'imaghjini da quale u cuntinuu hè spartu.
5. Contenitore.
6. Docker registry hè un repository d'imaghjini.

Schematicamente si vede qualcosa cum'è questu:

Docker daemon corre nantu à Docker_host è lancia cuntenituri. Ci hè un Cliente chì manda cumandamenti: custruite l'imaghjini, scaricate l'imaghjini, lanciate u containeru. Docker daemon va à u registru è li eseguisce. U cliente Docker pò accede à u locu (à un socket Unix) è via TCP da un host remoto.

Andemu per ogni cumpunente.

Demone Docker - questu hè a parte di u servitore, travaglia nantu à a macchina d'ospiti: scaricate l'imaghjini è lancia i cuntenituri da elli, crea una rete trà cuntenituri, raccoglie logs. Quandu dicemu "creà una maghjina", u dimòniu face ancu questu.

Docker CLI - Parte cliente Docker, utilità di cunsola per travaglià cù u demone. Ripecu, pò travaglià micca solu in u locu, ma ancu nantu à a reta.

Comandamenti basi:

docker ps - mostra i cuntenituri chì sò attualmente in esecuzione nantu à l'ospite Docker.
docker images - mostra l'imaghjini scaricate in u locu.
docker search <> - cercate una maghjina in u registru.
docker pull <> - scaricate una maghjina da u registru à a macchina.
docker build < > - cullate l'imaghjini.
docker run <> - lanciari u containeru.
docker rm <> - caccià u cuntinuu.
docker logs <> - logs di u containeru
docker start/stop/restart <> - travaglià cù u containeru

Se mastrini sti cumandamenti è sò cunfidenti in l'usu di elli, cunsiderà 70% proficient in Docker à u livellu di l'utilizatori.

dockerfile - struzzioni per creà una maghjina. Quasi ogni cumanda d'istruzzioni hè una nova capa. Fighjemu un esempiu.

Questu hè ciò chì u Dockerfile s'assumiglia: cumandamenti à manca, argumenti à diritta. Ogni cumanda chì hè quì (è generalmente scrittu in u Dockerfile) crea una nova capa in Image.

Ancu fighjendu à u latu manca, pudete apprussimatamente capisce ciò chì succede. Dicemu: "create un cartulare per noi" - questu hè una capa. "Fà u cartulare di travaglià" hè un altru stratu, è cetara. Layer cake rende a vita più faciule. Se crea un altru Dockerfile è cambia qualcosa in l'ultima linea - I run qualcosa altru chè "python" "main.py", o installà dipendenze da un altru schedariu - allora i strati precedenti seranu reutilizati cum'è cache.

Image - questu hè un imballaggio di cuntainer; i cuntenituri sò lanciati da l'imaghjini. Se guardemu à Docker da u puntu di vista di un gestore di pacchetti (cum'è s'ellu travagliassi cù pacchetti deb o rpm), allora l'imagine hè essenzialmente un pacchettu rpm. Attraversu yum install pudemu installà l'applicazione, sguassate, truvallu in u repository, è scaricallu. Hè nantu à u listessu quì: i cuntenituri sò lanciati da l'imaghjini, sò guardati in u registru Docker (simili à yum, in un repository), è ogni imagine hà un hash SHA-256, un nome è un tag.

L'imaghjini hè custruitu secondu l'istruzzioni da u Dockerfile. Ogni struzzione da u Dockerfile crea una nova capa. I strati ponu esse riutilizzati.

Registru Docker hè un repositoriu d'imaghjini Docker. Simile à u SO, Docker hà un registru standard publicu - dockerhub. Ma pudete custruisce u vostru propiu repository, u vostru propiu registru Docker.

dépannage - ciò chì hè lanciatu da l'imaghjini. Avemu custruitu una maghjina secondu l'istruzzioni da u Dockerfile, dopu l'avemu lanciatu da questa maghjina. Stu cuntinuu hè isolatu da altri cuntenituri è deve cuntene tuttu ciò chì hè necessariu per u funziunamentu di l'applicazione. In questu casu, un cuntainer - un prucessu. Succede chì avete da fà dui prucessi, ma questu hè un pocu cuntrariu à l'ideulugia Docker.

U requisitu "un containeru, un prucessu" hè in relazione cù u PID Namespace. Quandu un prucessu cù PID 1 principia in Namespace, s'ellu mori di colpu, allora tuttu u cuntinuu mori ancu. Sì dui prucessi sò in esecuzione quì: unu hè vivu è l'altru hè mortu, allura u cuntinuu cuntinueghja sempre à vive. Ma questu hè una quistione di Best Practices, avemu da parlà di elli in altri materiali.

Per studià e caratteristiche è u prugramma cumpletu di u corsu in più dettagliu, seguite u ligame: "Corso video Docker».

Autore: Marcel Ibraev, amministratore certificatu Kubernetes, ingegnere praticante in Southbridge, parlante è sviluppatore di corsi Slurm.

Source: www.habr.com