Установка gitlab в lxc контейнер

Установка и использование контейнеров LXC 1.0 в RHEL/CentOS 6.5

Внезапно, чуваки из linuxcontainers.org выкатили LXC-контейнеры версии 1.0.0 готовые, как они утверждают, к промышленной эксплуатации. Разумеется, это надо немедленно проверить и, разумеется, на RHEL/CentOS 6.5. Для этого соберём lxc-1.0.0 из исходников, так как в репозитории EPEL для RHEL/CentOS доступна только версия lxc-0.9.0-2.el6.

[дополнение от 18.11.2015] Это было верно на момент написания статьи. Сейчас в репозитории EPEL для RHEL/CentOS 6/7 доступен пакет lxc-1.0.7-4.

Которые не в курсе, что такое LXC-контейнеры, тем поясняем, что это такой OpenVZ, только построенный на namespaces и cgroups ядра Linux, то есть для использования их не нужно специальное openvz-ядро, так как нужные фичи были добавлены в mainline ядро.

Которые не в курсе, что такое OpenVZ, тем поясняем, что это такой тип виртуализации, посередине между chroot и KVM (или Xen, или VMWare, или VirtualBox), когда процессы контейнера (гостя) бегут на том же ядре, что и основная система, но изолированы от неё средствами namespaces и cgroups.

Такой тип виртуализации отличается от KVM/Xen, которые эмулируют для гостя железо сервера целиком и гость использует своё собственное ядро. Которые не в курсе, что такое вышеупомянутые chroot, KVM, namespaces и cgroups — тем пичалька.

Итак, предположим у нас есть свежий минимальный Red Hat Enterprise Linux или CentOS 6.5. Нам надо установить компилятор, auto-tools, вот это всё для, собственно, сборки LXC из исходников.

Проще всего для этого установить группу Development tools целиком.

Также понадобится пакет libcap-devel для сборки LXC с поддержкой capabilities, пакет busybox для шаблона busybox и пакет bridge-utils для управления бриджами (bridge).

[root@serv ~]# yum groupinstall 'Development tools'
[root@serv ~]# yum install libcap-devel busybox bridge-utils

Если собрать LXC без поддержки capabilities (библиотеки libcap), то он ругнётся о невозможности их сбросить при старте контейнера вот таким образом:

[root@serv ~]# lxc-start -n test1
lxc-start: unknown capability mac_admin
lxc-start: failed to drop capabilities
lxc-start: failed to setup the container

Скачиваем исходники lxc-1.0.0 в куда-нибудь, распаковываем, собираем их с правильными путями и устанавливаем:

[root@serv ~]# wget http://linuxcontainers.org/downloads/lxc-1.0.0.tar.gz
…качаем…
2066-66-66 66:66:66 (1.2 MB/s) – “lxc-1.0.0.tar.gz” saved [779679/779679] [root@serv ~]# tar -xf lxc-1.0.0.tar.gz [root@serv ~]# cd lxc-1.0.0 [root@serv lxc-1.0.0]# ./autogen.sh
+ test -d autom4te.cache
+ aclocal -I config
+ autoheader
+ autoconf
+ automake –add-missing –copy [root@serv lxc-1.0.0]# ./configure –prefix=/usr –sysconfdir=/etc –localstatedir=/var
…много всего…
Environment: – compiler: gcc – distribution: centos – init script type(s): sysvinit – rpath: no – GnuTLS: no – Bash integration: yes
Security features: – Apparmor: no – Linux capabilities: yes – seccomp: no – SELinux: no – cgmanager: no
Bindings: – lua: no – python3: no
Documentation: – examples: yes – API documentation: yes – user documentation: no
Debugging: – tests: no – mutex debugging: no
Paths: – Logs in configpath: no [root@serv lxc-1.0.0]# make
…много всего… [root@serv lxc-1.0.0]# make install
…много всего…

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

[root@serv lxc-1.0.0]# lxc-ls
lxc-ls: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory
[root@serv lxc-1.0.0]# ldconfig
[root@serv lxc-1.0.0]# lxc-ls

Далее, для запуска контейнера кроме самого LXC нам нужна rootfs — корневая файловая система той операционной системы, которая будет запускаться в контейнере. Cамый простой способ — это хранить файловые системы контейнера как файлы в обычных директориях, по умолчанию путь к ним /var/lib/lxc/имя-контейнера/rootfs/.

Также LXC умеет хранить rootfs в подтомах (subvolume) btrfs, в логическом томе (logical volume) LVM, в overlayfs и, внезапно, в подтомах zfs.

Для создания rootfs какой-нибудь операционной системы существуют шаблоны (templates) — это (чаще всего) shell-скрипты, которые копируют откуда-нибудь (например, скачивают из интернетов) архив или файлы соответствующей корневой файловой системы и меняют конфигурационные файлы системы для работы внутри контейнера.

Для каждого типа операционной системы — свой шаблон, они все разные и не все правильно работают. Шаблоны лежат по-умолчанию в /usr/share/lxc/templates/ (при использовании –prefix=/usr в ./configure):

[root@serv ~]# ls /usr/share/lxc/templates/
lxc-alpine lxc-centos lxc-fedora lxc-oracle lxc-ubuntu-cloud
lxc-altlinux lxc-cirros lxc-gentoo lxc-plamo
lxc-archlinux lxc-debian lxc-openmandriva lxc-sshd
lxc-busybox lxc-download lxc-opensuse lxc-ubuntu

Используем самый простой шаблон busybox чтобы проверить можем ли мы вообще стартовать контейнер. Контейнер максимально прост, так как используется один выполнимый файл busybox для всего, включая init. Создаём контейнер с помощью команды lxc-create -t имя-шаблона -n имя-контейнера и запускаем (пытаемся запустить) с помощью lxc-start -n имя-контейнера

[root@serv ~]# lxc-create -t busybox -n busytest
setting root password to “root”
Password for 'root' changed
[root@serv ~]# lxc-start -n busytest
lxc-start: failed to attach 'vethX6WD9V' to the bridge 'virbr0' : No such device
lxc-start: failed to create netdev
lxc-start: failed to create the network
lxc-start: failed to spawn 'busytest'

Внезапно, нифига! Строчка «failed to attach … to the bridge … : No such device» как бы говорит нам, что контейнер хочет прицепить свой сетевой интерфейс к бриджу virbr0, которого у нас нет. Делать это заставляет конфиг контейнера, который лежит в /var/lib/lxc/имя-контейнера/config и в котором, в частности, написано:

[root@serv usr]# cat /var/lib/lxc/busytest/config
…
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = virbr0
lxc.rootfs = /usr/lib/lxc/busytest/rootfs

Итак, надо создать бридж virbr0. К этому бриджу должен быть привязан интерфейс на хосте, позволяющий выход в локальную сеть или интернеты, если контейнер должен иметь к ним доступ. Ну или нет, если нет.

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

Создаём простые конфиги для бриджа и интерфейса (не забудьте подставить ваш MAC-адрес) и поднимаем бридж (ну, или перезагружаемся):

[root@serv ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=66:66:66:66:66:66
TYPE=Ethernet
BRIDGE=virbr0
ONBOOT=yes [root@serv ~]# cat /etc/sysconfig/network-scripts/ifcfg-virbr0
DEVICE=virbr0
TYPE=Bridge
BOOTPROTO=dhcp
IPV6INIT=no
ONBOOT=yes [root@serv ~]# ifup eth1
[root@serv ~]# ifup virbr0
Determining IP information for virbr0… done.
[root@serv ~]# ip addr show virbr0
4: virbr0: mtu 1500 qdisc noqueue state UNKNOWN link/ether 66:66:66:66:66:66 brd ff:ff:ff:ff:ff:ff inet 192.166.66.66/24 brd 192.166.66.255 scope global virbr0

Пробуем опять взлететь:

[root@serv lxc-1.0.0]# lxc-start -n busytest
lxc-start: cgroupfs failed to detect cgroup metadata
lxc-start: failed initializing cgroup support
lxc-start: failed to spawn 'busytest'

Внезапно, опять нифига! Что, вообще-то, логично. LXC-контейнеры хотят cgroups, которых у нас и нет. Необходимо смонтировать файловую систему cgroup. Добавляем строчку про cgroups в /etc/fstab, монтируем их, проверяем:

[root@serv lxc-1.0.0]# mkdir -p /cgroup
[root@serv lxc-1.0.0]# cat /etc/fstab
…
cgroup /cgroup cgroup defaults 0 0
[root@serv lxc-1.0.0]# mount -t cgroup cgroup /cgroup
[root@serv lxc-1.0.0]# mount
…
cgroup on /cgroup type cgroup (rw)

Пробуем опять взлететь:

[root@serv ~]# lxc-start -n busytest
udhcpc (v1.15.1) started
Sending discover…
Sending select for 192.166.66.67…
Lease of 192.166.66.67 obtained, lease time 1800 Please press Enter to activate this console. # uname -a
uname -a
Linux busytest 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 66 66:66:66 UTC 2066 x86_64 x86_64 x86_64 GNU/Linux # ip addr show eth0
ip addr show eth0
7: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 22:a1:c1:83:7b:17 brd ff:ff:ff:ff:ff:ff inet 192.166.66.67/24 brd 192.166.66.255 scope global eth0 # halt
halt
The system is going down NOW!
Sent SIGTERM to all processes
Terminated
Sent SIGKILL to all processes
Requesting system halt

Внезапно, работает. Теперь попробуем создать контейнер с, например, Ubuntu. Его шаблон не работает на RHEL/CentOS, но чуваки с linuxcontainers.org раздают уже подготовленные rootfs для различных операционных систем. Скачивание обеспечивается шаблоном download (размер rootfs от Ubuntu Precise 64bit — примерно 56 Mb), создадим контейнер с его помощью:

[root@serv lxc-1.0.0]# lxc-create -t download -n ubuntu
Setting up the GPG keyring
Downloading the image index
—
DIST RELEASE ARCH VARIANT BUILD
—
centos 6 amd64 default 20140222_02:17
centos 6 i386 default 20140222_02:17
debian jessie amd64 default 20140221_22:43
debian jessie armel default 20140220_22:43
debian jessie armhf default 20140220_22:43
debian jessie i386 default 20140221_22:43
debian sid amd64 default 20140221_22:43
debian sid armel default 20140220_22:43
debian sid armhf default 20140219_22:43
debian sid i386 default 20140221_22:43
debian wheezy amd64 default 20140221_22:43
debian wheezy armel default 20140220_22:43
debian wheezy armhf default 20140220_22:43
debian wheezy i386 default 20140221_22:43
fedora 19 amd64 default 20140222_01:28
fedora 19 i386 default 20140222_01:28
fedora 20 amd64 default 20140222_01:28
fedora 20 armhf default 20140222_01:28
fedora 20 i386 default 20140222_01:28
gentoo current amd64 default 20140128_14:35
gentoo current armhf default 20140128_14:35
gentoo current i386 default 20140128_14:35
oracle 6.5 amd64 default 20140222_11:41
oracle 6.5 i386 default 20140222_11:41
plamo 5.x amd64 default 20140221_21:37
plamo 5.x i386 default 20140221_21:37
ubuntu lucid amd64 default 20140222_03:50
ubuntu lucid i386 default 20140222_03:50
ubuntu precise amd64 default 20140222_03:50
ubuntu precise armel default 20140222_03:50
ubuntu precise armhf default 20140222_03:50
ubuntu precise i386 default 20140222_03:50
ubuntu quantal amd64 default 20140222_03:50
ubuntu quantal armel default 20140222_03:50
ubuntu quantal armhf default 20140222_03:50
ubuntu quantal i386 default 20140222_03:50
ubuntu saucy amd64 default 20140222_03:50
ubuntu saucy armhf default 20140222_03:50
ubuntu saucy i386 default 20140222_03:50
ubuntu trusty amd64 default 20140222_03:50
ubuntu trusty armhf default 20140222_03:50
ubuntu trusty i386 default 20140222_03:50
—
Distribution: ubuntu
Release: precise
Architecture: amd64 Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs
—
You just created an Ubuntu container (release=precise, arch=amd64).
The default username/password is: ubuntu / ubuntu
To gain root privileges, please use sudo.

Читайте также:  Настройка mikrotik контроллера capsman для бесшовного wifi роуминга на примере routerboard 2011uias-2hnd-in

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

[root@serv ~]# lxc-start -n ubuntu
…много всего…
init: failsafe main process (128) killed by TERM signal
init: setvtrgb main process (381) terminated with status 1 Ubuntu 12.04.4 LTS ubuntu console ubuntu login: ubuntu
Password:
Welcome to Ubuntu 12.04.4 LTS (GNU/Linux 2.6.32-431.el6.x86_64 x86_64)
ubuntu@ubuntu:~$ ip addr show eth0
11: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether d6:64:e3:b6:4e:43 brd ff:ff:ff:ff:ff:ff inet 192.166.66.68/24 brd 192.166.66.255 scope global eth0

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

lxc-start -n имя-контейнера -d

К консоли контейнера можно присоединится (ctrl-a + q для отсоединения):

lxc-console -n имя-контейнера

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

lxc-attach -n имя-контейнера

Можно узнать некоторую информацию о контейнере, включая его IP адрес:

lxc-info -n имя-контейнера

Можно остановить контейнер как из самого контейнера (shutdown -h, halt) или корректно остановить контейнера из хоста:

lxc-stop -n имя-контейнера

Если контейнер завис, можно грубо убить контейнера из хоста (убивается init-процесс контейнера):

lxc-stop -n имя-контейнера -k

Можно получить список всех созданных (запущеных и остановленых) контейнеров в системе:

lxc-ls

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

Пыщь! Оригинал поста размещен в блоге Ад, ненависть и локалхост. Комментить? Набигай. Подкат? ОИНЧ.

Источник: https://nefigtut.livejournal.com/28321.html

Установка Redmine в изолированном контейнере LXC

Redmine – гибкий инструмент позволяющий удобно организовывать проекты и задачи, а также отслеживать ошибки. Написан он на Ruby и использует известный фреймворк Ruby on Rails. GNU GPL, Open Source и все дела… (В вики более подробно)

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

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

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

Чтобы минимизировать вред для вашей системы и упростить процесс обновления, бэкапа, а также разворачивания тестовых окружений я использую контейнеры LXC. Сам набор утилит уже умеет создавать “клоны” систем, используя простое копирование или более продвинутые методы типа снапшотов BTRFS или LVM.

Установка LXC

yum install lxc lxc-templates libvirt libvirt-python

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

service libvirtd start

По умолчанию, в качестве места установки будет использоваться /var/lib/lxc Если необходимо добавить там места или вынести на отдельный диск, раздел или планету, лучше сделать это сейчас.

VMSNAME=PlzKillMe #Имя контейнера
TEMPLATE=centos #Шаблон будущей системы
LXCPATH=/var/lib/lxc #Место хранения образов
REL=6 #Релиз CentOS
lxc-create -n $VMSNAME -t $TEMPLATE -P $LXCPATH — –release=$REL

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

—
The temporary root password is stored in: '/var/lib/lxc/PlzKillMe/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/PlzKillMe/rootfs passwd
—

Можно запустить контейнер:

lxc-start -d -n $VMSNAME

Установка Ruby

Через некоторое время после старта узнаём адрес контейнера

IP=$(lxc-info -n $VMSNAME | grep IP | awk '{print $2}') && echo $IP

И подключаемся к этому контейнеру (пароль в файле, если не меняли)

ssh root@$IP

“Кристаллики” будем ставить с помощью rvm Устанавливаем нужные пакеты

yum install which tar

После чего следуем официальной документации (Эти команды могут устареть, сравните с оффдоками)

gpg –keyserver hkp://keys.gnupg.net –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
сurl -sSL https://get.rvm.io | bash -s stable
source /etc/profile.d/rvm.sh

Устанавливаем последний релиз Ruby

rvm install ruby

Готово! Проверяем

ruby -v

Получение и установка Redmine

rpm -ivh http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
yum install epel-release -y
yum install wget nginx ImageMagick-devel mysql-server mysql-devel libcurl-devel

Качаем последнюю версию RM по ссылке

cd /opt/
wget http://www.redmine.org/releases/redmine-3.0.1.tar.gz
tar xf redmine-3.0.1.tar.gz
ln -s redmine-3.0.1 redmine
adduser redmine

Далее следуем официальной документации

cd /opt/redmine/
gem install bundler mysql2
bundle install –without development test

Настройку сервера БД я оставлю на ваше усмотрение, данные остается только прописать в config/database.yml В этом примере я буду использовать дефолтный сервер CentOS с правами доступа по умолчанию.

cp config/database.yml.example config/database.ymlservice mysqld start
mysql -e “create database redmine character set utf8;”
rake generate_secret_token
RAILS_ENV=production rake db:migrate
RAILS_ENV=production rake redmine:load_default_data
chown redmine:nginx -R files/ log/ tmp/ public/plugin_assets

На этом установка и базовая настройка окончена, теперь попробуем запустить сервер:

ruby bin/rails server webrick -e production

Эта строка будет означать успешный запуск:

[2015-03-24 10:50:49] INFO WEBrick::HTTPServer#start: pid=24657 port=3000

Установка Nginx с модулем Passenger

Для запуска RoR приложений будем использовать Passenger

gem install passenger
passenger-install-nginx-module

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

После сборки готовый к работе Nginx будет находится в /opt/nginx, нам лишь остаётся запускать его системным init скриптом от нашего старого nginx. Немного подправим файл с настройками /etc/sysconfig/nginx к следующему виду:

NGINX=/opt/nginx/sbin/nginx
CONFFILE=/opt/nginx/conf/nginx.conf
PIDFILE=/opt/nginx/logs/nginx.pid

Попробуем запустить?

service nginx start

Если всё хорошо, и сервер запустился, то добавляем в конфиг /opt/nginx/conf/nginx.conf следующие настройки:

passenger_log_level 5;
passenger_debug_log_file /opt/nginx/logs/passenger.log;
server { listen 80; server_name redmine.myhost.ru; client_max_body_size 128m; root /opt/redmine/public/; passenger_user redmine; passenger_group nginx; passenger_enabled on; passenger_min_instances 1;
}
passenger_pre_start http://redmine.myhost.ru/;

!! Отредактируйте опции в соответствии с вашими условиями. !!

Перезапускаем Nginx и получаем на $IP:80 ваш любимый RM. У меня всё. Дальше вы настраиваете проксирование трафика с хоста в гостя как вам удобнее (haproxy, nginx и т.п.) По умолчанию для входа используются admin/admin

Источник: https://srv-nix.com/linux/2015/03/24/redmine-centos.html

Как установить много Linux в одном дистрибутиве с помощью LXC

(Linux Containers) — легкая и простая в использовании система виртуализации, позволяющая одновременно использовать несколько изолированных друг от друга операционных систем на одном компьютере.

Отличается LXC от других систем виртуализации (VirtualBox, KVM, Vmware) тем, что гостевые операционные системы работают на том же ядре, что и основная система (host), виртуальная машина при этом не используется, что позволяет существенно экономить ресурсы и получить полностью изолированные экземпляры операционных систем.

Как установить LXC

Откройте терминал и впишите следующие команды:

sudo apt-get install lxc lxctl lxc-templates
sudo lxc-checkconfig

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

Создание контейнера с операционной системой в LXC

Проще всего воспользоваться готовыми шаблонами lxc-templates, которые содержат все необходимые сведения для установки Ubuntu, Debian, Fedora, openSUSE, Gentoo и других дистрибутивов. Полный список поддерживаемых систем можно посмотреть следующей командой в терминале:

ls /usr/share/lxc/templates/

Создается контейнер всего одной командой. Например, установка Ubuntu в LXC выполняется так:

lxc-create -n ubuntu01 -t ubuntu

Где опция -n отвечает за имя контейнера, а -t — за используемый шаблон. Далее LXC скачает и установит нужные ISO и пакеты. Вмешательство пользователя не требуется. В заключении пользователю будет сообщен пароль для входа в установленную систему (в данном случае: ubuntu/ubuntu).

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

Когда контейнер с системой готов, можно перейти к его запуску. Для этого введите следующие команды:

lxc-start -n ubuntu01 -d
lxc-console -n ubuntu01

Легко догадаться, что lxc-star запускает контейнер, а lxc-console открывает консоль управления к нему. Останавливаются контейнеры командой lxc-stop:

Установить можно любое количество операционных систем. Сколько из них сможет работать одновременно зависит только от количества свободных ресурсов компьютера.

Преимущества использования LXC

Помимо основного предназначения — создания изолированных сред — LXC позволяет использовать все преимущества виртуализации. А именно:

Клонирование операционных систем

lxc-stop -n ubuntu01
lxc-clone ubuntu01 ubuntu02

Создание снэпшотов (снимков)

Снэпшот позволяет зафиксировать текущее состояние операционной системы в контейнере и легко к нему вернуться, если что-то пойдет не так:

lxc-stop -n ubuntu01
lxc-snapshot -n ubuntu01

Управление контейнерами дистанционно, через web-интерфейс

Для этого потребуется установить lxc-webpanel:

wget http://lxc-webpanel.github.io/tools/install.sh -O – | bash

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

Источник: http://liberatum.ru/exclusive/lxc-linux-containers

LXC Linux Containers часть №2. Установка

Одно из главных преимуществ LXC, это присутствие его базовых блоков (cgroups и namespaces) практически во всех современных ядрах Linux.

Это означает что нет необходимости что-то компилировать или использовать стороннее ядро, как в случае с OpenVZ. Единственное, что необходимо установить, это пакет утилит управления. В моем случае использовался Ubuntu Linux 13.

10 как дистрибутив с наиболее свежей пакетной базой. Все проделанные в этой статье манипуляции будут проводиться на его примере.

Я не стану описывать процесс установки этого дистрибутива, так как он примитивен и не требует пояснений. Единственное, о чем стоит сказать, так это о разметке и распределении пространства на жестких дисках. По умолчанию каталог в котором будут храниться контейнеры и их конфигурация монтируется в /var/lib/lxc.

Так же, в директорию /var именно в /var/cache/lxc помещается кэш шаблонов. По этому, при установке, имеет смысл указать для этой точки монтирования, отдельный раздел, жесткий диск или RAID-массив достаточного объема. Параметры монтирования для указанных каталогов LXC можно будет изменить и после установки системы, но лучше об этом задуматься сразу.

Читайте также:  Zabbix: init_cpu_collector(): cannot make counterpath

Объем одного контейнера составляет примерно 250-300 Мб на диске.

Рис 1. Пример разметки дисков

На рисунке 1, раздел, выделенный для директории /var, находится на отдельном диске и отформатирован в файловую систему Btrfs. Этот выбор не случаен. Утилиты LXC совместимы с Btrfs и способна ее средствами создавать моментальные снимки файловой системы и отдельных контейнеров в частности. Такая техника позволяет выполнять быстрое клонирование и резервное копирование с помощью снапшотов.

После того как система установлена и настроена сеть, можно приступать к установке LXC.

Далее по тексту подразумевается, что вы используете Ubuntu. Для получения последних, ежедневно обновляемой версий LXC для Ubuntu 12.04, 12.10, 13.04, 13.10, 14.04 можно использовать PPA-репозиторий:

$ sudo apt-add-repository -y ppa:ubuntu-lxc/daily$ sudo apt-get update –quiet

И устанавливаем :

$ sudo apt-get install lxc

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

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

/var/lib/lxc/ — хранилище контейнеров по умолчанию.
/var/lib/lxcsnap/ — хранилище снимков.
/var/cache/lxc/ — пакетная база шаблонов.
/etc/default/lxc — конфигурационный файл LXС.
/etc/default/lxc-net — в этом файле задается конфигурация моста LXC (lxcbr0), его IP-аддрес и прочие параметры,
/etc/lxc/default.

conf — если при создании нового контейнера не указывается конфигурационный файл, будет использоваться этот.
/usr/share/lxc/templates/ — каталог с шаблонами различных дистрибутивов, которые могут быть использованы при создании новых контейнеров.
/etc/apparmor.

d/lxc/lxc-default — здесь задается профиль доступа Apparmor по умолчанию, который обеспечивает защиту хост-системы от контейнеров.

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

lxcbr0 создается в процессе старта хост-системы. За это отвечает параметр USE_LXC_BRIDGE имеющий значение true в файле /etc/default/lxc-net. Этому мосту по умолчанию устанавливается частный IP-адрес 10.0.3.

1, а контейнеры его использующие получат адреса из это го же диапазона 10.0.3.0/24. Если, в системе присутствует другой мост, то его можно указать в конфигурационном файле контейнера или в конфигурации контейнера по умолчанию /etc/lxc/default.conf параметр lxc.network.link.

Далее, сетевая конфигурация будет разобрана более подробно.

Источник: https://ivirt-it.ru/lxc-linux-containers-install/

Setup LXC Container with Gitlab

Here is a simple step by step manual to setup an LXC Container with GitLab Community Edition on Ubuntu Server LTS 14.04.

Links:

Install LXC

sudo apt-get update && apt-get install bridge-utils lxc

Create an LXC Container from a template

lxc-create -t ubuntu -n gitlabLXC

This will create a new Container located under /var/lib/lxc/. Important to note is the default username and password:

# The default user is 'ubuntu' with password 'ubuntu'! # Use the 'sudo' command to run tasks as root in the container.

List all LXC Containers:

lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ——————————————————- ELKStack RUNNING 192.168.xx.xx – YES gitlabLXC STOPPED – – NO https://help.ubuntu.com/lts/serverguide/network-configuration.html#bridging
or read under “Host device as bridge” => https://wiki.debian.org/LXC/SimpleBridge

Configure the LXC Container network (/var/lib/lxc/gitlabLXC/config):

# Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu # Parameters passed to the template: # For additional config options, please look at lxc.container.conf(5) # Common configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf # Container specific configuration lxc.rootfs = /var/lib/lxc/gitlabLXC/rootfs lxc.mount = /var/lib/lxc/gitlabLXC/fstab lxc.utsname = gitlabLXC lxc.arch = amd64 # Network configuration lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0
lxc.network.hwaddr = 00:16:3e:0e:d8:af lxc.network.ipv4 = 192.168.xx.xx/24
lxc.network.ipv4.gateway = 192.168.xx.xx
# Autostart (optional)
lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 103

The ipv4 is your static ip and gateway is your networks gateway (the same as the host uses). change also the link to br0 in reference to your hosts network interface as configured before.

The section Autostart is optional. if you add this lines the LXC Container will start automatically if your host reboots or starts.

Now it’s time to start our “gitlabLXC” Container:

lxc-start -n gitlabLXC -d

Check if the Container runs:

lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ———————————————————————– ELKStack RUNNING 192.168.xx.xx – YES gitlabLXC RUNNING 192.168.xx.xx, 192.168.xx.xx – YES

Yes the Container is running… but there are two IP addresses?

This is because of the bridged network and the standard configuration of the LXC “ubuntu” templates. The network interface in the LXC itself is set to DHCP. So the Container received a second IP address. This is easy to fix. Login to the Container:

lxc-console -n gitlabLXC -e q

With this command you will receive the Login from the LXC Container:

Ubuntu 14.04.4 LTS gitlabLXC tty1 gitlabLXC login: You can logout/switch back to the host with this: Type to exit the console, to enter Ctrl+q itself

ok so now login with ubuntu/ubuntu and type:

Источник: https://www.supportblog.ch/setup-lxc-container-with-gitlab/

GitLab: перенос данных с omnibus-установки в docker-установку

GitLab — одна из самых популярных систем контроля версий и управления Git-репозиториями с открытым исходным кодом и очень широкой функциональностью. Процесс установки GitLab (будь-то omnibus, docker или готовая виртуальная машина) хорошо задокументирован, поэтому рассматривать мы его не будем.

В данной статье подробно разберем пример переезда GitLab с omnibus-установки в docker-установку с сохранением всех данных — репозиториев, мерджей, комментариев, артефактов и билдов (если такие есть). Давайте разберемся!

Итак, имеем неактуальную omnibus-установку GitLab из пакета gitlab-ce_8.10.10-ce.0_amd64.deb. Хотим получить актуальную версию (8.17.2), установленную в docker-контейнере, для простоты обновления в будущем.

Сначала делаем резервную копию omnibus-установки GitLab:

sudo gitlab-rake gitlab:backup:create

По умолчанию резервная копия будет создана в каталоге /var/opt/gitlab/backups.

Из docker-образа устанавливаем GitLab той же версии, что и в omnibus-установке:

sudo docker run -d -h gitlab.example.com –name gitlab –restart always -p 10080:80 -p 10022:22 -v /data/gitlab/config:/etc/gitlab -v /data/gitlab/logs:/var/log/gitlab -v /data/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:8.10.10-ce.0

После запуска контейнера в хост-системе будет автоматически создан каталог /data/gitlab/data. Переходим в него, создаем папку backups и копируем туда только что созданную резервную копию:

cd /data/gitlab/data && mkdir backups
cp /var/opt/gitlab/backups/1924945297_gitlab_backup.tar /data/gitlab/data/backups

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

sudo docker exec -it gitlab bash
chmod 600 /var/opt/gitlab/backups/1924945297_gitlab_backup.tar
chown git:git /var/opt/gitlab/backups/1924945297_gitlab_backup.tar

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

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-rake gitlab:backup:restore BACKUP=1924945297
gitlab-ctl start
gitlab-rake gitlab:check SANITIZE=true

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

Останавливаем и удаляем docker-контейнер с GitLab:

sudo docker stop gitlab && sudo docker rm gitlab

Запускаем docker-контейнер с актуальной версией GitLab и подсовываем ему нужные данные:

sudo docker run -d -h gitlab.example.com –name gitlab –restart always -p 10080:80 -p 10022:22 -v /data/gitlab/config:/etc/gitlab -v /data/gitlab/logs:/var/log/gitlab -v /data/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:8.17.2-ce.0

При первом запуске все необходимые процедуры обновления запустятся самостоятельно (занимают буквально пару минут). После этого можно удалять старую omnibus-установку:

sudo dpkg -r gitlab

или:

sudo aptitude purge gitlab-ce

И не забыть потом удалить данные из старых рабочих каталогов Gitlab:

sudo rm -rf /var/opt/gitlab/
sudo rm -rf /opt/gitlab

В дальнейшем вся процедура обновления Gitlab сводится к обновлению docker-контейнера.

Источник: https://letsclearitup.com.ua/ubuntu/gitlab-perenos-dannyih-s-omnibus-ustanovki-v-docker-ustanovku.html

LXC 1.0: Первый Ubuntu контейнер

Статья 1 из 10, в которой речь пойдёт об LXC и создании первого контейнера.

Что такое LXC?

LXC – интерфейс в пользовательском пространстве для работы с контейнерами, реализованные в ядре Linux. Мощный API и простые инструменты позволяют линукс пользователям легко создавать и управлять контейнерами.

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

ГитХаб проекта: http://github.com/lxc
Веб сайт: http://linuxcontainers.org
Почтовая рассылка: http://lists.linuxcontainers.org

LXC 1.0

LXC 1.0 – первый, реально стабильный релиз LXC, который будет поддерживаться 5 лет и будет поставляться с Ubuntu 14.04 LTS, выходящая в апреле 2014 года.

LXC 1.0 будет идти с:

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

Как получить LXC?

Ради справки, стоит знать, что LXC в Ubuntu, начиная с 12.04. Сейчас речь пойдёт о получении более новых версий.

Подразумевается далее по тексту, что вы используете Ubuntu. Для получения последних версий LXC для Ubuntu 12.04, 12.10, 13.04, 13.10, 14.04 можно использовать PPA https://launchpad.net/~ubuntu-lxc/+archive/daily

Если вы по непонятной причине не хотите использовать deb пакеты с дневными билдами и хотите самостоятельно скомпилировать нужное, хотя это не рекомендуется в linux системах с пакетным менеджментом, то на свой страх и риск:
git clone git://github.com/lxc/lxc
cd lxc
sh autogen.sh
./configure
make
sudo make install

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

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

Создаём контейнер p1, используя шаблон ubuntu и такую же архитектуру и версию как и хост. Использование “– –help” выведет список всех доступных опций.
sudo lxc-create -t ubuntu -n p1

Запуск контейнера в фоне.
sudo lxc-start -n p1 -d

Читайте также:  Asterisk - sip атс для офиса, пошаговая инструкция по настройке с нуля

Вход в контейнер одним из различных путей:

  • Присоединение к консоли контейнера (ctrl-a + q для отсоединения)sudo lxc-console -n p1
  • Запуск bash напрямую в контейнере, минуя логин. Требуется ядро >= 3.8.sudo lxc-attach -n p1

SSH в контейнер. Логин ubuntu, пароль ubuntu.
sudo lxc-info -n p1
ssh ubuntu@IP-из-lxc-info

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

  • Остановка контейнера из самого контейнера.sudo poweroff
  • Корректная остановка контейнера из хоста.sudo lxc-stop -n p1
  • Грубое убийство контейнера из хоста.sudo lxc-stop -n p1 -k

Вот и готов первый контейнер. Как и обещано, в Ubuntu – всё просто! Ядра обладают поддержкой всего что нужно для LXC и контейнер использует bridge и DHCP по умолчанию. Естественно, всё можно изменить и настроить под свои нужды, но это в следующих статьях.

Стефан Грабер рассказывает о планах и датах LXC 1.0.

Продолжение LXC 1.0: Второй контейнер.

Дополнительные материалы:
Серия статей LXC 1.0 от Стефана Грабера.
LXC и Vagrant. 13 причин использовать Ubuntu Server. Часть 3.
Вход в систему Unity Greeter может аутентифицировать в системе, находящейся в LXC контейнере.

Источник: https://programming086.blogspot.com/2014/01/lxc-1-0-first-ubuntu-container.html

GitLab Docker images

Both GitLab CE and EE are in Docker Hub:

  • GitLab CE Docker image
  • GitLab EE Docker image

The GitLab Docker images are monolithic images of GitLab running all the necessary services on a single container.

In the following examples we are using the image of GitLab CE. To use GitLab EE instead of GitLab CE, replace the image name to gitlab/gitlab-ee:latest.

If you want to use the latest RC image, use gitlab/gitlab-ce:rc or gitlab/gitlab-ee:rc for GitLab CE and GitLab EE respectively.

The GitLab Docker images can be run in multiple ways:

Prerequisites

Docker installation is required, see the official installation docs.

Note: Using a native Docker install instead of Docker Toolbox is recommended in order to use the persisted volumes

Warning: We do not officially support running on Docker for Windows. There are known issues with volume permissions, and potentially other unknown issues. If you are trying to run on Docker for Windows, please see our getting help page for links to community resources (IRC, forum, etc) to seek help from other users.

Run the image

Run the image:

sudo docker run –detach –hostname gitlab.example.com –publish 443:443 –publish 80:80 –publish 22:22 –name gitlab –restart always –volume /srv/gitlab/config:/etc/gitlab –volume /srv/gitlab/logs:/var/log/gitlab –volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest

This will download and start a GitLab CE container and publish ports needed to access SSH, HTTP and HTTPS. All GitLab data will be stored as subdirectories of /srv/gitlab/. The container will automatically restart after a system reboot.

You can now login to the web interface as explained in After starting a container.

If you are on SELinux then run this instead:

sudo docker run –detach –hostname gitlab.example.com –publish 443:443 –publish 80:80 –publish 22:22 –name gitlab –restart always –volume /srv/gitlab/config:/etc/gitlab:Z –volume /srv/gitlab/logs:/var/log/gitlab:Z –volume /srv/gitlab/data:/var/opt/gitlab:Z gitlab/gitlab-ce:latest

This will ensure that the Docker process has enough permissions to create the config files in the mounted volumes.

Where is the data stored?

The GitLab container uses host mounted volumes to store persistent data:

Local locationContainer locationUsage
/srv/gitlab/data /var/opt/gitlab For storing application data
/srv/gitlab/logs /var/log/gitlab For storing logs
/srv/gitlab/config /etc/gitlab For storing the GitLab configuration files

You can fine tune these directories to meet your requirements.

Configure GitLab

This container uses the official Omnibus GitLab package, so all configuration is done in the unique configuration file /etc/gitlab/gitlab.rb.

To access GitLab’s configuration file, you can start a shell session in the context of a running container. This will allow you to browse all directories and use your favorite text editor:

sudo docker exec -it gitlab /bin/bash

You can also just edit /etc/gitlab/gitlab.rb:

sudo docker exec -it gitlab vi /etc/gitlab/gitlab.rb

Once you open /etc/gitlab/gitlab.rb make sure to set the external_url to point to a valid URL.

To receive e-mails from GitLab you have to configure the SMTP settings because the GitLab Docker image doesn’t have an SMTP server installed.

You may also be interested in Enabling HTTPS.

After you make all the changes you want, you will need to restart the container in order to reconfigure GitLab:

sudo docker restart gitlab

Note: GitLab will reconfigure itself whenever the container starts.

For more options about configuring GitLab please check the Omnibus GitLab documentation.

Pre-configure Docker container

You can pre-configure the GitLab Docker image by adding the environment variable GITLAB_OMNIBUS_CONFIG to docker run command. This variable can contain any gitlab.rb setting and will be evaluated before loading the container’s gitlab.rb file. That way you can easily configure GitLab’s external URL, make any database configuration or any other option from the Omnibus GitLab template.

Note: The settings contained in GITLAB_OMNIBUS_CONFIG will not be written to the gitlab.rb configuration file, they’re evaluated on load.

Here’s an example that sets the external URL and enables LFS while starting the container:

sudo docker run –detach –hostname gitlab.example.com –env GITLAB_OMNIBUS_CONFIG=”external_url 'http://my.domain.com/'; gitlab_rails['lfs_enabled'] = true;” –publish 443:443 –publish 80:80 –publish 22:22 –name gitlab –restart always –volume /srv/gitlab/config:/etc/gitlab –volume /srv/gitlab/logs:/var/log/gitlab –volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest

Note that every time you execute a docker run command, you need to provide the GITLAB_OMNIBUS_CONFIG option. The content of GITLAB_OMNIBUS_CONFIG is not preserved between subsequent runs.

There are also a limited number of environment variables to configure GitLab. They are documented in the environment variables section of the GitLab documentation.

After starting a container

After starting a container you can visit http://localhost/ or http://192.168.59.103 if you use boot2docker. It might take a while before the Docker container starts to respond to queries.

Note: The initialization process may take a long time. You can track this process with the command sudo docker logs -f gitlab

The very first time you visit GitLab, you will be asked to set up the admin password. After you change it, you can login with username root and the password you set up.

Upgrade GitLab to newer version

To upgrade GitLab to a new version you have to:

  1. Stop the running container:

  2. Remove existing container:

  3. Pull the new image:

    sudo docker pull gitlab/gitlab-ce:latest

  4. Create the container once again with previously specified options:

    sudo docker run –detach –hostname gitlab.example.com –publish 443:443 –publish 80:80 –publish 22:22 –name gitlab –restart always –volume /srv/gitlab/config:/etc/gitlab –volume /srv/gitlab/logs:/var/log/gitlab –volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest

On the first run, GitLab will reconfigure and update itself.

Источник: https://docs.gitlab.com/omnibus/docker

LXC: Kонтейнерные утилиты Linux

Обзор и установка новых контейнерных утилит Linux® Containers

Мэт Хэлсли
Опубликовано 14.07.2009

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

В отличие от виртуализации, здесь не требуется ни эмуляция на командном уровне, ни компиляция “на лету” (just-in-time compilation). Контейнеры могут исполнять прямые процессорные команды, не прибегая к механизмам интерпретации.

Также отпадают сложности паравиртуализации и преобразования системных вызовов.

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

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

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

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

Контейнерные технологии существуют уже довольно продолжительное время. В качестве примеров контейнеров из других Unix-систем следует назвать Solaris Zones и BSD jails.

У контейнерных технологий в Linux также давние традиции: Linux-Vserver, OpenVZ и FreeVPS.

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

В статье Сержа Халлина (Serge Hallyn) “Модули безопасности Linux: Рецепты для работы с контейнерами” (developerWorks, февраль 2009 г.), рассказывается, как можно усилить безопасность легких контейнеров с помощью политик SELinux и Smack. Подробности об этих технологиях ищите в Ресурсах.

Проект Linux Resource Containers (который разрабатывается и поддерживается специалистом IBM Дэниелом Лезкано (Daniel Lezcano); см.

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

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

Для лучшего понимания статьи необходимо уверенно чувствовать себя в командной строке в работе с такими программами, как make, gcc, и patch, а также быть знакомым с процессом распаковки тарболов (файлов с расширением .tar.gz).

Получение, сборка и установка LXC

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

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

Источник: https://www.ibm.com/developerworks/ru/library/l-lxc-containers/

Оценка статьи:
1 звезда2 звезды3 звезды4 звезды5 звезд (нет голосов)
Загрузка...
Поделиться с друзьями:
Ссылка на основную публикацию
Похожие публикации