Introducción

En capítulos anteriores, hemos estado trabajando mucho con comandos de Docker para trabajar con imágenes de Docker, contenedores, volúmenes y redes. Una de las características destacadas de Docker es la increíble experiencia del usuario que proporciona a través de sus comandos fáciles de recordar y bien estructurados. Con un solo comando de Docker, podemos crear un contenedor de microservicio o utilidad muy útil. Sin embargo, detrás de escena, el cliente de Docker traduce nuestra solicitud en múltiples llamadas a la API para cumplirla. Estas API se llaman API del motor de Docker, y están diseñadas utilizando el paradigma REST.

La API del motor de Docker está documentada utilizando la especificación OpenAPI (anteriormente conocida como Swagger ). Como resultado, podemos acceder a la ayuda de la API a través de cualquier editor de OpenAPI estándar. En este libro, estamos utilizando un editor llamado Swagger Editor, y está disponible en http://editor.swagger.io; sin embargo, puedes utilizar cualquier editor de OpenAPI de tu elección. Swagger Editor tiene opciones como Probar y Ejecutar, que se pueden utilizar para generar comandos curl con opciones adecuadas. La siguiente captura de pantalla muestra Swagger Editor con el documento de la API del motor de Docker:

Aquí, generamos el documento de la API del motor de Docker a partir del archivo swagger.yaml disponible en https://docs.docker.com/engine/api/v1.35/swagger.yaml. Por supuesto, también puedes consultar la versión actual y en proceso de trabajo de la API en https://raw.githubusercontent.com/moby/moby/master/api/swagger.yaml.

De forma predeterminada, el motor de Docker escucha en /var/run/docker.sock, un socket de dominio de Unix, para comunicarse con su cliente. El socket de dominio de Unix, también conocido como socket de comunicación entre procesos, permite una comunicación confiable dentro de un host. Además, /var/run/docker.sock tiene acceso de lectura y escritura para el usuario root y el grupo docker; por lo tanto, la aplicación del cliente debe tener privilegios de root o ser miembro del grupo docker. Además del socket de Unix, el demonio de Docker admite dos tipos de sockets más:

• fd : Activación de socket de Systemd. En sistemas basados en Systemd como Ubuntu 16.04, el demonio de Docker escucha en el socket fd, que se mapea internamente al socket de Unix /var/run/docker.sock utilizando la función de activación de socket de Systemd.

• tcp : Para conectividad remota. En la receta Configuración del demonio de Docker para conectividad remota, configuraremos el demonio de Docker para aceptar comunicación no cifrada desde el cliente, y en la receta Seguridad de la conectividad remota del demonio de Docker, configuraremos el demonio de Docker para utilizar comunicación segura.

Docker también proporciona Kit de Desarrollo de Software ( SDK ) para los lenguajes de programación Python y Go. Estos SDK utilizan internamente las API de REST del motor de Docker. Además de estos SDK estándar, hay muchas bibliotecas de API de soporte comunitario para otros lenguajes de programación. Algunas de estas bibliotecas de API se enumeran en https://docs.docker.com/develop/sdk/#unofficial-libraries. Sin embargo, estas bibliotecas no son probadas por Docker.

A lo largo de este capítulo, utilizaremos dos herramientas, curl y jq:

• curl es una herramienta de línea de comandos para transferir datos. Utilizamos curl para conectarnos a nuestro demonio de Docker. Asegúrate de estar ejecutando curl 7.40 o superior, porque curl comenzó a admitir sockets de Unix desde la versión 7.40. Puedes encontrar más detalles sobre curl en el sitio web oficial en https://curl.haxx.se/.

• jq es una herramienta de línea de comandos para procesar datos JSON. Utilizamos jq para manipular los datos que recibimos del demonio de Docker. Puedes encontrar más detalles sobre jq en el sitio web oficial en https://stedolan.github.io/jq/.

Todas las recetas de este capítulo asumen que Docker está instalado y en ejecución.