Herramientas de plataforma de contenedores en Windows

¡La plataforma de contenedores de Windows se está expandiendo! Docker fue la primera parte del recorrido de los contenedores, y ahora estamos creando otras herramientas para la plataforma de contenedores.

• containerd/cri, nuevo en Windows Server 2019/Windows 10 1809.
• runhcs: un host de contenedor de Windows equivalente a runc.
• hcs: servicio de proceso de host y correcciones de compatibilidad (shim) útiles para que sea más fácil de usar.
  • hcsshim
  • dotnet-computevirtualization

En este artículo hablaremos sobre la plataforma de contenedores de Windows y Linux, así como de cada herramienta para la plataforma de contenedores.

Plataforma de contenedores de Windows y Linux

En entornos de Linux, las herramientas de administración de contenedores, como Docker, se basan en un conjunto más granular de herramientas de contenedor: runc y containerd.

runc es una herramienta de línea de comandos de Linux para crear y ejecutar contenedores según la especificación de runtime de contenedores de OCI.

containerd es un demonio que administra el ciclo de vida de los contenedores, desde la descarga de la imagen del contenedor, pasando por su desempaquetado, hasta la ejecución y supervisión del contenedor.

En Windows, adoptamos un enfoque diferente. Cuando comenzamos a trabajar con Docker para admitir contenedores de Windows, compilamos directamente en el HCS (servicio de proceso de host). Esta entrada de blog está llena de información sobre por qué creamos el HCS y por qué adoptamos este enfoque para los contenedores en un principio.

En este momento, Docker todavía llama directamente al HCS. No obstante, en el futuro las herramientas de administración de contenedores que se expanden para incluir contenedores de Windows y el host de contenedor de Windows podrían llamar a containerd y runhcs de la forma en que llaman a containerd y runc en Linux.

runhcs

runhcs es una bifurcación de runc. Al igual que runc, runhcs es un cliente de línea de comandos para ejecutar aplicaciones empaquetadas según el formato de Open Container Initiative (OCI), y es una implementación compatible de la especificación de Open Container Initiative.

Entre las diferencias funcionales entre runc y runhcs se incluyen:

• runhcs se ejecuta en Windows. Se comunica con el HCS para crear y administrar contenedores.

• runhcs puede ejecutar una variedad de tipos de contenedor diferentes.

  • Aislamiento de Hyper-V para Windows y Linux
  • Contenedores de procesos de Windows (la imagen del contenedor debe coincidir con el host de contenedor)

Uso:

runhcs run [ -b bundle ] <container-id>

<container-id> es el nombre de la instancia de contenedor que estás iniciando. El nombre debe ser único en el host de contenedor.

El directorio del conjunto (mediante -b bundle) es opcional. Al igual que con runc, los contenedores se configuran mediante conjuntos. El conjunto de un contenedor es el directorio con el archivo de la especificación de OCI del contenedor, "config.json". El valor predeterminado para "bundle" es el directorio actual.

El archivo de especificación de OCI, "config.json", tiene que tener dos campos para ejecutarse correctamente:

• Una ruta de acceso al espacio de desecho del contenedor
• Una ruta de acceso al directorio de capas del contenedor

Entre los comandos de contenedor disponibles en runhcs se incluyen:

• Herramientas para crear y ejecutar un contenedor

  • run crea y ejecuta un contenedor.
  • create crea un contenedor.

• Herramientas para administrar procesos que se ejecutan en un contenedor:

  • start ejecuta el proceso definido por el usuario en un contenedor creado.
  • exec ejecuta un nuevo proceso dentro del contenedor.
  • pause suspende todos los procesos dentro del contenedor.
  • resume reanuda todos los procesos que se han pausado previamente.
  • ps muestra los procesos que se ejecutan dentro de un contenedor.

• Herramientas para administrar el estado de un contenedor

  • state genera el estado de un contenedor.
  • kill envía la señal especificada (valor predeterminado: SIGTERM) al proceso de inicialización del contenedor.
  • delete elimina todos los recursos que mantiene el contenedor que se usan a menudo con el contenedor separado.

El único comando que se puede considerar como de varios contenedores es list. Muestra los contenedores en ejecución o en pausa iniciados por runhcs con la raíz especificada.

HCS

Tenemos dos encapsulados disponibles en GitHub para interactuar con el HCS. Dado que el HCS es una API de C, los encapsulados facilitan la llamada al HCS desde lenguajes de nivel superior.

• hcsshim: HCSShim está escrito en Go y es la base de runhcs. Obtén la versión más reciente de AppVeyor o compílala tú mismo.
• dotnet-computevirtualization: dotnet-computevirtualization es un encapsulado de C# para el HCS.

Si quieres usar el HCS (ya sea directamente o a través de un encapsulado) o quieres crear un encapsulado de Rust/Haskell/IndicaTuLenguaje alrededor del HCS, deja un comentario.

Para una mirada más profunda del HCS, ve la presentación de John en DockerCon.

containerd/cri

Importante

La compatibilidad con CRI solo está disponible en Server 2019/Windows 10 1809 y versiones posteriores.

Mientras que las especificaciones de OCI definen un único contenedor, CRI (interfaz de runtime de contenedores) describe los contenedores como cargas de trabajo en un entorno de espacio aislado compartido denominado pod. Los pods pueden contener una o más cargas de trabajo de contenedor. Los pods permiten a los orquestadores de contenedores, como Kubernetes y Service Fabric Mesh, controlar las cargas de trabajo agrupadas que deben estar en el mismo host con algunos recursos compartidos, como la memoria y las redes virtuales.

containerd/cri habilita la siguiente matriz de compatibilidad para los pods:

Sistema operativo host	SO de contenedor	Aislamiento	¿Compatibilidad con pods?
Windows Server 2019/1809 Windows 10 1809	Linux	hyperv	Sí; admite pods de varios contenedores verdaderos.
	Windows Server 2019/1809	process* o bien hyperv	Sí; admite pods de varios contenedores verdaderos si cada SO de contenedor de cargas de trabajo coincide con el SO de la VM.
	Windows Server 2016, Windows Server 1709, Windows Server 1803	hyperv	Parcial; admite espacios aislados de pods que pueden admitir un solo contenedor aislado de proceso por VM de utilidad si el SO de contenedor coincide con el sistema operativo de la VM de utilidad.

* Los hosts de Windows 10 solo admiten el aislamiento de Hyper-V.

Vínculos a la especificación de CRI:

• RunPodSandbox: especificación de pods
• CreateContainer: especificación de cargas de trabajo

Si bien runHCS y containerd se pueden usar en cualquier sistema de Windows Server 2016 o posterior, la compatibilidad de los pods (grupos de contenedores) exigieron cambios importantes en las herramientas de contenedor de Windows. La compatibilidad con CRI está disponible en Windows Server 2019/Windows 10 1809 y versiones posteriores.