Комментарии 12
Типичный пример обращения пользователя, когда приходится применять libastral. etcd просто так не падает, должна быть причина. Пытались ли включить автозагрузку etcd через systemd enable. Обычно это самая распространенная ошибка. Как правило etcd конфигурируется с помощь cloud-config, если использовать systemd enable etcd2, то при перезагрузке CoreOS (например при установке автоматического обновления) etcd2 сервис запустится до конфигурации системы, что может вызвать сбои.
А вобще причину нужно искать в логах. Нет информации по размеру кластера, был ли достигнут кворум. Ну и желательно сам cloud-config предоставить.
Respect kay
/me кричит из дальнего угла "LXC!", а потом ещё " OpenVZ!"
Тоже контейнеры, только применение другое.
Собственно, вопрос на который мне никто не может сформулировать внятный ответ: что делать когда надо в контейнере иметь больше одного процесса? Скажем, Консул нужен.
Да, я знаю про supervisord, но он тупой. Что-то в контейнере "встало раком", как это словить и обработать?
Как выражался один мой знакомый "Костылинг и х**чинг".
Зачем делать то, что идет вразрез с парадигмой использования технологии?
Раз уже там появляется еще и мониторинг, то почему бы не использовать уже простые виртуалки с системой управления состояниями (Salt, Chef, Puppet, ...)? Городить в таком раскладе контейнер — глупо.
Как уже ответили выше, можно использовать rkt + systemd. Кстати rkt может запускать не только контейнеры, но и полноценную изолированную виртуальную машину на основе lkvm (тут нужно сказать спасибо ребятам из Intel, которые это разработали).
True way — использовать контейнер под каждый сервис, а если требуется запутстиь нечто, что должно работать в одном контейнере — namespaces в помощь. Можно расшарить сеть (как это делается для kubernetes pods). Вот насчет pid namespace — пока только на стадии разработки (https://github.com/docker/docker/pull/22481)
https://github.com/coreos/rkt -краем уха слышал, но пока не щупал. Выглядит интересно.
Насколько я слышал о pod'ах, ими пользуется Kubernetes и там это несколько (Docker) контейнеров с общим localhost'ом. В целом — интересно. На бумаге мне это нравится больше чем Docker.
True way — использовать контейнер под каждый сервис
Так вот в том же и дело, что если использовать discovery или еще что-то, что требует резидентного приложения (читай Consul, а он такой не один), то вы автоматом отказываетесь от парадигмы "один процесс = один контейнер", что в определенных ситуациях ломает внутренние механизмы Docker.
если требуется запутстиь нечто, что должно работать в одном контейнере
тут всё просто — lxc-create и у вас появляется виртуальное окружение, пусть и с кучей ограничений, но с точки зрения управления это почти ВМ.
Я в плотную работаюс Докером, но в основнон на старых, достаточно монилтных проектах, которые регулярно патчатся но перерефакторитьих на микросервицы или нет время или нет смысла…
Однако по 2-5 контейнеров на аппликушечку набирается…
Пока хватает Docker-Compose на одной двух машинах, но тема с CoreOS очень интересна…
Мозехте просветить с вашим опытом по паре вопросов…
1) Стоит ли заморачиватся с CoreOS если сервисов пока 2-5 на аппликуху и 2, 3 виртуальных машин хватает.
2) Есть ли у вас опыт с Kubernetes который предлагхает гугл в своем опыте, мы поигрались, конечно это для наших задачь церезчур мощнан и динамическая среда… Но на рост в полне, однако мои мене опытные коллеги испугались (Инфраструктуры боятся)…
3) Есть ли у вас опыт со стэком Rancher? Воспринимается ли это как конкуренция CoreOS?
Может у вас есть общего плана совет для проектов с таким начальным количеством контейнеров и достаточно медленным их ростом, что-бы не не сильно вкладываться в инфраструктуру (в смысле майтенненса)
ни иметь по возможности максимум контроля?
1) Стоит. Как минимум для того, чтобы понабраться опыта проектирования приложения под контейнеры. С ростом проекта будет все сложнее и сложнее.
2) См. выше. Технологии Kubernetes/Mesos очень бурно развиваются. Лучше потратить силы сейчас, чем быть менее конкурентноспособным в будущем.
3) Опыта нет, но разработчики CoreOS о Rancher знают. Эти проекты всё же отличаются друг от друга, чтобы их можно было сравнивать как конкурентов.
Общий план и совет: см. выше.
Как я год работал на CoreOS