Собираем docker и деплоим из GitHub Actions

Я приведу краткую инструкцию, как быстро собирать проект и деплоить docker. Времена докера никуда не ушли, все мелкие проекты мы до сих пор делаем на обычных докерах, а также там, где всё on-premise и не дают облака с Kubernetes. Сопровождать Kubernetes самим — то еще удовольствие, особенно, когда заказчики не выделяют бюджеты на «золотых» (Ваня, привет!) devops-еров.

Флоу будет очень простым: одним job мы собираем образ (с указанием тэга или ветки) и кладем в приватный репозиторий образов GitHub, а другим job деплоим оттуда. Это удобно, когда есть несколько сред и мы один раз собираем и контейнер запускаем из него с разными переменными среды. И важное условие: мы не устанавливаем docker-compose или github runner на сервер с docker.

Начнем.

Сборка образа

Дано: очень простой образ для приложения на python. Это не образец безопасности и multistage, просто пример Dockerfile:

FROM python:3.10-slim  WORKDIR /app/  RUN python -m pip install --upgrade pip  COPY requirements.txt . RUN python -m pip install -r requirements.txt  COPY ./ .  EXPOSE 8501 CMD ["streamlit", "run", "app.py"]

Для его деплоя применяется docker-compose.yml

version: '3'  services:   bot:     image: ${IMAGE_REF}     container_name: globe     restart: always     environment:       - OPENAI_API_KEY=${OPENAI_API_KEY}     ports:       - "8501:8501"

В данном случае у нас всего две переменные среды, которые необходимо прописать. Первый параметр — ссылка на образ, а второй — API-ключ. Мы, например, для всех проектов и сред всегда используем разные API-ключи (в данном случае для OpenAI), чтобы отслеживать расходы.

Файл для экшена сборки .github/workflows/build.yml:

name: Build and Push Docker Image  on:     push:         branches:             - '*' env:     REGISTRY: ghcr.io     IMAGE_NAME: ${{ github.repository }}  jobs:     build:         runs-on: ubuntu-latest          steps:             - name: Checkout code               uses: actions/checkout@v4              - name: Log in to the Container registry               uses: docker/login-action@v3.0.0               with:                 registry: ${{ env.REGISTRY }}                 username: ${{ github.actor }}                 password: ${{ secrets.GITHUB_TOKEN }}                    - name: Extract metadata (tags, labels) for Docker               id: meta               uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7               with:                 images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}                          - name: Build and push Docker image               uses: docker/build-push-action@v5.3.0               with:                 context: .                 push: true                 tags: ${{ steps.meta.outputs.tags }}                 labels: ${{ steps.meta.outputs.labels }}                 

Разберем чуть подробнее:

1. Сборка контейнера происходит по каждому пушу кода в git. В простых проектах это ок, в сложных вы должны навесить дополнительные условия по папкам, веткам и т.п.

2. Забираем исходный код;

3. Логинимся в репозиторий контейнеров GitHub ghcr.io;

4. Получаем имя текущей ветки кода;

5. Собираем и пушим docker-образ.

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

А в репозитории видим новый docker-образ, пример:

Деплой контейнера

Мы уже собрали образ, теперь пора и задеплоить на сервер.

В свойствах GitHub-репозитория нужно добавить секреты либо для всего репозитория, либо для конкретного environment (dev, staging, production etc.).

1. OPENAI_API_KEY — API-ключ внешнего сервиса

2. SSH_HOST — сервер, куда деплоим

3. SSH_PRIVATE_KEY — приватный ssh-ключ

4. SSH_USER — имя ssh-пользователя

Важно, в целях безопасности не следует на серверах открывать ssh всем подряд, лучше ограничить по IP-адресу GitHub Runner облачного или hosted. Желательно также перед вашим сервером с докером поставить балансир человеческий или nginx на отдельном сервере.

Пример скрипта деплоя .github/workflows/deploy.yml:

name: Deploy  env:   REGISTRY: ghcr.io   IMAGE_NAME: ${{ github.repository }}    on:   workflow_dispatch  jobs:   deploy:     runs-on: ubuntu-22.04     environment: production      steps:       - name: Checkout          uses: actions/checkout@v4.1.1         env:           GIT_TOKEN: ${{ secrets.GITHUB_TOKEN }}         with:           fetch-depth: 0        - name: Install ssh keys         run: |           install -m 600 -D /dev/null ~/.ssh/id_rsa           echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa           ssh-keyscan -H ${{ secrets.SSH_HOST }} > ~/.ssh/known_hosts           docker context create remote --docker host=ssh://${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}        - name: Extract metadata (tags, labels) for Docker         id: meta         uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7         with:           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}        - name: Log in to the Container registry         uses: docker/login-action@v3.0.0         with:           registry: ${{ env.REGISTRY }}           username: ${{ github.actor }}           password: ${{ secrets.GITHUB_TOKEN }}        - name: Docker compose         env:           IMAGE_REF: ${{ steps.meta.outputs.tags }}           OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}         run: |           docker-compose --context remote -f docker-compose.yml up -d        - name: cleanup         run: rm -rf ~/.ssh

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

Предпоследним шагом выполняем docker-compose с новым контекстом. Новый образ автоматом скачается и задеплоится на нужном сервере.

Последним шагом удаляем SSH-ключи.

Данный job запускается руками (вы можете сделать автоматически) из меню Actions

Заключение

Приведенное руководство позволит разработчику самостоятельно сделать деплой без devops-специалиста, но, очевидно, следует использовать этот туториал с головой и адаптировать под ваши задачи и требования безопасности.

_{PS. Написано без привлечения ChatGPT}