Centos 7 lxc настройка

Обновлено: 07.07.2024

Проверка параметров LXC/корректность установки LXC

Kernel configuration not found at / proc / config . gz ; searching . . . Kernel configuration found at / boot / config - 3.10.0 - 327.36.2.el7.x86_64 Note : Before booting a new kernel , you can check its configuration usage : CONFIG = / path / to / config / usr / bin / lxc - checkconfig

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

Запск и проверка состояния LXC

● lxc . service - LXC Container Initialization and Autoboot Code Loaded : loaded ( / usr / lib / systemd / system / lxc . service ; disabled ; vendor preset : disabled ) Active : active ( exited ) since Mon 2016 - 10 - 17 22 : 29 : 34 EEST ; 16s ago Process : 1258 ExecStart = / usr / libexec / lxc / lxc - autostart - helper start ( code = exited , status = 0 / SUCCESS ) Process : 1250 ExecStartPre = / usr / libexec / lxc / lxc - devsetup ( code = exited , status = 0 / SUCCESS ) Oct 17 22 : 29 : 04 centos71 . kamaok . org . ua systemd [ 1 ] : Starting LXC Container Initialization and Autoboot Code . . . Oct 17 22 : 29 : 04 centos71 . kamaok . org . ua lxc - devsetup [ 1250 ] : Creating / dev / . lxc Oct 17 22 : 29 : 04 centos71 . kamaok . org . ua lxc - devsetup [ 1250 ] : / dev is devtmpfs Oct 17 22 : 29 : 04 centos71 . kamaok . org . ua lxc - devsetup [ 1250 ] : Creating / dev / . lxc / user Oct 17 22 : 29 : 34 centos71 . kamaok . org . ua lxc - autostart - helper [ 1258 ] : Starting LXC autoboot containers : [ OK ] Oct 17 22 : 29 : 34 centos71 . kamaok . org . ua systemd [ 1 ] : Started LXC Container Initialization and Autoboot Code .

Добавление в автозагрузку LXC

Created symlink from / etc / systemd / system / multi - user . target . wants / lxc . service to / usr / lib / systemd / system / lxc . service .

2. Создание контейнера

Установка Debian8

Checking cache download in / var / cache / lxc / debian / rootfs - jessie - amd64 . . .

Установка Centos7

Также пароль можно изменить командой, если контейнер включен

Настройка сети на ноде и в контейнере для выпуска контейнеров в Интернет

Использование сетевого стека хост-системы (type = veth)
При запуске контейнера с таким типом сети, на хост-машине создается специальный виртуальный интерфейс (в примере ниже, он называется veth-*). Этот виртуальный интерфейс фактически и использует контейнер для взаимодействия с внешней средой.

Я давно хотел посмотреть какую-нибудь систему контейнеризации, отличную от docker, так как очень его не люблю. Решил в итоге остановиться для начала на lxc, познакомиться, рассказать вам, как установить и настроить lxc на CentOS 7. Впечатления у меня от него не однозначные, расскажу обо всем по порядку.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Введение

Сразу предупреждаю, что данная статья это мое знакомство с lxc контейнерами. Я не имею практического опыта работы с ними, поэтому бездумно брать и применять мои рекомендации не стоит.

Не буду много писать о том, что такое контейнеры, чем они отличаются от виртуальных машин, и чем отличаются системы контейнеров (lxc, docker, openvz и др.) друг от друга. Все это можно найти в интернете на сайтах самих продуктов. Расскажу все своими словами.

Главное отличие контейнера от виртуальной машины в том, что он запускается на том же уровне железа, что и хостовый сервер. Нет необходимости в виртуальных устройствах. Контейнер видит исходное железо. Это плюс к производительности. Используется ядро исходной системы и изоляция ресурсов внутри системы.
Контейнер может масштабироваться по ресурсам до целого физического сервера. Например, контейнер может использовать тот же диск и файловую систему, что и хостовая машина. Нет необходимости разбивать диск на кусочки, как с виртуальными машинами и давать каждому по кусочку. В итоге, кто-то может свой диск вообще не использовать, а кому-то не хватит. С контейнерами можно поступить проще - все используют общий диск с хостом. Ограничений для диска как в виртуальной машине тем не менее все равно можно устанавливать. То же самое можно сделать с процессором и памятью.

Я почти не работал с контейнерами, кроме докера. С ним приходится работать только в связке с разработчиками. Для своих целей я его не использую, так как для моих задач он мне кажется неудобным. Не хочется сейчас здесь раскрывать эту тему, может быть в другой раз в статье о докер, если таковая будет. Но в целом докер я не люблю, особенно в продакшене.

Расскажу о том, почему мне захотелось посмотреть на контейнеры вместо виртуальных машин, которые использую повсеместно уже много лет.

Например, у меня есть достаточно мощные VDS серверы от ihor. 2 ядра, 8 гигов, 150Гб диск. Иногда то, что там размещается, не использует полностью ресурсы виртуальной машины. Хочется как-то их занять, но при этом никак не затрагивать основные проекты на виртуальной машине. Иногда хочется какие-то тестовые среды создавать для сайтов и пробовать новые версии софта. Для этого надо отдельную виртуалку брать. Вместо этого я решил попробовать lxc контейнеры.

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

Заказывать каждому контейнеру отдельный внешний IP, настраивать для контейнера bridge на реальном сетевом интерфейсе и выпускать его напрямую в интернет. Этот вариант подходит, если есть ip адреса или не жалко для них денег. Так работать удобнее всего.
Настраивать виртуальный bridge, настраивать NAT и проброс портов с хостовой машины внутрь контейнеров. Не очень удобно, но тем не менее вполне рабочий вариант.

Я расскажу про оба способа, так как проверял и то и другое. Настраивать все будем на CentOS 7.

Если у вас еще нет своего сервера с CentOS 8, то рекомендую мои материалы на эту тему:

Настройка сети для LXC контейнеров

Начнем с настройки сети для контейнеров. Нам понадобится пакет bridge-utils. Установим его:

Настроим виртуальный бридж, который будут использовать только контейнеры внутри своей виртуальной сети - 10.1.1.1/24. Для этого создаем в директории /etc/sysconfig/network-scripts файл ifcfg-virbr0 следующего содержания:

После изменения сетевых настроек лучше перезагрузиться. Проверим, что получилось:

Дальше нам может помочь статья по настройке шлюза на centos, так как часть функционала шлюза нам нужно будет реализовать на хосте. А именно:

Включить маршрутизацию пакетов между сетевыми интерфейсами
Настроить NAT для виртуальной сети контейнера
Настроить проброс портов в контейнеры

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

Теперь основное - настройка iptables. Вообще, она сходу не берется и чаще всего у людей возникают вопросы по работе, если настраивают первый раз. В CentOS 7 по-умолчанию установлен firewalld. Я не использую его и всегда отключаю. Не потому, что он плохой и неудобный, а потому, что привык работать с iptables напрямую, у меня много готовых конфигурация для него.

Устанавливаем службы iptables:

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

Не забудьте поменять имена сетевых интерфейсов и ip адреса. Я не рекомендую настраивать фаервол, если у вас нет доступа к консоли сервера. Так вы можете потерять управление сервером.

Делаем скрипт /etc/iptables.sh исполняемым:

Запускаем iptables и добавляем в автозагрузку:

Выполняем скрипт с правилами:

Проверяем установленные правила:

Проверяем NAT и проброс портов:

Это я разобрал пример, когда у контейнеров своя виртуальная сеть, без прямого доступа во внешнюю. Если же они будут бриджем выходить наружу с прямым ip, то iptables вообще трогать не надо. Достаточно включить маршрутизацию пакетов между интерфейсами, создать bridge и добавить туда реальный интерфейс сервера. Контейнерам подключать этот бридж. Работает так же, как и bridge в proxmox.

Создаем конфиг для нового бриджа:

И приводим конфиг основного сетевого интерфейса к такому виду:

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

virbr0 - виртуальный бридж, который создает виртуальную локальную сеть для контейнеров. Выход во внешнюю сеть они осуществляют с помощью хоста, где настроен NAT и проброс портов с помощью iptables.
virbr1 - бридж, который включает в себя реальный физический интерфейс хоста. С помощью этого бриджа контейнеры получают прямой доступ во внешнюю сеть.

Установка LXC на CentOS 7

Теперь устанавливаем сам lxc:

Проверим готовность системы к работе lxc:

Все должно быть enable, кроме двух строк:

Запускаем lxc и добавляем в автозагрузку:

Все в порядке, lxc сервис установлен и запущен. Переходим к созданию и настройке контейнеров.

Создание и настройка lxc контейнеров

Создадим новый контейнер с названием lxc_centos под управлением системы centos.

После ключа -t указывается название шаблона. Список доступных шаблонов для установки можно посмотреть в /usr/share/lxc/templates/

После установки контейнера, нам нужно указать свой root пароль к нему.

Для этого выполните в консоли команду и укажите новый пароль:

Новый контейнер располагается по адресу /var/lib/lxc/lxc_centos. В этой директории лежит файл config. Приводим его к следующему виду:

Зададим некоторые сетевые настройки в самом контейнере. Добавим dns серверы в /etc/resolv.conf:

Конфиг сетевого интерфейса приводим к следующему виду:

Настройка lxc контейнера завершена. Запускаем его:

Посмотрим состояние контейнера:

Подключаемся к консоли контейнера:

Обращаю внимание на ключ -t 0. Если его не указать, то при подключении к консоли, вы будете пытаться подключиться к tty 1, на котором не будет никакого ответа. Вы увидите на экране:

Ничего сделать больше не сможете, кроме как отключиться, нажав сначала Ctrl+a, затем отдельно q. Обращаю на это внимание, так как не очевидно, как нужно набирать эту комбинацию. Ключом -t мы указываем нулевую консоль и успешно к ней подключаемся. Для возврата к хостовой системе, нужно нажать Ctrl+a, затем отдельно q.

Если после подключения к консоли контейнера вы не видите экрана приветствия, нажмите Enter на клавиатуре.

На этом настройка lxc контейнера с centos 7 закончена. Проверяйте сеть, должно быть все в порядке. Чтобы подключиться по ssh к контейнеру, необходимо подключиться к порту 23543 хоста. При условии, что вы взяли мой пример настройки iptables в самом начале.

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

В данном случае 192.168.13.0/24 - внешняя сеть для хоста. В моем случае это локальная сеть тестового окружения. Если у вас будет реальный ip адрес на бридже, то контейнеру понадобится еще один реальный внешний ip адрес.

Обращаю внимание на очень важный нюанс, который мне стоил нескольких часов разбирательств. Для написания этой статьи я использовал виртуальную машину на hyper-v, у которой единственный сетевой интерфейс был бриджем во внешнюю сеть. Когда я пробрасывал контейнер через этот интерфейс с помощью virbr1, у меня ничего не работало. Контейнер видел только хост и ничего за его пределами. Я многократно проверял настройки, но никак не мог понять, почему не работает.

Оказалось, что по-умолчанию, гипервизор выпускает во внешнюю сеть только те устройства, mac адреса которых он знает. В данном случае это только мак адрес виртуальной машины. Контейнеры же на этой машине имеют другие мак адреса, которые гипервизору неизвестны, и он не выпускал их пакеты во внешнюю сеть. Конкретно в hyper-v такое поведение можно изменить в свойствах сетевого адаптера виртуальной машины:

После этого бридж во внешнюю сеть нормально заработал и контейнеры получили в нее доступ. Такое же поведение будет на виртуальных машинах с proxmox. По-умолчанию, контейнеры не получат доступа во внешнюю сеть. У меня не было под рукой доступа к настройкам гипервизора proxmox на той машине, где я проверил. Не стал подробно разбираться, но имейте ввиду этот момент. C vmware, кстати, будет то же самое. Контейнеры не выйдут во внешнюю сеть.

Дальше пойдет рассказ о проблемах, с которыми я столкнулся в процессе работы с lxc контейнерами.

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

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

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

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

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

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

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

Не работает chronyd

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

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

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

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

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

В целом, вывод по lxc неоднозначный. С одной стороны, вроде все удобно и даже работает. Но с дугой стороны, такие нерешенные проблемы, как зависание контейнеров мне не понятны. Почему оно не заработало из коробки - не ясно. Кроме того, периодически я получал зависания таких команд как lxc-info. Хочешь получить инфу по контейнеру, а в ответ тишина. Просто висит команда в консоли и не выводит ничего. Оставлял на час - без изменений. После перезапуска контейнера показывает нормально. Такие явные ошибки очень настораживают и предостерегают от использования в продакшене.

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

Если у вас есть опыт работы с lxc или какими-то другими контейнерами, но не докером, я с ним сам много работал и в целом знаком, прошу поделиться в комментариях.

Настройка Linux-контейнера с LXC на CentOS 7 / RHEL 7

Контейнеры Linux (LXC) - это легкий метод виртуализации на уровне операционной системы, который позволяет нам запускать несколько изолированных систем (контейнеров) Linux на одном хосте
LXC не предоставляет все функции стандартного программного обеспечения для виртуализации, такого как VMware, VirtualBox и KVM, но предоставляет виртуальную среду с собственным ЦП, памятью, блоками ввода-вывода и сетью
LXC создает среду Linux, максимально приближенную к стандартной установке Linux, но без необходимости отдельного ядра

LXC является свободным программным обеспечением и выпущено под лицензией GNU LGPLv2.1 +
Проект LXC спонсируется компанией Canonical Ltd, которая поддерживает Ubuntu OS

В этом руководстве я покажу вам, как установить LXC и как создавать и управлять LXC с помощью командной строки, а также с помощью веб-портала LXC

Предпосылки

Контейнеры LXC используют мостовую сеть для доступа к / из внешней сети, перед запуском контейнера мы должны создать сетевой мост на CentOS 7 / RHEL 7
Имя сетевого моста должно быть "virbr0":

Установите LXC на CentOS 7

После того, как вы выполнили необходимые условия, пришло время установить LXC

Создание контейнеров Linux

LXC поставляется с готовыми шаблонами для простой установки контейнеров

Чтобы создать контейнер, введите следующую команду:
lxc-create -n centos_lxc -t centos

Где:
-n <имя контейнера>
-t <шаблон>

После того, как вы ввели вышеупомянутую команду, LXC начнет создавать контейнер с именем "centos_lxc"

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

Учетные данные контейнеров

Чтобы войти в контейнер (centos_lxc), используйте временный пароль root, который хранится в следующем месте
В нашем случае "Root-centos_lxc-xK2VSL" является корневым паролем centos_lxc

или же:

Запуск Linux-контейнеров

Теперь возьмите консоль контейнера, используя следующую команду:

Введите имя пользователя и пароль для входа в систему
Учетные данные можно найти в конце вывода при создании контейнера
Вы должны изменить пароль root при первом входе в систему

После входа в систему вы можете выполнять всю работу в этом контейнере, как на обычном сервере Linux

Чтобы выйти из консоли контейнера, нажмите "Ctrl + a", а затем "q". Теперь вы вернетесь обратно в терминал хост-компьютера

Работа с контейнерами Linux

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

Приведенная выше команда предоставляет вам подробную информацию (имя, состояние, IP-адрес, процессор, память, ввод-вывод и использование сети) контейнера "centos_lxc"

Вы также можете использовать IP-адрес для подключения к контейнерам вместо консоли LXC

Клонирование контейнеров Linux

Клонирование контейнера из существующего контейнера

Запустите следующую команду, чтобы клонировать существующий контейнер centos_lxc в новый контейнер centos_lxc_clone:

Снимок

Используйте следующие команды:

В Centos 7 снимки LXC хранятся в "/var/lib/lxcsnaps/"

Восстановление снимка

Удаление контейнеров

Запуск контейнера Ubuntu в CentOS 7

Я столкнулся с множеством проблем, когда пытался запустить контейнер Ubuntu на CentOS, смог запустить Ubuntu с помощью некоторых настроек, опубликованных на других сайтах

Запустите следующую команду, чтобы заменить зеркало Debian на зеркало ubuntu:

Получите точный набор ключей Ubuntu и поместите его в каталог ключей:

Спасибо: blog.toxa.de

Из приведенного выше вывода видно, что пользователь по умолчанию - "ubuntu", а пароль для пользователя - "ubuntu"

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

В этой статье мы поговорим об использовании LXC в системах Oracle Linux, CentOS, RHEL 6.X/7.X (RHEL-based), с использованием кастомного ядра Oracle: Unbreakable Enterprise Kernel (UEK) 4, в режиме bridge (через мост, контейнеры будут иметь прямой выход наружу по внешнему адресу).

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

1. Подключаем rpm-репозитории Oracle

Необходимо, для установки всего софта и его обновлений:

Далее проверяем и обновляемся:

2. Установка специального ядра Oracle UEK4 (Unbreakable Enterprise Kernel)

Ставим нашу крутое ядро:

После чего несколько модификаций, чтобы оно грузилось по дефолту (только для 6.X ОС CentOS и RHEL, для Oracle Linux не нужно):

А для (только для 7.X ОС CentOS и RHEL, для Oracle Linux не нужно) чуть по другому, из-за более современной версии grub (выбрать нужны номер):

После чего перезагрузка:

3. Установка необходимых утилит

Ставим утилиты, которые активируют соответствующие функции в ядре:

4. Настройка моста

После чего следует перезагрузится:

5. Проверка мостов и подготовка LXC к работе

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

Смонтируем что надо для LXC:

6. Работа с LXC

Общий список всех контейнеров:

Склонировать контейнер С1, новый контейнер назвать С2:

Запустить контейнер С1:

Запустить контейнер С1, не входя в него:

Остановить контейнер С1:

Удалить контейнер С1:

Зайти в консоль контейнера С1:

Поставить контейнер С1 на паузу:

Восстановить контейнер С1 из паузы:

Информация по контейнеру:

7. Эталонный контейнер

Создадим его и поправим соответствующий конфиг (в репозиториях Oracle Linux лежит версия 1.1.5, вместо обычной 1.0.8, и у нее путь нахождения контейнеров лежит тут /container/..):

Вот и он (обратите внимание, IP надо указывать в формате CIDR, сеть класса B):

После чего включить контейнер, он сразу заработает и будет доступен по своему IP:

8. Экспорт-импорт контейнеров

..архив будет лежать в /root, после чего копируем его на ноду2 (тоже в /root, любым удобным способом) и там распаковываем его.. правим конфиг если нужно. Все, можно сразу включать:

Вуаля! Все просто и понятно. (sic! DNS на новом сервере надо прописать вручную, можно напрямую с главной системы /container/С1/rootfs/etc/resolv.conf или /etc/resolv.conf с самого контейнера).

Выводы

Собственно это и все. В дальнейшем, мы можем понарезать клонов с эталонного контейнера, сколько душе влезет.. как колбасу. Достаточно только назначить ип IP, шлюз и сразу вперед. Очень удобно и практично. Отличие данной статьи от моей самой первой (по LXC) состоит в том, что там использовался NAT и проброшены порты одного конкретного приложения. Здесь иначе, напрямую. И так удобнее, ИМХО. Более того, работа с таким базовым инструментарием на столь низком уровне (без веб-интерфейсов и прочего), дает нам максимальную гибкость в реализации любых проектов, а также высокий уровень понимания всего происходящего на сервере.

Всем удачного полета!.)

Использование LXC (без libvirt) через bridge на Oracle Linux, CentOS, RHEL 6.X/7.X : Один комментарий

Отличная статья. Настроил сеть, как здесь написано, только на OEL6 и с bond0 вместо eth0. Спасибо!

Читайте также: