Si treballeu amb contenidors, tard o d'hora et toca la part menys glamurosa: desplegar un contenidor Docker en un servidor remot sense que tot sigui un caos d'ordres, ports, certificats i scripts. La bona notícia és que l'ecosistema Docker (Plesk, remot Docker Engine, Docker Desktop amb WSL2, Portainer, GitHub Actions, etc.) ja té gairebé tots els problemes típics resolts, només cal encaixar-los amb cap.
En aquest article veuràs, amb força detall, com funcionen els diferents escenaris per utilitzar Docker remotament : des d'usar un servidor Linux o Windows com a “màquina de build” o node d'execució, fins a administrar-lo des de Plesk, VS Code o fins i tot automatitzant desplegaments amb docker-compose i CI/CD. La idea és que puguis replicar tot el flux: construir, pujar, executar, exposar ports, gestionar volums i controlar contenidors sense tenir Docker corrent directament a la teva màquina principal.
Requisits i compatibilitat per utilitzar Docker en servidors remots
Abans de ficar-se a desplegar res, cal tenir clar on es pot executar Docker de manera suportada i amb quines limitacions. En entorns tipus Plesk, per exemple, hi ha requisits molt concrets de sistema operatiu i arquitectura.
Plesk suporta Docker en una llista tancada de sistemes Linux moderns: CentOS 7, Red Hat Enterprise Linux 7, Debian 10/11/12, Ubuntu 18.04/20.04/22.04/24.04, AlmaLinux 8.x/9.x, Rocky Linux 8.x i també en Rocky Linux 8.x i també 1 (7.0.1-686). Un punt clau: Docker a Plesk només funciona en sistemes x64 , així que si estàs en arquitectures rares o de 32 bits, oblida't.
Hi ha un detall important que sol passar desapercebut: no es pot fer servir Docker si Plesk està desplegat dins d'un contenidor Docker . És a dir, Plesk ha d'executar-se sobre un amfitrió “real” (físic o virtual) per poder manejar contenidors, no al revés. A més, a Virtuozzo 7 els contenidors basats en CentOS 7 vénen amb firewall activat per defecte, cosa que obliga l'administrador de Plesk a configurar manualment les regles de firewall per obrir els ports que necessita Plesk i els que faran servir els contenidors.
Al món Windows la pel·lícula és diferent. Amb Plesk per a Windows pots utilitzar Docker instal·lat en una màquina remota , sense tenir Docker al propi servidor on corre Plesk. Per això, cal recórrer als serveis remots de Docker i, molt important, disposar d'una llicència addicional (Docker remot s'inclou en packs com Hosting Pack, Power Pack o Developer Pack, o es compra a part). Això permet mantenir Windows “net” i centralitzar contenidors en un altre node.
Un últim matís sobre compatibilitat: els contenidors Docker gestionats des de Plesk no es poden migrar ni clonar directament , encara que sí que pots donar suport a les dades que usen a través de volums o instantànies. Així que l'estratègia habitual és dades persistents mitjançant volums, imatge reproduïble i, si cal, snapshot per a estats puntuals.
Instal·lació i desplegament d'un servidor amb Docker llest per a remot
La base de qualsevol desplegament remot és tenir un servidor amb Docker correctament instal·lat i configurat . Pots anar per la via clàssica (instal·lar Docker CE en un Ubuntu, Debian, etc.) o fer servir solucions que ja vénen preempaquetades amb Docker.
A plataformes tipus Cloudbuilder, per exemple, crear un servidor amb Docker preinstal·lat és bàsicament un tràmit al panell: tries una imatge de servidor que ja porta Docker a la pestanya “Aplicacions”, la selecciones a l'assistent d'alta i, en uns minuts, tens un host llest per rebre contenidors. Si no apareix a la primera, podeu cercar “Docker” al cercador d'imatges i seleccionar l'aplicació.
Si el que vols és un escenari més avançat, especialment quan treballes amb Windows Server Containers i Kubernetes (AKS/EKS/GKE) , pots muntar la teva pròpia màquina de build remota amb Docker Engine. Al Windows Server 2019, per exemple, el mateix sistema ja inclou llicència de Docker Engine Enterprise , i pots instal·lar-lo via PowerShell usant el proveïdor DockerMsftProvider i la característica Containers. Aquest enfocament és ideal si el teu portàtil va just de recursos o si necessites process isolation en lloc de Hyper-V isolation , una cosa habitual quan vols que les teves imatges coincideixin amb els nodes Windows de Kubernetes.
El flux general seria: aixeques un Windows Server 2019 amb la build adequada (millor en mode Server Core per estalviar recursos), instal·les Docker Engine Enterprise, i després el configures per acceptar connexions remotes segures per TLS , de manera que puguis construir imatges i executar contenidors des del teu equip local o des d'un pipeline, sense tocar directament aquest servidor.
Cerca, selecció i gestió d'imatges a Docker (local i remot)
Un cop tens un host amb Docker, el següent pas és gestionar les imatges que utilitzaràs per als teus contenidors . Aquí entren en joc tant el dipòsit local del host com Docker Hub o altres registres.
En interfícies com Plesk, podeu utilitzar el quadre de cerca per localitzar imatges . El sistema cerca en els repositoris habilitats, que solen ser el repositori local (imatges ja descarregades i emmagatzemades al servidor amb Docker) i Docker Hub . Si una imatge ja està en local, veuràs indicacions tipus “(local)” al costat de la versió; si no, es descarregarà des del registre remot.
És habitual que una mateixa aplicació tingui múltiples versions etiquetades . Per llançar una versió concreta només cal seleccionar l'etiqueta adequada en executar el contenidor. Des de Plesk, en triar una imatge, pots escollir la “Versió de la imatge” en un menú desplegable o, si no vols complicar-te, quedar-te amb la versió més recent. A més, des de la targeta de la imatge pots obrir la documentació i descripció a Docker Hub (excepte en imatges locals, on no s'aplica).
Amb el temps el repositori local es converteix en un calaix de sastre, així que és important netejar imatges en desús . Per exemple, des de Plesk podeu anar a la secció Docker > Imatges, cercar una imatge concreta, o fer clic a l'enllaç sota el nom d'un producte per veure totes les etiquetes locals i l'espai que ocupen. Des d'aquí selecciones les que ja no necessites i les elimines, alliberant disc al host.
Creació i configuració detallada de contenidors en un host remot
Quan executes un contenidor en un servidor remot, l'ideal és no quedar-te al simple docker run , sinó controlar-ne bé la configuració: memòria, ports, volums, variables d'entorn i polítiques d'arrencada.
En un panell com Plesk, el flux típic seria entrar a Docker > Contenidors > Executar contenidor , cercar la imatge, seleccionar la versió i, en passar al següent pas, ajustar-ne la configuració. Aquí és on defineixes, per exemple, les variables d'entorn , els ports que exposarà i els volums que muntarà. En prémer Executar, el contenidor es crearà i quedarà llistat a la pestanya Contenidors; des d'allà podeu obrir els vostres registres de consola per comprovar que esteu funcionant correctament.
Hi ha diverses opcions avançades que convé tenir controlades:
- Limitació de memòria: per defecte els contenidors Docker poden utilitzar tota la RAM disponible del host. Si no voleu que un contenidor s'endugui el servidor, activeu la casella de límit de memòria i definiu un valor en MB raonable per a la càrrega.
- Inici automàtic: si desactives “Inici automàtic després de reiniciar el sistema”, quan el host es reiniciï els teus contenidors no arrencaran sols i els llocs que en depenguin es quedaran caiguts fins que els llevants manualment. En entorns de producció sol ser bona idea mantenir l'autoarrencada activada.
- Assignació de ports: per defecte, l'opció d'assignació automàtica fa que el port intern del contenidor es mapegi a un port aleatori al host (per exemple, 32768). Si voleu tenir aquest port sota control, desactiva l'assignació automàtica i configura una “Assignació manual”. Si aquesta opció no apareix, normalment vol dir que la imatge no exposa ports.
- Seguretat de ports: en usar assignació manual, Docker sol vincular per defecte aquest port només a 127.0.0.1 (localhost), fent el servei inaccessible des d'Internet. Això és perfecte si posaràs un servidor intermediari invers davant o només necessites accés intern. Si desmarqueu l'opció que bloqueja l'accés extern, el port es vincularà a totes les interfícies i l'aplicació serà accessible des de fora usant una IP del host més el port triat.
La pestanya de configuració del contenidor també permet realitzar accions com canviar el nom del contenidor , ajustar variables d'entorn o mapeigs de volums, revisar registres i consum de recursos, recrear el contenidor amb una altra versió d'imatge, desar la configuració actual com una imatge nova, descarregar-te una instantània o eliminar completament el contenidor.
Gestió de dades persistents: volums i backups
Un dels punts crítics quan desplegues Docker en remot és com persistir dades sense lligar-les a la vida del contenidor. Aquí entren els volums de Docker, que actuen com a carpetes del host muntades dins del contenidor.
Un volum no és més que un directori del servidor host muntat al sistema de fitxers del contenidor . Això permet que les dades (bases de dades, fitxers pujats per usuaris, logs importants, etc.) segueixin aquí encara que paris o esborris el contenidor. D'aquesta manera, si necessiteu recrear el contenidor o canviar de versió de la imatge, les vostres dades romandran intactes.
A l'hora de configurar un volum has d'indicar, d'una banda, la ruta absoluta a l'amfitrió on viuran les dades (camp Host) i, de l'altra, la ruta absoluta dins del contenidor on l'aplicació espera trobar-les (camp Contenidor). Si necessiteu més d'un volum, simplement afegiu noves entrades. Convé, a més, revisar la documentació oficial de Docker per entendre bé les diferències entre volums gestionats per Docker i bind mounts sobre rutes del sistema.
Tingues present que, encara que Plesk o altres eines no permetin “migrar” el contenidor com a tal, els volums sí que poden copiar-se o recolzar-se com qualsevol carpeta del servidor, o fins i tot mitjançant snapshots de nivell de sistema de fitxers. Això fa que lestratègia de còpia de seguretat se centri en els volums i no tant en el contenidor en si, que és molt més fàcil de reconstruir.
Configuració de xarxa i proxy invers per a contenidors remots
Perquè una aplicació Docker desplegada en un servidor remot sigui accessible des de fora, no n'hi ha prou amb exposar ports al contenidor: cal coordinar ports del host, firewall i, en molts casos, un proxy invers com Nginx o Apache.
En entorns on utilitzeu, per exemple, Cloudbuilder, si la vostra aplicació escolta al port 3030 i teniu un mapatge 3030:3030 a docker-compose, haureu d' obrir aquest port a la política de tallafocs del servidor . Això es fa creant una regla personalitzada i associant-la al servidor. Un cop obert, podreu accedir a l'aplicació des del vostre navegador amb una URL del tipus https://IP_DEL_SERVIDOR:3030.
Si treballes amb Plesk i Nginx, és molt típic que es configurin regles de proxy invers per dirigir el trànsit HTTP estàndard (port 80 o 443) cap al port intern on escolta el contenidor. Aquestes regles s'implementen a la configuració del servidor web del domini, per exemple a /var/www/vhosts/system/$domain/conf/nginx.conf. D'aquesta manera pots servir una web continguda a Docker com si fos un lloc més al servidor, amb el seu domini, certificat TLS i altres, mentre el contenidor escolta en un port intern no exposat directament a Internet.
Aquestes configuracions solen funcionar bé fins i tot si el servidor està darrere de NAT , sempre que tinguis els ports del tallafocs i els mapatges de xarxa configurats de forma coherent. En escenaris complexos (diversos contenidors, diversos hosts, etc.) és habitual col·locar un proxy invers genèric que actuï de “router” HTTP i es comuniqui internament amb els diferents serveis Docker mitjançant els ports interns o una xarxa Docker dedicada.
Ús de Docker Compose per orquestrar desplegaments en servidors remots
Quan les aplicacions comencen a tenir més d'un servei (frontend, backend, base de dades, memòria cau, etc.), treballar només amb docker run es torna incòmode. Aquí entra Docker Compose, que et permet definir una pila completa de serveis en un únic fitxer i aixecar-la d'una vegada al servidor remot.
Un exemple típic senzill seria una aplicació NodeJS amb Express. Primer crees el teu projecte (per exemple en una carpeta “app”), inicialitzes amb npm init, instal·les exprés amb npm install express i escrius un index.js que aixequi el servidor al port 3030. Un cop tinguis l'app funcionant localment amb node index, arriba el moment de dockeritzar.
Per això crees un Dockerfile, per exemple a “app/Dockerfile”, on defineixes la base (per exemple FROM node:12), El DIR. TREBALL, copies el codi, executes npm install i exposes el port 3030. És bona idea afegir un .dockerignore per evitar pujar carpetes pesades com node_modules al context de build.
Després defineixes un fitxer docker-compose.yml a l'arrel del projecte, on descrius els serveis. En una app senzilleta podries tenir alguna cosa com un servei “express” que fa build sobre ./app , mapeja el port 3030:3030 i defineix l'ordre d'inici. En projectes més seriosos s'afegeixen també contenidors per al frontend , el backend , la base de dades (per exemple MongoDB) i qualsevol altre component, cadascun amb la seva pròpia configuració de volums, xarxes i variables.
Per desplegar aquesta pila en un servidor remot, és habitual:
- Connectar-te per SSH al servidor que ja té Docker instal·lat.
- Clonar el repositori amb el projecte (o pujar els fitxers per SCP, encara que git sol ser més còmode).
- Assegurar-te que el binari docker-compose està instal·lat, ja que en moltes distribucions no ve de sèrie amb Docker. A Linux, per exemple, pots descarregar-lo des de GitHub amb
curl, guardeu-lo a/usr/local/bin/docker-composei marcar-ho com a executable. Convé revisar la pàgina oficial “Install Docker Compose” per veure la versió recomanada. - Des de la carpeta on és el
docker-compose.yml, executar docker-compose up (potser en mode-dperquè es quedi en segon pla). La primera execució trigarà més, perquè haurà de descarregar imatges i resoldre dependències; les següents seran molt més ràpides.
En panells com Plesk també pots desplegar piles Docker Compose sense llençar directament de SSH. Des de Docker > Piles > Afegir pila pots donar-li un nom de projecte i triar si vols enganxar el contingut del fitxer Compose en un editor, pujar-lo des de la teva màquina o seleccionar un fitxer ja present a l'espai web d'un domini. La pila s'encarregarà de declarar i crear contenidors personalitzats, els artefactes dels quals s'emmagatzemaran al directori principal del lloc web.
Desplegaments remots automatitzats amb GitHub Actions i docker-compose
Si treballes amb CI/CD, el més lògic és que vulguis automatitzar el desplegament dels teus contenidors en un servidor remot cada vegada que facis push a certes branques (per exemple, development o main). Docker Compose encaixa molt bé en aquest tipus de flux.
Un patró força habitual és que el teu workflow de GitHub Actions es connecti per SSH al servidor Ubuntu remot. Fins ara, molts fan alguna cosa així: descarregar imatges de Docker Hub, parar i esborrar contenidors en execució i després llançar docker run per a cadascú . En migrar a docker-compose, el workflow es pot simplificar força.
El plantejament més directe és que, una vegada establerta la connexió SSH, el job faci un cd al repositori al servidor (o al directori on tinguis el teu docker-compose.yml) i executeu les ordres de docker-compose que necessitis, per exemple docker-compose pull per actualitzar imatges i docker-compose up -d --remove-orphans per recrear els serveis segons els canvis al fitxer Compose.
És una estratègia perfectament vàlida i, per a molts projectes, més que suficient i força robusta . La clau és assegurar-te que el servidor remot té els binaris de Docker i docker-compose correctament instal·lats, i que l'usuari que es connecta per SSH té permisos per executar aquestes ordres (sovint pertinença al grup docker o sudoers configurat adequadament). Des del punt de vista de GitHub Actions, la resta és només qüestió de fer servir una acció de SSH fiable i gestionar els teus secrets (IP del servidor, usuari, clau privada, etc.) mitjançant els secrets del repositori.
Docker remot des de Windows sense Hyper-V: WSL2, Docker Engine remot i Portainer
Si ets a Windows i no pots o no vols activar Hyper-V (per exemple, perquè xoca amb altres eines de virtualització), tens diverses maneres d' usar contenidors allotjats en un altre servidor com si fossin locals , a l'estil del que ofereix LXD.
Una opció és donar suport a Docker Desktop amb backend WSL2 . Si podeu utilitzar WSL2 (Windows Subsystem for Linux v2) però no Hyper-V clàssic, Docker Desktop us permet muntar un entorn de desenvolupament basat en Linux on els contenidors s'executen en una distro WSL2 (Ubuntu, per exemple), i tu operes des de Windows. El flux típic és:
- Instal·lar WSL2 i una distribució Linux (Ubuntu 22.04, 24.04, etc.).
- Instal·lar Docker Desktop i, a la configuració, activar el motor basat en WSL2 a la secció General.
- Triar a “WSL Integration” les distros WSL2 on vols integrar Docker.
- Des de la distro, comprovar
docker --versioni provar ambdocker run hello-world.
A partir d'aquí pots treballar amb VS Code usant les extensions WSL, Dev Containers i Docker per desenvolupar directament a contenidors remots (en realitat, allotjats a WSL2), obrint carpetes en contenidor, depurant, etc. És molt còmode per a desenvolupament, encara que no és exactament el mateix que apuntar a un servidor remot extern.
Si el que vols és fer servir un Docker Engine remot de veritat, allotjat en un altre servidor (Linux o Windows Server), podeu configurar-lo per acceptar connexions TLS per TCP (típicament al port 2376). Per això generes certificats X.509 (CA, certificat de servidor i de client), configures el daemon.json del servidor per habilitar TLS, especificar rutes als certificats i obrir el host TCP on escoltarà el dimoni. Després, al client, instal·les els certificats a ~/.docker (o al perfil de l'usuari del Windows) i configures variables d'entorn com DOCKER_HOST y DOCKER_TLS_VERIFY o, en versions més recents, crees un docker context apuntant a aquest host remot. Un cop actives aquest context, qualsevol ordre docker que llancis a la teva màquina local s'executa realment contra el servidor remot.
Una altra eina molt útil en aquest escenari és Portainer, que proporciona una interfície web per administrar contenidors Docker en un o diversos servidors. Per instal·lar-lo, crees primer un volum de dades per a Portainer i després arrenques el seu contenidor, mapejant els ports 8000 i 9000, i muntant el /var/run/docker.sock que us permet parlar amb el dimoni Docker del host. A partir d'aquí entres pel port 9000 (recordeu-vos d'obrir-lo al firewall), creeu un usuari administrador i configureu connexions tant locals com remotes. Portainer pot comunicar amb altres nodes Docker usant la Docker API o mitjançant el Portainer Agent, cosa que et permet gestionar múltiples hosts Docker des d'una única consola web.
Configuració avançada de Docker Engine remot amb TLS i contexts
Quan vols que la teva màquina de desenvolupament faci servir un servidor remot com a motor Docker principal, és recomanable protegir aquesta comunicació amb TLS i no deixar el dimoni obert al boig per TCP. Això implica treballar amb certificats X.509 i ajustament fi tant al servidor com al client.
En un Windows Server amb Docker Engine, per exemple, pots automatitzar la generació de certificats amb un script de PowerShell que instal·la openssl, crea una CA, emet un certificat de servidor amb subjectAltName que inclogui el DNS i les IPs necessàries (pública, interna i localhost), i també genera certificats de client per a autenticació mútua. Els fitxers resultants (normalment ca.pem, server-cert.pem, server-key.pem, cert.pem y key.pem) es col·loquen en una carpeta accessible, per exemple C:\ProgramData\docker\config\.
A l'arxiu daemon.json del servidor configures claus com tls: true, tlsverify: true, tlscacert, tlscert, tlskey i la llista de hosts, incloent un tcp://0.0.0.0:2376 al costat del named pipe nadiu de Windows. Reinicieu el servei Docker i comproveu que tot segueix funcionant. Recordeu que el port estàndard xifrat és el 2376, mentre que el 2375 es reserva per a connexions sense xifrar (molt desaconsellables cap a Internet).
Finalment, a la màquina client copies els certificats al teu directori Docker (~/.docker o similar) i configures bé sigui les variables d'entorn (DOCKER_HOST, DOCKER_TLS_VERIFY) o un context amb docker context create, on indiques host, CA, cert i key. Un cop actiu el context remot, quan executes docker version veuràs que el client i el servidor tenen versions i arquitectures diferents (per exemple, client linux/amd64 i servidor windows/amd64 amb Docker Engine Enterprise), però les teves ordres s'apliquen al host remot com si estiguessin en local.
Si en el passat vas fer servir previews de Docker per a WSL, pot ser que tinguis contextos antics com “wsl” que ja no es fan servir. Pots comprovar-ho amb docker context ls i, si cal, eliminar els contextos obsolets amb docker context rm per evitar errors de connexió amb pipes antics.
En conjunt, tota aquesta sopa de peces (Plesk, Docker Engine remot, Docker Desktop amb WSL2, docker-compose, Portainer i GitHub Actions) et permet muntar fluxos en què construeixes i desplegas contenidors en servidors remots de forma segura, replicable i relativament còmoda , separant recursos de desenvolupament, no separant recursos de desenvolupament, no convingui en cada cas. Comparteix la guia i més usuaris coneixeran sobre el contenidor Docker.