Las aplicaciones "nativas de la nube" o simplemente "en la nube" están diseñadas específicamente para funcionar en infraestructuras de nube. Por lo general, se construyen como un conjunto de microservicios débilmente acoplados, empaquetados en contenedores, que son gestionados por una plataforma de nube. Estas aplicaciones están preparadas para fallos por defecto, lo que significa que funcionan de manera fiable y pueden escalar incluso ante fallos significativos a nivel de infraestructura. La contrapartida es un conjunto de restricciones (contratos) que la plataforma de nube impone sobre las aplicaciones en contenedores para poder gestionarlas de manera automática.
Bien conscientes de la necesidad y la importancia de la transición a aplicaciones en la nube, muchas organizaciones aún no saben por dónde empezar. En esta publicación, abordaremos una serie de principios cuyo cumplimiento en el desarrollo de aplicaciones en contenedores permitirá aprovechar el potencial de las plataformas en la nube y lograr un funcionamiento y escalabilidad fiables de las aplicaciones, incluso ante fallos significativos en la infraestructura de TI. El objetivo final de los principios expuestos aquí es aprender a crear aplicaciones que puedan ser gestionadas automáticamente por plataformas de nube como Kubernetes.
Principios de diseño de software
En el mundo de la programación, los principios se entienden como reglas generales que deben seguirse al desarrollar software. Pueden aplicarse al trabajar con cualquier lenguaje de programación. Cada principio tiene sus propios objetivos, que generalmente son alcanzados mediante patrones y prácticas. También existe un conjunto de principios fundamentales para la creación de software de calidad, de los cuales derivan todos los demás. A continuación, presentaremos ejemplos de principios fundamentales:
- (Keep it simple, stupid) – no complicar;
- (Don’t repeat yourself) – no repetir;
- (You aren’t gonna need it) – no crear lo que no se necesita de inmediato;
- (Separation of concerns) – separar responsabilidades.
Como se puede ver, estos principios no establecen reglas concretas, sino que pertenecen a la categoría de consideraciones de sentido común basadas en la experiencia práctica, que comparten muchos desarrolladores y que ellos mismos citan con regularidad.
Además, existe – conjunto de los cinco primeros principios de la programación orientada a objetos y diseño, formulados por Robert C. Martin. SOLID incluye principios complementarios que son generalizables y abiertos a interpretación, los cuales, si se aplican en conjunto, ayudan a crear sistemas de software de mayor calidad y a mantenerlos mejor a largo plazo.
Los principios SOLID se refieren al ámbito de la POO y se formulan en el lenguaje de conceptos como clases, interfaces y herencia. Por analogía, para las aplicaciones en la nube también se pueden formular principios de desarrollo, donde el elemento básico ya no será la clase, sino el contenedor. Siguiendo estos principios, se pueden crear aplicaciones en contenedores que se alineen mejor con los objetivos y metas de plataformas en la nube como Kubernetes.
Contenedores orientados a la nube: enfoque de Red Hat
Hoy en día, es relativamente fácil empaquetar prácticamente cualquier aplicación en contenedores. Sin embargo, para que las aplicaciones se automaticen y orquesten de manera efectiva en una plataforma en la nube como Kubernetes, se requiere un esfuerzo adicional.
La base de las ideas expuestas a continuación es la metodología y numerosos otros trabajos sobre diversos aspectos de la creación de aplicaciones web, desde la gestión del código fuente hasta los modelos de escalabilidad. Los principios descritos se refieren solo al desarrollo de aplicaciones en contenedores, que están basadas en microservicios y diseñadas para plataformas en la nube como Kubernetes. El elemento básico en nuestras consideraciones es la imagen del contenedor, y el entorno de ejecución objetivo de los contenedores se entiende como la plataforma de orquestación de contenedores. El objetivo de los principios propuestos es crear contenedores para los cuales en la mayoría de las plataformas de orquestación se puedan automatizar las tareas de programación (scheduling - selección de host para ejecutar una instancia del contenedor), escalabilidad y monitoreo. Los principios se exponen en orden arbitrario.
Principio de responsabilidad única (Single Concern Principle, SCP)
Este principio es muy similar al principio de responsabilidad única (Single Responsibility Principle, ), que forma parte del conjunto SOLID y establece que cada objeto debe tener una única responsabilidad, y esa responsabilidad debe estar completamente encapsulada en la clase. La esencia del SRP es que cada responsabilidad es una razón para los cambios, y la clase debe tener una sola razón para cambiar.
En SCP, en lugar de la palabra «responsabilidad» (responsibility), utilizamos la palabra «tarea» (concern) para indicar un nivel más alto de abstracción y un propósito más amplio del contenedor en comparación con una clase de OOP. Y si el objetivo del SRP es tener solo una razón para los cambios, SCP está impulsado por el deseo de extender la capacidad de reutilización y reemplazo de los contenedores. Al seguir el SRP y crear un contenedor que resuelva una única tarea y lo haga de manera funcionalmente completa, aumentas las posibilidades de reutilizar ese contenedor en diferentes contextos de aplicación.
El principio SCP establece que cada contenedor debe resolver una única tarea y hacerlo bien. Además, en el mundo de los contenedores se logra más fácilmente SCP que SRP en el ámbito de OOP, ya que los contenedores generalmente realizan un único proceso y, la mayor parte del tiempo, ese proceso se encarga de una única tarea.
Si algún microservicio en contenedor debe resolver múltiples tareas, se puede descomponer en contenedores de una sola tarea y agruparlos dentro de un mismo pod (unidad de despliegue en la plataforma de contenedores) utilizando plantillas sidecar y contenedores init. Además, SCP facilita la sustitución de un contenedor viejo (por ejemplo, un servidor web o un corredor de mensajes) por uno nuevo que resuelva la misma tarea pero que tenga funcionalidades ampliadas o que escale mejor.
El principio de alta observabilidad (High Observability Principle, HOP)
Al utilizar contenedores como una forma unificada de empaquetar y ejecutar aplicaciones, las aplicaciones mismas se consideran como una "caja negra". Sin embargo, si se trata de contenedores en la nube, deben proporcionar a su entorno de ejecución API especiales para controlar la integridad de los contenedores y tomar las medidas adecuadas cuando sea necesario. Sin esto, no se podrá unificar la automatización de la actualización de contenedores y la gestión de su ciclo de vida, lo que, a su vez, deteriorará la resiliencia y la facilidad de uso del sistema de software.
En la práctica, una aplicación en contenedor debe, como mínimo, tener una API para varios tipos de comprobaciones de integridad: pruebas de actividad (liveness) y pruebas de preparación (readiness). Si la aplicación reclama más, también debe proporcionar otros medios para controlar su estado. Por ejemplo, registrando eventos importantes a través de STDERR y STDOUT para la agregación de registros utilizando Fluentd, Logstash y otras herramientas similares. Así como integrar con bibliotecas de trazado y recolección de métricas, como OpenTracing, Prometheus, etc.
En general, una aplicación aún puede considerarse como una "caja negra", pero debe estar equipada con todas las API necesarias para que la plataforma pueda monitorearla y gestionarla de la mejor manera posible.
Principio de conformidad con el ciclo de vida (Life-cycle Conformance Principle, LCP)
LCP es la antítesis de HOP. Mientras que HOP establece que un contenedor debe proporcionar a la plataforma interfaces API para la lectura, LCP exige que la aplicación tenga la capacidad de recibir información de la plataforma. Además, el contenedor no solo debe recibir eventos, sino también adaptarse, es decir, reaccionar a ellos. De ahí el nombre del principio, que puede considerarse como un requerimiento para proporcionar a la plataforma interfaces API para la escritura.
Las plataformas tienen diferentes tipos de eventos que ayudan a gestionar el ciclo de vida del contenedor. Pero decidir cuáles de ellos recibir y cómo reaccionar debe ser responsabilidad de la propia aplicación.
Es evidente que algunos eventos son más importantes que otros. Por ejemplo, si una aplicación maneja mal el cierre inesperado, debe aceptar los mensajes signal: terminate (SIGTERM) e iniciar su procedimiento de cierre lo más rápido posible, para conseguirlo antes de recibir el signal: kill (SIGKILL), que llega después de SIGTERM.
Además, para el ciclo de vida de la aplicación, pueden ser importantes eventos como PostStart y PreStop. Por ejemplo, después del inicio, la aplicación puede necesitar un tiempo de "calentamiento" antes de poder responder a las solicitudes. O la aplicación debe liberar recursos de una manera especial al cerrarse.
Principio de inmutabilidad de la imagen del contenedor (Image Immutability Principle, IIP)
Se acepta generalmente que las aplicaciones en contenedores deben permanecer invariables después de la construcción, incluso si se ejecutan en diferentes entornos. De aquí surge la necesidad de externalizar el almacenamiento de datos en tiempo de ejecución (en otras palabras, utilizar herramientas externas para esto), así como confiar en configuraciones externas, adaptadas a un entorno de ejecución específico, en lugar de modificar o crear contenedores únicos para cada entorno. Después de cualquier cambio en la aplicación, la imagen del contenedor debe ser reconstruida y desplegada en todos los entornos utilizados. Por cierto, en la gestión de sistemas de TI se utiliza un principio similar, conocido como el principio de inmutabilidad de los servidores y la infraestructura.
El objetivo del IIP es prevenir 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 apropiada para un entorno específico. Seguir este principio permite implementar prácticas importantes para la automatización de sistemas en la nube, como el retroceso (roll-back) y la implementación (roll-forward) de actualizaciones de la aplicación.
Principio de desechabilidad de procesos (Process Disposability Principle, PDP)
Una de las características más importantes de un contenedor es su efimeridad: una instancia de contenedor se puede crear fácilmente y destruirse fácilmente, por lo que en cualquier momento se puede reemplazar fácilmente por otra instancia. Hay muchas razones para tal reemplazo: fallo en la prueba de integridad, escalado de la aplicación, migración a otro host, agotamiento de recursos de la plataforma u otras situaciones.
Como resultado, las aplicaciones en contenedores deben mantener su estado utilizando algún medio externo, o usar esquemas distribuidos internos con redundancia. Además, la aplicación debe iniciarse rápidamente y finalizar su ejecución con agilidad, así como estar preparadas para un fallo fatal inesperado del hardware.
Una de las prácticas que ayuda a implementar este principio es crear contenedores de tamaño pequeño. Los entornos en la nube pueden seleccionar automáticamente el anfitrión para ejecutar una instancia del contenedor, por lo que cuanto más pequeño sea el tamaño del contenedor, más rápido se iniciará; simplemente se copia más rápidamente en el anfitrión de destino a través de la red.
Principio de autosuficiencia (Self-containment Principle, S-CP)
De acuerdo con este principio, en la etapa de construcción se incluyen todos los componentes necesarios en el contenedor. El contenedor debe construirse asumiendo que en el sistema solo hay un núcleo Linux limpio, por lo que todas las bibliotecas adicionales necesarias deben estar dentro del propio contenedor. También deben incluirse cosas como el entorno de ejecución para el lenguaje de programación correspondiente, la plataforma de aplicaciones (si es necesario) y otras dependencias que serán necesarias durante la ejecución de la aplicación en contenedor.
Las excepciones solo se hacen para configuraciones que varían de un entorno a otro y deben proporcionarse en la etapa de ejecución, por ejemplo, a través de Kubernetes ConfigMap.
La aplicación puede incluir varios componentes en contenedores, como un contenedor de base de datos separado en una aplicación web en contenedor. Según el principio S-CP, estos contenedores no deben combinarse en uno solo, sino que el contenedor de la base de datos debe contener todo lo necesario para el funcionamiento de la base de datos, mientras que el contenedor de la aplicación web debe incluir todo lo necesario para el funcionamiento de la aplicación web, incluido el servidor web. Como resultado, durante la ejecución, el contenedor de la aplicación web dependerá del contenedor de la base de datos y se comunicará con él según sea necesario.
Principio de confinamiento en tiempo de ejecución (Runtime Confinement Principle, RCP)
El principio S-CP define cómo debe ensamblarse un contenedor y qué debe contener el archivo binario de la imagen. Pero un contenedor no es solo una "caja negra" que tiene una sola característica: el tamaño del archivo. Durante la ejecución, el contenedor adquiere otras dimensiones: el volumen de memoria utilizada, el tiempo de CPU y otros recursos del sistema.
Y aquí es donde entra en juego el principio RCP, de acuerdo al cual el contenedor debe desacoplar sus requisitos de recursos del sistema y transmitirlos a la plataforma. Con los perfiles de recursos de cada contenedor (cuántos recursos de CPU, memoria, red y sistema de disco necesita), la plataforma puede realizar la programación y el escalado automático de manera óptima, gestionar las capacidades de TI y mantener los niveles SLA para los contenedores.
Además de satisfacer los requisitos de recursos del contenedor, la aplicación también es importante para no sobrepasar los límites que ella misma ha definido. De lo contrario, en caso de escasez de recursos, la plataforma tendrá más probabilidades de incluirla en la lista de aplicaciones que deben ser detenidas o migradas.
Hablando de orientación hacia la nube, nos referimos principalmente a la forma de trabajar.
Hemos formulado anteriormente una serie de principios generales que establecen la base metodológica para construir aplicaciones de contenedores de calidad para entornos en la nube.
Cabe destacar que además de estos principios generales, también necesitará métodos y técnicas avanzadas adicionales para trabajar con contenedores. Además, tenemos algunas recomendaciones breves que son de carácter más específico 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 menor 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.
- Apéguese a un User-ID arbitrario: no utilice el comando sudo o ningún userid especial para ejecutar sus contenedores.
- Etiquete puertos importantes: los números de puerto se pueden definir también durante la ejecución, pero es mejor especificarlos mediante el comando EXPOSE; será más fácil para otros usuarios y programas utilizar sus imágenes.
- Almacene datos persistentes en volúmenes: los datos que deben permanecer después de la eliminación del contenedor deben escribirse en volúmenes.
- Escriba los metadatos de la imagen: las etiquetas, marcas y anotaciones facilitan el uso de imágenes; otros desarrolladores se lo agradecerán.
- Sincronice el host y las imágenes: algunas aplicaciones de contenedores requieren la sincronización del contenedor con el host en ciertos atributos, como la hora o el identificador de la máquina.
- Para concluir, compartimos plantillas y mejores prácticas que ayudarán a implementar de manera más efectiva los principios mencionados anteriormente:
11 de junio a las 11:00
Lo que aprenderá:
- Red Hat Enterprise Linux CoreOS Inmutable
- Malla de servicios OpenShift
- Marco de operadores
- Marco de Knative
Fuente: habr.com
