Docker и GitLab помогают малому бизнесу обновлять сайт на VPS по понятному сценарию: разработчик меняет код, GitLab проверяет проект и запускает новую версию контейнера. Такой подход снижает количество ручных действий, упрощает возврат к предыдущей версии и делает процесс понятным даже для небольшой команды. В статье разберём схему, подготовку VPS, настройку GitLab CI/CD и ошибки, из-за которых обновление сайта может остановиться.
Зачем малому бизнесу автоматизировать обновление сайта?
Когда сайт обновляют вручную, администратору приходится подключаться к серверу, загружать файлы, менять настройки и проверять результат. Один пропущенный шаг может привести к ошибке в конфигурации или к запуску неполной версии проекта. При автоматическом развёртывании порядок действий записан в файле GitLab CI/CD и повторяется одинаково при каждом выпуске.
Docker изолирует приложение вместе с его зависимостями. Сайт запускается внутри контейнера, а сервер хранит отдельные настройки, данные базы и загруженные пользователями файлы. Благодаря этому перенос проекта на другой VPS проходит предсказуемее: администратор разворачивает тот же образ и подключает нужные хранилища.
Для малого бизнеса особенно полезны четыре результата:
- обновление запускается после проверки кода;
- версию приложения можно привязать к конкретному коммиту;
- ошибочную сборку можно заменить предыдущей;
- на сервере остаётся меньше ручных операций.
Автоматизация не отменяет резервное копирование. Код хранится в GitLab, но база данных, загруженные изображения и файлы конфигурации требуют отдельной копии. Для этой задачи пригодится резервное копирование на VPS.
Какую схему развёртывания выбрать?
Для небольшого сайта достаточно одной VPS и одного GitLab-проекта. В репозитории находятся исходный код, Dockerfile и файл с описанием сервисов. На сервере работают Docker, обратный прокси и контейнер приложения. Если проект использует базу данных или очередь задач, их можно подключить отдельными контейнерами.
| Компонент | Задача | Что хранить отдельно |
|---|---|---|
| GitLab | Хранит код, историю изменений и сценарий CI/CD | Переменные доступа и секреты |
| Docker | Собирает и запускает контейнер приложения | Данные, которые нельзя терять при пересоздании контейнера |
| Обратный прокси | Принимает запросы домена и передаёт их приложению | Конфигурацию домена и сертификаты |
| VPS | Запускает контейнеры и обслуживает сайт | Резервные копии и журналы |
Сценарий зависит от типа сайта. Для статического проекта GitLab может собрать файлы и передать их веб-серверу. Для приложения с серверной частью CI/CD собирает Docker-образ, отправляет его в реестр и запускает нужный тег на VPS. В обоих случаях важно разделять код и данные: удаление контейнера не должно удалять базу или пользовательские загрузки.
Как подготовить VPS к работе с Docker?
Сначала создайте отдельного пользователя для администрирования и отключите привычку работать под учётной записью с неограниченными правами. Затем установите обновления системы, настройте сетевой экран и ограничьте доступ к SSH. Пароль не стоит использовать как единственный способ входа, если сервером управляет несколько человек.
На VPS установите Docker и инструмент для запуска нескольких контейнеров. В конфигурации опишите приложение, базу данных, сеть, тома и переменные окружения. Секреты не помещайте в репозиторий: пароль базы, ключи и токены передавайте через защищённые переменные GitLab или отдельный файл на сервере с ограниченными правами.
Перед первым автоматическим запуском проверьте ручной сценарий. Контейнер должен запуститься, приложение должно видеть базу данных, а обратный прокси должен передать запрос на правильный внутренний порт. Для сайта с доменом также потребуется HTTPS и автоматическое обновление сертификата. Практическая инструкция по этой части описана в материале о настройке бесплатного SSL на VPS.
После запуска проверьте журналы контейнеров и состояние диска. Логи помогают понять, почему приложение не стартовало, а свободное место показывает, не накопились ли старые образы. Для постоянного контроля можно настроить мониторинг VPS для малого бизнеса.
Как настроить GitLab CI/CD для обновления приложения?
В корне проекта создайте файл .gitlab-ci.yml. В нём указывают этапы сборки, проверки и публикации. Названия этапов могут отличаться, но логика обычно выглядит так: GitLab получает код, собирает образ, запускает тесты и передаёт результат на VPS.
- Соберите Docker-образ из Dockerfile. В нём задайте базовый образ, установку зависимостей, копирование файлов и команду запуска приложения.
- Запустите проверку. Это может быть тест синтаксиса, проверка зависимостей или короткий запуск контейнера с тестовой конфигурацией.
- Присвойте образу понятный тег. Для этого подходит идентификатор коммита или отдельный тег релиза.
- Опубликуйте образ в реестре контейнеров GitLab.
- Передайте на VPS команду обновления. Сервер загрузит новый образ, остановит старый контейнер и запустит новую версию.
- Проверьте доступность сайта и завершите старый контейнер только после успешной проверки.
Для рабочего сервера лучше разделить ветки. Изменения сначала попадают в ветку разработки, затем проходят проверку и только после этого отправляются в основную ветку. В GitLab можно добавить ручное подтверждение для публикации: сборка подготовит релиз, а запуск на VPS произойдёт после отдельного действия администратора.
Сценарий публикации должен уметь вернуть предыдущую версию. Проще всего хранить несколько образов с тегами и при ошибке запускать последний рабочий тег. Такой откат не восстановит удалённые данные базы, поэтому миграции базы выполняйте отдельно и заранее продумывайте обратимый план.
Как защитить автоматический доступ к VPS?
GitLab Runner не должен входить на сервер по общему паролю. Для CI/CD создайте отдельный SSH-ключ с минимальными правами. Закрытую часть ключа сохраните в защищённых переменных проекта, а открытую добавьте только пользователю, который запускает развёртывание.
Ограничьте, какие команды разрешено выполнять из pipeline. Если сценарий запускает произвольные команды с правами администратора, ошибка в файле CI/CD затронет весь сервер. Для небольшого проекта лучше выделить отдельного пользователя для публикации и разрешить ему только необходимые операции с Docker и каталогом приложения.
Не передавайте секреты в текст вывода сборки. Пароли могут попасть в журнал GitLab через команду с включённым подробным режимом. После изменения ключа или пароля старое значение нужно удалить из переменных и конфигурации, а затем проверить, что новый доступ работает.
Какие ошибки чаще всего мешают обновлению?
- Данные записываются внутрь контейнера. После пересоздания контейнера база или загруженные файлы исчезают. Используйте постоянные тома и отдельные резервные копии.
- В образ попадают секреты. Пароли нельзя хранить в Dockerfile и открытом репозитории. Передавайте их при запуске через защищённые переменные.
- Все изменения публикуются сразу. Без проверки ошибочный коммит может попасть на рабочий сайт. Добавьте тестовый этап и ручное подтверждение релиза.
- Старые образы не удаляются. Диск VPS постепенно заполняется. Установите правило очистки образов, но оставьте версии, которые нужны для отката.
- Прокси указывает на старый порт. После смены конфигурации контейнера сайт может отвечать ошибкой. Проверьте внутреннюю сеть Docker и настройки прокси.
- Откат меняет только код. Если новая версия изменила структуру базы, возврат старого образа может не решить проблему. Для миграций подготовьте резервную копию и отдельную процедуру восстановления.
Для сайта на VPS рабочая схема начинается с описания инфраструктуры в файлах, хранения данных вне контейнеров и понятного процесса отката. На этой неделе можно сделать три шага:
- Соберите Docker-образ и запустите его вручную на тестовом VPS или отдельном порту.
- Добавьте в GitLab этапы сборки и проверки, не публикуя секреты в репозитории.
- Настройте автоматическое обновление только после успешной проверки, резервное копирование и мониторинг доступности.
