Docker, CoreOS и развертывание на флоте

Я пытаюсь обернуть голову вокруг CoreOS, и я просмотрел их официальные документы, некоторые случайные статьи и даже просмотрел это отличная презентация их технического директора.

  • Мое понимание CoreOS заключается в том, что его лишенный дистрибутива Linux, который требует, чтобы на нем работало OCF-совместимый контейнер, а не только Docker контейнер.
  • Мое понимание флота заключается в том, что его systemd на уровне кластера
  • Мое понимание flannel заключается в том, что его сетевой уровень используется как etcd и флот для маршрутизации сетевых запросов на контейнеры, живущие в кластере

Итак, сначала, если мои вышеприведенные утверждения неверны или введены в заблуждение, пожалуйста, начните с исправления! Предполагая, что я более или менее на ходу, у меня есть несколько проблем здесь:

  • Какие конкретные преимущества CoreOS предлагают приложения для Docker, которые отсутствуют в других дистрибутивах Linux, таких как Ubuntu или Debian? Другими словами, какие объективные преимущества я получаю, перейдя Docker/CoreOS против Docker/Ubuntu?
  • Флот просто кажется механизмом планирования, например, Mesos или Kubernetes. Является ли это прямым конкурентом этим проектам или они обрабатывают планирование в разных "слоях" (разные типы обязанностей)? Если да, то каковы эти различия?

ОТВЕТЫ

Ответ 1

Здесь много движущихся частей. Ответ уже опубликован очень хорошо. Я думаю, что в любом ответе вы найдете мнения. Я думал, что пройду свой список ударов в своей попытке на 100 пунктов: -)

Я использую CoreOS/Flannel/Kubernetes/Fleet каждый день в течение примерно 6 месяцев. Когда вы разместили URL-адрес для введения, я решил посмотреть его. Ничего себе, отличная презентация. Я думаю, что Брэндон Филипс - очень хороший учитель. Мне нравится, как он основывался на каждой технологии, когда он представил ее. Я рекомендовал бы этот учебник для всех.

CoreOS - это операционная система на основе Linux. Он очень убран, ничего лишнего. Для меня он делает следующее:

  • Автоматическое обновление. Это хорошо. Двойные разделы, обновления неактивны, свопы активны, отпадают (я думаю, я никогда не испытывал спада). Они решили проблему "как обновить вашу операционную систему после развертывания" и сделали ее относительно безболезненной.
  • systemd init system. Это заняло у меня немного больше времени, чтобы понравиться (будучи парнем /etc/init.d), но через некоторое время он растет на вас. Существует довольно крутая кривая обучения. Как только вы получите то, что происходит, вам понравится, как systemd поддерживает работу с конкретными вещами, зависимостями, перезагрузками (если хотите), прослушиванием сокетов (например, super initd) и нерестится, d-bus (хотя я не знаю многое об этой части еще). systemd позволяет вам указывать "единицы", а единицы могут иметь зависимости, процессы до и после и т.д.
  • основные услуги. Я скопировал краткую строку описания из каждой службы, которая работает в моей системе CoreOS.
    • systemd - он предоставляет диспетчер системы и обслуживания, который работает как PID 1 и запускает остальную часть системы.
    • docker - Docker - это проект с открытым исходным кодом для упаковки, отправки и запуска любого приложения в виде легкого контейнера.
    • etcd - etcd - это распределенное, согласованное хранилище ключей для общей конфигурации и обнаружения службы.
    • sshd - sshd (OpenSSH Daemon) - это программа демона для ssh (1). Вместе эти программы заменяют rlogin и rsh и обеспечивают безопасную зашифрованную связь между двумя ненадежными хостами по небезопасной сети.
    • locksmithd - locksmith - это диспетчер перезагрузки для механизма обновления ядра CoreOS, который использует etcd, чтобы гарантировать, что только подмножество кластера машин перезагружается в любой момент времени. locksmithd работает как демон на машинах CoreOS и отвечает за контроль над поведением перезагрузки после обновлений.
    • journald - systemd-journald - это системная служба, которая собирает и хранит данные ведения журнала.
    • timesyncd - systemd-timesyncd - системная служба, которая может использоваться для синхронизации локальных системных часов с сервером удаленного сетевого протокола.
    • update_engine
    • udevd - systemd-udevd слушает ядро ​​uevents. Для каждого события systemd-udevd выполняет соответствующие инструкции, указанные в правилах udev. См. Udev (7).
    • logind - systemd-logind - системная служба, которая управляет входами пользователя.
    • resolved - systemd-resolved - это системная служба, которая управляет разрешением имени сети. Он реализует кэширующий DNS-заглушку и средство распознавания LLMNR и ответчика.
    • hostnamed - это крошечный демон, который можно использовать для управления именем хоста и связанными с ним метаданных в пользовательских программах.
    • networkd - systemd-networkd - это системная служба, которая управляет сетями. Он обнаруживает и настраивает сетевые устройства по мере их появления, а также создает виртуальные сетевые устройства.

CoreOS не обязательно требует, чтобы все, что вы хотите запустить, должно быть контейнером. Он будет запускать все, что будет запускать блок unix. yum и apt-get явно отсутствуют, но wget включен. Таким образом, вы можете "устанавливать" программы, библиотеки, даже apt-get через wget и быть на пути к загрязнению базы CoreOS. Это было бы неплохо. Вы действительно хотите сохранить его в чистом виде. С этой целью они включают в себя "набор инструментов", который позволяет запускать контейнер как песочницу для выполнения вашей работы, которая исчезает, когда вы выходите из нее.

Моя любимая часть CoreOS - это облако-config. При первой загрузке вы можете предоставить user_data, называемую облачной конфигурацией. Это файл yaml, который сообщает базовому CoreOS, что делать, когда он загружается в первый раз. Здесь вы устанавливаете такие вещи, как флот, фланель, кубернеты и т.д. Это очень простой способ получить повторяющуюся установку комбинации по вашему выбору на виртуальной машине. В типичной конфигурации cloud-config я буду писать файлы конфигурации, копировать файлы с других компьютеров для установки на новую машину и создавать файлы модулей, которые управляют другими процессами, которые мы хотим, чтобы система CoreOS управляла (например, фланель, флот и т.д.). И это вполне повторяемо.

Вот еще одна интересная вещь о CoreOS. Вы можете изменить зависимость и конфигурацию существующих устройств. Например, CoreOS начинает докер. Но я хочу изменить последовательность запуска докера, поэтому я могу добавить конфигурацию с добавлением, которая добавляет конфигурацию существующей системы докеров. Я использую это для включения зависимостей для фланели перед запуском докеров, поэтому я могу настроить докер для использования сети, снабженной фланелем. Это не обязательно CoreOS, но, это делает все это подходящим.

Я думаю, вы можете использовать cloud-config с Ubuntu, а также с CoreOS, и вы можете делать то же самое. Итак, я думаю, что выгода от CoreOS над Ubuntu будет заключаться в том, что вы часто получаете новую версию, операционная система автоматически обновляется, и у вас нет ничего "лишнего" запуска (это худой и уменьшенный вектор атаки это осадок). CoreOS настроен для докеров (он уже запущен), а ubuntu уже не работает. Хотя, вы можете создать файл облачной конфигурации, который заставит ubuntu запускать докеры... В общем, я думаю, что вы поняли, что CoreOS.

Еще одна вещь, которую вы можете получить с помощью CoreOS, - это поддержка, непосредственно от компании, либо платная, либо неоплачиваемая. У меня было много вопросов, заданных людьми из CoreOS через этот форум и группы пользователей Google CoreOS Dev/CoreOS.

Ваше описание флота также очень хорошо. Флот управляет кластером. Кластер - это одна или несколько машин CoreOS. Итак, если вы собираетесь использовать флот, вы должны использовать CoreOS, я думаю, это было бы еще одним из преимуществ CoreOS над Ubuntu.

Похоже на то, как файл Unit для элементов управления systemd запускает процесс на хосте, - файл модуля для элементов управления fleetd, выполняющих процесс в кластере. Существует немного синтаксического сахара, но файл Unit для флота примерно такой же, как файл unit для systemd. Они прекрасно сочетаются. Файлы блоков флота сохраняются в базе данных etcd, поэтому после проглатывания устройство остается постоянным, даже если машина (ы), на которой размещена служба устройства, спускается вниз, описание устройства существует в etcd.

У Fleet также есть команды для перечисления моих машин в моем кластере, перечисления файла блока, показывающего выполняемые единицы и т.д. В принципе вы можете отправлять единицы для запуска в кластере (или на всех машинах или на определенный тип (например, с дисками ssd) или на том же компьютере, что и другое (сродство) и т.д. и т.д.).

Флот продолжает работать. Если машина уйдет, его блоки будут запущены на другой машине в кластере.

В учебнике, в котором вы ссылаетесь, Брэндон использует Fleet для запуска Kubernetes. Это очень просто сделать. Делая файлы блоков Fleet, Kubernetes размещает Kubernetes на всех машинах кластера флота, поскольку машины добавляются и вычитаются из кластера флота. Кубернетес автоматически использует эту машину и планирует запуск Kubernetes на них. Я тоже запустил кластер Kubernetes. Однако я больше этого не делаю. Я уверен, что есть такая польза, которую я не вижу, но я чувствую, что это не нужно в моей среде. Так как я уже загружаю свои машины с помощью файла с облачной конфигурацией, тривиальным образом можно установить сервисы Kubernetes node. Фактически, с облачной конфигурацией, если бы я хотел использовать Fleet для загрузки материала Kubernetes, мне пришлось бы писать файлы блоков Fleet, запускать Fleet, отправлять файлы модулей, которые я написал в Fleet, когда я мог просто написать файл блока для запуска Кубернетов node. Но я отвлекаюсь...

Флот - это механизм планирования, как и Кубернетес. Однако Fleet может запускать любой исполняемый файл, как systemd, через единичный файл, где Kubernetes ориентирован на контейнеры. Кубернетес позволяет определить:

  • контроллеры репликации
  • услуги
  • стручки
    • контейнеры

(другие вещи также).

Итак, утверждение, что флот - это просто "слой" планирования, является хорошим. Вы можете добавить, что Флот планирует разные вещи. В своей работе я не использую слой Fleet, я просто прыгаю прямо в Kubernetes, потому что я работаю только с контейнерами.

Наконец, утверждение о фланеле неверно. Flannel использует etcd для своей базы данных. Flannel создает частную сеть для каждого хоста, которая маршрутизирует между ними. Флинковая сеть передается докере, и докеру предлагается использовать эту сеть для назначения адресов ip. Таким образом, процессы докеров, которые используют фланель, могут связываться друг с другом по ip. Все файлы сопоставления портов можно пропустить, поскольку каждый контейнер получает свой собственный IP-адрес. Эти докерные процессы могут передавать инфракрасную и внутреннюю машины по сети фланелей. Я могу ошибаться, но я не думаю, что есть какая-то связь между Флотом и фланелем. Кроме того, я не думаю, что etcd или Fleet используют фланель для маршрутизации своих данных. Etcd и Fleet определяют, используется ли фланель. Контейнеры-докеры направляют трафик по фланеле.

-g

Ответ 2

Да, ваше понимание в значительной степени правильное.

Coreos разработан как более безопасная операционная система, которая автоматически настраивается по умолчанию и использует минимальный уровень обслуживания для уменьшения любого вектора атаки. http://www.activestate.com/blog/2013/08/alex-polvi-explains-coreos

Все нужно либо запускать в контейнере, либо статически компилироваться (например, в качестве исполняемых файлов golang), либо быть оболочкой script. Не установлен python или ruby.

Контейнеры/системные блоки, запускаемые Fleet, могут быть перенесены на другой node, если его сервер завершится с ошибкой (при условии, что контейнер является эфемерным) и должен сохранить запрошенное количество экземпляров, запущенных по кластеру, и подчиняться ограничениям развертывания. https://coreos.com/using-coreos/clustering/

Mesos - это скорее платформа для планировщика, вам все еще нужно что-то еще (chronos/marathon), чтобы обеспечить выполнение заданий, но оно очень гибко в этом отношении и лучше справляется с использованием ресурсов сервера.

У меня нет большого опыта работы с Flannel, но новые сетевые плагины, входящие в будущую версию Docker, могут предоставить вам больше возможностей для создания сетей в контейнерах. http://blog.docker.com/2015/06/networking-receives-an-upgrade/

Ответ 3

какие объективные выгоды я получу, перейдя в Docker/CoreOS vs. Docker/Ubuntu?

Технические преимущества

Функции, которые привлекают меня к CoreOS:

  • Это кластер, а не одна машина, ОС
  • Он построен с ошибкой
  • Самообновление

CoreOS - это кластер, а Ubuntu - одна машина. Когда CoreOS, когда машина, на которой запущен контейнер, исчезает, кластер запускает контейнер в другом месте. Когда этот сервер Ubuntu выходит из строя, его контейнеры идут вниз. CoreOS позволяет машине быть одноразовым, что хорошо.

С учетом сказанного, имейте в виду CoreOS не обрабатывает постоянство данных; данных, хранящихся в контейнере, не существует!;) В моем случае я динамически при необходимости добавляю тома EBS.

Преимущества дизайна

Для меня более важно то, что технические преимущества выше приносят с собой преимущества дизайна. Идя в систему, зная, что "этот процесс будет беспорядочно исчезать", отлично подходит для создания отказоустойчивости. С самого начала службы не имеют статуса и, поскольку вы в буквальном смысле понятия не имеете, какая система зависит от службы, они также должны быть доступны для обнаружения. CoreOS etcd, хранилище распределенной конфигурации, может быть использовано для обнаружения того, где находится служба. Наконец, поскольку процессы могут быть не на одном компьютере, доступ к сети - обязательный для горизонтально масштабируемых систем - единственный способ пойти.

В целом, я считаю, что CoreOS отлично подходит для создания Двенадцатифакторных приложений, и вы получаете Chaos Monkey бесплатно.

Флот просто кажется механизмом планирования, например, Mesos или Kubernetes. Является ли это прямым конкурентом этих проектов или они справляются планирование на разных "слоях" (различные типы обязанности)? Если да, то каковы эти различия?

Да, Флот планирует контейнер и определяет, где он находится в кластере. Если эта машина исчезнет, ​​Fleet также берет на себя ответственность за повторное запуск ее на рабочей машине.

Я не совершил глубокого погружения в Кубернете, но похоже, что это перекрытие. До сих пор я понимаю, что Fleet управляет запуском одного контейнера ( "единицы" ), в то время как Kubernetes дополняет и организует несколько блоков, входящих в систему. Например, Fleet гарантирует, что Postgres будет работать; Kubernetes обеспечивает ваше приложение, например. состоящие из Postgres, Redis и Django, все напевают.