Ну вот коллега el777 верно говорит. Я рассматриваю тут ситуацию как системщик, а не разработчик. стоимость связки nginx-elastic-api будет ощутимо дешевле, чем любые варианты с celery/rabbit/DB. Собственно жто вопрос разделяемых ресурсов. Когда писем не очень много — это не важно, когда начинаешь масштабироваться — то вопрсо встает совсем под другим углом.

ну у парсера будет задержка 5-10 минут, а если грамотно класть логи, например в тот же elasticsearch, то все будет зависеть от скорости реиндекса. У меня около 30 секунд. На объемы от 100ГБ до пары-тройки Тб. И тут API будет дергать ES, именно когда клиент запрашивает. То есть почти рилтайм. А при открытии API нагрузка на бекэнд машины будет меньше.

Вопрос, а поему бы не пойти "ленивым" путем по учету открытия пикселя — то есть считать это по логам nginx?

Думаю, что бсдя кому-то хороша. Из того, что имею я у себя (только о серверах):

1. Сопровождение какого-то дополнительного ПО — геморой. Причем еще какой. Автоматизировать пересборку пакетов при изменении зависимостей почти не реально. Сопровождение манифестов сборки — еще тот процесс. Может я его не знаю, тогда покажите, хоть что-то похожее на OBS для бсди.
2. Не предсказуемое поведение систем управления конфигурацией, при наличии геторогенной *nix среды выливается в кучу каких-то обвязок и условных ветвлений.
3. Не всегда предсказуемое поведение интерпретируемого кода, сталкивался с ruby/python/lua. Что, снова, ведет к каким-то обвязкам.

Собственно, в случае большой гетерогенной среды и ориентировки большинства ПО на линукс, приводит к тому, что наличие бсди увеличивает вдвое затраты на поддержку.

За den-o-matic спасибо, интересно. В остальном, любое CI прекрасно до того момента, пока вы не зависите от управления зависимостями при сборке пакета, когда в зависимости от одного, надо сделать ребилд пары сотен.

Возможно. Хотя мне кажется можно сделать иначе.

1) опять же, ваш выбор. я разницы, где держать конфиги, не вижу. А вот доп сервисы в контейнере вижу.
2) https://docs.docker.com/engine/userguide/labels-custom-metadata/ отталкиваться от сюда. В swarm указываю, при старте конейнеров, условно, запустить 10 штук, на машина с лабелом блабла.
3) Опять же, не вижу тут проблем. Вопрос решается системой управления конфигурации.

кстати, надо посомтреть поподробнее, что там предлагается.

Я думаю, что крон — это изменение данных в некой центральной точке. Потому проще держать отдельный инстанс.

Мне думается это ошибка в архитектуре. Я не говорю о том, что таких кейсов не может быть. Но все таки контейнеру подразумевают какое-то CI и систему управления конфигурацией.

по мне, consul-template, как и крон выносятся на хост тачку.
Хотя тут и есть вопросы с swarm и прочим.

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

Разве? ну возможно. Хотя вроде jinja тянет в зависимостях. А потом обертывает в свои врапперы. Утверждать не буду, проверять лень. :)

В нашем случае:

1. Обилие говнокода на puppet, разгребать смысла нет. В текущем состоянии идет постоянное нарастание.
2. Наличие центрального сервера и агентов. Что вместе с п1 ведет к серьезным тормозам. Например: запуск агентов был сначала раз в 25 минут, потом раз в 45, потом раз в час, потом раз в 2 часа. Agentless у ansible, считаем это плюсом. А наличие CI позволяет вполне заменять центральный сервер.
3. Осознание излищней сложности puppet. Docker+ansible позволяют выкинуть 60% кода без рефакторинга.
4. Очень удобная декомпозиция ролей. Соответсвенно всегда можно удобно и быстро выполнить малую роль.

Спасибо :) завтра вкурю полноценно

У меня сейчас миграция с puppet на ansible, и комбинация -i и --limit очень помогает.

Именно. То есть получается, все плюшки jinja там толком не поиспользовать.

Еще раз. Я не про include в коде yaml, а в коде шаблона. То есть если я приведенный выше кусок вынесу в инклюд, я ничего не получу.

Я про include/block в контексте jinja, а не yaml.

Сразу скажу, не копал глубоко.
Есть куча конфигов nginx с обшей частью, я попытался загнать общую часть в файлик, но не вышло. Что-то подобное в джанге было на урра.

{% set upstream_name = item.name + "_upstream" %}
{% set server_name = item.name + "-" + item.type + "-" + base_domain %}
{% set root_dir = build_dest + "/" + item.type + "/" + item.name + "/htdocs;" %}