Re: LXC vs Docker и форматы контейнеров
On 2018-10-11, Oleksandr Gavenko wrote: > * Есть ли локальные запускалки контейнеров, альтернативные Docker? https://discuss.linuxcontainers.org/t/lxc-3-0-0-has-been-released/1449 New OCI template This adds support for creating application containers from OCI formats. Examples: create a container from a local OCI layout in …/oci: sudo lxc-create -t oci -n a1 -- -u oci:../oci:alpine create a container pulling from the docker hub. sudo lxc-create -t oci -n u1 -- -u docker://ubuntu -- http://defun.work/
Re: LXC vs Docker и форматы контейнеров
Tim Sattarov wrote: > On 11/16/18 6:45 AM, Andrey Jr. Melnikov wrote: > > Artem Chuprina wrote: > > > >> Я же не про то, что надо. Я про то, что пипл хавает. > > Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб "мнеьше > > кнопочек нажимать" - "в экран ткнул и готово". > > > > > я рискую свалиться в оффтопик??? > но вы правда думаете, что ваш почтовый сервер в (квартире|датацентре|где то у > друга провайдера) > более безопасен и защищён, Риски озвучивать будем - от чего он защищён и безопасен? > чем у компании, в которой больше чем один человек занимается этим полный > рабочий день? Да? В корпорации добра, насквозь пользующей всякие AI, где есть один вменяемый postmaster-человек, а всё остальное - роботы исполняющие затейливый танец в стиле "нах-нах, кожаные улюбдки"? Они то - да, полный рабочий день 24/7/365 стараются. > Не флейма ради, не обязательно Гугл, есть куча других провайдеров. Вопрос > использования контента для > рекламы опустим, платный GSuite не таргетируется.
Re: LXC vs Docker и форматы контейнеров
Не в обиду будь сказано, но быстрая вошка первой попадает на гребешок. Все эти телодвижения достаточно хорошо видны, включая Tor, DuckDuckGo и иже с ними. Потому, что логика проста - если кто-то что-то старательно скрывает - значит есть что скрывать. А значит при прочих равных - первым на карандаш поставят криптоманька. А если следить персонально за вами - тут уже хоть обсекреться, о кадом походе в сортир будет известно раньше чем вам. пт, 16 нояб. 2018 г. в 22:52, Victor Wagner : > On Fri, 16 Nov 2018 10:30:55 -0500 > Tim Sattarov wrote: > > > On 11/16/18 6:45 AM, Andrey Jr. Melnikov wrote: > > > Artem Chuprina wrote: > > > > > >> Я же не про то, что надо. Я про то, что пипл хавает. > > > Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб > > > "мнеьше кнопочек нажимать" - "в экран ткнул и готово". > > > > > > > > я рискую свалиться в оффтопик… > > но вы правда думаете, что ваш почтовый сервер в > > (квартире|датацентре|где то у друга провайдера) более безопасен и > > защищён, чем у компании, в которой больше чем один человек занимается > > этим полный рабочий день? > > Да. Потому что целью всех этих людей является не максимизировать > безопасность моих данных, а максимизировать прибыль своей компании. > Поэтому безопасность моих данных их интересует постольку, поскольку > они потеряют прибыли при ее нарушении. Учитывая, что я не являюсь их > платным клиентом, потерять они могут только репутацию в ходе скандала. > > А пока все шито-крыто в их интересах сливать мои данные любым > спецслужбам, любым спамерам и т.д. > > Разница в мотивации важнее разницы в квалификации. > > Кроме того, помимо безопасности моих данных есть еще вопрос о том, > узнаю ли я, что кто-то копался в моих данных. Если провайдеру придет > subpoena, они не будут иметь права мне рассказать, что полиция поимела > мои данные. > > Если полиция вломится в мою квартиру с судебным ордером с целью > конфисковать мой компьютер и порыться на его диске, я об этом узнаю, > сколько бы подписок о неразглашении они с меня ни взяли, потому что > брать их будут С МЕНЯ. > > -- > >
Re: LXC vs Docker и форматы контейнеров
On Fri, 16 Nov 2018 10:30:55 -0500 Tim Sattarov wrote: > On 11/16/18 6:45 AM, Andrey Jr. Melnikov wrote: > > Artem Chuprina wrote: > > > >> Я же не про то, что надо. Я про то, что пипл хавает. > > Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб > > "мнеьше кнопочек нажимать" - "в экран ткнул и готово". > > > > > я рискую свалиться в оффтопик… > но вы правда думаете, что ваш почтовый сервер в > (квартире|датацентре|где то у друга провайдера) более безопасен и > защищён, чем у компании, в которой больше чем один человек занимается > этим полный рабочий день? Да. Потому что целью всех этих людей является не максимизировать безопасность моих данных, а максимизировать прибыль своей компании. Поэтому безопасность моих данных их интересует постольку, поскольку они потеряют прибыли при ее нарушении. Учитывая, что я не являюсь их платным клиентом, потерять они могут только репутацию в ходе скандала. А пока все шито-крыто в их интересах сливать мои данные любым спецслужбам, любым спамерам и т.д. Разница в мотивации важнее разницы в квалификации. Кроме того, помимо безопасности моих данных есть еще вопрос о том, узнаю ли я, что кто-то копался в моих данных. Если провайдеру придет subpoena, они не будут иметь права мне рассказать, что полиция поимела мои данные. Если полиция вломится в мою квартиру с судебным ордером с целью конфисковать мой компьютер и порыться на его диске, я об этом узнаю, сколько бы подписок о неразглашении они с меня ни взяли, потому что брать их будут С МЕНЯ. --
Re: LXC vs Docker и форматы контейнеров
Зависит от модели угрозы. Гугл защитит от хакерских атак, но кто защитит от гугля? В любой момент, компания может выбросить любой фортель: забанить нафиг, запретить imap, поменять политики и ничего с ней не сделаешь. Tim Sattarov writes: > On 11/16/18 6:45 AM, Andrey Jr. Melnikov wrote: >> Artem Chuprina wrote: >> >>> Я же не про то, что надо. Я про то, что пипл хавает. >> Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб "мнеьше >> кнопочек нажимать" - "в экран ткнул и готово". >> >> > я рискую свалиться в оффтопик… > но вы правда думаете, что ваш почтовый сервер в (квартире|датацентре|где то у > друга провайдера) > более безопасен и защищён, чем у компании, в которой больше чем один человек > занимается этим полный > рабочий день? > > Не флейма ради, не обязательно Гугл, есть куча других провайдеров. Вопрос > использования контента для > рекламы опустим, платный GSuite не таргетируется. -- With best regards, ugoday
Re: LXC vs Docker и форматы контейнеров
On 11/16/18 6:45 AM, Andrey Jr. Melnikov wrote: > Artem Chuprina wrote: > >> Я же не про то, что надо. Я про то, что пипл хавает. > Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб "мнеьше > кнопочек нажимать" - "в экран ткнул и готово". > > я рискую свалиться в оффтопик… но вы правда думаете, что ваш почтовый сервер в (квартире|датацентре|где то у друга провайдера) более безопасен и защищён, чем у компании, в которой больше чем один человек занимается этим полный рабочий день? Не флейма ради, не обязательно Гугл, есть куча других провайдеров. Вопрос использования контента для рекламы опустим, платный GSuite не таргетируется.
Re: LXC vs Docker и форматы контейнеров
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Wed, 14 Nov 2018 > 20:05:06 +0300: > >> Почту, календарь, контакты, > >> в меньшей степени "быстрая" связь (видео, голос, мессенджер), > > Хангаутс-то? Так себе видео/голос/месенджер. Оно же в дуплекс голосом еще > не > > научилось. > >> "документы", кстати. > >> В смысле, docs, sheets, и кто там у него presentation умеет. > >> Если нужна совместная работа с кем-то еще. > > Ну да, после эпических факапов с паролями в доксах - да, исключительно надо > > всем раздавать для совсестной работы. > Я же не про то, что надо. Я про то, что пипл хавает. Пипл далёк от безопасности, а она от него ещё дальше. Ему надо чтоб "мнеьше кнопочек нажимать" - "в экран ткнул и готово".
Re: LXC vs Docker и форматы контейнеров
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Wed, 14 Nov 2018 20:05:06 +0300: >> Почту, календарь, контакты, >> в меньшей степени "быстрая" связь (видео, голос, мессенджер), > Хангаутс-то? Так себе видео/голос/месенджер. Оно же в дуплекс голосом еще не > научилось. >> "документы", кстати. >> В смысле, docs, sheets, и кто там у него presentation умеет. >> Если нужна совместная работа с кем-то еще. > Ну да, после эпических факапов с паролями в доксах - да, исключительно надо > всем раздавать для совсестной работы. Я же не про то, что надо. Я про то, что пипл хавает.
Re: LXC vs Docker и форматы контейнеров
Artem Chuprina wrote: > Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Sun, 11 Nov 2018 > 16:12:42 +0300: > >> Т.е. в основном оно используется для того что обычный современный юзер > >> отдает Гуглю, а я не хочу. > > А что там можно отдать гуглю - почту и календари? Нее, я из того набора, что Витус держит у себя. > Почту, календарь, контакты, > в меньшей степени "быстрая" связь (видео, голос, мессенджер), Хангаутс-то? Так себе видео/голос/месенджер. Оно же в дуплекс голосом еще не научилось. > "документы", кстати. > В смысле, docs, sheets, и кто там у него presentation умеет. > Если нужна совместная работа с кем-то еще. Ну да, после эпических факапов с паролями в доксах - да, исключительно надо всем раздавать для совсестной работы.
Re: LXC vs Docker и форматы контейнеров
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Sun, 11 Nov 2018 16:12:42 +0300: >> Т.е. в основном оно используется для того что обычный современный юзер >> отдает Гуглю, а я не хочу. > А что там можно отдать гуглю - почту и календари? Почту, календарь, контакты, в меньшей степени "быстрая" связь (видео, голос, мессенджер), "документы", кстати. В смысле, docs, sheets, и кто там у него presentation умеет. Если нужна совместная работа с кем-то еще.
Re: LXC vs Docker и форматы контейнеров
Victor Wagner wrote: > On Thu, 1 Nov 2018 14:59:23 +0300 > "Andrey Jr. Melnikov" wrote: > > > Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz > > > контейнер был не за доллар в месяц, а за 5, и виртуалка теперь > > > примерно за такие же деньги. > > Сложный вопрос - за то-же самое хотят по $5-$6, а платить за > > виртуалку с la 0.0 за последние 2 года - земноводное душит. > Ну значит надо сервисы диверсифицирвоать. Чтобы за их комплект не > жалко было $5 отдавать. Там и так всё деверсифицированно. Эта виртуалка нужна только на "посмотреть издалека снаружи" как видно всё остальное. > У меня ж там не только и не столько web, сколько всякие другие вещи > - почта (в том числе и с вебмейлом) > - джаббер > - mumble > - CardDAV/CalDAV > - Сервер SyncThing, организованного по схеме звезда > - Сервер OpenVPN, благодаря которому я могу зайти по ssh на любую из > своих машин даже если она за провайдерским NAT. Ну и не только по ssh. > Transmission на домашней машине я тоже так порулить могу. Нее, такие сервисы лежат ближе к телу, на своём железе, где я сам знаю как и чего. > Т.е. в основном оно используется для того что обычный современный юзер > отдает Гуглю, а я не хочу. А что там можно отдать гуглю - почту и календари? > Ну и фоточки тоже там хранятся. (кстати, думаю их оттуда унести, по > крайней мере полноразмерные. А то что-то места мало осталось). > > Мне проще затащить свой сервер к кому-нибудь, где его можно поставить > > в угол и платить аренду пивом-коньяком ;) > Если продать тот сервер на eBay, то сколько лет можно с полученных > денег платить по $5 в месяц? Нисколько. На авито железка такого вида стоит 9 тышь +-. Но надо найти еще идиота, который её купит. >И сколько шансов что сервер за эти годы не сдохнет? Мало. Быстрее сдохнут винты, чем сама платформа.
Re: LXC vs Docker и форматы контейнеров
On Thu, Nov 01, 2018 at 09:47:56AM +0300, Victor Wagner wrote: > > > 1. Обеспечить работу недоверенных приложений > > Это дыркер-то? > Да. И я тут описываю именно задачу для которой нужны "дырявые кошелки". Гм, я было прочёл "недоверенные приложения". > А для задач, под которые создавался vz сейчас проще использовать kvm. > Да, оверхед от лишнего ядра. Но это дешевле чем бороться с ядрами с > версией ниже числа e. Коллега борется с их 4.14, но он привычный... > > > При этом надо понимать, что если вы ходите что-то серьезное хостить > > ...то сперва стоит посмотреть https://www.cvedetails.com/product/28125 > А какой смысл? Все равно взломают. Сейчас гораздо выгоднее > вкладываться в процедуры своевременного обнаружения, > и восстановления после взлома, а не тешить себя иллюзиями > невзламываемых систем. Про непробиваемый щит понятно -- я скорее о понимании того, что чем именно стоит считать ещё на берегу. -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info
Re: LXC vs Docker и форматы контейнеров
On Thu, 1 Nov 2018 14:59:23 +0300 "Andrey Jr. Melnikov" wrote: > > Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz > > контейнер был не за доллар в месяц, а за 5, и виртуалка теперь > > примерно за такие же деньги. > Сложный вопрос - за то-же самое хотят по $5-$6, а платить за > виртуалку с la 0.0 за последние 2 года - земноводное душит. Ну значит надо сервисы диверсифицирвоать. Чтобы за их комплект не жалко было $5 отдавать. У меня ж там не только и не столько web, сколько всякие другие вещи - почта (в том числе и с вебмейлом) - джаббер - mumble - CardDAV/CalDAV - Сервер SyncThing, организованного по схеме звезда - Сервер OpenVPN, благодаря которому я могу зайти по ssh на любую из своих машин даже если она за провайдерским NAT. Ну и не только по ssh. Transmission на домашней машине я тоже так порулить могу. Т.е. в основном оно используется для того что обычный современный юзер отдает Гуглю, а я не хочу. Ну и фоточки тоже там хранятся. (кстати, думаю их оттуда унести, по крайней мере полноразмерные. А то что-то места мало осталось). > Мне проще затащить свой сервер к кому-нибудь, где его можно поставить > в угол и платить аренду пивом-коньяком ;) Если продать тот сервер на eBay, то сколько лет можно с полученных денег платить по $5 в месяц? И сколько шансов что сервер за эти годы не сдохнет?
Re: LXC vs Docker и форматы контейнеров
Victor Wagner wrote: > В Thu, 1 Nov 2018 01:59:59 +0300 > "Andrey Jr. Melnikov" пишет: > > Michael Shigorin wrote: > > PS: Вот гляжу я на контейнер за $1: > > ~# uname -a > > Linux ns2 2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 > > x86_64 GNU/Linux > > > > и возникает у меня мысль - а не пора ли свой доллар нести дяде с lxc. > > или с kvm. Т.к. дельцы с openvz забили на апгрейды. Или у них платная > > поддержка кончилась. > Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz > контейнер был не за доллар в месяц, а за 5, и виртуалка теперь > примерно за такие же деньги. Сложный вопрос - за то-же самое хотят по $5-$6, а платить за виртуалку с la 0.0 за последние 2 года - земноводное душит. Да и барыги с идиотскими тарифами где как достижение 1 IPv6 адрес и следующие за деньги - идут мимо моих денег. Мне проще затащить свой сервер к кому-нибудь, где его можно поставить в угол и платить аренду пивом-коньяком ;)
Re: LXC vs Docker и форматы контейнеров
On Wed, 31 Oct 2018 23:20:06 +0300 Michael Shigorin wrote: > On Thu, Oct 11, 2018 at 07:40:19AM +0300, Victor Wagner wrote: > > Итак, что может хотеться получить: > > > > 1. Обеспечить работу недоверенных приложений, возможно > > нескольких взаимодействующих, возможно предъявляющих > > несовместимые требования к операционным системам, в которых > > развернуты. Под эту задачу создавался докер. > > Это дыркер-то? Виктор, ну Вы-то можете различать контейнеры > (которые были ровно ovz/vz) и дырявые кошёлки для удобства > переноски разных кучек всякого (а это то, что может дать lxc > и около)... Да. И я тут описываю именно задачу для которой нужны "дырявые кошелки". Более того, зачастую и они избыточны. Хватило бы даже не chroot, а чуть более строгого разграничения прав на файловую систему по пользователям и группами. А для задач, под которые создавался vz сейчас проще использовать kvm. Да, оверхед от лишнего ядра. Но это дешевле чем бороться с ядрами с версией ниже числа e. > > > При этом надо понимать, что если вы ходите что-то серьезное > > хостить > > ...то сперва стоит посмотреть https://www.cvedetails.com/product/28125 > и характер дырок, потом очень-очень осторожно спросить kir@ А какой смысл? Все равно взломают. Сейчас гораздо выгоднее вкладываться в процедуры своевременного обнаружения, и восстановления после взлома, а не тешить себя иллюзиями невзламываемых систем. --
Re: LXC vs Docker и форматы контейнеров
В Thu, 1 Nov 2018 01:59:59 +0300 "Andrey Jr. Melnikov" пишет: > Michael Shigorin wrote: > PS: Вот гляжу я на контейнер за $1: > ~# uname -a > Linux ns2 2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 > x86_64 GNU/Linux > > и возникает у меня мысль - а не пора ли свой доллар нести дяде с lxc. > или с kvm. Т.к. дельцы с openvz забили на апгрейды. Или у них платная > поддержка кончилась. Пора. Я уже года три, как ношу дяде с KVM. Правда, у меня и с ovz контейнер был не за доллар в месяц, а за 5, и виртуалка теперь примерно за такие же деньги. -- Victor Wagner
Re: LXC vs Docker и форматы контейнеров
Michael Shigorin wrote: > On Thu, Oct 11, 2018 at 07:40:19AM +0300, Victor Wagner wrote: > > Итак, что может хотеться получить: > > > > 1. Обеспечить работу недоверенных приложений, возможно > > нескольких взаимодействующих, возможно предъявляющих > > несовместимые требования к операционным системам, в которых > > развернуты. Под эту задачу создавался докер. > Это дыркер-то? Виктор, ну Вы-то можете различать контейнеры > (которые были ровно ovz/vz) и дырявые кошёлки для удобства ой, вот только не надо нам тут про дырявые пакеты наспех закленные изолентой рассказывать. Вечный геморой с сетевой конфигурацией, за нодой tun/tap надо к дяде на поклон ходить, ipv6 вобще через жо. И это не говоря про отсутствие возможности просто смонтировать кусок FS из хост-машины в гостевую. Да, на продажу LAMP стеков по 3 цента пучок - просто изумительно. Только вот ситуация изменилась, и теперь за 5 центов берут готовый arm и запихивают вместе с крутящимся на нем LAMP-стеком в лампочку освещения. И светит и греет и жопкой в интернет торчит. > переноски разных кучек всякого (а это то, что может дать lxc > и около)... А lxc то причем в разрезе docker'a ? Кто там в cgroup корявыми ручками лахает - с того и спрашивать надо. lxc хоть не такой стильно-модно-молодежный, в отличии от. PS: Вот гляжу я на контейнер за $1: ~# uname -a Linux ns2 2.6.32-042stab113.21 #1 SMP Wed Mar 23 11:05:25 MSK 2016 x86_64 GNU/Linux и возникает у меня мысль - а не пора ли свой доллар нести дяде с lxc. или с kvm. Т.к. дельцы с openvz забили на апгрейды. Или у них платная поддержка кончилась.
Re: LXC vs Docker и форматы контейнеров
On Thu, Oct 11, 2018 at 12:36:08PM +0300, Victor Wagner wrote: > Потому что каждый раз перед использованием генерить образ, это > совершенно непроизводительный расход ресурсов. Я бы лучше эти > процессорные такты потратил на запуск дополнительных тестов или > поддержку yet another дистрибутива. OBS, например, так вообще kvm генерит-запущает на каждый чих... (с другой стороны, это же dpkg превращает генерацию болванки в достаточно длительное мероприятие -- у меня, скажем, "обычный" ovz tempate cache на сизифе генерится минуту на железе 2009 года, и это уже безобразие: пять лет назад было секунд сорок, да и размер не под двести метров .tar, а что-то в районе ста: https://download.openvz.org/template/precreated/contrib/) -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info
Re: LXC vs Docker и форматы контейнеров
On Thu, Oct 11, 2018 at 07:40:19AM +0300, Victor Wagner wrote: > Итак, что может хотеться получить: > > 1. Обеспечить работу недоверенных приложений, возможно > нескольких взаимодействующих, возможно предъявляющих > несовместимые требования к операционным системам, в которых > развернуты. Под эту задачу создавался докер. Это дыркер-то? Виктор, ну Вы-то можете различать контейнеры (которые были ровно ovz/vz) и дырявые кошёлки для удобства переноски разных кучек всякого (а это то, что может дать lxc и около)... > При этом надо понимать, что если вы ходите что-то серьезное хостить ...то сперва стоит посмотреть https://www.cvedetails.com/product/28125 и характер дырок, потом очень-очень осторожно спросить kir@ (в плюсике, пока не закрыли, или через неконторскую почту), а у них вообще команда разработчиков выросла из горшковой группы или всё так же ждать детских CVE дублетами... Жаль, конечно, но пригодных для этого применения контейнеров, похоже, уже не будет -- большое "спасибо" болотным монаховым. -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info
Re: LXC vs Docker и форматы контейнеров
On 10/20/18 17:28, Oleksandr Gavenko wrote: > On 2018-10-15, Tim Sattarov wrote: > >> рекомендую послушать вот этого товарища: >> https://www.youtube.com/watch?v=xXWaECk9XqM одно из лучших на мой взгляд >> обозрений контейнерных технологий > Интересный парень. Автор dtrace... Он и его товарищ Brendan Gregg (http://www.brendangregg.com/ ), два столпа :) > Он кстати говнит Linux как среду для контейнеров, потому как из мира Solaris > Zones и фанат нативного исполнения в cloud (в том числе стоит за компанией, > предоставляющий клауд на SmartOS). В других видео он выражался что важнее > libc, а не ядро. И что будущий формат контейнеров - ELF. мир движется, мнения меняются. В этом видео он гонит на EC2 как платформу для контейнеров, потому что это виртуализация поверх другой виртуализации :) > Я посмотрел другие его выступления и очень близко к душе "припало" его > мета-наблюдения по отладке https://www.youtube.com/watch?v=30jNsCVLpAE Надо будет посмотреть
Re: LXC vs Docker и форматы контейнеров
On 2018-10-15, Tim Sattarov wrote: > рекомендую послушать вот этого товарища: > https://www.youtube.com/watch?v=xXWaECk9XqM одно из лучших на мой взгляд > обозрений контейнерных технологий Интересный парень. Автор dtrace... Он кстати говнит Linux как среду для контейнеров, потому как из мира Solaris Zones и фанат нативного исполнения в cloud (в том числе стоит за компанией, предоставляющий клауд на SmartOS). В других видео он выражался что важнее libc, а не ядро. И что будущий формат контейнеров - ELF. Я посмотрел другие его выступления и очень близко к душе "припало" его мета-наблюдения по отладке https://www.youtube.com/watch?v=30jNsCVLpAE На собеседовании я прошу описать опыт отладки, почему-то приходится оплаживать много. Я думаю что из-за высокоуровневости инструментов, когда не понимаешь что вообще происходит и всех контрактов фреймворков. -- http://defun.work/
Re: LXC vs Docker и форматы контейнеров
On 10/10/18 18:29, Oleksandr Gavenko wrote: > Зачем настраивать коробку очередным YAML DSL, если можно ее загрузить > контейнерами. Как для обывателей - вставил в розетку и работает )) > > Мания на контейнеры пошла с 2013: https://www.youtube.com/watch?v=wW9CAH9nSLs рекомендую послушать вот этого товарища: https://www.youtube.com/watch?v=xXWaECk9XqM одно из лучших на мой взгляд обозрений контейнерных технологий > > > * Во что оборачивать контейнеры? Вроде есть: зависит от того, с каким поставщиком виртуализации ты работаешь, Docker сейчас выглядит как стандарт де-факто. |docker image 2>&1 | grep tar import Import the contents from a tarball to create a filesystem image load Load an image from a tar archive or STDIN save Save one or more images to a tar archive (streamed to STDOUT by default) | Можно держать в файлах, можно в своём docker image repository. можно в публичном (hub) > > > * Стоит ли заморачиваться с LXC для развертывания локальных демо-стендов? Как > писал выше я умею варить Vagrant+VirtualBox. Пару лет назад настройка > бриждей была непосильна разуму. > > Docker + Compose - вроде функциональная альтернатива. Я еще не понимаю как там > думать в терминах портов, с VirtualBox я работал в терминах IP адресов, что > приближено к реальности... compose уже устарел, на его место пытались засунуть swarm, но сейчас все похоже скатились в Kubernetes (K8S) (можно держать локальный K8S кластер) > * Правильно ли впихивать 10 гигабайт в контейнер или это должен быть Alpine > (100 mb с lighttpd) или CoreOS (500mb)? > > Не будет Debian без Python и без 1GB места в голом виде? всё зависит от того, что ты хочешь, никакие рекоммендации не запрещают иметь большие контейнеры, пустое место не считается в размер. > > > * Микросервис - это потому что выставляется немного HTTP REST эндпоинтов, > связаных функционалом? Я вижу микросервисы как продолжение концепции Unix: каждая программа умеет делать одну вещь и хорошо, общение между ними по текстовому протоколу (REST) > А то когда видишь "микросервисный" Java-jar файл в 100 MB в гигабайтном > убунтовом контейнере - дисонанс с моим калькулятором МК-61 с 104 однобайтными > ячейками памяти... не все понимают такой подход одинаково :) > > > * Зачем вообще разбираться с Puppet, Ansible, Salt, CFEngine и т.д., если все > пакуется в контейнеры? > > Что бы менеджить оставшийся не "микросервисный" софт (базы данных, файерволы и > остальное, что требует больше чем RAM+CPU)? Чтобы собрать образ контейнера иногда надо использовать немного более хитрую логику чем простой набор bash команд внутри Dockerfile. в этом пригождаются системы управления конфигурацией (Puppet, Ansible, etc.) > > > * Можно ли жить без Docker? > > По идее Docker не нужен, нужен только формат пакета и "исполнятор". Запускать > как бы и раньше умели другими технологиями... Прибавочная стоимость в > оркестрации, а не голом запускании... можно, если совсем не хочется туда идти, но по моему опыту это сейчас довольно широко используемый инструмент. Не без проблем, часто представляется как панацея от всех бед. Но если трезво посмотреть, вполне даже себе вменяемый инструмент. Как в видео выше сказал Брайан: теперь разработчики могут локально запустить такую же систему как на сервере и быстрее разрабатывать. Улучшается переносимость, контроллируемость окружений разработки. Меньше становится ситуаций, когда разработчик сидя на своём Эппл макбуке, забывает, что ФС у них не case sensitive или говорит “works on my laptop” > По идее тут будет у нас https://packages.debian.org/source/sid/kubernetes > > Да и сам Докер не без приключений добрался в Debian > https://www.collabora.com/news-and-blog/blog/2018/07/04/docker-io-debian-package-back-to-life/ > С упаковкой всех этих довольно быстро развивающихся инструментов в Дебьяне беда, Докер выходит каждй месяц, со стабильной версией раз в квартал. Кубернетес тоже довольно часто, Приходится использовать их репозитарии или собирать самому локально.
Re: LXC vs Docker и форматы контейнеров
Oleksandr Gavenko пишет: > > * Есть ли локальные запускалки контейнеров, альтернативные Docker? > > > Разработка rkt остановилась (https://news.ycombinator.com/item?id=17496877): > > > Yes, they announced at the Red Hat summit that they'll be phasing out > > development of rkt, though of course will do nothing to stop outside > > development > > Т.е. напугали Docker Inc и умерли. > > Как дела с cri-o (It is a lightweight alternative to using Docker as the > runtime for kubernetes) пока не ясно. К этому ещё можно добавить systemd-nspawn [1], если позапускть локально, без кластеров, то самое оно. Поттеринг [2] частенько приезжает продвигать эту тему. [1]: https://blog.selectel.ru/systemd-i-kontejnery-znakomstvo-s-systemd-nspawn/ [2]: https://it-events.com/events/9745/materials/2306 -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: LXC vs Docker и форматы контейнеров
11.10.2018, Victor Wagner написал(а): >> Не "перед использованием", а "раз в сутки" всё же. >> Это ж сколько заняло бы развёртывание виртуалки, если б её через >> debootstrap ставили... >> А так - раз в сутки создаются три десятка образов. > > Что? У вас "использование" занимает существенно меньше суток? Не "использование занимает меньше суток", а "появляется потребность в новой виртуалке указанного типа". Хостинг-провайдер, где клиенты заказывают себе вдс, тыкая в кнопки панели или дёргая API. >> Ну и, кстати, apt-get update && apt-get upgrade там, где требуется >> именно новая система без следов обновлений - может быть неверным >> решением. > > Я полагаю, что требование "новой системы без следов обновления" > является ошибкой при постановке технического задания. Возможно, но ТЗ было именно такое. Почему-то некоторые клиенты плохо относились к тому, что в системе оставались рудименты от обновлений (в теории их можно почистить, на практике - обязательно найдётся товарищ, который будет копать и таки найдёт). Из рудиментов кроме логов dpkg появлялись, как минимум, .dpkg-old/.dpkg-dist для некоторых конфигов и что-то ещё, что навскидку не припомню, но помню, что это указывали именно клиенты.. -- Stanislav
Re: LXC vs Docker и форматы контейнеров
On 2018-10-11, Oleksandr Gavenko wrote: > * Есть ли локальные запускалки контейнеров, альтернативные Docker? > Разработка rkt остановилась (https://news.ycombinator.com/item?id=17496877): > Yes, they announced at the Red Hat summit that they'll be phasing out > development of rkt, though of course will do nothing to stop outside > development Т.е. напугали Docker Inc и умерли. Как дела с cri-o (It is a lightweight alternative to using Docker as the runtime for kubernetes) пока не ясно. > * Правильно ли впихивать 10 гигабайт в контейнер или это должен быть Alpine > (100 mb с lighttpd) или CoreOS (500mb)? > > Не будет Debian без Python и без 1GB места в голом виде? > Совсем недавно Minimal Ubuntu (29MB): https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released Также есть RancherOS, но она чисто под Docker (в ней init 1 == Docker xD). И есть еще http://www.projectatomic.io/ CoreOS - без пакетов, просто сборка с командами docker, docker-compose, docker-machine. -- http://defun.work/
Re: LXC vs Docker и форматы контейнеров
On Thu, 11 Oct 2018 16:09:51 +0500 Stanislav Vlasov wrote: > 11.10.2018, Victor Wagner написал(а): > >> Руками - это Centos и т.п., для которых работающего аналога > >> debootstrap не обнаружено. > >> Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить > >> перед использованием, так как apt-get upgrade в мастер-образе > >> может дать не такой же результат, как генерация с нуля. > > > По-моему, если делать apt-get dist-upgrade, то разница будет > > пренебрежимо мала. Во всяком случае, если речь идет о stable, > > oldstable и Ubuntu LTS. > > Верно, но у нас не только убунты c дебианами. > Тут заодно решалась задача унификации создания мастер-образов, так как > часть образов - генерилась автоматически, часть - приходилось > делать/обновлять руками. > > > Впрочем, лично я считаю что "генерировать с нуля перед > > использованием" это категорически неправильный подход. > > Не "перед использованием", а "раз в сутки" всё же. > Это ж сколько заняло бы развёртывание виртуалки, если б её через > debootstrap ставили... > А так - раз в сутки создаются три десятка образов. Что? У вас "использование" занимает существенно меньше суток? По-моему, обычно "использование" того же докер-контейера для предоставления сервиса наружу продолжается до тех пор пока не потребуется что-то капитально сапгрейдить - либо софт в контейнере, либо ядро на хосте. Мы - фирма необычная, мы кроссплатформной разработкой занимаемся (а судя по тому что я вижу в тенденциях развития софта, обычные люди очень хотят забыть, что бывают архитектуры, кроме amd64 и операционки кроме Linux). Поэтому у нас сборочный контейнер работает считанные минуты. Хотя в целом получается что за сутки он хорошо если десяток раз успеет запуститься. Потому что их таких много. > Ну и, кстати, apt-get update && apt-get upgrade там, где требуется > именно новая система без следов обновлений - может быть неверным > решением. Я полагаю, что требование "новой системы без следов обновления" является ошибкой при постановке технического задания. > Но это уже местные особенности. >
Re: LXC vs Docker и форматы контейнеров
Приношу извинения за приват. В Gnus не заходил пол года и нажал R, вместо F... Вы уже ответили в приват. Я не переношу ответ сюда, соблюдая приватность пересылки. Если автор выскажет желание - я могу его опубликовать. Сам вопрос: On 2018-10-11, Stanislav Vlasov wrote: > Более того, у нас на работе мастер-образы для виртуалок в kvm > создаются на базе соответствующих образов докера путём доустановки > нужных пакетов в распакованном chroot. > Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем руками. Я хочу подробностей... В оригинальном письме об этом спрашивал. Как запаковывать? Какие форматы архивов/контейнеров? Вы виртуалки для KVM подготавливаете как хостер или для запуска конечных приложений? Это какой-то cow / qcow / qcow2 / qed / raw / vmdk / etc блоб? Я так полагаю что они все "совместимы" и даже tar для этого достаточен (не учитыая что теряем разметку хранилища и файловую систему). Важет только контент в файлах и имена/атрибуты файлов. Т.е. можно "распаковать" любой формат в chroot, внести модификации на уровне контента файлов и засунуть результат обратно в иной блоб. Мне кажется что сами форматы эквивалетнты, у каждого просто свои особенности. Каким софтом можно создавать и модифицировать? Какие ключевые слова что бы самому поискать? > Ну и окончательная конфигурация (хостнейм, сеть, пароли, ключи) > создаётся после раскатывания образа при помощи runc. Если runc - то значит у Вас контейнеры все же? https://github.com/opencontainers/runc CLI tool for spawning and running containers according to the OCI specification Т.е. Вы используете контейнеры запакованые согласно OCI specification, а не докеровкие форматы? И инфраструктурно - кто закускает runc и как описана схема развертывания (что/откуда, сколько и куда)? Есть ли динамизм (запусть N штук), в файле под контролем версий или как запись в БД? Общий вопрос: я не понимаю необходимости держать в контейнерах. Т.е. зачем покупать одну толстую машину и нарезать контейнеры, если можно купить 10 машин для каждого приложения. Из того что я вижу - менеджер контейнеров имеет унифицированое API. А вот виртуалки на проде будут от AWS, Google Cloud, DigitalOcean / etc - у каждого свое API для оркестрации. Аргумент что RAM лучше экономится с контейнерами пока выглядит слабо мне... -- http://defun.work/
Re: LXC vs Docker и форматы контейнеров
Приношу извинения за приват. В Gnus не заходил пол года и нажал R, вместо F... Вы пока не отвечали, если будет интересно - с нетерпением жду в рассылке... On 2018-10-11, Victor Wagner wrote: > В Thu, 11 Oct 2018 01:29:09 +0300 > Oleksandr Gavenko пишет: > >> Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его >> нужно было либо на голом железе крутить или с особыми ядрами. В общем >> VistualBox можно кликать, экономя время и мозги. >> > > Правильно поставленный вопрос - это больше половины ответа. У докера > есть своя область применения, у LXC-своя. А есть вещи (вроде того же > запуска skype) для которых LXC - это избыточно тяжеловесное решение, и > надо испольовать что-то типа firejail или chroot. > Это потому что избыточно тянуть системные библиотеки (200 MB зависимостей) когда просто нужно оградить забором? > К сожалению, из огромного письма, перечисляющего разные свойства > технологий (в которые почему-то вместе с технологиями изоляции и > виртуализации попали технологии массового управления системами - > ansible и CFEngine) я так и не понял чего хочется получить. > Мне не ясно нужно ли тратить время на ansible, если я буду упаковывать все в контейнеры, а остальное что не пакуется предоставляется провайдер (например Amazon Relational Database Service). Провиженинг Vagrant коробок я делаю с помошью bash/sed, т.к. Puppet/Salt требует отдельного сервера (мне не нужно дополнительных абстракций), а Ansible и CFEngine умеет без сервера, но требуют инталяций в коробке. Мне не нравится что 50 MB Python доставится что бы только поменять какую то строчку в /etc/bla-bla.d С другой стороны работать с структурироваными форматами (ini/yaml/json/xml) из sed - неблагодарный труд и лишний Python/Ruby не так неприятен )) > 1. Обеспечить работу недоверенных приложений...[SKIP] > Принято! > Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому > что не надо приноравливаться к тому как сделали разработчики докера, а > можно сделать как кажется нужным в конкретной ситуации. > LXC-низкоуровневый конструктор, этим и плох, этим и хорош. > А как хостить LXC? С kubernates к примеру есть способ описывать деплои в терминах Docker-контейнеров. Это предполагается что нужно свое решение делать, набрав пул виртуальных машин? С kubernates хостеры поддерживают сервера / балансировщики / хранилища настроек вне кластера контейнеров и зачастую бесплатно. Для LXC как я понимаю есть LXD и его крутить придется вручную и еще за хостинг платить? > 2. Обеспечить разработку и тестирование программы на возможно широком > спектре дистрибутивов Linux при ограниченных аппаратных ресурсах. > Вот здесь, на мой взгляд, LXC гораздо лучше. Хотя на практике часть > тестовых систем все равно приходится держать в KVM, несмотря на > его более высокий оверхед поскольку необходимо бывает тестироваться с > их родными ядрами. Какой-нибудь Oracle Linux unbreakable kernel или > Astra Smolensk с ее мандатным доступом. > Пока не знаю заведется ли Jenkins в паре с LXC. Всякие CircleCI, Bitbucket Pipelines, Google cloud-build работают только с образами Docker... > 3. То же что и 2, но поддерживаемых линуксов меньше десятка, а основной > упор в переносимости надо делать на системы с другими ядрами. Тогда > проще не париться и все держать в KVM/VirtualBox/VMWare. Необходимость > менеджить две системы изоляции/виртуализации обойтется дороже, чем > оверхед от загоняния в виртуальную машину того, что могло бы жить в > контейнере. > Принято! > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне > конкуренции. Потому что у него есть DockerHub где этих образов море. > Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu > эту технологию стали развивать когда уткнулись в ограничения докера. Я позно попал на бал упаковки всего узерспейс окружения и начал с Vagrant. У них есть свой хаб https://app.vagrantup.com с одной бедой - append only + нету проверок издателя. Т.е. нельзя "убить" проблемный релиз и все образы недоверенные и без какиз либо гарантий. Они не хотят менеджить гарантии кто есть кто, как в докер-хаб. Если смотреть на проекты, то пока еще можно встретить запаковки в Vagrant что бы поиграться, но все больше все скатываются в Docker, убивая популярность Vagrant. -- http://defun.work/
Re: LXC vs Docker и форматы контейнеров
11.10.2018, Victor Wagner написал(а): >> Руками - это Centos и т.п., для которых работающего аналога >> debootstrap не обнаружено. >> Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить перед >> использованием, так как apt-get upgrade в мастер-образе может дать не >> такой же результат, как генерация с нуля. > По-моему, если делать apt-get dist-upgrade, то разница будет > пренебрежимо мала. Во всяком случае, если речь идет о stable, oldstable > и Ubuntu LTS. Верно, но у нас не только убунты c дебианами. Тут заодно решалась задача унификации создания мастер-образов, так как часть образов - генерилась автоматически, часть - приходилось делать/обновлять руками. > Впрочем, лично я считаю что "генерировать с нуля перед использованием" > это категорически неправильный подход. Не "перед использованием", а "раз в сутки" всё же. Это ж сколько заняло бы развёртывание виртуалки, если б её через debootstrap ставили... А так - раз в сутки создаются три десятка образов. Ну и, кстати, apt-get update && apt-get upgrade там, где требуется именно новая система без следов обновлений - может быть неверным решением. Но это уже местные особенности. -- Stanislav
Re: LXC vs Docker и форматы контейнеров
On Thu, 11 Oct 2018 12:40:56 +0300 Alexander Gerasiov wrote: > Hello Victor, > > On Thu, 11 Oct 2018 07:40:19 +0300 > Victor Wagner wrote: > > > Решение на базе LXC или LXC+Ansible здесь может оказаться проще > > потому что не надо приноравливаться к тому как сделали разработчики > > докера, а можно сделать как кажется нужным в конкретной ситуации. > > LXC-низкоуровневый конструктор, этим и плох, этим и хорош. > > Я рекомендую LXD: он чуть более высокоуровневый и очень приятный в > плане баланса между простой интерфейс/возможности по кастомизации. > Единственная проблема - ставится пока только из snap. > Ну во-первых, не только из snap. В убунтах он есть в виде нормальных пакетов, соответственно можно взять исходники и спортировать. Во-вторых мне несколько неочевидно, что выбранная его авторами схема работы с контейнерами (для моих целей) лучше докера. Но вообще интересно то, что LXD написан на Go. А авторами этого языка в саму концепцию средств разработки на нем заложена та же идея, что и в snap - максимальная изоляция приложения от окружающей системы. Поэтому идея заворачивания go-приложения в snap уже выглядит какой-то подозрительной. --
Re: LXC vs Docker и форматы контейнеров
Hello Victor, On Thu, 11 Oct 2018 07:40:19 +0300 Victor Wagner wrote: > Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому > что не надо приноравливаться к тому как сделали разработчики докера, а > можно сделать как кажется нужным в конкретной ситуации. > LXC-низкоуровневый конструктор, этим и плох, этим и хорош. Я рекомендую LXD: он чуть более высокоуровневый и очень приятный в плане баланса между простой интерфейс/возможности по кастомизации. Единственная проблема - ставится пока только из snap. -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su WWW: http://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Re: LXC vs Docker и форматы контейнеров
On Thu, 11 Oct 2018 13:02:34 +0500 Stanislav Vlasov wrote: > 11.10.2018, Victor Wagner написал(а): > >> Более того, у нас на работе мастер-образы для виртуалок в kvm > >> создаются на базе соответствующих образов докера путём доустановки > >> нужных пакетов в распакованном chroot. > [...] > > > Честно сказать не понимаю, зачем мастер-образы делать таким > > способом. По-моему проще эталонный qcow2 файл скопировать, и потом > > уже доустанавливать пакеты и настраивать сеть каким-нибудь ansible. > > Тем более что это будет работать не только с линуксаии, но и с > > freebsd, solaris и даже windows. > > Поэтому: > >> Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем > >> руками. > > Руками - это Centos и т.п., для которых работающего аналога > debootstrap не обнаружено. > Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить перед > использованием, так как apt-get upgrade в мастер-образе может дать не > такой же результат, как генерация с нуля. По-моему, если делать apt-get dist-upgrade, то разница будет пренебрежимо мала. Во всяком случае, если речь идет о stable, oldstable и Ubuntu LTS. Впрочем, лично я считаю что "генерировать с нуля перед использованием" это категорически неправильный подход. Скажем, для сборочных систем у нас используется цепочка докерных образов - мастер-образ (с докерхаба, если там соотвествтующихй дистрбутив есть)- сборочный образ с уже установленными всеми build-dependencies- рабочий контейнер. Вот рабочий контейнер после использования прибивается, а сборочный образ живет своей жизнью и апдейтится раз в неделю, по выходным. Потому что каждый раз перед использованием генерить образ, это совершенно непроизводительный расход ресурсов. Я бы лучше эти процессорные такты потратил на запуск дополнительных тестов или поддержку yet another дистрибутива. --
Re: LXC vs Docker и форматы контейнеров
11.10.2018, Victor Wagner написал(а): >> Более того, у нас на работе мастер-образы для виртуалок в kvm >> создаются на базе соответствующих образов докера путём доустановки >> нужных пакетов в распакованном chroot. [...] > Честно сказать не понимаю, зачем мастер-образы делать таким способом. > По-моему проще эталонный qcow2 файл скопировать, и потом уже > доустанавливать пакеты и настраивать сеть каким-нибудь ansible. > Тем более что это будет работать не только с линуксаии, но и с freebsd, > solaris и даже windows. Поэтому: >> Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем >> руками. Руками - это Centos и т.п., для которых работающего аналога debootstrap не обнаружено. Ну и, к тому же, этот самый эталонный qcow2 тоже надо генерить перед использованием, так как apt-get upgrade в мастер-образе может дать не такой же результат, как генерация с нуля. У нас более ограниченная номенклатура базовых систем, если что. Только linux. -- Stanislav
Re: LXC vs Docker и форматы контейнеров
On Thu, 11 Oct 2018 11:02:17 +0500 Stanislav Vlasov wrote: > 11.10.2018, Victor Wagner написал(а): > > > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер > > вне конкуренции. Потому что у него есть DockerHub где этих образов > > море. Хотя тут уже надо смотреть в сторону убунтовских snap. > > Видимо, в ubuntu эту технологию стали развивать когда уткнулись в > > ограничения докера. > > Более того, у нас на работе мастер-образы для виртуалок в kvm > создаются на базе соответствующих образов докера путём доустановки > нужных пакетов в распакованном chroot. > Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем > руками. Ну и окончательная конфигурация (хостнейм, сеть, пароли, > ключи) создаётся после раскатывания образа при помощи runc. Мне чаще приходится сталкиваться с обратной задачей - поставив в виртуалку какой-нибудь дистрибутив родным инсталляторм, сделать из этого докер-образ. Потому что примерно половина дистрибутивов, с которыми приходится иметь дело- это всякие хитрые российские сертифицированные варианты. для которых на докерхабе ничего нет. Честно сказать не понимаю, зачем мастер-образы делать таким способом. По-моему проще эталонный qcow2 файл скопировать, и потом уже доустанавливать пакеты и настраивать сеть каким-нибудь ansible. Тем более что это будет работать не только с линуксаии, но и с freebsd, solaris и даже windows. C другой стороны, мне много виртуалок не нужно. У меня сейчас примерно 4 десятка поддержвиваемых дистрибутивов/систем, и на каждую нужно от силы пяток экземпляров 1. В билдферме для тестирования кода, принимаемого от разработчиков 2. Для сборки пакетов 3. Для тестирования собранных пакетов 4,5. Для выполнения всяких длительных тестов --
Re: LXC vs Docker и форматы контейнеров
11.10.2018, Victor Wagner написал(а): > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне > конкуренции. Потому что у него есть DockerHub где этих образов море. > Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu > эту технологию стали развивать когда уткнулись в ограничения докера. Более того, у нас на работе мастер-образы для виртуалок в kvm создаются на базе соответствующих образов докера путём доустановки нужных пакетов в распакованном chroot. Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем руками. Ну и окончательная конфигурация (хостнейм, сеть, пароли, ключи) создаётся после раскатывания образа при помощи runc. -- Stanislav
Re: LXC vs Docker и форматы контейнеров
В Thu, 11 Oct 2018 01:29:09 +0300 Oleksandr Gavenko пишет: > Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его > нужно было либо на голом железе крутить или с особыми ядрами. В общем > VistualBox можно кликать, экономя время и мозги. > Правильно поставленный вопрос - это больше половины ответа. У докера есть своя область применения, у LXC-своя. А есть вещи (вроде того же запуска skype) для которых LXC - это избыточно тяжеловесное решение, и надо испольовать что-то типа firejail или chroot. К сожалению, из огромного письма, перечисляющего разные свойства технологий (в которые почему-то вместе с технологиями изоляции и виртуализации попали технологии массового управления системами - ansible и CFEngine) я так и не понял чего хочется получить. Кроме того я не понял в чем сложности с настройкой бриджа-то? Вещь исключительно простая и прямолинейная. Итак, что может хотеться получить: 1. Обеспечить работу недоверенных приложений, возможно нескольких взаимодействующих, возможно предъявляющих несовместимые требования к операционным системам, в которых развернуты. Под эту задачу создавался докер. И ее худо-бедно решает. В смысле как только в список несовместимых требований попадает "это приложение у нас 32-разрядное", становится худо. При этом надо понимать, что если вы ходите что-то серьезное хостить, то "сэкономить время и мозги" не получится. Придется достигать глубокого понимания как работает докер (а он заметно overengineered), как решать проблемы, которые он не решает (например защиту данных от несанкционированного изменения при взломе приложения, которое вообще-то имеет право в эти данные писать). Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому что не надо приноравливаться к тому как сделали разработчики докера, а можно сделать как кажется нужным в конкретной ситуации. LXC-низкоуровневый конструктор, этим и плох, этим и хорош. 2. Обеспечить разработку и тестирование программы на возможно широком спектре дистрибутивов Linux при ограниченных аппаратных ресурсах. Вот здесь, на мой взгляд, LXC гораздо лучше. Хотя на практике часть тестовых систем все равно приходится держать в KVM, несмотря на его более высокий оверхед поскольку необходимо бывает тестироваться с их родными ядрами. Какой-нибудь Oracle Linux unbreakable kernel или Astra Smolensk с ее мандатным доступом. 3. То же что и 2, но поддерживаемых линуксов меньше десятка, а основной упор в переносимости надо делать на системы с другими ядрами. Тогда проще не париться и все держать в KVM/VirtualBox/VMWare. Необходимость менеджить две системы изоляции/виртуализации обойтется дороже, чем оверхед от загоняния в виртуальную машину того, что могло бы жить в контейнере. 4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне конкуренции. Потому что у него есть DockerHub где этих образов море. Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu эту технологию стали развивать когда уткнулись в ограничения докера. -- Victor Wagner
