As aplicacións "nativas da nube" ou simplemente "na nube" créanse especificamente para traballar en infraestruturas na nube. Normalmente constrúense como un conxunto de microservizos pouco acoplados empaquetados en contedores, que á súa vez son xestionados por unha plataforma na nube. Tales aplicacións están preparadas para fallas de forma predeterminada, o que significa que funcionan de forma fiable e escalan incluso en caso de fallas graves a nivel de infraestrutura. A outra cara da moeda son os conxuntos de restricións (contratos) que a plataforma na nube impón ás aplicacións de contedores para poder xestionalas automaticamente.
Aínda que son plenamente conscientes da necesidade e importancia de pasar a aplicacións baseadas na nube, moitas organizacións aínda non saben por onde comezar. Neste post, analizaremos unha serie de principios que, se se seguen ao desenvolver aplicacións en contenedores, permitirán que se dea conta do potencial das plataformas na nube e lograr un funcionamento e escalado fiables das aplicacións mesmo en caso de fallos graves na infraestrutura de TI. nivel. O obxectivo final dos principios aquí descritos é aprender a crear aplicacións que poidan ser xestionadas automaticamente por plataformas na nube como Kubernetes.
Principios de deseño de software
No mundo da programación, os principios refírense a regras bastante xerais que se deben seguir ao desenvolver software. Pódense usar cando se traballa con calquera linguaxe de programación. Cada principio ten os seus propios obxectivos, as ferramentas para conseguilos que adoitan ser modelos e prácticas. Tamén hai unha serie de principios fundamentais para crear software de alta calidade, dos que todos os demais flúen. Aquí tes algúns exemplos de principios fundamentais:
- (Keep it simple, stupid) - non o compliques;
- (Non te repitas) - non te repitas;
- (Non o necesitarás) - non crees algo que non sexa necesario inmediatamente;
- Separación de preocupacións: compartir responsabilidades.
Como podes ver, estes principios non establecen ningunha norma específica, senón que pertencen á categoría das denominadas consideracións de sentido común baseadas na experiencia práctica, que son compartidas por moitos desenvolvedores e ás que se refiren regularmente.
Ademais, hai – Un conxunto dos cinco primeiros principios de programación e deseño orientados a obxectos, formulados por Robert Martin. SOLID inclúe principios complementarios amplos e abertos que, cando se aplican en conxunto, axudan a crear mellores sistemas de software e mantelos mellor a longo prazo.
Os principios SOLID pertencen ao campo da POO e están formulados na linguaxe de conceptos e conceptos como clases, interfaces e herdanza. Por analoxía, os principios de desenvolvemento tamén se poden formular para aplicacións na nube, só o elemento básico aquí non será unha clase, senón un contedor. Seguindo estes principios, podes crear aplicacións en contedores que cumpran mellor os obxectivos e os obxectivos de plataformas na nube como Kubernetes.
Contenedores nativos da nube: o enfoque de Red Hat
Hoxe, case calquera aplicación pódese empaquetar con relativa facilidade en contedores. Pero para que as aplicacións sexan automatizadas e orquestradas de forma efectiva nunha plataforma en nube como Kubernetes, é necesario un esforzo adicional.
A base das ideas expostas a continuación foi a metodoloxía e moitos outros traballos sobre diversos aspectos da construción de aplicacións web, desde a xestión do código fonte ata modelos de escalado. Os principios descritos só aplícanse ao desenvolvemento de aplicacións en contedores que están construídas sobre microservizos e deseñadas para plataformas na nube como Kubernetes. O elemento básico da nosa discusión é a imaxe do contedor e o tempo de execución do contedor de destino é a plataforma de orquestración de contedores. O obxectivo dos principios propostos é crear contedores para os que se poidan automatizar tarefas de programación, escalado e seguimento na maioría das plataformas de orquestración. Os principios preséntanse sen orde en particular.
Principio de preocupación única (SCP)
Este principio é en moitos aspectos semellante ao Principio de Responsabilidade Única. ), que forma parte do conxunto SOLID e indica que cada obxecto debe ter unha responsabilidade, e esa responsabilidade debe estar completamente encapsulada nunha clase. O punto de SRP é que toda responsabilidade é un motivo para o cambio, e unha clase debe ter un e só un motivo para o cambio.
En SCP, usamos a palabra "preocupación" en lugar da palabra "responsabilidade" para indicar o maior nivel de abstracción e o propósito máis amplo dun contedor en comparación cunha clase OOP. E se o obxectivo de SRP é ter só un motivo para o cambio, entón detrás de SCP está o desexo de ampliar a capacidade de reutilizar e substituír os envases. Ao seguir o SRP e crear un contedor que resolve un único problema e o fai dunha forma funcionalmente completa, aumenta as posibilidades de reutilizar esa imaxe do contenedor en diferentes contextos de aplicación.
O principio SCP establece que cada recipiente debe resolver un único problema e facelo ben. Ademais, o SCP no mundo dos contedores é máis fácil de conseguir que o SRP no mundo OOP, xa que os contedores adoitan executar un só proceso, e a maioría das veces este proceso resolve unha única tarefa.
Se algún microservizo de contedores debe resolver varios problemas ao mesmo tempo, pódese dividir en contedores dunha soa tarefa e combinarse nun pod (unha unidade de implantación da plataforma de contedores) mediante modelos sidecar e de contedores de inicio. Ademais, SCP facilita a substitución dun contedor antigo (como un servidor web ou un intermediario de mensaxes) por un novo que resolve o mesmo problema pero que amplía a funcionalidade ou escala mellor.
Principio de alta observabilidade (HOP)
Cando os contedores se utilizan como unha forma unificada de empaquetar e executar aplicacións, as propias aplicacións trátanse como unha caixa negra. Non obstante, se se trata de contedores na nube, deben proporcionar API especiais ao tempo de execución para supervisar o estado dos contedores e, se é necesario, tomar as medidas oportunas. Sen isto, non será posible unificar a automatización da actualización dos contedores e a xestión do seu ciclo de vida, o que, á súa vez, empeorará a estabilidade e usabilidade do sistema software.
Na práctica, unha aplicación en contedores debería ter, como mínimo, unha API para varios tipos de controis de saúde: probas de vida e probas de preparación. Se unha aplicación afirma facer máis, debe proporcionar outros medios para controlar o seu estado. Por exemplo, rexistrar eventos importantes a través de STDERR e STDOUT para a agregación de rexistros mediante Fluentd, Logstash e outras ferramentas similares. Así como a integración con bibliotecas de trazado e colección de métricas, como OpenTracing, Prometheus, etc.
En xeral, a aplicación aínda pode ser tratada como unha caixa negra, pero debe estar provista de todas as API que precisa a plataforma para supervisala e xestionala da mellor maneira posible.
Principio de conformidade do ciclo de vida (LCP)
LCP é a antítese de HOP. Aínda que HOP indica que o contedor debe expoñer as API de lectura á plataforma, LCP require que a aplicación poida aceptar información da plataforma. Ademais, o contedor non só debe recibir eventos, senón tamén adaptarse, é dicir, reaccionar a eles. De aí o nome do principio, que se pode considerar como un requisito para proporcionar á plataforma API de escritura.
As plataformas teñen diferentes tipos de eventos para axudar a xestionar o ciclo de vida dun contedor. Pero correspóndelle á propia aplicación decidir cal deles percibir e como reaccionar.
Está claro que uns acontecementos son máis importantes que outros. Por exemplo, se unha aplicación non tolera ben os fallos, debe aceptar mensaxes sinal: terminar (SIGTERM) e iniciar a súa rutina de terminación o máis rápido posible para captar o sinal: matar (SIGKILL) que vén despois de SIGTERM.
Ademais, eventos como PostStart e PreStop poden ser importantes para o ciclo de vida dunha aplicación. Por exemplo, despois de iniciar unha aplicación, pode requirir un tempo de quecemento antes de que poida responder ás solicitudes. Ou a aplicación debe liberar recursos dalgún xeito especial cando se apaga.
Principio de inmutabilidade da imaxe (IIP)
En xeral, acéptase que as aplicacións en contenedores deben permanecer sen cambios despois de ser construídas, aínda que se executen en ambientes diferentes. Isto require a necesidade de externalizar o almacenamento de datos en tempo de execución (noutras palabras, de usar ferramentas externas para iso) e de depender de configuracións externas específicas do tempo de execución, en lugar de modificar ou crear contedores únicos para cada ambiente. Despois de calquera cambio na aplicación, a imaxe do contedor debe ser reconstruída e despregada en todos os ambientes utilizados. Por certo, á hora de xestionar sistemas informáticos utilízase un principio similar, coñecido como principio de inmutabilidade dos servidores e da infraestrutura.
O obxectivo do IIP é evitar a creación de imaxes de contedores separadas para diferentes ambientes de execución e utilizar a mesma imaxe en todas partes xunto coa configuración específica do contorno axeitada. Seguir este principio permítelle implementar prácticas tan importantes desde o punto de vista da automatización dos sistemas de nube, como a recuperación e o avance das actualizacións de aplicacións.
Principio de eliminación do proceso (PDP)
Unha das características máis importantes dun contedor é a súa efémeridade: unha instancia dun recipiente é fácil de crear e de destruír, polo que se pode substituír facilmente por outra en calquera momento. Pode haber moitas razóns para tal substitución: falla dunha proba de servizo, escalado da aplicación, transferencia a outro host, esgotamento dos recursos da plataforma ou outras situacións.
Como consecuencia, as aplicacións contenedoras deben manter o seu estado mediante algúns medios externos, ou utilizar esquemas distribuídos internos con redundancia para iso. Ademais, a aplicación debe iniciarse e apagarse rapidamente e estar preparado para un fallo súbito de hardware.
Unha práctica que axuda a implementar este principio é manter os recipientes pequenos. Os ambientes na nube poden seleccionar automaticamente un host no que lanzar unha instancia de contenedor, polo que canto máis pequeno sexa o contenedor, máis rápido comezará; simplemente copiarase no host de destino a través da rede máis rápido.
Principio de autocontención (S-CP)
Segundo este principio, na fase de montaxe, todos os compoñentes necesarios están incluídos no recipiente. O contedor debe construírse asumindo que o sistema só ten un núcleo Linux puro, polo que todas as bibliotecas adicionais necesarias deberían colocarse no propio contenedor. Tamén debería conter cousas como o tempo de execución para a linguaxe de programación correspondente, a plataforma da aplicación (se é necesario) e outras dependencias que serán necesarias mentres se executa a aplicación do contedor.
Faise excepcións para configuracións que varían dun ambiente a outro e que deben proporcionarse en tempo de execución, por exemplo a través dun ConfigMap de Kubernetes.
Unha aplicación pode incluír varios compoñentes en contedores, por exemplo, un contedor de DBMS separado dentro dunha aplicación web en contenedores. Segundo o principio S-CP, estes contedores non deben combinarse nun só, senón que deben facerse para que o contedor DBMS conteña todo o necesario para o funcionamento da base de datos e o contedor da aplicación web conteña todo o necesario para o funcionamento da web. aplicación, o mesmo servidor web. Como resultado, no tempo de execución o contedor da aplicación web dependerá do contenedor DBMS e accederá a el segundo sexa necesario.
Principio de confinamento en tempo de execución (RCP)
O principio S-CP define como se debe construír o contedor e o que debe conter o binario da imaxe. Pero un contedor non é só unha "caixa negra" que só ten unha característica: o tamaño do ficheiro. Durante a execución, o contedor adquire outras dimensións: a cantidade de memoria utilizada, o tempo de CPU e outros recursos do sistema.
E aquí resulta útil o principio RCP, segundo o cal o contedor debe decapitar os seus requisitos de recursos do sistema e transferilos á plataforma. Cos perfís de recursos de cada contedor (cantos recursos de CPU, memoria, rede e disco que necesita), a plataforma pode realizar de forma óptima a programación e a escala automática, xestionar a capacidade de TI e manter os niveis de SLA dos contedores.
Ademais de cumprir os requisitos de recursos do contedor, tamén é importante que a aplicación non vaia máis aló dos seus propios límites. En caso contrario, cando se produce unha escaseza de recursos, é máis probable que a plataforma o inclúa na lista de aplicacións que deben ser finalizadas ou migradas.
Cando falamos de estar en primeiro lugar na nube, falamos da forma en que traballamos.
Arriba, formulamos unha serie de principios xerais que establecen as bases metodolóxicas para crear aplicacións de contedores de alta calidade para ambientes de nube.
Teña en conta que, ademais destes principios xerais, tamén necesitará métodos e técnicas avanzadas adicionais para traballar con contedores. Ademais, temos algunhas recomendacións breves que son máis específicas e que se deben aplicar (ou non aplicar) segundo a situación:
- Intente reducir o tamaño das imaxes: elimine os ficheiros temporais e non instale paquetes innecesarios: canto menor sexa o tamaño do contenedor, máis rápido se ensambla e cópiase no host de destino a través da rede.
- Concéntrase en ID de usuario arbitrarios: non use o comando sudo nin ningún ID de usuario especial para lanzar os seus contedores.
- Marcar os portos importantes: podes definir os números de porto no tempo de execución, pero é mellor especificalos mediante o comando EXPOSE: facilitará que outras persoas e programas utilicen as túas imaxes.
- Almacenar datos persistentes en volumes: os datos que deberían permanecer despois da destrución do contedor deben escribirse nos volumes.
- Escribe metadatos de imaxes: as etiquetas, as etiquetas e as anotacións fan que as imaxes sexan máis fáciles de usar; outros desenvolvedores agradecerano.
- Sincronizar host e imaxes: algunhas aplicacións en contedores requiren que o contenedor se sincronice co host en determinados atributos, como a hora ou o ID da máquina.
- En conclusión, compartimos modelos e prácticas recomendadas que che axudarán a implementar de forma máis eficaz os principios enumerados anteriormente:
11 de xuño ás 11.00 h
Que vai aprender:
- Red Hat Enterprise Linux CoreOS inmutable
- Malla de servizo OpenShift
- Marco do operador
- Marco knative
Fonte: www.habr.com