Статья 10 из 10, в которой речь пойдёт об отладочных приёмах и поисках проблем.
Журналирование.
У большинства LXC команд есть два параметра:
- -o, --logfile=FILE: указать файл журнала (по дефолту stder)
- -l, --logpriority=LEVEL: приоритет журнала (умолчание соответствует ERROR)
Правильное значение LEVEL может указывать только на:
- FATAL
- ALERT
- CRIT
- ERROR
- WARN
- NOTICE
- INFO
- DEBUG
- TRACE
Если нужно увидеть все записи, то нужно указать TRACE.
Есть два параметра в конфигурации, которые можно использовать в конфигурации каждого контейнера.
- lxc.logfile
- lxc.loglevel
Стоит помнить, что если в параметрах командной строки используются -o или -l, то они перекрывают значения в конфиге контейнера. Если хочется отправить отчёт об ошибке LXC, то хорошей идей будет приложить журнал работы с контейнером с --logpriority=DEBUG.
Отладка API.
Когда отлаживается код, использующий API LXC, то хорошей практикой является переписывания проблемного кода на C, использующий liblxc напрямую. Это поможет исключить проблему с биндингами (binding) и получить более чистую трассировку стека (stack traces) и упростить отчёт об ошибке.
Так же полезно выставить lxc.loglevel=DEBUG через set_config_item и увидеть, что происходит не правильно.
Тестирование.
До погружения в глубины отладки вашего кода, желательно проверить работу LXC на вашей машине. Стоит запустить lxc-checkconfig для проверки и понять: а что ваше ядро поддерживает из возможностей LXC? Если всё хорошо и вывод lxc-checkconfig обнадёживает, то можно перейти к тестам. Вам нужно скомпилировать и установить их, если вы ставили LXC из исходников. В Убунту есть пакет lxc-tests, который можно установить и получить весь набор тестов. Большинство тестов исходит из предположения, что у вас установлена Ubuntu, но другие дистрибутивы линукс должны работать с тестами нормально. Если это не так, то шлите патчи.
Запускайте от root'а тесты lxc-test-* и обращайте внимание на неисправности. К сожалению, тест может оставить после себя хлам, который сам по себе может помешать следующему тесту. Поэтому нужно внимание человека и подчищайте после тестов.
Сообщение об ошибке.
Основной баг трекер LXC - https://github.com/lxc/lxc/issues
Отчёт об ошибке можно подать в рамках вашего дистрибутива или в upstream или туда и туда и связать их.
Для Ubuntu баг трекер находится по адресу https://bugs.launchpad.net/ubuntu/+source/lxc
Если вы проделали определённую работу по созданию отчёта, то можно обратиться к разработчикам в их почтовой рассылке, которые найдёте чуть ниже.
Отправка патча.
Разработчики LXC рады любому вкладу и счастливы сообщить, что насчитывают активных разработчиков около 60 человек, которые способствовали выходу LXC 1.0. Есть не так много правил, регулирующих вклад в работу. Требуется лишь указание лицензии, под которой вы публикуете патч, и что вы являетесь владельцем авторских прав на ваш код.
Что касается лицензирования, то всё что попадает в liblxc или в биндинги должно быть под лицензией LGPLv2.1+ или совместимой с ней, не налагая дополнительные ограничения. Бинарники и скрипты могут быть под лицензией LGLPv2.1+ или GPLv2. Если есть какие-либо сомнения, то выбор LGPLv2.1+ будет идеален.
Патчи можно отправить двумя способами:
- Отправив по почте lxc-devel@lists.linuxcontainers.org, например через git send-email
- Сделав pull request в github проекта.
Контакты.
Основной способ общения у разработчиков LXC - это почтовые рассылки. Их две.
Одна для вопросов от разработчиков и одна для пользователей:
- lxc-devel: https://lists.linuxcontainers.org/listinfo/lxc-devel
- lxc-users: https://lists.linuxcontainers.org/listinfo/lxc-users
Для более динамичного и живого общения есть канал IRC #lxcontainers на irc.freenode.net.
Последние замечания.
Цикл из 10 статей закончился до финального выхода LXC 1.0. Сейчас проект переходит из rc3 в rc4 и выход релиза стоит ожидать 20 февраля вечером или 21 февраля утром.
Данный цикл статей от Стефана Грабера может стать полезным справочным материалом для людей, осваивающих LXC 1.0.
Предыдущая статья LXC 1.0: GUI в контейнере.
Добавляя от себя пять копеек, хочется рассказать о свои граблях. Технология LXC для доступа виртуальных машин использует bridge lxcbr0. Я использовал bind9 вместо дефолтного dnsmasq, который используется в LXC для работы с DNS и DHCP. Пришлось вернуться к дефолтному dnsmasq. Заодно пришлось сменить дефолтное использование подсети 10.0.3.x, так как у меня есть такая работающая подсеть.
Следует знать, что система Docker использует под капотом систему виртуализации на уровне операционной системы LXC, поэтому изучение LXC поможет лучше понять, что делает Докер.
Инструмент оркестровки Juju умеет работать не только с облачными образами, но и с "локальным" LXC. Благодаря этому факту, можно поиграть в облачного админа, используя LXC. Лично я хочу посветить этому вопросу время и написать в будущем статью об успехах или неудачах на этом поле.
Кстати, Unity Greeter умеет входить не только в локальную систему, но и в удалённые облачные инстансы, а так же в локальные контейнеры LXC. То есть при старте вашей системы, можно залогиниться в операционную систему контейнера. Всё это так же планирую попробовать в живую и предоставить вам результаты.
На этом пока всё! Удачи и успехов!
Дополнительные материалы:
Серия статей LXC 1.0. от Стефана Грабера.
Что такое Juju?
Победа Ubuntu Juju.
Ubuntu. Вход в облака.
Немає коментарів:
Дописати коментар