Linux-контейнеры дома: зачем и как




    Рассуждения


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

    Дома, на личных компьютерах многие используют виртуальные машины: в основном, пожалуй, Virtualbox. Как правило, для того, чтобы работая под Linux, иметь под рукой Windows или наоборот. Однако, при наличии множества родственных Linux-операционок, я стал замечать, что использование виртуальных машин — это, мягко говоря, нерационально.

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

    Во вторую — это больший расход оперативной памяти. В третью — не самые удобные инструменты взаимодействия…

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

    Что такое контейнеры и чем это все отличается от виртуализации? В случае контейнеров, не создается виртуальное аппаратное окружение, а используется изолированное пространство процессов и сетевого стека. Скажем так, получается chroot с расширенными возможностями.

    Зачем это нужно:

    — Для сборки ПО при нежелании захламлять разномастными *-dev пакетами основную рабочую систему.
    — Потребность в другом дистрибутиве для запуска каких-либо специфических программ и, опять же, сборки.
    — Изоляция потенциально небезопасного софта, вроде того же скайпа совершающего разные непонятные действия в домашнем каталоге пользователя и всяких сомнительных веб-технологий: уязвимость во флеше, в java, в обработчике pdf — это только то, что плавает на поверхности.
    — Анонимность. Эдак можно банально остаться залогиненым в своей любимой социалочке, забыть подчистить куки или оказаться незнакомым с очередной новой веб-технологией вроде этой webrtc. Можно, конечно, держать несколько профилей браузера, но от перечисленных выше дыр и технологий это не защитит.

    Итак, рассмотрим плюсы и минусы LXC:

    + Работает на ванильном ядре
    + Простота проброса устройств и каталогов хоста, так как работает это все через cgroups
    + Очень нетребовательно к ресурсам, в отличии от виртуальных машин типа Virtualbox или qemu

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

    Развертывание и настройка контейнера



    В первую очередь, ставим пакет lxc и все необходимые утилиты:
    sudo apt-get install lxc bridge-utils


    Смотрим доступные группы томов LVM:
    $sudo vgs
      VG         #PV #LV #SN Attr   VSize   VFree
      nethack-vg   1   6   0 wz--n- 119,00g 7,36g
    


    sudo lxc-create -t debian -B lvm --vgname nethack-vg --fssize 2G -n deb_test




    Указываем использовать LVM в качестве системы хранения, Volume Group ( в моем случае — nethack-vg) и размер 2 гигабайта, иначе по умолчанию будет создан одногиговый том. Хотя, если вдруг стало тесновато, можно будет сделать lvresize.

    Смотрим:



    $sudo lvs
      LV   VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      deb_test nethack-vg -wi-ao----   2,00g
      home     nethack-vg -wi-ao----  93,09g
      root     nethack-vg -wi-ao----   8,38g
      tmp      nethack-vg -wi-ao---- 380,00m
      var      nethack-vg -wi-ao----   2,79g
      vm       nethack-vg -wi-ao----   5,00g
    


    Видим, что у нас появился том deb_test.

    Типовой конфиг, созданный скриптом:
    /var/lib/lxc/deb_test/config

    # Template used to create this container: /usr/share/lxc/templates/lxc-debian
    # Parameters passed to the template:
    # For additional config options, please look at lxc.container.conf(5)
    lxc.rootfs = /dev/nethack-vg/deb_test
    
    # Common configuration
    lxc.include = /usr/share/lxc/config/debian.common.conf
    
    # Container specific configuration
    lxc.mount = /var/lib/lxc/deb_test/fstab
    lxc.utsname = deb_test
    lxc.arch = amd64
    lxc.autodev = 1
    lxc.kmsg = 0
    




    Стартуем:
    sudo lxc-start -n deb_test



    Залогинимся с указанным паролем. Для запуска в headless-режиме используется ключ -d, а рутовую консоль можно получить с помощью команды

    sudo lxc-attach -n deb_test


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

    На хосте прописываем в /etc/network/interfaces
    auto lo br0
    
    iface br0 inet static
       address 172.20.0.1
       netmask 255.255.255.0
       pre-up  /sbin/brctl addbr br0
       post-up /sbin/brctl setfd br0 0
       post-up iptables -t nat -A POSTROUTING -s 172.20.0.0/24 -j MASQUERADE
       post-up echo 1 > /proc/sys/net/ipv4/ip_forward
       pre-down /sbin/brctl delbr br0
    


    В конфиг контейнера дописываем:
    lxc.network.type = veth
    lxc.network.flags = up
    lxc.network.link = br0
    lxc.network.hwaddr = 00:01:02:03:04:05
    


    Понятно, что mac-адрес произвольный, на любой вкус.
    Чтобы сразу получить рабочую сеть и возможность установки пакетов apt'ом, допишем
    lxc.network.ipv4 = 172.20.0.3
    lxc.network.ipv4.gateway = 172.20.0.1
    

    И выполним
    echo "nameserver 192.168.18.1">/etc/resolv.conf


    Понятно, что 192.168.18.1 — IP моего DNS.

    Установим нужные пакеты:
    #apt-get install vim openvpn zsh iftop


    Дальше либо на хосте, либо на другой рабочей виртуалке можно получить список установленных пакетов и установить их все в нашем новом контейнере:
    scp user@172.20.0.2:/etc/apt/sources.list /etc/apt/
    scp -r user@172.20.0.2:/etc/apt/sources.list.d /etc/apt/
    apt-get update
    ssh user@172.20.0.2 'dpkg --get-selections|grep -v deinstall'|dpkg --set-selections
    apt-get dselect-upgrade
    


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

    /etc/network/interfaces:
    auto lo eth0
    iface lo inet loopback
    
    iface eth0 inet static
    address 172.20.0.3
    netmask 255.255.255.0
    gateway 172.20.0.1
    dns-nameservers 192.168.18.1
    


    Впрочем, это можно было сделать с хост-системы, например, смонтировав логический том. Способов много.

    В принципе, в качестве DNS можно указать любой публичный, если не опасаетесь за свою приватность. Например, гугловские 8.8.8.8 и 8.8.4.4.

    По доступу к устройствам хост-системы, я придерживаюсь политики «все, что не разрешено, запрещено». Добавим для этого следующую строчку в конфиг:
    lxc.cgroup.devices.deny = a
    


    Удаляем
    lxc.include = /usr/share/lxc/config/debian.common.conf


    Попробуем подключиться через OpenVPN. Сразу же получаем ошибку:
    Thu Oct 15 16:39:33 2015 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
    Thu Oct 15 16:39:33 2015 Exiting due to fatal error
    




    Система пишет, что интерфейсы TUN/TAP недоступны по причине их отсутствия. Очевидно, что нужно разрешить гостевой системе использовать устройства хоста. Открываем конфигурационный файл контейнера, /var/lib/lxc/deb_test/config и добавляем туда строчку:
    lxc.cgroup.devices.allow = c 10:200 rwm 
    


    В контейнере выполняем:
    root@deb_test:/# mkdir /dev/net; mknod /dev/net/tun c 10 200
    





    Обратим внимание на 10:200 — это идентификатор типа устройств. Если выполним на хосте:
    $ls -l /dev/net/tun
    crw-rw-rw- 1 root root 10, 200 окт 13 10:30 /dev/net/tun
    


    То увидим идентификаторы 10, 200. По ним и будем ориентироваться, разрешая доступ к устройства, например камере — video0.

    lxc.cgroup.devices.allow = c 81:* rwm
    


    Точно также добавляем остальные нужные устройства:

    # /dev/null and zero
    lxc.cgroup.devices.allow = c 1:3 rwm
    lxc.cgroup.devices.allow = c 1:5 rwm
    # consoles
    lxc.cgroup.devices.allow = c 5:1 rwm
    lxc.cgroup.devices.allow = c 5:0 rwm
    lxc.cgroup.devices.allow = c 4:0 rwm
    lxc.cgroup.devices.allow = c 4:1 rwm
    # /dev/{,u}random
    lxc.cgroup.devices.allow = c 1:9 rwm
    lxc.cgroup.devices.allow = c 1:8 rwm
    lxc.cgroup.devices.allow = c 136:* rwm
    lxc.cgroup.devices.allow = c 5:2 rwm
    # rtc
    lxc.cgroup.devices.allow = c 254:0 rm
    #usb passthrough
    lxc.cgroup.devices.allow = c 189:* rwm
    #video
    lxc.cgroup.devices.allow = c 81:* rwm
    #sound
    lxc.cgroup.devices.allow = c 116:* rwm
    lxc.cgroup.devices.allow = c 14:* rwm
    


    Для функционирования иксов и возможности их проброса через ssh, нужно добавить точку монтирования:
    lxc.mount.entry = /tmp/.X11-unix/X0 tmp/.X11-unix/X0 none bind,optional,create=file
    


    По аналогии можно примонтировать и другие, нужные каталоги и файлы:
    lxc.mount.entry = /home/user/.vim home/user/.vim none bind,optional,create=dir 0 0 
    lxc.mount.entry = /home/user/.vimrc home/user/.vimrc none bind,optional,create=file 0 0 
    


    Для воспроизведения звука, можно разрешить доступ к звуковому устройству, если карта многопоточная (с однопоточной при использовании dmix возникают проблемы с блокировкой):
    lxc.cgroup.devices.allow = c 116:* rwm
    lxc.cgroup.devices.allow = c 14:* rwm
    lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir 0 0 
    


    А можно настроить pulseaudio на воспроизведение звука по сети, как это описано здесь. Кратко:

    Отредактировать на хосте /etc/pulse/default.pa, дописав туда:
    load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;172.20.0.3 auth-anonymous=1
    


    В итоге у нас получается вот такой конфиг:
    /var/lib/lxc/deb_test/config

    lxc.rootfs = /dev/nethack-vg/deb_test
    
    lxc.mount = /var/lib/lxc/deb_test/fstab
    lxc.utsname = deb_test
    lxc.arch = amd64
    lxc.autodev = 1
    lxc.kmsg = 0
    
    lxc.network.type = veth
    lxc.network.flags = up
    lxc.network.link = br0
    lxc.network.hwaddr = 00:01:02:03:04:05
    
    lxc.network.ipv4 = 172.20.0.3
    lxc.network.ipv4.gateway = 172.20.0.1
    
    #deny acces for all devices
    lxc.cgroup.devices.deny = a
    
    # /dev/null and zero
    lxc.cgroup.devices.allow = c 1:3 rwm
    lxc.cgroup.devices.allow = c 1:5 rwm
    # consoles
    lxc.cgroup.devices.allow = c 5:1 rwm
    lxc.cgroup.devices.allow = c 5:0 rwm
    lxc.cgroup.devices.allow = c 4:0 rwm
    lxc.cgroup.devices.allow = c 4:1 rwm
    # /dev/{,u}random
    lxc.cgroup.devices.allow = c 1:9 rwm
    lxc.cgroup.devices.allow = c 1:8 rwm
    lxc.cgroup.devices.allow = c 136:* rwm
    lxc.cgroup.devices.allow = c 5:2 rwm
    # rtc
    lxc.cgroup.devices.allow = c 254:0 rm
    
    #sound
    lxc.cgroup.devices.allow = c 116:* rwm
    lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir 0 0 
    #tun/tap adapters
    lxc.cgroup.devices.allow = c 10:200 rwm 
    #video0
    lxc.cgroup.devices.allow = c 81:* rwm
    lxc.mount.entry = /dev/video0 dev/video0 none bind,optional,create=file
    
    lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
    lxc.mount.entry = /tmp/.X11-unix/X0 tmp/.X11-unix/X0 none bind,optional,create=file
    
    




    Контейнер готов к использованию.

    Использование



    Доустановим, например, i2p с Tor'ом, если не сделали этого ранее, и сходу настроим privoxy:
    wget -q https://geti2p.net/_static/i2p-debian-repo.key.asc -O- | sudo apt-key add -
    echo "deb http://deb.i2p2.no/ jessie main" >/etc/apt/sources.list.d/i2p.list
    echo "deb-src http://deb.i2p2.no/ jessie main" >>/etc/apt/sources.list.d/i2p.list
    apt-get update
    apt-get install privoxy i2p tor
    

    /etc/privoxy/config

    user-manual /usr/share/doc/privoxy/user-manual
    confdir /etc/privoxy
    logdir /var/log/privoxy
    actionsfile user.action      # User customizations
    filterfile default.filter
    filterfile user.filter      # User customizations
    logfile logfile
    listen-address  localhost:8118
    toggle  1
    enable-remote-toggle  1
    enable-remote-http-toggle  1
    enable-edit-actions 1
    enforce-blocks 0
    buffer-limit 4096
    enable-proxy-authentication-forwarding 0
    forwarded-connect-retries  0
    accept-intercepted-requests 0
    allow-cgi-request-crunching 0
    split-large-forms 0
    keep-alive-timeout 5
    tolerate-pipelining 1
    socket-timeout 300
    forward .i2p localhost:4444
    forward-socks5 .onion localhost:9050 .
    




    Запускать графические приложения вроде браузера удобнее всего через ssh:
    ssh -Y 172.20.0.2 "PULSE_SERVER=172.20.0.1 http_proxy=127.0.0.1:8118 chromium"
    





    Также, разумеется, LXC предоставляет средства для клонирования контейнеров и снятия снапшотов.

    Так, например, склонировать контейнер, файловая система которого будет являться LVM-снапшотом можно командой:
    sudo lxc-clone -s -H -o deb_test -L 200M --new deb_test2
    




    Будет создан контейнер deb_test2 с файловой системой, размещенной на LVM-снапшоте размером 200MB (под хранение diff'ов). Это будет точная копия deb_test, над которой можно провести пару экспериментов и, например, безболезненно удалить.

    А вот lxc-snapshot с LVM в качестве хранилища, на версии lxc-1.0.6 почему-то не работает:
    ->sudo lxc-snapshot -n deb_test 
    	lxc_container: deb_test's backing store cannot be backed up.
    	lxc_container: Your container must use another backing store type.
    	lxc_container: Error creating a snapshot
    


    Проблема описывается и обсуждается здесь. Потому, снимки придется делать по старинке:
    sudo lvcreate -L100M -s -n deb_test_before_rm_rf -p r /dev/nethack-vg/deb_test
    


    В данном случае создали read-only снапшот с именем deb_test_before_rm_rf размером 100MB. Что с ним делать дальше? Например, его можно сдампить посредством dd, перенести на другую машину вместе с конфигами контейнера, создать там том нужного размера и пролить тем же dd (cp, cat, итд) — эдакая «живая миграция».

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

    На этом пока все.

    WestComp

    30,48

    WestComp — Вы нас нашли!

    Поделиться публикацией

    Похожие публикации

    Комментарии 84
      +1
      На первый взгляд отличная статья. Спасибо, попробую.
        0
        Спасибо за статью! Один вопрос: зачем вы размещаете изображения для статьи на Хабре на непонятном хостинге (это дурной тон), есть же родной habrastorage.org?
          0
          С habrasorage'ом у меня не самые приятные отношения. Обсуждаемый когда-то на хабре способ загрузки с помощью curl в очередной раз накрылся, я какое-то время поковырял, плюнул и загрузил изображения на другой хостинг.

          Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.
            +9
            Все равно автоматом на habrastoradge перенесет.
              0
              На habrastorage.org все фото переносятся разом в одно движение мышки, что в этом неудобного?
                0
                Попробую объяснить. У нас есть куча картинок. В идеале, их все нужно загрузить скопом, не важно там, мышкой или командой и получить список готовых к вставке html-тегов. Желательно, сразу с превьюшками.

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

                Ладно бы оно нормально работало с curl, скрипт-то сваять не проблема. Но там что-то опять накрутили, и получаем «moved permanetly», что не делай.

                Удобства, как говорится, во дворе. Потому я отдаю предпочтения сервисам, которые не столь параноидальны и позволяют взаимодействовать с собой не только посредством тыканья мышкой в браузере.
            +4
            Прочитал статью, но так и не понял, что же такое контейнерная виртуализация…
              +5
              Ну, на этот счет написано довольно много. Если в двух словах, то контейнеры — это расширенный chroot с изоляцией, в том числе, сетевого стека.
                0
                Вот тут чуть подробнее про контейнерную виртуализацию.
              0
              Так lxc.network.type = empty или veth?

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

              Уже года три смотрю иногда на LXC, оно всё выглядит как очень для энтузиастов.
                0
                В целом да, но его активно поддерживает canonical и api у него более полное и стабильное, чем у docker, при этом оно само не привязано к сторонним сервисам, в отличии от rocket
                  +3
                  Для энтузиастов, говорите? OpenVZ заменили на LXC в недавно вышедшем Proxmox VE 4.0
                    0
                    Да? Пошел смотреть. Как то я новость пропустил.
                      0
                      На это и надежда, что с более широким использованием оно станет таким же понятным и удобным инструментом, как например VirtualBox (мне кажется, во многом поэтому его и используют на декстопе). У самого в планах игры с PVE4.
                        0
                        У которого (PVE4), кстати, свой проблемы. Первая же обновлённая с PVE3 машина не умела создание LXC-контейнеров. Предлагая создать, внезапно, только OpenVZ-контейнеры.
                          –1
                          ну Proxmox и так понятнее некуда. Другое дело, что если ты хочешь, что-то такое например поставить его на сотовый RAID, то можноь получить массу проблем.

                          Ну Upgrade всегда связан с рисками, обычно звонок в support — и они начинают решать эту проблему.
                          Сам пока на боевых серверах, буду ждать с обновлением, а вот на поиграться поставлю.
                          Тем более там и CEPH новый.
                            0
                            Другое дело, что если ты хочешь, что-то такое например поставить его на сотовый RAID, то можноь получить массу проблем.

                            Да ладно? Элементарно ставится по инструкции с сайта — делаем debian на софтовом раиде, затем конвертируем в pve. Никаких проблем. В смысле надёжности и эксплуатации такая система совершенно не отличается от просто линукса с софтовым раидом, т. е. для многих даже зачастую предпочтительнее, чем аппаратный раид.

                            Вообще обновление прошло нормально. А вот CEPH вызвал вопросы. Если в прошлом релизе в лаборатории мы тестировали и без проблем разместили ceph osd на lvm-томе, то в этом релизе это вызвало затруднения.
                              +1
                              Я про софт рад как пример. Понятно, что сейчас уже это не проблема, но вот в первых версиях было много вопросов. Достаточно тут поиском пройтись как установить proxmox на soft raid.

                              ceph используем без lvm, тут не помогу.
                      0
                      Черт возьми, все таки пролезло empty, хотя вроде все лишнее поудалял. Разумеется veth, А при создании контейнера, по дефолту пишется empty. Сейчас подправлю.
                        0
                        >отрабатывать после всех остальных сервисов, в т.ч. и openvpn,

                        Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.

                        В частности у меня оно выглядит вот так:
                        /etc/rc.local
                        #mkdir /dev/net &
                        #mknod /dev/net/tun c 10 200 &
                        su user -c 'i2prouter start' &
                        openvpn /home/user/vpn/my.ovpn
                        


                        Сейчас подредактирую.
                          0
                          Да уже больше года как используем в продакшене LXC на Ubuntu 14.04.
                          Там много чего вкусного есть.
                            0
                            Можете сравнить с OpenVZ?
                              0
                                0
                                Вы извените, но я не первый год в сообществе openvz и уж про такие таблицы я знаю.
                                Вот про LXC я не знаю и хочется узнать непосредственно из уст человека который перешел и похоже плотно перешел с openvz.
                                0
                                К сожалению, с OpenVZ не сталкивался почти, поэтому сказать ничего не могу, но LXC довольно активно развивается.
                                0
                                ну, ведь наружу, в «дикие интернеты» lxc скорее всего не смотрит?
                                у меня в DMZ сервисы живут только в OpenVZ,
                                так соображения безопасности заставляют мириться с древним ядром.
                                  0
                                  а с LXC можно новое ядро использовать.
                                  Конечно ядро системы это бич OpenVZ и это они сами признают.
                                    0
                                    Почему не смотрит? Смотрит. Используется защита Неуловимого Джо, но даже если и так, то чтобы вылезти из контейнера, нужно:
                                    1. Влезть в контейнер
                                    2. Поднять привилегии
                                    3. Понять что используется LXC
                                    4. Вылезти из LXC

                                    Я согласен, что в случае полной виртуализации выйти за пределы ВМ сложнее, но до этого вам предстоит еще, как минимум, два этапа.

                                    Были проломы сайтов (дыры в WP и самописных движках), но не более.
                                      0
                                      Я на своем домашнем сервере все-таки вынес публичные сервисы и owncloud на kvm. Не доверяю я своим навыкам закрыть все возможные дыры.
                                        +1
                                        Никто не доверяет. Поэтому «мухи отдельно, котлеты — отдельно».
                                        Как показывает практика, даже просто использование LXC в качестве chroot позволяет избежать массы проблем, не говоря уже о полной виртуализации. Правда, оба подхода требуют применения системы массового управления конфигурацией/состояниями (Chef, Puppet, Ansible, Salt).
                                        0
                                        С полноценной виртуализацией тоже не всё гладко. «Недавний» баг в Xen 3.4+ XSE 148/CVE-2015-7835 (дыра была с ~2009 года, если что) показывает, что даже нормальная виртуализация далека от хорошей изоляции.

                                        Это конечно, паравиртуализация, но кто в том же kvm сейчас живёт без virtio или в esxi/vmware без их модулей?

                                        Для желающих, рекомендую почитать github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
                                  +4
                                  Для домашнего использования я бы порекомендовал еще посмотреть на bocker, Rocket и Vagga.
                                  Если нужен просто расширенный chroot без ограничения ресурсов через cgroops, то можно пользоваться системным unshare или чем-нибудь еще. Есть вот моя поделка — pyspaces =)

                                  Больше справочной инфы по ним всем тут
                                    –3
                                    Docker Standart de facto? Rly?
                                      0
                                      Вы можете назвать другой продукт, формат образов которого из коробки поддерживают большие cloud провайдеры вроде amazon и google, для которого пишутся большинство оркестраторов и который принят за основу спецификации с участием очень большого количества игроков на рынке?
                                        0
                                        который принят за основу спецификации
                                        вы не указали название спецификации
                                          +2
                                          Простите, понадеялся, что вы ссылку сами найдете в том же списке.
                                          Open Container Initiative
                                          спека на гитхабе
                                          в спеке rkt указано, что они перейдут на этот фомат после того, как он пройдет фазу активного развития и стабилизируется

                                          Я сам не в большом восторге от докера, но с его нынешнем статусом приходится мириться
                                            +1
                                            > Я сам не в большом восторге от докера, но с его нынешнем статусом приходится мириться

                                            Согласен.
                                    +2
                                    Мне как-то напрочь изолированный kvm ближе. Ресурсов и памяти у сервера с избытком…
                                      0
                                      Ну это если с избытком, а обычно дома стоят тихие сервера. Там контейнеры очень да же правят миром.
                                        0
                                        Он у меня тихий. Но это Core i5 и 16 ГБ RAM. Так что я себя в экспериментах не ограничиваю.
                                          0
                                          у меня core i7 с заниженым энергопотреблением, но я бы не сказал, что мне KVM хватит на все мои вирт машины.
                                        0
                                        У сервера, у лаптопа — нет. А контейнеры нужны и на нем.
                                        0
                                        Дома контейнеры уже лет 8 как.
                                        bridge-utils лучше заменить на Open vSwitch
                                          +1
                                          Хотелось бы статью на эту тему. Именно вот так вот вы делали bridge-utils, а вот так это следует делать ovs
                                            0
                                            Я из разряда перфекционистов-прокрастинаторов.

                                            Потом если начинаешь переходить с одной технологии на другую, после чтение документации вопросы отпадают.
                                            Сравнивать bridge-utils и ovs это в корне не верно.
                                              +2
                                              Я вот писал об этом http://blog.ipeacocks.info/2015/12/lxc-ontainers-part-ii-network.html
                                              На украинском, но он чудесно корректно переводится на русский.
                                              +4
                                              К openvswitch ровно одна претензия: ОЧЕНЬ большой оверинжиниринг. Он содержит слишком много того, чего не должен. В этом смысле он похож на systemd: от утилиты управления openvswitch я ожидаю, что она будет исключительно заниматься передачей моих команд ядру, но никак не поддержания отдельной базы данных с конфигурацией (тем более, я категорически против такой базы в бинарном виде), синхронизации между нодами и тому подобного. Пусть синхронизацией занимается мой механизм кластеризации, на базе того же corosync, а не непонятный сервис, поведение которого при различных отказах не определено; базу конфигурации оставим скриптам инициализации ОС, которая лучше знает, какие у чего зависимости.

                                              С ip + brctl можно сделать что нужно: ip link add link name eth0.15 dev eth0 type vlan id 15 и дальше brctl addif br15 eth0.15 и всё, я сделал влан и добавил в мост. Это легко автоматизировать, прекрасно поддерживается скриптами инициализации сети во всех дистрибутивах. Если мне надо, я могу, не прерывая сервис, свободно модифицировать эту структуру в памяти, не трогая конфигурацию, или наоборот только изменить конфигурацию, которая активируется при следующей перезагрузке.
                                              Самое главное: эти две утилиты — это всё, что нужно, никакой базы данных, всё оперативное состояние хранится в ядре и используется при работе, а конфигурация — в конфиг-файлах ОС и загружается понятным и простым образом.
                                              –1
                                              Ну как то много телодвижений для домашнего использования, да и с дисковым пространством и памятью сейчас проблем нет.
                                                +1
                                                Телодвижений многовато только на первых порах, в момент первичной настройки своего первого контейнера. Да и то, телодвижений — создать контейнер, прописать в конфиге нужные устройства и маунтпоинты, прописать интерфейсы. Может быть в статье это выглядит несколько монстроузно, а на деле делается минут за 20 с кружкой чая. Когда-нибудь, думается, для этого будет сделана гуевая тулза.

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

                                                А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
                                                  0
                                                  Вот когда будет «гуёвая тулза», тогда и можно будет говорить о домашнем применении, а пока для основной массы тех, кто использует линукс дома, нуждается в виртуальной машине и не хочет лезть в консоль, VirtualBox останется «маст хэв».
                                                +1
                                                Домашний сервер давно уже не держу, но вот на рабочем пк сделал связку vagrant + lxc, контейнеры это быстро, а когда все настроить ещё и удобно. Для девелоп и тестовой сред используем PVE кластер, начали тестировать PVE4, в целом довольны, планируем CEPH поднять под это дело. в общем-то мы с коллегами верим в LXC. Статья полезная, спасибо!
                                                  0
                                                  планируем CEPH поднять
                                                  Почему не Gluster?
                                                    0
                                                    медленный же, да и претензии по кластер у меня лично были. Там это все пофиксили?
                                                      0
                                                      Самому интересно. А если сравнивать в плане надежности?
                                                  +3
                                                  Дальше либо на хосте, либо на другой рабочей виртуалке можно получить список установленных пакетов и установить их все в нашем новом контейнере:
                                                  Вместо этого костыля, можно и нужно использовать шаблоны.
                                                  Шаблоны, поставляемые с lxc, можно найти в /usr/share/lxc/templates.
                                                  Там имеются, помимо прочего, шаблоны для создания контейнеров Ubuntu, Debian, Fedora, Oracle, Centos и Gentoo.
                                                  При выполнении lxc-create все параметры, указанные после --, передаются шаблону.
                                                  В следующей команде --name, --template и --bdev передаются lxc-create, в то время как --release передаётся шаблону:
                                                  lxc-create --template ubuntu --name c1 --bdev loop -- --release trusty
                                                  
                                                    0
                                                    Конечно можно. Их можно править, создавать свои, или вообще создавать образ с помощью того же debbootstrap'a.

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

                                                    Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
                                                    +2
                                                    vim /etc/lxc/default.conf
                                                    И задаем параметры по умолчанию для новых контейнеров. Например прописываем сеть и автостарт
                                                    lxc.network.type = veth
                                                    lxc.network.link = br0
                                                    lxc.network.flags = up
                                                    lxc.network.hwaddr = 00:16:3e:xx:xx:xx
                                                    
                                                    lxc.start.auto = 1
                                                    lxc.start.delay = 10
                                                    

                                                    Тут же, в конфиге, можно задать и IP, маску, gateway. А можно поставить и подстроить dnsmasq, который сам всё сделает.

                                                    Зачем удалять инклюд дефолтного конфига?
                                                    lxc.include = /usr/share/lxc/config/debian.common.conf

                                                    Можно еще поиграться с unprivileged контейнерами — там у рута uid 100000, я пока не занимался этим.
                                                    А еще есть LXD…
                                                      0
                                                      >Тут же, в конфиге, можно задать и IP, маску, gateway.

                                                      Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.

                                                      А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…

                                                      В общем, юзкейсов и способов построения много (:

                                                      >Зачем удалять инклюд дефолтного конфига?

                                                      Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
                                                        0
                                                        >Можно еще поиграться с unprivileged контейнерами

                                                        Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
                                                        lxc.id_map = u 0 31337 1
                                                        lxc.id_map = g 0 31337 1
                                                        

                                                        И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.

                                                        Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
                                                          0
                                                          Что касается отображения процессов то ps и htop умеют cgroups, которые в свою очередь позволяют выделить все процессы конкретного контейнера.
                                                        +1
                                                        Контейнеры идеальны для автоматического тестирования. Каждый тест можно в своей песочнице запускать
                                                          0
                                                          А кто-нибудь знает ответ на следующий вопрос? Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?

                                                          Это требуется для CUDA(OpenCL) вычислений. Мне нужна специфичная версия проприоретарного видео драйвера (и, видимо, как следствие, ядра), отличная от той, которая установлена в хостовой системе.

                                                          Смогу ли я решить этот вопрос контейнерами, или требуется полноценная виртуализация + проброс PCI устройств?
                                                            0
                                                            > Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?

                                                            Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
                                                              0
                                                              Виртуализация и проброс. qemu-kvmэто неплохо научился в пслд версиях, по тестам потеря производительности около 1% в видео.
                                                              0
                                                              Вот что бы я изменил в Вашей инструкции — так это использование LVM. Теряется масса преимуществ без дополнительных бонусов. Преимущества — простой доступ к файловой системе контейнера и создание контейнеров с опцией -B aufs и потенциально в каком-то будущем overlayfs (в Debian). Вот с этими бонусами использование для указанных применений LXC становится приятно и просто.
                                                                0
                                                                В случае с LVM доступ по-прежнему простой и удобный, хотя в цепочку действий добавляется необходимость монтирования. Плюсов у LVM много, а в данном случае весьма критично использовать снапшоты в том числе и под машины-клоны. То есть, имеем первый контейнер размером в 2GB, и второй — его копию, но с куда более скромны объемом в сотню метров.

                                                                Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.

                                                                Про aufs ничего не скажу, сталкиваться покамест не приходилось.
                                                                  0
                                                                  Btrfs и ZFS так же хороши. Поддержка идет из коробки. Единственное есть противный баг github.com/lxc/lxc/issues/603
                                                                    0
                                                                    Да, zfs — штука более чем приятная, а контексте обсуждаемого, с соларис-контейнерами. так вообще просто шик.

                                                                    Но есть нюансы. На том же основном лаптопе прекрасно работает связка LVM+LUKS, причем получается она, что называется, «из коробки», а вот с brtfs или zfs тут может потребоваться несколько больше телодвижений. Да и со стабильностью, увы, пока не слишком хорошо: так на brtfs поверх dm-crypt вот такая веселуха может всплыть: permalink.gmane.org/gmane.comp.file-systems.btrfs/15564

                                                                    А в дебиан-стейбле у нас 3.16, ага.
                                                                      0
                                                                      На лаптопе — полностью согласен. Достаточно стабильно и консервативно. Если же говорить как минимум о стейджинг серверах, то это очень дешевый вариант создания контейнеров за несколько секунд. Недавно внедрил в проект LXC (опционально) в качестве замены VirtualBox-у. Речь идет о Vagrant-е. Разработчики использующие Linux ликуют:)
                                                                    0
                                                                    LVM для указанных применений не имеет ни одного плюса. Во-первых, любой снапшот — это ресурсы при его удалении. Во-вторых, бэкапирование и без LVM делается проще, можно даже сказать что гораздо проще — опять же, для указанного применения. В третьих размер файловой системы становится фиксированным что, несмотря на возможность расширения, неудобно. Ну а машины-клоны с помощью Aufs занимают вообще пустяки, не заслуживающие упоминания — гораздо меньше чем LVM.
                                                                      0
                                                                      Мы используем LVM как раз для ограничения по диску.
                                                                        +1
                                                                        Поясните, зачем aufs, если в ванильном ядре есть overlayfs?
                                                                          +1
                                                                          «Выбор же пал на LXC, поставляющийся в репозитарии стабильного Debian'a. »
                                                                          В нём overlayfs нет.
                                                                        0
                                                                        А как там теперь, LVM не тупит в случае наличия снапшотов?
                                                                      0
                                                                      Прочитал статью, но не понял, чем Docker-то не угодил?
                                                                        +2
                                                                        Docker довольно узкоспециализирован. Для изоляции приложений и даже деплоя он, конечно, хорош. Но когда нужен контейнер с полноценной операционной системой, лучше все-таки смотреть на lxc или openvz.
                                                                          0
                                                                          Или KVM)
                                                                            0
                                                                            зачем платить больше?
                                                                            (ресурсами хоста)
                                                                          0
                                                                          А как в Docker разрешить пользователю управление только его контейнерами?
                                                                            0
                                                                            Докер для этого не предназначен. Человек имеющий права на управление контейнерами докера фактически имеет права рута на соответствующем хосте.

                                                                            Можно, конечно, делать обёртку, чтобы пользователь не имел возможности работать напрямую и сделать свой IaaS/PaaS.
                                                                              0
                                                                              Получается, в этом Docker уступает LXC — там есть unprivileged-контейнеры, хранящиеся в $HOME.
                                                                                0
                                                                                Сранение, мягко говоря, некорректно. Docker построен поверх LXC (да, есть другие провайдеры, но в 99% использования — это LXC). Т.о., как и при использовании любой обёртки, теоретических возможностей у высокоуровневого API меньше, чем у низкоуровневого, но с другой стороны вам предоставляют удобный интерфейс для создания, запуска и менеджмента LXC-шек, скрестив это дело с файловыми системами, предоставляющими каскадно-объединённое монтирование (ну а также как альтернатива — c оверлеями device mapper-а).
                                                                                  +1
                                                                                  Если кто захочет написать, что libcontainer (который юзается последними версиями докера) != LXC — теоретически верно, но внутри одно и то же. Те же механизмы ядра linux для контейнеризации (cgroups). Теоретически LXC — это название набора простых тулз для работы с этими вызовами, но обычно, говоря LXC, подразумевают всю технологию контейнеризации, предоставляемую ядром linux.

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

                                                                        Самое читаемое