Cómo y por qué usar un host Docker remoto: CloudSavvy IT

La docker El programa CLI es independiente del demonio de Docker que ejecuta los contenedores. Aunque ambos componentes generalmente se ejecutan en la computadora local, pueden ejecutarse docker comandos contra un host Docker remoto.

El uso de un host remoto puede resultar útil en algunos escenarios. Puede configurar una instalación de Docker Engine compartida para un pequeño equipo de desarrollo. Luego, cada desarrollador podría conectarse a los contenedores remotos con su propio docker exec mando.

Los hosts remotos suelen ser valiosos cuando no se utiliza un servidor potente. Si su computadora portátil funciona con lentitud o se está quedando sin almacenamiento, el uso de un host Docker dedicado en su red puede aumentar drásticamente el rendimiento. Sigues teniendo todas las comodidades del lugar docker CLI en su terminal.

Índice de contenidos
  1. Configuración de host remoto
  2. Conectarse al host remoto
  3. Mejorar la seguridad
  4. Creando contextos
  5. Desventajas de los hosts remotos
  6. Conclusión

Configuración de host remoto

Asegúrese de tener Docker instalado en el sistema que será su host remoto. Solo necesitas el docker-cli package en la máquina local, ya que no ejecutará Docker Engine.

Una nueva instalación de Docker proporciona un socket Unix de forma predeterminada. El acceso remoto requiere un socket TCP. Correr dockerd (el ejecutable del demonio de Docker) con la extensión -H bandera para definir los sockets a los que desea enlazar.

sudo dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

Este comando conectará Docker al puerto Unix predeterminado y al puerto 2375 en la dirección de bucle invertido de su máquina. Puede enlazar a sockets y direcciones IP adicionales repitiendo el archivo -H bandera.

Las banderas deben pasarse cada vez que corras dockerd. Si desea que persistan después del reinicio, cree un alias de shell o cambie la definición del servicio Docker. Así es como puede obtener este último con systemd, que la mayoría de las distribuciones de Linux utilizan para la gestión de servicios.

cambio /etc/systemd/system/docker.service.d/options.conf (o créelo si no existe). Encuentra el [Service] sección y editar el archivo ExecStart línea:

[Service]
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

Recarga tu systemd configuración para aplicar los cambios:

sudo systemctl daemon-reload

Si Docker ya se está ejecutando, use sudo systemctl restart docker para reiniciar el servicio. El demonio de Docker ahora se conectará al puerto TCP 2375 cada vez que se inicie. Asegúrese de que la configuración de su firewall permita el tráfico al puerto. Si esta usando ufw, correr ufw allow 2375 para abrir el puerto.

Conectarse al host remoto

La CLI de Docker usa la extensión DOCKER_HOST variable de entorno para determinar el host al que conectarse. Cuando la variable no está configurada, se usará el socket Unix del demonio local.

Puede usar un host remoto para un solo archivo docker comando prefijando el DOCKER_HOST variable:

DOCKER_HOST=tcp://192.168.0.1:2375 docker run httpd:latest -d

Esto iniciará un nuevo contenedor desde httpd:latest imagen usando el motor Docker en 192.168.0.1:2375.

Si va a ejecutar varios comandos en una sesión, exporte el archivo DOCKER_HOST variable en su caparazón:

export DOCKER_HOST=tcp://192.168.0.1:2375

docker run httpd:latest -d --name httpd
docker ps
docker rm httpd --force

Tu puedes hacer docker utilice siempre un host remoto configurando DOCKER_HOST globalmente en el archivo de configuración de shell. Así es como lo haría en Bash:

echo "export DOCKER_HOST=tcp://192.168.0.1:2375" >> ~/.bashrc

Ahora el DOCKER_HOST la variable de entorno se establecerá cada vez que se inicie el shell.

Mejorar la seguridad

El socket TCP básico no es seguro. Cualquiera que pueda acceder a su máquina a través de la red puede utilizar el zócalo de Docker para controlar sus contenedores.

Docker admite SSH en lugar de TCP. Esta suele ser una mejor opción si el host tiene un servidor SSH disponible. Evita que los usuarios no autenticados obtengan acceso. El uso de SSH no requiere ninguna configuración adicional. DOCKER_HOST le permite pasar una cadena de conexión SSH:

DOCKER_HOST=ssh://user@hostname docker run -d --name httpd

Alternativamente, puede usar enlaces SSH para vincular directamente el socket Docker Unix del host remoto a su máquina local:

ssh -L /var/run/docker.sock:/var/run/docker.sock

Ahora no es necesario utilizar DOCKER_HOST en absoluto. El mando a distancia docker.sock estará vinculado a su contraparte local. Docker lo detectará automáticamente como un socket Unix estándar.

Usar una de las soluciones basadas en SSH es la mejor manera de acercarse a la seguridad del demonio Docker. Estibador también es compatible con TLS si proporciona una autoridad de certificación y claves de servidor y cliente:

dockerd --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=0.0.0.0:2375

Los clientes ahora podrán conectarse en el puerto 2375 si presentan un certificado SSL válido en el que confíe la autoridad de certificación. ca.pem.

RELACIONADOS: ¿Qué es un archivo PEM y cómo se usa?

Creando contextos

Docker le permite configurar diferentes "contextos" para conectarse a diferentes hosts. Los contextos se pueden utilizar en lugar de DOCKER_HOST Variable ambiental. Facilitan el cambio entre varios hosts remotos.

docker context create --docker host=tcp://192.168.0.1:2375 --description remote
docker context create --docker host=unix:///var/run/docker.sock --description local

Estos comandos crean dos contextos diferentes, uno para su lugar docker.sock y uno para una conexión remota.

Puede cambiar entre contextos usando docker context use mando:

docker context use remote

# Container is started on "remote"
docker run httpd:-latest -d

docker context use local

# Lists containers running on "local"
docker ps

Los contextos son útiles cuando trabaja con varios hosts de Docker. Son menos molestos que la recuperación continua de archivos. DOCKER_HOST variable a medida que se mueve entre los hosts.

Desventajas de los hosts remotos

Observamos anteriormente que un host remoto puede mejorar el rendimiento de la compilación. Esta afirmación solo es cierta si la máquina que ejecuta Docker Engine es más rápida que su hardware local. El mayor inconveniente de un host remoto es la sobrecarga adicional de interactuar en la red. También se vuelve dependiente de la red: si pierde la conectividad, no podrá administrar sus contenedores.

Debe tener una conexión de red confiable de alta velocidad si tiene la intención de utilizar un host remoto como servidor de compilación principal. El primero docker build stage envía el contenido del contexto de construcción de la imagen (generalmente el directorio de trabajo) a Docker Engine. Esto es rápido cuando Docker se ejecuta localmente, pero podría tardar mucho más en cargarse en una máquina remota.

Exponer una instancia de demonio de Docker en la red es un riesgo de seguridad. Debe asegurarse de que el acceso esté limitado a usuarios y dispositivos autorizados. La exposición involuntaria de un demonio de socket de Docker podría dar a los atacantes acceso ilimitado al host. Docker generalmente se ejecuta como root por lo tanto, es fundamental que solo las personas de confianza puedan iniciar los contenedores.

Conclusión

La configuración de un host Docker remoto le permite separar las instancias de contenedor de la máquina de desarrollo local. Un servidor de compilación de Docker dedicado puede ofrecer un rendimiento mejorado y más almacenamiento de imágenes.

Debe tener cuidado de verificar la seguridad de su implementación. Un socket TCP simple puede ser seguro en una red privada, pero no debe implementarse en ningún entorno sensible. El uso de SSH ayuda a mitigar los riesgos si practica una buena higiene de seguridad de SSH, como la autenticación obligatoria basada en claves.

Descubre más contenido

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Información básica sobre protección de datos Ver más

  • Responsable: Nelida Haydee Saldivia.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio. El Titular ha contratado los servicios de alojamiento web a KnownHost que actúa como encargado de tratamiento.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

Subir