Docker Swarm, Kubernetes жана Mesos - эң популярдуу контейнердик оркестрдик алкактар. Өз сөзүндө Арун Гупта Докер, Сварм жана Кубернетестин төмөнкү аспектилерин салыштырат:
- Жергиликтүү өнүгүү.
- Жайгаштыруу функциялары.
- Көп контейнердик колдонмолор.
- Кызматтын ачылышы.
- Кызматты масштабдоо.
- Бир жолу аткарылуучу тапшырмалар.
- Maven менен интеграция.
- "Rolling" жаңыртуу.
- Couchbase маалымат базасы кластерин түзүү.
Натыйжада, сиз ар бир оркестрдин куралы эмне сунуш кыларын так түшүнүп, бул платформаларды кантип натыйжалуу колдонууну үйрөнөсүз.
Арун Гупта 10 жылдан ашык убакыттан бери Sun, Oracle, Red Hat жана Couchbase иштеп чыгуучу коомдоштуктарын иштеп чыккан Amazon Web Services компаниясынын ачык булактуу өнүмдөр боюнча башкы технологу. Маркетинг кампаниялары жана программалары үчүн стратегияны иштеп чыгуу жана ишке ашыруу боюнча алдыңкы кайчылаш-функционалдык командаларда иштөө боюнча чоң тажрыйбасы бар. Ал Sun инженерлеринин командаларын жетектеген, Java EE командасынын негиздөөчүлөрүнүн бири жана Devoxx4Kidsтин АКШ филиалынын жаратуучусу. Арун Гупта IT-блогдордогу 2 миңден ашык посттордун автору жана 40тан ашык өлкөдө баяндамаларды жасаган.
55-сапта бул маалымат базасы кызматын көрсөткөн COUCHBASE_URI камтылган, ал дагы Kubernetes конфигурация файлы аркылуу түзүлгөн. Эгер сиз 2-сапты карасаңыз, түрүн көрө аласыз: Кызмат - бул мен түзүп жаткан кызмат - couchbase-service деп аталат жана ошол эле ат 4-сапта көрсөтүлгөн. Төмөндө кээ бир порттор бар.
Негизги саптар 6 жана 7. Кызматта мен айтам: “Эй, бул мен издеп жаткан энбелгилер!”, жана бул энбелгилер өзгөрүлмө түгөйлөрдүн аталыштарынан башка эч нерсе эмес, жана 7-сап менин couchbase-rs-pod үчүн чекиттер. колдонмо. Төмөндө ушул эле энбелгилерге кирүү мүмкүнчүлүгүн камсыз кылган порттор бар.
19-сапта мен ReplicaSet жаңы түрүн түзөм, 31-сапта сүрөттүн аталышы камтылган жана 24-27-саптар менин подъем менен байланышкан метаберилиштерди көрсөтүп турат. Кызмат дал ушул нерсени издеп жатат жана эмнеге байланыш түзүлүшү керек. Файлдын аягында 55-56 жана 4-саптардын ортосунда кандайдыр бир байланыш бар: "бул кызматты колдонуңуз!"
Ошентип, мен реплика топтому болгондо кызматымды баштайм жана ар бир реплика топтомунун тиешелүү энбелгиси бар өзүнүн порту болгондуктан, ал кызматка кирет. Иштеп чыгуучунун көз карашы боюнча, сиз жөн гана кызматка чаласыз, ал андан кийин сизге керектүү репликалардын топтомун колдонот.
Жыйынтыгында, менде Couchbase кызматы аркылуу маалымат базасы менен байланышуучу WildFly подъезди бар. Мен фронтонду бир нече WildFly поддондору менен колдоно алам, алар да couchbase кызматы аркылуу couchbase бэкэнди менен байланышат.
Кийинчерээк кластердин сыртында жайгашкан кызмат өзүнүн IP дареги аркылуу кластердин ичинде жайгашкан жана ички IP дареги бар элементтер менен кантип байланышарын карап чыгабыз.
Демек, жарандыгы жок контейнерлер абдан жакшы, бирок мамлекеттик контейнерлерди колдонуу канчалык жакшы? Келгиле, абалды көрсөткөн же туруктуу контейнерлер үчүн системанын жөндөөлөрүн карап көрөлү. Докерде, сиз көңүл бурушуңуз керек болгон маалыматтарды сактоонун 4 башка ыкмасы бар. Биринчиси - Implicit Per-Container, бул couchbase, MySQL же MyDB каныккан контейнерлерди колдонууда алардын бардыгы демейки Sandbox менен башталат дегенди билдирет. Башкача айтканда, базада сакталган нерселердин баары контейнердин өзүндө сакталат. Контейнер жок болуп кетсе, аны менен кошо маалыматтар да жок болот.
Экинчиси - ачык-айкын Контейнер, сиз докер көлөмү менен белгилүү бир сактагычты түзүп, команданы түзүп, андагы маалыматтарды сактаңыз. Үчүнчү Per-Host ыкмасы контейнерде сакталган нерселердин баары бир эле учурда хостто кайталанганда, сактоо картасы менен байланышкан. Контейнер иштебей калса, маалыматтар хостто кала берет. Акыркысы ар кандай чечимдерди өндүрүү стадиясында сунушталган бир нече Multi-Host хостторун колдонуу. Колдонмолоруңуз менен контейнерлериңиз хостто иштеп жатат дейли, бирок сиз өзүңүздүн маалыматтарыңызды Интернеттин бир жеринде сактагыңыз келет жана бул үчүн бөлүштүрүлгөн системалар үчүн автоматтык картаны колдоносуз.
Бул ыкмалардын ар бири белгилүү бир сактоо ордун колдонот. Ачык жана ачык Контейнер /var/lib/docker/volumes дарегинде хостто маалыматтарды сактайт. Per-Host ыкмасын колдонууда сактагыч контейнердин ичине орнотулат, ал эми контейнер өзү хостко орнотулат. Көп хосттор үчүн Ceph, ClusterFS, NFS ж.б. сыяктуу чечимдерди колдонсо болот.
Туруктуу контейнер иштебей калса, сактоо каталогу биринчи эки учурда жеткиликсиз болуп калат, бирок акыркы эки учурда жеткиликтүүлүк сакталат. Бирок, биринчи учурда, сиз виртуалдык машинада иштеген Docker хосту аркылуу репозиторийге кире аласыз. Экинчи учурда, маалыматтар да жоголбойт, анткени сиз ачык сактагычты түздүңүз.
Хост иштебей калса, сактоо каталогу алгачкы үч учурда жеткиликсиз, акыркы учурда сактоо менен байланыш үзүлбөйт. Акыр-аягы, жалпы функция биринчи учурда сактоо үчүн толугу менен алынып салынат жана калган учурда мүмкүн. Экинчи учурда, маалымат базаңыз бөлүштүрүлгөн сактагычты колдойбу же жокпу, жараша сактагычты бөлүшө аласыз. Per-Host болгон учурда, маалыматтарды бөлүштүрүү берилген хостто гана мүмкүн, ал эми мультихост үчүн ал кластерди кеңейтүү аркылуу камсыз кылынат.
Бул штаттык контейнерлерди түзүүдө эске алынышы керек. Дагы бир пайдалуу Docker куралы - бул "батареялар бар, бирок алмаштырылышы керек" принциби боюнча иштеген Көлөм плагини. Docker контейнерин ишке киргизгениңизде, ал мындай дейт: "Эй, маалымат базасы бар контейнерди баштагандан кийин, маалыматыңызды ушул контейнерде сактай аласыз!" Бул демейки өзгөчөлүк, бирок сиз аны өзгөртө аласыз. Бул плагин контейнер базасынын ордуна тармактык дискти же ушуга окшош нерсени колдонууга мүмкүндүк берет. Ал хостко негизделген сактоо үчүн демейки драйверди камтыйт жана Amazon EBS, Azure Storage жана GCE Persistent дисктери сыяктуу тышкы сактагыч системалары менен контейнерди интеграциялоого мүмкүндүк берет.
Кийинки слайд Docker Volume плагининин архитектурасын көрсөтөт.
Көк түс сизге маалыматтарды сактоо үчүн контейнерлер менен камсыз кылган Local сактагыч кыймылдаткычы бар көк 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 контейнерин көрсөтөт.
Кубернетес кластерин чагылдырган күрөң тик бурчтуктун ичинде сары менен көрсөтүлгөн бир башкы түйүн жана эки жумушчу түйүн бар. Жумушчу түйүндөрүнүн биринде кызгылт сары поддон, сактагыч, реплика контроллери жана жашыл Docker Couchbase контейнери бар. Кластердин ичинде, түйүндөрдүн үстүндө, кызгылт көк тик бурчтук Кызматты сырттан жеткиликтүү көрсөтүп турат. Бул архитектура аппараттын өзүндө маалыматтарды сактоо үчүн сунушталат. Керек болсо, кийинки слайдда көрсөтүлгөндөй, мен өзүмдүн маалыматтарымды EBSде кластерден тышкары сактай алам. Бул масштабдаштыруунун типтүү модели, бирок аны колдонууда эске алуу керек болгон каржылык аспект бар - тармактын кайсы бир жеринде маалыматтарды сактоо хостко караганда кымбатыраак болушу мүмкүн. Контейнерлөө чечимдерин тандап жатканда, бул олуттуу аргументтердин бири.
Docker сыяктуу эле, сиз Portworx менен туруктуу Kubernetes контейнерлерин колдоно аласыз.
Бул учурдагы Kubernetes 1.6 терминологиясында "StatefulSet" деп аталат - Podду токтотуу жана Graceful Oturdown боюнча окуяларды иштеткен Статалдуу колдонмолор менен иштөө ыкмасы. Биздин учурда мындай тиркемелер маалымат базасы болуп саналат. Менин блогумда сиз Portworx аркылуу Kubernetesте StatefulSet кантип түзүүнү окуй аласыз.
Келгиле, өнүгүү жагына токтолсок. Мен айткандай, Dockerдин 2 версиясы бар - CE жана EE, биринчи учурда биз ай сайын жаңыланып турган 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 сүрөтүнүн жаңы версиясын жана жаңыртуу ыкмасын жаңыртуу-параллелдүүлүк 2 көрсөтөм. 2 саны система 2 тиркеме сүрөтүн жаңылай турганын билдирет. бир эле учурда, андан кийин 10 секунддук жаңыртуу кечигүү 10 сек, андан кийин кийинки 2 сүрөт дагы 2 түйүндө жаңыртылат ж.б. Бул жөнөкөй жаңыртуу механизми сизге Dockerдин бир бөлүгү катары берилген.
Kubernetesте жылма жаңыртуу ушундай иштейт. Репликация контроллери rc бир эле версиянын репликаларынын топтомун түзөт жана бул webapp-rc ичиндеги ар бир подкастка etcd ичинде жайгашкан энбелгиси берилет. Мага подключ керек болгондо, көрсөтүлгөн энбелги менен подколь менен камсыз кылган etcd репозиторийине кирүү үчүн Колдонмо кызматын колдоном.
Бул учурда, бизде WildFly версиясынын 3 тиркемесин иштеткен Репликация контроллерунда 1 поддон бар. Фондук режимде жаңыртып жатканда, аягында окшош ат менен башка репликация контроллери түзүлөт - - xxxxx, мында x кокус сандар, жана ошол эле этикеткалар менен. Эми Колдонмо кызматында тиркеменин эски версиясы менен үч поддон жана жаңы Репликация контроллерунда жаңы версиясы бар үч поддон бар. Андан кийин, эски подъезддер өчүрүлөт, жаңы подъезддер менен репликация контроллери кайра аталат жана ишке киргизилет.
Мониторингге өтөбүз. 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 (контейнер кеңешчиси үчүн кыскача). Ал иштеп жаткан контейнерлерден ресурстардын колдонулушу жана өндүрүмдүүлүк маалыматтарын талдап, камсыздайт жана Prometheus көрсөткүчтөрүн кутудан чыгып берет. Бул курал жөнүндө өзгөчө нерсе, ал акыркы 60 секунд үчүн гана маалыматтарды берет. Ошондуктан, сиз бул маалыматтарды чогултуп, узак мөөнөттүү процесске мониторинг жүргүзүү үчүн аны маалымат базасына киргизе билишиңиз керек. Ал ошондой эле Grafana же Kibana аркылуу башкаруу панелинин көрсөткүчтөрүн графикалык түрдө көрсөтүү үчүн колдонулушу мүмкүн. Менин блогумда CAdvisor'ду Кибана панелинин жардамы менен контейнерлерди көзөмөлдөө үчүн кантип колдонуу керектиги толук сүрөттөлгөн.
Кийинки слайд Prometheus акыркы чекитинин чыгышы кандай экенин жана көрсөтүүгө жеткиликтүү көрсөткүчтөрдү көрсөтөт.
Төмөнкү сол жакта HTTP сурамдары, жооптору ж.б. үчүн көрсөткүчтөрдү көрөсүз, оң жакта алардын графикалык дисплейи.
Kubernetes ошондой эле орнотулган мониторинг куралдарын камтыйт. Бул слайд бир мастер жана үч жумушчу түйүн камтыган типтүү кластерди көрсөтөт.
Жумушчу түйүндөрдүн ар бири автоматтык түрдө ишке киргизилген cAdvisor'ду камтыйт. Мындан тышкары, Heapster, Kubernetes версиясы 1.0.6 жана андан жогору шайкеш келген аткарууну көзөмөлдөө жана метрикаларды чогултуу системасы бар. Heapster сизге жумуш жүктөмүнүн, поддондордун жана контейнерлердин аткаруу көрсөткүчтөрүн гана эмес, ошондой эле бүткүл кластер тарабынан түзүлгөн окуяларды жана башка сигналдарды чогултууга мүмкүндүк берет. Маалыматтарды чогултуу үчүн, ал ар бир поддондун Kubelet менен сүйлөшүп, маалыматты автоматтык түрдө InfluxDB маалымат базасында сактайт жана аны метрика катары Grafana башкаруу панелине чыгарат. Бирок, эсиңизде болсун, эгер сиз miniKube колдонуп жатсаңыз, бул функция демейки боюнча жеткиликтүү эмес, андыктан мониторинг үчүн кошумчаларды колдонушуңуз керек болот. Ошентип, бардыгы контейнерлерди кайда иштеткениңизден жана демейки боюнча кайсы мониторинг куралдарын колдоно ала турганыңыздан жана өзүнчө кошумча катары орнотушуңуз керек болгонуңуздан көз каранды.
Кийинки слайдда менин контейнерлеримдин иштөө абалын көрсөткөн Grafana башкаруу такталары көрсөтүлгөн. Бул жерде абдан көп кызыктуу маалыматтар бар. Албетте, SysDig, DataDog, NewRelic сыяктуу көптөгөн коммерциялык Docker жана Kubernetes процесстерин көзөмөлдөө куралдары бар. Алардын айрымдарынын 30 жылдык акысыз сыноо мөөнөтү бар, ошондуктан сиз аракет кылып, сизге эң ылайыктуусун таба аласыз. Жеке мен Kubernetes менен жакшы интеграцияланган SysDig жана NewRelicти колдонгум келет. Docker жана Kubernetes платформаларына бирдей жакшы интеграцияланган куралдар бар.
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com