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

Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.

• Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
• Подход со статической компоновкой, языкоспецифичными библиотеками и прочим новомодным пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.
• Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.

Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.

Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.

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

Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.

• Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
• Подход со статической компоновкой, языкоспецифичными библиотеками и прочим пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.
• Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.

Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.

Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.

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

Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.

• Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
• Подход со статической компоновкой, языкоспецифичными библиотеками и прочим пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.
• Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.

Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.

Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.

С другой стороны, в принципе, если процессы построены на от5.1сь, то нет никакой разницы, построены они на докере или на чём-то другом. Просто докер очень сильно упрощает, облегчает и порой даже рекомендует строить процессы именно на от5.1сь.

Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.

• Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
• Подход со статической компоновкой, языкоспецифичными библиотеками и прочим пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.
• Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости, пересобрать прикладной софт.

Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.

Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.

С другой стороны, в принципе, если процессы построены на от5.1сь, то нет никакой разницы, построены они на докере или на чём-то другом. Просто докер очень сильно упрощает, облегчает и порой даже рекомендует строить процессы именно так.