Docker Swarm, Kubernetes è Mesos sò i quadri di orchestrazione di container più populari. In u so discorsu, Arun Gupta compara i seguenti aspetti di Docker, Swarm è Kubernetes:
- Sviluppu lucale.
- Funzioni di implementazione.
- Applicazioni multi-container.
- Scuperta di serviziu.
- Scaling u serviziu.
- Eseguite una volta i travaglii.
- Integrazione cù Maven.
- Actualizazione "Rolling".
- Creazione di un cluster di basa di dati Couchbase.
In u risultatu, guadagnerete una comprensione chjara di ciò chì ogni strumentu d'orchestrazione hà da offre è amparà à utilizà sti piattaforme in modu efficace.
Arun Gupta hè u tecnulugu capu per i prudutti open-source in Amazon Web Services, chì hà sviluppatu e cumunità di sviluppatori Sun, Oracle, Red Hat è Couchbase per più di 10 anni. Hà una vasta sperienza di travaglià in squadre interfunzionali chì sviluppanu è implementanu strategie per campagne è prugrammi di marketing. Hà guidatu squadre di ingegneri Sun, hè unu di i fundatori di a squadra Java EE è u creatore di a filiera US di Devoxx4Kids. Arun Gupta hè l'autore di più di 2 mila posti in blogs IT è hà datu discorsi in più di 40 paesi.
A linea 55 cuntene un COUCHBASE_URI chì punta à stu serviziu di basa di dati, chì hè statu ancu creatu cù u schedariu di cunfigurazione Kubernetes. Se fighjate à a linea 2, pudete vede tipu: U serviziu hè u serviziu chì aghju creatu chjamatu couchbase-service, è u listessu nome hè listatu nantu à a linea 4. Sottu sò qualchi porti.
I linii chjave sò 6 è 7. In u serviziu dicu: "Ehi, queste sò e etichette chì cercu!", è queste etichette ùn sò più chè nomi di coppia variabile, è a linea 7 punta à u mo couchbase-rs-pod. applicazione. I seguenti sò i porti chì furniscenu accessu à sti stessi etichette.
In a linea 19 crea un novu tipu ReplicaSet, a linea 31 cuntene u nome di l'imaghjini, è e linee 24-27 puntanu à i metadati assuciati cù u mo pod. Questu hè esattamente ciò chì u serviziu cerca è ciò chì a cunnessione deve esse fatta. À a fine di u schedariu ci hè un tipu di cunnessione trà e linee 55-56 è 4, dicendu: "utilizate stu serviziu!"
Allora, aghju principiatu u mo serviziu quandu ci hè una replica set, è postu chì ogni replica set hà u so propiu portu cù l'etichetta currispondente, hè inclusu in u serviziu. Da u puntu di vista di u sviluppatore, solu chjamate u serviziu, chì poi usa u settore di repliche chì avete bisognu.
In u risultatu, aghju un pod WildFly chì cumunicà cù u backend di a basa di dati via Couchbase Service. Puderaghju aduprà u frontend cù parechje pods WildFly, chì cumunicà ancu cù u backend di couchbase per mezu di u serviziu di couchbase.
In seguitu, guardemu cumu un serviziu situatu fora di u cluster cumunicà attraversu u so indirizzu IP cù elementi chì sò situati in u cluster è avè un indirizzu IP internu.
Allora, i cuntenituri senza statu sò grandi, ma quantu hè bonu per utilizà cuntenituri stateful? Fighjemu i paràmetri di u sistema per cuntenituri stateful, o persistenti. In Docker, ci sò 4 approcci diffirenti per u layout di almacenamiento di dati chì duvete prestu attente. U primu hè Implicit Per-Container, chì significa chì quandu si usa couchbase, MySQL o MyDB satateful containers, tutti cumincianu cù u Sandbox predeterminatu. Questu hè, tuttu ciò chì hè guardatu in a basa di dati hè guardatu in u cuntainer stessu. Se u cuntinuu sparisce, i dati sparisce cun ellu.
U sicondu hè Explicit Per-Container, quandu crea un almacenamentu specificu cù u voluminu di docker crea cumandamentu è almacena dati in questu. U terzu approcciu Per-Host hè assuciatu cù a mapping di almacenamentu, quandu tuttu ciò chì hè almacenatu in u cuntinuu hè simultaneamente duplicatu nantu à l'ospite. Se u cuntinuu falla, i dati restanu nantu à l'ospite. L'ultime hè l'usu di parechji òspiti Multi-Host, chì hè cunsigliatu in u stadiu di produzzione di diverse soluzioni. Diciamu chì i vostri cuntenituri cù e vostre applicazioni sò in esecuzione nantu à l'ospiti, ma vulete almacenà e vostre dati in un locu in Internet, è per questu utilizate mapping automaticu per i sistemi distribuiti.
Ognunu di sti metudi usa un locu di almacenamentu specificu. Implicit and Explicit Per-Container almacenanu dati nantu à l'ospite in /var/lib/docker/volumes. Quandu si usa u metudu Per-Host, l'almacenamiento hè muntatu in u cuntinuu, è u cuntinuu stessu hè muntatu nantu à l'ospite. Per i multihosts, si ponu utilizà suluzioni cum'è Ceph, ClusterFS, NFS, etc.
Se un containeru persistente falla, u repertoriu di almacenamiento diventa inaccessibile in i primi dui casi, ma in l'ultimi dui casi l'accessu hè mantinutu. Tuttavia, in u primu casu, pudete accede à u repository attraversu un host Docker in esecuzione in una macchina virtuale. In u sicondu casu, i dati ùn serà micca persu ancu, perchè avete creatu un almacenamiento esplicitu.
Se l'ospitu falla, u repertoriu di almacenamiento ùn hè micca dispunibule in i primi trè casi; in l'ultimu casu, a cunnessione cù l'almacenamiento ùn hè micca interrotta. Infine, a funzione sparta hè cumpletamente escluduta per u almacenamiento in u primu casu è hè pussibule in u restu. In u sicondu casu, pudete sparte l'almacenamiento secondu chì a vostra basa di dati sustene u almacenamentu distribuitu o micca. In u casu di Per-Host, a distribuzione di dati hè pussibule solu nantu à un ospite datu, è per un multihost hè furnitu da l'espansione di cluster.
Questu deve esse cunsideratu quandu creanu cuntenituri stateful. Un altru strumentu Docker utile hè u plugin Volume, chì travaglia nantu à u principiu di "batterie prisenti, ma deve esse rimpiazzatu". Quandu avete principiatu un containeru Docker, dice: "Ehi, una volta chì avete principiatu un containeru cù una basa di dati, pudete almacenà e vostre dati in questu container!" Questa hè a funzione predeterminata, ma pudete cambià. Stu plugin permette di utilizà una unità di rete o qualcosa simili invece di una basa di dati di cuntainer. Include un driver predeterminatu per u almacenamentu basatu in l'ospite è permette l'integrazione di u containeru cù sistemi di almacenamentu esterni cum'è Amazon EBS, Azure Storage è dischi persistenti GCE.
A prossima slide mostra l'architettura di u plugin Docker Volume.
U culore turchinu rapprisenta u cliente Docker assuciatu cù l'ospite blu Docker, chì hà un mutore di almacenamiento Locale chì vi furnisce cuntenituri per almacenà dati. U verde indica u Plugin Client è u Plugin Daemon, chì sò ancu cunnessi à l'ospite. Offrenu l'uppurtunità di almacenà e dati in u almacenamentu di a rete di u tipu di Storage Backend chì avete bisognu.
U plugin Docker Volume pò esse usatu cù u almacenamiento Portworx. U modulu PX-Dev hè in realtà un cuntinuu chì eseguite chì cunnetta à u vostru host Docker è vi permette di almacenà facilmente e dati in Amazon EBS.
U cliente Portworx permette di monitorà u statutu di diversi cuntenituri di almacenamiento chì sò cunnessi à u vostru òspite. Se visitate u mo blog, pudete leghje cumu fà u più di Portworx cù Docker.
U cuncettu di almacenamiento in Kubernetes hè simile à Docker è hè rapprisintatu da cartulari chì sò accessibili à u vostru cuntinuu in un pod. Sò indipindenti di a vita di ogni cuntinuu. I tipi di almacenamiento più cumuni dispunibuli sò hostPath, nfs, awsElasticBlockStore è gsePersistentDisk. Fighjemu un ochju à cumu si travaglianu sti magazzini in Kubernetes. Di genere, u prucessu di cunnessu li hè custituitu di 3 passi.
U primu hè chì qualchissia in u latu di a rete, di solitu un amministratore, vi furnisce un almacenamentu persistente. Ci hè un schedariu di cunfigurazione PersistentVolume currispundente per questu. In seguitu, u sviluppatore di l'applicazione scrive un schedariu di cunfigurazione chjamatu PersistentVolumeClaim, o una dumanda di almacenamiento PVC, chì dice: "Aghju 50 GB di almacenamiento distribuitu furnitu, ma per chì altre persone anu ancu aduprà a so capacità, dicu à questu PVC chì aghju attualmente. bisognu solu 10 GB ". Infine, u terzu passu hè chì a vostra dumanda hè muntata cum'è almacenamiento, è l'applicazione chì hà u pod, o replica set, o qualcosa simili, cumencia à aduprà. Hè impurtante di ricurdà chì stu prucessu hè custituitu da i 3 passi citati è hè scalable.
A prossima diapositiva mostra u Kubernetes Persistence Container di l'architettura AWS.
Dentru u rettangulu marrone chì rapprisenta u cluster Kubernetes, ci hè un nodu maestru è dui nodi di u travagliu, indicati in giallu. Unu di i nodi di u travagliu cuntene un pod aranciu, almacenamiento, un controller di replica, è un cuntainer Docker Couchbase verde. Dentru u cluster, sopra à i nodi, un rectangulu viole indica u serviziu accessibile da l'esternu. Questa architettura hè cunsigliatu per almacenà e dati nantu à u dispusitivu stessu. In casu di necessariu, possu almacenà e mo dati in EBS fora di u cluster, cum'è mostra in a prossima slide. Questu hè un mudellu tipicu per a scala, ma ci hè un aspettu finanziariu per cunsiderà quandu l'utilizanu - l'almacenamiento di dati in un locu in a reta pò esse più caru cà in un host. Quandu sceglite suluzione di containerizazione, questu hè unu di l'argumenti di pesu.
Cum'è cù Docker, pudete aduprà cuntenituri persistenti Kubernetes cù Portworx.
Questu hè ciò chì in a terminologia attuale di Kubernetes 1.6 hè chjamatu "StatefulSet" - un modu di travaglià cù l'applicazioni Stateful chì processa l'avvenimenti per fermà u Pod è eseguisce Graceful Shutdown. In u nostru casu, tali applicazioni sò basa di dati. In u mo blog pudete leghje cumu creà un StatefulSet in Kubernetes cù Portworx.
Parlemu di l'aspettu di sviluppu. Comu dissi, Docker hà versioni 2 - CE è EE, in u primu casu parlemu di una versione stabile di l'Edizione Comunitaria, chì hè aghjurnata una volta ogni 3 mesi, in cuntrastu à a versione aghjurnata mensili di EE. Pudete scaricà Docker per Mac, Linux o Windows. Una volta installatu, Docker aggiornerà automaticamente è hè assai faciule per inizià.
Per Kubernetes, preferimu a versione Minikube - hè un bonu modu per cumincià cù a piattaforma creendu un cluster in un unicu node. Per creà clusters di parechji nodi, l'scelta di versioni hè più larga: sò kops, kube-aws (CoreOS + AWS), kube-up (obsoleti). Sè vo circate di utilizà Kubernetes basatu in AWS, vi cunsigliu di unisce à l'AWS SIG, chì si riunisce in linea ogni venneri è publica una varietà di materiali interessanti nantu à u travagliu cù AWS Kubernetes.
Fighjemu cume Rolling Update hè realizatu nantu à queste piattaforme. Se ci hè un cluster di parechji nodi, allora usa una versione specifica di l'imaghjini, per esempiu, WildFly: 1. Un aghjurnamentu rolling significa chì a versione di l'imaghjini hè rimpiazzata in sequenza cù una nova in ogni node, unu dopu à l'altru.
Per fà questu, aghju utilizatu u cumandamentu di l'aghjurnamentu di u serviziu docker (nome di serviziu), in quale aghju specificà a nova versione di l'imaghjini WildFly: 2 è u metudu d'aghjurnamentu update-parallelism 2. U numeru 2 significa chì u sistema aghjurnà l'imaghjini di l'applicazione 2. simultaneamente, poi un ritardu di aghjurnamentu di 10 secondi 10s, dopu à quale l'imaghjini 2 prossime seranu aghjurnati nantu à 2 nodi più, etc. Stu meccanisimu simplice di aghjurnamentu rolling hè furnitu à voi cum'è parte di Docker.
In Kubernetes, un aghjurnamentu rolling funziona cusì. U controller di replicazione rc crea un settore di repliche di a stessa versione, è ogni pod in questa webapp-rc hè furnitu cù una etichetta situata in etcd. Quandu aghju bisognu di un pod, aghju utilizatu u serviziu di l'applicazione per accede à u repository etcd, chì mi furnisce u pod cù l'etichetta specifica.
In questu casu, avemu 3 pods in u controller di replicazione chì eseguisce l'applicazione WildFly versione 1. Quandu l'aghjurnà in u sfondate, un altru controller di replicazione hè creatu cù u listessu nome è indice à a fine - - xxxxx, induve x sò numeri aleatorii, è cù i stessi etichette. Avà u serviziu di l'applicazione hà trè pods cù a versione antica di l'applicazione è trè pods cù a nova versione in u novu controller di replicazione. Dopu questu, i vechji pods sò sguassati, u controller di replicazione cù i novi pods hè rinominatu è messu in opera.
Passemu à u monitoraghju. Docker hà assai cumandamenti di monitoraghju integrati. Per esempiu, l'interfaccia di linea di cummanda di statistiche di u contenitore di docker permette di visualizà infurmazioni nantu à u statu di i cuntenituri à a cunsola ogni secondu - usu di processore, usu di discu, carica di rete. U strumentu Docker Remote API furnisce dati nantu à cumu u cliente cumunicà cù u servitore. Utiliza cumandamenti simplici, ma hè basatu annantu à l'API REST Docker. In questu casu, e parolle REST, Flash, Remote significanu a stessa cosa. Quandu si cumunicà cù l'ospite, hè una API REST. L'API Docker Remote permette di ottene più infurmazione nantu à l'esecuzione di cuntenituri. U mo blog delinea i dettagli di l'usu di sta monitorizazione cù Windows Server.
U monitoraghju di l'avvenimenti di u sistema docker quandu eseguisce un cluster multi-host permette di ottene dati nantu à un crash d'ospite o un crash di cuntainer in un host specificu, scaling services, è simili. Partendu da Docker 1.20, include Prometheus, chì incorpora endpoints in applicazioni esistenti. Questu permette di riceve metriche via HTTP è di vede nantu à i dashboards.
Un'altra funzione di monitoraghju hè cAdvisor (abbreviazione di cunsigliere di container). Analizeghja è furnisce l'usu di e risorse è e dati di rendiment da i cuntenituri in esecuzione, furnisce metriche di Prometheus ghjustu da a scatula. A cosa particulari di stu strumentu hè chì furnisce solu dati per l'ultimi 60 seconde. Dunque, avete bisognu di pudè cullà sti dati è mette in una basa di dati per pudè monitorà un prucessu longu. Pò esse ancu usatu per visualizà metriche di u dashboard graficamente cù Grafana o Kibana. U mo blog hà una descrizzione dettagliata di cumu utilizà cAdvisor per monitorà i cuntenituri cù u dashboard Kibana.
A prossima diapositiva mostra ciò chì l'output endpoint di Prometheus pare è e metriche dispunibuli per vede.
In u fondu di manca si vede metriche per richieste HTTP, risposte, etc., à a diritta hè a so visualizazione gràfica.
Kubernetes include ancu strumenti di monitoraghju integrati. Questa diapositiva mostra un cluster tipicu chì cuntene un nodu maestru è trè travagliadori.
Ognunu di i nodi di travagliu cuntene un cAdvisor lanciatu automaticamente. Inoltre, ci hè Heapster, un sistema di monitoraghju di u rendiment è di cullezzione di metrica cumpatibile cù a versione Kubernetes 1.0.6 è superiore. Heapster vi permette di cullà micca solu metriche di rendiment di carichi di travagliu, pods è cuntenituri, ma ancu avvenimenti è altri signali generati da tuttu u cluster. Per cullà dati, parla à u Kubelet di ogni pod, guarda automaticamente l'infurmazioni in a basa di dati InfluxDB, è l'emette cum'è metrica à u dashboard Grafana. Tuttavia, tenite in mente chì sè vo site cù miniKube, sta funzione ùn hè micca dispunibile per automaticamente, cusì avete da aduprà addons per u monitoraghju. Allora tuttu dipende da induve eseguite i cuntenituri è quali strumenti di surviglianza pudete aduprà per automaticamente è chì avete bisognu di stallà cum'è add-ons separati.
A prossima diapositiva mostra i dashboards Grafana chì mostranu u statu di esecuzione di i mo cuntenituri. Ci hè assai di dati interessanti quì. Di sicuru, ci sò assai strumenti cummirciali di monitoraghju di u prucessu Docker è Kubernetes, cum'è SysDig, DataDog, NewRelic. Certi di elli anu un periodu di prova gratuitu di 30 anni, cusì pudete pruvà è truvà quellu chì vi cunvene megliu. In modu persunale, preferimu aduprà SysDig è NewRelic, chì integranu bè cù Kubernetes. Ci sò strumenti chì si integranu ugualmente bè in e plataforme Docker è Kubernetes.
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com