Нет, это не шутка, я просто недостаточно развил свою мысль. Она действительно не для всех очевидна, так что исправляюсь.
В определённый исторический период сложился такой консенсус, что лучше иметь универсальный механизм изоляции для всего, то есть контейнеризацию через Docker. Предполагалось, что девопс-инженерам не придётся изучать тонкости языков и платформ, они просто будут воспроизводить одинаковую среду на серверах и машинах разработчиков, и все будут счастливы.
Но сегодня стало очевидно, что этот универсальный механизм себя не оправдал, не реализовал обещаний. Для разработчиков затраты на поддержание той же системы контейнеров, что и на серверах, оказались неподъёмны: сложно, требует изучения и поддержки, нужно мощное железо, намного усложнились задачи, которые раньше были простыми, типа отладки. Девопсы так и не смогли обойтись без изучения целевых платформ, просто вместо прямого подхода (прочитать немного про CPython, pip и virtualenv) им приходится начинать погружение в чудесный мир Python с отлаживания необъяснимых багов (почему cryptography не собирается в контейнере с Alpine).
В результате поддержка простых и понятных деплой-скриптов на Fabric оказывается намного практичней, чем монструозная система изоляции всего и вся. Особенно если основа продакшена − Python, который уже имел специфические, весьма развитые и взрослые средства изоляции с отличным уровнем переносимости, когда докера ещё не было в проекте.
«Что угодно aio*» − это плюс один фреймворк, то есть для собственного резюме − здорово, а для предприятия − не то чтобы.
Лично я, скажу честно, не горю желанием перейти на асинхронное программирование, и не встречал ещё таких питонистов, которые бы мечтали об этом. Я видел, как самые простые вещи с async/await превращаются в инкубатор неотлаживаемых багов, и не хочу быть крайним в разгребании этих авгиевых конюшень.
Сейчас в systemd есть пользовательские юниты. Использовать их очень просто: нужно вместо /etc/systemd/system использовать ~/.config/systemd/user, а к вызову systemctl добавлять ключ --user.
Когда пользовательских юнитов не было, принято было подменять пользователя для запуска gunicorn/uwsgi/et c. вот таким образом:
У меня есть антресольный безголовый сервер, на котором я ресет могу и сам нажать, без мосфетов, а вот в биосе поковыряться или безопасно перезагрузить в случае отвала сети − уже нет. Для меня такая схема была бы самое оно. И расходов меньше чем на 3000р.
Вот в дата-центр за тыщи км я бы такой девайс не повёз устанавливать, не спорю. Но это ещё не значит, что он совсем бесполезный.
1) надо эмулировать HID, а это можно делать только через OTG-порт, который на малинке совмещён со входом питания,
3) в оригинальной статье есть ссылки на Амазон (переходники HDMI→CSI и HDMI→USB).
Сочувствую вам. Я работаю в маленькой компании, с такими вещами не сталкивался. С другой стороны, я немножко сочувствую и вашему менеджменту тоже. Мы же все общаемся со всеми, можем потюнить воркфлоу на ходу, если видим, что при существующем порядке работа пробуксовывает. А для вашей организации в таком случае будет уже поздно пить боржом.
Какую общую тенденцию? Что надо всегда придерживаться лучших практик? То есть вы хотите сказать, что статья в любом случае бессмысленна − что с примерами, что без оных?
Ради доказательства. Я, допустим, абсолютно уверен, что best practices нужно придерживаться всегда и во всём. Может ли эта статья убедить меня в чём-то? Ни малейшей вероятности.
Но если бы я своими глазами увидел кусок кода, написанный согласно best practice, но при этом неоправданно дорого обошедшийся в продакшне − уязвимый, неподдерживаемый, вызвавший потерю данных − тогда я поверил бы автору.
В определённый исторический период сложился такой консенсус, что лучше иметь универсальный механизм изоляции для всего, то есть контейнеризацию через Docker. Предполагалось, что девопс-инженерам не придётся изучать тонкости языков и платформ, они просто будут воспроизводить одинаковую среду на серверах и машинах разработчиков, и все будут счастливы.
Но сегодня стало очевидно, что этот универсальный механизм себя не оправдал, не реализовал обещаний. Для разработчиков затраты на поддержание той же системы контейнеров, что и на серверах, оказались неподъёмны: сложно, требует изучения и поддержки, нужно мощное железо, намного усложнились задачи, которые раньше были простыми, типа отладки. Девопсы так и не смогли обойтись без изучения целевых платформ, просто вместо прямого подхода (прочитать немного про CPython, pip и virtualenv) им приходится начинать погружение в чудесный мир Python с отлаживания необъяснимых багов (почему cryptography не собирается в контейнере с Alpine).
В результате поддержка простых и понятных деплой-скриптов на Fabric оказывается намного практичней, чем монструозная система изоляции всего и вся. Особенно если основа продакшена − Python, который уже имел специфические, весьма развитые и взрослые средства изоляции с отличным уровнем переносимости, когда докера ещё не было в проекте.
Сейчас в systemd есть пользовательские юниты. Использовать их очень просто: нужно вместо
/etc/systemd/systemиспользовать~/.config/systemd/user, а к вызовуsystemctlдобавлять ключ--user.Когда пользовательских юнитов не было, принято было подменять пользователя для запуска gunicorn/uwsgi/et c. вот таким образом:
Пускать Django из-под рута − это варварство.
Вот в дата-центр за тыщи км я бы такой девайс не повёз устанавливать, не спорю. Но это ещё не значит, что он совсем бесполезный.
3) в оригинальной статье есть ссылки на Амазон (переходники HDMI→CSI и HDMI→USB).
Но если бы я своими глазами увидел кусок кода, написанный согласно best practice, но при этом неоправданно дорого обошедшийся в продакшне − уязвимый, неподдерживаемый, вызвавший потерю данных − тогда я поверил бы автору.