Сборка гипервизора контейнеров LXC (LXD) из исходных кодов и настройка окружения разработчика


Виртуализация серверов и рабочих станций в Windows и Linux - Hiperv, KVM, VMWare Мое портфолио, сертификаты и разработки
aptitude compile linux lxc lxd ubuntu контейнер
 
 

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


(последние правки 5 дней, 19 часов)

Данная статья родилась в процессе работ над проектом по тестировнию функционала горячей миграции контейнеров LXC. Мы провели сборку LXD из git-репозитария и описали шаги для повторения этих манипипуляций в дальнейшем. Дополнительно мы подготовили инструкцию по созданию окружения для наших разработчиков.

Сегодня мы будем собирать из исходных кодов и подготавливать к работе два проекта опубликованные на GIT-HUB. Первый проект - это гипервизор контейнеров LXC (LXD), а второй, в свою очередь, - это проект для сохранения текущего состояния процессов (CRIU), который используется для бесшовной (живой миграции) контейнеров виртуальных машин.

Сборка проектов из исходных кодов

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

# aptitude install acl dnsmasq-base git golang libacl1-dev make pkg-config rsync \
  squashfs-tools tar xz-utils lvm2 thin-provisioning-tools btrfs-tools curl gettext\
  jq sqlite3 uuid-runtime bzr m4 automake autoconf
# aptitude install protobuf-c-compiler libnet1-dev libaio-dev asciidoc libcap-dev \
  libnl-3-dev python-protobuf golang-gogoprotobuf-dev libprotobuf-dev apparmor-utils \
  libcgmanager-dev libseccomp-dev docbook libtool

Скачиваем исходные коды master-веток LXD (в случае если мы хотим протестировать новый функционал или проверить на практике внесенные разработчиками правки):

# cd /usr/src
# git clone https://github.com/lxc/lxc.git
# cd ./lxc/
# libtoolize --force
# aclocal && autoheader
# automake --force-missing --add-missing
# autoconf
# ./autogen.sh
# ./configure
# make && make install
# cd ..
# git clone --recursive https://github.com/lxc/lxd.git
# cd ./lxd/
# mkdir -p ~/go
# export GOPATH=~/go
# cd ./lxd/
# make
# cd $GOPATH/src/github.com/lxc/lxd
# make

Процесс сборки LXC-достаточно типовой и мы собираем стандартное C++ приложение при помощи autoconf и make, а вот LXD (гипервизор) уже представляет собой специфичное и новое для меня приложение на GO, но и оно, как оказалось, собирается достаточно просто и вам остается лишь следовать представленной выше последовательности команд. Для Production - применений я бы рекомендовал использовать стабильную ветку репозитория, а не собирать нестабильный проект.

Проект LXC собран в каталог /usr/local/ и поэтому вам необходимо добавить путь /usr/local/lib/ в файл /etc/ld.so.conf и выполнить команду:

# ldconfig

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

# cd /usr/src/
# git clone https://github.com/checkpoint-restore/criu.git
# cd criu/
# make && make install
					  

Если сборка LXD прошла успешно, то вы увидите в консоли сообщение:

LXD built successfully

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

# echo "root:1000000:65536" | sudo tee -a /etc/subuid /etc/subgid
# sudo -E $GOPATH/bin/lxd --group sudo

Если при тестовом запуске вы получили ошибку:

WARN[11-22|11:11:01] CGroup memory swap accounting is disabled, swap limits will be ignored.

то возможным путем решения этой проблемы может быть установка пакета cgroup-lite:

# aptitude install cgroup-lite

и дополнительно необходимо добавить к параметрам загрузки ядра опцию swapaccount=1, для чего в файле /etc/default/grub добавьте этот параметр к строке:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash swapaccount=1"

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

# update-grub

Такого рода изменения применятся только после перезагрузки сервера, вы можете перезагрузить сервер сейчас или чуть позже на этапе тестирования SystemD - сервиса для автоматического запуска LXD на этапе загрузки сервера.

Как вы поняли, бинарные файлы демона LXD после сборки оказались в каталоге /root/go/bin/ и у нас есть два варианта как предоставить удобный доступ к бинарным файлам собранного проекта. Первый - это скопировать полученные бинарные файлы в /usr/local/bin/, а второй - это создать символические ссылки в каталог /usr/local/bin/. Я предпочитаю второй вариант, так как я занимаюсь тестированием этого проекта и периодически пересобираю для тестирования исправлений на мои баг-репорты:

# ln -s /root/go/bin/deps /usr/local/bin/deps
# ln -s /root/go/bin/fuidshift /usr/local/bin/fuidshift
# ln -s /root/go/bin/lxc /usr/local/bin/lxc
# ln -s /root/go/bin/lxd /usr/local/bin/lxd
# ln -s /root/go/bin/lxd-benchmark /usr/local/bin/lxd-benchmark
# ln -s /root/go/bin/macaroon-identity /usr/local/bin/macaroon-identity

Переходим к написанию SystemD - юнита, который будет запускать гипервизор контейнеров LXD при старте сервера. В простейшем виде юнит выглядит следующим образом:

[Unit]
Description=LXD - main daemon
After=network.target
Requires=network-online.target
Documentation=man:lxd(1)

[Service]
EnvironmentFile=-/etc/environment
ExecStart=/usr/local/bin/lxd --group sudo --logfile=/var/log/lxd.log
KillMode=process
TimeoutStartSec=600
TimeoutStopSec=40
Restart=on-failure
LimitNOFILE=1048576
LimitNPROC=infinity
TasksMax=infinity

[Install]
WantedBy=multi-user.target

И находится в файле /lib/systemd/system/lxd.service. Для настройки автозапуска сервиса при старте сервера выполните команду:

# systemctl enable lxd

Перезагрузите сервер и удостоверьтесь, что демон LXD запустился корректно:

# systemctl status lxd

После чего можно приступать к конфигурированию окружения разработчика.

Настройка окружения разработчика

В своей статье "Расширяем возможности контейнерной виртуализации LXC при помощи гипервизора для контейнеров LXD-гипервизор для контейнеров" я начал рассказывать про основы управления гипервизором контейнеров LXD. Но тогда я использовал штатный пакет из дистрибутива Ubuntu и, в этом случае, все предварительные настройки уже были предопределены и, в некотором роде это удобно, но не дает такой гибкости как настройка системы контейнерной изоляции с нуля.

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

$ lxc init ubuntu:16.04 test-ubuntu-lxd

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

$ lxd init

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

$ lxd init
Do you want to configure a new storage pool (yes/no) [default=yes]? 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (dir, btrfs, lvm) [default=btrfs]: 
Create a new BTRFS pool (yes/no) [default=yes]? 
Would you like to use an existing block device (yes/no) [default=no]? 
Size in GB of the new loop device (1GB minimum) [default=100GB]: 
Would you like LXD to be available over the network (yes/no) [default=no]? 
Would you like stale cached images to be updated automatically (yes/no) [default=yes]? 
Would you like to create a new network bridge (yes/no) [default=yes]? no
LXD has been successfully configured.

Из нетиповых решений, я использую хранилище на базе btrfs (для работы со снапшотами и живой миграции) и дополнительно я отказался от создания сетевого моста, так как интерфейс сетевого моста у меня уже есть и он подключен к внутренней сети help-me-24.com (про детали реализации нашей сети разработки и тестирования я уже писал).

Первое, что требуется сделать, это проверить что наш default-пул создан мастером настройки:

# lxc storage list
+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| default |             | btrfs  | /var/lib/lxd/disks/default.img | 1       |
+---------+-------------+--------+--------------------------------+---------+

Повторяем команду, которую мы пытались выполнить изначально (теперь она отработает корректно):

# lxc init ubuntu:16.04 test-ubuntu-lxd
Создание test-ubuntu-lxd
                                            
The container you are starting doesn't have any network attached to it.
  To create a new network, use: lxc network create
  To attach a network to a container, use: lxc network attach

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

# lxc list
+-----------------+---------+------+------+------------+-----------+
|      NAME       |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+-----------------+---------+------+------+------------+-----------+
| test-ubuntu-lxd | STOPPED |      |      | PERSISTENT | 0         |
+-----------------+---------+------+------+------------+-----------+

Контейнер мы можем запустить, но без привязки к сетевой инфраструктуре он нас не сильно интересует и нам необходимо настроить доступ к внутренней сети проекта help-me-24.com. Во-первых, мы можем настроить сетевой интерфейс для отдельно взятого контейнера:

# lxc network attach hm24-internal test-ubuntu-lxd eth0

Разберем параметры этой операции:

  • hm24-internal - имя сетевого моста
  • test-ubuntu-lxd - имя контейнера
  • eth0 - имя сетевого интерфейса внутри контейнера

Во-вторых, настроим сетевой интерфейс по умолчанию для создаваемых контейнеров:

# lxc network attach-profile hm24-internal default eth0

Запускаем контейнер и подключаемся к его консоли при помощи последовательности команд:

# lxc start test-ubuntu-lxd
# lxc console test-ubuntu-lxd

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

Моя официальная страница на FaceBook
Мой микроблог в твиттер

Управление дисковыми хранилищами LXD из консоли

Управление дисковыми хранилищами LXD из консоли

В предыдущей статье про базовую настройку окружения разработчика мы получили много вопросов по поводу управления дисковыми пулами и по результатам обсуждения статьи мы подготовили небольшую статью HOW-TO по управлению виртуальными дисками (и хранилищами) системы контейнерной изоляции LXD.


Скрипт и поясняющее видео сборки гипервизора контейнеров LXD из исходных кодов (мастер-ветка)

Скрипт и поясняющее видео сборки гипервизора контейнеров LXD из исходных кодов (мастер-ветка)

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


OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

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


Набор скриптов для управления LXD-фермой

Набор скриптов для управления LXD-фермой

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


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


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .