GitHub Actions, Docker, GitHub Registry

ntdesmond — Sat, 07 Jan 2023 21:36:17 GMT

Долго соображал, куда можно засунуть Docker-контейнеры для одного проекта — не пихать же их на личный аккаунт Docker Hub? Поднимать свой registry тоже так себе вариант... Изучал тему, и обнаружил интересную штуку — GitHub Packages, которая включает в себя GitHub Container Registry (GHCR). Иными словами, это Docker Registry от гитхаба, который можно юзать бесплатно для открытых репозиториев, при этом настроить доступ к самому package (аналог image в Docker Hub) можно отдельно.

А что значит хостинг на самом GitHub? Правильно, более простая настройка GitHub Actions для сбора и выгрузки образа Docker. Самое крутое, что можно сделать универсальный файл workflow, который будет достаточно закинуть в любой репозиторий, чтобы контейнер собирался и выгружался на ghcr.io.

К примеру, вот такой workflow при каждом обновлении ветки соберет и выгрузит образ с тем же названием, что и у репозитория, при этом между запусками кэш будет сохраняться в том же ghcr.io под тегом buildcache.

Впрочем, этот самый buildcache может не очень красиво смотреться

На что стоит обратить внимание (на чем я споткнулся при настройке пайплайна):

Workflow должен иметь разрешение на запись в packages. В противном случае он будет валиться с ошибкой 403 при попытке выгрузить образ. Впрочем, если не указывать permissions вообще, должно по умолчанию быть разрешено работать с packages.

permissions:
  contents: read
  packages: write

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

По умолчанию стоит только Private, несмотря на Inherit access

To sum up, настроив один раз Packages в организации и написав универсальный workflow, можно штамповать его везде и не париться о выгрузке контейнеров.

Python + Docker multi-stage build

ntdesmond — Fri, 16 Sep 2022 19:32:51 GMT

Все началось с того, как я по привычке использовал в учебном проекте venv в Docker-контейнере, на что мне в код-ревью сказали, что это просто трата ресурсов. Поискал в инете, люди говорят, что на самом деле особо пофиг, есть venv или же нет — как удобно, так и делай.
Однако, еще нашлось одно очень хорошее применение для использования виртуальной среды: раздельная установка зависимостей и запуск кода с помощью билда контейнера в несколько (2.00) этапов.

Суть в том, что можно создать venv на одном этапе, установить в него зависимости, а потом на новом этапе просто скопировать venv целиком с предыдущего этапа.
Такой подход позволяет использовать на последнем этапе более легковесные образы python (в моем случае для запуска хватило 3.10-alpine), при этом сохраняя все необходимое для установки зависимостей (много где требуется наличие gcc, например).
В моем случае вес итогового образа уменьшился практически в 8 раз (1.03GB -> 146MB).

Но.. даже тут я умудрился споткнуться и у меня произошла интересная ситуация (picrelated): вроде бы исполняемый файл есть, а запустить его нельзя.
Я так и не выяснил конкретную суть проблемы, но ради интереса заглянув в .venv/bin/activate обнаружил, что пути там указаны как /.venv а не /app/.venv, как это должно быть.

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