Comments 22
Хотя эти две рекомендации, лучше запуска от имени root, они работают не во всех окружениях, например таких как OpenShift.
Господа переводчики, все-таки переводить надо получше как-то, очень poor английский language.
Но иногда даже официальные образы могут не подойти из соображений безопасности или большого размера. В качестве примера сравните официальный образ node и bitnami/node. Последний предлагает различные версии поверх дистрибутива minideb.Зато официальные образы гарантируют поддержку и совместимость.
Пару лет назад, при обновлении bitnami/redmine между релизами 3.4 (кажется с 3.4.9 на 3.4.10) новый контейнер просто «убил» базу данных. С официальными сборками того же Redmine подобного не наблюдалось, в итоге перешли на официальные, экономить на размере рискуя получить кирпич вместо сервиса такое себе.
Я очень не люблю контейнеры без базовой системы. Почему? Потому что когда в них что-то хитро ломается (в продакшене, в продакшене), время, которое тратится на получение доступа во внутрь контейнера плюсуется к времени аварии. Снаружи можно смотреть на происходящее в контейнере только до определённого момента. Дальше нужно запустить tcpdump внутри, grep'нуть по какому-то файлу, попробовать коннект из контейнера (curl, nc), посмотреть на ресолвер пристально (host/dig).
Если это всё отбирают у оператора, оператор начинает считать вам штрафной даунтайм.
Как вариант – можно все это собрать заранее, и копировать по мере надобности в контейнеры.
… И при копировании/подцеплении по мере надобности (например, с помощью volume'ов) всё время, которое операторы выясняют, что им не дали ни sh, ни ps, часики даунтайма тикают.
Тогда можно просто остановить сборку на втором этапе и задеплоить «дебаг» образ вместо «продакшен», приложение при этом будет то же самое. Я просто не знаю, как у вас всё организовано, можно ли будет так.
Дело не в сборке. Если у вас transient (переходящая) проблема в продакшен-образе, то есть 90% вероятность, что после перезапуска контейнера она пройдёт. В этой ситуации, можно "починить" всего лишь рестартанув. Хотя, есть вероятность, что станет ещё хуже.
Операторам нужны нормальные инструменты отладки в том месте, где сломалось, а не там, где светло и есть инструменты отладки.
У нас организовано совсем не так по причинам специфики бизнеса. Но это general sense. Забираете у оператора инструменты — оператор у вас забирает аптайм.
github.com/zeromake/docker-debug
Позволяет «присоединить» к работающему контейнеру другой, содержащий необходимые диагностические инструменты.
from customize image runs a new container
Отлично подходит для программистов, чтобы понять что за фигня случилась в контейнере, полностью не подходит для продакшена, где нужно найти root cause странной неведомой фигни (это никогда не arp, только не в этот раз).
Повторю: контейнеры для разработчика это "шлёп-шлёп упал-поднялся". Для оператора — это "корова, застрявшая в бомболюке". Перезапустить легко и просто, а вот понять как она там застряла и как сделать, чтобы такого больше не было — сложно, и требует инструментария.
(Это я не разбираю вопросов, когда "контейнеры не перезапускаются, потому что BUG, TASK_UNINTERRUPTIBLE и т.д.)
- Контекст сборки и dockerignore
Гораздо удобней для этих целей не создавать определенную структуру проекта, а использовать buildkit, который позволяет для каждого dockerfile положить рядом соответствующий dockerignore, а dockerignore описать как whitelist. Это позволяет контролировать что попадает в контекст при билде, отчасти упрощает написание самих dockerfile и сильно упрощает жизнь если надо сбилдить два разных образа из одного репозитория (nginx + php, например)
buildkit уже включен в последние версии docker, включается просто переменной окружения.
https://docs.docker.com/develop/develop-images/build_enhancements/
- Rootless контейнеры
Рекомендуем избегать этого.
… рассказ о том как…
Приведенные рекомендации, намного лучше запуска от имени root
Похоже на "грузины лучше чем армяне. Чем лучше? Чем армяне". Так и не приведены аргументы, почему "rootless" лучше чем "rootful". Непонятны преимущества, ради которых надо страдать.
Да просто набор советов кочует из статьи в статью. Root внутри контейнера абсолютно безопасен если использовать user namespace. Так например запускаются контейнеры на circleCI.И это спасло их от CVE-2019-5736.
Карго-культ чистой воды. Ритуальное сложение прав (которых и так нет).
А можно чуть подробнее в двух словах? Имеется ввиду «в окружении dev мы позволяем себе хранить пароли прямо в parameter-file, но в проде такого нет» — не делать так? Или что-то другое?
20 лучших практик по работе с Dockerfile