Docker, часть вторая. Полуавтоматическая винтовка с самонаведением на ногу

Смотрите:
Port 80 -> Docker -> Nginx -> uWSGI -> Django -> My Code

1. Общепринятое мнение, что веб-фреймворк — это Django.
2. Мнение в духе Docker: веб-фреймворк — это всё что от Docker и до Django.

В первом случае мы говорим о том, что есть какой-то сайт, сделанный на фреймворке Django, и его нужно запускать на каком-то веб-сервере. Во втором случае мы говорим о том, что есть какой-то сайт, сделанный на фреймворке «Docker/Nginx/uWSGI/Django» и его можно запускать на любой «голой» ОС.

1. Всё верно: программист делает «детский конструктор из кубиков», а «админ из этих кубиков в своей песочнице строит какую-нибудь крепость».
2. Вы не должны принимать решения, которые зависят от среды исполнения. Количество воркеров — это такой же конфигурационный параметр, как коннекшн стринг к базе. Совершенно точно будут параметры, которые вы захотите железно захардкодить и запретить админам их изменять, но будут и параметры, которые вы захотите сделать частью интерфейса. Например внутренний параметр «количество воркеров Nginx» вы можете пробросить как внешний параметр «количество ядер для использования». Типа абстракция такая.

все установится и запустится само, без участия админа

Очень смелое утверждение, причём особенно касательно production. Без участия админа пробросятся 80 и 443 порт? Без участия админа установится сам докер?

commit и push изменят эти настройки у всех в команды разработчиков, а мне совсем не нужно значение innodb_buffer_pool_size=32Gb на локальной виртуалке

commit без push… а зачем? там они потеряются при выкладке новой версии. пусть они лежат все вместе в отдельной папке прямо под рукой у админа и монтируются в контейнер, не надо открывать shell в контейнере чтобы отредактировать конфиг, а в контейнере пусть лежат дефолтные значения,

Вот, например:

Открываю документацию любого официального образа сервисного ПО — например, Nginx и нахожу раздел «How to use this image». Нам предлагают создать свой образ на базе официального, скопировав в него наши файлы, настроить мапинг порта в мир, и подмонтировать свою папку с конфигами.

FROM…
COPY. /usr/src/myapp
WORKDIR /usr/src/myapp

Да, нам предлагают унаследовать Model от View в одном звездном классе и заплатить за хранение на Docker Hub образов наших проприетарных приложений.

1. Пример приведён из доков по php, хотя по тексту об nginx речь идёт.

2. Предлагают, первым делом, не унаследовать «звёздный класс» типа

class DockerNginx extends DockerDebian
{
    public function __construct()
    {
        $this->install('nginx');
        /// some other init...
    }

    public function run()
    {
        $this->cmd('nginx')
    }
}

, а инстанцировать и запустить его, предварительно установив свойство /usr/share/nginx/html. Типа

$some_nginx = new DockerNginx();
$some_nginx->fs->root->share->nginx->html = $host->fs->pwd->static-html-directory;
$some_nginx->run();

Во вторую очередь предлагают унаследовать «звёздный класс», переопределив это свойство (относящееся в рамках nginx исключительно к Model, если рассматривать его как MVC приложение) в конструкторе, типа:

class SomeContentNginx extends DockerNginx
{
    public finction __construct()
    {
        $this->fs->root->share->nginx->html = clone ($host->fs->pwd->static_html_directory);
    }
}

$some_nginx = new SomeContentNginx();
$some_nginx->run();

То есть продемонстрированы две основные возможности изменения функциональности объекта: инъекция желаемой зависимости в объект вместо дефолтной после инстанцирования объекта перед началом его использования и унаследование класса в котором желаемая зависимость устанавливается при его инстанцировании перед началом использования. За рамками документации класса DockerNginx остаются как другие способы инжектирования Docker, так и свойства, которые можно инжектировать в Nginx, поскольку предполагается, что пользователь, которому они нужны достаточно знаком с обеими системами или хотя бы способен почитать документацию по ним, чтобы максимум за пару часов собрать свой универсальный образ согласно своим практикам использования nginx и Docker, например использования его во всех своих проектах с помощью docker-composer, подключая тома или линки.

3. В данной документации вообще ничего не говорится о хранении наших «проприетарных» образов, даже их создание преподносится лишь как один из доступных вариантов решения задачи, а платное хранение на официальном хабе докера тоже лишь как один из вариантов в документации по докеру, который (вариант) хорошо подходит для случая, когда в паблик образ выкладывать нежелательно, шарить образ (или его докерфайл) между разработчиками, админами, тестерами и т. д. универсальными средствами (ОС, шаред в локалке, облачные сервисы хранения файлов и т. д.) неудобно, а поднимать свою инфраструктуру докера нет желания или возможности.

С удовальствием бы с вами поспорил буть бы сейчас время, в замену предлагаю вам ещё раз перечитать коментарии других пользователей и хорошенько над ними помидитировать.

symphony и doctrine (вроде как клон hybernate на php) как раз исповедуют принцип «напишите простой конфиг, а всю чёрную работу мы сделаем за вас»

Какая связь?