TOC

Как использовать Fleet и Fleetctl для управления кластером CoreOS

Вступление

CoreOS предоставляет отличную среду для управления контейнерами Docker в многосерверных средах. Одним из наиболее важных компонентов, упрощающих управление кластером, является сервис под названием * fleet *.

Fleet позволяет пользователям управлять контейнерами Docker как сервисами для всего их кластера. Он работает как интерфейс и уровень абстракции в системе systemd init каждого члена кластера. Пользователи могут устанавливать ограничения, которые влияют на условия, в которых работает служба. Это позволяет администраторам определять, как они хотели бы, чтобы их инфраструктура выглядела, приказывая определенным приложениям запускаться на тех же или отдельных хостах на основе предоставленных критериев.

В этом руководстве мы рассмотрим флот и утилиту + fleetctl +, которая позволяет вам управлять демоном.

Предпосылки

Чтобы следовать этому руководству, у вас должен быть доступный кластер CoreOS.

Кластер, который мы используем в этом руководстве, можно создать, следуя нашему руководству на how для создать кластер CoreOS на DigitalOcean. Предположим, что у вас есть конфигурация кластера, описанная в этом руководстве.

У настроенного кластера есть три узла. Они настроены для связи друг с другом с использованием интерфейса частной сети. Открытый интерфейс доступен на каждом из этих узлов для запуска общих служб. Имена узлов:

  • coreos-1

  • coreos-2

  • coreos-3

Когда у вас будет готов кластер, продолжайте изучать флот.

Работа с файлами сервисных модулей

Прежде чем мы перейдем к инструменту + fleetctl +, немного поговорим о файлах сервисных модулей.

Файлы модулей используются системой инициализации + systemd + для описания каждого доступного сервиса, определения команд, необходимых для управления им, и установки информации о зависимостях, чтобы гарантировать, что система находится в работоспособном состоянии при запуске каждого сервиса. Демон + fleet + построен поверх + systemd + для управления сервисами на уровне кластера. Из-за этого он использует слегка модифицированные версии стандартных файлов модулей + systemd +.

Чтобы получить более подробную информацию о файлах модулей + fleet +, следуйте нашим https://www.digitalocean.com/community/tutorials/how-to-create-f flex-services-for-a-coreos-cluster-with -fleet-unit-файлы [глубокое погружение] по теме. Для этого руководства мы просто дадим приблизительный обзор формата этих файлов. Мы также предоставим пример файла модуля, который вы можете использовать, чтобы узнать о + fleetctl +.

Разделы Файла Единицы Флота

Основные разделы, которые будут иметь большинство файлов модулей:

  • * Единица *: этот раздел используется для предоставления общей информации о единице, которая не зависит от «типа» единицы. Это будет включать в себя информацию метаданных и информацию о зависимости. Это в основном используется в + fleet + для предоставления описаний и указания места этих единиц в соединении с другими единицами обслуживания.

  • * Раздел Типа Блока *: Демон + fleet + может принимать юниты разных типов, в том числе:

  • обслуживание

  • Разъем

  • устройство

  • гора

  • Automount

  • таймер

  • Path

Если у типа есть определенные опции, то разрешается раздел связанного типа. Тип раздела + Service + является наиболее распространенным. Этот раздел используется для определения специфичных для типа атрибутов. Для модулей + Service + это обычно включает в себя определение команд запуска и остановки, а также команд до и после запуска или остановки, которые могут выполнять связанные действия.

  • * X-Fleet *: этот раздел используется для предоставления параметров конфигурации, специфичных для парка. В основном это означает, что вы можете указать, что служба должна или не должна планироваться определенным образом на основе таких критериев, как идентификатор компьютера, работающие в данный момент службы, информация о метаданных и т. Д.

Общий формат файла модуля будет:

[Unit]



[Service]



[X-Fleet]

Образец файла сервисного блока

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

vim hello.service

Внутри введите наш пример файла службы:

[Unit]
Description=My Service
After=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill hello
ExecStartPre=-/usr/bin/docker rm hello
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop hello

Давайте быстро рассмотрим, что это делает.

В разделе + [Unit] + приводится описание, и мы сообщаем + systemd +, что эта служба может быть запущена только после запуска модуля + docker.service +. Это потому, что наш модуль полагается на Docker для работы.

В разделе + [Service] + мы отключаем время ожидания запуска, а затем настраиваем некоторые действия, которые нужно выполнить до запуска службы. + ExecStartPre + выполняется перед основным действием + ExecStart +. Если они вызываются с помощью + = - +, это означает, что действие может завершиться неудачей и не повлияет на завершение службы. Это необходимо, поскольку наши действия перед запуском сводят на нет все ранее запущенные службы, которые могли работать. Это не удастся, если ничего не может быть найдено, и мы не хотим, чтобы это мешало запуску нашего сервиса, так как это всего лишь процедура очистки.

Последнее предстартовое действие опускает базовый образ busybox, который будет использоваться для запуска наших команд. Поскольку это необходимо, мы не используем синтаксис + = - +. Затем мы запускаем контейнер с этим изображением с бесконечным циклом, который выводит «Hello World» раз в секунду. Действие stop просто останавливает этот контейнер.

Этого будет достаточно, чтобы вы начали работать. Если вы хотите получить больше информации о том, как разрабатывать файлы флота, посетите https://www.digitalocean.com/community/tutorials/how-to-create-f Flexible-services-for-a-coreos-cluster-with-fleet- юнит-файлы [наше руководство по юнит-файлам флота].

Основные команды управления машиной

Первое, что мы сделаем, - познакомим вас с утилитой + fleetctl +. Как администратор кластера, этот инструмент будет вашим основным интерфейсом для управления вашим парком машин. Большая часть синтаксиса была перенесена из + systemctl +, инструмента управления systemd.

Для начала, мы можем получить список всех членов кластера, набрав:

fleetctl list-machines
MACHINE     IP      METADATA
14ffe4c3... 10.132.249.212  -
1af37f7c... 10.132.249.206  -
9e389e93... 10.132.248.177  -

Как видите, каждая из ваших машин указана здесь как доступная. Когда каждый участник загружает себя с помощью файла cloud-config, он генерирует уникальный идентификатор компьютера, который используется для идентификации каждого узла. Это записывается в файл в + / etc / machine-id.

По умолчанию автопарк будет использовать общедоступный IPv4-адрес машины для связи с другими участниками. Тем не менее, в нашем файле конфигурации облака мы сказали флоту использовать наши частные интерфейсы для связи. Это IP-адреса, показанные в выводе выше.

В приведенном выше примере столбец «METADATA» пуст. Однако мы могли бы добавить произвольные пары ключ-значение под атрибутом + metadata + для fleet в облачной конфигурации. Это может выглядеть так:

#cloud-config
. . .
coreos:
 fleet:
   public-ip: $private_ipv4
   metadata: region=europe,public_ip=$public_ipv4

Если вы установите это в облачной конфигурации для начальной загрузки всех ваших машин, ваш вывод будет выглядеть примерно так:

MACHINE     IP      METADATA
14ffe4c3... 10.132.249.212  public_ip=104.131.36.200,region=europe
1af37f7c... 10.132.249.206  public_ip=104.131.15.192,region=europe
9e389e93... 10.132.248.177  public_ip=104.131.15.192,region=europe

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

Чтобы подключиться к определенной машине в кластере, вы можете использовать команду + fleetctl ssh +. Это позволит вам идентифицировать компьютер для подключения на основе его идентификатора или компьютера, связанного с указанным именем устройства.

Например, если у вас запущен модуль с именем + nginx.service +, вы можете подключиться к любому хосту, на котором запущена эта служба, набрав:

fleetctl ssh nginx

Вы попадете в сеанс оболочки на соответствующем хосте. Вы также можете запустить одну команду на удаленном хосте, так же, как и при запуске с обычным исполняемым файлом + ssh +. Например, чтобы получить значения переменных + COREOS_PRIVATE_IPV4 + и + COREOS_PUBLIC_IPV4 +, которые CoreOS устанавливает в файле с именем + / etc / environment + (на основе параметров конфигурации облака и доступных сетевых интерфейсов), Вы можете ввести:

fleetctl ssh nginx cat /etc/environment
COREOS_PRIVATE_IPV4=10.132.249.212
COREOS_PUBLIC_IPV4=104.131.29.80

Управление Сервисом

Большинство других команд, доступных через + fleetctl +, основаны на управлении сервисами.

Запуск Сервиса

Запуск службы включает в себя довольно много шагов. Служебный файл должен быть загружен в + fleet +, чтобы он знал об устройстве. Затем он должен быть запланирован на конкретную машину из кластера. Это может быть начато. Для каждого из них есть команды с + fleetctl +, причем команды, отвечающие за последние этапы, также выполняют первый при необходимости.

Вы можете использовать команду + submit + для отправки файла вашего модуля в + fleet +. Это просто заставит + fleet + читать содержимое файла в память, делая его доступным для дальнейших действий.

fleetctl submit hello.service

Ваш файл + hello.service + теперь известен + fleet +. Чтобы просмотреть отправленные файлы юнитов, вы можете набрать:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 inactive    inactive    -

Как видите, файл модуля присутствует, но не был запланирован ни на одном хосте или запущен.

Чтобы увидеть содержимое файла модуля, о котором знает + fleet +, вы можете набрать:

fleetctl cat hello.service
[Unit]
Description=My Service
After=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill hello
ExecStartPre=-/usr/bin/docker rm hello
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop hello

Это позволит вам увидеть текущий файл, о котором знает + fleet +.

  • Примечание *: команда submit является идемпотентной, что означает, что + fleet + не будет _ обновлять файл модуля в памяти, если вы повторно отправите его. Если вам нужно обновить файл модуля, вы должны полностью удалить его, а затем повторно отправить его. Мы расскажем, как это сделать позже.

Как только ваше устройство отправлено, следующим шагом является планирование его на машине. Планирование подразделения включает в себя двигатель + fleet +, который смотрит на устройство, чтобы выбрать лучшую машину в кластере для передачи устройства. Это будет зависеть от условий в разделе + [X-Fleet] + устройства, а также от текущего объема работы каждой машины в кластере. Когда модуль был запланирован, он был передан на конкретную машину и загружен в локальный экземпляр + systemd +.

Используйте команду + load + для загрузки и планирования модуля:

fleetctl load hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212

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

Теперь, если мы проверим наши файлы модулей, мы увидим, что они были загружены. Мы даже можем увидеть, на какой машине он запланирован:

fleetctl list-unit-files
UNIT        HASH    DSTATE  STATE   TMACHINE
hello.service   0d1c468 loaded  loaded  14ffe4c3.../10.132.249.212

Это также наша первая возможность проверить команду + list-units +. Эта команда используется для отображения любых работающих или запланированных юнитов и их статусов:

fleetctl list-units
UNIT        MACHINE             ACTIVE      SUB
hello.service   14ffe4c3.../10.132.249.212  inactive    dead

Чтобы фактически запустить юнит, вы можете использовать команду + start +. Это запустит модуль на машине, на которой он был загружен, выполнив команды запуска, определенные в файле модуля:

fleetctl start hello.service
Unit hello.service launched on 14ffe4c3.../10.132.249.212

Еще раз, мы должны проверить + list-unit-files:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 launched    launched    14ffe4c3.../10.132.249.212

В приведенном выше выводе мы видим, что сервис запущен. Столбец «+ STATE» указывает «желаемое состояние», а «+ STATE» указывает фактическое состояние. Если эти два совпадения, это обычно означает, что действие было успешным.

Мы также должны снова посмотреть на + list-units +:

fleetctl list-units
UNIT        MACHINE             ACTIVE  SUB
hello.service   14ffe4c3.../10.132.249.212  active  running

Это дает нам информацию о состоянии + systemd +. Он собирается непосредственно от локального демона, так что это лучшее представление о том, как локальная система видит состояние службы. Столбец + ACTIVE + - это обобщенное состояние устройства, а + SUB + - более низкоуровневое описание.

Остановка службы

Каждая из приведенных выше команд имеет сопутствующую команду, которая меняет состояние на противоположное.

Например, чтобы остановить запуск службы, используйте команду + stop +. Это заставит экземпляр + systemd + на локальной машине выполнить команды остановки, определенные в модуле:

fleetctl stop hello.service
Unit hello.service loaded on 14ffe4c3.../10.132.249.212

Как вы можете видеть, сервис вернулся в состояние «+ загружен ». Это означает, что он все еще загружен в машинный ` systemd +`, но в данный момент он не работает. Мы можем подтвердить это здесь:

fleetctl list-unit-files
UNIT        HASH    DSTATE  STATE   TMACHINE
hello.service   0d1c468 loaded  loaded  14ffe4c3.../10.132.249.212

Чтобы удалить устройство из systemd этой машины, но оставить его доступным в + fleet +, вы можете + unload + устройство. Если устройство в данный момент активно, оно будет остановлено перед выгрузкой:

fleetctl unload hello.service

Если мы проверим состояние, то увидим, что оно помечено как неактивное. Там также нет целевой машины в списке:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 inactive    inactive    -

Если мы хотим полностью удалить подразделение из + fleet +, мы можем использовать команду + destroy +. Это остановит и разгрузит устройство, если это необходимо, а затем удалит устройство из + fleet +:

fleetctl destroy hello.service

Если вы изменяете файл юнита, вы должны уничтожить текущий юнит в + fleet + перед его отправкой / повторным запуском.

Получение статусов юнитов

Вы уже видели некоторые методы получения информации о статусе юнитов.

Например, мы рассмотрели, как + list-unit + перечислит все единицы, которые в настоящее время запланированы на машине:

fleetctl list-units
UNIT        MACHINE             ACTIVE  SUB
hello.service   14ffe4c3.../10.132.249.212  active  running

+ List-unit-files предоставляет список all модулей, о которых знает` + fleet + `. Он также дает информацию о желаемом и фактическом состоянии:

fleetctl list-unit-files
UNIT        HASH    DSTATE      STATE       TMACHINE
hello.service   0d1c468 launched    launched    14ffe4c3.../10.132.249.212

Для получения более конкретной информации о модуле, который был запущен, есть несколько других команд. Команда + status + возвращает результат + systemctl status + для службы на хосте, на котором работает устройство:

fleetctl status hello.service
● hello.service - My Service
  Loaded: loaded (/run/fleet/units/hello.service; linked-runtime)
  Active: active (running) since Mon 2014-09-08 21:51:22 UTC; 3min 57s ago
 Process: 7630 ExecStartPre=/usr/bin/docker pull busybox (code=exited, status=0/SUCCESS)
 Process: 7618 ExecStartPre=/usr/bin/docker rm hello (code=exited, status=0/SUCCESS)
 Process: 7609 ExecStartPre=/usr/bin/docker kill hello (code=exited, status=0/SUCCESS)
Main PID: 7638 (docker)
  CGroup: /system.slice/hello.service
          └─7638 /usr/bin/docker run --name hello busybox /bin/sh -c while true; do echo Hello World; sleep 1; done

Sep 08 21:55:11 coreos-3 docker[7638]: Hello World
Sep 08 21:55:12 coreos-3 docker[7638]: Hello World
Sep 08 21:55:13 coreos-3 docker[7638]: Hello World
Sep 08 21:55:14 coreos-3 docker[7638]: Hello World
Sep 08 21:55:15 coreos-3 docker[7638]: Hello World
Sep 08 21:55:16 coreos-3 docker[7638]: Hello World
Sep 08 21:55:17 coreos-3 docker[7638]: Hello World
Sep 08 21:55:18 coreos-3 docker[7638]: Hello World
Sep 08 21:55:19 coreos-3 docker[7638]: Hello World
Sep 08 21:55:20 coreos-3 docker[7638]: Hello World

Как вы можете видеть, мы наконец-то можем убедиться, что вывод нашего блока производится.

Аналогично, если вы хотите просмотреть запись журнала для службы, которая доступна на соответствующем компьютере, вы можете использовать команду + journal +:

fleetctl journal hello.service
-- Logs begin at Mon 2014-09-08 14:22:14 UTC, end at Mon 2014-09-08 21:55:47 UTC. --
Sep 08 21:55:38 coreos-3 docker[7638]: Hello World
Sep 08 21:55:39 coreos-3 docker[7638]: Hello World
Sep 08 21:55:40 coreos-3 docker[7638]: Hello World
Sep 08 21:55:41 coreos-3 docker[7638]: Hello World
Sep 08 21:55:42 coreos-3 docker[7638]: Hello World
Sep 08 21:55:43 coreos-3 docker[7638]: Hello World
Sep 08 21:55:44 coreos-3 docker[7638]: Hello World
Sep 08 21:55:45 coreos-3 docker[7638]: Hello World
Sep 08 21:55:46 coreos-3 docker[7638]: Hello World
Sep 08 21:55:47 coreos-3 docker[7638]: Hello World

По умолчанию это покажет последние 10 строк. Вы можете изменить это, добавив параметр + - lines +, например так:

fleetctl journal --lines 20 hello.service

Вы также можете использовать параметр + -f +, который означает «следовать». Это ведет себя подобно + tail -f + в том смысле, что он будет продолжать передавать последние записи журнала:

fleetctl journal -f hello.service

Заключение

Научившись эффективно использовать + fleet + и + fleetctl +, вы легко сможете управлять кластером CoreOS. Ваши услуги и контейнеры можно перемещать на разные машины без особых проблем.

В следующем руководстве мы обсудим более подробно https://www.digitalocean.com/community/tutorials/how-to-create-f flex-services-for-a-coreos-cluster-with-fleet-unit -files [как создавать файлы юнитов флота]. Это позволит вам создавать гибкие и мощные сервисы, использующие преимущества архитектуры CoreOS.

Related