Што е Докер: кратка екскурзија во историјата и основните апстракции

Започна на 10 август во Слурм Докер видео курс, во која целосно го анализираме - од основни апстракции до мрежните параметри.

Во оваа статија ќе зборуваме за историјата на Docker и неговите главни апстракции: Image, Cli, Dockerfile. Предавањето е наменето за почетници, па веројатно нема да биде интересно за искусните корисници. Нема да има крв, слепо црево или длабоко потопување. Самите основи.

Што е Докер

Ајде да ја погледнеме дефиницијата за Докер од Википедија.

Docker е софтвер за автоматизирање на распоредувањето и управувањето со апликациите во контејнеризирани средини.

Ништо не е јасно од оваа дефиниција. Особено е нејасно што значи „во средини што поддржуваат контејнеризација“. За да дознаеме, да се вратиме во времето. Да почнеме со ерата што јас конвенционално ја нарекувам „Монолитна ера“.

Монолитна ера

Монолитната ера е раните 2000-ти, кога сите апликации беа монолитни, со еден куп зависности. Развојот траеше долго време. Во исто време, немаше многу сервери, сите ги знаевме по име и ги следевме. Има една таква смешна споредба:

Домашните миленици се домашни животни. Во монолитната ера, ги третиравме нашите сервери како миленичиња, негувани и негувани, дувајќи дамки прашина. И за подобро управување со ресурсите, користевме виртуелизација: зедовме сервер и го пресековме на неколку виртуелни машини, со што обезбедивме изолација на околината.

Системи за виртуелизација базирани на хипервизор

Сите веројатно слушнале за системи за виртуелизација: VMware, VirtualBox, Hyper-V, Qemu KVM итн. Тие обезбедуваат изолација на апликации и управување со ресурси, но имаат и недостатоци. За да направите виртуелизација, потребен ви е хипервизор. И хипервизорот е ресурс преку глава. И самата виртуелна машина е обично цел колос - тешка слика која содржи оперативен систем, Nginx, Apache, а можеби и MySQL. Сликата е голема и виртуелната машина е незгодна за работа. Како резултат на тоа, работата со виртуелни машини може да биде бавна. За да се реши овој проблем, системи за виртуелизација беа креирани на ниво на јадрото.

Системи за виртуелизација на ниво на јадро

Виртуелизацијата на ниво на кернел е поддржана од системи OpenVZ, Systemd-nspawn, LXC. Впечатлив пример за таква виртуелизација е LXC (Linux Containers).

LXC е систем за виртуелизација на ниво на оперативен систем за извршување на повеќе изолирани примероци на оперативниот систем Linux на еден јазол. LXC не користи виртуелни машини, туку создава виртуелна средина со сопствен процесен простор и мрежен стек.

Во суштина LXC создава контејнери. Која е разликата помеѓу виртуелните машини и контејнерите?

Контејнерот не е погоден за изолирање на процесите: во системите за виртуелизација на ниво на кернел се наоѓаат ранливости што им овозможуваат да избегаат од контејнерот до домаќинот. Затоа, ако треба да изолирате нешто, подобро е да користите виртуелна машина.

Разликите помеѓу виртуелизацијата и контејнеризацијата може да се видат на дијаграмот.
Постојат хардверски хипервизори, хипервизори на врвот на ОС и контејнери.

Хардверските хипервизори се кул ако навистина сакате да изолирате нешто. Бидејќи е можно да се изолираат на ниво на мемориски страници и процесори.

Има хипервизори како програма, има и контејнери и за нив ќе зборуваме понатаму. Системите за контејнеризација немаат хипервизор, но постои Container Engine кој создава и управува со контејнери. Оваа работа е полесна, така што поради работата со јадрото има помалку надземни трошоци или воопшто нема.

Што се користи за контејнеризација на ниво на јадро

Главните технологии кои ви дозволуваат да креирате контејнер изолиран од други процеси се Простори со имиња и контролни групи.

Простори со имиња: PID, Networking, Mount и User. Има повеќе, но за полесно разбирање ќе се фокусираме на нив.

PID Именскиот простор ги ограничува процесите. Кога, на пример, ќе создадеме PID именски простор и ќе поставиме процес таму, тој станува со PID 1. Обично во системите PID 1 е системски или инициран. Според тоа, кога поставуваме процес во нов именски простор, тој добива и PID 1.

Вмрежување именски простор ви овозможува да ја ограничите/изолирате мрежата и да поставите свои интерфејси внатре. Монтирањето е ограничување на датотечниот систем. Корисник - ограничување на корисниците.

Контролни групи: меморија, процесор, IOPS, мрежа - вкупно околу 12 поставки. Инаку тие се нарекуваат и Cgroups („C-групи“).

Контролните групи управуваат со ресурсите за контејнер. Преку контролните групи можеме да кажеме дека контејнерот не треба да троши повеќе од одредена количина ресурси.

За целосно да функционира контејнеризацијата, се користат дополнителни технологии: способности, Copy-on-write и други.

Способностите се кога му кажуваме на процесот што може и што не може да направи. На ниво на јадрото, ова се едноставно битмапи со многу параметри. На пример, root корисникот има целосни привилегии и може да направи сè. Временскиот сервер може да го промени времето на системот: има можности на Временската капсула и тоа е тоа. Користејќи ги привилегиите, можете флексибилно да конфигурирате ограничувања за процесите и со тоа да се заштитите.

Системот Copy-on-write ни овозможува да работиме со Docker слики и да ги користиме поефикасно.

Докер моментално има проблеми со компатибилноста со Cgroups v2, така што овој напис се фокусира конкретно на Cgroups v1.

Но, да се вратиме на историјата.

Кога системите за виртуелизација се појавија на ниво на јадрото, тие почнаа активно да се користат. Надземните трошоци на хипервизорот исчезнаа, но останаа некои проблеми:

• големи слики: туркаат оперативен систем, библиотеки, куп различен софтвер во истиот OpenVZ, и на крајот сликата сепак се покажува доста голема;
• Не постои нормален стандард за пакување и испорака, така што проблемот со зависностите останува. Постојат ситуации кога две парчиња код користат иста библиотека, но со различни верзии. Може да има конфликт меѓу нив.

За да се решат сите овие проблеми, дојде следната ера.

Ера на контејнери

Кога пристигна ерата на контејнерите, филозофијата на работа со нив се промени:

• Еден процес - еден контејнер.
• Ги доставуваме сите зависности што му се потребни на процесот до неговиот контејнер. Ова бара сечење монолит во микросервис.
• Колку е помала сликата, толку подобро - има помалку можни ранливости, таа се исфрла побрзо и така натаму.
• Случаите стануваат ефемерни.

Се сеќавате што кажав за миленичиња против говеда? Порано инстанците беа како домашни животни, а сега станаа како говеда. Претходно, имаше монолит - една апликација. Сега има 100 микросервиси, 100 контејнери. Некои контејнери може да имаат 2-3 реплики. За нас станува помалку важно да го контролираме секој контејнер. Она што ни е поважно е достапноста на самата услуга: што прави овој сет на контејнери. Ова го менува пристапот кон мониторингот.

Во 2014-2015 година, Докер процвета - технологијата за која ќе зборуваме сега.

Докер ја смени филозофијата и стандардизирано пакување на апликацијата. Користејќи го Docker, можеме да пакуваме апликација, да ја испратиме во складиште, да ја преземеме од таму и да ја распоредиме.

Ставивме сè што ни треба во контејнерот Docker, така што проблемот со зависноста е решен. Docker гарантира репродуктивност. Мислам дека многу луѓе се сретнаа со нерепродуктивност: сè работи за вас, го туркате до производство и таму престанува да работи. Со Docker овој проблем исчезнува. Ако вашиот Docker контејнер стартува и го прави она што треба да го направи, тогаш со голем степен на веројатност ќе започне со производство и ќе го стори истото таму.

Дигресија за надземни трошоци

Секогаш има спорови за општите трошоци. Некои луѓе веруваат дека Docker не носи дополнително оптоварување, бидејќи го користи кернелот на Linux и сите негови процеси неопходни за контејнеризација. Како, „ако кажете дека Docker е над глава, тогаш кернелот на Linux е над глава“.

Од друга страна, ако навлезете подлабоко, навистина има неколку работи во Докер за кои, со истегнување, може да се каже дека се над глава.

Првиот е именскиот простор на PID. Кога поставуваме процес во именски простор, му се доделува PID 1. Во исто време, овој процес има уште еден PID, кој се наоѓа на именскиот простор на домаќинот, надвор од контејнерот. На пример, го лансиравме Nginx во контејнер, тој стана PID 1 (главен процес). И на домаќинот има PID 12623. И тешко е да се каже колкава е цената.

Втората работа е Cgroups. Да ги земеме Cgroups по меморија, односно способноста да се ограничи меморијата на контејнер. Кога е овозможено, се активираат бројачите и сметководството за меморија: кернелот треба да разбере колку страници се доделени и колку се уште се слободни за овој контејнер. Ова е можеби над глава, но не сум видел никакви прецизни студии за тоа како тоа влијае на перформансите. И јас самиот не забележав дека апликацијата што работи во Docker одеднаш доживеа остра загуба во перформансите.

И уште една забелешка за перформансите. Некои параметри на јадрото се пренесуваат од домаќинот до контејнерот. Особено, некои мрежни параметри. Затоа, ако сакате да извршите нешто со високи перформанси во Docker, на пример, нешто што активно ќе ја користи мрежата, тогаш барем треба да ги прилагодите овие параметри. Некои nf_conntrack, на пример.

За концептот Docker

Докер се состои од неколку компоненти:

1. Docker Daemon е истиот Container Engine; лансира контејнери.
2. Docker CII е алатка за управување со Docker.
3. Dockerfile - инструкции за тоа како да се изгради слика.
4. Слика — слика од која се вала контејнерот.
5. Контејнер.
6. Докерскиот регистар е складиште за слики.

Шематски изгледа вака:

Докер демонот работи на Docker_host и лансира контејнери. Постои клиент кој испраќа команди: изгради ја сликата, преземете ја сликата, стартувајте го контејнерот. Docker daemon оди во регистарот и ги извршува. Клиентот Docker може да пристапи и локално (до Unix приклучок) и преку TCP од оддалечен домаќин.

Ајде да поминеме низ секоја компонента.

Докер демон - ова е дел од серверот, работи на машината домаќин: презема слики и лансира контејнери од нив, создава мрежа помеѓу контејнерите, собира дневници. Кога велиме „создади слика“, демонот исто така го прави тоа.

Докер CLI — Докер клиентски дел, алатка за конзола за работа со демонот. Повторувам, може да работи не само локално, туку и преку мрежата.

Основни команди:

docker ps - прикажувај ги контејнерите што моментално работат на домаќинот Docker.
докер слики - прикажувај слики преземени локално.
докер пребарување <> - побарајте слика во регистарот.
docker pull <> - преземете слика од регистарот на машината.
докер изгради < > - соберете ја сликата.
docker run <> - стартувајте го контејнерот.
docker rm <> - извадете го садот.
докер логови <> - дневници за контејнери
docker start/stop/restart <> - работа со контејнерот

Ако ги совладате овие команди и сте сигурни во нивното користење, сметајте дека сте 70% умешен во Docker на ниво на корисник.

dockerfile - инструкции за креирање слика. Речиси секоја команда со инструкции е нов слој. Ајде да погледнеме на пример.

Вака изгледа Dockerfile: команди лево, аргументи десно. Секоја команда што е овде (и генерално напишана во Dockerfile) создава нов слој во Image.

Дури и гледајќи на левата страна, грубо можете да разберете што се случува. Ние велиме: „создадете папка за нас“ - ова е еден слој. „Направи ја папката да работи“ е уште еден слој, и така натаму. Слојната торта го олеснува животот. Ако создадам друг Dockerfile и променам нешто во последната линија - стартувам нешто друго освен „python“ „main.py“, или инсталирам зависност од друга датотека - тогаш претходните слоеви ќе се користат повторно како кеш.

Сликата - ова е контејнерско пакување; контејнерите се лансираат од сликата. Ако го погледнеме Docker од гледна точка на менаџер на пакети (како да работиме со deb или rpm пакети), тогаш сликата во суштина е пакет со вртежи во минута. Преку yum install можеме да ја инсталираме апликацијата, да ја избришеме, да ја најдеме во складиштето и да ја преземеме. Овде е приближно исто: контејнерите се лансираат од сликата, се чуваат во регистарот Docker (слично на yum, во складиште) и секоја слика има хаш SHA-256, име и ознака.

Сликата е изградена според упатствата од Dockerfile. Секоја инструкција од Dockerfile создава нов слој. Слоевите може повторно да се користат.

Докер регистар е складиште за слики на Docker. Слично на ОС, Docker има јавен стандарден регистар - dockerhub. Но, можете да изградите сопствено складиште, свој Docker регистар.

Контејнер - што се лансира од сликата. Изградивме слика според упатствата од Dockerfile, а потоа ја стартуваме од оваа слика. Овој контејнер е изолиран од други контејнери и мора да содржи се што е потребно за да функционира апликацијата. Во овој случај, еден контејнер - еден процес. Се случува да треба да направите два процеси, но тоа е нешто спротивно на идеологијата на Докер.

Барањето „еден контејнер, еден процес“ е поврзано со Именскиот простор на PID. Кога ќе започне процес со PID 1 во Именскиот простор, ако одеднаш умре, тогаш умира и целиот контејнер. Ако таму работат два процеса: едниот е жив, а другиот мртов, тогаш контејнерот сепак ќе продолжи да живее. Но, ова е прашање на најдобрите практики, ќе зборуваме за нив во други материјали.

За подетално да ги проучите карактеристиките и целосната програма на курсот, ве молиме следете ја врската: “Докер видео курс".

Автор: Марсел Ибраев, сертифициран администратор на Кубернетес, инженер-практик во Саутбриџ, говорник и развивач на курсеви за Slurm.

Извор: www.habr.com