Va començar el 10 d'agost a Slurm , en què ho analitzem completament, des d'abstraccions bàsiques fins a paràmetres de xarxa.
En aquest article parlarem de la història de Docker i les seves principals abstraccions: Image, Cli, Dockerfile. La conferència està pensada per a principiants, per la qual cosa és poc probable que sigui d'interès per als usuaris experimentats. No hi haurà sang, apèndix o immersió profunda. Els bàsics.
Què és Docker
Vegem la definició de Docker de la Viquipèdia.
Docker és un programari per automatitzar el desplegament i la gestió d'aplicacions en entorns contenidors.
Res és clar d'aquesta definició. No està especialment clar què significa "en entorns que admeten la contenidorització". Per saber-ho, retrocedim en el temps. Comencem per l'època que convencionalment anomeno "Era monolítica".
Època monolítica
L'era monolítica és a principis dels anys 2000, quan totes les aplicacions eren monolítices, amb un munt de dependències. El desenvolupament va trigar molt de temps. Al mateix temps, no hi havia molts servidors; tots els coneixíem pel seu nom i els controlàvem. Hi ha una comparació tan divertida:
Les mascotes són animals domèstics. A l'era monolítica, vam tractar els nostres servidors com a mascotes, cuidats i estimats, fent eixugar les molles de pols. I per a una millor gestió dels recursos, vam utilitzar la virtualització: vam agafar un servidor i el vam tallar en diverses màquines virtuals, garantint així l'aïllament de l'entorn.
Sistemes de virtualització basats en hipervisor
Segurament tothom ha sentit parlar dels sistemes de virtualització: VMware, VirtualBox, Hyper-V, Qemu KVM, etc. Proporcionen aïllament d'aplicacions i gestió de recursos, però també tenen desavantatges. Per fer la virtualització, necessiteu un hipervisor. I l'hipervisor és una sobrecàrrega de recursos. I la pròpia màquina virtual sol ser tot un colós: una imatge pesada que conté un sistema operatiu, Nginx, Apache i possiblement MySQL. La imatge és gran i la màquina virtual és incòmode per funcionar. Com a resultat, treballar amb màquines virtuals pot ser lent. Per resoldre aquest problema, es van crear sistemes de virtualització a nivell del nucli.
Sistemes de virtualització a nivell de nucli
La virtualització a nivell de nucli és compatible amb sistemes OpenVZ, Systemd-nspawn i LXC. Un exemple sorprenent d'aquesta virtualització és LXC (Linux Containers).
LXC és un sistema de virtualització a nivell de sistema operatiu per executar múltiples instàncies aïllades del sistema operatiu Linux en un sol node. LXC no utilitza màquines virtuals, sinó que crea un entorn virtual amb el seu propi espai de procés i pila de xarxa.
Essencialment, LXC crea contenidors. Quina diferència hi ha entre les màquines virtuals i els contenidors?
El contenidor no és adequat per aïllar processos: es troben vulnerabilitats als sistemes de virtualització a nivell del nucli que els permeten escapar del contenidor a l'amfitrió. Per tant, si necessiteu aïllar alguna cosa, és millor utilitzar una màquina virtual.
Les diferències entre virtualització i contenidorització es poden veure al diagrama.
Hi ha hipervisors de maquinari, hipervisors a la part superior del sistema operatiu i contenidors.
Els hipervisors de maquinari són genials si realment voleu aïllar alguna cosa. Perquè és possible aïllar a nivell de pàgines de memòria i processadors.
Hi ha hipervisors com a programa, i hi ha contenidors, i en parlarem més endavant. Els sistemes de contenidorització no tenen hipervisor, però hi ha un motor de contenidors que crea i gestiona contenidors. Aquesta cosa és més lleugera, de manera que a causa de treballar amb el nucli hi ha menys sobrecàrrega o cap.
Què s'utilitza per a la contenidorització a nivell del nucli
Les principals tecnologies que permeten crear un contenidor aïllat d'altres processos són els espais de noms i els grups de control.
Espais de noms: PID, Xarxa, Muntatge i Usuari. N'hi ha més, però per facilitar la comprensió ens centrarem en aquests.
L'espai de noms PID limita els processos. Quan, per exemple, creem un espai de noms PID i hi col·loquem un procés, es converteix en PID 1. Normalment, als sistemes, el PID 1 és systemd o init. En conseqüència, quan col·loquem un procés en un espai de noms nou, també rep el PID 1.
L'espai de noms de xarxa us permet limitar/aïllar la xarxa i col·locar-hi les vostres pròpies interfícies. El muntatge és una limitació del sistema de fitxers. Usuari: restricció d'usuaris.
Grups de control: memòria, CPU, IOPS, xarxa: uns 12 paràmetres en total. En cas contrari, també s'anomenen grups C ("grups C").
Els grups de control gestionen els recursos d'un contenidor. A través dels Grups de Control podem dir que el contenidor no ha de consumir més d'una determinada quantitat de recursos.
Perquè la contenidorització funcioni completament, s'utilitzen tecnologies addicionals: Capacitats, Copy-on-write i altres.
Les capacitats són quan diem a un procés què pot i què no pot fer. A nivell del nucli, aquests són simplement mapes de bits amb molts paràmetres. Per exemple, l'usuari root té privilegis complets i pot fer-ho tot. El servidor de temps pot canviar l'hora del sistema: té capacitats a Time Capsule, i això és tot. Amb privilegis, podeu configurar de manera flexible les restriccions dels processos i, per tant, protegir-vos.
El sistema Copy-on-write ens permet treballar amb imatges de Docker i utilitzar-les de manera més eficient.
Docker actualment té problemes de compatibilitat amb Cgroups v2, de manera que aquest article se centra específicament en Cgroups v1.
Però tornem a la història.
Quan van aparèixer els sistemes de virtualització a nivell del nucli, es van començar a utilitzar activament. La sobrecàrrega de l'hipervisor va desaparèixer, però es van mantenir alguns problemes:
- imatges grans: empenyen un sistema operatiu, biblioteques, un munt de programari diferent al mateix OpenVZ, i al final la imatge encara resulta bastant gran;
- No hi ha un estàndard normal per a l'embalatge i el lliurament, de manera que el problema de les dependències es manté. Hi ha situacions en què dues peces de codi utilitzen la mateixa biblioteca, però amb versions diferents. Pot haver-hi un conflicte entre ells.
Per resoldre tots aquests problemes, ha arribat la propera era.
Era dels contenidors
Quan va arribar l'era dels contenidors, la filosofia de treballar amb ells va canviar:
- Un procés: un contenidor.
- Entreguem totes les dependències que el procés necessita al seu contenidor. Això requereix tallar monòlits en microserveis.
- Com més petita sigui la imatge, millor: hi ha menys vulnerabilitats possibles, es desplega més ràpid, etc.
- Les instàncies es tornen efímeres.
Recordeu el que vaig dir sobre les mascotes i el bestiar? Abans, els casos eren com animals domèstics, però ara s'han convertit en bestiar. Anteriorment, hi havia un monòlit: una aplicació. Ara són 100 microserveis, 100 contenidors. Alguns contenidors poden tenir 2-3 rèpliques. Es fa menys important per a nosaltres controlar tots els contenidors. El que és més important per a nosaltres és la disponibilitat del propi servei: què fa aquest conjunt de contenidors. Això canvia els enfocaments del seguiment.
El 2014-2015, Docker va florir, la tecnologia de la qual parlarem ara.
Docker va canviar la filosofia i va estandarditzar el paquet d'aplicacions. Amb Docker, podem empaquetar una aplicació, enviar-la a un repositori, descarregar-la des d'allà i desplegar-la.
Posem tot el que necessitem al contenidor Docker, de manera que el problema de dependència està resolt. Docker garanteix la reproductibilitat. Crec que molta gent s'ha trobat amb la irreproducibilitat: tot funciona per a tu, t'ho poses a la producció i allà deixa de funcionar. Amb Docker aquest problema desapareix. Si el vostre contenidor Docker s'inicia i fa el que ha de fer, llavors amb un alt grau de probabilitat s'iniciarà en producció i farà el mateix allà.
Digressió sobre les despeses generals
Sempre hi ha disputes sobre les despeses generals. Algunes persones creuen que Docker no porta una càrrega addicional, ja que utilitza el nucli Linux i tots els seus processos necessaris per a la contenidorització. Per exemple, "si dius que Docker està per sobre, llavors el nucli de Linux està per sobre".
D'altra banda, si s'aprofundeix, de fet hi ha diverses coses a Docker que, amb un tram, es pot dir que són per sobre.
El primer és l'espai de noms PID. Quan col·loquem un procés en un espai de noms, se li assigna el PID 1. Al mateix temps, aquest procés té un altre PID, que es troba a l'espai de noms de l'amfitrió, fora del contenidor. Per exemple, vam llançar Nginx en un contenidor, es va convertir en PID 1 (procés mestre). I a l'amfitrió té el PID 12623. I és difícil dir quanta sobrecàrrega és.
La segona cosa és Cgroups. Prenem Cgroups per memòria, és a dir, la capacitat de limitar la memòria d'un contenidor. Quan està activat, s'activen els comptadors i la comptabilitat de memòria: el nucli ha d'entendre quantes pàgines s'han assignat i quantes encara queden lliures per a aquest contenidor. Això és possiblement una sobrecàrrega, però no he vist cap estudi precís sobre com afecta el rendiment. I jo mateix no em vaig adonar que l'aplicació que s'executava a Docker va experimentar de sobte una forta pèrdua de rendiment.
I una nota més sobre el rendiment. Alguns paràmetres del nucli es passen de l'amfitrió al contenidor. En particular, alguns paràmetres de xarxa. Per tant, si voleu executar alguna cosa d'alt rendiment a Docker, per exemple, una cosa que utilitzi activament la xarxa, almenys haureu d'ajustar aquests paràmetres. Alguns nf_conntrack, per exemple.
Sobre el concepte Docker
Docker consta de diversos components:
- Docker Daemon és el mateix motor de contenidors; llança contenidors.
- Docker CII és una utilitat de gestió de Docker.
- Dockerfile: instruccions sobre com crear una imatge.
- Imatge: la imatge des de la qual es desplega el contenidor.
- Contenidor.
- El registre Docker és un dipòsit d'imatges.
Esquemàticament sembla una cosa així:
El dimoni Docker s'executa a Docker_host i llança contenidors. Hi ha un client que envia ordres: construïu la imatge, descarregueu la imatge, inicieu el contenidor. El dimoni Docker va al registre i els executa. El client Docker pot accedir tant localment (a un sòcol Unix) com mitjançant TCP des d'un host remot.
Repassem cada component.
Dimoni Docker - aquesta és la part del servidor, funciona a la màquina host: descarrega imatges i llança contenidors des d'elles, crea una xarxa entre contenidors, recull registres. Quan diem "crea una imatge", el dimoni també ho fa.
Docker CLI — Part del client Docker, utilitat de consola per treballar amb el dimoni. Repeteixo, pot funcionar no només localment, sinó també a través de la xarxa.
Ordres bàsiques:
docker ps: mostra els contenidors que s'estan executant actualment a l'amfitrió Docker.
imatges docker: mostren imatges descarregades localment.
Docker search <> - cerca una imatge al registre.
docker pull <>: baixa una imatge del registre a la màquina.
Docker build < > - recollir la imatge.
docker run <>: llança el contenidor.
docker rm <> - elimina el contenidor.
Docker logs <> - registres del contenidor
docker start/stop/restart <> - treballant amb el contenidor
Si domineu aquestes ordres i confieu en utilitzar-les, considereu-vos un 70% competent en Docker a nivell d'usuari.
Dockerfile - instruccions per crear una imatge. Gairebé totes les ordres d'instrucció són una capa nova. Vegem un exemple.
Així és el Dockerfile: ordres a l'esquerra, arguments a la dreta. Cada comanda que hi ha aquí (i generalment escrita al Dockerfile) crea una nova capa a Image.
Fins i tot mirant el costat esquerre, podeu entendre aproximadament el que està passant. Diem: "creeu una carpeta per a nosaltres": aquesta és una capa. "Fes que la carpeta funcioni" és una altra capa, i així successivament. El pastís de capes facilita la vida. Si creo un altre Dockerfile i canvio alguna cosa a l'última línia (executo una altra cosa que no sigui "python" "main.py" o instal·lo dependències des d'un altre fitxer), aleshores les capes anteriors es reutilitzaran com a memòria cau.
Imatge - Es tracta d'envasos de contenidors; els contenidors es llancen des de la imatge. Si mirem Docker des del punt de vista d'un gestor de paquets (com si treballéssim amb paquets deb o rpm), llavors la imatge és essencialment un paquet rpm. Mitjançant yum install podem instal·lar l'aplicació, eliminar-la, trobar-la al repositori i descarregar-la. Aquí passa més o menys el mateix: els contenidors es llancen des de la imatge, s'emmagatzemen al registre de Docker (semblant a yum, en un dipòsit) i cada imatge té un hash SHA-256, un nom i una etiqueta.
La imatge es crea segons les instruccions del Dockerfile. Cada instrucció del Dockerfile crea una nova capa. Les capes es poden reutilitzar.
Registre Docker és un dipòsit d'imatges de Docker. Similar al sistema operatiu, Docker té un registre estàndard públic: dockerhub. Però podeu crear el vostre propi dipòsit, el vostre propi registre Docker.
Contenidor - el que es llança des de la imatge. Hem construït una imatge segons les instruccions del Dockerfile, després la llancem des d'aquesta imatge. Aquest contenidor està aïllat d'altres contenidors i ha de contenir tot el necessari perquè l'aplicació funcioni. En aquest cas, un contenidor - un procés. Passa que has de fer dos processos, però això és una mica contrari a la ideologia de Docker.
El requisit "un contenidor, un procés" està relacionat amb l'espai de noms PID. Quan s'inicia un procés amb PID 1 a l'espai de noms, si mor de sobte, també mor el contenidor sencer. Si s'estan executant dos processos allà: un està viu i l'altre està mort, el contenidor encara continuarà viu. Però això és una qüestió de Bones Pràctiques, en parlarem en altres materials.
Per estudiar les característiques i el programa complet del curs amb més detall, seguiu l'enllaç: "».
Autor: Marcel Ibraev, administrador certificat de Kubernetes, enginyer en exercici a Southbridge, ponent i desenvolupador de cursos Slurm.
Font: www.habr.com