Ну так создай там docker config с кредами

это не конфигурируемо

я ваще ожидал что оно из сокета хоста получит всё чо надо

хост про авторизацию ничего не знает

вообще крутить докер в докере как-то не очень

вообще крутить докер в докере как-то не очень

согласен, но приходится) ... причем даже докер в докере в докере =(

http://i1.kym-cdn.com/photos/images/original/000/531/557/a88.jpg

согласен, но приходится) ... причем даже докер в докере в докере =(

А рекурсию замутить можно?

это не конфигурируемо

конфигурируемо, если ты конфиг приносишь каким-нить менеджером конфигурации, например ansible ну или монтируй хомяк из хоста в докер

вообще крутить докер в докере как-то не очень

ну предложи другой вариант как собирать имаджи в CI

CI в докере

у меня вот есть контейнеры самоавторизующиеся для CI , им в ENV даешь все что нужно и они сами авторизуются в докер регистр, в ssh/git.

ну предложи другой вариант как собирать имаджи в CI

именно так и собираются имаджи и вообще все что угодно

у нас имеджи собираются в CI на виртуалках. под каждый проект выделен свой слейв-виртуалка. Если нужно, можно на каждый билд поднимать временную виртуалку

у нас имаджи собирает специальный самоавторизующийся контейнер с dind наборту и всем необходимым для билда чего угодно. такойконтейнер запускается gitlab runner'ом , раннер подсовывает этому контейнеру файлик с данными для авторизации Раннер устанавливается через ansible , и в этот момент подсовываются авторизационные данные

все абсолютно секьюрно

вот у нас тоже самое, только тимсити

а у нас jenkins =)

у кого drone ?

у нас имаджи собирает специальный самоавторизующийся контейнер с dind наборту и всем необходимым для билда чего угодно. такойконтейнер запускается gitlab runner'ом , раннер подсовывает этому контейнеру файлик с данными для авторизации Раннер устанавливается через ansible , и в этот момент подсовываются авторизационные данные

у тебя получается перед запуском раннера какой-то там шеллскрипт который авторизацию настраивает из конфига?

или не шелл

есть контейнер с диндом, он просто умеет башем сделать source /some/mount/file/with.env и потом сделать docker login -p ${REG..PASS} -u ${REG..USER} ${REG..URL} и всё... тоесть он авторизауетсякаждый раз при старте, все это вшито в entrypoint и состороны никак нельзя заафектить или вытащит приватные данные

в итоге такой CI RUNNER шареный для любого проекта в пределах нашего гита

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

м

Если на хост машине ubutnu 16.04 и в базовом контейнере ubutnu 16.04, то какие-то куски библиотек будут шариться или только ядро?

только ядро

если ты специально что-то монтировать снаружи не будешь

так то ты можешь хоть альпин гонять внутри контейнера который на убунте работает

только ядро

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

а, чёрт, я вопрос не совсем правильно понял. да, дедупликацию впилили вроде, ага

но да, я тоже не уверен что оно работает всегда и везде, там всё как-то сложно было

Ну лан будем считать что это не гарантированная фича

вон в рассылке по этому поводу

Which (if I read the tea leaves right) confirms what Jérôme is saying - if you use aufs, then the memory is shared, but if you use one of the other 'real' device based FS's, it isn't.

https://groups.google.com/forum/#!topic/docker-dev/NOeA2YHl1sU

от 2014 года

кстати, а кто-то уже пробовал докера на zfs на бубунте 16.04?

я бы спросил "кто решился на zfs на птицуксе" )

есть опыт, правда не с докером, а lxd. Подкупило нативная в zfs реализация рейдов и встроенный кеш на ssd диске

оказалось крайне удобно и производительно

кстати, а кто-то уже пробовал докера на zfs на бубунте 16.04?

собственно с докером есть проблема - одна из прелестей докера это 9p^W ой... overlayfs. и тут кагбэ...

ну overlay и zfs это вроде разные драйвера для стораджей или я что-то путаю?

и тут какбе снепшоты у zfs?

aufs тоже вполне себе умеет в слои

или я не понял пассажа про overlayfs

zfs в линксе, имхо, все-таки про удобства работы с рейдами, снепшотами и ssd кешем, профита от zfs на сингл диске относительно aufs скорей всего просто нет

у меня есть эфемерный sata ssd, и есть куча nbd

я хочу на ssd кеш, а из сетевых блочных устройств наделать себе пулов

мне больше всего интересно что будет c named volumes и можно ли их будет нормально снепшотить

нет такого опыта нет - на бэкап средствами zfs не завязывался, да для каких то вещей скорей ок, плюс дедупликация

в девопс чятике плохо отзывались про дедупликацию на ZoL

но мой юзкейс в zfs иметь "много" места за счет sata и чтобы оно быстро работало

второй юзкейс - zvol по iscsi

тут вообще все хорошо

ну overlay и zfs это вроде разные драйвера для стораджей или я что-то путаю?

ну вот да.

нет такого опыта нет - на бэкап средствами zfs не завязывался, да для каких то вещей скорей ок, плюс дедупликация

я кстати делаю. няшно. но не птицукс. freebsd и smartos

в девопс чятике плохо отзывались про дедупликацию на ZoL

очень много вообще плохих отзывов про ZoL

c 15.04 ситуация вроде как заметно изменилась

меня пугает в целом две вещи

1) докер там активно использует снепшоты, а большое количество снепшотов для зфс так себе

2) не очень понятно насколько драйвер для зфс в докере вменяемый. информации ничтожно мало

в общем плюсов от zfs в 16.04 - я вообщем даже понимаю Космонавта - это очень серьезное и походу очень правильное решение было, вкупе с lxd - там громадные перспективы

а что под вменяемостью понимать?

драйвер в ядре, прослоек нет. Да там вроде есть баги про acl и все такое, но это актально темЮ кто самбу собрался гонять на zfs

ERROR: S client not available

насколько оно адекватно использует все возможности zfs

м, не правильно сказал, стораджадапетр то есть же

ну свои кейсы я выще описал, в кернел паник не уходил ни разу, при чем сижу с беты 16.04 работает быстро, но разумеется надо много памяти

много — для дедупликации или для ARC?

это слишком большой пласт для внедрения - тестирование всей конструкции займет много времени -по этому пока в такие дебри и не лезли

и много, это сколько? :)

у всех разные понятия много :)

кстати, про smartos, это который от joyent?

Много? Ну там же много кейсов - everybody wants backup nobody wants to rrestore - то есть надо моделировать отказ и потом восстанавливать, при чем не на малых данныхз

и это уже много времени получается на полноцененое внедрение

вы её как вообще деплоите? мне очень нравится идея, но после того как я почитал их доку по железным требованиям и понял что всё очень сложно

про много, я про память

ааа

чем больше тем лучше :))

на сторадже с 16tib 32 гига - уже тяжко

хотелось бы больше

но и так работает, по isci на мелких файла стабильно около 600 mib канал забит

локально тестить - надо еще понять как - поскольку как я поняль нельзя сказать -o direct

там очень все на память завязано

16тб у нас пока не будет, у нас основная проблема субд хранить, а там уже и так всё оптимизированно и я предпологаю около 10гб в месяц роста, так что далеко :)

1) докер там активно использует снепшоты, а большое количество снепшотов для зфс так себе

zfs насрать на количество снапшотов

кстати, про smartos, это который от joyent?

да

Мне кстати не очень понятно, overlayfs он поверх zfs будет работать?

нет

https://docs.docker.com/engine/userguide/storagedriver/zfs-driver/

точнее как, наверное конечно можно, но зачем

ммм... чтобы не дублировать?

так в zfs вместо слоёв снепшоты

про базу в контейнере - вопрос релизиозный, простой пример: автовакуум не отработал, в это время снашот - что в спаншоте, как стартанет потом с него?

про базу в контейнере - вопрос релизиозный, простой пример: автовакуум не отработал, в это время снашот - что в спаншоте, как стартанет потом с него?

потому что не надо так делать

а я и не делаю, я бекаплю со слейва :)