{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Hvad er Docker: en kort introduktion til historien og de vigtigste abstraktioner","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

10. august startede der et videokursus om Docker<\/a><\/noindex>, hvor vi d\u00e6kker det fuldst\u00e6ndigt \u2014 fra grundl\u00e6ggende abstraktioner til netv\u00e6rksparametre. <\/p>\n

<\/p>\n

I denne artikel vil vi tale om historien bag Docker og dets grundl\u00e6ggende abstraktioner: Image, CLI, Dockerfile. Forel\u00e6sningen er rettet mod nybegyndere, s\u00e5 det vil n\u00e6ppe v\u00e6re interessant for erfarne brugere. Der vil ikke v\u00e6re nogen blodige detaljer, appendicer eller dybtg\u00e5ende analysere. Bare det helt grundl\u00e6ggende.<\/p>\n

<\/p>\n

\"Hvad<\/p>\n

<\/a><\/noindex><\/p>\n

Hvad er Docker<\/h2>\n

<\/p>\n

Lad os se p\u00e5 definitionen af Docker fra Wikipedia.<\/p>\n

<\/p>\n

Docker er software til automatisering af implementering og styring af applikationer i milj\u00f8er med containerunderst\u00f8ttelse.<\/p><\/blockquote>\n

Ud fra denne definition er der ikke meget klarhed. Is\u00e6r hvad det betyder at 'i milj\u00f8er med containerunderst\u00f8ttelse'. For at forst\u00e5 det, lad os g\u00e5 tilbage i tiden. Vi starter i en \u00e6ra, som jeg delvis kalder 'Monolit\u00e6raen'.<\/p>\n

<\/p>\n

Monolit\u00e6raen<\/h2>\n

<\/p>\n

Monolit\u00e6raen er begyndelsen af 2000'erne, hvor alle applikationer var monolitiske, med et v\u00e6ld af afh\u00e6ngigheder. Udviklingen tog lang tid. P\u00e5 samme tid var serverne ikke s\u00e5 mange, og vi kendte dem alle ved navn og overv\u00e5gede dem. Der er et sjovt sammenligningspunkt:<\/p>\n

\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Pets \u2014 det er k\u00e6ledyr. I monolit\u00e6raen behandlede vi vores servere som k\u00e6ledyr, vi plejer og tager os af dem, bl\u00e6ser st\u00f8vet af dem. For bedre at styre ressourcerne brugte vi virtualisering: vi tog en server og delte den op i flere virtuelle maskiner, og dermed sikrede vi isolering af milj\u00f8et.<\/p>\n

<\/p>\n

Virtualiseringssystemer baseret p\u00e5 hypervisor<\/h2>\n

<\/p>\n

Alle har sikkert h\u00f8rt om virtualiseringssystemer: VMware, VirtualBox, Hyper-V, Qemu KVM osv. De sikrer isolering af applikationer og ressourceforvaltning, men de har ogs\u00e5 ulemper. For at lave virtualisering kr\u00e6ves en hypervisor. Og hypervisoren medf\u00f8rer ressourceoverhead. Desuden er selve den virtuelle maskine ofte en stor enhed \u2014 et tungt billede, som har et operativsystem, Nginx, Apache og muligvis MySQL. Billedet er stort, og det er uhandy at arbejde med en virtuel maskine. Som f\u00f8lge heraf kan arbejdet med virtualisering v\u00e6re langsomt. For at l\u00f8se dette problem blev der skabt virtualiseringssystemer p\u00e5 kernniveau.<\/p>\n

<\/p>\n

Virtualiseringssystemer p\u00e5 kernniveau<\/h2>\n

<\/p>\n

Virtualisering p\u00e5 kerniveau underst\u00f8ttes af systemer som OpenVZ, Systemd-nspawn, LXC. Et klart eksempel p\u00e5 s\u00e5dan virtualisering er LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 et virtualiseringssystem p\u00e5 operativsystemniveau, der tillader k\u00f8rsel af flere isolerede forekomster af Linux-operativsystemet p\u00e5 \u00e9n v\u00e6rtsmaskine. LXC bruger ikke virtuelle maskiner, men opretter et virtuelt milj\u00f8 med sit eget procesrum og netv\u00e6rksstak.<\/p>\n

<\/p>\n

Essentielt set opretter LXC containere. Hvad er forskellen mellem virtuelle maskiner og containere?<\/p>\n

<\/p>\n

\"Hvad<\/p>\n

<\/p>\n

Containere er ikke velegnede til procesisolering: i virtualiseringssystemer p\u00e5 kerniveau findes der s\u00e5rbarheder, der g\u00f8r det muligt at komme ud af en container til v\u00e6rten. S\u00e5 hvis du har brug for at isolere noget, er det bedre at bruge en virtuel maskine.<\/p>\n

<\/p>\n

Forskelle mellem virtualisering og containerisering kan ses i diagrammet.
\nDer findes hardwarehypervisorer, hypervisorer ovenp\u00e5 operativsystemet og containere. <\/p>\n

<\/p>\n

\"Hvad<\/p>\n

<\/p>\n

\"Hardware\" hypervisorer er fantastisk, hvis du virkelig vil isolere noget. Fordi der er mulighed for at isolere p\u00e5 niveau med hukommelsessider og processorer.<\/p>\n

<\/p>\n

Der er hypervisorer som programmer, og der er containere, og dem vil vi tale videre om. I containeriseringssystemer findes der ikke en hypervisor, men der er en Container Engine, der opretter og administrerer containere. Denne l\u00f8sning er lettere, s\u00e5 ved at arbejde med kernen er overheadet mindre, eller det findes slet ikke.<\/p>\n

<\/p>\n

\n

Hvad der bruges til containerisering p\u00e5 kerne-niveau<\/h2>\n

De prim\u00e6re teknologier, der muligg\u00f8r oprettelsen af en isoleret container fra andre processer, er Namespaces og Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount og User. Der er flere, men for enkelhedens skyld stopper vi ved disse.<\/p>\n

PID Namespace begr\u00e6nser processer. N\u00e5r vi for eksempel opretter et PID Namespace og placerer en proces der, f\u00e5r den PID 1. Normalt er PID 1 i systemer systemd eller init. N\u00e5r vi derfor placerer en proces i et nyt namespace, f\u00e5r den ogs\u00e5 PID 1.<\/p>\n

Networking Namespace tillader begr\u00e6nsning\/isolering af netv\u00e6rket, og man kan placere sine egne gr\u00e6nseflader der. Mount er en begr\u00e6nsning i filsystemet. User er en begr\u00e6nsning for brugere.<\/p>\n

Control Groups: Memory, CPU, IOPS, Network \u2014 omkring 12 indstillinger i alt. De kaldes ogs\u00e5 Cgroups (\"C-grupper\").<\/p>\n

Control Groups styrer ressourcerne for containeren. Gennem Control Groups kan vi angive, at containeren ikke m\u00e5 forbruge mere end en vis m\u00e6ngde ressourcer.<\/p>\n

For containerization to work effectively, additional technologies are used: Capabilities, Copy-on-write, and others.<\/p>\n

Capabilities refer to defining what a process can and cannot do. At the kernel level, these are simply bitmaps with numerous parameters. For instance, the root user has full privileges and can do anything. A time server can change the system time: it has capabilities for Time Capsule, and that\u2019s it. Privileges allow for flexible constraints on processes, thereby enhancing security.<\/p>\n

The Copy-on-write system allows us to work with Docker images more efficiently.<\/p>\n

Currently, Docker has compatibility issues with Cgroups v2, so this article specifically addresses Cgroups v1.<\/em><\/p><\/blockquote>\n

But let\u2019s return to the history. <\/p>\n

<\/p>\n

When virtualization systems at the kernel level emerged, they began to be widely adopted. The overhead on the hypervisor disappeared, but some issues remained:<\/p>\n

<\/p>\n