Cum se implementează un container Docker pe un server la distanță

Dacă ești nou în Docker și te chinui să implementezi containerele pe un server la distanță , nu-ți face griji: este o întrebare foarte frecventă. Între Docker, Docker Compose, implementări SSH , GitHub Actions, Plesk, Docker Desktop, Portainer... numărul mare de opțiuni poate fi copleșitor, mai ales dacă ești obișnuit să rulezi totul manual cu câteva comenzi `docker run` pe mașina locală.

În acest articol, vă vom prezenta, pas cu pas, diferitele modalități de a rula containere Docker pe servere Linux sau Windows la distanță , cum să automatizați implementarea cu Docker Compose și CI/CD și ce alternative aveți dacă computerul dvs. nu are suficientă putere și preferați să lăsați cloud-ul să se ocupe de toată procesarea. De asemenea, veți vedea exemple complete cu Node.js, aplicații web și chiar medii grafice la distanță, într-un container accesibil dintr-un browser.

Concepte de bază: containere locale vs. containere la distanță

Înainte de a trece la treabă, este important să înțelegem că un container Docker rulează întotdeauna acolo unde se află motorul Docker : dacă serverul tău la distanță are Docker instalat, containerele tale vor rula acolo; laptopul tău va acționa doar ca client pentru a trimite imagini și comenzi (prin SSH, API-ul Docker sau instrumente precum GitHub Actions, Plesk sau Portainer).

Din perspectiva resurselor, exact asta cauți dacă ai o mașină cu putere redusă: poți dezvolta cod ușor local și rula containerele „grele” pe un server la distanță , care oferă procesorul, memoria RAM și spațiul pe disc. Mașina ta are nevoie doar de un client Docker, un browser și, dacă dorești, un editor precum VS Code.

Această diagramă evidențiază un element cheie: modul în care vă conectați la motorul Docker de la distanță . Există mai multe posibilități: accesarea serverului prin SSH și rularea comenzilor acolo, expunerea API-ului TCP al Docker (cu TLS) pentru administrare de la distanță, utilizarea tablourilor de bord precum Plesk, utilizarea Portainer sau valorificarea fluxurilor de lucru CI/CD precum GitHub Actions pentru a iniția implementarea.

De la rulare Docker la Docker Compose pe un server la distanță

Un scenariu foarte tipic este acesta: aveți o aplicație pe care o implementați cu mai multe comenzi `docker run` pe un server Ubuntu la distanță, iar acum ați trecut la Docker Compose pentru a defini toate serviciile într-un singur fișier. Fluxul de lucru este de obicei simplu: de fiecare dată când faceți push către ramura de dezvoltare de pe GitHub, se lansează o acțiune GitHub care se conectează prin SSH la server, curăță containerele vechi și pornește cele noi.

Modelul manual clasic este de obicei cam așa: conexiune SSH la server, descărcarea imaginilor din Docker Hub, oprirea și eliminarea containerelor vechi și pornirea de containere noi cu porturile corespunzătoare pentru ca Nginx să transmită traficul proxy. Funcționează, dar devine greoi pe măsură ce aplicația crește.

Cu Docker Compose abordarea nu se schimbă prea mult, dar este simplificată: în mod ideal, fișierul docker-compose.yml este live pe server (sau clonează depozitul acolo) și, după ce faci cd în directorul proiectului, lansează docker compose pull y docker compose up -d --remove-orphansAceasta înlocuiește întregul dans al docker alerga și asigură că întreaga stivă este recreată în mod consecvent.

Pentru a automatiza acest lucru cu GitHub Actions, un flux foarte rezonabil este ca fluxul de lucru să utilizeze o acțiune de SSH la distanță (sau configurați un runner auto-găzduit chiar pe server) și rulați comenzile Compose acolo. Dacă ați versionat atât codul, cât și serverul în sine. docker-compose.yml, tot ce ai nevoie este unul git trageți pe server, urmată de comenzile Compose pentru a implementa noua versiune.

Creați un server la distanță cu Docker gata de implementare

Primul pas pentru a lucra cu containere la distanță este să aveți un server (fizic, VPS sau cloud) cu Docker instalat . Mulți furnizori vă permit să implementați direct imagini cu Docker preinstalat, astfel încât în ​​câteva minute aveți o mașină cu daemonul gata să primească containere.

Dacă începeți cu o mașină virtuală curată, procesul obișnuit în Linux este să instalați motorul Docker și apoi, Instalați Docker Compose (În unele distribuții face parte din pachet; în altele trebuie să descărcați fișierul binar). Pe sisteme precum Debian sau Ubuntu puteți utiliza un curl la binarul oficial și acordați-i permisiuni de execuție:

sudo curl -L 'https://github.com/docker/compose/releases/download/1.26.2/docker-compose-$(uname -s)-$(uname -m)' -o /usr/local/bin/docker-compose

sudo chmod + x / usr / local / bin / docker-compose

De aici, cu daemonul Docker rulând, puteți clona depozitul sau încărca codul prin SCP/rsync și începe să rulați containerele de la distanță. Dacă furnizorul dvs. de găzduire are propriul firewall (firewall de platformă), verificați dacă porturile pe care le vor expune containerele dvs. sunt deschise.

Exemplu simplu: Dockerizarea unei aplicații Node.js și implementarea acesteia

Pentru a vedea mai clar, imaginați-vă o aplicație foarte simplă a Node.js cu ExpressPe mașina de dezvoltare, creați folderul proiectului și în cadrul acestuia un subfolder. appȘi de acolo începi proiectul npm init și instalați Express:

npm install express

Cel mai simplu cod dintr-un index.js Ar putea fi un mesaj de tip „salut lume” care ascultă pe portul 3030. Local, îl pornești cu node index și vedeți aplicația în https://localhost:3030Până acum, nimic nou.

Următorul pas este creați un fișier Dockerfile în folderul aplicației, unde definiți imaginea de bază (de exemplu, node:12), directorul de lucru, copiați codul în interiorul containerului, instalați dependențele și expuneți portul:

DE LA nodul:12 · DIRECTORLUCRARE /usr/src/app · ADĂUGAȚI . /usr/src/app · RULARE instalare npm · EXPOZE 3030

De asemenea, este recomandabil să se creeze un .dockerignore A evita nod_module și alte directoare mari sunt copiate în imagine. Odată ce imaginea este definită, o puteți construi și testa local cu docker build y docker run înainte de a accesa serverul la distanță.

Orchestrarea mai multor servicii cu Docker Compose

Când aplicația ta nu mai este doar un backend Node, ci include frontend, API, bază de date și eventual servicii auxiliareÎn mod normal, toate sunt definite într-un singur fișier. docker-compose.yml la baza proiectului. Chiar dacă exemplul tău real folosește un singur container, înțelegerea Compose ca instrument de orchestrare deschide calea către designuri mai complete.

Un exemplu minimal de „hello world” din Compose pentru Express ar putea arăta cam așa: versiunea de Compose este specificată, un serviciu numit expres care este construit din folder ./appPortul intern 3030 este mapat la portul extern 3030, iar comanda de boot este specificată:

versiune: '3.8' · servicii: · express: · build: ./app · porturi: – '3030:3030' · comandă: index de nod

Această definiție este transferată ca atare către serverul la distanță. După ce aveți proiectul pe mașină (clonat din Git sau copiat manual), instalați pur și simplu docker-compose, navigați la folderul proiectului și lansați :

docker-compune-te

Prima dată va dura mai mult deoarece imaginea de bază Node și dependențele npm sunt descărcate. De atunci încolo, orice implementare viitoare este la fel de simplă ca ` docker-compose up -d --build` pentru a recrea serviciile fără a întrerupe aplicația prea mult timp.

Expunerea aplicației: porturi, firewall și Nginx

Cu containerele care rulează pe serverul la distanță, totuși vă lipsește un detaliu important: asigurarea faptului că traficul extern ajunge la portul corect . Dacă aplicația dvs. ascultă pe portul 3030 și nu aveți un proxy invers, aveți nevoie ca serverul sau firewall-ul din cloud să permită conexiunile de intrare la acel port.

Mulți furnizori configurează politicile firewall la nivel de panou de control (de exemplu, în Cloudbuilder sau Virtuozzo), unde creați o regulă pentru a deschide portul 3030/TCP și a-l asocia cu serverul dvs. Pe serverele cu un firewall local (ufw, firewalld, iptables), va trebui să permiteți acel port specific sau, dacă utilizați Nginx și doriți să expuneți doar porturile 80/443, să configurați Nginx ca proxy invers către container.

Odată ce portul este deschis, puteți accesa aplicația la https://SERVER_IP:3030 . În medii mai complexe, Nginx sau Apache acționează de obicei ca un proxy invers pe portul 80/443 și redirecționează traficul către containerele interne (intern, acestea pot utiliza porturi înalte sau chiar rețele Docker personalizate).

Dacă gestionați serverul cu Plesk, o parte din această logică este integrată în instrumentul în sine: regulile proxy sunt definite în configurația Nginx a domeniului, de exemplu prin directive în nginx.conf Bajo /var/www/vhosts/system/$domain/conf/și Plesk se ocupă de asta cererile către domeniu sunt transmise către containerul corect.

Gestionați containerele la distanță cu Portainer

Pentru cei care preferă o interfață grafică, Portainer este o opțiune foarte interesantă. Este un panou web care rulează într-un container și se conectează la daemonul Docker (local sau la distanță) pentru a afișa containere, imagini, stive, volume și așa mai departe, într-un mod foarte vizual.

Instalarea de bază pe serverul dvs. implică mai întâi crearea unui volum pentru datele Portainer, apoi rularea containerului, expunerea porturilor 8000 și 9000 și montarea socketului Docker:

docker volume create portainer_data

docker run -d -p 8000:8000 -p 9000:9000 –name=portainer –restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

După aceea, panoul devine disponibil pe portul 9000 al serverului. Îl accesezi cu browserul tău, creezi utilizatorul administrator pentru prima dată, apoi poți gestiona containere locale sau adăuga noduri la distanță (folosind API-ul Docker sau Agentul Portainer) pentru a centraliza administrarea mai multor servere.

Odată configurat, puteți vedea dintr-o privire ce containere rulează, puteți revizui jurnalele , resursele consumate sau puteți crea stive folosind fișiere Docker Compose fără a atinge linia de comandă.

Utilizarea Docker de la distanță cu Plesk

Dacă utilizați Plesk în loc să gestionați direct serverul, aveți o altă modalitate de a gestiona containerele Docker fără a părăsi panoul de control . Plesk acceptă Docker pe mai multe distribuții Linux (CentOS 7, RHEL 7, Debian 10/11/12, Ubuntu 18.04/20.04/22.04/24.04, AlmaLinux 8/9, Rocky 8 etc.) și acceptă, de asemenea, accesul de la distanță la Docker din Plesk pentru Windows , cu condiția să aveți licența corespunzătoare.

Din secțiunea Docker a panoului, puteți căuta imagini atât în ​​depozitul local al mașinii, cât și în Docker Hub , puteți selecta versiunea specifică folosind etichete și puteți lansa containere cu configurația de care aveți nevoie: variabile de mediu, limite de memorie, atribuiri de porturi și volume, politică de repornire etc.

În mod implicit, Plesk poate atribui automat porturi , legând portul intern al containerului la un port aleatoriu de pe gazdă (de exemplu, 32768) și restricționând accesul la localhost pentru a-l păstra ascuns de internet. Dacă debifați opțiunea „Port inaccesibil de pe internet”, Docker expune acel port pe toate interfețele gazdei, făcând aplicația accesibilă din exterior.

Panoul vă permite, de asemenea, să montați directoare de server în cadrul containerului (volumelor) pentru a obține o stocare persistentă care supraviețuiește recreării containerelor. În mod similar, puteți ajusta variabilele de mediu, redenumi containerele, le puteți recrea cu o versiune de imagine diferită, salva starea curentă ca o imagine nouă sau chiar descărca o imagine instant.

Pe lângă containerele individuale, Plesk acceptă stivele Docker Compose : puteți accesa Docker > Stacks > Add Stack, puteți da un nume de proiect și puteți alege dacă doriți să lipiți conținutul fișierului Compose, să îl încărcați de pe computer sau să îl selectați din spațiul web al unui domeniu. De acolo, Plesk se ocupă de crearea și gestionarea întregii stive, direct din cutie.

Servicii Docker la distanță și schimbarea contextului cu Plesk

Plesk nu numai că pornește containere pe serverul propriu-zis, dar se poate conecta și la motoare Docker la distanță . Pentru a face acest lucru, trebuie mai întâi să configurați daemonul la distanță conform documentației oficiale Docker, deschizând API-ul TCP și securându-l cu certificate TLS.

Procesul tipic pe o gazdă la distanță implică crearea unui fișier /etc/docker/daemon.json cu configurația corectă, Generați certificate .pem pentru server și clientși modificați serviciul Docker pentru a porni numai după finalizarea configurării rețelei. Apoi exportați certificatele pe mașina pe care rulează Plesk.

Pe serverul Plesk, accesați Docker > Environments și adăugați un nou server la distanță introducând detaliile conexiunii și certificatele. Îl puteți marca ca activ, astfel încât toate operațiunile Docker din tabloul de bord să fie efectuate pe acel nod . Comutarea între serviciile Docker este la fel de simplă ca selectarea acestuia din lista de medii și efectuarea unui clic pe „Setare ca activ”.

Din secțiunea de imagini, Plesk vă permite să vizualizați toate imaginile locale ale acelui Docker la distanță, să le filtrați, să vedeți etichetele disponibile, spațiul pe disc utilizat și șterge-le pe cele de care nu ai nevoie Cu un singur clic. Este o modalitate convenabilă de a curăța fără a fi nevoie să vă amintiți toate opțiunile. docker image prune și companie

Dezvoltare cu Docker Desktop, WSL 2 și containere la distanță

În mediile Windows moderne, este foarte comun să se utilizeze Docker Desktop cu WSL 2 pentru a avea un motor Docker complet integrat bazat pe Linux. Docker Desktop vă permite să rulați containere Windows și Linux pe aceeași mașină și permite integrarea cu diversele distribuții WSL pe care le aveți instalate (Ubuntu, Debian etc.).

După instalarea WSL 2 și Docker Desktop, în configurație activați motor bazat pe WSL 2 și alegi ce distribuții au integrare Docker. Dintr-o terminal Puteți verifica versiunea cu WSL. docker --version și testați dacă totul funcționează lansând imaginea de test:

docker alerga hello-lume

Această configurație este ideală dacă doriți să dezvoltați local folosind VS Code și, în același timp, să implementați pe servere la distanță . Datorită extensiilor WSL, Dev Containers și Docker pentru VS Code, puteți deschide proiectul într-un container de dezvoltare, puteți compila imagini, depana și apoi puteți trimite acele imagini sau fișiere Composate către serverul la distanță, unde vor rula în producție.

VS Code și containere de dezvoltare la distanță

Cu VS Code și extensia Dev Containers puteți transforma orice proiect în un mediu de dezvoltare containerizatFluxul de lucru obișnuit este: clonează repozitoriul (în distribuția WSL, de exemplu), deschide folderul cu code . și alegeți „Redeschideți în container” pentru ca VS Code să genereze un folder .devcontainer cu ei Dockerfile y devcontainer.json.

Când containerul de dezvoltare pornește, VS Code se conectează la acesta și toate instrumentele (IntelliSense, depanare, terminal integrat) rulează în interiorul containerului respectiv. Puteți verifica acest lucru cu uname să vezi că ești încă pe Linux și cu python3 --version sau timpul de execuție pe care îl utilizați pentru a verifica versiuni specifice ale containerului.

De acolo puteți configura profiluri de execuție și depanare (de exemplu, pentru un proiect Django, Node sau orice alt proiect framework) folosind un launch.json în folder .vscodeApăsând F5, aplicația pornește în containerul de dezvoltare și o vedeți în browser, dar același cod și Dockerfile pot fi apoi folosite pentru a genera imaginea pe care o veți implementa pe serverul la distanță.

Avantajul acestei abordări este că minimizezi clasicul „funcționează pe mașina mea” : dacă dezvolți în interiorul unui container și apoi implementezi aceeași imagine (sau una foarte similară) pe server, diferențele de mediu sunt reduse la minimum.

Containere la distanță pentru aplicații grafice (noVNC, TigerVNC, Caddy)

Până acum am discutat despre servicii backend sau web tipice, dar este posibil și să rulați aplicații desktop complete într-un container și să le accesați dintr-un browser pe orice dispozitiv. Un exemplu foarte ilustrativ este împachetarea Mozilla Thunderbird într-un container care combină TigerVNC, noVNC și serverul web Caddy.

Ideea este ca containerul să includă un server X11/VNC (TigerVNC), un server noVNC pentru a expune sesiunea VNC ca WebSocket și un manager de procese precum supervisord care pornește și monitorizează toate componentele: serverul grafic, serverul noVNC, managerul de ferestre (OpenBox) și aplicația principală (Thunderbird).

În setări supervisord.conf Mai întâi, definiți blocul daemon global (astfel încât să ruleze în prim-plan și să înregistreze în jurnal pe stdout), apoi programe individuale: unul pentru serverul X11 cu Xtigervnc, altul pentru ascultarea easy-novnc pe portul 8080 și conectarea la VNC pe 5900, altul pentru Openbox ca manager de ferestre și un bloc final pentru lansare. /usr/bin/thunderbird cu variabila DISPLAY arătând spre afișajul :0.

OpenBox folosește propriul meniu rădăcină definit în menu.xmlAici creați intrări pentru a deschide Thunderbird, un terminal și htop. Acest meniu apare când faceți clic dreapta pe desktop în sesiunea grafică accesibilă prin intermediul unui browser.

Construirea imaginii: Dockerfile în mai multe etape și aplicație grafică

Pentru ca totul să se potrivească, o Dockerfile în mai multe etapeÎn prima fază, pe baza golang:1.14-busterFișierul binar easy-novnc este compilat din depozitul GitHub, specificând o anumită versiune pentru a asigura compilări deterministe. A doua fază începe cu debian:buster și instalați pachetele necesare: openbox, tigervnc-standalone-server, supervisor, gosu și diverse utilitare (terminal, nano, wget, openssh-client, rsync, ca-certificates, xdg-utils, htop, instrumente de compresie etc.).

Apoi instalați Thunderbird ca aplicație principalăCopiați fișierul binar easy-novnc din prima etapă în PATH și adăugați fișierele de configurare. menu.xml y supervisord.conf către sistemul de fișiere al imaginii. Portul 8080 este expus, acesta fiind punctul de intrare HTTP pentru sesiunea la distanță.

Pentru a evita rularea tuturor lucrurilor ca atare rădăcinăDockerfile-ul creează un utilizator aplicaţia Cu UID și GID 1000, pregătiți directorul /data, îl marchează ca VOLUME pentru a persista configurația aplicației și definește o comandă de boot CMD care ajustează permisiunile pentru /data y /dev/stdout și apoi rulați supervisord ca utilizator al aplicației folosind gosu.

Odată ce aceasta a fost construită, tot ce mai rămâne este să creați imaginea cu docker build -t thunderbird .o rețea Docker thunderbird-net, un volum thunderbird-data și lansați containerul cu o politică de repornire mereu activă, montând volumul în /data și conectarea acestuia la rețeaua respectivă. Containerul aplicație Thunderbird Rămâne pregătit și rulează în fundal.

Protejați accesul și expuneți fișierele cu Caddy și WebDAV

Pentru a evita expunerea interfeței noVNC fără niciun control, se creează un alt container bazat pe Caddy v2 cu modul WebDAVAcest al doilea container acționează ca un proxy invers către thunderbird-app:8080, solicită autentificare de bază și, de asemenea, servește conținutul /data prin HTTP și WebDAV pentru a accesa fișierele aplicației.

Dockerfile-ul lui Caddy este, de asemenea, în mai multe etape: mai întâi, compilează Caddy cu modulul caddy-webdav, apoi construiește o imagine minimalistă bazată pe Debian care include doar gosu și binarul Caddy. Caddyfile a /etc/CaddyfilePortul 8080 este expus și este creat un utilizator de aplicație similar cu cel din containerul anterior, care partajează și un volum. /data.

El Caddyfile definește un server pe portul 8080 care proxy de la root la thunderbird-app:8080, expune un browser de fișiere în /files și un punct final WebDAV în /webdavAmbele utilizează același director de date partajat. Autentificarea HTTP de bază utilizează un nume de utilizator și o parolă hashed, citite din variabilele de mediu APP_USERNAME și APP_PASSWORD_HASH.

Pentru a genera hash-ul parolei, se execută un container temporar Thunderbird-Caddy cu comanda caddy hash-password -plaintext 'mypass'Rezultatul este copiat, iar apoi containerul final Thunderbird-web este lansat cu docker run –env APP_USERNAME=»myuser» –env APP_PASSWORD_HASH=»mypass-hash», publicând portul 8080 pe gazdă.

Acces din browser și gestionarea fișierelor

Cu ambele containere rulând, puteți accesa http://SERVER_IP:8080 în browser , introduce numele de utilizator și parola și faceți clic pe „Conectare” în interfața noVNC. Veți vedea un desktop negru cu managerul de ferestre Openbox; dacă faceți clic dreapta, se va afișa meniul cu Thunderbird, Terminal și Htop.

Fereastra aplicației se redimensionează automat pentru a se potrivi browserului datorită setărilor de redimensionare de la distanță ale TigerVNC și funcției easy-novnc. Performanța este de obicei mai mult decât acceptabilă, chiar și pe dispozitive modeste precum Chromebook-urile, deoarece randarea se face direct pe server, nu pe client.

Dacă accesați http://SERVER_IP:8080/files/ veți vedea o listă de fișiere în directorul de date, iar dacă montați http://SERVER_IP:8080/webdav/ pe un client WebDAV compatibil, puteți citi și scrie direct în acel folder. Pe Windows, pentru a-l mapa ca unitate de rețea, va trebui să adăugați HTTPS folosind un proxy invers extern sau să ajustați registry-ul pentru a permite autentificarea de bază prin HTTP.

Frumusețea acestei configurații constă în faptul că poți repeta modelul cu orice aplicație grafică Linux : GIMP , medii de inginerie inversă precum Cutter sau chiar Wine pentru a rula aplicații Windows într-un container Linux cu acces de la distanță. Toate acestea valorifică puterea unui server la distanță, în timp ce pe propriul computer ai nevoie doar de un browser web.

Având în vedere toate cele de mai sus, imaginea implementării containerelor Docker pe servere la distanță este destul de clară: puteți utiliza SSH simplu și Docker Compose, vă puteți baza pe panouri precum Plesk sau Portainer, puteți utiliza fluxuri CI/CD cu GitHub Actions sau chiar puteți încapsula aplicații grafice complete accesibile prin web, toate acestea în timp ce descărcați sarcina de calcul către mașinile la distanță și lăsați mașina locală liberă pentru ceea ce face cel mai bine: dezvoltarea și orchestrarea, fără a-i consuma resursele.