Revisión: Red Hat hace Docker por las malas

Project Atomic de Red Hat es una forma obstinada de ejecutar contenedores de Linux. El sistema operativo Atomic Host viene con Docker (contenedores), Flannel (redes), OSTree (administración de host), Etcd (almacén distribuido de clave-valor) y Kubernetes (orquestación) ya instalados. 

Kubernetes es uno de los dos sistemas de orquestación de contenedores más populares, el otro es Docker Swarm. Podría llamarlo “completo”, pero con eso viene una complejidad adicional y gastos administrativos.

Kubernetes coordina la creación de "pods" en varios hosts Atomic. Los pods son grupos de contenedores de Docker que separan lógicamente los servicios en una aplicación. Los contenedores de un pod comparten una dirección IP y se comunican a través de localhost.

Flannel proporciona una red superpuesta para hosts Atomic, lo que permite que cada pod del clúster se comunique con cualquier otro pod o servicio dentro del clúster. Esta red superpuesta se utiliza solo para redes de contenedores. Un servicio de proxy de Kubernetes proporciona acceso al espacio de IP del host.

Etcd se utiliza para almacenar configuraciones para Kubernetes y Flannel en todos los hosts del clúster.

Los clústeres de contenedores atómicos hacen ciertas suposiciones debido a Kubernetes. Los administradores realmente no tienen otra opción con Atomic: usar Kubernetes o buscar otro sistema operativo contenedor. 

Si le irrita el "diseño por convención" y desea más libertad y flexibilidad en un host contenedor, podría considerar RancherOS o VMware Photon. Si su objetivo final es ejecutar muchos contenedores en muchos hosts, entonces Atomic Host, Kubernetes y amigos pueden ser justo lo que necesita.  

Administración del sistema Atomic Host

Atomic Host usa su propia versión del dockercomando, atomicaunque el dockercomando real  está disponible en / bin / docker. Su ubicación en / bin sugiere algunas de las modificaciones que se realizaron en RHEL / CentOS / Fedora para hacer que el sistema operativo Atomic esté diseñado específicamente para contenedores. Normalmente, solo los binarios del sistema importantes residen en / bin.

Administra Atomic Host a través de dos subsistemas. RPM-OSTree maneja la implementación y las actualizaciones del sistema host, mientras que Docker maneja el aprovisionamiento de contenedores para ejecutar servicios y aplicaciones. Ambos subsistemas son administrados por el atomiccomando ubicado en / usr / bin /.

RPM-OSTree hace que el sistema de archivos Atomic sea inmutable; es decir, el sistema de archivos es de solo lectura excepto para / var y / etc. El directorio / var / lib / docker es donde se almacenan todos los archivos e imágenes relacionados con Docker, mientras que / etc tiene todos los archivos de configuración. Como veremos más adelante, esto hace que las actualizaciones y degradaciones del host sean más simples y seguras, un requisito esencial cuando se administran potencialmente miles de hosts contenedores en un clúster.

El atomiccomando está destinado a ser un único punto de entrada al subsistema del contenedor, un comando general para todo lo relacionado con el contenedor, incluidas las operaciones del host. El atomiccomando se parece mucho al dockercomando, pero aborda un problema fundamental compartido por todos los sistemas operativos de host de contenedor: iniciar un servicio a nivel de sistema en un contenedor en el momento del arranque, de una manera confiable y transparente, utilizando archivos de unidad Systemd.

En Atomic, esto se hace con lo que se llama un contenedor superprivilegiado, que tiene la capacidad de ver y manipular el propio host. Entonces, aunque atomicparece un comando estándar de Docker, está llenando los vacíos entre Docker y RPM-OSTree (configurando scripts de instalación, configurando servicios, asignando los privilegios adecuados, etc.) para permitir la implementación confiable de una aplicación basada en contenedores. .

En pocas palabras, el  atomic comando le permite manipular la infraestructura del host subyacente (cgroups, espacios de nombres, SELinux, etc.) para ejecutar sus aplicaciones. Por ejemplo, supongamos que creó una aplicación de contenedor de Protocolo de tiempo de red (ntpd) que requiere la capacidad SYS_TIME para modificar la hora del sistema del host. Puede configurar esto agregando metadatos a la imagen de su contenedor usando el comando:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

Luego, cuando ejecute el contenedor ( atomic run ntpd), el sistema leerá esos metadatos y configurará la capacidad SYS_TIME y otros recursos para el contenedor. 

Instalación y configuración de Atomic Host

La instalación fue una lucha, principalmente porque encontré la documentación desorganizada y confusa. Los documentos asumen un alto nivel de conocimiento del ecosistema de Red Hat que no todos los lectores tendrán. Después de algunos comienzos en falso, finalmente logré instalar desde un ISO completo. El soporte para la instalación de máquinas virtuales con cualquier otra cosa que no sea virt-manager es doloroso. Atomic Host definitivamente no es compatible con Windows o Mac en este sentido.

Para cualquiera que esté familiarizado con una instalación de CentOS, el procedimiento completo será fácil. Las únicas diferencias notables están en el diseño del disco, con espacio reservado automáticamente para Docker y contenedores, junto con la gran cantidad de montajes para SELinux, cgroups, etc. que acompañan a la instalación de un sistema operativo contenedor.

Usar Kubernetes para administrar contenedores en un clúster es significativamente más complicado que ejecutar Docker en un solo host, pero una mayor complejidad conlleva una mayor confiabilidad y capacidad. Con Kubernetes, también obtiene la comodidad de saber que el sistema ha sido probado en batalla en entornos de producción a gran escala (en Google).

No existe una forma sencilla de configurar un maestro de Kubernetes. La documentación se distribuye en varios sitios web de proyectos, y muchas veces los documentos se dirigen a otros sitios para obtener detalles, así que prepárese para pasar mucho tiempo leyendo, buscando documentos y experimentando. La suma total del esfuerzo implica la modificación de una docena de archivos distribuidos en unos pocos directorios / etc. Por supuesto, el truco está en saber cuáles son esas modificaciones. Kubernetes no está realmente diseñado para la experimentación casual con contenedores. Esto es material de producción de alta resistencia.

Después de configurar el maestro con Kubernetes, certificados, servicios y una red de superposición de Flannel, luego instalar Flannel (flanneld), Kubernetes (kubelet) y Etcd en cada nodo, finalmente tuve un clúster de contenedores de cinco nodos en ejecución. Desafortunadamente, esto consumió bastante memoria y no pude encontrar una manera de probar usando un solo nodo, como hice cuando probé RancherOS y VMware Photon.

En este punto, Kubernetes se puede usar para lanzar y administrar pods, esos grupos de contenedores que encapsulan servicios y aplicaciones.

Almacenamiento y redes de Atomic Host

Como la mayoría de los sistemas operativos de host de contenedores, Atomic Host adopta un enfoque minimalista, con suficiente espacio en disco incluido para ejecutar el host. Eso no deja mucho para los muchos contenedores de Docker que se ejecutará un clúster típico, por lo que deberá adjuntar almacenamiento externo al host para eso.

En Docker, las imágenes y los archivos relacionados generalmente se almacenan en / var / lib / docker, y en la mayoría de los sistemas operativos estándar, simplemente montaría un dispositivo en ese punto del sistema de archivos para agregar almacenamiento. Sin embargo, Atomic usa volúmenes LVM (Administrador de volumen de Linux) directos a través del back-end de Device Mapper para almacenar imágenes y metadatos de Docker: / dev / atomicos / docker-data y / dev / atomicos / docker-meta. Eso significa que necesitará aprender algo sobre LVM y volúmenes para poder agregar espacio a un host Atomic.

El punto de partida para la gestión del almacenamiento en Atomic es el script de configuración, / etc / sysconfig / docker-storage-setup. Atomic Host tiene un grupo de almacenamiento para el almacenamiento de Docker (y host), por lo que el truco aquí es agregar un nuevo dispositivo a este grupo. Hará esto agregando a la lista de dispositivos en el archivo, así:

DEVS="/dev/vdb /dev/vdc"

Luego ejecuta el script auxiliar, / usr / bin / docker-storage-setup. Si todo va bien, sus discos se han agregado al grupo y su host Atomic tiene espacio para Docker. Supongo que LVM se administrará en producción con las herramientas de administración existentes, o con scripts como Ansible / Salt / Chef / Puppet, por lo que probablemente parecerá más estándar para los administradores que trabajan en entornos de grandes centros de datos.

Project Atomic usa Flannel para proporcionar una red de superposición de contenedores a través de Etcd. Puede configurar esto insertando un archivo de configuración JSON en el almacén de valores clave de Etcd, utilizando herramientas como Curl. Para configurar una subred para los contenedores, podríamos crear un archivo JSON con este aspecto:

   "Red": "172.16.0.0/12",

   "SubnetLen": 24,

   "Backend": {

      "Tipo": "vxlan"

   }

}

Y para poner esto en el maestro Etcd, lo insertamos en la clave de configuración de red:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Aunque algo engorroso, es manejable. Me gustaría ver una envoltura para estos comandos de configuración que hacen que sea más intuitivo para el administrador de Unix, tal vez algo así como atomic ifconfig…, atomic route…, etc.

Aquí hay otra diferencia que vale la pena destacar: los conceptos de pods y servicios de Kubernetes. Una vaina es un grupo de contenedores que están acoplados de manera relativamente estrecha. Todos los contenedores de un pod comparten el mismo host y la misma dirección IP, y todos viven o mueren juntos. Usted especifica cuántas instancias de un pod desea ejecutar y Kubernetes ejecuta el pedido. Si una instancia se detiene o falla, Kubernetes activa otra para que coincida con el estado deseado.

Un servicio de Kubernetes es una abstracción que define un conjunto lógico de pods y una política para acceder a ellos. Esto le da a un (micro) servicio un nombre y una dirección únicos y estables a lo largo del ciclo de vida del pod. Hay mucho más en esto, pero eso debería ayudarlo a comprender por qué necesita un componente separado para administrar la red. En Atomic Host, ese componente es Flannel.

Actualizaciones y degradaciones de Atomic Host

Atomic Host utiliza un administrador de paquetes llamado RPM-OSTree, que combina características de RPM y OSTree tradicionales. RPM-OSTree nos brinda la capacidad de avanzar y retroceder de manera confiable, ya que el proceso es "atómico" (en el sentido de la palabra como base de datos). RPM-OSTree proporciona transacciones confiables para actualizaciones, lo que significa que es poco probable que rompa el sistema operativo. Al igual que los comandos para contenedores, las actualizaciones y reversiones de host están dirigidas por el atomicsistema de gestión:

atomic host upgrade

atomic host rollback

Tenga en cuenta que no probé una reversión porque no tenía nada a lo que revertir.

Red Hat Atomic Host es más adecuado para organizaciones con una gran inversión en habilidades e infraestructura de Red Hat. Las empresas que comienzan desde un ángulo diferente pueden querer considerar otras opciones. La inclusión de Kubernetes y la historia de Red Hat en entornos de producción grandes significan que Atomic Host será casi un "complemento" para ejecutar cargas de trabajo en contenedores en empresas. Pero no veo que los desarrolladores lo elijan como su plataforma Docker preferida.