Удаленный деплой с помощью docker-compose на GitHub Actions

Чем дольше знакомишься с темой, тем больше замечательных и простых вариантов находишь для выполнения своих задач. Деплой своего проекта — крайне обширная тема, и очень тяжело избежать ловушки мышления, когда пытаешь сделать на удаленной машине так же, как ты делаешь на своей.

Допустим, как работает docker-compose? Ему необходим файл docker-compose.yaml, в котором описаны все контейнеры и их связи, а также от одного до бесконечности файлов Dockerfile, которые помогут собрать образы. Также всякие конфиги nginx, файлы с переменными окружения .env. И первое желание — перенести все эти файлы на удаленный сервер с помощью ssh или scp и начать разворачивать там руками.

Но есть гораздо более правильный путь (This is the way). Наша задача копнуть чуть глубже и попробовать развернуть наши контейнеры на удаленном сервере без каких либо файлов в принципе. Не верите?

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

docker context ls

Вы увидите этот слой с настройками, его имя default *, где астериск означает, что данный контекст (слой, файл с настройками) в данный момент активен.

Если мы хотим создать новый контекст (опять-таки, для удобства думайте о нем как о файле с настройками), то нам нужно выполнить несколько условий:

1. У нас должен быть приватный ключ SSH
2. На сервере должен быть соответствующий ему открытый ключ
3. Мы должны знать IP адрес сервера. Можно настроить и по домену, но, как показала практика, IP адрес дает более надежную идентификацию хоста
4. Наш хост должен быть знаком нашему компьютеру, чтобы избежать лишних вопросов про то, доверяем ли мы ему

Пункты в целом несложные, последний вообще можно исполнить без SSH подключения к серверу:

ssh-keyscan -H 192.168.1.162 >> ~/.ssh/known_hosts

Таким вот образом указанный выше IP будет с этого момента доверенным.

Теперь давайте создадим новый контекст настроек. Типовая команда выглядит так:

docker context create remote --docker "host=ssh://user@$host_ip"

В данной строке есть команда create (создать), имя нашего нового контекста remote и хост, где работает Docker. Дело в том, что докер может управлять не только докером, но и целым swarm или Kubernetes. Это все системы оркестрации, где вы можете (как дирижер оркестра) управлять деплоем на сотни машин, про них позже, сейчас мы просто прокладываем мост между двумя докерами, самое простое решение, поэтому ключ пишем --docker.

Попробуйте обязательно эту команду на своей локальной машине, указав удаленный хост. После этого у вас в списке контекста появится новый пункт — remote! Это значит, что теперь мы можем управлять нашей машиной на расстоянии, для этого нам нужно применить настройки этого контекста командой:

docker context use remote

Теперь * астериск будет стоять напротив пункта remote в списке контекстов. Не забудьте потом переключиться обратно на default, когда закончите.

Ну что, проверим магию? Давай посмотрим список контейнеров на удаленном хосте командой…

docker ps

Именно! Все обычные команды, которые мы выполняли на локальной машине, подходят и теперь, только общаются они с удаленным сервером!

Если у нас крутятся какие-то контейнеры, то давайте их все остановим и удалим, чтобы развернуть наш удаленный docker-compose. Раньше я предлагал ввести следующие команды:

docker kill $(docker ps -q)
docker rm $(docker ps -a -q)

Но этот способ слишком ультимативный. А если на сервере есть еще проекты? Ведь они все упадут. Поэтому новый вариант выглядит так:

          docker pull dockerhubname/image:latest
          docker-compose --context remote down
          docker volume rm foodgram-project_static

Объясню, что здесь происходит. Мы стягиваем свежий образ нашего проекта с докерхаб, затем очень нежно выключаем наш проект с помощью встроенной в docker-compose функции down. Дальше я запускаю профилактическое удаление тома со статикой, так как она может обновиться в процессе разработки. В вашем случае нужно подставить правильное название тома, узнать его можно командой:

docker volume ls

Теперь самое время запустить docker-compose. Здесь важно понимать, что docker и docker-compose, несмотря на очевидное сходство в названии, по сути своей разные программы для выполнения разных задач. Раньше они вообще мало были связаны, сейчас интеграция становится все лучше и лучше. Совсем недавно docker-compose научился работать с контекстами docker, но пока это происходит не в автоматическом режиме после использования команды use, а с помощью специального флага —context. Перейдите в директорию с файлом docker-compose.yaml и выполните команду:

docker-compose --context remote up -d --force-recreate

Смотрите, мы используем контекст remote, поднимаем наши контейнеры в -d режиме (чтобы не видеть вывод) и на всякий случай силой их пересоздаем, если на сервере остались какие-то контейнеры с подобным названием. Все зависимости у нас под рукой — переменные окружения, yaml файл и прочие. Убедитесь, что все ваши контейнеры создаются на основе образов, а не собираются из файлов.

В идеальном мире вы получите контейнеры, развернутые на вашем сервере. Проверьте, работает ли сайт по нужному адресу и порту.

Справка по контексту доступна на сайте докера.

GitHub Actions

Как нам применить эти знания к деплою проекта с помощью GitHub Actions?

Алгоритм будет следующий:

1. Создаем виртуальную машину
2. Разворачиваем наш репозиторий (можно не ставить зависимости, нам нужны только файлы): actions/checkout@v2
3. Устанавливаем Python 3.8: actions/setup-python@v2
4. Устанавливаем наш SSH KEY в виртуальную машину и добавляем наш IP в доверенные хосты. Очень поможет вот этот action.
5. Устанавливаем последнюю версию докера, чтобы она могла управлять всеми другими версиями докера, в том числе и младшими (используйте sudo pip install docker-compose, в текущей версии по curl есть критический баг с OpenSSL и вы точно не хотите с ним провести пару часов)
6. Создаем переменные окружения по инструкции
7. Создаем пустой файл .env (почему-то без него docker-compose на сервере не может перейти к этапу просмотра переменных окружения в системе, на локальной машине таких проблем нет). Поможет команда touch .env
8. Запускаем все наши команды из статьи выше, не забыв заменить секретные данные переменными окружения.

Вот и все. Получилось, что весь деплой уместился в 6 строчек, если не считать объявления переменных окружения и установки зависимостей.