Hola habrozhiteli!Con el desarrollo de microservicios y contenedores, los enfoques para el diseño, creación y lanzamiento de software han cambiado. Explore los nuevos patrones y principios de diseño necesarios para implementar las aplicaciones en la nube de Kubernetes.Este libro está dirigido a desarrolladores que desean diseñar y desarrollar aplicaciones basadas en la nube para la plataforma Kubernetes. El mayor beneficio será que los lectores estén al menos un poco familiarizados con los contenedores y quieran ascender a un nuevo nivel. Cada patrón de diseño es una descripción del problema real, y la solución es compatible e ilustrada por ejemplos de código específicos.Extracto. Patrón de sidecar
El patrón Sidecar (Trailer) es para definir un contenedor que amplíe las capacidades de un contenedor existente sin cambiarlo. Este es uno de los patrones de contenedor fundamentales que le permite crear contenedores altamente especializados que trabajan estrechamente entre sí. En este capítulo aprenderá todo lo relacionado con la idea del patrón Sidecar (Tráiler). Y en los capítulos 16 y 17 conocerá variantes especializadas de este patrón: los patrones Adaptador y Embajador, respectivamente.Tarea
Los contenedores son una tecnología de empaquetado popular que permite a los desarrolladores y administradores de sistemas crear, entregar y ejecutar aplicaciones de manera unificada. Un contenedor representa el límite natural de una unidad funcional con su tiempo de ejecución, ciclo de lanzamiento, API y el equipo de desarrollo al que pertenece. Un contenedor típico actúa como un proceso en Linux, resuelve un problema y lo hace bien, y se crea bajo el supuesto de la posibilidad de reemplazo y reutilización. Esto último es especialmente importante porque le permite crear rápidamente aplicaciones utilizando contenedores especializados existentes.Actualmente, para enviar una solicitud HTTP, no necesita escribir una biblioteca cliente, solo use la existente. Del mismo modo, para mantener el sitio web, no necesita crear un contenedor con un servidor web, solo use el existente. Este enfoque permite a los desarrolladores no reinventar la rueda y crear un ecosistema con menos contenedores de mejor calidad para el mantenimiento. Sin embargo, para poder utilizar contenedores reutilizables altamente especializados, son necesarias formas de expandir sus capacidades y medios para organizar las interacciones entre ellos. El patrón Sidecar (Tráiler) describe tal forma de organizar las interacciones cuando un contenedor expande las capacidades de otro contenedor existente.Decisión
En el capítulo 1, vimos cómo las vainas le permiten combinar varios contenedores en un bloque. Detrás de escena, en tiempo de ejecución, debajo también hay un contenedor, pero comienza como un proceso en pausa (literalmente usando el comando de pausa) frente a todos los demás contenedores en el hogar. No hace nada más que almacenar todos los espacios de nombres de Linux que los contenedores de aplicaciones usan para interactuar durante todo el ciclo de vida del pod. Además de este detalle de implementación, todas las características que proporciona la abstracción del hogar también son de interés.Under es una primitiva tan fundamental que está presente en muchas plataformas en la nube, aunque con diferentes nombres, pero siempre con capacidades similares. Debajo, como unidad de despliegue, impone ciertas restricciones de tiempo de ejecución en sus contenedores. Por ejemplo, todos los contenedores se implementan en un nodo y tienen un ciclo de vida común. Además, under permite que sus contenedores utilicen volúmenes compartidos e intercambien datos a través de una red local o mediante herramientas de comunicación entre procesos del host. Es por eso que los usuarios combinan contenedores en cápsulas. El patrón Sidecar (Trailer), a veces también llamado Sidekick (Companion), describe el escenario de agregar un contenedor a la parte inferior para expandir las capacidades de otro contenedor.Un ejemplo típico que demuestra este patrón es el servidor HTTP y el mecanismo de sincronización con el repositorio de Git. El contenedor del servidor HTTP resuelve los problemas asociados con el mantenimiento de archivos a través de HTTP y no sabe cómo y de dónde provienen estos archivos. Del mismo modo, el único propósito de un contenedor que se sincroniza con Git es sincronizar los datos en el sistema de archivos local con los datos en el servidor Git. No le importa lo que suceda con los archivos después de la sincronización, su única tarea es sincronizar los contenidos de la carpeta local con los contenidos en el servidor Git remoto. El Listado 15.1 proporciona una definición de pod con estos dos contenedores configurados para usar el volumen para compartir archivos.Listado 15.1. Implementación de patrones de sidecar (Tráiler)apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: app
image: docker.io/centos/httpd ❶
ports:
- containerPort: 80
volumeMounts:
- mountPath: /var/www/html ❸
name: git
- name: poll
image: axeclbr/git ❷
volumeMounts:
- mountPath: /var/lib/data ❸
name: git
env:
- name: GIT_REPO
value: https://github.com/mdn/beginner-html-site-scripted
command:
- "sh"
- "-c"
- "git clone $(GIT_REPO) . && watch -n 600 git pull"
workingDir: /var/lib/data
volumes:
- emptyDir: {}
name: git
(1) El contenedor principal de la aplicación que sirve archivos a través de HTTP.(2) Contenedor auxiliar (Trailer) que actúa en paralelo y recibe datos del servidor Git.(3) Una carpeta compartida para intercambiar datos entre los contenedores primario y secundario.Este ejemplo muestra cómo un contenedor de sincronización con Git agrega contenido para ser servido por un servidor HTTP y lo mantiene actualizado. También puede decir que ambos contenedores funcionan en estrecha colaboración y son igualmente importantes, pero el patrón Sidecar (Trailer) supone la presencia de un contenedor principal (principal) y auxiliar que expande el comportamiento colectivo. Por lo general, el principal aparece primero en la lista de contenedores y representa el contenedor predeterminado (que se inicia con el comando kubectl exec, por ejemplo).Este patrón simple, que se muestra en la fig. 15.1 garantiza una estrecha cooperación de los contenedores en tiempo de ejecución y al mismo tiempo permite compartir tareas que pueden pertenecer a equipos separados de desarrolladores que utilizan diferentes lenguajes de programación, con diferentes ciclos de lanzamiento de nuevas versiones, etc. También promueve la intercambiabilidad y la reutilización de contenedores: en el sentido de que el servidor HTTP y el mecanismo de sincronización Git pueden reutilizarse en otras aplicaciones y con otras configuraciones, tanto de forma independiente como en combinación con otros contenedores.Explicación
Ya se ha dicho anteriormente que las imágenes de contenedor son similares a las clases, y los contenedores son como objetos en la programación orientada a objetos (OOP). Continuando con esta analogía, podemos comparar la expansión de las capacidades de los contenedores con la herencia en OOP, y el trabajo conjunto de varios contenedores en el hogar con la recepción de una composición en OOP. Ambos enfoques permiten la reutilización del código, pero la herencia define una relación más estrecha y representa la relación "es" entre los contenedores.La composición en el hogar representa la relación "tiene": es más flexible porque no requiere la combinación de contenedores durante el ensamblaje, lo que hace posible cambiar los contenedores en la definición del hogar más adelante. Pero la composición también implica la presencia de varios contenedores (procesos) que funcionan simultáneamente, que deben verificarse para que funcionen y reiniciarse, y que consumen recursos, así como el contenedor principal de la aplicación. El patrón Sidecar (Trailer) implica la creación de pequeños contenedores auxiliares que consumen recursos mínimos, pero usted decide si iniciar un proceso separado o combinar mejor todas las tareas en un contenedor principal.Desde otro punto de vista, la composición de los contenedores es similar a la programación orientada a aspectos, cuando con la ayuda de contenedores adicionales, se agregan capacidades secundarias ortogonales (independientes) que no están relacionadas con el contenedor principal. En los últimos meses, el patrón Sidecar ha ido ganando popularidad, especialmente para las tareas de administración de redes y monitoreo de servicios, donde cada servicio también se presenta en forma de contenedores auxiliares.»Se puede encontrar más información sobre el libro en el sitio web del editor» Contenido» Extracto deKhabrozhiteley 25% de descuento en el cupón - KubernetesTras el pago de la versión en papel del libro, se envía un libro electrónico por correo electrónico.