Как да разположите Docker контейнери на отдалечени сървъри

  • Използването на Docker Compose и SSH или GitHub Actions опростява разполагането на контейнери на отдалечени сървъри и прави актуализирането на услугите по-лесно.
  • Инструменти като WSL 2, VS Code и Dev Containers позволяват разработка в отдалечени Docker среди с почти локално изживяване.
  • Plesk и Portainer предлагат уеб интерфейси за управление на локални и отдалечени Docker хостове, Compose стекове, томове и изображения.
  • С VNC/noVNC и Caddy е възможно да се изпълняват графични приложения в отдалечени контейнери и да се осъществява сигурен достъп до тях от браузъра.
Pablo

14 Minutos

Разполагане на Docker контейнери на отдалечени сървъри

Работа с Docker контейнери на отдалечени сървъри Това се превърна в основната храна за всеки, който иска да внедрява съвременни приложения, без да се затруднява със зависимости, версии на библиотеки и класическото „работи на моята машина“. Когато обаче преминем от изпълнение на просто... docker run Преминавайки от настройване на сериозно внедряване локално на Linux сървър, с Docker Compose, споделяния на GitHub, Plesk, Portainer или дори графични приложения, достъпни през браузър, нещата стават малко по-сложни.

Ако целта ви е да разположите Docker контейнери на отдалечен сървър (Ubuntu, Debian, Windows с WSL 2, облачен сървър, Plesk и др.) и да го направите по поддържаем, автоматизиран и сигурен начин, в това ръководство ще намерите сравнително пълен преглед: от основното използване на Docker Compose дистанционно, до среди за разработка с VS Code, внедрявания от Plesk, администриране с Portainer и дистанционно изпълнение на графични приложения с помощта на noVNC и Caddy.

Основни понятия: Docker контейнери и отдалечено внедряване

Docker е контейнерна платформа Той пакетира приложението заедно с всичко необходимо (библиотеки, зависимости, двоични файлове, минимална системна конфигурация), така че да работи по един и същи начин на всяка машина с инсталиран Docker енджин. Ключовата разлика в сравнение с виртуалната машина е, че контейнерът не включва пълна операционна система; вместо това той споделя ядрото на хоста, което води до по-леки образи и по-добра производителност.

За да разположите Docker контейнери на отдалечени сървъри Обикновено имате хост (например Ubuntu сървър в облака) с Docker и, по избор, Docker Compose, след което изпращате кода или изображенията към него, за да се изпълни. Можете да направите това ръчно чрез SSH, да го автоматизирате с GitHub Actions или да го интегрирате с панели като Plesk или инструменти като Portainer.

Основните сценарии от реалния свят, с които ще се сблъскате Когато говорим за „отдалечен Docker“, има три аспекта: локална разработка, но изпълнение на контейнери на друга машина (или в WSL 2), автоматизирано внедряване на backend/frontend услуги и управление на производствени контейнери (мониторинг, регистриране, рестартирания, мрежови политики и др.). Технологията е същата; това, което се променя, е как е оркестрирана.

В допълнение към традиционните бекенд услугиDocker позволява нещо по-малко познато, но много мощно: стартиране на графични приложения (имейл клиенти, IDE, инструменти за анализ и др.) в отдалечени контейнери и достъп до тях от браузър, използвайки VNC през WebSocket. Това е удобен начин да се използват мощни сървъри, когато вашият компютър не е достатъчно мощен.

От Docker Run към Docker Compose на отдалечен сървър

Използване на Docker Compose на отдалечен сървър

Доста често срещан модел на ръчно внедряване Състои се от наличието на хранилище за код в GitHub, отдалечен Ubuntu сървър с инсталиран Docker и CI/CD работен процес (например GitHub Actions), който прави следното, когато изпращате към клон като development o main:

  • Свържете се с отдалечения сървър чрез SSH.
  • Спрете и отстранете работещите контейнери.
  • Изтеглете новите изображения от Docker Hub (или от вашия личен регистър).
  • тичам docker run за всяка услуга.
  • Нека Nginx (или обратният прокси, който използвате) пренасочва трафика към портовете на всеки контейнер.

Когато преминете към Docker Compose Процесът е значително опростен, защото вместо да управлявате контейнерите един по един, вие дефинирате целия си стек (фронтенд, бекенд, база данни, кеш и т.н.) в един единствен docker-compose.yml, с неговите мрежи, обеми и променливи на околната среда.

Най-простата (и доста често срещана) практика с GitHub Actions Работният процес трябва да изпълнява cd към директорията на проекта на отдалечения сървър (където вашият docker-compose.yml) и изпълнява команди като:

  • docker compose pull за да донесе най-новите изображения.
  • docker compose down за спиране и премахване на стари контейнери (по избор с --remove-orphans).
  • docker compose up -d --build ако изграждате изображения от самия сървър.

Този подход работи добре и е доста надежденПри условие че имате добър контрол върху идентификационните данни, променливите на средата и томовете, можете да подобрите сигурността, като предотвратите пълен root достъп на GitHub Actions до сървъра, ограничите SSH ключовете, използвате специални потребители или дори изложите Docker като защитена отдалечена услуга със сертификати, вместо да изпълнявате всичко през SSH.

Няма по-добър „магически начин“ от този. За проста среда: ключът е да се автоматизира и напише добре docker-compose.ymlИзползвайте непроменяеми тагове за изображения (напр. специфични версии) и имайте механизъм за връщане назад (напр. запазване на предишната версия на писането или изображенията).

Среда за отдалечена разработка с Docker, WSL 2 и VS Code

Отдалечен Docker с VS Code и WSL 2

В Windows е много често срещано да се разработва с Docker, използвайки WSL 2.Docker Desktop за Windows предлага WSL 2-базиран енджин, който ви позволява да стартирате Linux и Windows контейнери от една и съща машина, докато редактирате код с VS Code и тествате в локалния браузър.

Типичният работен процес за настройване на среда за разработка с отдалечени контейнери, използващи WSL 2 е следното:

  1. Инсталирайте WSL 2 и дистрибуция на Linux (например Ubuntu).
  2. Инсталирате Docker Desktop на Windows и активирате опцията „Използване на WSL 2-базиран енджин“ в Настройки > Общи.
  3. В Настройки > Ресурси > WSL интеграция избирате WSL дистрибуциите, върху които искате Docker да работи.
  4. Проверявате инсталацията с docker --version и бягане docker run hello-world в рамките на WSL дистрибуцията.

Да се ​​развива „в рамките“ на контейнерите И не става въпрос само за използване на Docker като двигател; VS Code е ключов. С WSL, Dev Containers и разширенията на Docker можете да правите неща като:

  • Отворете папката на проекта си, хоствана в WSL, директно във VS Code.
  • Отворете отново тази папка „в контейнер за разработка“ (Dev Container), използвайки Dockerfile и devcontainer.json които описват вашата идеална среда (версия на Python, Node и др.).
  • Отстранете грешки в приложението си от VS Code, докато то работи в контейнера.

Много често срещан пример Работи с Django или Node.js проект: клонирате хранилището в WSL, отваряте папката с code .Избирате дефиниция на Dev Container (например „Python 3“) и VS Code изгражда образа и стартира контейнера с всички зависимости. Оттам можете да го стартирате, да отстранявате грешки и да проверявате дали кодът работи на Linux, дори ако вашата хост система е Windows.

Този подход е полезен и когато машината ви не е много мощнаЗащото можете да преместите част от натоварването на отдалечен сървър с Docker и да се свържете с него с VS Code чрез SSH и Dev Containers, работейки почти сякаш е локален, но разчитайки на ресурсите на сървъра.

Разгръщане на приложения на облачен сървър с Docker и Docker Compose

Настройте облачен сървър с Docker, готов за внедряване Много е бързо с повечето доставчици: избирате системен образ, на който вече е предварително инсталиран Docker, изчаквате няколко минути и машината ви е готова да приема контейнери.

Типичен модел за внедряване на просто Node.js приложение Това би било:

  1. Създайте проекта Node.js (например „Hello world“ с Express) на вашата локална машина: папка на проекта, поддиректория app, npm init, инсталиране на зависимости (като например express) и а index.js който настройва сървър на порт 3030 с основно съобщение.
  2. Докеризирайте приложението с Докер файл което определя основното изображение (например node:12), WORKDIRКопирайте файловете на приложението, стартирайте го npm install и освободете вътрешния порт.
  3. Добавете a .dockerignore за да се избягва поставянето на неща като node_modules.
  4. Създайте a докер-compose.yml в корена на проекта, указвайки версията (например, 3.8) и определяне на основната услуга, нейната build, картографиране на портове (3030:3030) и командата (node index).

След като проектът и писането са готовиРазгръщането на отдалечения сървър обикновено следва следния процес:

  • Свързвате се със сървъра чрез SSH.
  • Клонирате хранилището или качвате файловете (Git, SCP, rsync…).
  • Вие инсталирате докер-ново съобщение ако вече не е бил там (в много дистрибуции трябва да го инсталирате отделно от Docker, например като изтеглите двоичния файл от GitHub и му дадете разрешения за изпълнение).
  • Изпълнявате docker-compose up (o docker compose up (в зависимост от версията), така че изображенията да бъдат изтеглени, изображението на приложението ви да бъде изградено и контейнерите да бъдат стартирани.

Един момент, който често се пренебрегва, е защитната стена на доставчика.Ако вашата услуга слуша на порт 3030, ще трябва да го отворите в правилата на защитната си стена или да създадете специфична политика и да го свържете със сървъра. В противен случай ще видите само съобщение „връзката е отказана“ отвън, дори ако контейнерът работи правилно.

След като заработи, можете да получите достъп до приложението използвайки публичния IP адрес и открития порт на сървъра (например, https://IP_DEL_SERVIDOR:3030) или като скриете този порт зад обратен прокси сървър като Nginx/Traefik, който слуша на порт 80/443.

Управление на отдалечени контейнери с Plesk и Docker

Ако използвате Plesk като контролен панелМожете също да използвате разширението му Docker, за да управлявате контейнери директно от уеб интерфейса, както на самия сървър, така и на отдалечени Docker хостове.

Plesk поддържа Docker на голямо разнообразие от операционни системиCentOS 7, RHEL 7, Debian 10/11/12, различни версии на Ubuntu (18.04, 20.04, 22.04, 24.04), AlmaLinux 8/9, Rocky Linux 8.x и актуализираната Virtuozzo 7. В Plesk за Windows, Docker не работи локално, а на отдалечена машина, действаща като Docker хост.

Има някои важни ограничения, които трябва да се имат предвид:

  • Не можете да използвате разширението Docker, ако Plesk е разположен в контейнер на Docker.
  • За да използвате отдалечени Docker услуги (т.е. външни хостове), ви е необходим допълнителен лиценз или специфични пакети (Hosting Pack, Power Pack, Developer Pack).
  • Docker контейнерите, управлявани от Plesk, не са „мигрируеми“ като такива, въпреки че можете да архивирате данните, които използват, като използвате томове или моментни снимки.

От интерфейса на Plesk можете да търсите изображения както в локалното хранилище (изображенията вече са изтеглени на хоста), така и в Docker Hub. За да стартирате контейнер, панелът ви насочва:

  1. Посещение Докер > Контейнери > Изпълнение на контейнер.
  2. Намерете желаното изображение и прегледайте документацията му в Docker Hub (ако е приложимо).
  3. По желание изберете конкретен етикет/версия на изображението.
  4. Конфигурирайте параметрите на контейнера (променливи на средата, портове, томове, памет, автоматично стартиране и др.) и щракнете върху „Изпълни“.

Plesk ви позволява да управлявате и разширени настройки За всеки контейнер: преназначете портове (автоматично или ръчно), решете дали портът е достъпен от интернет или само от localhost, ограничете RAM паметта, която контейнерът може да консумира, дефинирайте томове (път на хоста и в контейнера) или добавете толкова променливи на средата, колкото са ви необходими.

Относно аспекта на отдалечената оркестрацияPlesk може да работи с „отдалечени Docker услуги“. Това включва конфигуриране на Docker демона на отдалечения хост (например, с помощта на /etc/docker/daemon.json с поддръжка на TLS и TCP сокети), генериране на сертификати .pem и регистрирайте този хост в Plesk от Докер > Среди > Добавяне на сървърСлед това можете да маркирате този Docker възел като активен и да превключвате между различни сървъри от един и същ интерфейс.

Разгръщане на Docker Compose стекове от Plesk

Ако вече използвате Docker Compose за вашата инфраструктураМоже би ще ви е интересно Plesk да се справи с разполагането на „стекове“ от файлове. docker-compose.yml.

Работният процес за внедряване на Compose в Plesk Сравнително е просто:

  1. отидете в Докер > Стекове > Добавяне на стек.
  2. Задайте име на проект на стека.
  3. Изберете източника на файла за съставяне: редактор (поставете съдържанието), качете файл от вашия компютър или изберете съществуващ файл в уеб пространството на домейн.
  4. Потвърдете конфигурацията и позволете на Plesk да декларира и създаде дефинираните контейнери.

Всичко, което се изгражда по време на процеса на изграждане Свързаният Compose се съхранява в главната директория на уебсайта, което улеснява достъпа до лог файлове, междинни артефакти или допълнителни файлове, генерирани от компилацията.

Plesk също така улеснява управлението на локални изображения: от Докер > Изображения Можете да филтрирате, да преглеждате различни етикети на продукти, да виждате използваното пространство и да изтривате остарели изображения, за да освободите място на диска. Това е важно в отдалечени среди с ограничено пространство.

Ако използвате Nginx като ваш front-end уеб сървърPlesk прилага правила за прокси (например в nginx.conf (от домейна), за да насочвате трафика към вашите Docker контейнери, дори в сценарии зад NAT. Това ви спестява ръчната работа с конфигурации на обратен прокси сървър на отдалечени сървъри.

Управлявайте отдалечени контейнери с Portainer

Portainer е лек уеб интерфейс За Docker това значително опростява ежедневната работа на тези, които не искат да работят в командния ред. Той функционира като контейнер и може да управлява локалния хост или множество отдалечени хостове (дори с Portainer Agent).

За да инсталирате Portainer на вашия сървър, използвайки Docker Обикновено следвате тези основни стъпки:

  • Създайте том за данните на Portainer: docker volume create portainer_data.
  • Стартирайте контейнера Portainer, като картографирате портове 8000 и 9000, монтирате Docker сокета (/var/run/docker.sock) и обемът на данните: 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.

Това ще накара Portainer да слуша на порт 9000 на сървъра.Както винаги, ще трябва да отворите порта във вашата защитна стена или да го предоставите чрез обратен HTTPS прокси. Първия път, когато го достъпите през браузър, Portainer ще ви помоли да създадете потребител с администраторски права и след това можете да изберете дали да управлявате локалния Docker или допълнителни отдалечени хостове.

Панелът на Portainer е доста интуитивен.Ще видите активни контейнери, техните лог файлове, статистика за потреблението на ресурси, Compose стекове, мрежи, томове и други. И най-важното е, че ви позволява да пресъздавате контейнери с различни параметри, да актуализирате изображения, да управлявате стекове и да централизирате множество отдалечени сървъри от един интерфейс.

Стартирайте графични приложения в отдалечени контейнери и достъпвайте до тях чрез браузър

Когато ресурсите на компютъра ви свършат Но ако трябва да използвате тежки графични приложения (като имейл клиенти, IDE или инструменти за обратно инженерство), едно много интересно решение е да ги стартирате в Docker контейнери на мощен сървър и да осъществявате достъп до тях през интернет.

Много добре документиран казус Идеята е да се капсулира Mozilla Thunderbird в контейнер, да се предостави графичният му интерфейс чрез TigerVNC/noVNC и да се осигури достъп с Caddy. Тази концепция може да се използва повторно за почти всяко Linux GUI приложение.

Основната архитектура на този тип графичен контейнер обикновено включва:

  • Лек VNC/X11 сървър (TigerVNC), който действа като сървър за дисплей.
  • Минималистичен мениджър на прозорци (OpenBox) за работа с прозорци.
  • Малък, лесен за използване тип сървър easy-novnc който предоставя VNC като WebSocket и генерира HTML страница за свързване от браузъра.
  • supervisord или подобно, за да стартирате и наблюдавате всички процеси в контейнера.
  • Самото приложение (Thunderbird, GIMP и др.), конфигурирано да се показва на отдалечения дисплей (DISPLAY=:0).

На практика се създава работна директория. (например ~/thunderbird) където са поставени:

  • Un supervisor.conf който определя програмите за стартиране: TigerVNC, easy-novnc, OpenBox и основното приложение, с приоритети, така че графичният сървър да стартира преди приложението.
  • Un menu.xml OpenBox конфигурира менюто на работния плот (главно приложение, терминал, монитор на процеси с htop и др.).
  • Un многоетапен Dockerfile който на първия етап компилира easy-novnc с Go, а във втората стъпка създава финалния образ на Debian, инсталира openbox, tigervnc, supervisor, конзолни помощни програми, приложението (Thunderbird в примера), копира двоичните файлове и конфигурациите, създава потребител без root права и дефинира постоянен обем данни в /data.

Командата по подразбиране на контейнера обикновено се делегира на supervisord., стартирайки го като нормален потребител, използващ gosuСлед коригиране на разрешенията за обема данни, когато контейнерът се стартира, VNC, noVNC, мениджърът на прозорци и приложението се стартират автоматично и е необходим само достъп до HTTP порта, предоставен от easy-novnc.

За да го направим по-стабилен и лесен за ползване в интернетДобра идея е да поставите уеб сървър като Caddy отпред, също в контейнер, който действа като обратен прокси към вашето графично приложение, добавя основно удостоверяване (хеширано потребителско име и парола) и по избор предоставя WebDAV за достъп до файловете. /data от вашата локална машина.

Оркестрирайте решението с мрежи, томове и Caddy

За да се поддържа организирано разполагане на този тип Обичайният подход е да създадете своя собствена Docker мрежа и един или повече томове данни:

  • Мрежа, например thunderbird-net, който ще бъде споделен от всички свързани контейнери.
  • Volumen thunderbird-data който ще съдържа потребителския профил и постоянните данни на графичното приложение.

Контейнерът на графичното приложение Можете да го стартирате с нещо подобно:

  • Политика --restart=always за да може да се изправи самостоятелно.
  • Сглобяване на обем thunderbird-data:/data.
  • Мрежова връзка thunderbird-net.
  • Идентифицируемо име (thunderbird-app(например), който Caddy ще използва за обратния прокси.

В друга директория (например, ~/caddy) образът на Кади е конструиран с необходимите модули (като например плъгина WebDAV) и a Caddyfile което определя:

  • Сървър на порт 8080.
  • Un reverse_proxy за thunderbird-app:8080 (или портът, който noVNC предоставя).
  • Допълнителни пътища за навигация през файлове (/files) и за WebDAV (/webdav), като и двете обслужват съдържанието на обема данни.
  • Блок от basicauth което защитава всички пътища с потребител и хеширана парола, прочетени от променливите на средата.

При създаване на контейнера Caddyсъщият обем е сглобен thunderbird-data:/data, той се свързва с мрежата thunderbird-net и неговият порт е публикуван (например, -p 8080:8080) на хоста. С това просто трябва да влезете в браузъра си, за да http://IP_DEL_SERVIDOR:8080Въведете вашите идентификационни данни и щракнете върху „Свързване“, за да започнете да използвате графичното приложение дистанционно.

Дългосрочната поддръжка е простаКогато е необходимо да актуализирате, можете да спрете и изтриете контейнерите, да възстановите изображенията с новите версии и да ги стартирате отново. docker run поддържане на обема на данните, така че настройките и файловете на потребителя да останат непокътнати.

С всички тези компоненти (Docker Compose, Plesk, Portainer, VS Code, WSL 2, Caddy, noVNC…) Възможно е да се настрои всичко - от прости backend внедрявания до отдалечени десктопи, капсулирани в контейнери и перфектно достъпни през браузър, като се възползвате от сървъри с много по-голяма мощност от вашата машина и поддържате доста фин контрол върху мрежите, сигурността, съхранението и актуализациите.