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

Установка и настройка Squid на CentOS 7

В этой статье я опишу процесс установки SQUID на CentOS 7. Для тех, кто не знает, SQUID — это прокси сервер, работающий под OS Linux всех модификаций. В основном SQUID используют для раздачи интернета внутри локальной сети, но можно его еще использовать, как внешний прокси сервер.

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

Устанавливаем прокси-сервер следующей командой:

Все настройки происходят через конфигурационный файл squid.conf, вот его открываем на редактирование:

По умолчанию доступ разрешен для всех стандартных локальных сетей, директива за это отвечает acl localnet src, вот ее и редактируем для ограничения доступа:

acl localnet src 192.168.1.0/24

Если хотим разрешить доступ всем сетям, то пишем:

acl all src 0.0.0.0/0.0.0.0

Чтобы разрешить весь трафик, добавляем следующую строчку:

важно, чтобы она была выше запрещающей — http_access deny all

Настраиваем директорию для кэш;

cache_dir ufs /var/spool/squid 1024 16 256

где ufs — файловая система (ufs для SQUID является самой подходящей); /var/spool/squid — директория хранения кэша; 1024— объем пространства в мегабайтах, которое будет выделено под кэш; 16— количество каталого первого уровня, которое будет создано для размещение кэша; 256 — количество каталого второго уровня, которое будет создано для размещение кэша.

При таком раскладе, доступ происходит без пароля, достаточно в браузере прописать ip адрес прокси сервера и порт 3128.

Далее рассмотрим вариант настройки, — вход по логину и паролю.

Добавляем в начале файла /etc/squid/squid.conf следующие строки:

auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/auth_usersauth_param basic children 50auth_param basic realm SQUID PROXYauth_param basic credentialsttl 3 hoursacl auth_users proxy_auth REQUIRED

где /usr/lib64/squid/basic_ncsa_auth — расположение ncsa_auth (в зависимости от системы может находиться в другом каталоге); /etc/squid/auth_users — файл с логинами и паролями; children 50 разрешает 50 одновременных подключений; SQUID PROXY — произвольная фраза для приветствия; credentialsttl 3 hours будет держать сессию 3 часа, после потребуется повторный ввод логина и пароля.

И после строки:

http_access deny !Safe_ports

Добавляем:

http_access allow auth_users

Далее создадим файл с логинами и паролями, только для этого в начале установим httpd-tools:

Добавляем пользователя для SQUID:

htpasswd -c /etc/squid/auth_users user01

Появится запрос на ввод пароля. Вот таким образом создаем всех пользователей.

Перезапускаем SQUID:

И сразу добавляем в автозагрузку:

Стань профессиональным веб-мастером или программистом!

Источник: http://ddr64.ru/ustanovka-i-nastroyka-squid-na-centos-7/

Установка и настройка стека ELK на Centos 7.3

В больших и высоконагруженных системах анализ журнальных файлов (логов) представляется достаточно сложным делом, так как генерируется большой объем информации, иногда также и разбросанной по различным местам. Для облегчения сбора и анализа логов таких систем существуют различные продукты, одним из примеров которых является и стек ELК. Это три продукта, логически связанные между собой:

Эти продукты не входят в стандартные репозитории ОС, поэтому, чтобы не ставить их вручную из исходных кодов, предварительно скачаем и установим платформу JAVA используя пакетный менеджер yum.

Скачать Java можно например отсюда. Необходимо выбрать версию для нашей ОС и скачать её, нажав соответствующую кнопку. Установка выполняется также через Yum.

Также на сайте справа есть инструкция по установке Java.

Поисковый движок ElasticSearch для анализа логов;
Logstash – демон пересылки логов, позволяет перенаправлять различные журналы для дальнейшего анализа, может фильтровать эти журналы по определенным признакам;
Kibana – интерфейс для анализа содержимого лог-файлов и наглядного представления полученной информации.

Скачиваем и добавляем ключ репозитория

После этого можно начинать настройку. Рассмотрим для примера настройку анализа файлов журналов Nginx локального сервера (на котором установлен стек ELK).

Раскомментируем в файле /etc/elasticsearch/elasticsearch.yml строчки network.host и http.port, заповнив их значениями указанными ниже. Они указывают с каких хостов и по какому порту elasticsearch будет принимать соединения. В нашем случае localhost – то есть этот же компьютер.

После этого стартуем сервис elasticsearch и включаем его автозапуск.

Теперь создадим правило для пересылки логов c локального сервера для logstash.

Любая конфигурация logstash содержит эти разделы (могут быть и другие):

input – какие данные и где брать для анализа.. В данном случае это файл /var/log/nginx/access.log
output – выходной раздел – место для отправки input- в данном случае принимающий демон на этой же машине.
filter – фильтр input если какая-то часть данных не нужна для анализа.

Включаем logstash

Последним настраивается web-интерфейс kibana. В файле /etc/kibana/kibana.yml необходимо задать как-минимум адрес на котором будет доступна kibana, порт и url elasticsearch.

После этого можно запустить Kibana командой systemctl.

Теперь можно зайти в Kibana по указанному адресу и порту 5601. Firewall должен быть настроен на разрешение доступа к порту Кибана. http://78.140.223.147:5601

Источник: https://oblako.kz/help/linux/ustanovka-elk-steka-na-centos

Установка и настройка LXC в CentOS 7

LXC (Linux Containers) — система виртуализации уровня ОС, позволяющая внутри основной операционной системы запускать изолированные дочерние ОС (с отдельными файловыми системами, сетевым стеком и памятью, но общим ядром).

Давайте разберемся на конкретном примере установки Linux Containers (LXC) в операционной системе CentOS 7!

На сегодняшний день установка LXC недоступна из базового репозитория CentOS 7, поэтому нужно добавить в систему EPEL репозиторий командой:

yum -y install epel-release

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

После настройки сети приступаем к установке необходимых пакетов:

yum -y install lxc lxc-templates libcap-devel libcgroup wget bridge-utils dnsmasq iptables-services

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

lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching…
Kernel configuration found at /boot/config-3.10.0-514.2.2.el7.x86_64
— Namespaces —
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled — Control groups —
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled — Misc —
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
Bridges: enabled
Advanced netfilter: enabled
CONFIG_NF_NAT_IPV4: enabled
CONFIG_NF_NAT_IPV6: enabled
CONFIG_IP_NF_TARGET_MASQUERADE: enabled
CONFIG_IP6_NF_TARGET_MASQUERADE: enabled
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled — Checkpoint/Restore —
checkpoint restore: enabled
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: enabled
CONFIG_INET_DIAG: enabled
CONFIG_PACKET_DIAG: enabled
CONFIG_NETLINK_DIAG: enabled
File capabilities: enabled Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Благодаря установленному пакету lxc-templates мы получили готовые шаблоны, которые можно использовать для быстрого создания LXC-контейнеров. Просмотреть список шаблонов можно так:

ls -la /usr/share/lxc/templates/
total 344
drwxr-xr-x. 2 root root 4096 Jan 12 02:43 .
drwxr-xr-x. 6 root root 106 Jan 12 02:43 ..
-rwxr-xr-x. 1 root root 10579 Dec 3 14:09 lxc-alpine
-rwxr-xr-x. 1 root root 13534 Dec 3 14:09 lxc-altlinux
-rwxr-xr-x. 1 root root 10839 Dec 3 14:09 lxc-archlinux
-rwxr-xr-x. 1 root root 9677 Dec 3 14:09 lxc-busybox
-rwxr-xr-x. 1 root root 29491 Dec 3 14:09 lxc-centos
-rwxr-xr-x. 1 root root 10486 Dec 3 14:09 lxc-cirros
-rwxr-xr-x. 1 root root 18306 Dec 3 14:09 lxc-debian
-rwxr-xr-x. 1 root root 17781 Dec 3 14:09 lxc-download
-rwxr-xr-x. 1 root root 49435 Dec 3 14:09 lxc-fedora
-rwxr-xr-x. 1 root root 28253 Dec 3 14:09 lxc-gentoo
-rwxr-xr-x. 1 root root 13962 Dec 3 14:09 lxc-openmandriva
-rwxr-xr-x. 1 root root 14046 Dec 3 14:09 lxc-opensuse
-rwxr-xr-x. 1 root root 35540 Dec 3 14:09 lxc-oracle
-rwxr-xr-x. 1 root root 12233 Dec 3 14:09 lxc-plamo
-rwxr-xr-x. 1 root root 6851 Dec 3 14:09 lxc-sshd
-rwxr-xr-x. 1 root root 23976 Dec 3 14:09 lxc-ubuntu
-rwxr-xr-x. 1 root root 11641 Dec 3 14:09 lxc-ubuntu-cloud

Создать контейнер можно командой lxc-create, указав после опции -n имя контейнера, а после -t шаблон ОС для его создания. Результат выполнения команды сильно сокращен:

lxc-create -n Lxc0 -t centos
Host CPE ID from /etc/os-release: cpe:/o:centos:centos:7
Checking cache download in /var/cache/lxc/centos/x86_64/7/rootfs …
Cache found. Updating…
Loaded plugins: fastestmirror
…
…
…
Complete!
Loaded plugins: fastestmirror
Cleaning repos: base extras updates
0 package files removed
Update finished
Copy /var/cache/lxc/centos/x86_64/7/rootfs to /var/lib/lxc/Lxc0/rootfs …
Copying rootfs to /var/lib/lxc/Lxc0/rootfs …
sed: can't read /var/lib/lxc/Lxc0/rootfs/etc/init/tty.conf: No such file or directory
Storing root password in '/var/lib/lxc/Lxc0/tmp_root_pass'
Expiring password for user root.
passwd: Success
sed: can't read /var/lib/lxc/Lxc0/rootfs/etc/rc.sysinit: No such file or directory
sed: can't read /var/lib/lxc/Lxc0/rootfs/etc/rc.d/rc.sysinit: No such file or directory Container rootfs and config have been created.
Edit the config file to check/enable networking setup. The temporary root password is stored in: '/var/lib/lxc/Lxc0/tmp_root_pass' The root password is set up as expired and will require it to be changed
at first login, which you should do as soon as possible. If you lose the
root password or wish to change it without starting the container, you
can change it from the host by running the following command (which will
also reset the expired flag): chroot /var/lib/lxc/Lxc0/rootfs passwd

Контейнер будет создан с паролем по умолчанию, который можно подсмотреть в файле /var/lib/lxc/Lxc0/tmp_root_pass:

cat /var/lib/lxc/Lxc0/tmp_root_pass
Root-Lxc0-d3OLnh

Этот автоматически созданный рутовый пароль сразу же меняем на более удобный. Сделать это можно так:

chroot /var/lib/lxc/Lxc0/rootfs passwd

Существует также вариант создания контейнеров в более интерактивном режиме (возможность выбрать дистрибутив/релиз/архитектуру), например:

lxc-create -t download -n Lxc1
…
Distribution: centos
Release: 7
Architecture: amd64

Для запуска LXC-контейнера в фоновом режиме следует использовать команду:

lxc-start -n Lxc1 -d

Если же вы не укажете опцию -d, то после старта контейнера автоматически попадете в его консоль. При первом подключении к контейнеру вы увидите что-то типа:

Type to exit the console, to enter Ctrl+a itself

— в моем случае это не заработало, поэтому я всегда запускаю контейнеры с опцией -d.

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

lxc-attach -n Lxc0

На этом этапе следует установить внутри контейнера все необходимые для комфортной работы системные утилиты.

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

lxc-stop -n Lxc0

получение дополнительной информации о контейнере:

lxc-info -n Lxc0

клонирования контейнеров:

lxc-clone Lxc0 Lxc2

создания снепшотов (работает при остановленном контейнере):

lxc-snapshot -n Lxc0

восстановления из снепшотов:

lxc-snapshot -r snap0 -n Lxc0

и удаления контейнеров:

lxc-destroy -n Lxc0

Для более тонкой настройки контейнера можно использовать конфигурационный файл /var/lib/lxc/{имя_контейнера}/config.

Источник: https://letsclearitup.com.ua/lxc/ustanovka-i-nastroyka-lxc-v-centos-7.html

Наш опыт тестирования LXC (Linux Containers) на примере Debian Wheezy

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

Под катом вы найдете небольшой обзор технологии и краткий мануал по использованию LXC в Debian Wheezy и наши выводы. Технология уже давно и активно разрабатывается. На данный момент стабильная версия 0.9, в следующем году готовится релиз 1.0, который будет включен в состав Ubuntu 14.04 LTS.

Однако, на данный момент в mainstream-ядре Ubuntu отсутствует поддержка User Namespace, поэтому в данной статье рассмотрено применение Linux Containers на примере Debian Wheezy. Стоит ли начать использовать LXC уже сейчас? Попробуем разобраться.

LXC (Linux Containers) есть не что иное, как технология виртуализации уровня операционной системы.

Хотя в полной мере технологией виртуализации LXC назвать нельзя, это скорее технология изоляции и разделения ресурсов компьютера. LXC это логическое продолжение двух предыдущих технологий Vserver и OpenVZ, однако развивается в рамках “ванильной” ветки ядра начиная с версии 2.6.29.

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

Что представляет собой LXC? LXC — это набор утилит, позволяющий посредством API использовать возможности ядра Linux по созданию изолированных контейнеров операционной системы и их управлению. Достичь всего этого позволяют различные возможности ядра Linux:

Изоляция и ограничение ресурсов (cgroup)
Изоляция пространств имен ядра (ipc, uts, mount, pid, network, user)
Изоляция файловой системы (Chroot)
Профили Apparmor и SELinux
Политики Seccomp

Как и любая другая технология контейнерной виртуализации, LXC будет полезна для нужд веб-хостинга, разработки, а также для тестирования и отладки веб-проектов.

Установка, настройка LXC на Debian 7

Как уже было сказано ранее, LXC использует Cgroup, и чтобы начать работать с контейнерами, необходимо примонтировать файловую систему cgroup. По умолчанию точка монтирования /sys/fs/cgroup, однако можно производить монтирование в произвольной точке. Поправим fstab, добавим cgroup:vi /etc/fstab

…

cgroup /sys/fs/cgroup cgroup defaults 0 0
…
И примонтируем виртуальную файловую систему cgroup:mount /sys/fs/cgroup
Для администрирования контейнеров используется набор утилит lxc.

Установим пакет lxc, остальное система сама подтянет:apt-get install lxc
Папка в которой будут храниться контейнеры, по умолчанию: /var/lib/lxc После установки утилит необходимо удостовериться, что система полностью готова для начала работы с контейнерами:lxc-checkconfig

root@lxc-debian:~# lxc-checkconfig Kernel config /proc/config.gz not found, looking in other places…
Found kernel config file /boot/config-3.2.0-4-amd64
— Namespaces —
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled — Control groups —
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled — Misc —
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
Если все в порядке, можно попробовать создать первый контейнер.

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

lxc-create -n test -t debian
где ‘-n test’ — имя контейнера, ‘-t debian’ шаблон ОС создаваемого контейнера. Сам lxc-шаблон представляет собой bash-скрипт, который создает папки корневой файловой системы, минимальный набор файлов конфигов, а также подтягивает свежие пакеты из репозиториев. При этом, после первого запуска скрипта создания шаблона, нужные пакеты кэшируются на диске. Конечно же скрипт легко подстроить под себя. Например добавить установку набора необходимых для вас пакетов. Такой подход к шаблонам, по моему скромному мнению, немного удобнее чем в том же OpenVZ. В Debian можно найти шаблоны Archlinux, Altlinux, Fedora, Opensuse, Ubuntu-Cloud. Если имеющегося набора шаблонов недостаточно, можно попробовать создать недостающий шаблон самому.

По умолчанию в Debian запускается некий мастер который поможет создать контейнер, проведя по нескольким шагам. И все бы хорошо, но вот шаблон Wheezy “сломан”, а использовать Sqeeze уже не очень хочется. Поэтому нужно либо сделать свой шаблон, либо поискать рабочий на просторах интернета.

Скачаем новый шаблон, к примеру, для CentOS 6:cd /usr/share/lxc/templates

wget https://gist.github.com/hagix9/3514296/raw/7f6bb4e291fad1dad59a49a5c02f78642bb99a45/lxc-centos

chmod +x lxc-centos
Также для CentOS понадобится менеджер пакетов yumapt-get install yum
Создадим новый контейнер с использованием шаблона CentOS:lxc-create -n test -t centos
Создав первый контейнер, мы получаем абсолютно чистую систему: в ней нет практически ничего даже текстовых редакторов. Попасть в консоль контейнера можно двумя способами: При запуске контейнера вы автоматически попадете в его консоль, где вам нужно будет авторизоваться, по-умолчанию в Debian пароль root: root.lxc-start -n test
Если вы используете альтернативный шаблон, то пароль можно подсмотреть в файле шаблона. Второй вариант, подключение к уже запущенному контейнеру:lxc-console -n test
При первом подключении к контейнеру должна появляться такая нотация:Type to exit the console, to enter Ctrl+a itself
— это не работает или работает не всегда. Может быть на более свежих релизах уже починили. Поэтому стоит использовать screen, либо запускать контейнер с ключом -d и заходить на него по ssh (если сеть уже настроена). В общем случае контейнер будет использовать сетевой стек хостовой машины. Для тестирования вполне сойдет, но не для веб-проектов, поэтому далее рассмотрим как получить изолированный сетевой стек в контейнере. Удаление контейнера выполняется утилитой lxc-destroy:lxc-destroy -n test

Настройка сети Рассмотрим два варианта: — У нас есть сервер и много “белых” ip-адресов. Каждый контейнер может иметь свой адрес и свободно общаться с интернетом. — У нас есть сервер и несколько, а то и всего один “белый” ip-адрес. В этом случае, скорее всего, большая часть контейнеров будет работать за NAT. В обоих случаях нам пригодится сетевой мост, DHCP-сервер и iptables:apt-get install bridge-utils isc-dhcp-server

Прежде чем приступить к настройке сети контейнера, настроим два сетевых моста (bridge) на хостовой машине. Один для “белых” адресов, другой — для приватных “серых” адресов. Файл настроек сетевых адаптеров будет выглядеть так:vi /etc/network/interfaces

# Для белых адресов
auto br0 iface br0 inet static bridge_ports eth0 bridge_fd 0 address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 192.168.0.1 8.8.8.8 # Для серых адресов
auto lxcbr0 iface lxcbr0 inet static bridge_ports none bridge_fd 0 address 10.0.0.1 netmask 255.255.255.0

Первый вариант Пропишем сетевой адаптер в конфиге контейнера. По умолчанию папка в которой содержатся контейнеры /var/lib/lxc, в ней ищем папку с именем нашего контейнера (test), в ней будет лежать файл config, его и будем редактировать. Допишем в конец файла блок с сетевыми настройками:vi /var/lib/lxc/test/config

…
# networking
lxc.utsname = centos
# Тип сети (виртуальный интерфейс)
lxc.network.type = veth
# Флаг – линк поднят lxc.network.flags = up
# Физический сетевой адаптер (сетевой мост)
lxc.network.link = br0 # Имя виртуального адаптера в контейнере
lxc.network.name = eth0 # Имя виртуального адаптера на хостовой машине
lxc.network.veth.pair = veth0 # IP-адрес контейнера
lxc.network.ipv4 = 192.168.0.101/24 # Основной шлюз контейнера
lxc.network.ipv4.gateway = 192.168.0.1 # Физический (mac) адрес виртуального адаптера
lxc.network.hwaddr = 00:1E:2D:F7:E3:4F
Теперь можно запускать контейнер и пробовать подключаться по ssh:lxc-start -n test -d && ssh [email protected]

Второй вариант

Источник: https://habr.com/company/southbridge/blog/202482/

Записки программиста

Пришло время научиться работать с Linux Containers, более известными под названием LXC.

Далее мы будем рассматривать LXC в контексте Debian и Ubuntu, но написанное во многом будет применимо и для других дистрибутивов Linux.

Мы коснемся не только основ использования LXC, но и узнаем, как настроить bridged сеть, ограничить количество ресурсов, используемых контейнером, и даже осилим unprivileged containers.<\p>

Коротко о главном

LXC — технология контейнерной виртуализации, как и OpenVZ. Накладные расходы на создание контейнеров очень невелики, и ничто не мешает нам запускать их сотнями или тысячами.

Что невозможно при использовании честной и полноценной виртуализации, такой, как KVM. С другой стороны, запустить в контейнере ОС, отличную от Linux, мы не можем. На самом деле, не совсем корректно называть LXC отдельной технологией.

Все работает сразу на нескольких фичах ядра Linux. Как минимум, это cgroups и namespaces.

Control Groups, они же cgroups, позволяют организовывать процессы в группы и для каждой группы задавать лимиты. Например, лимиты на использование CPU, объем используемой памяти и дисковый ввод-вывод.

Namespaces бывают разные — PID namespace, IPC namespace, UTS namespace, user namespace, mount namespace, network namespace. Неймспейсы изолируют друг от другая процессы таким образом, что процессы в одной группе не могут видеть ресурсы другой группы.

Например, PID namespace предоставляет уникальные идентификаторы процессов в рамках группы. Внутри одной группы может быть процесс с pid’ом 1 и внутри второй группы тоже может быть процесс с pid’ом 1, хотя это два совершенно разных процесса, которые друг о другие ничего не знают.

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

В отличие от Docker, который заточен на создание PaaS, в LXC нет никаких слоеных неизменяемых файловых систем. Контейнеры очень похожи на VDS’ы, как и в OpenVZ. Но в отличие от OpenVZ, в LXC далеко не все есть из коробки.

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

Как следствие, LXC превосходно работает на самой обычной Ubuntu, чем OpenVZ похвастаться не может.

Примечание: Кстати, в заметке Начало работы с Vagrant и зачем он вообще нужен рассказывается, как работать с LXC через Vagrant. Использование LXC через Vagrant кому-то может показаться удобнее, чем работа с LXC напрямую.

Установка

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

Итак:

sudo apt-get update
sudo apt-get install lxc lxc-templates systemd-services cgroup-bin
bridge-utils debootstrap

Очень важно реально сделать update, чтобы поставились наиболее свежие версии указанных пакетов. И, не поверите, но реально лучше сразу сделать reboot. Иначе, работая с LXC, вы в какой-то момент можете получить странную ошибку вроде такой:

call to cgmanager_create_sync failed: invalid request

Источник: https://eax.me/lxc/

Установка и использование Docker на Centos 7

В инструкции описан процесс установки и использования Docker на виртуальных серверах под управлением операционной системы Centos 7.

Что это такое?

Docker – это платформа для разработчиков и системных администраторов, предназначенная для разработки, развертывания и запуска приложений в контейнерах изолированных друг от друга.

Использование контейнеров для развертывания приложений в Linux называется контейнеризацией.

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

Для работы с Docker необходимо понимать отличия между терминами образ и контейнер:

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

О контейнерах подробно написано в нашем блоге: В чём суть контейнеров приложений?

Образ является шаблоном доступным только для чтения. Образ Docker может быть дистрибутивом Linux или полностью сконфигурированным корпоративным программным обеспечением, готовым к запуску. Все зависит от специального файла – Dockerfile.

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

Примечание: демон является одним из компонентов Docker, который выполняет тяжелые задачи по созданию, запуску и распределению изображений после получения команд из Докер-клиента.

В общем случае запуск приложения в Docker выглядит так:

Выбирается приложение, которое требуется запустить в контейнере.
В конфигурационном файле Dockerfile описывается это приложение и среда выполнения согласно синтаксису.
Формируется образ приложения, представляющий собой единый файл. Он включает в себя и исполняемые файлы приложения, и все его библиотеки (за исключением общесистемных), т.е. в дальнейшем приложение остается неизменным в контейнере.
Запускается Docker с указанным образом прикладного приложения, которое используется для прикладных задачи.

Установка

Прежде всего следует обновить локальную базу пакетов:

Для установки самой последней и стабильной версии Docker необходимо обратиться к официальному репозиторию Docker. Следующая команда добавит репозиторий, загрузит последнюю версию ПО и установит его:

Примечание: если вы собираетесь использовать Docker не от имени пользователя root, то необходимо добавить пользователя в созданную после установки группу docker:

Например:

Запустите демон Docker после окончания установки:

Убедитесь в том, что демон стартовал без ошибок и предупреждений:

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

Работа с образами в Docker

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

docker

Чтобы вывести на экран все доступные команды и краткую информацию о них, просто используйте команду docker:

docker

По умолчанию образы извлекаются из реестра Docker Hub, дочернего проекта Docker. Любой пользователь может создавать и размещать свои образы на Docker Hub, поэтому большинство приложений, СУБД и дистрибутивов Linux имеют свои образы на Docker Hub.

Чтобы проверить, можете ли вы получать и загружать образы из Docker Hub, выполните следующую команду:

В результате должно отобразиться подобное сообщение:

Чтобы выполнить поиск нужного образа, используйте следующий формат команды:

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

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

Загрузить нужный образ можно с помощью команды следующего формата:

docker pull

Например:

docker pull nginx

Вы увидите процесс загрузки:

После того как образ был загружен на ваш сервер, запустить его можно с помощью опции run:

Посмотреть все загруженные образы можно с помощью опции images:

Отобразится список:

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

Чтобы создать контейнер с именем example на основе образа image, используйте следующую команду:

Примечание: комбинация ключей -i и -t дает интерактивный доступ к оболочке shell в контейнере.

Пример создания контейнера example на основе образа nginx:

Посмотреть запущенные контейнеры можно с помощью опции ps:

Примечание: ключ -l позволяет просмотреть все существующие контейнеры.

Отобразится список:

Чтобы запустить созданный контейнер в фоновом режиме, используйте следующую команду:

Например:

Чтобы зайти внутрь контейнера, который работает в фоновом режиме, выполните следующую команду:

Пример:

Для выхода из контейнера используйте стандартную команду exit.

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

Например:

Чтобы удалить контейнер используйте опцию rm:

Например:

Примечание: ключ -f позволяет удалять запущенные контейнеры без их предварительной остановки.

Для более подробного примера запустим приложение nginx на конкретном порту, например 80, и убедимся, что все работает. Не забудьте настроить firewall и открыть данный порт на сервере:

Запускаем контейнер с именем example:

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

Источник: https://1cloud.ru/help/linux/instruktsiya-docker-na-centos7

LXC-контейнеры для домашнего сервера (часть первая)

Вместо вступления

Контейнерная виртуализация переживает настоящий бум именно сейчас. Увлечение Docker с целью или без оной не оставило равнодушным ни одного более-менее адекватного “ойтишнега”, который хочет быть “в тренде” и тщетно прокачивает скиллы в надежде на светлое будущее. LXC (Linux Containers) плетутся (или бегут ?) где-то рядом.

Дальнейший текст – лишь результат эксперимента, проведенного на домашнем сервере под управлением Linux. Он не претендует на полноту и точность, и, совершенно точно, можно сделать лучше. Но всем, вобщем-то пофигу.

В чём проблема, бро ?

Есть домашний сервер, который работает качалкой торрентов, хостингом OwnCloud, TOR-middlebox'ом и помимо этого тащит на себе [email protected] и пару других чахлых web-приложений. Задача – изолировать приложения друг от друга и от хост-системы. Зачем ? Ответов несколько:

Поддерживать хост (bare metal) систему в рабочем предсказуемом состоянии не загаживая её кучей зависимостей, а тем более – собранных из исходников пакетов. Место на диске считаем условно бесконечным, учитывая цену за гигабайт.
Пусть каждое приложение работает в окружении, которое рекомендовано производителем. То есть, если кто-то любит Lighttpd, а для OwnCloud готовые решения хорошо документированы при использовании nginx, ради бога – пусть это будет nginx.
Настроить бэкап так, чтобы инфраструктуру можно было восстановить “обратно” не тратя времени на повторную настройку и сборку граблей.
Потому что хочется (это, кстати, самый веский аргумент)

Как будем разруливать ?

Довольно очевидным способом, а именно создадим набор контейнеров, каждый из которых будет иметь собственный внутренний IP-адрес, выделенный кусочек LVM, и сильно популярный дистрибутив, дабы не искать выход из тупика на говнофорумах расейских пользователей типа LOR, а пользоваться уже накопленными и систематизированными знаниями в кормушках типа LinuxQuestions и StackOverflow. Как уже говорилось – на сегодня у нас 2 мощнейших кандидата – Docker и LXC. Для моих задач больше подходит LXC – Docker всё-таки больше подходит под deploy и “одно приложение-один контейнер”. Ну и заморочки с persitent тоже время отожрут немалое, а толку от них в домашнем хозяйстве не очень много.

Подготовка

Все действия производились на Cubieboard 2 под управлением Armbian и ядра 4.х. Тестирование proof-of-concept проводилось на Андроид-стике с ядром 3.0.

36 (на Linux, если что), так что решение заработает на любом ущербном китайском устройстве, даже если нет “последнего ядра”, лишь бы все нужные флаги в ядре присутствовали (поддержка cgroups, например).

Ну за этим – в документацию. Там всё хорошо описано.

Для начала нам нужно будет создать ещё одну подсеть, в которой будут жить наши контейнеры. Шаги:

Установим lxc, он “потащит” за собой нужные пакеты.
Дальше – настроим сеть.
Ещё нужно позаботиться о дисковом пространстве. Я использую LVM в качестве storage backend, но можно обойтись без него и файловая система “ляжет” в обычную директорию.

Сеть

Нам потребуется “поднять” bridge-интерфейс. При этом я не привязывал его к конкретному сетевому адаптеру, чтобы работало даже на устройствах, где кроме беспроводного интерфейса ничего нет.

Вот примерно так выглядит /etc/network/interfaces:

#empty bridge auto br0 iface br0 inet static address 192.168.242.1 netmask 255.255.255.0 network 192.168.242.0 bridge_ports none

Итак, сеть вида 192.168.242.x будет отдана под контейнеры.

На сетевой карте, которая “смотрит” в интернет нужно включить masquerading с помощью iptables, ну и не забыть бы forwarding в настройках ядра. Делается примерно так, правда нужно сохранить настройки, чтобы переживать перезагрузку (способов много):

iptables –table nat –append POSTROUTING –out-interface eth0 -j MASQUERADE /sbin/sysctl -w net.ipv4.ip_forward=1

Ещё я использую пакет dnsmasq для обеспечения доступа к DNS своих контейнеров. После установки нужно будет добавить в конфигурационный файл /etc/dnsmasq.conf такие строчки:

interface=br0 no-dhcp-interface=br0

Мы говорим, что DNS доступен на интерфейсе br0, и мы используем статические IP для контейнера.

Диск

Как уже говорилось – в случае использования LVM должно быть достаточное количество дискового пространства. По-умолчанию контейнер выделяет себе гигабайт. Как показала практика – это не очень много 🙂

Если LVM не используется – вы ограничены только свободным местом на основном диске.

Первый контейнер

В принципе, можно создавать первый контейнер. Делается это командой lxc-create, в моем случае это выглядит вот так:

sudo lxc-create -t download -n applications -B lvm –vgname vg0 –fssize 2G –lvname applications

Рассмотрим подробнее:

Мы будем использовать LVM для storage backend.
Мы будем скачивать готовый rootfs с сайта LXC (кстати, он иногда любит упасть). Выберем его позднее в интерактивном режиме выполнения lxc-create.
Контейнер будет называться “applications”
Он будет создан в Volume Group vg0 (/dev/vg0)
Логический том будет иметь то же имя (applications)
Мы выделяем под него 2 гигабайта места

В случае не-использования lvm – решительно убираем опции -B, –vgname, –fssize, –lvname.

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

Downloading the image index

—

DIST RELEASE ARCH VARIANT BUILD

—

centos 6 amd64 default 20160811_02:16 centos 6 i386 default 20160811_02:16 centos 7 amd64 default 20160811_02:16 debian jessie amd64 default 20160810_22:42 debian jessie arm64 default 20160811_03:58 …..

ubuntu yakkety armhf default 20160811_03:49 ubuntu yakkety i386 default 20160811_03:49 ubuntu yakkety powerpc default 20160811_03:49 ubuntu yakkety ppc64el default 20160811_03:49 ubuntu yakkety s390x default 20160811_03:49

Напомню, что весь процесс у нас происходит на процессоре ARM (CubieBoard2, Orange Pi), поэтому архитектуру мы будем использовать armhf.

Вообще, лучше выбирать какой-нибудь известный дистрибутив. Я использвал ubunty trusty для armhf – это всё-таки LTS, хоть и старый, да и под настройку всего полно туториалов.

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

После окончания процесса получаем примерно такое сообщение:

You just created an Ubuntu container (release=trusty, arch=armhf, variant=default) To enable sshd, run: apt-get install openssh-server For security reason, container images ship without user accounts and without a root password.
Use lxc-attach or chroot directly into the rootfs to set a root password or create user accounts.

Не торопитесь запуcкать контейнер. Для начала его нужно настроить – создать пароль root'а по крайней мере, да и сеть тоже не будет лишней.

Установка пароля root в контейнере

Вот тут начинается самое главное. Конечно, можно воспользоваться советом системы и запустить lxc-attach, но у меня лично на старом тестовом ядре не заработал “как надо”. Так что предлагаю смонтировать lvm в директорию, и сделать туда chroot перед запуском, чтобы установить пароль root и настроить сеть.

Вот настройка настройка сети для использования статического адреса в контейнере с Ubuntu 14.04:

auto eth0 iface eth0 inet static address 192.168.242.120 netmask 255.255.255.0 gateway 192.168.242.1 dns-nameservers 192.168.242.1

Команды, которые нужно выполнить для chroot в контейнер и настройки сети

mount /dev/vg0/applications /mnt chroot /mnt passwd vi /etc/network/interfaces (….тут настраиваем сеть….) exit umount /mnt

Подготовка конфигурационного файла

Вторым шагом перед стартом контейнера – его нужно донастроить. Конфигурационный файл в нашем случае – /var/lib/lxc/applications/config

#Distribution configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf #Container specific configuration lxc.rootfs = /dev/vg0/applications lxc.utsname = applications lxc.arch=armhf lxc.autodev=1 lxc.kmsg=0 #Network configuration lxc.network.type = veth lxc.

network.flags = up lxc.network.link = br0 lxc.network.hwaddr = f8:7a:15:0c:f6:4f lxc.network.script.up = /usr/local/bin/lxc_applications.sh lxc.mount.entry = /var/lvm/data/downloads var/downloads none bind 0 0 #Autostart lxc.start.auto = 1 lxc.start.order = 0 lxc.start.

delay = 10

Возможно, для начала, секцию Autostart можно выкинуть (и включить, когда все уже настроено).

В конфигурации сети нужно указать тип сети (veth), линк (br0), и мак-адрес. Его можно сгенерить с помощью массы онлайн сервисов. Напомню, что сам IP адрес “прописан” в самом контейнере – как на “настоящей” системе.

Еще присутствует некий скрипт, который будет выполняться на хосте при старте контейнера – но об этом во второй части заметки, равно как и подключение “внешней” директории через директиву lxc.mount.entry.

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

Для первого старта:

lxc-start -n applications

Если всё хорошо – мы увидим стартующие сервисы и сможем попасть внутрь контейнера, используя пароль root.

Если что-то пошло не так – проверяем, что мак-адрес валиден (можно просто перегенерить) и что мы действительно установили пароль. Ну или пользуемся lxc-attach, если ядро позволяет.

В LXC 1.0 – контейнер по-умолчанию стартует в foreground mode, в 2.0 – в background.

Чтобы запустить 1.0 контейнер в background mode, нужно использовать опцию “-d” команды lxc-start.

Итак, если все хорошо, то будет доступна сеть и можно ставить нужные приложения!

To Be Continued..

Окончание этой санта-барбары

Источник: http://znoxx.me/2016/08/11/lxc-kontieiniery-dlia-domashniegho-sierviera-chast-piervaia/

LXC

Контейнерная виртуализация выполняется на уровне операционной системы — обычно это Docker или LXC, она выгодно отличается, например от KVM тем, что не требует перекомпиляции ядра. LXC о котором пойдет речь может работать с «ванильным ядром», т.е. ядром в которое специально не вносилось каких-либо изменений.

LXC контейнер — гостевая система, которая создается в рамках хоста и создается, а затем администрируем выполнением команд с хоста, который после запуска на нем гостевых систем становится мастер-сервером .

Для создания виртуальных машин на базе LXC удобно использовать Ubuntu, при подготовке данного материала использовалась серверная Ubuntu 16.04. ВСе команды кроме тех, что вводятся в консоли гостевой системы выполяняются от имени root или с sudo.

Обновляем информацию о подключенных репозиториях

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

После того как процесс завершится (будет занято около 60 Мб места на диске) сервер нужно перезагрузить поскольку в процессе установки вносились изменения в сетевые настройки — был добавлен интерфейс, на котором будут работать гостевые системы

После перезагрузки можно создавать первый контейнер, именем виртуальной машины будет container. Создавать машину будем из шаблона (ubuntu), все доступные шаблоны находятся в каталоге /usr/share/lxc/templates/ (туда можно загружать свои шаблоны)

Список существующих LXC контейнеров можно вывести выполнив

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

Останавливается виртуальная машина идентичным способом

Данные конкретном контейнере можно посмотреть

Контейнер является полноценной виртуальной машиной с которой можно работать по SSH

С мастер хоста можно попасть внутрь выполнив:

Оказавшись внутри гостевой системы из нее не так просто выйти, при вводе стандартной комбинации CTRL+D вновь возникнет диалог авторизации, выйти из которого нельзя.

Самым распространенным способом является работы с виртуальными машинами является использование screen или, более простое решение — при необходимости покинуть сервер можно зайти на мастер другой консолью и сказать lxc-stop -n container

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

Поскольку LXC контейнер создавался из шаблона логин и пароль стандартные — ubuntu. Оказавшись в системе пароль нужно сменить, иначе сервер будет быстро взломан ботами, подбирающими пароли.

Ненужный больше контейнер можно удалить

Дополнительные возможности при работе с LXC

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

LXC контейнер можно склонировать

Можно создать точный снимок системы, затем восстановиться из него в любой удобный момент (этот функционал идентичен другим системам виртуализации)

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

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

Настройка автозапуска гостевых систем

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

Они вносятся в /var/lib/lxc/CONTAINERNAME/config и заключаются в добавлении трех строк, значения второй и третьей директив можно варьировать

lxc.start.auto = 1
lxc.start.delay = 10
lxc.start.order = 40

Выделение виртуальной машине указанного количества серверных ресурсов

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

Все корректировки применимы к существующим машинам, однако они в обязательном порядке должны быть перезагружены для того чтобы изменения в конфигах вступили в силу (можно задавать и для работающих, в таком случае они будут актуальны до перезагрузки — lxc-cgroup -n container memory.limit_in_bytes 512M, после перезагрузки начнут использоваться заданные в конфигурационных файлах).

Ограничение по CPU

Перед внесением изменений останавливаем тестовый LXC контейнер.

lxc.cgroup.memory.limit_in_bytes = 512M

Проверить все ли получилось можно запустив контейнер, затем выполнив следующую команду:

Также можно использовать дебаг

Затем можно выбрать из лога все упоминания о «memory» используя grep

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

Ограничение по диску

Ограничить количество пространства на диске хост машины который может использовать LXC контейнер можно несколькими способами: для этого можно использовать LVM или выделить отдельный раздел в /var/lib/lxc/CONTAINAME, примонтировать его, добавить в /etc/fstab. Второй способ применим чаще, но предполагает ограничение в .img файле, на основе которого создается машина, поэтому поменять объем диска существующей вирт. машины будет сложнее, чем с LVM.

На этапе создания машины нужно выполнить такие действия:

Ограничиваем размер файла при помощи truncate до 1 Гб

Создаем файловую систему ext4

Каталог непосредственно под LXC контейнер

И монтируем раздел

В /etc/fstab допишем строку для автоматического монтирования раздела после перезагрузки:

/var/lib/lxc/container.img /var/lib/lxc/container ext4 loop 0 0

Теперь при создании контейнера система увидит, что заданное имя container совпадает с именем каталога и раздела и разместит данные в нем, авторизовавшись на виртуальной машине по SSH и выполнив команду df -h можно будет увидеть, что объем файловой системы составляет 1 Гб

LXC контейнераизация и настройки сети

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

Проверить адрес можно выполнив команду

Чтобы каждая гостевая система (или некоторые из них) была доступна по белому IP адресу — если хост машине выделено несколько таких адресов — можно настроить виртуальный бридж, однако проще добавить правило в таблицу NAT цепочки PREROUTING iptables

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

Источник: https://server-gu.ru/lxc/

Запускаем виртуализацию LXC на Ubuntu

LXC (англ. Linux Containers) — система виртуализации на уровне операционной системы, которая позволяет запустить множество изолированных пользовательских окружений в рамках одного гипервизора. Мы ранее писали о разнице в технологиях виртуализации в заметке Чем отличаются хостинг, VPS, VDS и выделенный сервер?.

LXC является сравнительно молодым представителем систем “частичной” виртуализации, позволяя запускать на одном выделенном сервере или даже SSD VDS несколько гостевых контейнеров.

Так как речь идет о частичной виртуализации, в качестве гостевых систем можно использовать только различные дистрибутивы Linux – как и в популярном продукте OpenVZ.

Для чего можно использовать LXC? По сравнению с доживающим свой век “традиционным” OpenVZ, решение LXC считается более простым – работает “из коробки” и не требует установки специального ядра, управляется очень просто.

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

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

Давайте попробуем основные возможности LXC – скажем, на сервере под управлением Ubuntu 16. Вначале – переключим работу физического интерфейса в режим “моста” (bridge) – это самый простой вариант обеспечить доступ гостевым системам к сети.

В /etc/network/interfaces создаем интерфейс br0, переносим в его свойства настройки IP-адреса и подключаем этот интерфейс к сетевому адаптеру (enp2s0):