Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes

Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes

Un enfocament modern de les operacions resol molts problemes empresarials urgents. Els contenidors i els orquestradors faciliten l'escala de projectes de qualsevol complexitat, simplifiquen el llançament de noves versions, els fan més fiables, però al mateix temps creen problemes addicionals per als desenvolupadors. El programador, en primer lloc, es preocupa pel seu codi: arquitectura, qualitat, rendiment, elegància, i no com funcionarà a Kubernetes i com provar-lo i depurar-lo després de fer canvis mínims. Per tant, també és molt natural que s'estan desenvolupant activament eines per a Kubernetes, que ajuden a resoldre els problemes fins i tot dels desenvolupadors més "arcaics" i els permeten centrar-se en el principal.

Aquesta revisió proporciona informació breu sobre algunes de les eines que faciliten la vida a un programador el codi del qual s'executa al pod'ax d'un clúster de Kubernetes.

Ajudants senzills

Kubectl-depuració

  • La línia de fons: afegiu el vostre contenidor a un pod i mireu què hi passa.
  • GitHub.
  • Breus estadístiques de GH: 715 estrelles, 54 commits, 9 col·laboradors.
  • Idioma: Anar.
  • Llicència: Apache License 2.0.

Aquest connector per a kubectl us permet crear un contenidor addicional dins del pod d'interès, que compartirà l'espai de noms del procés amb altres contenidors. En ell podeu depurar el funcionament del pod: comprovar la xarxa, escoltar el trànsit de la xarxa, fer un resum del procés d'interès, etc.

També podeu canviar al contenidor del procés executant-lo chroot /proc/PID/root - Això pot ser molt convenient quan necessiteu obtenir un shell arrel en un contenidor per al qual està establert al manifest securityContext.runAs.

L'eina és senzilla i eficaç, de manera que pot ser útil per a tots els desenvolupadors. Vam escriure més sobre això a article a part.

Telepresència

  • La línia de fons: transfereix l'aplicació al teu ordinador. Desenvolupar i depurar localment.
  • Lloc; GitHub.
  • Breus estadístiques de GH: 2131 estrelles, 2712 commits, 33 col·laboradors.
  • Idioma: Python.
  • Llicència: Apache License 2.0.

La idea d'aquest complement és llançar un contenidor amb l'aplicació a l'ordinador de l'usuari local i proxy tot el trànsit des del clúster cap a ell i cap enrere. Aquest enfocament us permet desenvolupar localment simplement editant fitxers al vostre IDE favorit: els resultats estaran disponibles immediatament.

Els avantatges d'executar-se localment són la comoditat de les edicions i els resultats instantanis, la possibilitat de depurar l'aplicació de la manera habitual. L'inconvenient és que exigeix ​​la velocitat de connexió, cosa que es nota especialment quan s'ha de treballar amb una aplicació amb RPS i trànsit força elevats. A més, Telepresence té problemes amb els muntatges de volum a Windows, cosa que pot ser una limitació decisiva per als desenvolupadors acostumats a aquest sistema operatiu.

Ja hem compartit la nostra experiència d'utilitzar la Telepresència aquí.

Ksync

  • La línia de fons: sincronització gairebé instantània del codi amb el contenidor del clúster.
  • GitHub.
  • Breus estadístiques de GH: 555 estrelles, 362 commits, 11 col·laboradors.
  • Idioma: Anar.
  • Llicència: Apache License 2.0.

La utilitat us permet sincronitzar el contingut d'un directori local amb el directori d'un contenidor que s'executa al clúster. Aquesta eina és perfecta per als desenvolupadors de llenguatges de programació de programació, el principal problema dels quals és lliurar codi a un contenidor en execució. Ksync està dissenyat per alleujar aquest mal de cap.

Quan s'inicialitza una vegada per l'ordre ksync init es crea un DaemonSet al clúster, que s'utilitza per supervisar l'estat del sistema de fitxers del contenidor seleccionat. Al seu ordinador local, el desenvolupador executa l'ordre ksync watch, que supervisa les configuracions i les execucions sincronitzant, que sincronitza directament els fitxers amb el clúster.

Tot el que queda és indicar a ksync què ha de sincronitzar amb què. Per exemple, aquesta comanda:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

...crearà un observador anomenat myprojectque buscarà una beina amb una etiqueta app=backend i intenteu sincronitzar el directori local /home/user/myproject/ amb catàleg /var/www/myproject/ al contenidor anomenat php.

Problemes i notes sobre ksync de la nostra experiència:

  • S'ha d'utilitzar als nodes del clúster de Kubernetes overlay2 com a controlador d'emmagatzematge per a Docker. La utilitat no funcionarà amb cap altra.
  • Quan utilitzeu Windows com a sistema operatiu client, és possible que l'observador del sistema de fitxers no funcioni correctament. Aquest error es va notar quan es treballava amb directoris grans, amb un gran nombre de fitxers i directoris imbricats. Vam crear qüestió rellevant en el projecte de sincronització, però encara no hi ha cap avenç (des de principis de juliol).
  • Utilitza el fitxer .stignore per especificar camins o patrons de fitxers que no s'han de sincronitzar (per exemple, directoris app/cache и .git).
  • Per defecte, ksync reiniciarà el contenidor sempre que canviïn els fitxers. Per a Node.js això és convenient, però per a PHP és completament innecessari. És millor desactivar l'opcache i utilitzar la bandera --reload=false.
  • La configuració sempre es pot corregir a $HOME/.ksync/ksync.yaml.

Esquaix

  • La línia de fons: depurar processos directament al clúster.
  • GitHub.
  • Breus estadístiques de GH: 1154 estrelles, 279 commits, 23 col·laboradors.
  • Idioma: Anar.
  • Llicència: Apache License 2.0.

Aquesta eina està dissenyada per depurar processos directament en pods. La utilitat és senzilla i de manera interactiva us permet seleccionar el depurador desitjat (mirar abaix) i espai de noms + pod, en el procés dels quals cal intervenir. Actualment suportat:

  • aprofundir - per a aplicacions Go;
  • GDB - a través de la destinació remota + reenviament de ports;
  • Reenviament de ports JDWP per depurar aplicacions Java.

Al costat de l'IDE, el suport només està disponible a VScode (utilitzant expansió), però, els plans per a l'any actual (2019) inclouen Eclipse i Intellij.

Per depurar processos, Squash executa un contenidor privilegiat als nodes del clúster, de manera que primer us heu de familiaritzar amb les capacitats. mode segur per evitar problemes de seguretat.

Solucions completes

Passem a l'artilleria pesada: projectes més "a gran escala" dissenyats per satisfer immediatament moltes de les necessitats dels desenvolupadors.

NB: En aquesta llista, per descomptat, hi ha un lloc per a la nostra utilitat de codi obert werf (abans conegut com a dapp). Tanmateix, ja n'hem escrit i parlat més d'una vegada i, per tant, hem decidit no incloure'l a la ressenya. Per a aquells que vulguin familiaritzar-se amb les seves capacitats, recomanem llegir/escoltar l'informe "werf és la nostra eina per CI/CD a Kubernetes».

DevSpace

  • La línia de fons: per a aquells que volen començar a treballar a Kubernetes, però no volen endinsar-se en la seva selva.
  • GitHub.
  • Breus estadístiques de GH: 630 estrelles, 1912 commits, 13 col·laboradors.
  • Idioma: Anar.
  • Llicència: Apache License 2.0.

Una solució de l'empresa del mateix nom, que proporciona clústers gestionats amb Kubernetes per al desenvolupament de l'equip. La utilitat es va crear per a clústers comercials, però funciona molt bé amb qualsevol altre.

En executar l'ordre devspace init al catàleg de projectes se us oferirà (de manera interactiva):

  • seleccioneu un clúster de Kubernetes que funcioni,
  • ús existent Dockerfile (o generar-ne un de nou) per crear un contenidor basat en ell,
  • seleccioneu un dipòsit per emmagatzemar imatges de contenidors, etc.

Després de tots aquests passos preparatoris, podeu començar el desenvolupament executant l'ordre devspace dev. Construirà el contenidor, el carregarà al dipòsit, desplegarà el desplegament al clúster i iniciarà el reenviament de ports i la sincronització del contenidor amb el directori local.

Opcionalment, se us demanarà que moveu el terminal al contenidor. No us hauríeu de negar, perquè en realitat el contenidor comença amb l'ordre de repòs, i per fer proves reals l'aplicació s'ha de llançar manualment.

Finalment, l'equip devspace deploy desplega l'aplicació i la infraestructura associada al clúster, després del qual tot comença a funcionar en mode combat.

Tota la configuració del projecte s'emmagatzema en un fitxer devspace.yaml. A més de la configuració de l'entorn de desenvolupament, també hi podeu trobar una descripció de la infraestructura, similar als manifests estàndard de Kubernetes, només molt simplificada.

Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes
Arquitectura i principals etapes de treball amb DevSpace

A més, és fàcil afegir un component predefinit (per exemple, un SGBD MySQL) o un gràfic Helm al projecte. Llegeix més a documentació - no és complicat.

Bastida

  • Lloc; GitHub.
  • Breus estadístiques de GH: 7423 estrelles, 4173 commits, 136 col·laboradors.
  • Idioma: Anar.
  • Llicència: Apache License 2.0.

Aquesta utilitat de Google afirma cobrir totes les necessitats d'un desenvolupador el codi del qual s'executarà d'alguna manera en un clúster de Kubernetes. Començar a utilitzar-lo no és tan fàcil com devspace: sense interactivitat, detecció d'idiomes i creació automàtica Dockerfile aquí no t'ho oferiran.

Tanmateix, si això no us fa por, aquí teniu el que us permet fer Skaffold:

  • Feu un seguiment dels canvis al codi font.
  • Sincronitzeu-lo amb el contenidor de la beina si no requereix muntatge.
  • Recolliu contenidors amb codi, si s'interpreta el llenguatge, o compileu artefactes i empaqueteu-los en contenidors.
  • Les imatges resultants es comproven automàticament amb prova-estructura-contenidor.
  • Etiquetar i pujar imatges al registre Docker.
  • Desplegueu una aplicació en un clúster mitjançant kubectl, Helm o kustomize.
  • Realitzeu el reenviament de ports.
  • Depura aplicacions escrites en Java, Node.js, Python.

El flux de treball en diverses variacions es descriu declarativament al fitxer skaffold.yaml. Per a un projecte, també podeu definir diversos perfils en els quals podeu canviar parcialment o completament les etapes de muntatge i desplegament. Per exemple, per al desenvolupament, especifiqueu una imatge base convenient per al desenvolupador i per a la posada en escena i la producció, una mínima (+ ús securityContext contenidors o redefinir el clúster en el qual es desplegarà l'aplicació).

Els contenidors Docker es poden construir de manera local o remota: a Google Cloud Build o en un clúster utilitzant Kaniko. Bazel i Jib Maven/Gradle també són compatibles. Per a l'etiquetatge, Skaffold admet moltes estratègies: per git commit hash, data/hora, sha256-sum de fonts, etc.

Per separat, val la pena destacar la possibilitat de provar contenidors. El marc de prova d'estructura de contenidors ja esmentat ofereix els següents mètodes de verificació:

  • Execució d'ordres en el context d'un contenidor amb un seguiment dels estats de sortida i comprovació de la sortida de text de l'ordre.
  • Comprovació de la presència de fitxers al contenidor i coincidència amb els atributs especificats.
  • Control del contingut dels fitxers mitjançant expressions regulars.
  • Verificació de metadades de la imatge (ENV, ENTRYPOINT, VOLUMES etc.).
  • Comprovació de la compatibilitat de la llicència.

La sincronització dels fitxers amb el contenidor no es realitza de la manera més òptima: Skaffold simplement crea un arxiu amb les fonts, el copia i el desempaqueta al contenidor (cal instal·lar tar). Per tant, si la vostra tasca principal és la sincronització de codi, és millor mirar cap a una solució especialitzada (ksync).

Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes
Etapes principals del funcionament del Skaffold

En general, l'eina no permet abstraure's dels manifests de Kubernetes i no té cap interactivitat, per la qual cosa pot semblar difícil de dominar. Però aquest també és el seu avantatge: una major llibertat d'acció.

Garden

  • Lloc; GitHub.
  • Breus estadístiques de GH: 1063 estrelles, 1927 commits, 17 col·laboradors.
  • Llenguatge: TypeScript (es preveu dividir el projecte en diversos components, alguns dels quals estaran a Go, i també fer un SDK per crear complements a TypeScript/JavaScript i Go).
  • Llicència: Apache License 2.0.

Igual que Skaffold, Garden pretén automatitzar els processos de lliurament de codi d'aplicació al clúster K8s. Per fer-ho, primer heu de descriure l'estructura del projecte en un fitxer YAML i, a continuació, executar l'ordre garden dev. Ella farà tota la màgia:

  • Recollir contenidors amb diferents parts del projecte.
  • Realitza proves d'integració i unitats, si s'han descrit.
  • Desplega tots els components del projecte al clúster.
  • Si el codi font canvia, es reiniciarà tot el pipeline.

L'objectiu principal d'utilitzar aquesta eina és compartir un clúster remot amb un equip de desenvolupament. En aquest cas, si ja s'han fet alguns dels passos de construcció i prova, això accelerarà significativament tot el procés, ja que Garden podrà utilitzar els resultats de la memòria cau.

Un mòdul de projecte pot ser un contenidor, un contenidor Maven, un gràfic Helm, un manifest per kubectl apply o fins i tot una funció OpenFaaS. A més, qualsevol dels mòduls es pot extreure d'un dipòsit Git remot. Un mòdul pot definir o no serveis, tasques i proves. Els serveis i les tasques poden tenir dependències, de manera que podeu determinar la seqüència de desplegament d'un servei concret i organitzar el llançament de tasques i proves.

Garden ofereix a l'usuari un bonic tauler de control (actualment a estat experimental), que mostra el gràfic del projecte: components, seqüència de muntatge, execució de tasques i proves, les seves connexions i dependències. Al navegador, podeu veure els registres de tots els components del projecte i comprovar què produeix un component concret mitjançant HTTP (si, per descomptat, s'hi declara un recurs d'entrada).

Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes
Panell per al jardí

Aquesta eina també té un mode de recàrrega en calent, que simplement sincronitza els canvis d'script amb el contenidor del clúster, accelerant molt el procés de depuració de l'aplicació. El jardí en té un de bo documentació i no està malament conjunt d'exemples, que us permet acostumar-vos-hi ràpidament i començar a utilitzar-lo. Per cert, fa poc que hem publicat traducció de l'article dels seus autors.

Conclusió

Per descomptat, aquesta llista d'eines per desenvolupar i depurar aplicacions a Kubernetes no es limita a. Hi ha moltes més utilitats molt útils i pràctiques que mereixen, si no un article a part, almenys una menció. Explica'ns què fas servir, quins problemes has trobat i com els has resolt!

PS

Llegeix també al nostre blog:

Font: www.habr.com

Afegeix comentari