Docker images, дистрибутивы ОС, должны ли быть одинаковыми?

Скажем, у меня есть сервак с centos7, и я хочу на нем запускать все контейнеры, как от этого ситуация меняется?

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

по факту конечно магии нет, когда берешь ядро от хоста, а user-space с контейнера странные вещи происходят. Причем даже если хост от убунты и контейнер от убунты просто другой минорной версии.

Примеров масса, от нерабочей сборки rpm в centos-контейнере на убунту-хосте до отваливающегося генератора случайных чисел в PHP7.

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

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

А что насчет первой части вопроса, стоит ли париться по поводу разницы дистрибутивов внутри контейнеров? Сказывается ли это значительно на их размере? Ведь по идее, если нужной общей части не найдено на хосте, она попадет внутрь контейнера?

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

Ох чувствую будет веселье с этой докеризацией.

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

(кроме возможных граблей, описанных в предыдущем комментарии)

стоит ли париться по поводу разницы дистрибутивов внутри контейнеров? Сказывается ли это значительно на их размере?

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

это дает хоть какую-то гарантию отсутствия озвученных проблем (при условии отличных дистр-ов в контенерах | при условии таких же дистр-ов в контенрах)?

это даёт гарантию того, что ты вляпаешься в проблемы на этапе разработки (dev включает в себя тестирование, да же?) а не этапе релиза, когда разработчики с чувством выполненного долга уже разъехались пить коктейли под пальмами, а поседевший админ пытается понять, что случилось :)

Что в общем хорошо и правильно.

отсутствия проблем это конечно не гарантирует, но к ним хоть можно будет найти какие-то обходные пути

так что в конечном итоге юзать?
Докер в пределах одного ХОСТА(дистра/версии/железа) и не прыгать со своими контейнерами по разным хостам?

А на все остальное виртуалки?

Спасибо за ответы) Теперь знаю как буду действовать.

Так смотря для чего и как ведь.

Для разработки веб-приложений на локалхосте докер вполне ок. Баг с PHP7 ты получишь раз в полгода - не страшно.

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

Короче что разработчику легко, то девопсу job security на долгие годы :)

понятненько.
значит если попадается обслуживание «докеров» в продакшене, даже если это ооо //роги и ко-ко//, то можно их , даже в кач-ве клиентов, до пенсии дотянуть.

Офигеть, год докер в проде вертелся, такой дичи не было. Контейнеры debian, хосты debian, разработка у кого что rach, ubuntu, osx. В случае если кто-то пытался протащить левые контейнеры админы блокировали релиз. Ну и да, релиз без разработчика и тестера от команды - это как-то не по человечески, как разработчик говорю.

А как же линусово «We don't break userspace»?

докер уже не докер, он теперь moby

Пообещали CLI не менять же

Где Линус, а где мы.

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

Ох, мы с такими зоопарками говна наелись, особенно когда у разработчиков стали расходиться версии докера в их дев-окружениях. В итоге для нас хорошо рабочим вариантом стало так:

• Докер-кластер (кубик) в проде, все хосты идентичные.
• Staging-кластер, окружение хостов идентично проду.
• Dev-кластер, идентичное окружение. Используется для сборки имиджей, запуска промежуточных тестов, и просто на поиграться разработчикам.

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

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

Мы систему сборки пакетов на контейнерах делали, чтобы и рпм и деб на одном хосте собирать. И вот всё собирается, а два пакета не собираются. Ядро не подошло.