O abordare modernă a operațiunilor rezolvă multe probleme stringente de afaceri. Containerele și orchestratorii facilitează scalarea proiectelor de orice complexitate, simplifică lansarea de noi versiuni, le fac mai fiabile, dar în același timp creează probleme suplimentare pentru dezvoltatori. Programatorului, în primul rând, îi pasă de codul său: arhitectură, calitate, performanță, eleganță - și nu cum va funcționa în Kubernetes și cum să-l testeze și să-l depaneze după ce a făcut chiar și modificări minime. Prin urmare, este, de asemenea, destul de natural ca instrumentele pentru Kubernetes să fie dezvoltate în mod activ, ajutând la rezolvarea problemelor chiar și a celor mai „arhaici” dezvoltatori și permițându-le să se concentreze asupra principalului lucru.
Această recenzie oferă informații scurte despre unele dintre instrumentele care ușurează viața unui programator al cărui cod rulează în pod'ax-ul unui cluster Kubernetes.
Ajutoare simple
Kubectl-depanare
- Esenta: adăugați containerul într-un Pod și vedeți ce se întâmplă în el.
- .
- Scurte statistici GH: 715 stele, 54 commit-uri, 9 colaboratori.
- Limba: Du-te.
- Licență: Apache License 2.0.
Acest plugin pentru kubectl vă permite să creați un container suplimentar în interiorul podului de interes, care va partaja spațiul de nume al procesului cu alte containere. În el puteți depana funcționarea podului: verificați rețeaua, ascultați traficul din rețea, faceți o parte a procesului de interes etc.
De asemenea, puteți trece la containerul de proces rulând chroot /proc/PID/root - acest lucru poate fi foarte convenabil atunci când trebuie să obțineți un shell rădăcină într-un container pentru care este setat în manifest securityContext.runAs.
Instrumentul este simplu și eficient, așa că poate fi util oricărui dezvoltator. Am scris mai multe despre asta în .
Telepresenta
- Esenta: transferați aplicația pe computer. Dezvoltați și depanați local.
- ; .
- Scurtă statistică GH: 2131 de stele, 2712 de comite, 33 de colaboratori.
- Limbaj: Python.
- Licență: Apache License 2.0.
Ideea acestui snap-in este de a lansa un container cu aplicația pe computerul utilizatorului local și de a proxy tot traficul de la cluster la acesta și înapoi. Această abordare vă permite să dezvoltați local prin simpla editare a fișierelor în IDE-ul dvs. preferat: rezultatele vor fi disponibile imediat.
Avantajele rulării locale sunt comoditatea editărilor și a rezultatelor instantanee, capacitatea de a depana aplicația în mod obișnuit. Dezavantajul este că este pretențios la viteza de conectare, ceea ce se observă mai ales atunci când trebuie să lucrezi cu o aplicație cu RPS și trafic destul de mari. În plus, Telepresence are probleme cu monturile de volum pe Windows, ceea ce poate fi o limitare decisivă pentru dezvoltatorii obișnuiți cu acest OS.
Am împărtășit deja experiența noastră de utilizare a Teleprezenței .
Ksync
- Esenta: sincronizare aproape instantanee a codului cu containerul din cluster.
- .
- Scurte statistici GH: 555 stele, 362 commit-uri, 11 colaboratori.
- Limba: Du-te.
- Licență: Apache License 2.0.
Utilitarul vă permite să sincronizați conținutul unui director local cu directorul unui container care rulează în cluster. Un astfel de instrument este perfect pentru dezvoltatorii în limbaje de programare de scriptare, a căror problemă principală este livrarea codului într-un container care rulează. Ksync este conceput pentru a ameliora această durere de cap.
Când este inițializat o dată prin comandă ksync init un DaemonSet este creat în cluster, care este utilizat pentru a monitoriza starea sistemului de fișiere al containerului selectat. Pe computerul său local, dezvoltatorul rulează comanda ksync watch, care monitorizează configurațiile și rulează , care sincronizează direct fișierele cu clusterul.
Tot ce rămâne este să îi instruiți pe ksync ce să sincronizeze cu ce. De exemplu, această comandă:
ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/
...va crea un observator numit myprojectcare va căuta un pod cu o etichetă app=backend și încercați să sincronizați directorul local /home/user/myproject/ cu catalog /var/www/myproject/ la containerul numit php.
Probleme și note despre ksync din experiența noastră:
- Trebuie utilizat pe nodurile clusterului Kubernetes
overlay2ca driver de stocare pentru Docker. Utilitarul nu va funcționa cu alții. - Când utilizați Windows ca sistem de operare client, este posibil ca monitorul sistemului de fișiere să nu funcționeze corect. Această eroare a fost observată când lucrați cu directoare mari - cu un număr mare de fișiere și directoare imbricate. Noi am creat în proiectul de sincronizare, dar nu există încă niciun progres în acest sens (de la începutul lunii iulie).
- Folosește fișierul pentru a specifica căi sau modele de fișiere care nu trebuie să fie sincronizate (de exemplu, directoare
app/cacheи.git). - În mod implicit, ksync va reporni containerul ori de câte ori se schimbă fișierele. Pentru Node.js acest lucru este convenabil, dar pentru PHP este complet inutil. Este mai bine să dezactivați opcache-ul și să utilizați steag
--reload=false. - Configurația poate fi întotdeauna corectată în
$HOME/.ksync/ksync.yaml.
Suc de fructe
- Esenta: procesele de depanare direct în cluster.
- .
- Scurtă statistică GH: 1154 de stele, 279 de comite, 23 de colaboratori.
- Limba: Du-te.
- Licență: Apache License 2.0.
Acest instrument este conceput pentru procesele de depanare direct în pod-uri. Utilitarul este simplu și vă permite interactiv să selectați depanatorul dorit (Vezi mai jos) și namespace + pod, în procesul căruia trebuie să intervii. Suportat în prezent:
- delve - pentru aplicațiile Go;
- GDB - prin distanta tinta + port forwarding;
- Redirecționarea portului JDWP pentru depanarea aplicațiilor Java.
Pe partea IDE, suportul este disponibil numai în VScode (folosind ), cu toate acestea, planurile pentru anul curent (2019) includ Eclipse și Intellij.
Pentru a depana procesele, Squash rulează un container privilegiat pe nodurile clusterului, așa că trebuie mai întâi să vă familiarizați cu capabilitățile pentru a evita problemele de securitate.
Soluții integrate
Să trecem la artileria grea - mai multe proiecte „la scară largă” concepute pentru a satisface imediat multe dintre nevoile dezvoltatorilor.
NB: În această listă, desigur, există un loc pentru utilitarul nostru Open Source (cunoscut anterior ca dapp). Cu toate acestea, am scris și am vorbit deja despre asta de mai multe ori și, prin urmare, am decis să nu-l includem în recenzie. Pentru cei care doresc să se familiarizeze mai bine cu capacitățile sale, recomandăm citirea/ascultarea raportului „".
DevSpace
- Esenta: pentru cei care doresc să înceapă să lucreze în Kubernetes, dar nu doresc să se adâncească în jungla acestuia.
- .
- Scurtă statistică GH: 630 de stele, 1912 comite, 13 colaboratori.
- Limba: Du-te.
- Licență: Apache License 2.0.
O soluție de la compania cu același nume, care oferă clustere gestionate cu Kubernetes pentru dezvoltarea echipei. Utilitarul a fost creat pentru clustere comerciale, dar funcționează excelent cu oricare alții.
Când rulați comanda devspace init în catalogul proiectelor vi se vor oferi (interactiv):
- selectați un cluster Kubernetes funcțional,
- Folosește ce ai
Dockerfile(sau generați unul nou) pentru a crea un container pe baza acestuia, - selectați un depozit pentru stocarea imaginilor containerului etc.
După toți acești pași pregătitori, puteți începe dezvoltarea rulând comanda devspace dev. Acesta va construi containerul, îl va încărca în depozit, va lansa implementarea în cluster și va începe redirecționarea portului și sincronizarea containerului cu directorul local.
Opțional, vi se va solicita să mutați terminalul în container. Nu ar trebui să refuzați, pentru că în realitate containerul începe cu comanda sleep, iar pentru testarea reală aplicația trebuie lansată manual.
În sfârșit, echipa devspace deploy lansează aplicația și infrastructura asociată în cluster, după care totul începe să funcționeze în modul de luptă.
Toată configurația proiectului este stocată într-un fișier devspace.yaml. Pe lângă setările mediului de dezvoltare, puteți găsi și o descriere a infrastructurii din acesta, similară cu manifestele standard Kubernetes, doar foarte simplificată.
Arhitectura și etapele principale ale lucrului cu DevSpace
În plus, este ușor să adăugați o componentă predefinită (de exemplu, un DBMS MySQL) sau o diagramă Helm la proiect. Citiți mai multe în - nu este complicat.
Scaffold
- ; .
- Scurtă statistică GH: 7423 de stele, 4173 de comite, 136 de colaboratori.
- Limba: Du-te.
- Licență: Apache License 2.0.
Acest utilitar de la Google pretinde că acoperă toate nevoile unui dezvoltator al cărui cod va rula cumva pe un cluster Kubernetes. Începeți să îl utilizați nu este la fel de ușor ca devspace: fără interactivitate, detectarea limbii și crearea automată Dockerfile nu vi-l vor oferi aici.
Cu toate acestea, dacă acest lucru nu vă sperie, iată ce vă permite să faceți Skaffold:
- Urmăriți modificările codului sursă.
- Sincronizați-l cu recipientul pentru păstăi dacă nu necesită asamblare.
- Colectați containere cu cod, dacă limbajul este interpretat, sau compilați artefacte și împachetați-le în containere.
- Imaginile rezultate sunt verificate automat folosind .
- Etichetarea și încărcarea imaginilor în Registrul Docker.
- Implementați o aplicație într-un cluster folosind kubectl, Helm sau kustomize.
- Efectuați redirecționarea portului.
- Depanați aplicațiile scrise în Java, Node.js, Python.
Fluxul de lucru în diferite variante este descris declarativ în fișier skaffold.yaml. Pentru un proiect, puteți defini și mai multe profiluri în care puteți modifica parțial sau complet etapele de asamblare și implementare. De exemplu, pentru dezvoltare, specificați o imagine de bază convenabilă pentru dezvoltator și pentru punere în scenă și producție - una minimă (+ utilizare securityContext containere sau redefini clusterul în care va fi implementată aplicația).
Containerele Docker pot fi construite local sau de la distanță: în sau într-un cluster folosind . Bazel și Jib Maven/Gradle sunt de asemenea acceptate. Pentru etichetare, Skaffold acceptă multe strategii: prin git commit hash, dată/ora, sha256-sum de surse etc.
Separat, este de remarcat posibilitatea de a testa containerele. Cadrul container-structură-test deja menționat oferă următoarele metode de verificare:
- Executarea comenzilor în contextul unui container cu urmărirea stărilor de ieșire și verificarea rezultatului text al comenzii.
- Verificarea prezenței fișierelor în container și potrivirea atributelor specificate.
- Controlul conținutului fișierului folosind expresii regulate.
- Verificarea metadatelor imaginii (
ENV,ENTRYPOINT,VOLUMESetc). - Verificarea compatibilității licenței.
Sincronizarea fișierelor cu containerul nu se realizează în cel mai optim mod: Skaffold pur și simplu creează o arhivă cu sursele, o copiază și o despachetează în container (tarbuie instalat). Prin urmare, dacă sarcina dvs. principală este sincronizarea codului, este mai bine să priviți către o soluție specializată (ksync).
Etapele principale ale funcționării Skaffold
În general, instrumentul nu vă permite să faceți abstracție de la manifestele Kubernetes și nu are nicio interactivitate, așa că poate părea dificil de stăpânit. Dar acesta este și avantajul său - o mai mare libertate de acțiune.
Grădină
- ; .
- Scurtă statistică GH: 1063 stele, 1927 comite, 17 colaboratori.
- Limbaj: TypeScript (se plănuiește împărțirea proiectului în mai multe componente, dintre care unele vor fi în Go și, de asemenea, se va realiza un SDK pentru crearea de suplimente în TypeScript/JavaScript și Go).
- Licență: Apache License 2.0.
La fel ca Skaffold, Garden își propune să automatizeze procesele de livrare a codului aplicației către clusterul K8s. Pentru a face acest lucru, trebuie mai întâi să descrii structura proiectului într-un fișier YAML, apoi să rulezi comanda garden dev. Ea va face toată magia:
- Colectați containere cu diferite părți ale proiectului.
- Efectuează teste de integrare și unitate, dacă au fost descrise.
- Implementează toate componentele proiectului în cluster.
- Dacă codul sursă se modifică, va reporni întreaga conductă.
Obiectivul principal al utilizării acestui instrument este de a partaja un cluster la distanță cu o echipă de dezvoltare. În acest caz, dacă unii dintre pașii de construire și testare au fost deja efectuate, acest lucru va accelera semnificativ întregul proces, deoarece Garden va putea folosi rezultatele stocate în cache.
Un modul de proiect poate fi un container, un container Maven, o diagramă Helm, un manifest pentru kubectl apply sau chiar o funcție OpenFaaS. Mai mult, oricare dintre module poate fi extras dintr-un depozit Git la distanță. Un modul poate defini sau nu servicii, sarcini și teste. Serviciile și sarcinile pot avea dependențe, astfel încât să puteți determina secvența de implementare a unui anumit serviciu și să organizați lansarea sarcinilor și a testelor.
Garden oferă utilizatorului un tablou de bord frumos (în prezent ), care afișează graficul proiectului: componente, secvența de asamblare, execuția sarcinilor și testelor, conexiunile și dependențele acestora. Chiar în browser, puteți vizualiza jurnalele tuturor componentelor proiectului și puteți verifica ce iese o anumită componentă prin HTTP (dacă, desigur, este declarată o resursă de intrare pentru aceasta).
Panou pentru gradina
Acest instrument are, de asemenea, un mod de reîncărcare la cald, care sincronizează pur și simplu modificările de script cu containerul din cluster, accelerând foarte mult procesul de depanare a aplicației. Garden are unul bun si nu rau , permițându-vă să vă obișnuiți rapid cu el și să începeți să îl utilizați. Apropo, recent am publicat de la autorii săi.
Concluzie
Desigur, această listă de instrumente pentru dezvoltarea și depanarea aplicațiilor în Kubernetes nu se limitează la. Există multe alte utilități foarte utile și practice care merită, dacă nu un articol separat, atunci măcar o mențiune. Spune-ne ce folosești, ce probleme ai întâmpinat și cum le-ai rezolvat!
PS
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com