Какво е Docker: кратка екскурзия в историята и основни абстракции

Започна на 10 август в Slurm Докер видео курс, в който го анализираме изцяло – от базови абстракции до мрежови параметри.

В тази статия ще говорим за историята на Docker и основните му абстракции: Image, Cli, Dockerfile. Лекцията е предназначена за начинаещи, така че е малко вероятно да представлява интерес за опитни потребители. Няма да има кръв, апендикс или дълбоко потапяне. Самите основи.

Какво е Docker

Нека да разгледаме определението на Docker от Wikipedia.

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, мрежа, монтиране и потребител. Има още, но за по-лесно разбиране ще се спрем на тях.

PID Namespace ограничава процесите. Когато, например, създадем PID Namespace и поставим процес там, той става с PID 1. Обикновено в системите PID 1 е systemd или init. Съответно, когато поставим процес в ново пространство от имена, той също получава PID 1.

Мрежовото пространство на имената ви позволява да ограничите/изолирате мрежата и да поставите свои собствени интерфейси вътре. Монтирането е ограничение на файловата система. Потребител—ограничение за потребители.

Контролни групи: памет, процесор, IOPS, мрежа - общо около 12 настройки. В противен случай те се наричат ​​също C-групи („C-групи“).

Контролните групи управляват ресурси за контейнер. Чрез контролните групи можем да кажем, че контейнерът не трябва да консумира повече от определено количество ресурси.

За пълноценна работа на контейнеризацията се използват допълнителни технологии: Capabilities, Copy-on-write и други.

Възможностите са, когато казваме на процес какво може и какво не може да прави. На ниво ядро ​​това са просто растерни изображения с много параметри. Например root потребителят има пълни привилегии и може да прави всичко. Сървърът за време може да промени системното време: той има възможности на Time Capsule и това е всичко. Използвайки привилегии, можете гъвкаво да конфигурирате ограничения за процеси и по този начин да се защитите.

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

В момента Docker има проблеми със съвместимостта с Cgroups v2, така че тази статия се фокусира конкретно върху Cgroups v1.

Но да се върнем към историята.

Когато системите за виртуализация се появиха на ниво ядро, те започнаха да се използват активно. Овърхедът на хипервайзора изчезна, но някои проблеми останаха:

• големи изображения: те вкарват операционна система, библиотеки, куп различен софтуер в един и същ OpenVZ и в крайна сметка изображението пак се оказва доста голямо;
• Няма нормален стандарт за опаковане и доставка, така че проблемът със зависимостите остава. Има ситуации, когато две парчета код използват една и съща библиотека, но с различни версии. Може да има конфликт между тях.

За да се решат всички тези проблеми, дойде следващата ера.

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

Когато настъпи ерата на контейнерите, философията за работа с тях се промени:

• Един процес - един контейнер.
• Ние доставяме всички зависимости, необходими на процеса, в неговия контейнер. Това изисква рязане на монолитите в микроуслуги.
• Колкото по-малко е изображението, толкова по-добре - има по-малко възможни уязвимости, то се разпространява по-бързо и т.н.
• Случаите стават ефимерни.

Помните ли какво казах за домашни любимци срещу говеда? Преди това екземплярите бяха като домашни животни, но сега станаха като добитък. Преди това имаше монолит - едно приложение. Сега има 100 микроуслуги, 100 контейнера. Някои контейнери могат да имат 2-3 реплики. За нас става по-малко важно да контролираме всеки контейнер. Това, което е по-важно за нас, е наличието на самата услуга: какво прави този набор от контейнери. Това променя подхода към наблюдението.

През 2014-2015 г. Docker процъфтява - технологията, за която ще говорим сега.

Docker промени философията и стандартизира пакета на приложенията. Използвайки Docker, можем да пакетираме приложение, да го изпратим в хранилище, да го изтеглим от там и да го внедрим.

Поставяме всичко необходимо в контейнера на Docker, така че проблемът със зависимостта е решен. Docker гарантира възпроизводимост. Мисля, че много хора са се сблъсквали с невъзпроизводимост: всичко ви работи, бутнете го в производство и там то спира да работи. С Docker този проблем изчезва. Ако вашият Docker контейнер стартира и прави това, което трябва, тогава с голяма степен на вероятност той ще започне в производство и ще направи същото там.

Отклонение за режийните

Винаги има спорове за режийните разходи. Някои хора смятат, че Docker не носи допълнително натоварване, тъй като използва ядрото на Linux и всички негови процеси, необходими за контейнеризиране. Например, „ако кажете, че Docker е над главата, тогава ядрото на Linux е над главата.“

От друга страна, ако навлезете по-дълбоко, наистина има няколко неща в Docker, за които с удължение може да се каже, че са излишни.

Първият е PID namespace. Когато поставим процес в пространство от имена, той получава PID 1. В същото време този процес има друг PID, който се намира в пространството от имена на хоста, извън контейнера. Например, стартирахме Nginx в контейнер, той стана PID 1 (главен процес). И на хоста има PID 12623. И е трудно да се каже колко режийни са.

Второто нещо са Cgroups. Нека вземем Cgroups по памет, тоест възможността да ограничим паметта на контейнер. Когато е активиран, броячите и отчитането на паметта се активират: ядрото трябва да разбере колко страници са били разпределени и колко са все още свободни за този контейнер. Това вероятно е режийно, но не съм виждал точни проучвания за това как се отразява на производителността. И аз самият не забелязах, че приложението, работещо в Docker, изведнъж претърпя рязка загуба на производителност.

И още една забележка относно производителността. Някои параметри на ядрото се предават от хоста към контейнера. По-специално някои мрежови параметри. Ето защо, ако искате да стартирате нещо високопроизводително в Docker, например нещо, което ще използва активно мрежата, тогава трябва поне да коригирате тези параметри. Някакъв nf_conntrack например.

Относно концепцията Docker

Docker се състои от няколко компонента:

1. Docker Daemon е същият Container Engine; пуска контейнери.
2. Docker CII е помощна програма за управление на Docker.
3. Dockerfile - инструкции как да изградите изображение.
4. Изображение — изображението, от което се разгръща контейнерът.
5. Контейнер.
6. Регистърът на Docker е хранилище на изображения.

Схематично изглежда така:

Docker демон работи на Docker_host и стартира контейнери. Има клиент, който изпраща команди: изграждане на изображението, изтегляне на изображението, стартиране на контейнера. Docker daemon отива в системния регистър и ги изпълнява. Клиентът Docker може да осъществява достъп както локално (до Unix сокет), така и чрез TCP от отдалечен хост.

Нека да преминем през всеки компонент.

Докер демон - това е сървърната част, тя работи на хост машината: изтегля изображения и стартира контейнери от тях, създава мрежа между контейнери, събира регистрационни файлове. Когато казваме „създайте образ“, демонът прави и това.

Docker CLI — Docker клиентска част, конзолна помощна програма за работа с демона. Повтарям, може да работи не само локално, но и в мрежата.

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

docker ps - показва контейнери, които в момента се изпълняват на хоста на Docker.
докер изображения - показват изображения, изтеглени локално.
docker search <> - търсене на изображение в системния регистър.
docker pull <> - изтегляне на изображение от системния регистър на машината.
докер компилация < > - събиране на изображението.
docker run <> - стартиране на контейнера.
docker rm <> - премахване на контейнера.
докер дневници <> - дневници на контейнери
docker start/stop/restart <> - работа с контейнера

Ако владеете тези команди и сте уверени в използването им, считайте се за 70% опитен в Docker на ниво потребител.

Докер файл - инструкции за създаване на изображение. Почти всяка команда с инструкции е нов слой. Нека разгледаме един пример.

Ето как изглежда Dockerfile: команди отляво, аргументи отдясно. Всяка команда, която е тук (и обикновено написана в Dockerfile) създава нов слой в Image.

Дори да погледнете лявата страна, можете приблизително да разберете какво се случва. Казваме: „създайте папка за нас“ - това е един слой. „Направете папката работеща“ е друг слой и т.н. Слоевата торта прави живота по-лесен. Ако създам друг Dockerfile и променя нещо в последния ред - стартирам нещо различно от "python" "main.py" или инсталирам зависимости от друг файл - тогава предишните слоеве ще бъдат използвани повторно като кеш.

Изображение - това е контейнерна опаковка; контейнерите се стартират от изображението. Ако погледнем Docker от гледна точка на мениджър на пакети (сякаш работим с deb или rpm пакети), тогава изображението по същество е rpm пакет. Чрез yum install можем да инсталираме приложението, да го изтрием, да го намерим в хранилището и да го изтеглим. Тук е почти същото: контейнерите се стартират от изображението, съхраняват се в регистъра на Docker (подобно на yum, в хранилище) и всяко изображение има SHA-256 хеш, име и таг.

Изображението е изградено според инструкциите от Dockerfile. Всяка инструкция от Dockerfile създава нов слой. Слоевете могат да се използват повторно.

Докер регистър е хранилище за изображения на Docker. Подобно на ОС, Docker има публичен стандартен регистър - dockerhub. Но можете да създадете свое собствено хранилище, свой собствен регистър на Docker.

Контейнер - какво се стартира от изображението. Създадохме изображение според инструкциите от Dockerfile, след което го стартираме от това изображение. Този контейнер е изолиран от другите контейнери и трябва да съдържа всичко необходимо за функционирането на приложението. В този случай един контейнер - един процес. Случва се да трябва да направите два процеса, но това донякъде противоречи на идеологията на Docker.

Изискването „един контейнер, един процес“ е свързано с PID пространството от имена. Когато процес с PID 1 стартира в пространството на имената, ако внезапно умре, тогава умира и целият контейнер. Ако там се изпълняват два процеса: единият е жив, а другият е мъртъв, тогава контейнерът ще продължи да живее. Но това е въпрос на най-добри практики, ще говорим за тях в други материали.

За да проучите по-подробно функциите и пълната програма на курса, моля, последвайте връзката: “Докер видео курс".

Автор: Марсел Ибраев, сертифициран администратор на Kubernetes, практикуващ инженер в Southbridge, лектор и разработчик на курсове по Slurm.

Източник: www.habr.com