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

Ага, понял
Но смысл один и тот же получается, из которого, я надеюсь, я делаю правильные выводы:
1) Весь проект надо все равно держать в формате гит-репо; (а не предподготовленного образа с предустановленным окружением)
2) Так или иначе должны быть сохранены dockerfile(s) и docker-compose.yml
3) Процесс запуска заключается в клонировании файловой структуры из загруженного репо в контейнер, пробросе портов, запуске сервисов etc - это все должен покрывать docker-compose

3 пункт не такой

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

а. тут обратный пример

Я джангу у себя так упаковываю:

FROM python:3.6

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        postgresql-client ssh git \
    && rm -rf /var/lib/apt/lists/*

VOLUME ["/articles"]
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip3 install --upgrade pip && pip3 install -r requirements.txt
COPY . .
EXPOSE 8000
ENTRYPOINT ["/bin/sh", "./run.sh"]

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

Спасибо большое!

Я извиняюсь, кажется остался таки один вопрос :)
Почему, например, не используется такой вариант:

докер-файл в котором на основе образа, например, python3;
помимо прочих дефолтных операций производится git clone, pip3 install -r requirements.txt и сопутствующие созданию окружения команды.

Ну и все, как всегда, обернуто в docker-compose с дефолтными сервисами

Это, получается, почти как у вас, если я правильно понимаю, только за исключением одного момента:
вам не нужно заботиться о том, чтобы чтобы свежая версия была загружена где-нибудь на localhost, возиться с путями (ну вдруг какие-то ограничения появятся), все что вам нужно будет, по идее - docker, docker-compose, и dockerfile основного проекта и docker-compose.yml, и вы сможете собрать этот образ заново где угодно.

Если я правильно понимаю :)

если ты билдишь через раннер, то там отпадает нужда в git clone. раннер сам тебе все подготовит. Если ты билдишь локально, то тем более клонировать ничего не надо.
Ну и в регистри хранить по имени ветки/хэшу коммита/как угодно.

Там и так не надо возиться с путями. docker build -t <registry image url>:<tag> .

вопрос свежести версий как-то вторичен. Есть, например, 3 ветки, для каждой ветки будет свой образ называться свежим

Пошел читать дальше, спасибо :)

В чем код-то храните? битбакет/гитлаб/гитхаб/Etc?

Github/публичный

Может, мои данные устарели, но CI еще пару месяцев назад был платным. Так что подсказать ничего не смогу. На гитлабе бесплатный. Даже на официальном сайте

Так бы там можно было вписать, что при пуше в ветку надо собирать образ. (Регистри на гитлабе, кстати, тоже есть)

> вам не нужно заботиться о том, чтобы чтобы свежая версия была загружена где-нибудь на localhost, возиться с путями (ну вдруг какие-то ограничения появятся)

Это уже задача CI. не надо это делать вручную со своего компа, так как чревато человеческими ошибками.

На будущее - зафиксировал, но пока сфокусируюсь на самом docker, боюсь уйти в глубокую прокрастинацию. ))