а нужны ли мне эти ваши docker-контейнеры?

Наивные сисадмины потому что

Скорее просто они не понимают почему родилась та или иная технология. Я специально вот этот длиннопост для ТСа накидал: а нужны ли мне эти ваши docker-контейнеры? (комментарий)

Оно нифига не очевидно если с низкого старта идти, а потом да, «потом выясняется что просто с нуля придумать схему именования тегов для контейнеров и описать её в документации - это задача на месяц»

K8s - монстр. Сейчас уже понакодили всякие мини k3s, и прочие докеры на минималках без докера, уже и докер устарел и протух, знаем… плюс куб заточен под TCP архитектуру, где всё гоняется по сети в парадигме запрос-ответ. Но далеко не все сервисы так работают, например, игровые UDP и тп медиа службы, где не всегда может быть готов контент в короткое время и нужно службе «подумать» 5-10 секунд, прежде, чем выплюнуть результат, ну и тп

Кубы не монстр, в них как раз почти все то что нужно. Я делал аналог кубов в 2015 на pcmk+coro+consul+template+ansible+docker. Внезапно все то что есть в кубах вот только геморроя сильно больше. Когда начинаешь копать какие проблемы могут быть - в кубах есть почти всё.

K8s - монстр.

Он простой как валенок, что именно показалось вам таким уж сложным?

Я кстати не в курсе подробностей по k3s.

Можешь на пальцах объяснить чем отличается?

Изобретать поверх ВМ свою оркестрацию

На рынке мало готовых оркестраторов? Если чо, грамотные люди сами контейнеры крутят в VM так-то.

Ещё и сетевыми автообнаружениями заморачиваться придётся. Както же фронт-энв114 должен найти бэк-энв114 и не перепутать его с бэк-энв115

Проблема либо намного труднее, чем ты ее описываешь, либо ее нет. Намного труднее она если у вас масштабируемый сервис, и проблема в том, чтобы не уронить ее при отказах-масштабировании. Докер сам по себе никак не решает эту проблему. «Либо ее нет» в том случае, если вы тоже никак не решаете эту проблему, и настоящей масштабируемости-отказоустойчивости у вас нет. Тогда можно вешать статичные конфигурации сервисов вместо того, чтобы придумывать проблемы для решений.

В крайнем случае сделать сервер конфигов. Кубернет-то делался для того, чтобы даже после отказов можно было реконфигурировать кластер. Однако, справедливости ради, кубернет соснет, если отвалится более половины кластера. Еще раз хочу, чтобы присутствующие почувствовали значимость этого тезис: архитектура kubernetes подразумевает, что ваши рукожопы никогда ни при каких условиях не потеряют более половины управляющих хостов — в противном случае управление кубернетом будет потеряно, даже несмотря на то, что есть доступ по сети к оставшимся хостам.

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

А ещё вм медленно запускается, жрёт ресурсы и дисков на них не напасёшься

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

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

Если приложуха размазывает свои артефакты тонким слоем по ФС (unix-way) — тут как бы вопросов нет. Но далеко не все софтины так делают.

Второй бинарь открывает порт 8080 … упс. Кажется что-то пошло не так

Зачем второй бинарь открывает порт на 8080 в то же время? Если это два совершенно разных сервиса-теста, то их просто можно повесить на разные порты, и не придумывать проблемы для решений.

Ты знал! Ты знал! Да, я про AWS CDK, где конструк, который мне создаёт несколько IAM ролей весит 671Мб, вот, только-что проверил. Из них 200кб мой код, всё остальное нода накачала

Так я это читал, когда тебе отвечал по данной проблеме. Там в либах AWS стенка какой-то бессмысленной копипасты в устрашающих масштабах, я по итогу испугался и закрыл сорцы. Это к слову о том, что амазон дружелюбен к разработчикам, делает «много» клиентских либ для AWS.

s/конкретных версий ядра/практически любого линукса, который реально встретиь в продакшене/

Это из той индустрии, которая сервера делает на последних версиях убунты? Редхат, вон, не так давно (а может и до сих пор) бэкпортировал изменения в ветку 2.6.XX спецом для поддержки контейнеров.

По-моему, я всё понятно объяснил. Должно быть вам не хватает специфичного опыта. Приезжайте к нам в Гермашку, помучаетесь и сразу всё станет очевидным

Не, я просто хотел ненавязчиво рассказать, какой я клёвый. Только не знаю, куда эти навыки применить, потому что с заказчиками у меня плохо получается дружить.

На рынке мало готовых оркестраторов?

Возьмём, например, кубернетес …

Проблема либо намного труднее,

Странно, а я думал сейчас будет история как можно сделать свой service discovery примотав изолентой bind9 к пластиковой бутылке.

В крайнем случае сделать сервер конфигов

А, не, всё в порядке.

Зачем второй бинарь открывает порт на 8080 в то же время?

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

Если это два совершенно разных сервиса-теста,

А если два совершенно одинаковых? Или частично одинаковых?

Редхат, вон, не так давно (а может и до сих пор) бэкпортировал изменения в ветку 2.6.XX спецом для поддержки контейнеров.

Т.е. вас не устраивает технология, которая работает на ядрах от 2.6 до самых распоследних 5.17? Ну ок, на восьмой слаке, с которой я начинал 20 лет назад, и вправду докер не запустишь. Если встречу такое в проде, растеряюсь, заплачу, убегу, буду не знать, что делать. Плохой, докер, плохой.

Может я просто устал и упускаю что-то?

Возможно docker не нравится тебе потому, что ты не используешь docker-compose? Если запускать каждый контейнер вручную или даже скриптом, то docker может показаться лишней сущностью (вместо того, чтобы запустить приложение с нужными параметрами скриптом, запускаешь скриптом docker-контейнер с нужными параметрами, в котором запускается приложение…). А с docker-compose не нужно делать многие вещи вручную, например, связывать контейнеры между собой, ты просто обращаешься из одного контейнера к другому по имени хоста, которое определяется в docker-compose.yml (и, к примеру, при настройке приложения будет неважно, какой IP-адрес получит сервер базы данных, она будет доступна, например, по имени «db»), не нужно заботиться о том, чтобы останавливать все процессы (или контейнеры) при остановке приложения, и так далее.

В каком-то смысле компилятор Go — это и есть лучший докер.

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

кубернет соснет, если отвалится более половины кластера

Твоему хайлоад-деплою на баш-скриптах достаточно будет отвала одной ноды. Почувствуй разницу.

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

Ты не совсем понимаешь, в чём фишка докера. Почему он взлетел.

Видишь вот этот URL: https://hub.docker.com/_/postgres

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

Видишь этот URL: https://hub.docker.com/_/oracle-database-enterprise-edition

По нему располагается официальный образ оракла от самого оракла.

И так практически по любой софтине. Захотел я поставить графану – она есть в докер хабе, от производителей графаны.

docker hub это круче пакетов дебиана, т.к. пакеты дебиана пакетируют уставшие люди, на которых миллион пакетов на каждом, а в докер хабе чаще всего сборки от исходных разработчиков.

Именно в этом суть докера. В экосистеме. Когда любой софт находится на расстоянии пяти секунд вбивания docker run --rm -it ubuntu:16.04

Этого в альтернативах нет. Тот же lxc плохая что ли штука? Да примерно суть та же, контейнеры. Но им никто не пользуется, ибо вручную даже скрипт из трёх строчек вроде apt install писать всем вломы. Только одна строчка максимум и желательно в декларативном виде.

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

Всё (почти) в одном бинарнике. Поддерживает не только etcd, в том числе SQLite. Соответственно удобно для использования в самых разных условиях.

Из документации на сайте можно получить представление об идеях проекта за пару минут.

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

– Программисты! Равняйсь! Смиррна! По номеру тикета раассчитайсь!

Вот это тру оркестрация, я понемаю.

Вырезали кучу старых апишек и подпилили под single node. Пытались сделать распределенную dSQLite чтобы выкинуть etcd, но емнип не выгорело. В результате, при HA конфигурации получаешь те же цифры.

А насчет скорости - тут как с гентушниками, у них и скорость света на 7 процентов быстрее. Ящитаю замена runc на crun/youki дает больше прироста (контейнеры чуточку быстрее стартуют), ну и CNI подобрать под задачу (может и flannel хватит)

docker hub это круче пакетов дебиана, т.к. пакеты дебиана пакетируют уставшие люди, на которых миллион пакетов на каждом, а в докер хабе чаще всего сборки от исходных разработчиков.

Во-первых, насчёт миллиона пакетов - иногда может и бывает но в целом обычно не так. Во-вторых, точно так же исходные разработчики создают свои кастомные deb-репозитории со своими пакетами.

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

Я не знаю с чего начать, просто сравни количество метаданных запущеного докер-контейнера (их ещё найти надо, я не помню сходу где) и количеством метаданных запущеного freebsd jail - одна строчка командной строки: jail id, jail name, root path, hostname, ip-address, startup-command + какие-то опциональные флаги. Фс контейнера это просто директория в настоящей фс, сеть контейнера - это настоящая сеть, просто лимитированная айпи-адресами куда можно забиндиться + заворачивание локалхоста (хотя есть некое VIMAGE с виртуализированной сетью, но им закономерно никто не пользуется - не нужно оно), доступ к списку процессов изолирован прямолинейно и прозрачно (процесс виден только в своём jail-е и в тех что выше по иерархии, на этом всё), сравни с простынёй в man pid_namespaces у линукса, да и вообще - в линуксе там пачка отдельных абстракций с простынями-манами о том как их настраивать, в jail там одна сущность с ровно тем функционалом, который реально нужен (а не тем, который теоретически может пригодиться для странных вещей и в итоге замусоривает конфиг).

точно так же исходные разработчики создают свои кастомные deb-репозитории со своими пакетами.

Вот разработчики счастливы создавать пакеты подо все распространённые версии всех популярных дистрибутивов.

количество метаданных запущеного докер-контейнера (их ещё найти надо, я не помню сходу где)

Подсказываю: docker inspect $container.

Вот разработчики счастливы создавать пакеты подо все распространённые версии всех популярных дистрибутивов.

А кто-то видимо счастлив ради какого-нить nginx тянуть себе помойко-убунту потому что контейнер собран из неё. Не пиши ерунду.

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

и один херъ чегой-то под чоткий и правильный джайл не штампуют готовых образов…. и используют в проде наверное менее полтора землекопа…
отличие удобных инструментов от правильных…

А кто-то видимо счастлив ради какого-нить nginx тянуть себе

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

Не пиши ерунду.

Дельный совет.

то точно так же можешь сделать чрут с дебианом

Конечно, мне же платят за то, что я фигнёй вместо работы страдаю.

Докер противоречит юниксвейности и KISS. Поэтому нафиг не нужен!

Пусть этим говном вантузоиды убогие пользуются на своих бубунтах!

[докер нинужно]

freebsd jail

От оно чо, Михалыч. Он просто недостаточно дидоугоден.

чрут на максималках — тоже может быть полезным инструментом в некоторых сценариях. Но:

1. явно не серебряная пуля.

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

у тебя есть твой код. Чтоб он работал нужны либы, код плюс либы плюс сборка это приложение, например через npm/pip/maven

Ты почему-то используешь понятие «у меня есть приложение» в смысле «у меня есть груда сервисов для высоконагруженной системы, обслуживающей 10 пользователей одновременно». В большинстве случаев для такой высоконагруженной системы статичной конфигурации более чем достаточно. Соответственно, единственная реальная проблема — это максимальная ублюдочность питонового деплоя, которую можно решить даже банальным чрутом, собирая чистое окружение питона каким-нибудь Nix.

Другой вопрос что через N версий ты потратишь на ручной конфиг больше времени чем на автоматизацию

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

Зато ты можешь подключиться gdb к своему питоновому процессу, писать логи когда тебе нужно, делать кастомные конфиги когда нужно

Шаг 1: заходишь в контейнер. Шаг 2: дальше вот это вот всё, что выше написано.

Через неделю после того как я уволилась, услышала новость что поддерживать всё это кастомное написанное добро сил ни у кого нет, все сервисы переходят на K8S

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

Если ваша задача «просто как-нибудь запустить и молиться, чтобы заработало» — кубернет вам не нужен. Если у вас многократный резерв по ресурсам на серверах (что актуально для плохо спроектированной, то есть, средней системы на кубере), то вам никакая адаптация не нужна. Есть рассказы про «экономлю на AWS, плачу только когда вычисляю», но AWS выходит норм по деньгам только пока у вас 10 пользователей, а при росте нагрузки быстро выяняется, что дешевле было купить сотню 24/7 выделенных серверов у хецнера.

Шаг 1: заходишь в контейнер. Шаг 2: дальше вот это вот всё, что выше написано

Откуда в контейнере gdb? Откуда в контейнере отладочные символы? И профайлеры, наверное, тоже в этом же контейнере лежат, да? А конфиг кастомный мне как делать? Каждый раз руками менять?

Откуда в контейнере gdb? Откуда в контейнере отладочные символы?

Устанавливаешь их.

А конфиг кастомный мне как делать? Каждый раз руками менять?

Как и вне контейнера. Можешь его просто примонтировать снаружи.

За всё надо платить. Чтобы система работала надёжно и без сбоев, нужно максимально ограничить возможность пользователей залезть в неё своими шаловливыми ручками. Из-за этого же возникают неудобства у админов, когда надо всё-таки отлаживать поведение такой закрытой системы. Я сам от этого очень страдаю. Но альтернатива ещё хуже. Такие дела.

Можешь посмотреть на Red Hat Atomic Host и на CoreOS. Я про эти штуки кроме названия ничего не знаю, но вроде как это призвано быть той самой минимальной пускалкой контейнеров.

Ещё можно посмотреть на ту виртуалку, которую запускает docker desktop. Это уже минимальная пускалка от самих создателей докера.

K8s - монстр. Сейчас уже понакодили всякие мини k3s, и прочие докеры на минималках без докера

И я о том же. Людям не нужны микросервисы, но это популярно, и теперь все лепят сервисы, но оркестрировать их даже не собирались — им нужно просто «чтобы было всё залюбись». Спрос рождает предложение, и вот уже выростают недооркестраторы, управляемые одной кнопкой.

От Владимира)

Кстати, куда он пропал? ))

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

Я считаю, это полезно.

Проблема либо намного труднее,

Странно, а я думал сейчас будет история как можно сделать свой service discovery примотав изолентой bind9 к пластиковой бутылке.

В крайнем случае сделать сервер конфигов

А, не, всё в порядке

Service discovery никому не нужен. Люди чаще решают проблемы, которых у них не было. Это то, что я называю «придумывать проблему для решения».

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

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

Т.е. вас не устраивает технология, которая работает на ядрах от 2.6 до самых распоследних 5.17?

Вообще-то с 3.10. И то 3.10 не рекомендуется к применению с докером, так что скорее смотри на последние версии тройки — а это вполне себе недавний RHEL.

Сложно обсуждать, не зная конкретной задачи.

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

Представь себе бывают задачи не «поставить и молиться» и не «засыпать железом». Вполне часто бывают причём.

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

Вот здесь помедленнее. То есть, docker-compose волшебным образом поможет мне не потерять данные при остановке системы? Как?

Твоему хайлоад-деплою на баш-скриптах достаточно будет отвала одной ноды. Почувствуй разницу

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

Ты не совсем понимаешь, в чём фишка докера. Почему он взлетел

Bruh. I know that feel. Сам основатель докера говорил то же самое — это прежде всего «просто запускалка». Однако, так было в 2010, и прежде всего основывалось на допущении, что у тебя нет заранее известного ядра ОС, а вместо онного ты дергаешь stdc, который для никсов является аналогом клиентской либы ядра, и stdc не стабилен, потмоу нужно под каждую версию собирать софт из сорцов.

В 2022 ты можешь собрать портативную статически линкованную версию своей софтины, опирающуюся на API ЯДРА, которая носит с собой конфиги — нет ни одного оправдания для того, чтобы этого не делать. По сути, докер именно это и делает, только насильно для любого софта, который к 2022 году до сих пор не научился в портативный билд.

а нужны ли мне эти ваши docker-контейнеры?

Гм.

Все дороги ведут в Рим! ...

Владимир

И я о том же. Людям не нужны микросервисы, но это популярно, и теперь все лепят сервисы, но оркестрировать их даже не собирались — им нужно просто «чтобы было всё залюбись». Спрос рождает предложение, и вот уже выростают недооркестраторы, управляемые одной кнопкой.

Ну я тебе могу сказать, что хотят от меня. От меня хотят:

1. Минимизацию денег на серверы. Сейчас тратят кучу денег на несколько VDS со стрёмным конфигом. Реально по моим прикидкам если всё грамотно раскидать по сервисам, то можно сэкономить процентов 80. Сразу половина экономится за счёт того, что сервисом никто не пользуется 16 часов из 24. Ещё куча сэкономится за счёт того, что утилизация серверов по памяти в среднем на 30-40%, а по CPU по-моему вообще процентов на 5-10. Кстати недавно один сервис перевели на облачное хранение файлов вместо БД, вот прям залетал сразу сервис, оказывается облако отдаёт файлы в сто раз быстрей, чем кривой скрипт на ноде выковыривает их из постгреса, кто бы мог подумать. На халяву получили в сто раз лучшую надёжность (за тем хранилищем следят нормальные админы, там делается избыточность и прочее, тут тупо pg_backup раз в месяц, даже рейда нет). Денег стоит смешных.

2. Отказоустойчивость. Сейчас упавший сервер это даунтайм примерно на час. Потому, что сначала надо создать тикет, там в дата центре на другом конце страны кто-то очухается, сходит в туалет, нажмёт кнопку. И потом оно ещё полчаса грузиться будет. Круто, ага. Если сервер сломается - ну я даже такое представлять не хочу, на сутки точно даунтайм будет. А серверы, они ведь могут ломаться, они такие. А с кубером я мечтаю о том, чтобы у трёх хостеров купить по паре впсок и оно даже при проблемах у одного хостера работало нормально. Но даже без трёх хостеров тупо на кучке впсок отказоустойчивость будет более, чем достаточная, чем сейчас.

3. Масштабируемость. Была такая проблема несколько недель назад. Возник всплеск потребления всего в 5 раз. Ну чё, тупо оператива закончилась и гг. Я свопа сунул от души, оно там кое-как ворочалось, но то такое. Предлагал апнуть конфиг сервера в 2 раза - не хотят.

Я вот честно не хочу влезать в эти куберы, я в них ничего не понимаю. Но какие альтернативы-то? Я могу и на lxc сэмулировать контейнеры, я такой, баш скрипты писать люблю. Я даже на скриптах могу через апи запускать и тушить впски. Но не всерьёз же мне этим заниматься. docker swarm вроде как сдох. Выходит, что кроме кубернетиса ничего особо и не остаётся.

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

и один херъ чегой-то под чоткий и правильный джайл не штампуют готовых образов…. и используют в проде наверное менее полтора землекопа…
отличие удобных инструментов от правильных

Фряха в конце девяностых была топом. Потом и контейнера в ней появились первой. Но шли нулевые, гугл подхватил линукс, и вот уже вся индустрия крутит сервера на линуксе. Как бы ни был хорош jail, но линукс как платформа лучше фряхи, хоть фряха и пытается догнать линь. В чем «догонять»? В замене безнадежно устаревших синхронных интерфейсов Unix на что-то более асинхронное, и во фряхе родных футексов до сих пор нет, насколько я знаю.

Почему Вы стали меня игнорировать, друг мой?

Может, Владимир ненастоящий?

Забанили IP, например.

как что ?? «поднимать целину» и проталкивать фряху в продакшен… чтобы все тупые создатели серверов и систем на них поняли насколько бздунец кручеее линупса :)

Как и вне контейнера. Можешь его просто примонтировать снаружи

Воо-о-от, выясняется, что докер не упрощает, а усложняет нестандартную конфигурацию. Докер хорош только если вам нужно быстро растиражировать одинаковую конфигурацию — а я и спрашиваю: вам точно нужно быстро тиражировать одинаковую конфигурацию? Я недавно подумал поставить себе браузер и мессенжер во flatpak (безопасность и всё такое) — натрахался с конфигами-профилями так, что выкинул этот флетпак и оставил нативные приложухи.

Чтобы система работала надёжно и без сбоев, нужно максимально ограничить возможность пользователей залезть в неё своими шаловливыми ручками. Из-за этого же возникают неудобства у админов, когда надо всё-таки отлаживать поведение такой закрытой системы. Я сам от этого очень страдаю. Но альтернатива ещё хуже

Ну хоть здесь мы нашли точку соприкосновения.