Докер гэж юу вэ: Түүх, үндсэн хийсвэрлэлүүдийн талаархи товч аялал

10-р сарын XNUMX-нд Slurm-д эхэлсэн Докерын видео курс, үүнд бид үүнийг бүрэн шинжилдэг - үндсэн хийсвэрлэлээс сүлжээний параметрүүд хүртэл.

Энэ нийтлэлд бид Docker-ийн түүх ба түүний үндсэн хийсвэрлэлүүдийн талаар ярих болно: Image, Cli, Dockerfile. Лекц нь эхлэгчдэд зориулагдсан тул туршлагатай хэрэглэгчдэд сонирхолтой байх магадлал багатай юм. Цус, мухар олгойн, гүн гүнзгий дүрэлзэхгүй. Хамгийн суурь.

Docker гэж юу вэ

Wikipedia-аас Docker-ийн тодорхойлолтыг харцгаая.

Docker нь контейнерт агуулагдсан орчинд програмуудыг байршуулах, удирдах ажлыг автоматжуулах програм хангамж юм.

Энэ тодорхойлолтоос тодорхой зүйл алга. Ялангуяа "чингэлэгийг дэмждэг орчинд" гэдэг нь юу гэсэн үг вэ гэдэг нь тодорхойгүй байна. Үүнийг олж мэдэхийн тулд өнгөрсөн үе рүү буцъя. Миний уламжлалт ёсоор “Цул эрин” гэж нэрлэдэг эрин үеэс эхэлье.

Цул эрин үе

Цул эрин үе бол 2000-аад оны эхэн үе бөгөөд бүх хэрэглээ нь цул, олон хамааралтай байсан. Хөгжил нь нэлээд удаан үргэлжилсэн. Үүний зэрэгцээ серверүүд тийм ч олон байсангүй, бид бүгд нэрээр нь мэддэг, хянаж байсан. Ийм хөгжилтэй харьцуулалт байна:

Гэрийн тэжээмэл амьтад бол гэрийн тэжээвэр амьтад юм. Цул эрин үед бид серверүүддээ гэрийн тэжээвэр амьтан шиг хандаж, арчлан, нандигнаж, тоос шороог нь үлээдэг байсан. Нөөцийн менежментийг сайжруулахын тулд бид виртуалчлалыг ашигласан: бид сервер авч, хэд хэдэн виртуал машин болгон хуваасан, ингэснээр хүрээлэн буй орчны тусгаарлалтыг хангасан.

Гипервизорт суурилсан виртуалчлалын системүүд

Виртуалчлалын системүүдийн талаар хүн бүр сонссон байх: VMware, VirtualBox, Hyper-V, Qemu KVM гэх мэт. Тэд програмыг тусгаарлах, нөөцийн удирдлагыг хангадаг боловч сул талуудтай. Виртуалчлал хийхийн тулд танд гипервизор хэрэгтэй. Мөн гипервизор бол нөөцийн нэмэлт зардал юм. Виртуал машин нь ихэвчлэн бүхэл бүтэн асар том дүрс юм - үйлдлийн систем, Nginx, Apache, магадгүй MySQL агуулсан хүнд зураг. Зураг нь том бөгөөд виртуал машин ажиллахад тохиромжгүй. Үүний үр дүнд виртуал машинтай ажиллах нь удаан байдаг. Энэ асуудлыг шийдэхийн тулд цөмийн түвшинд виртуалчлалын системийг бий болгосон.

Цөмийн түвшний виртуалчлалын системүүд

Цөмийн түвшний виртуалчлалыг OpenVZ, Systemd-nspawn, LXC системүүд дэмждэг. Ийм виртуалчлалын тод жишээ бол LXC (Linux Containers) юм.

LXC нь Линукс үйлдлийн системийн олон тусгаарлагдсан тохиолдлуудыг нэг зангилаа дээр ажиллуулахад зориулагдсан үйлдлийн системийн түвшний виртуалчлалын систем юм. LXC нь виртуал машин ашигладаггүй боловч өөрийн процессын орон зай, сүлжээний стек бүхий виртуал орчинг бүрдүүлдэг.

Үндсэндээ LXC нь чингэлэг үүсгэдэг. Виртуал машин ба контейнер хоёрын ялгаа юу вэ?

Контейнер нь процессыг тусгаарлахад тохиромжгүй: эмзэг байдал нь цөмийн түвшний виртуалчлалын системд байдаг бөгөөд тэдгээр нь контейнерээс хост руу зугтах боломжийг олгодог. Тиймээс, хэрэв та ямар нэг зүйлийг тусгаарлах шаардлагатай бол виртуал машин ашиглах нь дээр.

Виртуалчлал ба контейнержуулалтын ялгааг диаграмаас харж болно.
Техник хангамжийн гипервизорууд, үйлдлийн систем дээрх гипервизорууд, контейнерууд байдаг.

Хэрэв та ямар нэг зүйлийг үнэхээр тусгаарлахыг хүсч байвал техник хангамжийн гипервизорууд гайхалтай. Учир нь санах ойн хуудас, процессорын түвшинд тусгаарлах боломжтой.

Програмын хувьд гипервизорууд байдаг бөгөөд контейнерууд байдаг бөгөөд бид тэдгээрийн талаар цааш ярих болно. Контейнержуулалтын системд гипервизор байдаггүй ч савыг үүсгэж, удирддаг Container Engine байдаг. Энэ зүйл нь илүү хөнгөн тул цөмтэй ажилладаг тул ачаалал багатай эсвэл огт байхгүй.

Цөмийн түвшинд контейнержуулахад юу ашигладаг вэ

Бусад процессуудаас тусгаарлагдсан контейнер үүсгэх боломжийг олгодог гол технологи нь Namespaces and Control Groups юм.

Нэрийн орон зай: PID, сүлжээ, холболт, хэрэглэгч. Илүү олон зүйл бий, гэхдээ ойлгоход хялбар болгох үүднээс бид эдгээрт анхаарлаа хандуулах болно.

PID Namespace нь процессуудыг хязгаарладаг. Жишээлбэл, бид PID Namespace үүсгээд тэнд процесс байрлуулах үед энэ нь PID 1-тэй болдог. Системд PID 1 нь ихэвчлэн systemd эсвэл init байдаг. Үүний дагуу бид процессыг шинэ нэрийн орон зайд байрлуулах үед энэ нь мөн PID 1 хүлээн авдаг.

Networking Namespace нь сүлжээг хязгаарлах/тусгаарлах, өөрийн интерфэйсүүдийг дотор нь байрлуулах боломжийг олгодог. Mount нь файлын системийн хязгаарлалт юм. Хэрэглэгч - хэрэглэгчдэд тавих хязгаарлалт.

Хяналтын бүлгүүд: Санах ой, CPU, IOPS, Сүлжээ - нийтдээ 12 орчим тохиргоо. Үгүй бол тэдгээрийг Cgroups ("C-groups") гэж нэрлэдэг.

Хяналтын бүлгүүд нь контейнерийн нөөцийг удирддаг. Хяналтын бүлгүүдээр дамжуулан бид сав нь тодорхой хэмжээний нөөцийг ашиглах ёсгүй гэж хэлж болно.

Контейнержуулалтыг бүрэн гүйцэд ажиллуулахын тулд нэмэлт технологи ашигладаг: Чадамж, Бичих дээр хуулбарлах болон бусад.

Чадавхи гэдэг нь үйл явцад юу хийж болох, юу хийж болохгүйг хэлэх явдал юм. Цөмийн түвшинд эдгээр нь зүгээр л олон параметр бүхий бит зураглал юм. Жишээлбэл, үндсэн хэрэглэгч бүрэн эрхтэй бөгөөд бүх зүйлийг хийх боломжтой. Цагийн сервер нь системийн цагийг өөрчлөх боломжтой: энэ нь Time Capsule дээр боломжтой, тэгээд л болоо. Эрхүүдийг ашигласнаар та процессуудын хязгаарлалтыг уян хатан тохируулж, улмаар өөрийгөө хамгаалах боломжтой.

Copy-on-write систем нь бидэнд Docker-ийн зургуудтай ажиллах, тэдгээрийг илүү үр дүнтэй ашиглах боломжийг олгодог.

Докер одоогоор Cgroups v2-тэй нийцтэй холбоотой асуудалтай байгаа тул энэ нийтлэл нь Cgroups v1 дээр онцгойлон анхаарч байна.

Гэхдээ түүх рүүгээ буцъя.

Виртуалчлалын системүүд цөмийн түвшинд гарч ирэхэд тэдгээрийг идэвхтэй ашиглаж эхэлсэн. Гипервизор дээрх ачаалал алга болсон боловч зарим асуудал хэвээр байна:

• том зургууд: тэдгээр нь үйлдлийн систем, номын сан, өөр өөр програм хангамжийг ижил OpenVZ руу түлхэж, эцэст нь зураг нь нэлээд том болж хувирдаг;
• Сав баглаа боодол, хүргэлтийн ердийн стандарт байдаггүй тул хараат байдлын асуудал хэвээр байна. Хоёр кодын нэг номын санг ашиглах тохиолдол байдаг, гэхдээ өөр хувилбартай. Тэдний хооронд зөрчилдөөн үүсч магадгүй юм.

Энэ бүх асуудлыг шийдэхийн тулд дараагийн эрин үе ирлээ.

Контейнерын эрин үе

Контейнерийн эрин үе ирэхэд тэдэнтэй ажиллах философи өөрчлөгдсөн.

• Нэг процесс - нэг сав.
• Бид процесст шаардлагатай бүх хамаарлыг контейнерт нь хүргэдэг. Энэ нь монолитуудыг бичил үйлчилгээ болгон хуваахыг шаарддаг.
• Зураг нь жижиг байх тусмаа сайн - боломжит эмзэг байдал бага, илүү хурдан эргэлддэг гэх мэт.
• Тохиолдлууд түр зуурын шинж чанартай болдог.

Гэрийн тэжээвэр амьтад болон үхрийн тухай миний хэлснийг санаж байна уу? Өмнө нь гэрийн тэжээвэр амьтад шиг байсан бол одоо үхэр шиг болжээ. Өмнө нь цул байсан - нэг програм. Одоо 100 микро үйлчилгээ, 100 контейнер байна. Зарим савнууд 2-3 хуулбартай байж болно. Бид сав бүрийг хянах нь чухал биш болж байна. Бидний хувьд хамгийн чухал зүйл бол үйлчилгээний хүртээмж юм: энэ багц савнууд юу хийдэг вэ. Энэ нь хяналтын арга барилыг өөрчилдөг.

2014-2015 онд Докер цэцэглэн хөгжсөн - одоо бидний ярих технологи.

Докер философи болон стандартчилсан хэрэглээний багцыг өөрчилсөн. Docker-ийг ашигласнаар бид програмыг багцалж, хадгалах газар руу илгээж, тэндээс татаж аваад байрлуулж болно.

Бид Docker контейнерт хэрэгтэй бүх зүйлээ хийдэг тул хараат байдлын асуудал шийдэгдсэн. Docker нь дахин үржих чадварыг баталгаажуулдаг. Олон хүмүүс давтагдах боломжгүй зүйлтэй тулгарсан гэж би бодож байна: бүх зүйл танд тохирсон, та үүнийг үйлдвэрлэлд түлхэж, тэнд ажиллахаа больсон. Docker-ийн тусламжтайгаар энэ асуудал арилдаг. Хэрэв таны Docker контейнер ажиллаж эхлэх бөгөөд хийх ёстой зүйлээ хийвэл өндөр магадлалтайгаар үйлдвэрлэлд орж, тэндээ ижил зүйлийг хийх болно.

Дээд талын зардлын талаархи ухралт

Нэмэлт зардлын талаар маргаан байнга гардаг. Зарим хүмүүс Docker нь Линукс цөм болон контейнержуулахад шаардлагатай бүх процессыг ашигладаг тул нэмэлт ачаалал өгдөггүй гэж үздэг. "Хэрэв та Docker-ийн ачаалал ихтэй гэж хэлбэл, Линукс цөм нь ачаалалтай байна" гэх мэт.

Нөгөөтэйгүүр, хэрэв та илүү гүнзгийрвэл, Докерт хэд хэдэн зүйл байдаг бөгөөд үүнийг хэт их ачаалалтай гэж хэлж болно.

Эхнийх нь PID нэрийн орон зай юм. Процессыг нэрийн талбарт байрлуулахад түүнд PID 1 оноогддог. Үүний зэрэгцээ энэ процесс нь контейнерийн гадна байрлах хостын нэрийн талбарт байрлах өөр PID-тэй байна. Жишээлбэл, бид Nginx-ийг саванд эхлүүлсэн бөгөөд энэ нь PID 1 (мастер процесс) болсон. Мөн хост дээр PID 12623 байна. Энэ нь хэр их ачаалалтай болохыг хэлэхэд хэцүү.

Хоёрдахь зүйл бол Cgroups. Cgroups-ийг санах ойгоор нь авч үзье, өөрөөр хэлбэл, савны санах ойг хязгаарлах чадвар. Үүнийг идэвхжүүлсэн үед тоолуур болон санах ойн бүртгэл идэвхждэг: цөм нь хэдэн хуудас хуваарилагдсан, хэд нь энэ саванд үнэгүй хэвээр байгааг ойлгох шаардлагатай. Энэ нь нэмэлт зардал байж магадгүй, гэхдээ энэ нь гүйцэтгэлд хэрхэн нөлөөлдөг талаар нарийн судалгаа хараагүй байна. Docker дээр ажиллаж байгаа програм гэнэт гүйцэтгэлийн огцом алдагдалд орсныг би өөрөө анзаарсангүй.

Гүйцэтгэлийн талаар бас нэг тэмдэглэл. Зарим цөмийн параметрүүдийг хостоос контейнер руу дамжуулдаг. Ялангуяа сүлжээний зарим параметрүүд. Тиймээс, хэрэв та Docker дээр өндөр гүйцэтгэлтэй, жишээлбэл сүлжээг идэвхтэй ашиглах ямар нэг зүйлийг ажиллуулахыг хүсч байвал ядаж эдгээр параметрүүдийг тохируулах хэрэгтэй. Жишээ нь зарим nf_conntrack.

Докерын үзэл баримтлалын тухай

Docker нь хэд хэдэн бүрэлдэхүүн хэсгээс бүрдэнэ.

1. Docker Daemon нь ижил контейнер хөдөлгүүр юм; чингэлэгүүдийг хөөргөдөг.
2. Docker CII нь Docker удирдлагын хэрэгсэл юм.
3. Dockerfile - зураг хэрхэн бүтээх заавар.
4. Зураг — савыг өнхрүүлсэн зураг.
5. Сав.
6. Докерын бүртгэл нь зургийн агуулах юм.

Схемийн хувьд энэ нь иймэрхүү харагдаж байна:

Docker дэмон нь Docker_host дээр ажиллаж, контейнеруудыг ажиллуулдаг. Зургийг бүтээх, зургийг татаж авах, савыг эхлүүлэх командуудыг илгээдэг Client байдаг. Докер демон нь бүртгэлд очиж тэдгээрийг гүйцэтгэдэг. Docker клиент нь локал (Unix залгуур руу) болон алсын хостоос TCP-ээр дамжуулан хандах боломжтой.

Бүрэлдэхүүн хэсэг бүрийг авч үзье.

Докер демон - энэ бол серверийн хэсэг бөгөөд энэ нь хост машин дээр ажилладаг: зураг татаж аваад тэдгээрээс контейнер ажиллуулж, контейнер хооронд сүлжээ үүсгэж, бүртгэл цуглуулдаг. Биднийг "дүрсийг бүтээх" гэж хэлэхэд чөтгөр бас үүнийг хийдэг.

Docker CLI — Докер клиентийн хэсэг, демонтой ажиллах консолын хэрэгсэл. Би давтан хэлье, энэ нь зөвхөн дотоодод төдийгүй сүлжээгээр ажиллах боломжтой.

Үндсэн тушаалууд:

docker ps - одоогоор Docker хост дээр ажиллаж байгаа контейнеруудыг харуулах.
docker images - орон нутгийн татаж авсан зургуудыг харуул.
docker search <> - бүртгэлээс зураг хайх.
docker pull <> - бүртгэлээс машин руу зураг татаж авах.
докер бүтээх < > - зургийг цуглуул.
docker run <> - савыг ажиллуулна.
docker rm <> - савыг зайлуул.
docker logs <> - контейнерийн бүртгэл
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-ийн заавар бүр шинэ давхарга үүсгэдэг. Давхаргыг дахин ашиглах боломжтой.

Докерын бүртгэл нь Docker зургийн агуулах юм. Үйлдлийн системтэй адил Docker нь нийтийн стандарт бүртгэлтэй - dockerhub. Гэхдээ та өөрийн хадгалах газар, өөрийн Docker бүртгэлийг үүсгэж болно.

чингэлэг - зурагнаас юу эхлүүлсэн. Бид Dockerfile-ийн зааврын дагуу зураг бүтээж, дараа нь энэ зургаас эхлүүлэв. Энэ сав нь бусад савнаас тусгаарлагдсан бөгөөд програмыг ажиллуулахад шаардлагатай бүх зүйлийг агуулсан байх ёстой. Энэ тохиолдолд нэг сав - нэг процесс. Та хоёр процессыг хийх хэрэгтэй болдог, гэхдээ энэ нь Докерын үзэл суртлын эсрэг зарим талаараа юм.

"Нэг контейнер, нэг процесс" шаардлага нь PID Нэрийн орон зайтай холбоотой. PID 1-тэй процесс Namespace-д эхлэхэд гэнэт үхвэл сав бүхэлдээ үхнэ. Хэрэв тэнд хоёр процесс явагдаж байгаа бол: нэг нь амьд, нөгөө нь үхсэн бол сав нь үргэлжлүүлэн амьдрах болно. Гэхдээ энэ бол шилдэг туршлагын тухай асуудал бөгөөд бид бусад материалд тэдгээрийн талаар ярих болно.

Хичээлийн онцлог, бүрэн хөтөлбөрийг илүү нарийвчлан судлахын тулд холбоосыг дагана уу: "Докерын видео курс".

Зохиогч: Марсель Ибраев, Kubernetes-ийн итгэмжлэгдсэн администратор, Southbridge-ийн дадлагажигч инженер, Slurm курсуудын илтгэгч, хөгжүүлэгч.

Эх сурвалж: www.habr.com