История изменений

«Не создавай лишних сущностей без крайней на то необходимости». При этом содержимое docker-контейнеров выключено из нормального цикла администрирования, обновления, накатывания патчей безопасности. Что если нужно вкатить новую версию библиотеки X во все Perl-приложения, использующие эту библиотеку - например, из-за того, что X стал работать в разы быстрее или там были пофикшены баги, которые при неправильном положении закрылок приводили к падениям в рантайме? При этом ситуация «мне нужно держать в каждом контейнере свою версию X, потому что у неё везде разный API», под которую вроде бы и заточен докер, представляется мне крайне надуманной: у хороших библиотек API - стабильно, и бы они там не изменялись внутри, снаружи это будет работать одинаково. А библиотеки с нестабильным API наверное и не стоит использовать.PATH, PERL5LIB, LD_LIBRARY_PATH, относительные пути - это элементарные вещи, которые прозрачным образом настраивают приложение на работу в рамках своего каталога, но при этом дают ему возможность использовать хоть 90, хоть 95% общих ресурсов, администрируемых централизованным предсказуемым образом.

С docker'ом, который можно использовать конечно для построения своеобразного слоёного дистрибутива, история чаще всего такая: «мы не умеем в Linux, но мы умеем в докер». При этом то, что образуется внутри контейнеров нельзя назвать иначе как помоечным складом какой-то рухляди, взаимодействующей с кодом основного приложения - это никто не обслуживает, не анализирует, этому никто не ищет более быструю замену, потому что «работает - не трожь» (и ещё обязательно молись, чтоб все тесты сошлись).

docker для большинства - это просто реализация какого-то эскапистского подхода, возможность сосредоточиться на приложении и забить на всё остальное. Такой подход не очень хорош, потому что он не о том, чтобы вообще забить на системное администрирование, он о том, что нужно в таком случае нанять в системного администратора в 2 раза дороже - того, который не только в осях силён, но ещё и на докерах с кубернетесами собаку съел. Иначе вы рано или поздно будет сами вынуждены стать системными администраторами и будете тратить на скрипты оркестрации контейнеров то время, которое было бы гораздо разумнее потратить на разработку собственно программного продукта.

«Не создавай лишних сущностей без крайней на то необходимости». При этом содержимое docker-контейнеров выключено из нормального цикла администрирования, обновления, накатывания патчей безопасности. Что если нужно вкатить новую версию библиотеки X во все Perl-приложения, использующие эту библиотеку - например, из-за того, что X стал работать в разы быстрее или там были пофикшены баги, которые при неправильном положении закрылок приводили к падениям в рантайме? При этом ситуация «мне нужно держать в каждом контейнере свою версию X, потому что у неё везде разный API», под которую вроде бы и заточен докер, представляется мной надуманной: у хороших библиотек API - стабильно, и бы они там не изменялись внутри, снаружи это будет работать одинаково. А библиотеки с нестабильным API наверное и не стоит использовать.PATH, PERL5LIB, LD_LIBRARY_PATH, относительные пути - это элементарные вещи, которые прозрачным образом настраивают приложение на работу в рамках своего каталога, но при этом дают ему возможность использовать хоть 90, хоть 95% общих ресурсов, администрируемых централизованным предсказуемым образом.

С docker'ом, который можно использовать конечно для построения своеобразного слоёного дистрибутива, история чаще всего такая: «мы не умеем в Linux, но мы умеем в докер». При этом то, что образуется внутри контейнеров нельзя назвать иначе как помоечным складом какой-то рухляди, взаимодействующей с кодом основного приложения - это никто не обслуживает, не анализирует, этому никто не ищет более быструю замену, потому что «работает - не трожь» (и ещё обязательно молись, чтоб все тесты сошлись).

docker для большинства - это просто реализация какого-то эскапистского подхода, возможность сосредоточиться на приложении и забить на всё остальное. Такой подход не очень хорош, потому что он не о том, чтобы вообще забить на системное администрирование, он о том, что нужно в таком случае нанять в системного администратора в 2 раза дороже - того, который не только в осях силён, но ещё и на докерах с кубернетесами собаку съел. Иначе вы рано или поздно будет сами вынуждены стать системными администраторами и будете тратить на скрипты оркестрации контейнеров то время, которое было бы гораздо разумнее потратить на разработку собственно программного продукта.