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

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

У овом чланку ћемо говорити о историји Доцкер-а и његовим главним апстракцијама: Имаге, Цли, Доцкерфиле. Предавање је намењено почетницима, па је мало вероватно да ће бити од интереса за искусне кориснике. Неће бити крви, слепог црева или дубоког урањања. Саме основе.

Шта је Доцкер

Погледајмо дефиницију Доцкер-а са Википедије.

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

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

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

Монолитна ера је почетком 2000-их, када су све апликације биле монолитне, са гомилом зависности. Развој је трајао дуго. У исто време, није било много сервера, сви смо их познавали по имену и пратили их. Постоји тако смешно поређење:

Кућни љубимци су домаће животиње. У монолитној ери, третирали смо наше сервере као кућне љубимце, неговане и неговане, отпухујући трунке прашине. А за боље управљање ресурсима користили смо виртуелизацију: узели смо сервер и пресекли га на неколико виртуелних машина, чиме смо обезбедили изолацију окружења.

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

Вероватно су сви чули за системе виртуелизације: ВМваре, ВиртуалБок, Хипер-В, Кему КВМ, итд. Они обезбеђују изолацију апликација и управљање ресурсима, али имају и недостатке. Да бисте извршили виртуелизацију, потребан вам је хипервизор. А хипервизор је главни ресурс. А сама виртуелна машина је обично цео колос - тешка слика која садржи оперативни систем, Нгинк, Апацхе и можда МиСКЛ. Слика је велика и виртуелна машина је незгодна за рад. Као резултат тога, рад са виртуелним машинама може бити спор. Да би се решио овај проблем, креирани су системи виртуелизације на нивоу кернела.

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

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

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

У суштини ЛКСЦ ствара контејнере. Која је разлика између виртуелних машина и контејнера?

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

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

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

Постоје хипервизори као програм, а постоје и контејнери и о њима ћемо даље. Системи за контејнеризацију немају хипервизор, али постоји Цонтаинер Енгине који креира контејнере и управља њима. Ова ствар је лакша, тако да због рада са језгром има мање трошкова или их уопште нема.

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

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

Простори имена: ПИД, Нетворкинг, Моунт и Усер. Има их још, али ради лакшег разумевања фокусираћемо се на ове.

ПИД Именски простор ограничава процесе. Када, на пример, креирамо ПИД Намеспаце и тамо поставимо процес, он постаје са ПИД 1. Обично је у системима ПИД 1 системд или инит. Сходно томе, када поставимо процес у нови простор имена, он такође добија ПИД 1.

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

Контролне групе: Меморија, ЦПУ, ИОПС, Мрежа - око 12 подешавања укупно. Иначе се називају и Ц-групе („Ц-групе”).

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

Да би контејнеризација функционисала у потпуности, користе се додатне технологије: Могућности, Цопи-он-врите и друге.

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

Систем Цопи-он-врите нам омогућава да радимо са Доцкер сликама и да их ефикасније користимо.

Доцкер тренутно има проблема са компатибилношћу са Цгроупс в2, тако да се овај чланак посебно фокусира на Цгроупс в1.

Али вратимо се историји.

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

• велике слике: гурају оперативни систем, библиотеке, гомилу различитог софтвера у исти ОпенВЗ, и на крају се слика и даље испоставља прилично велика;
• Не постоји нормалан стандард за паковање и испоруку, тако да остаје проблем зависности. Постоје ситуације када два дела кода користе исту библиотеку, али са различитим верзијама. Може доћи до сукоба између њих.

За решавање свих ових проблема дошло је следеће доба.

Контејнерска ера

Када је наступила ера контејнера, филозофија рада са њима се променила:

• Један процес - један контејнер.
• Испоручујемо све зависности које су потребне процесу у његов контејнер. Ово захтева сечење монолита у микросервисе.
• Што је слика мања, то боље – мање је могућих рањивости, брже се развија и тако даље.
• Случајеви постају ефемерни.

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

У 2014-2015, Доцкер је процветао - технологија о којој ћемо сада причати.

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

Стављамо све што нам је потребно у Доцкер контејнер, тако да је проблем зависности решен. Доцкер гарантује поновљивост. Мислим да су се многи људи сусрели са непоновљивошћу: све ти ради, гурнеш то у производњу и тамо престане да ради. Са Доцкер-ом овај проблем нестаје. Ако се ваш Доцкер контејнер покрене и уради оно што треба да уради, онда ће са великим степеном вероватноће почети у производњи и урадити исто тамо.

Дигресија о режији

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

С друге стране, ако зађете дубље, заиста постоји неколико ствари у Доцкер-у за које се, уз натезање, може рећи да су изнад главе.

Први је ПИД именски простор. Када поставимо процес у именски простор, њему се додељује ПИД 1. У исто време, овај процес има још један ПИД, који се налази на хост именском простору, изван контејнера. На пример, покренули смо Нгинк у контејнеру, постао је ПИД 1 (мастер процес). А на хосту има ПИД 12623. И тешко је рећи колики су то трошкови.

Друга ствар су Цгроупс. Узмимо Цгроупс по меморији, односно по могућности ограничавања меморије неког контејнера. Када је омогућено, активирају се бројачи и обрачун меморије: кернел треба да разуме колико је страница додељено и колико је још слободних за овај контејнер. Ово је вероватно додатни трошак, али нисам видео ниједну прецизну студију о томе како то утиче на перформансе. И сам нисам приметио да је апликација која ради у Доцкер-у изненада доживела оштар губитак у перформансама.

И још једна напомена о перформансама. Неки параметри кернела се прослеђују са хоста на контејнер. Конкретно, неки мрежни параметри. Стога, ако желите да покренете нешто високих перформанси у Доцкер-у, на пример, нешто што ће активно користити мрежу, онда барем морате да прилагодите ове параметре. Неки нф_цоннтрацк, на пример.

О концепту Доцкер

Доцкер се састоји од неколико компоненти:

1. Доцкер Даемон је исти Цонтаинер Енгине; лансира контејнере.
2. Доцкер ЦИИ је услужни програм за управљање Доцкер-ом.
3. Доцкерфиле - упутства о томе како да направите слику.
4. Слика — слика из које је контејнер извучен.
5. Контејнер.
6. Доцкер регистар је спремиште слика.

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

Доцкер демон ради на Доцкер_хост и покреће контејнере. Постоји клијент који шаље команде: направите слику, преузмите слику, покрените контејнер. Доцкер демон иде у регистар и извршава их. Доцкер клијент може приступити и локално (у Уник соцкет) и преко ТЦП-а са удаљеног хоста.

Хајде да прођемо кроз сваку компоненту.

Доцкер демон - ово је серверски део, ради на главној машини: преузима слике и покреће контејнере из њих, креира мрежу између контејнера, прикупља евиденције. Када кажемо „направи слику“, демон то такође ради.

Доцкер ЦЛИ — Доцкер клијентски део, конзолни услужни програм за рад са демоном. Понављам, може да ради не само локално, већ и преко мреже.

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

доцкер пс - прикажи контејнере који тренутно раде на Доцкер хосту.
доцкер слике - приказују слике преузете локално.
доцкер сеарцх <> - тражи слику у регистру.
доцкер пулл <> - преузимање слике из регистра на машину.
доцкер буилд < > - прикупи слику.
доцкер рун <> - покретање контејнера.
доцкер рм <> - уклоните контејнер.
доцкер логс <> - евиденције контејнера
доцкер старт/стоп/рестарт <> - рад са контејнером

Ако савладате ове команде и сигурни сте да их користите, сматрајте да сте 70% искусни у Доцкер-у на нивоу корисника.

Доцкерфиле - упутства за креирање слике. Скоро свака наредба инструкција је нови слој. Погледајмо пример.

Овако изгледа Доцкерфиле: команде на левој страни, аргументи на десној страни. Свака команда која је овде (и генерално написана у Доцкерфиле-у) креира нови слој у Имаге-у.

Чак и ако погледате леву страну, можете отприлике разумети шта се дешава. Кажемо: „направите фасциклу за нас“ - ово је један слој. „Направи фасциклу да ради“ је још један слој, и тако даље. Слојевити колач олакшава живот. Ако направим други Доцкерфиле и променим нешто у последњем реду – покренем нешто друго осим „питхон“ „маин.пи“, или инсталирам зависности из друге датотеке – претходни слојеви ће се поново користити као кеш.

Слика - ово је контејнерска амбалажа се покреће са слике. Ако посматрамо Доцкер са становишта менаџера пакета (као да радимо са деб или рпм пакетима), онда је слика у суштини рпм пакет. Кроз иум инсталл можемо инсталирати апликацију, обрисати је, пронаћи је у спремишту и преузети. Овде је отприлике исто: контејнери се покрећу са слике, чувају се у Доцкер регистру (слично као иум, у спремишту), а свака слика има СХА-256 хеш, име и ознаку.

Слика је направљена према упутствима из Доцкерфиле-а. Свака инструкција из Доцкерфиле-а ствара нови слој. Слојеви се могу поново користити.

Доцкер регистар је Доцкер спремиште слика. Слично ОС-у, Доцкер има јавни стандардни регистар - доцкерхуб. Али можете да направите сопствено спремиште, сопствени Доцкер регистар.

Контејнер - шта се покреће са слике. Направили смо слику према упутствима из Доцкерфиле-а, а затим је покрећемо са ове слике. Овај контејнер је изолован од других контејнера мора да садржи све што је потребно за рад апликације. У овом случају, један контејнер - један процес. Дешава се да морате да урадите два процеса, али то је донекле супротно Доцкер идеологији.

Захтев „један контејнер, један процес“ повезан је са простором имена ПИД. Када процес са ПИД 1 започне у Намеспацеу, ако изненада умре, умире и цео контејнер. Ако се тамо покрећу два процеса: један је жив, а други мртав, онда ће контејнер и даље наставити да живи. Али ово је питање најбољих пракси, о њима ћемо говорити у другим материјалима.

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

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

Извор: ввв.хабр.цом