10 тамызда Слурм қаласында басталды , онда біз оны толығымен талдаймыз - негізгі абстракциялардан желі параметрлеріне дейін.
Бұл мақалада біз Docker тарихы және оның негізгі абстракциялары туралы айтатын боламыз: Image, Cli, Dockerfile. Дәріс жаңадан бастаушыларға арналған, сондықтан тәжірибелі қолданушыларды қызықтыруы екіталай. Қан, аппендис немесе терең батыру болмайды. Ең негіздері.
Docker дегеніміз не
Википедиядағы Docker анықтамасын қарастырайық.
Docker - бұл контейнерлік орталарда қолданбаларды орналастыру мен басқаруды автоматтандыруға арналған бағдарламалық құрал.
Бұл анықтамадан ештеңе анық емес. Әсіресе «контейнерлеуді қолдайтын орталарда» деген нені білдіретіні түсініксіз. Мұны білу үшін өткенге оралайық. Мен шартты түрде «Монолит дәуірі» деп атайтын дәуірден бастайық.
Монолит дәуірі
Монолитті дәуір - 2000-шы жылдардың басы, ол кезде барлық қосымшалар монолитті және көптеген тәуелділіктермен болды. Даму ұзаққа созылды. Сонымен қатар, серверлер көп болмады, біз барлығымыз оларды атымен білдік және оларды бақылап отырдық. Мұндай күлкілі салыстыру бар:
Үй жануарлары үй жануарлары. Монолитті дәуірде біз өз серверлерімізді үй жануарлары ретінде қарастырдық, оларды күтіп-баптап, шаңның дақтарын кетірдік. Ал ресурстарды жақсырақ басқару үшін біз виртуализацияны қолдандық: біз серверді алып, оны бірнеше виртуалды машиналарға бөлдік, осылайша қоршаған ортаның оқшаулануын қамтамасыз еттік.
Гипервизор негізіндегі виртуалдандыру жүйелері
Виртуализация жүйелері туралы бәрі естіген шығар: VMware, VirtualBox, Hyper-V, Qemu KVM және т.б. Олар қолданбаларды оқшаулауды және ресурстарды басқаруды қамтамасыз етеді, бірақ олардың кемшіліктері де бар. Виртуализация жасау үшін сізге гипервизор қажет. Ал гипервизор – бұл қосымша ресурстар. Виртуалды машинаның өзі әдетте тұтас үлкен кескін болып табылады - операциялық жүйе, Nginx, Apache және мүмкін MySQL бар ауыр кескін. Кескін үлкен және виртуалды машина жұмыс істеуге ыңғайсыз. Нәтижесінде виртуалды машиналармен жұмыс істеу баяу болуы мүмкін. Бұл мәселені шешу үшін ядро деңгейінде виртуализация жүйелері құрылды.
Ядролық деңгейдегі виртуалдандыру жүйелері
Ядро деңгейіндегі виртуализацияға OpenVZ, Systemd-nspawn, LXC жүйелері қолдау көрсетеді. Мұндай виртуалдандырудың жарқын мысалы - LXC (Linux контейнерлері).
LXC — Linux операциялық жүйесінің бірнеше оқшауланған даналарын бір түйінде іске қосуға арналған операциялық жүйе деңгейіндегі виртуалдандыру жүйесі. LXC виртуалды машиналарды пайдаланбайды, бірақ өзінің процесс кеңістігі мен желі стекімен виртуалды ортаны жасайды.
Негізінде LXC контейнерлерді жасайды. Виртуалды машиналар мен контейнерлердің айырмашылығы неде?
Контейнер процестерді оқшаулау үшін жарамсыз: осалдықтар контейнерден хостқа өтуге мүмкіндік беретін ядро деңгейіндегі виртуалдандыру жүйелерінде кездеседі. Сондықтан, бір нәрсені оқшаулау қажет болса, виртуалды машинаны қолданған дұрыс.
Виртуализация мен контейнерлеу арасындағы айырмашылықтарды диаграммадан көруге болады.
Аппараттық гипервизорлар, ОЖ үстіңгі жағындағы гипервизорлар және контейнерлер бар.
Аппараттық гипервизорлар шынымен бірдеңені оқшаулағыңыз келсе керемет. Өйткені жад беттері мен процессорлар деңгейінде оқшаулауға болады.
Бағдарлама ретінде гипервизорлар бар және контейнерлер бар, біз олар туралы әрі қарай сөйлесеміз. Контейнерлеу жүйелерінде гипервизор жоқ, бірақ контейнерлерді жасайтын және басқаратын Контейнер қозғалтқышы бар. Бұл зат жеңілірек, сондықтан ядромен жұмыс істеудің арқасында үстеме аз немесе мүлде болмайды.
Ядро деңгейінде контейнерлеу үшін не қолданылады
Басқа процестерден оқшауланған контейнер жасауға мүмкіндік беретін негізгі технологиялар аттар кеңістігі және басқару топтары болып табылады.
Атау кеңістігі: PID, желі, орнату және пайдаланушы. Тағы да бар, бірақ түсіну жеңілдігі үшін біз осыларға тоқталамыз.
PID аттар кеңістігі процестерді шектейді. Мысалы, біз PID аттар кеңістігін жасап, сол жерге процесті орналастырғанда, ол PID 1-мен болады. Әдетте жүйелерде PID 1 жүйелік немесе init болып табылады. Сәйкесінше, процесті жаңа аттар кеңістігіне орналастырған кезде, ол PID 1 алады.
Желілік атаулар кеңістігі желіні шектеуге/оқшаулауға және өзіңіздің интерфейстеріңізді ішіне орналастыруға мүмкіндік береді. Mount файлдық жүйенің шектеуі болып табылады. Пайдаланушы — пайдаланушыларға шектеу.
Басқару топтары: жад, процессор, IOPS, желі – барлығы шамамен 12 параметр. Әйтпесе, оларды Cgroups («C-топтары») деп те атайды.
Басқару топтары контейнерге арналған ресурстарды басқарады. Бақылау топтары арқылы контейнер белгілі бір мөлшерден артық ресурстарды тұтынбауы керек деп айта аламыз.
Контейнерлеу толық жұмыс істеуі үшін қосымша технологиялар қолданылады: Мүмкіндіктер, Copy-on-write және т.б.
Мүмкіндіктер - бұл процеске оның не істей алатынын және не істей алмайтынын айтқан кезде. Ядро деңгейінде бұл жай ғана көптеген параметрлері бар нүктелік кескіндер. Мысалы, түбірлік пайдаланушы толық артықшылықтарға ие және бәрін жасай алады. Уақыт сервері жүйе уақытын өзгерте алады: оның 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 қосымша жүктемені көтермейді деп санайды, өйткені ол Linux ядросын және контейнерлеуге қажетті оның барлық процестерін пайдаланады. Мысалы, «егер сіз Docker үстеме жұмыс істейді десеңіз, онда Linux ядросы жоғары болады».
Екінші жағынан, егер сіз тереңірек үңілсеңіз, Докерде шынымен де бірнеше нәрсе бар, оларды созу арқылы үстеме деп айтуға болады.
Біріншісі - PID аттар кеңістігі. Процесті аттар кеңістігіне орналастырған кезде, оған PID 1 тағайындалады. Сонымен бірге, бұл процесте басқа PID бар, ол хост аттар кеңістігінде, контейнерден тыс орналасқан. Мысалы, біз Nginx-ті контейнерде іске қостық, ол PID 1 (мастер процесс) болды. Ал хостта оның PID 12623 бар. Оның қаншалықты үстеме шығын екенін айту қиын.
Екінші нәрсе - Cgroups. Жады бойынша Cgroups алайық, яғни контейнердің жадысын шектеу мүмкіндігі. Ол қосылған кезде есептегіштер мен жадты есепке алу іске қосылады: ядро қанша бет бөлінгенін және осы контейнер үшін қаншасы әлі бос екенін түсінуі керек. Бұл қосымша шығындар болуы мүмкін, бірақ мен оның өнімділікке қалай әсер ететіні туралы нақты зерттеулерді көрмедім. Мен өзім Docker-те жұмыс істейтін қосымшаның кенеттен өнімділігін күрт жоғалтқанын байқамадым.
Және өнімділік туралы тағы бір ескерту. Кейбір ядро параметрлері хосттан контейнерге беріледі. Атап айтқанда, кейбір желі параметрлері. Сондықтан, егер сіз Docker-те өнімділігі жоғары нәрсені, мысалы, желіні белсенді түрде пайдаланатын нәрсені іске қосқыңыз келсе, кем дегенде осы параметрлерді реттеу қажет. Кейбір nf_conntrack, мысалы.
Docker концепциясы туралы
Docker бірнеше компоненттерден тұрады:
- Docker Daemon - бірдей контейнерлік қозғалтқыш; контейнерлерді іске қосады.
- Docker CII — Docker басқару утилитасы.
- Dockerfile - кескінді құру туралы нұсқаулар.
- Кескін — контейнер шығарылатын сурет.
- Контейнер.
- Docker тізілімі - кескін репозиторийі.
Схемалық түрде ол келесідей көрінеді:
Docker демоны Docker_host жүйесінде жұмыс істейді және контейнерлерді іске қосады. Пәрмендерді жіберетін Клиент бар: суретті құрастыру, суретті жүктеп алу, контейнерді іске қосу. Докер демоны тізілімге кіріп, оларды орындайды. Docker клиенті жергілікті түрде де (Unix ұясына) және қашықтағы хосттан TCP арқылы қол жеткізе алады.
Әр компонентті қарастырайық.
Докер демоны - бұл сервер бөлігі, ол негізгі компьютерде жұмыс істейді: суреттерді жүктеп алады және олардан контейнерлерді іске қосады, контейнерлер арасында желі жасайды, журналдарды жинайды. Біз «бейне жасау» десек, жын да солай істейді.
Docker CLI — Docker клиент бөлігі, демонмен жұмыс істеуге арналған консольдік утилита. Қайталап айтамын, ол жергілікті ғана емес, желі арқылы да жұмыс істей алады.
Негізгі командалар:
docker ps - қазіргі уақытта Docker хостында жұмыс істейтін контейнерлерді көрсету.
докер суреттері - жергілікті түрде жүктелген кескіндерді көрсетеді.
docker search <> - тізілімдегі суретті іздеу.
docker pull <> - кескінді тізілімнен құрылғыға жүктеп алу.
докер құрастыру < > - суретті жинау.
docker run <> - контейнерді іске қосу.
docker rm <> - контейнерді алып тастаңыз.
докер журналдары <> - контейнер журналдары
docker start/stop/restart <> - контейнермен жұмыс істеу
Егер сіз осы пәрмендерді меңгерсеңіз және оларды пайдалануға сенімді болсаңыз, өзіңізді пайдаланушы деңгейінде Docker бағдарламасын 70% меңгерген деп есептеңіз.
Докер файлы - суретті құру нұсқаулары. Әрбір дерлік нұсқаулық пәрмені жаңа қабат болып табылады. Бір мысалды қарастырайық.
Dockerfile осылай көрінеді: сол жақта командалар, оң жақта аргументтер. Мұнда (және әдетте Dockerfile файлында жазылған) әрбір пәрмен Image ішінде жаңа қабатты жасайды.
Тіпті сол жаққа қарасаңыз да, не болып жатқанын шамамен түсінуге болады. Біз айтамыз: «біз үшін қалта жасаңыз» - бұл бір қабат. «Қалтаны жұмыс істейтін етіп жасау» басқа қабат және т.б. Қабатты торт өмірді жеңілдетеді. Егер мен басқа Dockerfile жасасам және соңғы жолда бір нәрсені өзгертсем - «python» «main.py» емес басқа нәрсені іске қосамын немесе басқа файлдан тәуелділіктерді орнатамын - онда алдыңғы қабаттар кэш ретінде қайта пайдаланылады.
бейне - бұл контейнерлік қаптама; контейнерлер суреттен іске қосылады. Егер біз Docker-ті пакет менеджері тұрғысынан қарастырсақ (біз deb немесе rpm пакеттерімен жұмыс істегендей), онда кескін негізінен rpm пакеті болып табылады. yum install арқылы біз қолданбаны орнатып, оны жоя аламыз, репозиторийден тауып, жүктей аламыз. Мұнда шамамен бірдей: контейнерлер кескіннен іске қосылады, олар Docker тізілімінде сақталады (yum сияқты, репозиторийде) және әр суретте SHA-256 хэш, атау және тег бар.
Кескін Dockerfile нұсқауларына сәйкес құрастырылған. Dockerfile әрбір нұсқауы жаңа қабат жасайды. Қабаттарды қайта пайдалануға болады.
Docker тізілімі Docker кескіндерінің репозиторийі болып табылады. Операциялық жүйеге ұқсас, Docker жалпыға ортақ стандартты тізілімге ие - dockerhub. Бірақ сіз өзіңіздің репозиторийіңізді, жеке Docker тізілімін құра аласыз.
контейнер - суреттен не іске қосылады. Біз Dockerfile нұсқауларына сәйкес кескінді құрастырдық, содан кейін оны осы кескіннен іске қосамыз. Бұл контейнер басқа контейнерлерден оқшауланған және қолданбаның жұмыс істеуі үшін қажеттінің барлығын қамтуы керек. Бұл жағдайда бір контейнер – бір процесс. Сізге екі процесті орындау керек болады, бірақ бұл Docker идеологиясына қайшы келеді.
«Бір контейнер, бір процесс» талабы PID аттар кеңістігіне қатысты. PID 1 бар процесс атаулар кеңістігінде басталғанда, егер ол кенеттен өлсе, онда бүкіл контейнер де өледі. Егер ол жерде екі процесс орындалса: біреуі тірі, екіншісі өлі болса, контейнер әлі де өмір сүре береді. Бірақ бұл ең жақсы тәжірибе туралы мәселе, біз олар туралы басқа материалдарда айтатын боламыз.
Курстың мүмкіндіктері мен толық бағдарламасын толығырақ оқу үшін мына сілтемеге өтіңіз: ««.
Авторы: Марсель Ибраев, Kubernetes сертификатталған әкімшісі, Southbridge-те тәжірибелік инженер, Slurm курстарының спикері және әзірлеушісі.
Ақпарат көзі: www.habr.com