Les aplicacions "natives del núvol" o simplement "núvols" es creen específicament per treballar en infraestructures de núvol. Normalment es construeixen com un conjunt de microserveis poc acoblats empaquetats en contenidors, que al seu torn són gestionats per una plataforma al núvol. Aquestes aplicacions estan preparades per a fallades de manera predeterminada, el que significa que funcionen de manera fiable i escalan fins i tot en cas de fallades greus a nivell d'infraestructura. L'altra cara de la moneda són els conjunts de restriccions (contractes) que la plataforma en núvol imposa a les aplicacions de contenidors per poder gestionar-les automàticament.
Tot i que són plenament conscients de la necessitat i la importància de passar a aplicacions basades en núvol, moltes organitzacions encara no saben per on començar. En aquesta publicació, analitzarem una sèrie de principis que, si es segueixen a l'hora de desenvolupar aplicacions en contenidors, us permetran adonar-vos del potencial de les plataformes en núvol i aconseguir un funcionament i escalat fiables de les aplicacions fins i tot en cas de fallades greus a la infraestructura informàtica. nivell. L'objectiu final dels principis descrits aquí és aprendre a crear aplicacions que puguin ser gestionades automàticament per plataformes en núvol com ara Kubernetes.
Principis de disseny de programari
En el món de la programació, els principis fan referència a regles força generals que s'han de seguir a l'hora de desenvolupar programari. Es poden utilitzar quan es treballa amb qualsevol llenguatge de programació. Cada principi té els seus propis objectius, les eines per aconseguir-ho que solen ser plantilles i pràctiques. També hi ha una sèrie de principis fonamentals per crear programari d'alta qualitat, dels quals surten tots els altres. Aquests són alguns exemples de principis fonamentals:
- (Mantenir-ho senzill, estúpid) - no ho compliquis;
- (No et repeteixis) - no et repeteixis;
- (No ho necessitareu) - no creeu quelcom que no sigui necessari immediatament;
- Separació de preocupacions: compartir responsabilitats.
Com podeu veure, aquests principis no estableixen cap regla específica, sinó que pertanyen a la categoria de les anomenades consideracions de sentit comú basades en l'experiència pràctica, que són compartides per molts desenvolupadors i a les quals es refereixen regularment.
A més, n’hi ha – Un conjunt dels cinc primers principis de programació i disseny orientats a objectes, formulats per Robert Martin. SOLID inclou principis amplis, oberts i complementaris que, quan s'apliquen conjuntament, ajuden a crear millors sistemes de programari i mantenir-los millor a llarg termini.
Els principis SOLID pertanyen al camp de la POO i es formulen en el llenguatge de conceptes i conceptes com les classes, les interfícies i l'herència. Per analogia, els principis de desenvolupament també es poden formular per a aplicacions al núvol, només que l'element bàsic aquí no serà una classe, sinó un contenidor. Seguint aquests principis, podeu crear aplicacions en contenidors que compleixin millor els objectius i els objectius de plataformes en núvol com Kubernetes.
Contenidors nadius del núvol: l'enfocament de Red Hat
Avui dia, gairebé qualsevol aplicació es pot empaquetar amb relativa facilitat en contenidors. Però perquè les aplicacions es puguin automatitzar i orquestrar de manera eficaç dins d'una plataforma en núvol com Kubernetes, cal un esforç addicional.
La base de les idees que es descriuen a continuació va ser la metodologia i molts altres treballs sobre diversos aspectes de la creació d'aplicacions web, des de la gestió del codi font fins als models d'escala. Els principis descrits només s'apliquen al desenvolupament d'aplicacions en contenidors que es creen sobre microserveis i dissenyades per a plataformes en núvol com ara Kubernetes. L'element bàsic de la nostra discussió és la imatge del contenidor, i el temps d'execució del contenidor objectiu és la plataforma d'orquestració de contenidors. L'objectiu dels principis proposats és crear contenidors per als quals les tasques de programació, escalat i supervisió es puguin automatitzar a la majoria de plataformes d'orquestració. Els principis es presenten sense cap ordre particular.
Principi de preocupació única (SCP)
Aquest principi és, en molts aspectes, similar al principi de responsabilitat única. ), que forma part del conjunt SOLID i estableix que cada objecte ha de tenir una responsabilitat, i aquesta responsabilitat ha d'estar completament encapsulada en una classe. El punt de l'SRP és que tota responsabilitat és una raó de canvi, i una classe ha de tenir una i només una raó de canvi.
A SCP, fem servir la paraula "preocupació" en lloc de la paraula "responsabilitat" per indicar el nivell més alt d'abstracció i el propòsit més ampli d'un contenidor en comparació amb una classe OOP. I si l'objectiu de SRP és tenir només una raó per al canvi, aleshores darrere de SCP hi ha el desig d'ampliar la capacitat de reutilitzar i substituir els contenidors. Seguint l'SRP i creant un contenidor que soluciona un únic problema i ho fa d'una manera funcionalment completa, augmenteu les possibilitats de reutilitzar la imatge del contenidor en diferents contextos d'aplicació.
El principi SCP estableix que cada contenidor hauria de resoldre un sol problema i fer-ho bé. A més, l'SCP al món dels contenidors és més fàcil d'aconseguir que l'SRP al món OOP, ja que els contenidors solen executar un sol procés i, la majoria de les vegades, aquest procés resol una única tasca.
Si un microservei de contenidors ha de resoldre diversos problemes alhora, es pot dividir en contenidors d'una sola tasca i combinar-se dins d'un pod (una unitat de desplegament de plataforma de contenidors) mitjançant plantilles de contenidors sidecar i d'inici. A més, SCP facilita la substitució d'un contenidor antic (com ara un servidor web o un agent de missatges) per un de nou que solucioni el mateix problema però que ha ampliat la funcionalitat o s'escala millor.
Principi d'alta observabilitat (HOP)
Quan els contenidors s'utilitzen com a forma unificada d'empaquetar i executar aplicacions, les aplicacions en si es tracten com una caixa negra. Tanmateix, si es tracta de contenidors al núvol, hauran de proporcionar API especials al temps d'execució per supervisar l'estat dels contenidors i, si cal, prendre les mesures oportunes. Sense això, no serà possible unificar l'automatització de l'actualització dels contenidors i la gestió del seu cicle de vida, fet que, al seu torn, empitjorarà l'estabilitat i usabilitat del sistema de programari.
A la pràctica, una aplicació en contenidors hauria de tenir, com a mínim, una API per a diversos tipus de controls de salut: proves de vida i proves de preparació. Si una aplicació afirma fer més, ha de proporcionar altres mitjans per controlar el seu estat. Per exemple, registrar esdeveniments importants mitjançant STDERR i STDOUT per a l'agregació de registres mitjançant Fluentd, Logstash i altres eines similars. Així com la integració amb biblioteques de traça i col·lecció de mètriques, com ara OpenTracing, Prometheus, etc.
En general, l'aplicació encara es pot tractar com una caixa negra, però s'ha de dotar de totes les API que necessita la plataforma per poder supervisar-la i gestionar-la de la millor manera possible.
Principi de conformitat del cicle de vida (LCP)
LCP és l'antítesi de HOP. Tot i que HOP afirma que el contenidor ha d'exposar les API de lectura a la plataforma, LCP requereix que l'aplicació pugui acceptar informació de la plataforma. A més, el contenidor no només ha de rebre esdeveniments, sinó també adaptar-se, és a dir, reaccionar-hi. D'aquí el nom del principi, que es pot considerar com un requisit per proporcionar a la plataforma API d'escriptura.
Les plataformes tenen diferents tipus d'esdeveniments per ajudar a gestionar el cicle de vida d'un contenidor. Però depèn de la mateixa aplicació decidir quin d'ells percebre i com reaccionar.
És evident que alguns esdeveniments són més importants que altres. Per exemple, si una aplicació no tolera bé els bloquejos, ha d'acceptar missatges de senyal: terminar (SIGTERM) i iniciar la seva rutina de terminació tan aviat com sigui possible per captar el senyal: matar (SIGKILL) que ve després de SIGTERM.
A més, esdeveniments com PostStart i PreStop poden ser importants per al cicle de vida d'una aplicació. Per exemple, després d'iniciar una aplicació, pot requerir un temps d'escalfament abans que pugui respondre a les sol·licituds. O l'aplicació ha d'alliberar recursos d'alguna manera especial quan s'apaga.
El principi d'immutabilitat de la imatge (IIP)
En general, s'accepta que les aplicacions en contenidors han de romandre sense canvis després de ser construïdes, fins i tot si s'executen en entorns diferents. Això requereix la necessitat d'externalitzar l'emmagatzematge de dades en temps d'execució (és a dir, utilitzar eines externes per a això) i confiar en configuracions externes específiques del temps d'execució, en lloc de modificar o crear contenidors únics per a cada entorn. Després de qualsevol canvi a l'aplicació, la imatge del contenidor s'ha de reconstruir i desplegar a tots els entorns utilitzats. Per cert, a l'hora de gestionar sistemes informàtics, s'utilitza un principi similar, conegut com a principi d'immutabilitat dels servidors i la infraestructura.
L'objectiu de l'IIP és evitar la creació d'imatges de contenidors separades per a diferents entorns d'execució i utilitzar la mateixa imatge a tot arreu juntament amb la configuració específica de l'entorn adequada. Seguir aquest principi us permet implementar pràctiques tan importants des del punt de vista de l'automatització dels sistemes al núvol com ara el rollback i roll-forward de les actualitzacions d'aplicacions.
Principi d'eliminació del procés (PDP)
Una de les característiques més importants d'un contenidor és la seva efímera: una instància d'un contenidor és fàcil de crear i fàcil de destruir, de manera que es pot substituir fàcilment per una altra en qualsevol moment. Hi pot haver moltes raons per a aquesta substitució: fallada d'una prova de servei, escala de l'aplicació, transferència a un altre amfitrió, esgotament dels recursos de la plataforma o altres situacions.
Com a conseqüència, les aplicacions en contenidors han de mantenir el seu estat mitjançant alguns mitjans externs, o utilitzar esquemes distribuïts interns amb redundància per a això. A més, l'aplicació s'ha d'iniciar i tancar ràpidament i estar preparat per a una fallada sobtada i fatal del maquinari.
Una pràctica que ajuda a implementar aquest principi és mantenir els contenidors petits. Els entorns al núvol poden seleccionar automàticament un amfitrió per llançar una instància de contenidor, de manera que com més petit sigui el contenidor, més ràpid s'iniciarà; simplement es copiarà a l'amfitrió objectiu a través de la xarxa més ràpidament.
Principi d'autocontenció (S-CP)
Segons aquest principi, en l'etapa de muntatge, tots els components necessaris s'inclouen al contenidor. El contenidor s'ha de construir en el supòsit que el sistema només té un nucli Linux pur, de manera que totes les biblioteques addicionals necessàries s'han de col·locar al propi contenidor. També hauria de contenir coses com el temps d'execució del llenguatge de programació corresponent, la plataforma de l'aplicació (si cal) i altres dependències que seran necessàries mentre s'executa l'aplicació contenidor.
Es fan excepcions per a configuracions que varien d'un entorn a un altre i s'han de proporcionar en temps d'execució, per exemple mitjançant un mapa de configuració de Kubernetes.
Una aplicació pot incloure diversos components en contenidors, per exemple, un contenidor DBMS independent dins d'una aplicació web en contenidors. Segons el principi S-CP, aquests contenidors no s'han de combinar en un, sinó que s'han de fer de manera que el contenidor DBMS contingui tot el necessari per al funcionament de la base de dades i el contenidor de l'aplicació web contingui tot el necessari per al funcionament de la web. aplicació, el mateix servidor web. Com a resultat, en temps d'execució, el contenidor de l'aplicació web dependrà del contenidor DBMS i hi accedirà segons sigui necessari.
Principi de confinament en temps d'execució (RCP)
El principi S-CP defineix com s'ha de construir el contenidor i què ha de contenir la imatge binària. Però un contenidor no és només una "caixa negra" que només té una característica: la mida del fitxer. Durant l'execució, el contenidor assumeix altres dimensions: la quantitat de memòria utilitzada, el temps de CPU i altres recursos del sistema.
I aquí és útil el principi RCP, segons el qual el contenidor ha de decapitar els seus requisits de recursos del sistema i transferir-los a la plataforma. Amb els perfils de recursos de cada contenidor (quants recursos de CPU, memòria, xarxa i disc que necessita), la plataforma pot realitzar de manera òptima la programació i l'escala automàtica, gestionar la capacitat de TI i mantenir els nivells de SLA dels contenidors.
A més de complir els requisits de recursos del contenidor, també és important que l'aplicació no vagi més enllà dels seus propis límits. En cas contrari, quan es produeix una escassetat de recursos, és més probable que la plataforma l'inclogui a la llista d'aplicacions que s'han de finalitzar o migrar.
Quan parlem de ser el primer al núvol, estem parlant de la nostra manera de treballar.
Més amunt, vam formular una sèrie de principis generals que estableixen les bases metodològiques per crear aplicacions de contenidors d'alta qualitat per a entorns en núvol.
Tingueu en compte que, a més d'aquests principis generals, també necessitareu mètodes i tècniques avançades addicionals per treballar amb contenidors. A més, tenim unes quantes recomanacions breus que són més específiques i que s'han d'aplicar (o no aplicar) segons la situació:
- Intenteu reduir la mida de les imatges: suprimiu els fitxers temporals i no instal·leu paquets innecessaris: com més petit sigui la mida del contenidor, més ràpid s'assembla i es copia a l'amfitrió de destinació a través de la xarxa.
- Centreu-vos en els ID d'usuari arbitraris: no feu servir l'ordre sudo ni cap identificador d'usuari especial per llançar els vostres contenidors.
- Marqueu els ports importants: podeu establir els números de port en temps d'execució, però és millor especificar-los mitjançant l'ordre EXPOSE, ja que facilitarà que altres persones i programes utilitzin les vostres imatges.
- Emmagatzemar dades persistents als volums: les dades que haurien de romandre després de destruir el contenidor s'han d'escriure als volums.
- Escriu metadades d'imatge: etiquetes, etiquetes i anotacions fan que les imatges siguin més fàcils d'utilitzar; altres desenvolupadors t'ho agrairan.
- Sincronitza l'amfitrió i les imatges: algunes aplicacions en contenidors requereixen que el contenidor se sincronitzi amb l'amfitrió en determinats atributs, com ara l'hora o l'identificador de màquina.
- En conclusió, compartim plantilles i bones pràctiques que us ajudaran a implementar de manera més eficaç els principis enumerats anteriorment:
11 de juny a les 11.00 h
Què aprendràs:
- Red Hat Enterprise Linux CoreOS immutable
- Malla de servei OpenShift
- Marc de l'operador
- Marc knatif
Font: www.habr.com