Несколько советов по организации Python-приложения на сервере

Эм… это как у вас так получается проект на разных языках? Вызов скриптов на других языках?

Вы пишете доку по тому, как развернуть ваш проект? Вот ansible это дока, только которая еще и выполняется.
В добавок к этому размер ansible скриптов всегда четко следует размерам проекта или связанной инфраструктуры. Если у вас просто баш скрипт, то вы или выгружаете его на сервер через ansible или разворачиваете там git репозиторий с проектом (и ключи для него). И все, это делается довольно быстро.

Ну и "а чем меньше сущностей используешь, тем надежнее", подразумевает, что вы не будете делать то, что делает ansible, но нет, у вас все равно будут самописные скрипты по деплою. И вместо того, что бы использовать продукт, который для этого разрабатывался вы предлагаете на коленке напилить ad-hoc решение, у которого не будет никаких преимуществ. Зачем?

Если руки кривые (а это бывает… ох бывает), то контейнер кокрастыке поможет.

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

Из-за какого мнения? Программирование — это не искусство, это прикладная область, за неё кушать дают. А хочется прекрасного — участвуйте в олимпиадах. Денег не заплатят, ну так художник и должен быть голодным :)

Запустили вы в subprocess какой-нибудь внешний процесс, а он получил все ваши пароли, а потом в крэшдампе отправил своим разработчикам.

Вроде бы в subprocess можно создавать чистое окружение, но аргумент всё же
принимается, спасибо.

Я реально не вижу удобства в переменных окружения. Мне лично удобнее прочитать переменную DATABASES как dict из yaml/json файла чем составлять ее из нескольких переменных окружения.

Хе-хе. Если б одна запись составлялась из нескольких переменных, это не было так круто, как есть. Жизнь — она горазда элегантнее.

Уже стало хорошей традицией записывать все кренделя в виде DSN

DATABASE_URL=postgres://user:supersecretpassword@hostname.com:5432/db?timeout=20
ANOTHER_DATABASE_URL=mysql://user:passwrd@mysqlserver.com/mysqldb

а настройки выглядят так:

import dj_database_url as db_config  # да, это внешняя зависимость. dj-database-url

DATABASES = {
    'default': db_config.config(),
    'another': db_config.config(var='ANOTHER_DATABASE_URL'),
}

Однажды видел, правда, не помню где, как особо одарённые люди делали так:

DATABASES = parse_env()

В результате этой надстройки в DATABASES под ключом default попадало распарсенное значение DATABASE_URL, а все переменные вида MYPREFIX_DATABASE_URLпопадали туда же как значение ключа myprefix.

Совершенно аналогично задаются кренделя к e-mail, кешам, очередям типа rabbitmq и прочая, и прочая, и прочая.

С примитивами тоже наглядно. Понятно, что переменная окружения всегда строка (если есть) и None, если не определена. Но многочисленные обвязки позволяют писать очень, на мой взгляд, довольно прикольно. Например, так:

SECRET_KEY = env('SECRET_KEY', cast=str, default='')
DEBUG = env('DEBUG', default=False, cast=bool)
ALLOWED_HOSTS = env('ALLOWED_HOSTS', cast=list, default=['*']) # разделяет строку по запятой

или так:

SECRET_KEY = env.string('SECRET_KEY')
DEBUG = env.boolean('DEBUG')

кто во что горазд, короче.

Разумеется, это тоже внешняя зависимость, как и в Вашем случае. Но всё же, по чесноку, что более выразительно и явно:

import_settings("/usr/local/etc/myservice.yaml")

или

DEBUG = env('DEBUG', default=False)
SECRET_KEY = env('SECRET_KEY_FROM_MY_ENV_VAR')

? Мы же помним, что явное лучше неявного. Кто его знает, какие переменные понаинжектили злобные русские хакеры в конфиг, который Вы инклюдите? :)