Docker Swarm, Kubernetes, Mesos зэрэг нь контейнер зохион байгуулах хамгийн алдартай хүрээ юм. Арун Гупта илтгэлдээ Докер, Сварм, Кубернетес нарын дараах талуудыг харьцуулав.
- Орон нутгийн хөгжил.
- Байршуулах функцууд.
- Олон контейнерийн програмууд.
- Үйлчилгээний нээлт.
- Үйлчилгээг өргөжүүлэх.
- Нэг удаа гүйцэтгэх даалгавар.
- Maven-тай нэгтгэх.
- "Өнхрөх" шинэчлэл.
- Couchbase мэдээллийн сангийн кластер үүсгэх.
Үүний үр дүнд та зохион байгуулалтын хэрэгсэл бүр юу санал болгодог талаар тодорхой ойлголттой болж, эдгээр платформыг хэрхэн үр дүнтэй ашиглах талаар сурах болно.
Арун Гупта бол 10 гаруй жилийн турш Sun, Oracle, Red Hat, Couchbase хөгжүүлэгчдийн нийгэмлэгүүдийг хөгжүүлж буй Amazon Web Services-ийн нээлттэй эхийн бүтээгдэхүүний ахлах технологич юм. Маркетингийн кампанит ажил, хөтөлбөрүүдийн стратеги боловсруулж хэрэгжүүлдэг олон талт багуудад ажиллаж байсан арвин туршлагатай. Тэрээр Нарны инженерүүдийн багийг удирдаж, Java EE багийг үүсгэн байгуулагчдын нэг бөгөөд Devoxx4Kids-ийн АНУ дахь салбарыг бүтээгч юм. Арун Гупта бол мэдээллийн технологийн блогт 2 мянга гаруй нийтлэл бичсэн бөгөөд дэлхийн 40 гаруй оронд илтгэл тавьсан.
55-р мөрөнд Kubernetes тохиргооны файлыг ашиглан үүсгэсэн энэхүү мэдээллийн сангийн үйлчилгээ рүү чиглэсэн COUCHBASE_URI-г агуулна. Хэрэв та 2-р мөрийг харвал төрөл зүйлийг харж болно: Үйлчилгээ бол миний үүсгэж байгаа үйлчилгээ бөгөөд couchbase-service гэж нэрлэгддэг бөгөөд ижил нэр нь 4-р мөрөнд бичигдсэн байдаг. Доор зарим портууд байна.
Гол мөрүүд нь 6 ба 7. Үйлчилгээнд би "Хөөе, энэ бол миний хайж буй шошго!" гэж хэлэх ба эдгээр шошго нь хувьсагчийн хосын нэрсээс өөр зүйл биш бөгөөд миний couchbase-rs-pod руу 7-р мөрийг зааж байна. програм. Дараах нь эдгээр ижил шошго руу нэвтрэх боломжийг олгодог портууд юм.
19-р мөрөнд би шинэ төрлийн ReplicaSet үүсгэж, 31-р мөрөнд зургийн нэр, 24-27-р мөрөнд миний подтой холбоотой мета өгөгдлийг зааж байна. Энэ нь үйлчилгээ хайж байгаа зүйл бөгөөд холболтыг юу хийх ёстой вэ. Файлын төгсгөлд 55-56 ба 4-р мөрүүдийн хооронд "энэ үйлчилгээг ашиглаарай!"
Тиймээс, хуулбарын багц байгаа үед би үйлчилгээгээ эхлүүлдэг бөгөөд хуулбар бүр нь харгалзах шошготой өөрийн порттой байдаг тул энэ үйлчилгээнд багтдаг. Хөгжүүлэгчийн үүднээс та зүгээр л үйлчилгээг дуудаж, дараа нь танд хэрэгтэй хуулбаруудын багцыг ашигладаг.
Үүний үр дүнд би Couchbase үйлчилгээгээр дамжуулан мэдээллийн баазтай холбогддог WildFly podтой болсон. Би урд талын хэсгийг хэд хэдэн WildFly pods-тэй ашиглаж болох бөгөөд энэ нь couchbase үйлчилгээгээр дамжуулан couchbase backend-тэй холбогддог.
Дараа нь бид кластерын гадна байрлах үйлчилгээ нь IP хаягаараа дамжуулан кластер дотор байрлах, дотоод IP хаягтай элементүүдтэй хэрхэн холбогддогийг авч үзэх болно.
Тэгэхээр, харьяалалгүй чингэлэг бол гайхалтай, гэхдээ төлөвтэй контейнер ашиглах нь хэр сайн бэ? Төлөв буюу байнгын контейнеруудын системийн тохиргоог харцгаая. Docker-д өгөгдөл хадгалах зохион байгуулалтын 4 өөр арга байдаг бөгөөд үүнд анхаарлаа хандуулах хэрэгтэй. Эхнийх нь Implicit Per-Container бөгөөд энэ нь couchbase, MySQL эсвэл MyDB ханасан контейнер ашиглах үед бүгд анхдагч Sandbox-оос эхэлдэг гэсэн үг юм. Өөрөөр хэлбэл, мэдээллийн санд хадгалагдсан бүх зүйл нь саванд хадгалагддаг. Хэрэв сав алга болбол өгөгдөл нь түүнтэй хамт алга болно.
Хоёр дахь нь Explicit Per-Container бөгөөд та docker-ийн эзэлхүүнийг ашиглан тодорхой хадгалах санг үүсгэж, түүнд өгөгдөл хадгалдаг. Гурав дахь "Per-Host" арга нь саванд хадгалагдсан бүх зүйл хост дээр нэгэн зэрэг хуулбарлагдах үед хадгалах газрын зураглалтай холбоотой юм. Хэрэв контейнер бүтэлгүйтвэл өгөгдөл хост дээр үлдэх болно. Сүүлийнх нь хэд хэдэн Multi-Host хостуудыг ашиглах явдал бөгөөд энэ нь янз бүрийн шийдлүүдийг үйлдвэрлэх үе шатанд зөвлөж байна. Таны програмууд бүхий контейнерууд хост дээр ажиллаж байна гэж бодъё, гэхдээ та интернетийн хаа нэгтээ мэдээллээ хадгалахыг хүсч байгаа бөгөөд үүний тулд та тархсан системд автомат зураглалыг ашигладаг.
Эдгээр аргууд тус бүр нь тодорхой хадгалах газрыг ашигладаг. Далд ба илэрхий Контейнер нь /var/lib/docker/volumes дээр хост дээрх өгөгдлийг хадгалдаг. Per-Host аргыг ашиглах үед агуулахыг чингэлэг дотор суулгаж, контейнер өөрөө хост дээр суурилагдсан байдаг. Олон хостуудын хувьд Ceph, ClusterFS, NFS гэх мэт шийдлүүдийг ашиглаж болно.
Хэрэв байнгын контейнер бүтэлгүйтвэл эхний хоёр тохиолдолд хадгалах санд хандах боломжгүй болох боловч сүүлийн хоёр тохиолдолд хандалт хадгалагдана. Гэхдээ эхний тохиолдолд та виртуал машин дээр ажилладаг Docker хостоор дамжуулан репозитор руу нэвтрэх боломжтой. Хоёр дахь тохиолдолд, та тодорхой хадгалах сан үүсгэсэн тул өгөгдөл устахгүй.
Хэрэв хост бүтэлгүйтсэн бол эхний гурван тохиолдолд санах ойн лавлах боломжгүй, сүүлийн тохиолдолд хадгалах сантай холболт тасрахгүй. Эцэст нь, хуваалцсан функцийг эхний тохиолдолд хадгалахад бүрэн хассан бөгөөд бусад тохиолдолд боломжтой. Хоёрдахь тохиолдолд, таны мэдээллийн сан түгээх санах ойг дэмждэг эсэхээс хамаарч хадгалах санг хуваалцаж болно. Per-Host-ийн хувьд өгөгдөл түгээх нь зөвхөн тухайн хост дээр боломжтой бөгөөд олон хостын хувьд үүнийг кластер өргөтгөлөөр хангадаг.
Үүнийг төлөвтэй контейнер үүсгэх үед анхаарч үзэх хэрэгтэй. Өөр нэг хэрэгтэй Docker хэрэгсэл бол "батерей байгаа, гэхдээ солих шаардлагатай" гэсэн зарчмаар ажилладаг Volume залгаас юм. Таныг Docker контейнер ажиллуулахад "Хөөе, та өгөгдлийн сантай контейнер ажиллуулсны дараа та энэ саванд мэдээллээ хадгалах боломжтой!" Энэ бол анхдагч функц боловч та үүнийг өөрчилж болно. Энэхүү залгаас нь контейнер мэдээллийн сангийн оронд сүлжээний хөтөч эсвэл үүнтэй төстэй зүйлийг ашиглах боломжийг олгодог. Энэ нь хост дээр суурилсан санах ойд зориулсан анхдагч драйверийг агуулсан бөгөөд Amazon EBS, Azure Storage болон GCE Persistent диск зэрэг гадаад санах ойн системтэй контейнер нэгтгэх боломжийг олгодог.
Дараагийн слайд нь Docker Volume залгаасын архитектурыг харуулж байна.
Цэнхэр өнгө нь цэнхэр Docker хосттой холбоотой Docker клиентийг илэрхийлдэг бөгөөд энэ нь танд өгөгдөл хадгалах саваар хангадаг Локал хадгалах системтэй. Ногоон өнгө нь хосттой холбогдсон Plugin Client болон Plugin Daemon-ийг заана. Эдгээр нь танд хэрэгтэй Storage Backend төрлийн сүлжээний санд өгөгдлийг хадгалах боломжийг олгодог.
Docker Volume залгаасыг Portworx санах ойд ашиглах боломжтой. PX-Dev модуль нь үнэндээ таны ажиллуулдаг контейнер бөгөөд таны Docker хосттой холбогдож, Amazon EBS дээр өгөгдлийг хялбархан хадгалах боломжийг олгодог.
Portworx клиент нь таны хосттой холбогдсон төрөл бүрийн хадгалах савны төлөвийг хянах боломжийг танд олгоно. Хэрэв та миний блогт зочилвол Docker-ийн тусламжтай Portworx-ийг хэрхэн ашиглах талаар уншиж болно.
Kubernetes дахь хадгалах тухай ойлголт нь Docker-тэй төстэй бөгөөд таны контейнерт хандах боломжтой сангуудаар илэрхийлэгддэг. Эдгээр нь ямар ч савны ашиглалтын хугацаанаас хамаардаггүй. Хамгийн түгээмэл хадгалалтын төрлүүд нь hostPath, nfs, awsElasticBlockStore, gsePersistentDisk юм. Эдгээр дэлгүүрүүд Kubernetes-д хэрхэн ажилладагийг харцгаая. Ихэвчлэн тэдгээрийг холбох үйл явц нь 3 үе шатаас бүрдэнэ.
Эхнийх нь сүлжээний талд байгаа хэн нэгэн, ихэвчлэн администратор нь танд байнгын хадгалалтаар хангадаг. Үүнд тохирох PersistentVolume тохиргооны файл байна. Дараа нь програм хөгжүүлэгч PersistentVolumeClaim нэртэй тохиргооны файл буюу PVC хадгалах хүсэлтийг бичдэг бөгөөд үүнд: "Надад 50 ГБ түгээсэн санах ой байгаа боловч бусад хүмүүс ч мөн түүний багтаамжийг ашиглахын тулд би энэ PVC файлыг одоогоор хэлж байна. Зөвхөн 10 ГБ хэрэгтэй. Эцэст нь, гурав дахь алхам бол таны хүсэлтийг хадгалах сан болгон суулгаж, под, хуулбар эсвэл үүнтэй төстэй зүйл бүхий программыг ашиглаж эхлэх явдал юм. Энэ үйл явц нь дурдсан 3 алхмаас бүрдэх бөгөөд өргөтгөх боломжтой гэдгийг санах нь чухал.
Дараагийн слайд нь AWS архитектурын Kubernetes Persistence Container-ийг харуулж байна.
Кубернетес кластерийг төлөөлсөн хүрэн тэгш өнцөгт дотор шараар тэмдэглэсэн нэг мастер зангилаа, хоёр ажилчны зангилаа байна. Ажилчны зангилааны нэг нь улбар шар өнгийн хонхорцог, хадгалах сан, хуулбар хянагч, ногоон Docker Couchbase контейнер агуулдаг. Кластер дотор, зангилааны дээгүүр, ягаан өнгийн тэгш өнцөгт нь гаднаас хандах боломжтой Үйлчилгээг заана. Энэ архитектурыг төхөөрөмж дээр өгөгдөл хадгалахад ашиглахыг зөвлөж байна. Шаардлагатай бол би дараагийн слайдад үзүүлсэн шиг кластераас гадуур EBS-д өөрийн өгөгдлийг хадгалах боломжтой. Энэ нь масштабыг нэмэгдүүлэх ердийн загвар боловч үүнийг ашиглахдаа анхаарах ёстой санхүүгийн тал байдаг - сүлжээний хаа нэгтээ өгөгдөл хадгалах нь хостоос илүү үнэтэй байж болно. Савлах шийдлүүдийг сонгохдоо энэ нь чухал аргументуудын нэг юм.
Docker-ийн нэгэн адил та Portworx-тэй байнгын Kubernetes контейнер ашиглаж болно.
Үүнийг одоогийн Kubernetes 1.6-ийн нэр томъёонд "StatefulSet" гэж нэрлэдэг бөгөөд энэ нь Pod-ийг зогсоох, Graceful Shutdown хийх үйл явдлуудыг боловсруулдаг Stateful програмуудтай ажиллах арга юм. Манай тохиолдолд ийм програмууд нь мэдээллийн сан юм. Миний блогоос та Portworx ашиглан Kubernetes дээр StatefulSet хэрхэн үүсгэх талаар уншиж болно.
Хөгжлийн талын талаар ярилцъя. Миний хэлсэнчлэн Docker нь CE ба EE гэсэн 2 хувилбартай бөгөөд эхний тохиолдолд бид EE-ийн сар бүр шинэчлэгдсэн хувилбараас ялгаатай нь 3 сар тутамд нэг удаа шинэчлэгддэг Community Edition-ийн тогтвортой хувилбарын тухай ярьж байна. Та Mac, Linux эсвэл Windows-д зориулсан Docker-г татаж авах боломжтой. Суулгасны дараа Docker автоматаар шинэчлэгдэх бөгөөд үүнийг эхлүүлэхэд маш хялбар болно.
Kubernetes-ийн хувьд би Minikube хувилбарыг илүүд үздэг - энэ нь нэг зангилаа дээр кластер үүсгэх замаар платформыг эхлүүлэх сайн арга юм. Хэд хэдэн зангилааны кластер үүсгэхийн тулд хувилбаруудын сонголт илүү өргөн байдаг: эдгээр нь kops, kube-aws (CoreOS+AWS), kube-up (хуучирсан) юм. Хэрэв та AWS-д суурилсан Kubernetes-ийг ашиглахыг хүсч байгаа бол долоо хоног бүрийн баасан гаригт онлайнаар хуралдаж, AWS Kubernetes-тэй ажиллах талаар олон сонирхолтой материалыг нийтэлдэг AWS SIG-д нэгдэхийг зөвлөж байна.
Эдгээр платформ дээр Rolling Update хэрхэн хийгддэгийг харцгаая. Хэрэв хэд хэдэн зангилааны кластер байгаа бол энэ нь зургийн тодорхой хувилбарыг ашигладаг, жишээлбэл, WildFly:1. Дамжуулж буй шинэчлэл гэдэг нь зургийн хувилбарыг зангилаа бүр дээр дараалан шинэ хувилбараар солино гэсэн үг юм.
Үүнийг хийхийн тулд би WildFly:2 зургийн шинэ хувилбар болон update-параллелизм 2-ын шинэ хувилбарыг зааж өгсөн docker service update (үйлчилгээний нэр) командыг ашигладаг. 2 гэсэн тоо нь систем 2 програмын зургийг шинэчилнэ гэсэн үг юм. Үүний зэрэгцээ, дараа нь 10 секундын шинэчлэлтийн саатал 10 секунд, дараа нь дараагийн 2 зураг 2 цэг дээр шинэчлэгдэнэ гэх мэт. Энэхүү энгийн гулсмал шинэчлэлтийн механизмыг Docker-ийн нэг хэсэг болгон танд санал болгож байна.
Kubernetes-д гулсмал шинэчлэлт иймэрхүү ажилладаг. Хуулбарлах хянагч rc нь ижил хувилбарын хуулбаруудын багцыг үүсгэдэг бөгөөд энэ webapp-rc дахь под бүр нь etcd дотор байрлах шошготой байдаг. Надад pod хэрэгтэй үед би заасан шошгыг ашиглан pod-ийг өгдөг etcd репозитор руу хандахын тулд Програмын үйлчилгээг ашигладаг.
Энэ тохиолдолд бид WildFly хувилбар 3 програмыг ажиллуулж байгаа Replication controller-д 1 подтой байна. Цаана нь шинэчлэх үед төгсгөлд нь ижил нэр, индекстэй өөр хуулбар хянагч үүсгэгддэг - - xxxxx, энд x нь санамсаргүй тоо, мөн ижил шошготой. Одоо Програмын үйлчилгээ нь шинэ Replication хянагч дахь програмын хуучин хувилбартай гурван pod, шинэ хувилбартай гурван podтой болсон. Үүний дараа хуучин подкуудыг устгаж, шинэ pods бүхий хуулбарлах хянагчийг нэрлэж, ашиглалтад оруулна.
Хяналт шалгалт руугаа явцгаая. Docker нь олон суурилуулсан хяналтын командуудтай. Жишээлбэл, docker container stats командын мөрийн интерфейс нь процессорын ашиглалт, дискний ашиглалт, сүлжээний ачаалал зэрэг контейнеруудын төлөв байдлын талаарх мэдээллийг секунд тутамд харуулах боломжийг олгодог. Docker Remote API хэрэгсэл нь үйлчлүүлэгч сервертэй хэрхэн харилцаж байгаа талаарх мэдээллийг өгдөг. Энэ нь энгийн командуудыг ашигладаг боловч Docker REST API дээр суурилдаг. Энэ тохиолдолд REST, Flash, Remote гэсэн үгс нь ижил утгатай. Та хосттой харилцах үед энэ нь REST API юм. Docker Remote API нь контейнер ажиллуулах талаар илүү их мэдээлэл авах боломжийг танд олгоно. Миний блог энэ мониторингийг Windows Server-тэй ашиглах талаар дэлгэрэнгүй тайлбарласан.
Олон хост кластер ажиллуулж байх үед докер системийн үйл явдлыг хянах нь тодорхой хост дээрх хостын эвдрэл, контейнерийн эвдрэл, масштабын үйлчилгээ гэх мэт мэдээллийг авах боломжтой болгодог. Docker 1.20-аас эхлэн энэ нь одоо байгаа програмуудад төгсгөлийн цэгүүдийг суулгадаг Prometheus-ийг агуулдаг. Энэ нь танд HTTP-ээр дамжуулан хэмжигдэхүүнийг хүлээн авч, хяналтын самбар дээр харуулах боломжийг олгоно.
Хяналтын өөр нэг онцлог нь cAdvisor (container advisor гэсэн үгийн товчлол) юм. Энэ нь ажиллаж байгаа контейнеруудаас нөөцийн ашиглалт, гүйцэтгэлийн өгөгдөлд дүн шинжилгээ хийж, хангадаг бөгөөд Prometheus хэмжигдэхүүнийг хайрцагнаас нь гаргаж өгдөг. Энэ хэрэгслийн онцлог нь зөвхөн сүүлийн 60 секундын мэдээллийг өгдөг. Тиймээс та энэ мэдээллийг цуглуулж, мэдээллийн санд оруулах чадвартай байх ёстой бөгөөд ингэснээр урт хугацааны үйл явцыг хянах боломжтой болно. Үүнийг мөн Графана эсвэл Кибана ашиглан хяналтын самбарын хэмжигдэхүүнийг графикаар харуулахад ашиглаж болно. Миний блогт cAdvisor ашиглан Кибана хяналтын самбарыг ашиглан савыг хэрхэн хянах талаар дэлгэрэнгүй тайлбарласан байгаа.
Дараагийн слайд нь Prometheus-ийн эцсийн цэгийн гаралт ямар харагдахыг болон харуулах боломжтой хэмжүүрүүдийг харуулав.
Зүүн доод талд та HTTP хүсэлт, хариулт гэх мэт хэмжигдэхүүнүүдийг харна, баруун талд нь тэдгээрийн график дэлгэц байна.
Kubernetes нь суурилуулсан хяналтын хэрэгслийг агуулдаг. Энэ слайд нь нэг мастер, гурван ажилчны зангилаа агуулсан ердийн кластерийг харуулж байна.
Ажлын зангилаа бүр автоматаар эхлүүлсэн cAdvisor-г агуулдаг. Нэмж дурдахад Kubernetes 1.0.6 ба түүнээс дээш хувилбартай нийцтэй гүйцэтгэлийн хяналт, хэмжүүр цуглуулах систем Heapster байдаг. Heapster нь зөвхөн ажлын ачаалал, сав, савны гүйцэтгэлийн хэмжигдэхүүнийг цуглуулахаас гадна бүхэл бүтэн кластераас үүсгэсэн үйл явдал болон бусад дохиог цуглуулах боломжийг олгодог. Өгөгдөл цуглуулахын тулд энэ нь pod's Kubelet-тэй ярьж, InfluxDB мэдээллийн санд мэдээллийг автоматаар хадгалж, Grafana хяналтын самбарт хэмжигдэхүүн болгон гаргадаг. Гэсэн хэдий ч, хэрэв та miniKube-г ашиглаж байгаа бол энэ функц нь анхдагчаар байхгүй тул танд хяналт тавих нэмэлт програмуудыг ашиглах шаардлагатай болно гэдгийг санаарай. Тэгэхээр энэ бүхэн нь та контейнеруудыг хаана ажиллуулж, ямар хяналтын хэрэгслийг анхдагчаар ашиглаж болох, аль нь тусдаа нэмэлт болгон суулгах шаардлагатай байгаагаас хамаарна.
Дараагийн слайд нь миний контейнеруудын ажиллаж байгаа байдлыг харуулсан Графана хяналтын самбаруудыг харуулж байна. Энд маш олон сонирхолтой мэдээлэл байна. Мэдээжийн хэрэг, SysDig, DataDog, NewRelic гэх мэт арилжааны Docker болон Kubernetes процессын хяналтын олон хэрэгслүүд байдаг. Тэдгээрийн зарим нь 30 жилийн үнэгүй туршилтын хугацаатай тул та өөрт тохирохыг нь хайж олох боломжтой. Би хувьдаа Kubernetes-тэй сайн нийцдэг SysDig болон NewRelic-ийг ашиглахыг илүүд үздэг. Docker болон Kubernetes платформд адилхан сайн нэгдсэн хэрэгслүүд байдаг.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com