Pull to refresh
18
0
flashvoid @flashvoid

User

Send message

Не в качестве претензии а обсуждения для: почему IT?

  • Потому что автор может помочь только с ИТ? - логично но автор может помочь только с ограниченным доменом ИТ знаний хотя принимает заявки хоть "на С"

  • Потому что в ИТ есть установленный механизм открытых исходников? - то же логично.

  • Потому то автор так решил для себя? - справедливо, но я думаю автор тут написал в легкой надежде вдохновить других авторов на подобные действия.

В идеале разработчик с огладкой на админа, в реальности админ с оглядкой на разработчика.
А в чем проблема хранить несколько версий одной кукбуки на chef сервере?
Задавать через chef_environment, который править через berkshelf.
Почти то же самое на примере nginx и в исполнении разработчиков докера — типа best practice.
Ну это же только вопрос времени, сейчас докер это тул для деплоя _своего_ кода. А в перспективе это будет такой же менеджер как 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 либо не в контейнере.
Ну так используй nginx вместо прокси.
Flannel входит не в Kubernetes, а в CoreOS.
Вообще у них очень тесные взаимоотношения, команда CoreOS использует fleet чтобы стартануть kubernetes и дальше работают в последнем. Существует вероятность что fleet просто заменят в один прекрасный момент,
Мне кажется для новичка статья будет неподъемная, а для продолжающих полезнее не сама статья, а мнения из комментов.
Может устроить хабра версию foodfightshow?
1. У Chef нормальная документация и всегда такой была: docs.chef.io/. Но если не знать где искать, на их сайте она немного неочевидно ищется.


Ну не скажите, последние полтора-два года chef сообщество приложило чудовищные усилия что бы облегчить жизнь новичкам и улучшить документацию в частности.
Ага, один момент — в ProbeRequest не то что бы сильно обязательно использовать свой настоящий мак — чем и воспользовалась Apple. Они потихоньку внедряют код, который будет использовать случайные мак адреса в пробах.

Однако даже в этом случае можно бобороться используя служебную информацию из других пакетов. Но это совсем другая история.
Ок. А как с зависимостями — обновили конфиг и надо передернуть демона?
Ansible это интересно.

Вопросы по теме:
Как там с гетерогенностью — насколько удобно создавать много разных серверов с похожими, но слегка отличающимися конфигами?
Как там с индемпотентностью — еcли я попрошу скачать фаил он будет его скачивать каждый раз или проверит что фаил уже есть?
Есть ли какие то решения кроме ssh — если я открою 10к ssh сессий одновременно моей системе поплохеет.
Хм. Куда уж серьезнее.
Вот потому, что этого не пишут на оффсайте, я пишу это тут.
Качать доверенные образы вроде ubuntu скорее всего ок, но существует вожможность скрафтить образ, который выполнит произвольный код на удаленной машине плюс проверки на добавление образа в docker.io никакой.

А выбор кому доверять всегда за Вами.
Всем кто интересуется контейнерами очень рекомендую вот это выступление

Оно было эпично по нескольким причинам.
Во первых — это официальный ответ Docker.io на тему как правильно готовить контейнеры в условиях ужесточившейся критики со стороны фюженов, кореосей и пр.
Во вторых — эти ребята очень хорошо знают кухню контейнеров и результат их метод дает отменный coreos/etcd уменьшился с 600Mb до 20Mb.
В третьих — если система требует такого извращения, то наверное система спроектирована не очень хорошо.

P.S. На каждом выступлении по контейнерам напоминали _не_использовать_ docker pull. Он настолько уязвим что даже запускать контейнер ненадо, к тому времени как он скачался уже поздно.

Information

Rating
Does not participate
Location
Тауранга, Bay of Plenty, Новая Зеландия
Date of birth
Registered
Activity