Установка и настройка lxc контейнеров на centos 7

Работа с кластером

Создание кластера

pvecm create YOUR-CLUSTER-NAME
pvecm status
pmxcfs -l

Заставить сервер работать в single mode (вне кластера)

pvecm e 1

При повторном добавлении ноды:

pvecm add  proxmox-01 -force

/usr/share/doc/corosync/examples/corosync.conf.example.udpu

transport: udpu

Добавить ноду (выполнить на ноде):

pvecm add IP-ADDRESS-CLUSTER

Обновить сертификаты (pveproxy /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 1626)

pvecm updatecerts

/etc/udev/rules.d/80-net-setup-link.rules

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="38:d5:47:c9:10:d7", NAME="net10"

Настройки сети на гипервизоре

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

Включаем , для этого в конец файла на выделенном сервере добавляем строку:

Применяем конфигурацию (вводим в консоли команду):

Теперь добавим маршрут для виртуальной машины:

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

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

На этом всё, ваша виртуальная машина должна быть доступна в сети. Если же вы решили использовать VMmanager 6 для создания и работы с виртуальными машинами, то про настройку сети в VPU также можете прочитать в нашей статье — настройка сети в VMmanager 6 на выделенных серверах с VPU.

Алексей Гарин, системный администратор

Проблемы и ошибки

Не устанавливается httpd

Сразу скажу, что в качестве хостовой системы и шаблонов для lxc контейнеров я использовал только centos. Возможно в других системах указанных мной ошибок не будет. Первое с чем сразу же столкнулся было невозможность установить пакет httpd. Была вот такая ошибка:

# yum install httpd
Running transaction
  Installing : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 
Error unpacking rpm package httpd-2.4.6-67.el7.centos.6.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;5a8adbd2: cpio: cap_set_file
  Verifying  : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 

Failed:
  httpd.x86_64 0:2.4.6-67.el7.centos.6                                                                                                                       

Complete!

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

Суть ошибки в том, что существуют некие ограничения ядра для работы file capabilities. Я не вникал подробно в эти file capabilities, не понимаю до конца сути ошибки, только поверхностно. Подробно ошибка разобрана тут — https://github.com/lxc/lxd/issues/1245. Так как решением проблемы предлагается перевести контейнер в privileged режим, когда хостовый рут и контейнерный имеют одинаковые системные id, то примерно понятно, в чем суть ошибки.

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

# chroot /var/lib/lxc/lxc_centos/rootfs
# yum install httpd

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

Зависает контейнер и нагружает cpu хоста

Следующая неприятная ошибка, с которой столкнулся сразу же после начала тестирования lxc контейнеров. Контейнер через несколько минут после запуска зависал. Я не мог его ни остановить, ни удалить. При этом на самом хосте процесс /usr/lib/systemd/systemd-journald на 100% нагружал одно ядро cpu.

Решение проблемы следующее. Добавляем в конфиг контейнера параметр:

lxc.kmsg = 0

Перезапускаем контейнер. Заходим в него и удаляем /dev/kmsg (именно в контейнере, не на хосте!!!)

# rm -f /dev/kmsg

После этого контейнеры стали работать стабильно и перестали зависать. Я установил bitrix-env и развернул сайт. Все заработало без проблем с нормальной скоростью.

Не работает chronyd

После установки и запуска chronyd в lxc контейнере с centos 7 получаем ошибку:

ConditionCapability=CAP_SYS_TIME was not met

Тут я уже немного утомился ковыряться в ошибках lxc и понял, что не хочу использовать в работе эти контейнеры. Но все же собрался с силами и погуглил еще немного. Как оказалось, это не ошибка, это ограничение работы в контейнере. Условием работы chronyd является доступ к системному вызову adjtimex(). У контейнера в не privileged режиме нет этого доступа, поэтому он и не запускается.

Контролирует эту ситуацию параметр

ConditionCapability=CAP_SYS_TIME

в конфиге systemd службы chronyd в контейнере — /etc/systemd/system/multi-user.target.wants/chronyd.service. Если убрать этот параметр и запустить службу, получим ошибку:

adjtimex(0x8001) failed : Operation not permitted

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

Рейтинг
( 1 оценка, среднее 5 из 5 )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock
detector