Ну это же только вопрос времени, сейчас докер это тул для деплоя _своего_ кода. А в перспективе это будет такой же менеджер как apt, и образы будут так же выпекаться в каноникле или еще где то в проверенном месте.
Когда-нибудь пробовали сделать обновление безопасности для контейнера?
А как вы обновляете бинарные пакеты — скачиваете свежие из apt/yum/wtf. То же и с докером — скачиваете новый образ.
За отутствие цифровой подписи его много и справедливо ругали — но докер привлек много денег и деньги надо отбивать — нету у них времени закрывать баги.
Ответ прост appc и rocket.
С докером же правило простое — качай Dockerfile, собирай у себя и толкай во внутренний registry.
Смысл контейнеров заключается в бинарных апдейтах. В вашем случае это удобно для выкатывания обновлений php. В норме у вас app сервер, помимо php, будет содержать всякие утилиты типа imagemagic и прочие зависимости системы которые, могут уходить глубоко в libc.
Каждый раз когда вы выкатываете обновление обновление на конфигурацию app сервера вы рискуете получить отличающееся состояние. Докер гарантирует, что обновления будут идентичными.
Но статья-то про кубернетис, а это следующий шаг после контейнров — scheduled deployments. Тут две радости — во первых удобно следовать infrastructure as code, во вторых масштабировать систему очень приятно — говоришь я хочу еще 10 этих контецнеров и через 5 секунд они работают.
Бывают volumes между хостом и контейнером, а бывают между ондинм контейнером и другим.
Оригинальное использование volumes именно между контейнерами — команда докера так делает бекапы и логи в вообщем все.
Volumes между хостом и контейнером считаются плохим тоном, хотя зря наверное, я люблю всякие сокеты с хоста прокидывать.
Оригинальный ответ от команды docker — используйте volumes.
Это такие контейнеры которые не запускают сервисов но хранят данные и могут шарить эти данные с другими контейнерами.
К сожалению идея работает очень убого ибо отключить и подключить volume к контейнеру можно только перезапуском самого контейнера.
Ну а базы данных так либо на Gluster либо не в контейнере.
Flannel входит не в Kubernetes, а в CoreOS.
Вообще у них очень тесные взаимоотношения, команда CoreOS использует fleet чтобы стартануть kubernetes и дальше работают в последнем. Существует вероятность что fleet просто заменят в один прекрасный момент,
Мне кажется для новичка статья будет неподъемная, а для продолжающих полезнее не сама статья, а мнения из комментов.
Может устроить хабра версию foodfightshow?
1. У Chef нормальная документация и всегда такой была: docs.chef.io/. Но если не знать где искать, на их сайте она немного неочевидно ищется.
Ну не скажите, последние полтора-два года chef сообщество приложило чудовищные усилия что бы облегчить жизнь новичкам и улучшить документацию в частности.
Ага, один момент — в ProbeRequest не то что бы сильно обязательно использовать свой настоящий мак — чем и воспользовалась Apple. Они потихоньку внедряют код, который будет использовать случайные мак адреса в пробах.
Однако даже в этом случае можно бобороться используя служебную информацию из других пакетов. Но это совсем другая история.
Вопросы по теме:
Как там с гетерогенностью — насколько удобно создавать много разных серверов с похожими, но слегка отличающимися конфигами?
Как там с индемпотентностью — еcли я попрошу скачать фаил он будет его скачивать каждый раз или проверит что фаил уже есть?
Есть ли какие то решения кроме ssh — если я открою 10к ssh сессий одновременно моей системе поплохеет.
Вот потому, что этого не пишут на оффсайте, я пишу это тут.
Качать доверенные образы вроде ubuntu скорее всего ок, но существует вожможность скрафтить образ, который выполнит произвольный код на удаленной машине плюс проверки на добавление образа в docker.io никакой.
Всем кто интересуется контейнерами очень рекомендую вот это выступление
Оно было эпично по нескольким причинам.
Во первых — это официальный ответ Docker.io на тему как правильно готовить контейнеры в условиях ужесточившейся критики со стороны фюженов, кореосей и пр.
Во вторых — эти ребята очень хорошо знают кухню контейнеров и результат их метод дает отменный coreos/etcd уменьшился с 600Mb до 20Mb.
В третьих — если система требует такого извращения, то наверное система спроектирована не очень хорошо.
P.S. На каждом выступлении по контейнерам напоминали _не_использовать_ docker pull. Он настолько уязвим что даже запускать контейнер ненадо, к тому времени как он скачался уже поздно.
Не в качестве претензии а обсуждения для: почему IT?
Потому что автор может помочь только с ИТ? - логично но автор может помочь только с ограниченным доменом ИТ знаний хотя принимает заявки хоть "на С"
Потому что в ИТ есть установленный механизм открытых исходников? - то же логично.
Потому то автор так решил для себя? - справедливо, но я думаю автор тут написал в легкой надежде вдохновить других авторов на подобные действия.
Задавать через chef_environment, который править через berkshelf.
А как вы обновляете бинарные пакеты — скачиваете свежие из apt/yum/wtf. То же и с докером — скачиваете новый образ.
За отутствие цифровой подписи его много и справедливо ругали — но докер привлек много денег и деньги надо отбивать — нету у них времени закрывать баги.
Ответ прост appc и rocket.
С докером же правило простое — качай Dockerfile, собирай у себя и толкай во внутренний registry.
Каждый раз когда вы выкатываете обновление обновление на конфигурацию app сервера вы рискуете получить отличающееся состояние. Докер гарантирует, что обновления будут идентичными.
Но статья-то про кубернетис, а это следующий шаг после контейнров — scheduled deployments. Тут две радости — во первых удобно следовать infrastructure as code, во вторых масштабировать систему очень приятно — говоришь я хочу еще 10 этих контецнеров и через 5 секунд они работают.
Оригинальное использование volumes именно между контейнерами — команда докера так делает бекапы и логи в вообщем все.
Volumes между хостом и контейнером считаются плохим тоном, хотя зря наверное, я люблю всякие сокеты с хоста прокидывать.
Это такие контейнеры которые не запускают сервисов но хранят данные и могут шарить эти данные с другими контейнерами.
К сожалению идея работает очень убого ибо отключить и подключить volume к контейнеру можно только перезапуском самого контейнера.
Ну а базы данных так либо на Gluster либо не в контейнере.
Вообще у них очень тесные взаимоотношения, команда CoreOS использует fleet чтобы стартануть kubernetes и дальше работают в последнем. Существует вероятность что fleet просто заменят в один прекрасный момент,
Может устроить хабра версию foodfightshow?
Ну не скажите, последние полтора-два года chef сообщество приложило чудовищные усилия что бы облегчить жизнь новичкам и улучшить документацию в частности.
Однако даже в этом случае можно бобороться используя служебную информацию из других пакетов. Но это совсем другая история.
Вопросы по теме:
Как там с гетерогенностью — насколько удобно создавать много разных серверов с похожими, но слегка отличающимися конфигами?
Как там с индемпотентностью — еcли я попрошу скачать фаил он будет его скачивать каждый раз или проверит что фаил уже есть?
Есть ли какие то решения кроме ssh — если я открою 10к ssh сессий одновременно моей системе поплохеет.
Качать доверенные образы вроде ubuntu скорее всего ок, но существует вожможность скрафтить образ, который выполнит произвольный код на удаленной машине плюс проверки на добавление образа в docker.io никакой.
А выбор кому доверять всегда за Вами.
Оно было эпично по нескольким причинам.
Во первых — это официальный ответ Docker.io на тему как правильно готовить контейнеры в условиях ужесточившейся критики со стороны фюженов, кореосей и пр.
Во вторых — эти ребята очень хорошо знают кухню контейнеров и результат их метод дает отменный coreos/etcd уменьшился с 600Mb до 20Mb.
В третьих — если система требует такого извращения, то наверное система спроектирована не очень хорошо.
P.S. На каждом выступлении по контейнерам напоминали _не_использовать_ docker pull. Он настолько уязвим что даже запускать контейнер ненадо, к тому времени как он скачался уже поздно.