Vad är Docker: en kort översikt över historien och grundläggande abstraktioner

10 augusti lanserades i Slörm en videokurs om Docker, där vi går igenom det i detalj – från grundläggande abstraktioner till nätverksinställningar.

I den här artikeln kommer vi att diskutera historien bakom Docker och dess grundläggande abstraktioner: Image, Cli, Dockerfile. Föreläsningen riktar sig till nybörjare, så den kommer knappast att intressera erfarna användare. Det kommer inte att förekomma blod, blindtarmsoperationer och djupdykningar. Bara grunderna.

Vad är Docker

Låt oss titta på definitionen av Docker från Wikipedia.

Docker är en mjukvara för automatisering av distribution och hantering av applikationer i miljöer med stöd för containrar.

Av denna definition framgår ingenting klart. Speciellt oklart är vad som menas med "i miljöer med stöd för containrar". För att förstå detta, låt oss gå tillbaka i tiden. Låt oss börja från en tid som jag kollektivt kallar "Den monolitiska eran".

Den monolitiska eran

Den monolitiska eran är början av 2000-talet, när alla applikationer var monolitiska med massor av beroenden. Utvecklingen tog lång tid. Samtidigt fanns det inte så många servrar, vi kände dem alla vid namn och övervakade dem. Det finns en rolig jämförelse:

Pets – det är husdjur. Under den monolitiska eran behandlade vi våra servrar som husdjur, vi tog hand om dem, och violen gärna fjädrade bort damm. För att bättre hantera resurser använde vi virtualisering: vi tog en server och delade den på flera virtuella maskiner, vilket därmed säkrade miljöisolering.

Virtualiseringssystem baserade på hypervisorer

Om virtualiseringssystem har säkert de flesta hört talas om: VMware, VirtualBox, Hyper-V, Qemu KVM etc. De tillhandahåller applikationsisolering och resurshantering, men de har också nackdelar. För att göra virtualisering behövs en hypervisor. Och hypervisorn innebär resurskostnader. Dessutom är själva den virtuella maskinen vanligtvis en stor apparat – en tung bild, med operativsystem, Nginx, Apache och eventuellt MySQL. Bilden är stor och det är besvärligt att arbeta med en virtuell maskin. Som en följd blir arbetet med virtuella maskiner långsamt. För att lösa detta problem skapades virtualiseringssystem på kärnnivå.

Virtualiseringssystem på kärnnivå

Virtualisering på kärnnivå stöds av system som OpenVZ, Systemd-nspawn, LXC. Ett tydligt exempel på sådan virtualisering är LXC (Linux Containers).

LXC — en virtualiseringssystem på operativsystemets nivå för att köra flera isolerade instanser av operativsystemet Linux på en och samma nod. LXC använder inte virtuella maskiner, utan skapar en virtuell miljö med eget processutrymme och nätverksstack.

I grund och botten skapar LXC containrar. Vad är skillnaden mellan virtuella maskiner och containrar?

Containern passar inte för att isolera processer: i virtualiseringssystem på kärnnivå finns sårbarheter som gör att man kan ta sig ut ur containern till värden. Så om du behöver isolera något, är det bättre att använda en virtuell maskin.

Skillnaderna mellan virtualisering och containerisering kan ses i diagrammet.
Det finns hårdvaruhypervisorer, hypervisorer ovanpå operativsystem och containrar.

"Hårdhypervisorer" är en fantastisk sak om du verkligen vill isolera något. För där finns möjligheten att isolera på minnesordsnivå och processorer.

Det finns hypervisorer som programvara och det finns containrar, och det är dem vi kommer att prata mer om. I containeriseringssystemet finns det ingen hypervisor, men det finns en Container Engine som skapar och hanterar containrar. Det är en lättviktslösning, så genom att arbeta med kärnan är overheaden mindre, eller inte alls.

Vad som används för containerisering på kärnnivå

De viktigaste teknologierna som gör det möjligt att skapa en isolerad container från andra processer är Namespaces och Control Groups.

Namespaces: PID, Nätverk, Montering och Användare. Det finns fler, men för enkelhetens skull fokuserar vi på dessa.

PID Namespace begränsar processerna. När vi till exempel skapar en PID Namespace och placerar en process där, får den PID 1. Vanligtvis är PID 1 i systemen antingen systemd eller init. Därför, när vi placerar en process i en ny namespace, får den också PID 1.

Networking Namespace möjliggör att begränsa/isolera nätverket och placera sina egna gränssnitt där inne. Montering är begränsning på filsystemet. Användare — begränsning på användarna.

Control Groups: Minne, CPU, IOPS, Nätverk — det finns totalt omkring 12 inställningar. De kallas också Cgroups ("C-grupper").

Control Groups hanterar resurser för containern. Genom Control Groups kan vi ange att containern inte får använda mer än en viss mängd resurser.

För att containerisering ska fungera fullt ut används ytterligare teknologier: Capabilities, Copy-on-write och andra.

Capabilities är när vi säger till processen vad den kan göra och vad den inte kan. På kärnnivå är det helt enkelt bitmasker med många parametrar. Till exempel har användaren root full behörighet och kan göra allt. Tidsservern kan ändra systemtiden: den har capabilities för Time Capsule, och så är det. Genom privilegier kan vi flexibelt ställa in begränsningar för processerna och på så sätt skydda oss själva.

Systemet Copy-on-write gör att vi kan arbeta med Docker-avbilder och använda dem mer effektivt.

För närvarande har Docker problem med kompatibilitet med Cgroups v2, så artikeln fokuserar på just Cgroups v1.

Men låt oss återgå till historien.

När virtualiseringssystem på kärnnivå kom ut, började de tillämpas aktivt. Överhuvudtaget försvann overheaden på hypervisorn, men vissa problem kvarstod:

• stora avbilder: i samma OpenVZ trycker man in operativsystemet, bibliotek, en massa olika mjukvaror, och i slutändan blir avbilden ändå ganska stor;
• det finns ingen ordentlig standard för paketering och distribution, så problemet med beroenden kvarstår. Det kan uppstå situationer där två kodstycken använder ett bibliotek, men med olika versioner. Det kan uppstå konflikter mellan dem.

För att lösa alla dessa problem kom nästa era.

Era av containrar

När Era av containrar inträffade, förändrades filosofin för hur man arbetar med dem:

• En process — en container.
• Alla nödvändiga beroenden för processen levereras i dess container. Detta kräver att man delar upp monoliter i mikrotjänster.
• Ju mindre avbild, desto bättre — färre potentiella sårbarheter, snabbare distribution och så vidare.
• Instanser blir efemära.

Kommer ni ihåg att jag pratade om pets vs cattle? Förr var instanser som husdjur, nu har de blivit som cattle — boskap. Tidigare fanns det en monolit — en applikation. Nu finns det 100 mikrotjänster, 100 containrar. Några containrar kan ha 2-3 repliker. Det blir inte så viktigt att kontrollera varje container. Det viktigare är tillgängligheten av själva tjänsten: vad denna uppsättning containrar gör. Detta förändrar tillvägagångssätten för övervakning.

Åren 2014-2015 inträffade blomstringen av Docker — den teknologi vi kommer att prata om nu.

Docker har förändrat filosofin och standardiserat paketeringen av applikationer. Med Docker kan vi paketera en applikation, skicka den till ett repot, ladda ner den därifrån och distribuera den.

I Docker-containern lägger vi allt som behövs, vilket löser problemet med beroenden. Docker garanterar reproducerbarhet. Jag tror att många har stött på problem med reproducerbarhet: allt fungerar för dig, men när du pushar till produktion slutar det fungera. Med Docker försvinner det problemet. Om din Docker-container startar och gör vad den ska, är chansen stor att den kommer att starta i produktion och göra samma sak där.

En avvikelse om overhead

Det pågår ständiga diskussioner om overhead. Vissa hävdar att Docker inte medför någon extra belastning, eftersom det använder Linux-kärnan och alla dess processer som behövs för containerisering. De säger att "om du påstår att Docker är overhead, då är även Linux-kärnan overhead".

Å andra sidan, om vi dyker djupare, så finns det faktiskt flera saker i Docker som, med viss inskränkning, kan sägas vara overhead.

För det första – PID-namnområdet. När vi placerar en process i ett namnrum tilldelas den PID 1. Samtidigt har denna process en annan PID som finns i värdnamnområdet, utanför containern. Till exempel, vi startade Nginx i containern, och det blev PID 1 (masterprocessen). Men på värden har den PID 12623. Och det är svårt att säga hur mycket overhead det här medför.

Den andra saken – Cgroups. Låt oss ta Cgroups för minne, det vill säga möjligheten att begränsa minnet för en container. När det aktiveras aktiveras räkneverken, minnes redovisning: kärnan måste förstå hur många sidor som har tilldelats och hur många som fortfarande är tillgängliga för denna container. Det kan vara overhead, men jag har inte sett några exakta studier av hur det påverkar prestandan. Och jag har inte märkt att en applikation som körs i Docker plötsligt tappar i prestanda.

Och en annan kommentar om prestanda. Vissa kärnparametrar förs över från värden till containern. I synnerhet vissa nätverksparametrar. Så om du vill köra något högpresterande i Docker, till exempel något som aktivt kommer att använda nätverket, så behöver du åtminstone justera dessa parametrar. Någon slags nf_conntrack, till exempel.

Om konceptet Docker

Docker består av flera komponenter:

1. Docker Daemon – det är just Container Engine; det startar containrar.
2. Docker CII – ett verktyg för att hantera Docker.
3. Dockerfile – en instruktion för hur man bygger en image.
4. Image – en bild som containern rullas ut ifrån.
5. Container.
6. Docker registry – en lagringsplats för images.

Schemat ser ungefär ut så här:

På Docker_host kör Docker daemon, som startar containrar. Det finns en klient som skickar kommandon: bygg en image, ladda ner en image, kör en container. Docker daemon går till registry och utför dem. Docker-klienten kan nå ut lokalt (till unix-socketen) eller via TCP från en fjärrvärd.

Låt oss gå igenom varje komponent.

Docker daemon (demon) – är den serverbaserade delen, den körs på värdmaskinen: laddar ner images och startar containrar från dem, skapar nätverk mellan containrar, samlar loggar. När vi säger 'skapa en image', så utför även demon det.

Docker CLI – den kundbaserade delen av Docker, ett kommandoradsverktyg för att arbeta med demon. Jag upprepar, den kan fungera inte bara lokalt utan även över nätverket.

Grundläggande kommandon:

docker ps – visa de containrar som för närvarande är körda på Docker-värden.
docker images – visa images som har laddats ner lokalt.
docker search – sök efter en image i registry.
docker pull – ladda ner en image från registry till maskinen.
docker build <> – bygg en image.
docker run – kör containern.
docker rm – ta bort containern.
docker logs – loggar för containern
docker start/stop/restart – hantera containern

Om du behärskar dessa kommandon och använder dem bekvämt, kan du anse att du har bemästrat Docker på användarnivå till 70%.

Dockerfile – instruktion för att skapa en image. Nästan varje kommando i instruktionen är ett nytt lager. Låt oss titta på ett exempel.

Ungefär så här ser en Dockerfile ut: kommandon till vänster, argument till höger. Varje kommando som finns här (och skrivs i Dockerfile) skapar ett nytt lager i Image.

Även om man tittar på vänster del, kan man förstå ungefär vad som pågår. Vi säger: 'skapa en mapp åt oss' – det är ett lager. 'Gör mappen till arbetsmapp' – det är ytterligare ett lager, och så vidare. Lagerkakan förenklar livet. Om jag skapar ytterligare en Dockerfile och ändrar något i den sista raden – om jag kör "python" "main.py" eller installerar beroenden från en annan fil – kommer de tidigare lagren att återsanvändas som cache.

Image — det här är en containeravbildning, från vilken containrar startas. Om vi ser på Docker ur ett pakethanterarperspektiv (som om vi arbetar med deb- eller rpm-paket), så är en bild i grund och botten ett rpm-paket. Genom yum install kan vi installera en applikation, ta bort den, hitta den i arkivet och ladda ner den. Här är det ungefär detsamma: containrar startas från bilden, de lagras i Docker-register (på samma sätt som yum, i ett arkiv), och varje bild har en SHA-256-hash, namn och tagg.

Bild byggs enligt instruktionerna i Dockerfile. Varje instruktion i Dockerfile skapar ett nytt lager. Lager kan återanvändas.

Docker-register — är ett register för Docker-bilder. Precis som operativsystem har Docker ett offentligt standardregister — dockerhub. Men det går att bygga ett eget register, en egen Docker-register.

Container — är det som körs från en bild. Vi har byggt bilden enligt instruktionerna i Dockerfile, och sedan kör vi den från denna bild. Denna container är isolerad från andra containrar och ska innehålla allt som behövs för att köra applikationen. Samtidigt är en container — en process. Det kan hända att vi måste ha två processer, men det strider mot Docker-ideologin.

Kravet "en container — en process" är relaterat till PID Namespace. När en process med PID 1 startas i ett Namespace, om den plötsligt dör, dör hela containern också. Om det däremot finns två processer som körs: en är levande och den andra har dött, så fortsätter containern att leva. Men det här handlar om Best Practices, och vi kommer att diskutera dem i andra material.

För mer detaljerad information om kursens egenskaper och hela program kan du följa länken: "Videokurs om Docker».

Författare: Marsel Ibraev, certifierad Kubernetes-administratör, verksam ingenjör på Southbridge, talare och kursutvecklare för Slürm.

Källa: habr.com