Слурмда 10-августта башталган , анда биз аны толугу менен талдайбыз - негизги абстракциялардан тармак параметрлерине чейин.
Бул макалада биз Докердин тарыхы жана анын негизги абстракциялары жөнүндө сүйлөшөбүз: Image, Cli, Dockerfile. Лекция үйрөнчүктөр үчүн арналган, ошондуктан тажрыйбалуу колдонуучулар үчүн кызыктуу болушу күмөн. Кан, сокур ичеги же терең чөмүлүү болбойт. Негизгилер.
Docker деген эмне
Википедиядан Докердин аныктамасын карап көрөлү.
Docker - бул контейнердик чөйрөлөрдө тиркемелерди жайгаштырууну жана башкарууну автоматташтыруу үчүн программалык камсыздоо.
Бул аныктамадан эч нерсе айкын эмес. Айрыкча "контейнерлештирүүнү колдогон чөйрөдө" деген эмнени билдирери белгисиз. Муну билүү үчүн, келгиле, убакытты артка кайтаралы. Мен шарттуу түрдө “монолит доору” деп атаган доордон баштайлы.
Монолит доору
Монолиттик доор - бул 2000-жылдардын башында, бардык тиркемелер бир топ көз карандылык менен монолиттүү болгон. Иштеп чыгуу көп убакытты талап кылды. Ошол эле учурда серверлер көп болгон жок, биз бардыгыбыз аты-жөнүн билип, көзөмөлдөп турчубуз. Мындай күлкүлүү салыштыруу бар:
Үй жаныбарлары үй жаныбарлары. Монолиттик доордо биз серверлерибизге үй жаныбарларындай мамиле кылып, аларды багып, бапестеп, чаңдын тактарын кетирчүбүз. Ал эми ресурстарды жакшыраак башкаруу үчүн биз виртуалдаштырууну колдондук: биз серверди алып, аны бир нече виртуалдык машиналарга бөлдүк, ошону менен чөйрөнүн изоляциясын камсыз кылдык.
Гипервизорго негизделген виртуалдаштыруу системалары
Виртуалдаштыруу системалары жөнүндө ар бир адам уккандыр: VMware, VirtualBox, Hyper-V, Qemu KVM ж.б. Алар тиркемелерди изоляциялоону жана ресурстарды башкарууну камсыз кылат, бирок алардын кемчиликтери да бар. Виртуалдаштыруу үчүн сизге гипервизор керек. Ал эми гипервизор бул ресурстук ашыкча чыгым. Ал эми виртуалдык машинанын өзү адатта бүтүндөй бир чоң сүрөт - Nginx, Apache жана мүмкүн MySQL операциялык тутумун камтыган оор сүрөт. Сүрөт чоң жана виртуалдык машина иштөөгө ыңгайсыз. Натыйжада, виртуалдык машиналар менен иштөө жай болушу мүмкүн. Бул көйгөйдү чечүү үчүн ядро деңгээлинде виртуалдаштыруу системалары түзүлгөн.
Ядро деңгээлиндеги виртуалдаштыруу системалары
Ядро деңгээлиндеги виртуалдаштыруу OpenVZ, Systemd-nspawn, LXC системалары тарабынан колдоого алынат. Мындай виртуалдаштыруунун айкын мисалы LXC (Linux контейнерлери).
LXC - бул Linux операциялык тутумунун бир нече изоляцияланган инстанцияларын бир түйүндө иштетүү үчүн иштөө тутумунун деңгээлиндеги виртуалдаштыруу системасы. LXC виртуалдык машиналарды колдонбойт, бирок өзүнүн процесстик мейкиндиги жана тармактык стек менен виртуалдык чөйрөнү түзөт.
Негизи LXC контейнерлерди түзөт. Виртуалдык машиналар менен контейнерлердин ортосунда кандай айырма бар?
Контейнер процесстерди изоляциялоо үчүн ылайыктуу эмес: ядро деңгээлинде виртуалдаштыруу тутумдарында алсыздыктар табылган, алар контейнерден хостко өтүп кетүүгө мүмкүндүк берет. Ошондуктан, бир нерсени изоляциялоо керек болсо, виртуалдык машинаны колдонуу жакшы.
Виртуалдаштыруу жана контейнерлештирүү ортосундагы айырмачылыктарды диаграммадан көрүүгө болот.
Аппараттык гипервизорлор, ОСтун үстүндө гипервизорлор жана контейнерлер бар.
Аппараттык гипервизорлор сонун, эгер сиз чындап эле бир нерсени бөлүп алгыңыз келсе. Анткени эстутум барактарынын жана процессорлордун деңгээлинде изоляциялоого болот.
Программа катары гипервизорлор бар жана контейнерлер бар, биз алар жөнүндө мындан ары да сүйлөшөбүз. Контейнерлештирүү системаларында гипервизор жок, бирок контейнерлерди түзгөн жана башкарган Контейнер кыймылдаткычы бар. Бул нерсе жеңилирээк, ошондуктан өзөк менен иштөөдөн улам ашыкча чыгым азыраак же такыр жок.
Ядро деңгээлинде контейнерлөө үчүн эмне колдонулат
Башка процесстерден обочолонгон контейнерди түзүүгө мүмкүндүк берген негизги технологиялар бул Namespaces жана Control Groups.
Ат мейкиндиктери: PID, Networking, Mount жана User. Дагы бар, бирок түшүнүү үчүн биз буларга токтолобуз.
PID ысым мейкиндиги процесстерди чектейт. Мисалы, биз PID ысым мейкиндигин түзүп, ал жерге процессти койгондо, ал PID 1 менен болот. Адатта PID 1 системаларда системалык же init болот. Демек, процессти жаңы аталыш мейкиндигине койгондо, ал PID 1 алат.
Networking Namespace тармакты чектөөгө/обочолонтууга жана өз интерфейстериңизди ичине жайгаштырууга мүмкүндүк берет. Mount бул файл тутумунун чектөөсү. Колдонуучу — колдонуучуларга чектөө.
Башкаруу топтору: эс тутум, CPU, IOPS, тармак - жалпысынан 12ге жакын орнотуулар. Болбосо, алар Cgroups («C-топтору») деп да аталат.
Контролдук топтор контейнер үчүн ресурстарды башкарат. Контролдук топтор аркылуу биз контейнер белгилүү бир өлчөмдөгү ресурстарды керектебеши керек деп айта алабыз.
Контейнеризация толук иштеши үчүн кошумча технологиялар колдонулат: Мүмкүнчүлүктөр, Копиялоо жана жазуу жана башкалар.
Мүмкүнчүлүктөр - бул процесске ал эмне кыла аларын жана эмнелерди кыла албасын айтканыбызда. Ядро деңгээлинде булар жөн гана көптөгөн параметрлери бар битмаптар. Мисалы, түпкү колдонуучу толук артыкчылыктарга ээ жана бардыгын жасай алат. Убакыт сервери системанын убактысын өзгөртө алат: анын Убакыт капсуласында мүмкүнчүлүктөрү бар жана бүттү. Артыкчылыктарды колдонуу менен процесстерге чектөөлөрдү ийкемдүү конфигурациялай аласыз жана ошону менен өзүңүздү коргой аласыз.
Copy-on-write системасы бизге Docker сүрөттөрү менен иштөөгө жана аларды эффективдүү колдонууга мүмкүндүк берет.
Учурда Докерде Cgroups v2 менен шайкештик көйгөйлөрү бар, андыктан бул макала өзгөчө Cgroups v1ге багытталган.
Бирок тарыхка кайрылалы.
Виртуалдаштыруу системалары ядро деңгээлинде пайда болгондо, алар активдүү колдонула баштаган. Гипервизордон ашыкча чыгым жок болду, бирок кээ бир көйгөйлөр кала берди:
- чоң сүрөттөр: алар бир эле OpenVZге операциялык тутумду, китепканаларды, ар кандай программалык камсыздоону түртүшөт жана акырында сүрөт дагы эле чоң болуп чыгат;
- Таңгактоо жана жеткирүү боюнча нормалдуу стандарт жок, ошондуктан көз карандылык маселеси сакталууда. Коддун эки даанасы бир китепкананы колдонгон, бирок ар кандай версиялары бар жагдайлар бар. Алардын ортосунда конфликт болушу мүмкүн.
Бул көйгөйлөрдүн баарын чечүү үчүн кийинки доор келди.
Контейнер доору
Контейнерлер доору келгенде, алар менен иштөө философиясы өзгөрдү:
- Бир процесс - бир контейнер.
- Биз процесске керек болгон бардык көз карандылыктарды анын контейнерине жеткиребиз. Бул микросервистерге монолиттерди кесүүнү талап кылат.
- Сүрөт канчалык кичине болсо, ошончолук жакшы - мүмкүн болгон кемчиликтер азыраак болот, ал тезирээк чыгат жана башкалар.
- Инстанциялар эфемердик болуп калат.
Үй жаныбарлары жана бодо малдар жөнүндө айтканымды эстейсизби? Мурда инстанциялар үй жаныбарларындай болсо, азыр бодо малдай болуп калды. Мурда монолит болгон - бир арыз. Азыр бул 100 микросервис, 100 контейнер. Кээ бир контейнерлерде 2-3 реплика болушу мүмкүн. Биз үчүн ар бир контейнерди көзөмөлдөө анча маанилүү болбой калат. Биз үчүн эң маанилүүсү – бул кызматтын жеткиликтүүлүгү: бул контейнерлердин топтому эмне кылат. Бул мониторинг жүргүзүү ыкмаларын өзгөртөт.
2014-2015-жылдары Docker гүлдөдү - биз азыр сүйлөшө турган технология.
Докер философияны жана стандартташтырылган колдонмолордун таңгагын өзгөрттү. Dockerдин жардамы менен биз тиркемени пакеттеп, репозиторийге жөнөтүп, аны ошол жерден жүктөп алып, жайылта алабыз.
Биз Docker контейнерине керектүү нерселердин баарын салабыз, ошондуктан көз карандылык маселеси чечилди. Docker кайталанууга кепилдик берет. Менимче, көп адамдар кайталанбастыкка туш болушту: баары сиз үчүн иштейт, сиз аны өндүрүшкө түртөсүз, ошондо ал иштебей калат. Docker менен бул көйгөй жок болот. Эгерде сиздин Docker контейнериңиз башталса жана эмне кылышы керек болсо, анда ал өндүрүштө башталып, ошол жерде да ушундай кылат.
Үстүңкү чыгымдар жөнүндө чегинүү
Ар дайым ашыкча чыгымдар боюнча талаш-тартыштар бар. Кээ бир адамдар Docker кошумча жүк көтөрбөйт деп эсептешет, анткени ал Linux ядросун жана контейнерлештирүү үчүн зарыл болгон бардык процесстерди колдонот. Мисалы, "эгерде сиз Докердин үстүңкү экенин айтсаңыз, анда 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 ps - учурда Docker хостунда иштеп жаткан контейнерлерди көрсөтүү.
докер сүрөттөрү - жергиликтүү түрдө жүктөлүп алынган сүрөттөрдү көрсөтүү.
докер издөө <> - реестрдеги сүрөттү издөө.
docker pull <> - реестрден сүрөттү машинага жүктөө.
докер куруу < > - сүрөттү чогултуу.
docker run <> - контейнерди ишке киргизүү.
docker rm <> - контейнерди алып салуу.
докер журналдары <> - контейнер журналдары
docker start/stop/restart <> - контейнер менен иштөө
Эгер сиз бул буйруктарды өздөштүрсөңүз жана аларды колдонууга ишенсеңиз, өзүңүздү Docker программасын колдонуучу деңгээлинде 70% билдим деп эсептеңиз.
докер файлы - сүрөттү түзүү боюнча нускамалар. Дээрлик ар бир нускама буйругу жаңы катмар болуп саналат. Келгиле, бир мисал карап көрөлү.
Dockerfile ушундай көрүнөт: сол жакта буйруктар, оң жакта аргументтер. Бул жердеги ар бир буйрук (жана жалпысынан Dockerfileде жазылган) Сүрөттө жаңы катмарды түзөт.
Ал тургай, сол жагына карап, сиз болжол менен эмне болуп жатканын түшүнүүгө болот. Биз айтабыз: "бизге папка түзүңүз" - бул бир катмар. "Папканы иштетүү" дагы бир катмар жана башкалар. Кабат торт жашоону жеңилдетет. Эгерде мен башка Dockerfile түзсөм жана акыркы сапта бир нерсени өзгөртсөм - "python" "main.py" эмес, башка бир нерсени иштетсем же башка файлдан көз карандылыкты орнотсам - анда мурунку катмарлар кэш катары кайра колдонулат.
Image - бул контейнер таңгак; контейнерлер сүрөттөн ишке киргизилген. Эгер биз Dockerди пакет менеджеринин көз карашынан карасак (биз deb же rpm пакеттери менен иштеп жаткандай), анда сүрөт негизинен rpm пакети болуп саналат. yum install аркылуу биз тиркемени орнотуп, өчүрүп, репозиторийден таап, жүктөй алабыз. Бул жерде болжол менен бирдей: контейнерлер сүрөттөн ишке киргизилет, алар Docker реестринде сакталат (yumга окшош, репозиторийде) жана ар бир сүрөттө SHA-256 хэш, аты жана теги бар.
Сүрөт Dockerfile көрсөтмөлөрүнө ылайык курулган. Dockerfile ар бир нускама жаңы катмарды түзөт. Катмарларды кайра колдонсо болот.
Докер реестри Докер сүрөт репозиторийси болуп саналат. OS сыяктуу, Docker коомдук стандарттуу реестрге ээ - dockerhub. Бирок сиз өзүңүздүн репозиторийиңизди, өзүңүздүн Docker реестриңизди кура аласыз.
контейнер - сүрөттөн эмне башталат. Биз Dockerfile нускамаларына ылайык сүрөт курдук, андан кийин аны ушул сүрөттөн ишке киргиздик. Бул контейнер башка контейнерлерден обочолонгон жана колдонмо иштеши үчүн зарыл болгон нерселердин баарын камтышы керек. Бул учурда, бир контейнер - бир процесс. Сиз эки процессти жасашыңыз керек болот, бирок бул Докер идеологиясына бир аз карама-каршы келет.
"Бир контейнер, бир процесс" талабы PID ысым мейкиндигине байланыштуу. PID 1 менен процесс Namespaceде башталганда, ал күтүлбөгөн жерден өлсө, анда бүт контейнер да өлөт. Эгерде ал жерде эки процесс жүрүп жатса: бири тирүү, экинчиси өлүк болсо, анда контейнер дагы эле жашай берет. Бирок бул алдыцкы тажрыйбалар женундегу маселе, биз алар женунде башка материалдарда кеп кылабыз.
Курстун өзгөчөлүктөрүн жана толук программасын кененирээк изилдөө үчүн шилтемени басыңыз: “«.
Автор: Марсель Ибраев, Кубернетестин сертификатталган администратору, Саутбриджде практикалык инженер, Slurm курстарынын спикери жана иштеп чыгуучусу.
Source: www.habr.com