Полная инструкция по настройке гипервизора контейнеров LXD в LTS версии 18.04 Ubuntu или Ubuntu server


Администрирование операционных систем на базе Linux (Debian/Ubuntu и Centos/RedHat) Виртуализация серверов и рабочих станций в Windows и Linux - Hiperv, KVM, VMWare
bridge firewall hardware linux lts lxd openvpn server ubuntu виртуальный сервер изоляция контейнер
 
 

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


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

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

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

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

Установку мы будем производить на стабильную LTS-ветку Ubuntu Server 18.04 и чтобы не вдаваться в детали установки дистрибутива Ubuntu Server 18.04 LTS, я подготовил небольшое видео.

После того как мы авторизовались по SSH на свежеустановленном сервере, мы задаем пароль root и разрешаем доступ пользователю root по SSH, для чего в файле /etc/ssh/sshd_config раскомментируйте и измените строку:

PermitRootLogin yes

Следующим этапом, мы авторизовываемся на сервере пользователем root, удаляем пользователя administrator и обновляем ПО. Можно конечно и оставить пользователя administrator и использовать sudo, но я считаю, что на хосте гипервизора это излишество.

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

# userdel administrator
# rm -R /home/administrator/
# apt-get update
# apt-get upgrade

В Ubuntu Server 18.04 по умолчанию отключен репозиторий Universe и ряд полезного ПО вам будет недоступно и я конечно же рекомендую его подключить и установить любимый mc:

# add-apt-repository universe
# apt-get install mc aptitude curl

Подготовка сетевой инфраструктуры

Так как мы подготавливаем серверную конфигурацию, то нам в обязательном порядке надо настроить сетевую подсистему и в моем случае все это сводится к следующим этапам:

  • Разрешить маршрутизацию
  • Настроить сетевой интерфейс (статика или DHCP)
  • Настроить один интерфейс в качестве сетевого моста с OpenVPN (если мы объединяем LXD-сервера)
  • Второй сетевой интерфейс настраиваем мостом к локальной сети

Схематически мы должны получить следующую конфигурацию:

Схема организации виртуальной сети для фермы LXD

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

Нам понадобится установить пакет поддержки сетевых мостов:

# aptitude install bridge-utils

В Ubuntu 18.04 используется новый механизм инициализации сетевых интерфейсов который мне не нравится и я предпочитаю вернуть все как было:

# aptitude install ifupdown

Включаем поддержку маршрутизации IPv4 в ядре Linux для чего в файле /etc/sysctl.conf расскомментирйте строку:

net.ipv4.ip_forward=1

Устанавливаем fail2ban и создаем типовой файл конфигурации firewall в каталоге /etc/firewall/:

# mkdir /etc/firewall
# aptitude install fail2ban
# touch /etc/firewall/firewall.sh
# chmod +x /etc/firewall/firewall.sh

Содержимое файла /etc/firewall/firewall.sh:

#!/bin/sh

IPT="/sbin/iptables"
PUBLIC_INTERFACE="local-bridge"
VPN_INTERFACE="master-bridge"

# Clean all tables
# Set default rules
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X

# All Drop by Design
$IPT -P OUTPUT ACCEPT
$IPT -P INPUT DROP
$IPT -P FORWARD DROP

# Allow localnetwork
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A FORWARD -o lo -j ACCEPT

# Curent connections
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Enable SSH from External Interface
$IPT -A INPUT -i $PUBLIC_INTERFACE  -p tcp --dport 22 -j ACCEPT

# Enable any traffic on VPN Interface
$IPT -A INPUT -i $VPN_INTERFACE  -j ACCEPT

# Route to Internet form VPN
$IPT -A FORWARD -s 10.211.0.0/16  -j ACCEPT
$IPT -A FORWARD -d 10.211.0.0/16  -j ACCEPT
$IPT -t nat -A POSTROUTING -s 10.211.0.0/16 -o $PUBLIC_INTERFACE -j MASQUERADE

/etc/init.d/fail2ban restart

В этом случае у нас получается, что:

  • local-bridge - сетевой мост в локальную сеть
  • master-bridge - сетевой мост в VPN-сеть
  • 10.211.0.0/16 - диапазон адресов VPN-сети

И наконец собственно файл описания всех наших сетевых интерфейсов:

auto local-bridge
iface local-bridge inet dhcp
    bridge_ports enp3s0
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    post-up /etc/firewall/firewall.sh

auto master-bridge
iface master-bridge inet static
    address 10.211.1.1
    netmask 255.255.0.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    post-up /etc/firewall/firewall.sh

Подключение VPN-сети без назначения IP-адресации на интерфейсах (схема с мостами), я уже описывал с статье "OpenVPN-сеть для LXD-кластера без назначения адресов клиентов" и в этом решении я использовал именно их.

Устанавливаем окружение LXC/LXD

Если вы читали предыдущие статьи, то вы наверное помните огромную инструкцию (и скрипт) сборки окружения LXC/LXD из исходных кодов, так вот все эти инструкции сводятся к одной команде:

# aptitude install lxc lxd criu

Но есть и обратная сторона медали, а именно при сборке из исходных кодов вы получаете версию 3.5 LXC/LXD:

# lxc --version
3.5
# lxd --version
3.5
# criu --version
Version: 3.10
GitID: v3.10-1-g380df8a

При установке из репозитория вы получите версию 3.0.2:

# lxc --version
3.0.2
# lxd --version
3.0.2
# criu --version
Version: 3.6

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

Запуск стабильной версии LXD-хоста

Для инициализации базового окружения используется команда:

# lxd init

В результате выполнения этой команды будет запущен мастер базовой настройки:

Would you like to use LXD clustering? (yes/no) [default=no]: no
Do you want to configure a new storage pool? (yes/no) [default=yes]: yes
Name of the new storage pool [default=default]: default
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: dir
Would you like to connect to a MAAS server? (yes/no) [default=no]: no
Would you like to create a new local network bridge? (yes/no) [default=yes]: no
Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: no
Would you like LXD to be available over the network? (yes/no) [default=no]: yes
Address to bind LXD to (not including port) [default=all]:
Port to bind LXD to [default=8443]:
Trust password for new clients:
Again:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] no
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: no

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

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

# lxc profile list
+---------+---------+
|  NAME   | USED BY |
+---------+---------+
| default | 0       |
+---------+---------+

Профилю по умолчанию мы назначаем сетевой мост master-bridge:

# lxc network attach-profile master-bridge default eth0

Создаем тестовый контейнер:

# lxc init ubuntu:16.04 test-ubuntu-lxd

Запускаем тестовый контейнер:

# lxc start test-ubuntu-lxd

Переходим внутрь контейнера:

# lxc exec test-ubuntu-lxd /bin/bash

Для теста назначим статический адрес на интерфейсе внутри контейнера (у меня нет DHCP-сервера в виртуальной сети) и проверим, что контейнер доступен из любой части распределенной VPN-сети:

# ifconfig eth0 10.211.1.25/16
# route add default gw 10.211.1.1

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

# lxc profile copy default default-localnet

Удаляю сетевой интерфейс и добавляю локальный:

# lxc profile device remove default-localnet eth0
# lxc network attach-profile local-bridge default-localnet eth

Инициализация контейнера с профилем отличным от стандартного немного отличается от простой команды описанной выше и выглядит следующим образом:

# lxc -p default-localnet init ubuntu:16.04 test-ubuntu-lxd

Запрашиваем список профилей и проверяем, что контейнер назначен нужному профилю:

# lxc profile list
+------------------+---------+
|       NAME       | USED BY |
+------------------+---------+
| default          | 0       |
+------------------+---------+
| default-localnet | 1       |
+------------------+---------+

И как я уже говорил, в локальной сети присутствует DHCP-сервер и контейнер получил сетевой адрес автоматически:

# lxc start test-ubuntu-lxd
# lxc list test-ubuntu-lxd
+-----------------+---------+------------------+------+------------+-----------+
|      NAME       |  STATE  |       IPV4       | IPV6 |    TYPE    | SNAPSHOTS |
+-----------------+---------+------------------+------+------------+-----------+
| test-ubuntu-lxd | RUNNING | 10.1.1.88 (eth0) |      | PERSISTENT | 0         |
+-----------------+---------+------------------+------+------------+-----------+

Основные команды используемые для администрирования LXD-хоста

Инициализируем контейнер:

# lxc init ubuntu:16.04 test-ubuntu-lxd

Устанавливаем MAC-адрес интерфейсу контейнера:

# lxc config set v33-machine volatile.eth0.hwaddr 00:16:3e:6d:12:ee

Отключение автозапуска контейнера:

# lxc config set mail-server boot.autostart 0

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

# lxc profile set default boot.autostart 0

Удаляем eth0 из конфигурации по умолчанию:

# lxc profile device remove default eth0

Назначаем новую ассоциацию с мостом по умолчанию:

# lxc network attach-profile lxd-cluster-01 default eth0

Миграция контейнеров между хостами LXD

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

На обоих хостах (источнике и приемнике) разрешаем удаленное управление LXD-гипервизором и назначаем мастер-пароль:

# lxc config set core.trust_password SecretMasterPassword
# lxc config set core.https_address 0.0.0.0:8443

Разрешаем управление удаленным LXD-гипервизором с хоста на который мы хотим скопировать контейнер:

# lxc remote add test-migration 10.1.1.105

Вам потребуется ввести пароль который вы задали предыдущими командами:

Certificate fingerprint: 72ceb5aba8647347cc45636a455d9f185f7d6bc3a6
ok (y/n)? y
Admin password for test-migration:
Client certificate stored at server:  test-migration

Запрашиваем список доступных удаленных серверов:

# lxc remote list
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
|      NAME       |                   URL                    |   PROTOCOL    | AUTH TYPE | PUBLIC | STATIC |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| images          | https://images.linuxcontainers.org       | simplestreams |           | YES    | NO     |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| local (default) | unix://                                  | lxd           | tls       | NO     | YES    |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| test-migration  | https://10.1.1.105:8443                  | lxd           | tls       | NO     | NO     |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | simplestreams |           | YES    | YES    |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | simplestreams |           | YES    | YES    |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+

Запрашиваем спиок контейнеров на удаленном сервере:

# lxc list test-migration:
+------------------------+---------+--------------------+------+------------+-----------+
|          NAME          |  STATE  |        IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+------------------------+---------+--------------------+------+------------+-----------+
| gitlab-server          | RUNNING | 10.211.0.12 (eth0) |      | PERSISTENT | 0         |
+------------------------+---------+--------------------+------+------------+-----------+
| site-service-functions | RUNNING | 10.211.0.14 (eth0) |      | PERSISTENT | 0         |
+------------------------+---------+--------------------+------+------------+-----------+

Копируем отключенный контейнер:

# lxc copy test-migration:gitlab-server gitlab-server

Перемещаем контейнер без его остановки (живая миграция):

# lxc move --stateless test-migration:test-ubuntu-lxd test-ubuntu-lxd
Моя официальная страница на FaceBook
Мой микроблог в твиттер

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

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

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


Управление дисковыми хранилищами 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 я уже писал, но сегодня я хотел предложить вашему вниманию набор скриптов которые я использую для построения узла фермы контейнерной виртуализации.


WEB-интерфейс управления узлом виртуализации LXD

WEB-интерфейс управления узлом виртуализации LXD

Я уже неоднократно рассказывал о настройке системы контейнерной изоляции LXD и управлении фермой LXD гипервизоров из консоли, но как верно подметили мои читатели все же хотелось бы иметь удобный графический интерфейс для управления LXD-сервером. Честно говоря какого-то официального web-интерфейса для LXD я не нашел и мне пришлось пробовать все проекты с github.


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


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

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