Докер, CoreOS и флота развертывания

Question

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

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

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

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

Answer 1

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

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

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 слушает события ядра. Для каждого события systemd-udevd выполняет соответствующие инструкции, указанные в правилах udev. Смотрите udev (7).
  • logind - systemd-logind - системная служба, которая управляет логинами пользователей.
  • resolved - systemd-resolved - системная служба, которая управляет разрешением сетевых имен. Он реализует кэширующий преобразователь заглушки DNS, а также преобразователь и ответчик LLMNR.
  • hostname - это крошечный демон, который можно использовать для управления именем хоста и соответствующими метаданными компьютера из пользовательских программ.
  • networkd - systemd-networkd - системный сервис, управляющий сетями. Он обнаруживает и настраивает сетевые устройства по мере их появления, а также создает виртуальные сетевые устройства.

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

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

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

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

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

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

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

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

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

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

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

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

(и другие вещи).

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

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

-г

Answer 2

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

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

Все должно либо выполняться в контейнере, либо статически компилироваться (например, в двоичных файлах golang), либо быть сценарием оболочки. Там не установлен Python или Ruby.

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

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

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

Answer 3

Какие объективные преимущества я получу, перейдя Docker/CoreOS против Docker/Ubuntu?

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

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

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

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

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

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

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

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

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

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

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