> Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
lxc.id_map = u 0 31337 1
lxc.id_map = g 0 31337 1
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
>Тут же, в конфиге, можно задать и IP, маску, gateway.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
Телодвижений многовато только на первых порах, в момент первичной настройки своего первого контейнера. Да и то, телодвижений — создать контейнер, прописать в конфиге нужные устройства и маунтпоинты, прописать интерфейсы. Может быть в статье это выглядит несколько монстроузно, а на деле делается минут за 20 с кружкой чая. Когда-нибудь, думается, для этого будет сделана гуевая тулза.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
>отрабатывать после всех остальных сервисов, в т.ч. и 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
Конечно можно. Их можно править, создавать свои, или вообще создавать образ с помощью того же debbootstrap'a.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
Черт возьми, все таки пролезло empty, хотя вроде все лишнее поудалял. Разумеется veth, А при создании контейнера, по дефолту пишется empty. Сейчас подправлю.
С habrasorage'ом у меня не самые приятные отношения. Обсуждаемый когда-то на хабре способ загрузки с помощью curl в очередной раз накрылся, я какое-то время поковырял, плюнул и загрузил изображения на другой хостинг.
Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.
>(оставляя в стороне побухтеть в тредике про неподходящее под (мои) нужды железо).
А это ничего, у нас есть планы потестить интирпрайзный интирпрайз, но начать решили с малого, отработать инструмент, автоматизировать процесс…
Закрытые технологии у меня тоже не вызывают приятных эмоций: черный ящик и черный ящик, а о его каком-то функционировании можно судить по каким-то внешним признакам.
Так, лет так N назад, когда админил небольшую конторку, подох адаптек на собранном непонятно кем и когда серваке — вот это было приключение. Потом как-то все на софтварном рейде собирал, проще собирать, если (скорей, когда) развалится по кусочкам.
Особо много приятных эмоций доставляли всякие недодевайсы типа псевдоаппаратных рейдов, завязанных на хитрые драйверы с поддержкой известно какой системы. Сейчас то ли ситуация на рынке изменилась, то ли я стал меньше сталкиваться.
В общем-то да. Но в том же виме я частенько использую такой прием в режиме ввода,, как перемещение курсора клавишами [hjkl] с модификатором — иной раз это оказывается быстрее, чем сменить режимы. Вот емаксовские C-[npbf] и тому подобные у меня не прижились, видимо потому, что [hjkl] все-таки ближе к основному положению пальцев на клавиатуре [fdsajkl;] и, например, перемещение курсора вниз либо нажатием j, либо m-j — требует меньше движений, чем c-n.
Такая гибридная схема у меня используется и в оболочке, где, в отличии от текстового редактора, многорежимность будет скорей минусом, чем плюсом.
А так, можно обойтись и без плагина: достаточно повесить на хоткей действие по подгрузке дополнительного ресурса xmodmap вида
Скрытый текст
keycode 43 = Left Left
keycode 44 = Down Down
keycode 45 = Up Up
keycode 46 = Right Right
keycode 33 = Prior Prior
keycode 57 = Next Next
!keycode 40 = Delete Delete
keycode 34 = Home Home
keycode 35 = End End
а при повторном нажатии — загрузки оригинальной раскладки. Плюс решения в том, что работать это будет везде, вне зависимости от тулкита и окружения. Минус — нужно не забыть подгрузить исходную раскладку перед залочкой экрана, хотя делается это не просто, а очень просто. Для отображения текущего режима тоже средств хватает: всевозможные osd_cat'ы, статусбары оконных менеджеров, notify и так далее. В общем-то, за все это я и люблю юниксоподобные системы и линукс в частности.
Пожалуй, стоило упомянуть в статье, что такую схему я использовал несколько лет, но все-таки отказался в пользу модификатора. Объяснение довольно простое: тексты все равно набираю в Vim, вот даже сейчас он вызван из браузера в качестве внешнего редактора.
Может быть, оформлю мысль с переключалкой в виде еще одной статейки, вдруг кому и пригодится.
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.
В частности у меня оно выглядит вот так:
/etc/rc.local
Сейчас подредактирую.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.
А это ничего, у нас есть планы потестить интирпрайзный интирпрайз, но начать решили с малого, отработать инструмент, автоматизировать процесс…
Закрытые технологии у меня тоже не вызывают приятных эмоций: черный ящик и черный ящик, а о его каком-то функционировании можно судить по каким-то внешним признакам.
Так, лет так N назад, когда админил небольшую конторку, подох адаптек на собранном непонятно кем и когда серваке — вот это было приключение. Потом как-то все на софтварном рейде собирал, проще собирать, если (скорей, когда) развалится по кусочкам.
Особо много приятных эмоций доставляли всякие недодевайсы типа псевдоаппаратных рейдов, завязанных на хитрые драйверы с поддержкой известно какой системы. Сейчас то ли ситуация на рынке изменилась, то ли я стал меньше сталкиваться.
У него контроллер шибко умный: попросту игнорирует команду на отключение. Можно, конечно, было плату вытащить, но поняли это все уже когда протестили.
С блоками 4K оттестили, но большие и перегруженные гистограммы упрятали под спойлер.
C SSD'шниками было б интересно потестить. Думаю, организуем.
Про writeback'и спасибо, поразмыслим.
В принципе, можно добавить — там пара строчек в gnuplot. А так, специально приложили csv'шку, по которой построить какие-нибудь свои гистограммы.
В общем-то да. Но в том же виме я частенько использую такой прием в режиме ввода,, как перемещение курсора клавишами [hjkl] с модификатором — иной раз это оказывается быстрее, чем сменить режимы. Вот емаксовские C-[npbf] и тому подобные у меня не прижились, видимо потому, что [hjkl] все-таки ближе к основному положению пальцев на клавиатуре [fdsajkl;] и, например, перемещение курсора вниз либо нажатием j, либо m-j — требует меньше движений, чем c-n.
Такая гибридная схема у меня используется и в оболочке, где, в отличии от текстового редактора, многорежимность будет скорей минусом, чем плюсом.
А так, можно обойтись и без плагина: достаточно повесить на хоткей действие по подгрузке дополнительного ресурса xmodmap вида
а при повторном нажатии — загрузки оригинальной раскладки. Плюс решения в том, что работать это будет везде, вне зависимости от тулкита и окружения. Минус — нужно не забыть подгрузить исходную раскладку перед залочкой экрана, хотя делается это не просто, а очень просто. Для отображения текущего режима тоже средств хватает: всевозможные osd_cat'ы, статусбары оконных менеджеров, notify и так далее. В общем-то, за все это я и люблю юниксоподобные системы и линукс в частности.
Пожалуй, стоило упомянуть в статье, что такую схему я использовал несколько лет, но все-таки отказался в пользу модификатора. Объяснение довольно простое: тексты все равно набираю в Vim, вот даже сейчас он вызван из браузера в качестве внешнего редактора.
Может быть, оформлю мысль с переключалкой в виде еще одной статейки, вдруг кому и пригодится.