Можно помотреть на официальном докер регистри. Вот по слову Ada, например.
Хотя, думаю, эти образы сделаны энтузиастами и непонятно, как хорошо они работают.
сразу надо с ОС поставлять — но так же не делаю — верно?
По сути, докер так и делает :)
А вообще ситуации бывают разные. Я начал статью с типовых ситуаций, где докер применять есть смысл.
Совершенно очевидно, что в массе других ситуаций докер не нужен, а нужно как раз «отдельное ПО».
Вы критикуете докер за то, что он добавляет в систему сложность, а значит и дополнительные места для сбоев. Это, в принципе верно.
Только в этом плане гипервизор — предмет для точно такой же критики.
Любое добавление сложности добавляет и хрупкость.
Вопрос всегда в том ради чего идти на такое усложнение и насколько качественна добавляющая сложность вещь.
В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.
Мало смысла использовать докер для тестировщиков, если потом не запускать тот же самый образ в production. Получится тестировали одно, а работает другое.
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными?
Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
Зависимость от хост-системы
Минимальна. В идеале её нет вовсе.
зависимость от докера
Да. Докер контейнеры зависят от докера. Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
зависимость от настройки контейнера
Как эта зависимость влияет на надежность? Настройка конейнера не может «упасть» и потянуть за собой какие-то проблемы. Настройка контейнера — это конфигурация.
зависимость настройки конечного ПО в контейнере
То есть ваше ПО зависит от его настройки. Неудивительно.
При этом докер как раз сильно снижает количество проблем такого рода, позволяя проверить ваш контейнер заранее точно в таком же окружении, в котором ему предстоит работать.
Как вы себе представляете работу сразу двух application серверов в одной системе? Как они порты поделят, например? А если они еще и данные кэшируют? А если новая версия приложения вносит изменения в схему базы данных?
сбой в работе с данными приводит к сбою приложения
Давайте уточним терминологию. Что вы называете «данными»? Неужели docker image? Или что?
На всякий случай: для хранения persistent данных в докере используются volumes. Данные хранятся отдельно от контейнеров и сохраняются при рестарте или обновлении. Docker image — это не данные. Это, если хотите — параметризованный код.
Докер — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого libssl) с поставщиков ОС и сисадминов на никого
Разве это не организационный вопрос? Пусть тот же сисадмин следит за актуальностью образов.
Не вижу почему в докере код работает не со своими данными.
да — надо перезагружаться при обновлениях
А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
Host систему никто не перегружает. А перезапуск контейнера делается очень быстро. Контейнеры вообще быстры и легковесны. По сравнению с native процессами penalty составляет 1-2%
да — влияет на работоспособность всех зависимых контейнеров
Напрямую не влияет. Они изолированы. Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
И еще одно интересное применение. Один из важных компонентов одного из наших проектов делается территориально удаленной командой разработчиков. Компонент написан на c++ и собирается под определенной версией linux.
До применения докера мы тратили массу времени на интеграцию этого компонента.
То авторы добавили новую зависимость, которой у нас нет и которая конфликтует с чем-то еще на нашем сервере.
То их бинарник просто почему-то не запускается, а при попытке сборки из сорцов вылетает ошибка компиляции.
Теперь они предоставляяют этот компонент, как докер image. Проблем больше нет. Вообще.
Docker также это и реально крутой способ развертывания development окружения для разработчика
Да. И даже более того.
Некоторые считают, что сам deployment вообще исчезнет, как отдельный процесс.
Dockerfile будет создаваться в процессе разработки.
Образы будут сразу тестироваться а потом, как есть отправляться в production.
Звучит интересно.
Это и есть docker registry. Я писал о ней в статье.
Но историю изменений там не увидишь. Можно просто хранить несколько версий одного образа, назначая версию вручную, при помощи тэга.
Можно вставить какой-нибудь apt-get upgrade прямо в свой Dockerfile.
В случае уязвимости — просто пересобрать образ (он при этом обновится), перезалить его в регистри и, да, перезапустить все контейнеры.
Для этого, кстати, иногда настраивают крон, который периодически проверяет наличие новых версий образа в регистри и, если находит, то делает обновление самостоятельно. Так удобно делать, если серверов много.
Ошибся тут: По умолчанию докер создает виртуальную сеть для каждого контейнера
На самом деле умолчания у докера и docker-compose одинаковы: виртуальная сеть, в которой каждый контейнер будет хостом
1) Вы поняли правильно
2) Здесь все сложнее. По умолчанию докер создает виртуальную сеть для каждого контейнера. Если использовать docker compose, то его умолчание — виртуальная сеть, в которой каждый контейнер будет хостом. Можно управлять виртуальными сетями гибко. А можно и вовсе их отключить и заставить все контейнеры напрямую использовать сеть хоста.
В последнем случае порты окажутся в общем адресном пространстве. Но так тоже делают, когда очен важен performance. Виртуальная сеть докера может добавить задержку до 70мс.
Вот по слову Ada, например.
Хотя, думаю, эти образы сделаны энтузиастами и непонятно, как хорошо они работают.
По сути, докер так и делает :)
А вообще ситуации бывают разные. Я начал статью с типовых ситуаций, где докер применять есть смысл.
Совершенно очевидно, что в массе других ситуаций докер не нужен, а нужно как раз «отдельное ПО».
Только в этом плане гипервизор — предмет для точно такой же критики.
Любое добавление сложности добавляет и хрупкость.
Вопрос всегда в том ради чего идти на такое усложнение и насколько качественна добавляющая сложность вещь.
Мало смысла использовать докер для тестировщиков, если потом не запускать тот же самый образ в production. Получится тестировали одно, а работает другое.
Нет. Union FS работает не так.
Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
Минимальна. В идеале её нет вовсе.
Да. Докер контейнеры зависят от докера. Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
Как эта зависимость влияет на надежность? Настройка конейнера не может «упасть» и потянуть за собой какие-то проблемы. Настройка контейнера — это конфигурация.
То есть ваше ПО зависит от его настройки. Неудивительно.
При этом докер как раз сильно снижает количество проблем такого рода, позволяя проверить ваш контейнер заранее точно в таком же окружении, в котором ему предстоит работать.
Кажется, проблема тут не у вас.
Как вы себе представляете работу сразу двух application серверов в одной системе? Как они порты поделят, например? А если они еще и данные кэшируют? А если новая версия приложения вносит изменения в схему базы данных?
Давайте уточним терминологию. Что вы называете «данными»? Неужели docker image? Или что?
На всякий случай: для хранения persistent данных в докере используются volumes. Данные хранятся отдельно от контейнеров и сохраняются при рестарте или обновлении. Docker image — это не данные. Это, если хотите — параметризованный код.
Мне не нравится только использование ansible, puppet и т п в качестве единсвенного средства deployment-a.
Разве это не организационный вопрос? Пусть тот же сисадмин следит за актуальностью образов.
А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
Host систему никто не перегружает. А перезапуск контейнера делается очень быстро. Контейнеры вообще быстры и легковесны. По сравнению с native процессами penalty составляет 1-2%
Напрямую не влияет. Они изолированы. Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
До применения докера мы тратили массу времени на интеграцию этого компонента.
То авторы добавили новую зависимость, которой у нас нет и которая конфликтует с чем-то еще на нашем сервере.
То их бинарник просто почему-то не запускается, а при попытке сборки из сорцов вылетает ошибка компиляции.
Теперь они предоставляяют этот компонент, как докер image. Проблем больше нет. Вообще.
Да. И даже более того.
Некоторые считают, что сам deployment вообще исчезнет, как отдельный процесс.
Dockerfile будет создаваться в процессе разработки.
Образы будут сразу тестироваться а потом, как есть отправляться в production.
Звучит интересно.
Это и есть docker registry. Я писал о ней в статье.
Но историю изменений там не увидишь. Можно просто хранить несколько версий одного образа, назначая версию вручную, при помощи тэга.
В случае уязвимости — просто пересобрать образ (он при этом обновится), перезалить его в регистри и, да, перезапустить все контейнеры.
Для этого, кстати, иногда настраивают крон, который периодически проверяет наличие новых версий образа в регистри и, если находит, то делает обновление самостоятельно. Так удобно делать, если серверов много.
На самом деле умолчания у докера и docker-compose одинаковы: виртуальная сеть, в которой каждый контейнер будет хостом
2) Здесь все сложнее. По умолчанию докер создает виртуальную сеть для каждого контейнера. Если использовать docker compose, то его умолчание — виртуальная сеть, в которой каждый контейнер будет хостом. Можно управлять виртуальными сетями гибко. А можно и вовсе их отключить и заставить все контейнеры напрямую использовать сеть хоста.
В последнем случае порты окажутся в общем адресном пространстве. Но так тоже делают, когда очен важен performance. Виртуальная сеть докера может добавить задержку до 70мс.