Comments 24
# ---STAGE-3---
# Стадия сборки зависимостей приложения для dev среды
FROM base-pdm-builder AS development-pdm-builder
RUN pdm install --check --dev
# ---STAGE-4---
# Стадия сборки зависимостей приложения для test среды
FROM base-pdm-builder AS test-pdm-builder
RUN pdm install --check -G test --no-self
# ---STAGE-5---
# Стадия сборки зависимостей приложения для prod среды
FROM base-pdm-builder AS production-pdm-builder
RUN pdm install --check --production --no-self
# ---STAGE-6---
# Базовая стадия сборки зависимостей для python образа
FROM python-base AS base-project-builder
Это противоречит всем современным практикам: один образ - много окружений, но никак не собирать разные образы под разные окружения
Я вижу что это про локальную разработку, но ведь когда-то это попадет на прод, и крайне желательно иметь единообразие между разными окружениями, меняется лишь инфраструктура вокруг
А как поступать, если вам необходимо доставлять образ в продакшн среду клиента предварительно обфусцировав код?
Не силён в Джанго, его значит можно деплоить как ASGI-приложение. Допустим, тогда вопрос, зачем gunicorn и uvicorn-worker? Ведь в Докер-окружении одного uvicorn достаточно.
Года 4 назад видел именно такой пример запуска, он прижился у меня в проектах, почитаю подробно свежую документацию, Спасибо за комментарий!
Спасибо что поделились, всегда интересно смотреть как это устроено у других.
Удобно конечно когда весь проект в одном репозитории, хотя и возникают вопросики - а что делать когда придётся использовать второй/третий репозитории? Проекты имеют обыкновение расти и распиливаться на микросервисы. Либо волевым решением постановить что будет монорепо, либо выносить конфигурацию запуска в отдельный репозиторий.
Я выбрал второй вариант. Я работаю с проектами, где в каждом несколько десятков репозиториев с кодом - приложения и библиотеки. Ну и им необходим десяток сервисов - база, редис и т.д.
Чтобы это не превратилось к гигантский монолитный docker-compose.yml файл, созданы отдельные файлы под каждый компонент. Ну а чтобы облегчить типовые операции над приложениями написана утилита elc. А все конфиги необходимые для запуска приложений и сервисов проекта вынесены в репозиторий
Мискликнул и отклонил один комментарий. Кто бы ты ни был, прости...
pipelines # пайплайны GitLab
Не надо так, ведь есть стандартная директория .gitlab
Да, к сожалению переместить туда .gitlab-ci.yml нельзя, но можно сделать его буквально из одной строки
include: ".gitlab/ci.yaml"Тоже не знал, спасибо, поправлю у себя в проектах
к сожалению переместить туда .gitlab-ci.yml нельзя, но можно сделать его буквально из одной строки
в настройках конкретного проекта CI/CD -> General pipelines можно переопределить путь, удобно когда репозиторий кочует между гитлабами
Это да, в целом то можно
и даже
для self-hosted gitlab'а в admin area можно для всех реп задать (Settings -> CI/CD -> Continuous Integration and Deployment -> Default CI/CD configuration file)
но для этого должны быть права не ниже maintainer (а то как бы и не owner, тут не помню)
репозиторий кочует между гитлабами
Ну не знаю, ИМХО наоборот не удобно отходить от пути по умолчанию - это ж при каждом переезде надо помнить про эту кастомизацию
Рекомендую рассмотреть использование утилиты mise - сильно упрощает работу с окружением per-project, например позволит схлопнуть все .env и .python-version (раз статья в разрезе python разработки) файлы и кастомные скрипты автоматизации (как например создание локальных файлов из статьи) в единый формат
ээ пропустил похоже. а что, без тестов, сразу в продакшн? Может все же tests папку и какие нить тесты запустить?
И еще не нашел где докер статику собирает. Или вы как-то иначе ее раздаете, типа глобально?
Интересная статья, сохранил.
Был у меня в работе репозиторий netbox, в котором имелся файл release.yaml и если его создать локально, изменив данные, а затем прокинуть в контейнер (volume), то будет отображаться информация из этого файла.
Так вот, в dev окружении появилась хотелка указывать вместо даты релиза самого netbox - дату коммита (да, локально ещё дорабатывалось всякое свое) плюс сам GIT commit.
Ручками это делать это просто будет невозможно, всякие разделения tenant в environment файле были завязаны на другую логику (код legacy).
Что сделал - дополнительно стал использовать makefile с его целями up (завязано несколько команд, в том числе Docker compose down, up) и devup (всё то же самое, только плюс манипуляция с файлом release.yaml)
Как считаете, makefile в вашем случае был бы излишне? Просто лично мне удобно и быстро набирать ряд команд
export ENV_FILE=.env.dev # устанавливаем с каким environment работаем
make devup
Давайте писать удобное локальное окружение…