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,46
    Компания
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 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
                                                                        А как в 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.

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

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