Как устранять типичные проблемы с вашими серверами CoreOS

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

В этом руководстве мы рассмотрим некоторые основные процедуры устранения неполадок для работы с хостами CoreOS, контейнерами Docker, которые они запускают, и инструментами управления сервисами, которые объединяют некоторые разрозненные компоненты.

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

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

Некоторые вещи, которые нужно проверить с помощью файла cloud-config:

Вы можете передать файл cloud-config только при создании машины, поэтому, если вы допустили ошибку, уничтожьте экземпляр сервера и запустите снова (в большинстве случаев с новым токеном).

Если вы уверены, что файл cloud-config сам по себе правильный, следующий шаг - войти на хост, чтобы убедиться, что файл был обработан правильно.

В большинстве случаев это должно быть легко, так как в DigitalOcean вы должны добавлять ключи ssh на сервер во время создания. Это означает, что вы можете без проблем подключиться к серверу по ssh.

Как только вы вошли в систему, есть несколько вещей, которые вы должны проверить, чтобы убедиться, что ваш cloud-config был обработан правильно.

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

К счастью, разработчики CoreOS предлагают элегантное решение этой проблемы. Используя скрипт «toolbox», включенный в каждый хост, вы можете запустить контейнер Fedora с доступом к хост-системам. Внутри этого контейнера вы можете установить любые утилиты, необходимые для отладки хоста.

Чтобы запустить его, просто используйте команду + toolbox +:

Это опустит последний образ Fedora и поместит вас в командную строку внутри контейнера. Если вы сделаете несколько быстрых проверок, вы поймете, что у вас есть доступ к сети хост-системы:

У вас также есть полный доступ к процессам хоста:

В этой среде вы можете установить любые инструменты, которые вам нужны. Например, мы можем установить + htop +, главный клон с дополнительными функциями, используя менеджер пакетов Fedora:

Это вызовет монитор процессов со всеми загруженными процессами хоста.

Чтобы выйти из среды контейнера, введите «exit» или трижды быстро нажмите «+ CTRL -] +». Вы попадете обратно в сессию оболочки хоста.

Еще одна область, в которой вам может потребоваться устранить неполадки, - это действующие службы, которые вы используете. Поскольку у нас есть + fleet + и + fleetctl + для управления нашими службами во всем кластере, наши первые шаги могут быть выполнены на любом из серверов в нашем кластере.

Мы должны начать с представления о состоянии ваших услуг, как с точки зрения «+ fleet », так и с отдельных хостов, которые были назначены для запуска каждой службы. Инструмент ` fleetctl +` дает нам команды, чтобы легко получить эту информацию.

Во-первых, получите представление о том, как + fleet + видит состояние сервиса, набрав:

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

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

Однако это не единственное важное место для проверки. Важно понимать, что бывают случаи, когда + fleet + не соглашается с локальным экземпляром машины + systemd + о состоянии службы. Это может произойти по разным причинам, например, если один блок запускает или останавливает другой блок внутри.

Чтобы получить информацию о состоянии каждой службы, взятую из экземпляра + systemd + хоста, на котором выполняется эта служба, используйте вместо этого команду + list-units +:

Здесь мы видим, что все службы перечислены как работающие. Это не согласуется с информацией, которую показывает + list-unit-files. Это связано с тем, что каждая из служб + apache запускает соответствующую службу` + apache-discovery`, не сообщая об этом + fleet +. Это не ошибка, но может привести к путанице в отношении фактического состояния службы.

Чтобы получить дополнительную информацию о любой из служб, вы можете использовать + fleetctl + для доступа к информации + systemctl status + и + journalctl -u + хост-системы. Просто введите:

Или прочитайте журнал, набрав:

Это может предоставить некоторую полезную информацию о том, почему ваши службы отказывают. Например, если в вашем модульном файле объявлена ​​недоступная зависимость, это будет показано здесь (это может произойти, если зависимость еще не была загружена в + fleet +).

Одна из ошибок, с которой вы можете столкнуться при вводе некоторых из этих команд:

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

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

Как только ваш ssh-агент получит доступ к вашему секретному ключу, вы должны подключиться к хосту CoreOS с опцией + -A +, чтобы forward эту информацию:

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

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

Как мы уже говорили выше, это легко, когда вы перенаправили свою информацию SSH при подключении. С хоста, к которому вы подключены, вы можете «прыгать» на другие машины, используя + fleetctl +. Вы можете указать идентификатор компьютера или просто имя службы. Процесс + fleetctl + достаточно умен, чтобы знать, на какой хост вы ссылаетесь:

Это даст вам ssh-соединение с хостом, назначенным для запуска этой службы. Служба должна быть в состоянии «загружен» или «запущен», чтобы это работало.

Отсюда у вас будет доступ ко всем локальным средствам устранения неполадок. Например, вы можете получить доступ к более полному набору флагов + journalctl +, который может быть недоступен с помощью команды + fleetctl journal +:

На этом этапе вы можете решить проблемы с Docker. Чтобы увидеть список запущенных контейнеров, введите:

Мы видим, что в данный момент работает один контейнер. Подсвеченный идентификатор контейнера полезен для многих других операций Docker.

Если ваш сервис не запустился, ваш контейнер не будет работать. Чтобы увидеть список всех контейнеров, включая те, которые вышли / не удалось, передайте флаг + -a +:

Чтобы увидеть контейнер last, который был запущен, независимо от его состояния, вы можете использовать вместо этого флаг + -l +:

Когда у вас есть идентификатор контейнера, который вы ищете, вы можете начать расследование на уровне Docker. Во-первых, вы можете просмотреть журналы:

Это даст вам информацию журнала, которую можно собрать из контейнера. Это должно работать независимо от того, запущен контейнер или нет. Если контейнер запускался интерактивно (с флагами + -i + и + -t + и сессией оболочки), весь сеанс будет доступен в журналах.

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

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

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