Las aplicaciones “nativas de la nube” o simplemente “en la nube” se crean específicamente para funcionar en infraestructuras en la nube. Por lo general, se crean como un conjunto de microservicios débilmente acoplados empaquetados en contenedores, que a su vez son administrados por una plataforma en la nube. Estas aplicaciones están preparadas para fallas de forma predeterminada, lo que significa que funcionan de manera confiable y escalan incluso en caso de fallas graves a nivel de infraestructura. La otra cara de la moneda son los conjuntos de restricciones (contratos) que la plataforma en la nube impone a las aplicaciones contenedoras para poder gestionarlas de forma automática.
Si bien son plenamente conscientes de la necesidad y la importancia de pasar a aplicaciones basadas en la nube, muchas organizaciones todavía no saben por dónde empezar. En esta publicación, veremos una serie de principios que, si se siguen al desarrollar aplicaciones en contenedores, le permitirán aprovechar el potencial de las plataformas en la nube y lograr un funcionamiento y escalamiento confiables de las aplicaciones incluso en caso de fallas graves en la infraestructura de TI. nivel. El objetivo final de los principios descritos aquí es aprender a crear aplicaciones que puedan administrarse automáticamente mediante plataformas en la nube como Kubernetes.
Principios de diseño de software
En el mundo de la programación, los principios se refieren a reglas bastante generales que se deben seguir al desarrollar software. Se pueden utilizar cuando se trabaja con cualquier lenguaje de programación. Cada principio tiene sus propios objetivos, cuyas herramientas para lograrlos suelen ser plantillas y prácticas. También hay una serie de principios fundamentales para la creación de software de alta calidad, de los que se derivan todos los demás. A continuación se muestran algunos ejemplos de principios fundamentales:
- (Mantenlo simple, estúpido) – no lo compliques;
- (No te repitas) - no te repitas;
- (No lo necesitarás) - no crees algo que no sea necesario de inmediato;
- Separación de preocupaciones: compartir responsabilidades.
Como puede ver, estos principios no establecen reglas específicas, sino que pertenecen a la categoría de las llamadas consideraciones de sentido común basadas en la experiencia práctica, que son compartidas por muchos desarrolladores y a las que se refieren regularmente.
Además, hay – Un conjunto de los cinco primeros principios de la programación y el diseño orientado a objetos, formulados por Robert Martin. SOLID incluye principios amplios, abiertos y complementarios que, cuando se aplican en conjunto, ayudan a crear mejores sistemas de software y a mantenerlos mejor a largo plazo.
Los principios SOLID pertenecen al campo de la programación orientada a objetos y están formulados en el lenguaje de conceptos y conceptos como clases, interfaces y herencia. Por analogía, los principios de desarrollo también se pueden formular para aplicaciones en la nube, sólo que el elemento básico aquí no será una clase, sino un contenedor. Si sigue estos principios, puede crear aplicaciones en contenedores que cumplan mejor las metas y objetivos de las plataformas en la nube como Kubernetes.
Contenedores nativos de la nube: el enfoque de Red Hat
Hoy en día, casi cualquier aplicación se puede empaquetar con relativa facilidad en contenedores. Pero para que las aplicaciones se automaticen y orquesten eficazmente dentro de una plataforma en la nube como Kubernetes, se requiere un esfuerzo adicional.
La base de las ideas que se describen a continuación fue la metodología y muchos otros trabajos sobre diversos aspectos de la creación de aplicaciones web, desde la gestión del código fuente hasta los modelos de escala. Los principios descritos se aplican únicamente al desarrollo de aplicaciones en contenedores construidas sobre microservicios y diseñadas para plataformas en la nube como Kubernetes. El elemento básico en nuestra discusión es la imagen del contenedor, y el tiempo de ejecución del contenedor de destino es la plataforma de orquestación del contenedor. El objetivo de los principios propuestos es crear contenedores para los cuales las tareas de programación, escalado y monitoreo puedan automatizarse en la mayoría de las plataformas de orquestación. Los principios se presentan sin ningún orden particular.
Principio de preocupación única (SCP)
Este principio es similar en muchos aspectos al principio de responsabilidad única. ), que es parte del conjunto SOLID y establece que cada objeto debe tener una responsabilidad, y esa responsabilidad debe estar completamente encapsulada en una clase. El objetivo de SRP es que cada responsabilidad es una razón para el cambio, y una clase debe tener una y sólo una razón para el cambio.
En SCP, utilizamos la palabra "preocupación" en lugar de la palabra "responsabilidad" para indicar el mayor nivel de abstracción y el propósito más amplio de un contenedor en comparación con una clase de programación orientada a objetos. Y si el objetivo del SRP es tener una sola razón para el cambio, entonces detrás del SCP está el deseo de ampliar la capacidad de reutilizar y reemplazar contenedores. Si sigue el SRP y crea un contenedor que resuelve un único problema y lo hace de manera funcionalmente completa, aumenta las posibilidades de reutilizar esa imagen de contenedor en diferentes contextos de aplicación.
El principio SCP establece que cada contenedor debe resolver un único problema y hacerlo bien. Además, SCP en el mundo de los contenedores es más fácil de lograr que SRP en el mundo de la programación orientada a objetos, ya que los contenedores generalmente ejecutan un solo proceso y la mayoría de las veces este proceso resuelve una sola tarea.
Si un microservicio de contenedor debe resolver varios problemas a la vez, entonces se puede dividir en contenedores de una sola tarea y combinarlos dentro de un pod (una unidad de implementación de plataforma de contenedores) utilizando plantillas de contenedor sidecar e init. Además, SCP facilita la sustitución de un contenedor antiguo (como un servidor web o un intermediario de mensajes) por uno nuevo que resuelve el mismo problema pero tiene una funcionalidad ampliada o se escala mejor.
Principio de alta observabilidad (HOP)
Cuando los contenedores se utilizan como una forma unificada de empaquetar y ejecutar aplicaciones, las aplicaciones mismas se tratan como una caja negra. Sin embargo, si se trata de contenedores en la nube, deben proporcionar API especiales al tiempo de ejecución para monitorear el estado de los contenedores y, si es necesario, tomar las medidas adecuadas. Sin esto, no será posible unificar la automatización de la actualización de contenedores y la gestión de su ciclo de vida, lo que, a su vez, empeorará la estabilidad y usabilidad del sistema de software.
En la práctica, una aplicación en contenedores debe, como mínimo, tener una API para varios tipos de controles de estado: pruebas de actividad y pruebas de preparación. Si una aplicación pretende hacer más, debe proporcionar otros medios para monitorear su estado. Por ejemplo, registrar eventos importantes a través de STDERR y STDOUT para agregar registros utilizando Fluentd, Logstash y otras herramientas similares. Además de la integración con bibliotecas de rastreo y recopilación de métricas, como OpenTracing, Prometheus, etc.
En general, la aplicación aún se puede tratar como una caja negra, pero se le deben proporcionar todas las API que la plataforma necesita para poder monitorearla y administrarla de la mejor manera posible.
Principio de conformidad del ciclo de vida (LCP)
LCP es la antítesis de HOP. Mientras que HOP establece que el contenedor debe exponer las API de lectura a la plataforma, LCP requiere que la aplicación pueda aceptar información de la plataforma. Además, el contenedor no sólo debe recibir eventos, sino también adaptarse, es decir, reaccionar ante ellos. De ahí el nombre del principio, que puede considerarse como un requisito para dotar a la plataforma de API de escritura.
Las plataformas tienen diferentes tipos de eventos para ayudar a gestionar el ciclo de vida de un contenedor. Pero corresponde a la propia aplicación decidir cuáles percibir y cómo reaccionar.
Está claro que algunos acontecimientos son más importantes que otros. Por ejemplo, si una aplicación no tolera bien las fallas, debe aceptar mensajes de señal: terminar (SIGTERM) e iniciar su rutina de terminación lo más rápido posible para captar la señal: matar (SIGKILL) que viene después de SIGTERM.
Además, eventos como PostStart y PreStop pueden ser importantes para el ciclo de vida de una aplicación. Por ejemplo, después de iniciar una aplicación, es posible que necesite un tiempo de preparación antes de que pueda responder a las solicitudes. O la aplicación debe liberar recursos de alguna manera especial al cerrarse.
El principio de inmutabilidad de la imagen (IIP)
En general, se acepta que las aplicaciones en contenedores deben permanecer sin cambios después de su creación, incluso si se ejecutan en entornos diferentes. Esto requiere la necesidad de externalizar el almacenamiento de datos en tiempo de ejecución (en otras palabras, usar herramientas externas para esto) y confiar en configuraciones externas específicas del tiempo de ejecución, en lugar de modificar o crear contenedores únicos para cada entorno. Después de cualquier cambio en la aplicación, la imagen del contenedor se debe reconstruir e implementar en todos los entornos utilizados. Por cierto, en la gestión de sistemas de TI se utiliza un principio similar, conocido como principio de inmutabilidad de servidores e infraestructura.
El objetivo de IIP es evitar la creación de imágenes de contenedores separadas para diferentes entornos de ejecución y utilizar la misma imagen en todas partes junto con la configuración adecuada específica del entorno. Seguir este principio le permite implementar prácticas tan importantes desde el punto de vista de la automatización de los sistemas en la nube como la reversión y avance de las actualizaciones de las aplicaciones.
Principio de desechabilidad del proceso (PDP)
Una de las características más importantes de un contenedor es su carácter efímero: una instancia de un contenedor es fácil de crear y de destruir, por lo que puede reemplazarse fácilmente por otra instancia en cualquier momento. Puede haber muchas razones para tal reemplazo: falla en una prueba de capacidad de servicio, escalamiento de la aplicación, transferencia a otro host, agotamiento de los recursos de la plataforma u otras situaciones.
Como consecuencia, las aplicaciones en contenedores deben mantener su estado utilizando algún medio externo, o utilizar esquemas distribuidos internos con redundancia para ello. Además, la aplicación debe iniciarse y cerrarse rápidamente, y estar preparada para un fallo repentino y fatal del hardware.
Una práctica que ayuda a implementar este principio es mantener los contenedores pequeños. Los entornos de nube pueden seleccionar automáticamente un host para lanzar una instancia de contenedor, por lo que cuanto más pequeño sea el contenedor, más rápido se iniciará; simplemente se copiará al host de destino a través de la red más rápido.
Principio de autocontención (S-CP)
Según este principio, en la etapa de montaje todos los componentes necesarios se incluyen en el contenedor. El contenedor debe construirse asumiendo que el sistema sólo tiene un kernel Linux puro, por lo que todas las bibliotecas adicionales necesarias deben colocarse en el propio contenedor. También debe contener elementos como el tiempo de ejecución del lenguaje de programación correspondiente, la plataforma de la aplicación (si es necesario) y otras dependencias que serán necesarias mientras se ejecuta la aplicación contenedora.
Se hacen excepciones para configuraciones que varían de un entorno a otro y deben proporcionarse en tiempo de ejecución, por ejemplo, a través de un ConfigMap de Kubernetes.
Una aplicación puede incluir varios componentes en contenedores, por ejemplo, un contenedor DBMS separado dentro de una aplicación web en contenedores. Según el principio S-CP, estos contenedores no deben combinarse en uno solo, sino que deben hacerse de modo que el contenedor DBMS contenga todo lo necesario para el funcionamiento de la base de datos y el contenedor de la aplicación web contenga todo lo necesario para el funcionamiento de la web. aplicación, el mismo servidor web. Como resultado, en tiempo de ejecución, el contenedor de la aplicación web dependerá del contenedor DBMS y accederá a él según sea necesario.
Principio de confinamiento en tiempo de ejecución (RCP)
El principio S-CP define cómo se debe construir el contenedor y qué debe contener la imagen binaria. Pero un contenedor no es sólo una “caja negra” que tiene una sola característica: el tamaño del archivo. Durante la ejecución, el contenedor adquiere otras dimensiones: la cantidad de memoria utilizada, el tiempo de CPU y otros recursos del sistema.
Y aquí resulta útil el principio RCP, según el cual el contenedor debe decapitar sus necesidades de recursos del sistema y transferirlos a la plataforma. Con los perfiles de recursos de cada contenedor (cuántos recursos de CPU, memoria, red y disco necesita), la plataforma puede realizar de manera óptima la programación y el escalado automático, administrar la capacidad de TI y mantener los niveles de SLA para los contenedores.
Además de cumplir con los requisitos de recursos del contenedor, también es importante que la aplicación no traspase sus propios límites. De lo contrario, cuando se produce una escasez de recursos, es más probable que la plataforma los incluya en la lista de aplicaciones que deben finalizarse o migrarse.
Cuando hablamos de dar prioridad a la nube, nos referimos a la forma en que trabajamos.
Anteriormente, formulamos una serie de principios generales que establecen la base metodológica para crear aplicaciones de contenedores de alta calidad para entornos de nube.
Tenga en cuenta que además de estos principios generales, también necesitará métodos y técnicas avanzados adicionales para trabajar con contenedores. Además, tenemos algunas recomendaciones breves que son más específicas y deben aplicarse (o no aplicarse) según la situación:
- Intente reducir el tamaño de las imágenes: elimine archivos temporales y no instale paquetes innecesarios; cuanto más pequeño sea el tamaño del contenedor, más rápido se ensamblará y copiará en el host de destino a través de la red.
- Concéntrese en ID de usuario arbitrarios: no utilice el comando sudo ni ningún ID de usuario especial para iniciar sus contenedores.
- Marque los puertos importantes: puede configurar los números de puerto en tiempo de ejecución, pero es mejor especificarlos usando el comando EXPOSE; facilitará que otras personas y programas utilicen sus imágenes.
- Almacene datos persistentes en volúmenes: los datos que deben permanecer después de que se destruya el contenedor deben escribirse en volúmenes.
- Escriba metadatos de imágenes: etiquetas, rótulos y anotaciones hacen que las imágenes sean más fáciles de usar; otros desarrolladores se lo agradecerán.
- Sincronizar host e imágenes: algunas aplicaciones en contenedores requieren que el contenedor se sincronice con el host en ciertos atributos, como la hora o la identificación de la máquina.
- En conclusión, compartimos plantillas y mejores prácticas que lo ayudarán a implementar de manera más efectiva los principios enumerados anteriormente:
11 de junio a las 11.00
Que aprenderás:
- CoreOS inmutable de Red Hat Enterprise Linux
- Malla de servicios OpenShift
- Marco del operador
- Marco nativo
Fuente: habr.com