Kako s pouzdanjem implementirati Docker kontejnere na udaljenim serverima

Početna » piton » Kako s pouzdanjem implementirati Docker kontejnere na udaljenim serverima

Ako ste tek naučili koristiti Docker i sada želite instalirati svoje kontejnere na udaljeni server, sasvim je normalno da se u početku osjećate pomalo izgubljeno. Odjednom morate kombinovati Docker, Docker Compose, SSH, CI/CD pipeline-e poput GitHub Actions-a, možda čak i kontrolne panele poput Pleska ili alate poput Portainera, a uz to i dalje držati Nginx, firewall-ove i volumene pod kontrolom.

Dobra vijest je da postoji vrlo jasan mentalni model i skup ponovljivih radnih procesa za implementaciju Dockerizovanih aplikacija na udaljene VPS servere sa vašeg laptopa. Kada jednom shvatite ove obrasce, nije bitno da li pokrećete implementacije iz GitHub Actions, Docker Desktopa, Pleska ili iz jednostavne SSH sesije: osnovni koncepti su uvijek isti.

Šira slika: kako obično izgledaju radni tokovi udaljenog implementacije Dockera

Na opštem nivou, postavljanje Docker kontejnera na udaljeni VPS se uvijek svodi na nekoliko ponavljajućih koraka. Pakujete svoju aplikaciju u kontejnere, šaljete kod ili slike na server, pokrećete te kontejnere (idealno s Docker Compose-om) i usmjeravate promet do njih putem nečega poput Nginx-a ili panela kao što je Plesk.

Vrlo tipičan početnički radni proces počinje jednostavnim SSH obrascem, često automatiziranim putem GitHub Actions ili nekog drugog CI sistema. Na primjer, pri svakom slanju na razvojnu granu, vaš CI pipeline se povezuje sa Ubuntu serverom preko SSH-a, povlači slike iz Docker Huba, zaustavlja i uklanja sve stare kontejnere, a zatim pokreće nove kontejnere sa... docker run, dok Nginx na serveru reverzno proxyira promet na prave kontejnerske portove.

Kada prelazite sa sirove hrane docker run Za Docker Compose, obrazac implementacije ostaje otprilike isti, ali postaje organizovaniji i ponovljiviji. Umjesto žongliranja s više naredbi za svaku uslugu, sve držite u jednoj docker-compose.yml datoteku i pokrenite docker compose up -d (ili docker-compose na starijim instalacijama) na udaljenom hostu kako bi se prikazao cijeli stek.

Glavna odluka koju morate donijeti je gdje i kako će se ta Compose datoteka izvršiti na udaljenom serveru. Najrobustnija opcija je obično držati repozitorij kloniran na VPS-u, imati CI/CD pipeline povezan sa serverom putem SSH-a, cd u taj repozitorij, a zatim tamo pokrenite naredbe Compose, tako da stanje implementacije postoji zajedno s vašim kodom.

Iz priručnika docker run na Docker Compose na udaljenom Ubuntu serveru

Ako vaš trenutni cjevovod samo povlači slike i pokreće ih sa docker runDocker Compose je vaše sljedeće veliko poboljšanje kvalitete života. Omogućava vam da opišete sve svoje servise, portove, volumene i varijable okruženja u jednoj datoteci, tako da ponovno pokretanje ili ažuriranje vašeg steka postaje jedna naredba, a ne krhki niz ručnih koraka.

Uobičajeni obrazac za početničku CI konfiguraciju izgleda ovako: tok rada GitHub Actions se pokreće prilikom slanja na development grana, povezuje se na vaš VPS putem SSH-a i tamo obavlja svu logiku implementacije. Unutar te SSH sesije, moguće je da će se slike preuzeti iz Docker Huba, zaustaviti i ukloniti svaki pokrenuti kontejner, a zatim pokrenuti nove sa sirovim Docker naredbama, dok je Nginx unaprijed konfiguriran za prosljeđivanje zahtjeva portovima kontejnera.

Nakon što usvojite Docker Compose, zapravo ne morate radikalno mijenjati CI tok, ali biste trebali promijeniti ono što se izvršava na serveru. Umjesto izdavanja nekoliko docker run komande, vaša akcija se može jednostavno pokrenuti docker compose pull (ako koristite slike registra) i docker compose up -d --remove-orphans od korijena vašeg projekta gdje docker-compose.yml živi.

Najlakši obrazac je obično: klonirajte isti repozitorij koji GitHub Actions koristi na Ubuntu server, a zatim pustite svoj radni tok putem SSH-a na taj host, cd u direktorij projekta i izvršite naredbe Compose. Ovo održava udaljeno stanje, konfiguraciju, datoteku za sastavljanje i sve datoteke okruženja sinhronizovanim sa vašim Git repozitorijem, a takođe znatno pojednostavljuje ručno otklanjanje grešaka prilikom implementacije putem SSH-a.

Postoje naprednije opcije poput pokretanja Docker-in-Docker-a unutar vašeg CI okruženja ili korištenja udaljenih Docker konteksta, ali za većinu malih i srednjih projekata obrazac "SSH na server + pokretanje Compose-a u repozitoriju" je više nego dovoljan. Jednostavno je za razumjeti, radi sa bilo kojim VPS provajderom i lijepo se slaže sa Nginxom ili bilo kojim drugim reverznim proxyjem koji je već pokrenut na mašini.

Dizajniranje Docker aplikacije i Compose steka za stvarni svijet

Prije nego što se brinete o implementaciji, potrebna vam je kontejnerizirana aplikacija koju zapravo ima smisla pokretati u produkciji. Jedan uobičajeni primjer je mali Node.js backend koji se poslužuje putem Expressa, ali isti obrazac funkcionira za bilo koji stek (Python, PHP, Go, Java, itd.).

Jednostavan način strukturiranja projekta je održavanje korijenske mape za cijeli stek i poddirektorija za stvarni kod aplikacije, na primjer mape pod nazivom app. unutra app inicijalizirate Node.js projekat sa npm init, instalirajte zavisnosti poput express i kreirajte svoju glavnu datoteku (na primjer index.js) koji sluša na datom portu kao što je 3030 i odgovara osnovnom porukom "Zdravo svijete".

Kada aplikacija radi lokalno (npr. node index i udaranje http://localhost:3030), možete ga pretvoriti u kontejner pisanjem Dockerfile u direktoriju aplikacije. Tipičan Dockerfile bi mogao odabrati osnovnu sliku čvora kao što je node:12, postavite radni direktorij kao što je /usr/src/app, kopirajte datoteke projekta, pokrenite npm install i otkriti luku 3030 prema van.

Da biste izbjegli nepotrebno prenaduvavanje slike, trebali biste dodati i .dockerignore datoteka za preskakanje mapa kao što je node_modules prilikom gradnje. Ovo smanjuje vrijeme izgradnje, sprječava curenje lokalnih artefakata u kontejner i proizvodi svjetlije slike koje je lakše prenijeti, povući i ponovo primijeniti.

Kada je to na mjestu, Docker Compose postaje alat koji sve spaja u koherentnu cjelinu. U korijenu vašeg projekta kreirate docker-compose.yml koji definira barem jednu uslugu (na primjer express), ukazuje na svoje build kontekst za ./app, mapira portove (kao 3030:3030) i postavlja command da biste pokrenuli svoju aplikaciju (npr. node index).

Proširenje na postavke s više kontejnera pomoću Docker Compose-a

Implementacije u stvarnom svijetu rijetko se sastoje od jednog kontejnera; gotovo uvijek ćete završiti s više servisa koji moraju međusobno komunicirati. Klasični obrazac je front-end kontejner, back-end API kontejner i baza podataka kao što je MongoDB ili PostgreSQL, sve orkestrirano pomoću Docker Compose-a.

U tim scenarijima, Compose postaje još vrijedniji jer garantuje da vaši servisi počinju sa ispravnim zavisnostima, mrežama i mapiranjem volumena. Na primjer, vaš docker-compose.yml moglo bi definirati frontend usluga, a backend usluga i a mongodb servis, a Compose automatski kreira internu mrežu tako da backend može pristupiti bazi podataka putem imena hosta mongodb umjesto izlaganja DB porta na javnom internetu.

Volumeni su ovdje posebno važni, jer vam omogućavaju da sačuvate podatke izvan životnog ciklusa bilo kojeg pojedinačnog kontejnera. Docker volumeni su jednostavno direktoriji na hostu koji su montirani u određene putanje unutar kontejnera; to znači da možete sigurno ukloniti ili ponovo kreirati kontejnere bez gubitka datoteka baze podataka, prenesenih resursa ili logova, sve dok su te putanje montirane kao volumeni.

Još jedan kritičan aspekt je konfiguracija okruženja, koja se u Docker Compose-u obrađuje putem varijabli okruženja definiranih direktno u compose datoteci ili u eksternim... .env datoteke. Ovo olakšava prosljeđivanje URL-ova baze podataka, API ključeva, tajnih podataka i zastavica funkcija vašim servisima, a u GUI okruženjima poput Pleska možete upravljati ovim varijablama putem obrazaca umjesto ručnog uređivanja YAML-a.

Nakon što je vaš stek modeliran u Composeu, implementacije na udaljeni VPS se svode samo na kopiranje repozitorija ili preuzimanje najnovijih promjena, a zatim pokretanje. docker-compose up -d (ili docker compose up -d). Prvo pokretanje će izgraditi slike i preuzeti zavisnosti, dok će sljedeća pokretanja ažurirati samo ono što je promijenjeno, čineći kontinuirano postavljanje i predvidljivim i brzim.

Implementacija Dockerizovanih aplikacija na cloud serveru i otvaranje pristupa

Kada ste spremni pokrenuti svoje kontejnere na pravom VPS-u ili cloud serveru, prvi zadaci su osigurati mašinu s instaliranim Dockerom, a zatim premjestiti svoj projekat na nju. Mnogi provajderi nude gotove slike sa unaprijed instaliranim Dockerom, tako da pokretanje servera sa Dockerom može biti jednostavno kao odabir te slike u kontrolnoj ploči i čekanje nekoliko minuta.

Dostavljanje koda vaše aplikacije na server se obično vrši kloniranjem vašeg Git repozitorija preko SSH-a ili kopiranjem datoteka putem SCP/rsync-a. Kloniranje repozitorija je poželjnije u većini slučajeva jer održava vaše implementacije reproducibilnim i omogućava vam da vratite ili pregledate određene commit-ove koji se izvode u produkciji.

Ako vaša cloud slika ima samo Docker engine, ali ne i Docker Compose, morat ćete ručno instalirati Compose. Na mnogim Linux distribucijama možete preuzeti Compose binarni fajl sa curl sa službene URL adrese izdanja GitHub-a, sačuvajte je na /usr/local/bin/docker-compose i učinite ga izvršnim sa chmod +x, nakon čega je docker-compose komanda postaje dostupna.

Nakon što je Compose instaliran i vaše projektne datoteke su na svom mjestu, pokretanje steka je obično samo stvar pokretanja. docker-compose up (opciono sa -d za odvojeni način rada). Prvo pokretanje može potrajati neko vrijeme jer Docker mora preuzeti osnovne slike i instalirati ovisnosti aplikacije (na primjer npm install u vašem Node kontejneru), ali će naknadna implementacije biti mnogo brže zahvaljujući Dockerovom keširanju slojeva.

U ovom trenutku vaša aplikacija vjerovatno osluškuje neki interni port (kao što je 3030) unutar kontejnera, mapiran na isti port na hostu, ali to ne garantuje da je dostupan s interneta. I dalje morate provjeriti da li svi zaštitni zidovi, sigurnosne grupe ili mrežne politike ispred servera dozvoljavaju dolazni promet na tom portu ili da li zahtjeve usmjeravate putem HTTP reverznog proxyja na portu 80/443, kao što je Nginx.

Umrežavanje, portovi i zaštitni zidovi u udaljenim Docker implementacijama

Pravilno izlaganje vaše kontejnerizirane aplikacije korisnicima bez slučajnog otvaranja svakog porta na vašem VPS-u jedna je od ključnih operativnih vještina koje će vam trebati. Podrazumevano, Docker-ova funkcija mapiranja portova vam omogućava da povežete interni port kontejnera sa bilo kojim portom na hostu, pomoću pravila kao što su -p 3030:3030 ili ekvivalent u Composeu.

Za jednostavna podešavanja možete mapirati kontejner direktno na javni port, ali u većini produkcijskih podešavanja će vam trebati HTTP reverzni proxy (kao što je Nginx) ili panel kao što je Plesk ili hosting firewall kao ulazna tačka. U tom modelu, vaša aplikacija sluša samo na localhost ili internu Docker mrežu, a obrnuti proxy prosljeđuje promet sa standardnih portova 80/443 na port kontejnera.

Kada ručno konfigurirate mapiranja portova, često možete odabrati da li port treba biti dostupan samo s lokalnog interfejsa hosta ili sa svih mrežnih interfejsa. Vezivanje za 127.0.0.1:PORT znači da port nije dostupan s javnog interneta, što je sigurnije za administratorske alate ili interne usluge; povezivanje sa 0.0.0.0:PORT omogućava mu pristup izvana (podložno pravilima zaštitnog zida).

Pored Docker-ovih povezivanja portova, vaš cloud provajder ili hosting platforma mogu nametnuti vlastita pravila zaštitnog zida (firewall), koja morate zasebno konfigurirati. Na primjer, ako vaša aplikacija osluškuje port 3030 i ne koristite obrnuti proxy, morat ćete eksplicitno otvoriti 3030 na VPS zaštitnom zidu ili u konfiguraciji sigurnosti vaše cloud mreže prije nego što kliknete na [link]. http://SERVER_IP:3030 će raditi.

Za alate za udaljenu administraciju kao što je Portainer, koji često rade na portovima poput 9000 ili 8000, posebno je važno razmisliti o izloženosti zaštitnom zidu i možda ograničiti pristup putem dozvoljenih IP lista ili VPN-a, budući da ove nadzorne ploče obično daju potpunu kontrolu nad Dockerom na tom hostu.

Korištenje Pleska za upravljanje lokalnim i udaljenim Docker servisima

Ako hostujete web stranice na Plesku, možete integrirati Docker direktno u to okruženje, i na istom serveru i na udaljenim Docker hostovima. Plesk podržava Docker na nizu Linux distribucija, uključujući CentOS 7, RHEL 7, Debian 10-12 i Ubuntu 18.04, 20.04, 22.04 i 24.04, kao i AlmaLinux i Rocky Linux 8.x/9.x, plus određene verzije Virtuozza.

Na Plesku za Windows, ne možete pokrenuti Docker direktno na istoj mašini, ali se možete povezati s Dockerom koji je instaliran na zasebnom udaljenom hostu. Ovo je praktično ako ste vezani za Windows za panel, ali i dalje želite fleksibilnost Linux kontejnera na drugom čvoru kojim Plesk upravlja putem Dockerovog udaljenog API-ja.

Imajte na umu da kada sam Plesk radi unutar Docker kontejnera, funkcije integracije s Dockerom nisu dostupne. Podrška za Docker također zahtijeva dodatnu Plesk licencu ili paket, kao što su Hosting Pack, Power Pack ili Developer Pack, i radi samo na 64-bitnim (x64) sistemima.

Pleskova Docker ekstenzija znatno olakšava pretragu slika i u vašem lokalnom Docker repozitoriju i na Docker Hubu. Slike možete pronaći pomoću polja za pretragu, vidjeti koje su verzije (oznake) dostupne i odabrati tačno koju oznaku želite pokrenuti, što je važno za ponovljive implementacije i izbjegavanje „najnovijih“ iznenađenja.

Pokretanje i konfigurisanje kontejnera putem Pleska

Kada želite pokrenuti kontejner iz Pleska, obično idete u odjeljak Docker, odaberete "Kontejneri", a zatim "Pokreni kontejner". Tamo tražite sliku, odabirete željenu oznaku, a Plesk se brine o preuzimanju slike i kreiranju kontejnera za vas.

Nakon što je kontejner kreiran, Plesk vam daje ekran za konfiguraciju gdje možete podesiti ključne opcije izvođenja prije nego što pritisnete posljednje dugme „Pokreni“. Tu se podešavaju varijable okruženja, mapiranja portova, volumeni, ograničenja memorije i ponašanje pri ponovnom pokretanju, slično kao što biste to učinili u Compose datoteci, ali koristeći GUI umjesto YAML-a.

Podrazumevano, kontejneri nemaju ograničenje memorije i dozvoljeno im je da koriste onoliko RAM-a koliko im host dodijeli, što može biti u redu za male postavke, ali opasno pri velikim razmjerima. U Plesku možete uključiti opciju "Ograničenje memorije" i odrediti maksimum u megabajtima, sprječavajući da neiskorišteni kontejner iscrpi cijeli server resursima.

Još jedna važna Plesk opcija je da li kontejner treba automatski ponovo pokrenuti kada se sistem ponovo pokrene. Ako ne omogućite automatsko pokretanje, web-lokacije koje ovise o tom kontejneru mogu ostati neaktivne nakon ponovnog pokretanja dok se neko ne prijavi i ručno ponovo pokrene kontejner, tako da je za produkcijska opterećenja uobičajeno da automatsko pokretanje ostane omogućeno.

Plesk također olakšava ponovni pregled konfiguracije kontejnera kasnije: s liste kontejnera možete otvoriti logove, provjeriti korištenje resursa, preimenovati kontejnere, ponovo ih kreirati, spremiti ih kao nove slike, preuzeti snimke stanja i izbrisati ih kada više nisu potrebni. Ove radnje odražavaju ono što biste obično radili iz komandne linije s Dockerom i Composeom, ali su upakirane u panel koji bi mogao biti pristupačniji timovima koji nisu upoznati s SSH-om.

Portovi, volumeni i varijable okruženja u kontejnerima kojima upravlja Plesk

Kada Plesk kreira kontejner, on može automatski mapirati interne portove na nasumične portove visokog nivoa na hostu, ili to možete prepisati i postaviti ručno mapiranje portova. Automatsko mapiranje je pogodno za brze eksperimente, ali za produkciju obično želite predvidljiva, ručna mapiranja ili obrnuti proxy ispred.

S ručnim mapiranjem portova, Docker se prema zadanim postavkama veže za lokalni interfejs hosta, čineći port kontejnera dostupnim samo sa samog hosta, osim ako ga dodatno ne otvorite. U Plesku obično postoji opcija za odlučivanje da li port treba biti dostupan s interneta ili ograničen na localhost, što je ključno za sigurnosno osjetljive usluge.

Volumeni u Plesku se konfigurišu određivanjem apsolutne putanje na hostu i ciljne putanje unutar kontejnera. Ovo funkcioniše baš kao i standardni Docker volumeni: podaci pohranjeni u ovim tačkama montiranja preživljavaju ponovno kreiranje ili uklanjanje kontejnera, što ih čini idealnim za baze podataka, otpremljene datoteke, direktorijume keša i bilo koje trajno stanje koje je vašoj aplikaciji potrebno.

Varijable okruženja se konfigurišu putem posebnog odjeljka gdje možete dodavati, uređivati ​​ili uklanjati onoliko varijabli koliko vaša kontejnerizirana aplikacija zahtijeva. Ovo pruža jednostavan način za ubrizgavanje konfiguracijskih vrijednosti, tajni (iako za prave tajne možda ipak preferirate eksterne pohrane) ili zastavica bez njihovog ugrađivanja u vaše slike.

Iza kulisa, Plesk obično implementira HTTP proxy pravila u konfiguraciji web servera (na primjer u Nginx-ovom nginx.conf za određenu domenu) za prosljeđivanje prometa s domene na jedan od vaših kontejnera. Ovo proxyiranje obično funkcionira dobro čak i ako se server nalazi iza NAT-a, sve dok su vanjski zaštitni zid (firewall) i prosljeđivanje portova ispravno postavljeni.

Upravljanje udaljenim Docker čvorovima iz Pleska

Jedna od naprednijih mogućnosti Pleskove Docker integracije je podrška za upravljanje udaljenim Docker engine-ima, ne samo onim na istom serveru kao i Plesk. Ovo je korisno kada želite da Plesk ostane kontrolna ravan dok se velika opterećenja izvršavaju na drugim čvorovima.

Da biste ovo postavili, prvo morate konfigurirati Docker daemon udaljenog hosta da sigurno sluša udaljene veze, obično uređivanjem /etc/docker/daemon.json i omogućavanje TLS-a sa datotekama certifikata u .pem formatu. Generirate certifikate, konfigurirate daemon da ih koristi i ponovo pokrenete Docker tako da počne slušati na TCP portu pored uobičajenog lokalnog Unix socketa.

Nakon što je udaljeni daemon konfiguriran, spremate izlaze certifikata na lokalnom računaru kako bi vaš Docker klijent ili Plesk mogli izvršiti autentifikaciju na tom hostu. Kada su te datoteke spremne, idete u Plesk, otvorite odjeljak Docker "Okruženja" i dodajte novi server koristeći adresu udaljenog hosta i TLS vjerodajnice, označavajući ga kao aktivnog ako želite da ga Plesk odmah koristi.

Nakon što dodate nekoliko Docker okruženja, možete se prebacivati ​​između njih iz istog Plesk interfejsa, postavljajući bilo koje od njih kao aktivnu Docker uslugu u datom trenutku. Ovo vam omogućava centralizaciju upravljanja više Docker čvorova, a istovremeno fizički odvajanje njihovih radnih opterećenja.

Plesk također nudi prikaz slika za svako Docker okruženje gdje možete izlistati sve lokalne slike, provjeriti koje su oznake prisutne i koliko prostora na disku zauzimaju, te ukloniti neiskorištene slike kako biste oslobodili prostor za pohranu. Ovo je posebno korisno ako vaš CI cjevovod često gradi nove slike, a stare ostavlja na udaljenim čvorovima.

Implementacija Docker Compose stekova iz Pleska

Pored upravljanja pojedinačnim kontejnerima, Plesk također može implementirati kompletne višekontejnerske stekove opisane u Docker Compose datotekama. Ovo premošćuje jaz između "klikabilnog GUI-ja" i "infrastrukture kao koda", omogućavajući vam da Compose datoteke držite u kontroli verzija, a da i dalje imate panel za kontrolu implementacija.

Da biste to uradili, idite na odjeljak Docker "Stacks" u Plesku i odaberite dodavanje novog steka, dajte mu naziv projekta i odaberite kako želite da se dostavi Compose datoteka. Vaše opcije obično uključuju direktno kucanje ili lijepljenje datoteke u editor, postavljanje lokalne YAML datoteke ili ukazivanje na Compose datoteku koja se već nalazi u web prostoru određene domene.

Kada implementirate Compose stek putem Pleska, možete deklarirati i kreirati potpuno prilagođene kontejnere, a svi artefakti izgradnje proizvedeni tokom procesa pohranjuju se u korijenski direktorij web stranice. Ovo drži vaše resurse za implementaciju blizu datoteka vaše web-lokacije i olakšava pregled onoga što je generirano.

Iako Plesk apstrahuje veliki dio složenosti, osnovna Compose datoteka i dalje mora poštovati Dockerov format i semantiku. Za detaljne opcije kao što su mreže, argumenti izgradnje, provjere ispravnosti i napredno evidentiranje, i dalje vrijedi pročitati službenu specifikaciju Docker Compose-a i koristiti Plesk uglavnom kao prijateljski front-end preko nje.

Ako preferirate namjenskiji korisnički interfejs za upravljanje Dockerom, Pleskove Docker alate možete dopuniti ili čak zamijeniti s Portainerom, koji je u suštini web-bazirana kontrolna ploča za Docker i Docker Compose koja također podržava udaljene čvorove putem Docker API-ja ili agenta.

Rad sa udaljenim kontejnerima iz Docker Desktopa i VS Code-a

Ako koristite Windows, Docker Desktop u kombinaciji s WSL 2 i VS Codeom pruža vam vrlo uglađen tijek rada za lokalno kreiranje i pokretanje Linux kontejnera, što indirektno pomaže i pri udaljenom postavljanju. Docker Desktop koristi laganu Linux VM putem WSL 2, tako da možete kreirati i testirati iste Linux kontejnere na svom laptopu koje ćete kasnije prenijeti na udaljeni VPS.

Nakon instaliranja WSL 2 i Docker Desktopa, omogućavate WSL 2 backend u postavkama Dockera, birate koje WSL distribucije treba integrirati s Dockerom, a zatim provjeravate instalaciju pokretanjem docker --version i testni kontejner poput docker run hello-world sa WSL terminala. Ovo potvrđuje da vaše razvojno okruženje koristi isti Docker CLI i engine u Windows i Linux kontekstima.

VS Code-ovo WSL proširenje vam omogućava da otvorite projekat koji se nalazi unutar vašeg WSL datotečnog sistema i radite s njim kao da je lokalni, skrivajući probleme s putanjama između operativnih sistema i binarnom kompatibilnošću. Osim toga, ekstenzija Dev Containers vam omogućava da otvorite sam projekat "unutar" kontejnera, efektivno pretvarajući kontejner u vaše razvojno okruženje.

U praksi, uobičajeni tok je: klonirajte svoj projekat unutar WSL-a, otvorite ga pomoću VS Code-a putem WSL ekstenzije, a zatim koristite naredbu „Ponovno otvori u kontejneru“ iz ekstenzije Dev Containers. VS Code će kreirati .devcontainer fascikla sa Dockerfile i devcontainer.json, izgradite tu sliku, a zatim ponovo otvorite svoj projekat u dev kontejneru koji sadrži sve potrebne alate.

Odatle možete pokrenuti i debugirati svoju aplikaciju direktno unutar kontejnera koristeći VS Code-ov panel Run and Debug, koji će pokrenuti vaš server (na primjer, Django ili Node aplikaciju) i omogućiti vam da je aktivirate. http://127.0.0.1:PORT iz vašeg pregledača. Ovo vam daje visok nivo sigurnosti da će se kontejner koji instalirate na udaljeni VPS ponašati na isti način kao i onaj koji koristite za razvoj.

Rješavanje uobičajenih problema s Docker Desktopom i WSL-om

Ponekad prilikom migracije sa starijih pregleda Dockera za Windows, možete naići na zastarjeli Docker kontekst pod nazivom "wsl" koji ukazuje na nepostojeći kanal. Komanduje kao docker context ls će to otkriti, a poruke o grešci bi mogle spomenuti docker_wsl cijevi koje se ne mogu pronaći.

Rješenje je obično jednostavno kao uklanjanje tog zastarjelog konteksta pomoću docker context rm wsl tako da se podrazumijevani Docker kontekst koristi i za Windows i za WSL. Nakon toga, interakcije s Dockerom unutar WSL distribucija trebale bi ponovo proći kroz odgovarajuću Docker Desktop integraciju.

Još jedna česta zabuna je gdje Docker Desktop zapravo pohranjuje svoje WSL-podržane podatke, uključujući slike i volumene. Docker kreira distribucije nazvane nešto poput docker-desktop i docker-desktop-data, koji možete pregledavati putem Windows Explorera pokretanjem explorer.exe . iz WSL prompta i navigacijom do putanja poput \\wsl$\Distro\mnt\wsl.

Razumijevanje ovih lokacija za pohranu pomaže vam prilikom dijagnosticiranja problema s prostorom na disku ili pokušaja sigurnosnog kopiranja ili uklanjanja velikih slika i volumena koje je vaš lokalni razvojni rad akumulirao. Za svakodnevni razvoj i implementaciju, obično ne morate direktno dirati ove direktorije, ali je dobro znati gdje se nalaze.

Ako naiđete na općenite greške povezane s WSL-om, konsultovanje službenih vodiča za rješavanje problema s WSL-om i Dockerove vlastite dokumentacije o WSL integraciji često je najbrži put do rješenja. Mnogi poznati problemi, posebno oni koji se odnose na neusklađenosti verzija i postavke virtualizacije, imaju dobro dokumentirana rješenja.

Spajanje svih ovih dijelova – sastavljajte na svom VPS-u, opcionalnim grafičkim korisničkim interfejsima poput Pleska ili Portainera i solidnom lokalnom postavkom s Docker Desktopom i VS Codeom – daje vam fleksibilan, ponovljiv tijek rada za razvoj, isporuku i pokretanje kontejneriziranih aplikacija na udaljenim serverima bez neugodnih iznenađenja između okruženja.