Як перенести Docker Compose на новий VPS без простою

У більшості випадків перехід на новий VPS відбувається з якоїсь серйозної та практичної причини, наприклад, ваш проєкт розширився і перестав вміщуватися в наявні ресурси, або для вашого проєкту потрібне більш потужне обладнання, змінюється дата-центр чи настає час оновити інфраструктуру. Якщо додаток працює в Docker Compose, то це завдання на перший погляд здається досить простим, адже потрібно лише скопіювати файли, запустити контейнери - і все готово.

Але насправді саме таке спрощене уявлення в підсумку стає причиною простою, втрачених даних або несподіваної поведінки додатка. Звичайно, Docker значно спрощує перенесення інфраструктури, але не позбавляє адміністратора від необхідності правильно організувати сам процес міграції.

Є й хороша новина. Вона полягає в тому, що перенесення Docker Compose можна виконати практично непомітно для користувачів. Однак для цього важливо сприймати міграцію не як просте копіювання контейнерів, а як перенесення всього робочого середовища додатка, що включає конфігурації, безпосередньо дані, мережеві налаштування та оточення.

У цій статті розглянемо послідовність дій, яка дозволяє перенести ваш проєкт Docker Compose на новий VPS з мінімальним часом простою або взагалі без нього.

 

 

 

Підготуйте новий сервер заздалегідь

Як би це не суперечило інтуїції, але одна з найпоширеніших помилок, що допускаються під час міграції, це вимкнути старий VPS і лише потім почати налаштовувати новий. Такий підхід безпосередньо призводить до простою. Очевидно, що єдиним правильним варіантом є утримання обох серверів у робочому стані на час міграції та відключення старого сервера лише після повної підготовки нової платформи та переведення проєкту на неї.

Перед перенесенням проєкту на новий сервер на ньому необхідно виконати кілька підготовчих кроків:

• оновити операційну систему;
• встановити Docker Engine;
• встановити Docker Compose Plugin;
• налаштувати брандмауер;
• підготувати каталоги для постійних даних;
• переконатися, що ресурсів VPS вистачить для роботи проєкту з запасом.

 

Перевірити встановлені версії Docker можна за допомогою таких команд:

docker --version
docker compose version
docker info

Якщо проєкт використовує сучасні можливості Docker, наприклад BuildKit, то варто заздалегідь переконатися, що нова версія Docker Engine їх підтримує, адже краще виявити несумісність до початку міграції, ніж уже після запуску контейнерів.

Є ще один момент, який дуже легко пропустити. Перевірте архітектуру нового сервера. Якщо старий VPS працював на x86_64 (amd64), а новий використовує ARM, то частина образів може просто не запуститися. Особливо це стосується власних збірок або проєктів, де використовуються образи сторонніх розробників, які рідко оновлюються.

Після того, як ви оновили сервер і провели необхідні перевірки, можна переходити до поетапного перенесення проєкту.

 

 

 

 

Перенесіть інфраструктуру, а не лише додаток

Помилка багатьох міграцій полягає в тому, що на новий VPS копіюють лише файли додатка, після чого одразу намагаються запустити контейнери. Майже ніколи цього не вистачає, адже перед першим запуском потрібно підготувати все оточення проєкту. Як правило, йдеться про такі файли та компоненти:

• docker-compose.yml;
• .env;
• користувацькі Dockerfile;
• конфігурації Nginx, Apache або Traefik;
• SSL-сертифікатах;
• файлах конфігурації самого додатка;
• користувацьких скриптах;
• завданнях cron;
• резервних копіях.

 

Якщо інфраструктура зберігається разом із вихідним кодом, наприклад у Git-репозиторії, то підготовка нового сервера зазвичай займає всього кілька хвилин. Саме з цієї причини підхід "Infrastructure as Code" набув такого широкого поширення в останні роки, оскільки він дозволяє швидко відтворювати робоче середовище практично на будь-якому сервері.

Окрему увагу варто приділити секретам і конфігурації. Файл .envне можна зберігати в публічному репозиторії, але його актуальна копія має бути підготовлена ще до початку міграції.

До речі, саме відсутність .env - це одна з найпоширеніших причин невдалого перенесення Docker Compose. Контейнери можуть успішно запуститися, але додаток почне працювати з помилками або взагалі не зможе запуститися через відсутність необхідних змінних середовища.

 

 

 

 

Контейнери переносити не потрібно

Під час першої міграції багато хто намагається перенести самі контейнери. Для цього використовують docker commit, експортують образи або взагалі копіюють каталог /var/lib/docker цілком. На перший погляд ідея здається логічною, але це не правильний шлях.

Контейнер - це витратний елемент системи. Він створюється з образу, запускається, виконує своє завдання і, за потреби, відтворюється за лічені секунди. У цьому вся суть роботи Docker. Тому переносити потрібно не контейнери, а все, що знаходиться за їх межами і має зберегтися після перезапуску. Зазвичай це:

• вихідний код додатка;
• файл docker-compose.yml та інші конфігурації;
• образи Docker (або доступ до Registry, з якого вони будуть завантажені);
• Docker Volumes;
• бази даних;
• файли користувачів;
• SSL-сертифікати;
• секрети та змінні середовища.

 

Саме ці, але не тільки, дані мають цінність. Контейнери можна в будь-який момент створити заново, якщо під рукою є образ, конфігурація та все, що потрібно додатку для роботи.

 

 

 

 

Що робити з Docker Images

Якщо проєкт використовує образи з Docker Hub, GitHub Container Registry або власного Registry, то зазвичай ніяких складнощів не виникає. Достатньо просто завантажити потрібні версії та запустити контейнери.

docker compose pull
docker compose up -d

Docker Compose самостійно завантажить усі образи, зазначені в конфігурації.

 

Складніше справа виглядає в тому випадку, якщо в проєкті використовуються власні образи, які було зібрано локально і ніде не опубліковано. Тоді у вас є два варіанти.

Перший - це перекомпілювати їх уже на новому VPS:

docker compose build
docker compose up -d

 

Другий - зберегти готовий образ в архів, перенести його на новий сервер і там вже імпортувати.

docker save my-image:latest -o my-image.tar

Після копіювання файлу виконайте:

docker load -i my-image.tar

 

Якщо є така можливість, то краще вибрати перший спосіб, оскільки він робить процес міграції повністю відтворюваним. Це означає, що в будь-який момент можна розгорнути проєкт на іншому сервері, не займаючись перенесенням готових образів і не переймаючись тим, що якась локальна збірка була втрачена.

 

 

 

 

Найвідповідальніший етап - перенесення даних

Під час міграції Docker Compose основну увагу варто приділити даним. Контейнери завжди можна створити заново, а ось втрата вмісту бази даних або Docker Volumes майже завжди стає серйозною проблемою, оскільки більшість сучасних додатків зберігає свій стан саме там. Тому перенесення потрібно виконувати максимально обережно.

Якщо проєкт використовує PostgreSQL, MySQL, MariaDB або іншу СКБД, не варто копіювати каталог із файлами бази даних, поки вона продовжує приймати запити. Навіть якщо здається, що все пройшло успішно, після відновлення можна зіткнутися з пошкодженими таблицями або неконсистентними даними.

Надійніше буде використовувати вбудовані інструменти резервного копіювання.

Для PostgreSQL це стандартна утиліта pg_dump:

pg_dump -U postgres mydb > backup.sql

 

Для MySQL, відповідно, mysqldump:

mysqldump -u root -p mydb > backup.sql

 

Отриманий дамп переноситься на новий VPS, після чого база даних відновлюється вже на новому сервері.

Так, такий спосіб займає трохи більше часу, але зате ви отримуєте консистентну резервну копію та помітно знижуєте ризик виникнення проблем після запуску проєкту.

 

 

 

 

Перенесення Docker Volumes

Якщо додаток зберігає дані в Docker Volumes, то їх теж потрібно буде перенести на новий сервер. Саме там часто знаходяться файли користувачів, завантажений контент, кеш, службові дані та інша інформація, яка також має зберегтися після міграції.

Спочатку перегляньте список існуючих томів:

docker volume ls

 

Один із найпростіших способів перенесення - це створити архів за допомогою тимчасового контейнера, наприклад:

docker run --rm \
-v app_data:/from \
-v $(pwd):/backup \
alpine tar czf /backup/app_data.tar.gz -C /from .

 

Отриманий архів достатньо скопіювати на новий VPS-сервер. Потім створіть новий Docker Volume і розпакуйте в нього збережені дані тим самим способом, використовуючи тимчасовий контейнер.

Такий підхід вважається набагато безпечнішим, ніж спроба копіювати внутрішні каталоги Docker безпосередньо. Docker самостійно керує структурою зберігання даних, тому робота через Volumes та архівування їхнього вмісту дозволяє уникнути багатьох проблем під час перенесення проєкту.

 

 

 

 

Синхронізація файлів користувачів

Перенесення файлів користувачів зазвичай відбувається набагато простіше, ніж міграція баз даних або Docker Volumes. Тому якщо мова йде про образи, документи, резервні копії або інші завантажувані дані, то найчастіше достатньо скористатися утилітою для інкрементальної синхронізації файлів rsync.

Наприклад:

rsync -avz /var/www/uploads/ user@new-server:/var/www/uploads/

 

Головна перевага rsync полягає в тому, що під час повторного запуску він передає лише нові або змінені файли. Це дозволяє виконати першу синхронізацію заздалегідь, поки старий сервер продовжує працювати, а безпосередньо перед переключенням проєкту ще раз запустити команду й перенести лише останні зміни.

Саме так зазвичай і здійснюють міграцію інтернет-магазинів, корпоративних порталів, форумів, CMS та інших проєктів, де користувачі постійно завантажують новий контент. Такий підхід допомагає звести час простою практично до нуля.

 

 

 

 

Як скоротити час простою практично до нуля

У більшості випадків немає жодної необхідності повністю зупиняти проєкт на час міграції. Набагато зручніше спочатку перенести основну частину даних, а потім виконати коротку фінальну синхронізацію безпосередньо перед переходом на новий VPS.

Зазвичай процес виглядає так:

1. Виконується перша синхронізація файлів користувачів за допомогою rsync, поки додаток продовжує працювати;
2. Створюється та переноситься резервна копія бази даних;
3. На новому сервері запускаються контейнери, після чого перевіряється робота додатка;
4. На старому VPS увімкнюється режим обслуговування (maintenance mode) або тимчасово забороняється запис нових даних;
5. Виконується повторна синхронізація через rsync, яка переносить лише зміни, що з’явилися після першого запуску команди;
6. За необхідності переноситься актуальний стан бази даних або застосовуються останні зміни;
7. DNS-записи перенаправляються на новий сервер.

 

У результаті користувачі можуть навіть не помітити момент міграції. Зазвичай недоступними виявляються лише операції, пов’язані із записом даних, і лише на кілька секунд або хвилин - усе залежить від обсягу даних та особливостей самого проєкту.

Одна з головних переваг Docker Compose полягає в тому, що додаток можна повністю розгорнути ще до того, як користувачі почнуть звертатися до нового сервера.

Після перенесення даних достатньо виконати запуск:

docker compose up -d

 

Якщо використовуються свіжі образи з Registry, перед цим бажано оновити їх:

docker compose pull
docker compose up -d

 

Після запуску слід переконатися, що всі сервіси успішно запустилися:

docker ps

 

Також варто перевірити журнали контейнерів:

docker compose logs

або журнал окремого сервісу:

docker compose logs nginx

 

Помилки, виявлені зараз, виправити набагато простіше, ніж після переключення користувачів.

 

 

 

 

Перевірте роботу додатка перед перемиканням DNS

Перш ніж змінювати DNS-записи та переводити користувачів на новий VPS, варто переконатися, що проєкт повністю готовий до роботи. Краще витратити кілька хвилин на перевірку зараз, ніж розбиратися з помилками вже після завершення міграції.

Для початку відкрийте додаток через тимчасовий домен, локальний запис у файлі hosts або безпосередньо за IP-адресою нового сервера. Після цього перевірте кілька ключових моментів:

• додаток запускається без помилок;
• усі контейнери перебувають у стані Up;
• база даних відповідає на запити;
• файли користувачів доступні;
• авторизація та адміністративна панель працюють коректно;
• SSL-сертифікати встановлені та використовуються;
• журнали Docker не містять помилок.

Якщо проєкт працює через зворотний проксі (Nginx, Traefik або Caddy), переконайтеся, що запити коректно маршрутизуються між усіма сервісами.

Після такої перевірки можна оновлювати DNS і перемикати користувачів на новий сервер.

 

 

 

Перемикайте трафік і стежте за роботою проєкту

Коли новий VPS повністю перевірений, можна перемикати користувачів на нього. Зазвичай для цього достатньо змінити A- або AAAA-запис домену.

Якщо підготуватися заздалегідь, перехід відбудеться швидше. Наприклад, за добу до міграції можна зменшити TTL до 300 секунд, і тоді більшість клієнтів почне звертатися до нового сервера вже через кілька хвилин після зміни DNS-записів.

При цьому не варто розраховувати лише на TTL. Деякі DNS-сервери інтернет-провайдерів та корпоративних мереж кешують записи довше, ніж заявлено. З цієї причини старий VPS краще не відключати одразу після переключення. Зазвичай його залишають працювати ще кілька годин, а для великих проєктів - навіть до доби.

Однак після зміни DNS робота ще не закінчена. У перші години після міграції бажано уважно стежити за станом нового сервера: завантаженням процесора та пам’яті, дисковою підсистемою, мережевою активністю, журналами контейнерів і самим додатком. Саме в цей момент найчастіше виявляються проблеми, які не вдалося виявити під час тестування.

Для швидкого контролю знадобляться кілька стандартних команд:

docker stats
docker compose logs -f
docker events

 

Вони допоможуть вчасно помітити нестачу пам’яті, постійні перезапуски контейнерів, помилки додатка та інші проблеми, які краще усунути до того, як їх помітять користувачі.

 

 

 

План відкату та найпоширеніші помилки під час міграції

Навіть якщо перенесення було ретельно підготовлено, повністю виключити ймовірність помилок, на жаль, неможливо. Тому ще до початку міграції варто продумати сценарій відкату.

Найпростіший і водночас найнадійніший варіант - це не вимикати старий VPS одразу після запуску нового. Поки користувачі поступово переходять на новий сервер, колишня платформа продовжує працювати, дані на ній залишаються недоторканими, а за потреби достатньо повернути DNS-записи на стару IP-адресу. Після цього можна спокійно розібратися з проблемою, що виникла, і повторити міграцію пізніше.

Саме тому досвідчені адміністратори не поспішають видаляти старий сервер. Іноді критична помилка виявляється лише через кілька годин після перемикання, і можливість швидко повернутися до попередньої інфраструктури дозволяє уникнути тривалого простою.

Найчастіше проблеми виникають зовсім не через Docker. Причиною можуть стати звичайні помилки, яких легко припуститися під час перенесення.

Помилка	Наслідок
Не перенесено файл .env	Застосунок не запускається або працює з неправильними налаштуваннями
Не скопійовано SSL-сертифікати	Сайт перестає відкриватися через HTTPS
Змінилися шляхи до Docker Volumes	Застосунок втрачає доступ до своїх даних
Закрито необхідні порти у файрволі	Контейнери працюють, але сервіс недоступний ззовні
Базу даних скопійовано під час активного запису	Пошкодження або втрата даних
DNS перемкнено до завершення перевірки	Користувачі починають отримувати помилки
Не перенесено завдання cron	Перестають працювати резервне копіювання, сповіщення та фонові завдання
Не перевірено права доступу до каталогів	Виникають помилки запису файлів і журналів

 

Якщо не поспішати з переведенням користувачів і заздалегідь підготувати план міграції, то більшості цих проблем вдається уникнути. Саме тому підготовка зазвичай займає більше часу, ніж саме перенесення Docker Compose на новий VPS.

 

 

 

 

Що переносити, а що ні

Отже, підіб’ємо підсумки та зберемо все в одному місці. Під час міграції Docker Compose далеко не весь вміст сервера потрібно переносити на новий VPS. Одні компоненти необхідно зберегти в обов’язковому порядку, інші Docker без проблем створить заново.

Компонент	Потрібно переносити
docker-compose.yml	Так
.env	Так
Docker Volumes	Так
Бази даних	Так
Користувацькі файли	Так
SSL-сертифікати	Так
Docker Images	За потреби
Контейнери	Ні
Кеш контейнерів	Ні
Тимчасові файли	Ні

Якщо запам’ятати це правило, то сам процес міграції стає набагато зрозумілішим. Головне завдання всієї міграції - зберегти дані, конфігурацію та середовище додатка. Усе інше Docker здатний відновити самостійно.

 

 

 

 

Автоматизуйте майбутні міграції

Якщо перенесення Docker Compose виконується регулярно - наприклад, між тестовим, staging- та production-середовищами, то багато рутинних операцій з часом краще автоматизувати. Це скорочує час міграції та помітно знижує ймовірність помилок.

Для таких завдань найчастіше використовують:

• Ansible - для налаштування серверів та автоматичного розгортання Docker Compose;
• GitHub Actions або GitLab CI/CD - для збірки образів та автоматичного деплою;
• rsync через SSH - для синхронізації файлів користувачів;
• Docker Registry - для зберігання власних Docker-образів;
• B WatchtowerB та аналогічні інструменти - для автоматичного оновлення контейнерів, якщо такий підхід використовується в інфраструктурі.

 

Навіть часткова автоматизація позбавляє від безлічі однотипних дій. А чим менше ручної роботи під час міграції, тим нижча ймовірність припуститися помилки в найневідповідніший момент.

 

 

 

 

FAQ

Чи потрібно переносити самі контейнери Docker?

Ні. Контейнери вважаються одноразовими об’єктами, і в більшості випадків їх простіше та правильніше створити заново за допомогою Docker Compose.

 

Чи можна просто скопіювати каталог /var/lib/docker?

Технічно це можливо, але такий спосіб аж ніяк не вважається доброю практикою. Каталог містить внутрішню структуру Docker, яка залежить від версії движка, драйвера зберігання та конфігурації системи. Надійніше буде переносити дані через Docker Volumes, резервні копії баз даних та повторне створення контейнерів.

 

Чи потрібно переносити образи Docker?

Якщо образи доступні в Docker Hub або у власному Registry, то достатньо виконати docker compose pull. Експортувати їх має сенс лише в тих випадках, коли використовуються локально зібрані або недоступні ззовні образи.

 

Як довго оновлюється DNS після зміни сервера?

Якщо TTL було заздалегідь зменшено, то більшість користувачів перейде на новий VPS протягом декількох хвилин. Однак частина DNS-серверів може кешувати записи довше, тому старий сервер рекомендується залишити працювати ще деякий час.

 

Чи можна повністю уникнути простою?

У багатьох випадках - так, це можливо. Наприклад, якщо додаток допускає короткочасну зупинку запису даних, а перемикання виконується після попередньої синхронізації файлів і тестування нового сервера, більшість користувачів взагалі не помітить міграцію.

 

Що робити з SSL-сертифікатами?

Якщо використовуються власні сертифікати, їх необхідно перенести разом із закритими ключами. При використанні Let's Encrypt можна або перенести існуючі сертифікати, або повторно випустити їх уже на новому сервері після завершення міграції.

 

 

 

Висновок

Отже, ми з'ясували, що перенести проєкт з Docker Compose на новий VPS-сервер без простою цілком реально. І для цього не потрібні складні інструменти чи нестандартні рішення, а достатньо правильно організувати сам процес міграції.

Головна думка, яку варто запам'ятати, проста: переносити потрібно не контейнери, а інфраструктуру навколо них. Конфігурацію, бази даних, Docker Volumes, файли користувачів, сертифікати, змінні середовища та інші компоненти, без яких додаток не зможе працювати - переносимо, а самі контейнери за необхідності завжди можна створити заново.

Якщо новий сервер підготовлено заздалегідь, усі дані перенесено безпечним способом, додаток повністю протестовано до перемикання DNS, а старий VPS залишається доступним на випадок відкату, то для більшості користувачів міграція пройде практично непомітно. Саме такий підхід дозволяє переносити Docker Compose між серверами без тривалого простою та зайвого ризику.