Comments 41
Еххъ, куда не зайдешь посмотреть, все такие весёлые вещи про докер рассказывают…
А самое интересное — распределение портов, развертывание частей приложения на нескольких серверах (multi-host networking & overlay networking), service discovery, оркестровка — почти не обсуждается.
Сырой он пока, к сожалению. Из того, на что натыкался — случайные падения контейнеров при запуске, отваливание volume'ов при обновлении докера. Была ещё одна хорошая ядерная бага с неудачным уничтожением netns при остановке контейнера, приводящая к kernel panic, но это дистроспецифичное.
А самое интересное — распределение портов, развертывание частей приложения на нескольких серверах (multi-host networking & overlay networking), service discovery, оркестровка — почти не обсуждается.
Сырой он пока, к сожалению. Из того, на что натыкался — случайные падения контейнеров при запуске, отваливание volume'ов при обновлении докера. Была ещё одна хорошая ядерная бага с неудачным уничтожением netns при остановке контейнера, приводящая к kernel panic, но это дистроспецифичное.
Не могу сказать, что пост очень полезный, в нем явно побывал КО. Но то «самое интересное», о чем вы написали (сети, orchestration, discovery) — достаточно специфичные вопросы, не имеющие прямого отношения к докеру. Для каждой из этих проблем есть свои готовые и очень работоспособные решения. Нужны сети — можно смотреть weave или flannel. Нужен discovery — берете etcd, zookeeper и всякие прочие consul'ы. Orchestration — вообще отдельная тема, и контейнеры тут, по-сути, не вносят ничего нового — в крайнем случае, никто не мешает раскатывать контейнеры тем же ansible или puppet/mcollective. Все эти вопросы каждый решает по-разному, и скорее всего, исходит из уже имеющейся инфраструктуры.
А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
Про KO вы правы, но KO побывал до того и у вас, и теперь вам это очевидно. Статья для тех, у кого КО не частый гость. Да и если заходит, про Docker не беседует.
А я ж не против. Я отнюдь не критикую ваш пост, и более того, считаю его достаточно полезным в плане расстановки акцентов. Докер сейчас каждый интерпретирует как угодно и пытается им заткнуть любые свои проблемы. Вы вполне конкретно делаете упор на то, что докер — средство доставки релизов на сервер. Капитанское утверждение? Я думаю, что да. Но тем не менее, люди пытающиеся использовать докер, почему-то часто игнорируют это самое основное предназначение докера. И я уверен, что с этой точки зрения Ваш пост окажется этим людям полезен.
Я (неявно) подразумевал лишь то, что про докер, как про новую, сырую технологию, лучше писать не в духе «как Вам нужно сделать», а «как мы сами сделали, что у нас было изначально, и почему в итоге у нас получилось так, как есть» =)
Я (неявно) подразумевал лишь то, что про докер, как про новую, сырую технологию, лучше писать не в духе «как Вам нужно сделать», а «как мы сами сделали, что у нас было изначально, и почему в итоге у нас получилось так, как есть» =)
А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
bugzilla.kernel.org/show_bug.cgi?id=65191
bugs.centos.org/view.php?id=8039
bug info
0008039: kernel crash in netns cleanup_net (nf_nat_cleanup_conntrack)
Kernel crashes after several days (about 3-4 days in my case). I have some short-lived docker containers (created and destroyed every 15 mins), so it's netns is destroyed every 15 mins.
[289778.843818] Call Trace:
[289778.843865] [] __nf_ct_ext_destroy+0x44/0x60 [nf_conntrack]
[289778.843923] [] nf_conntrack_free+0x25/0x60 [nf_conntrack]
[289778.843976] [] destroy_conntrack+0xbd/0x110 [nf_conntrack]
[289778.844031] []? nf_conntrack_helper_fini+0x30/0x30 [nf_conntrack]
[289778.844102] [] nf_conntrack_destroy+0x17/0x20
[289778.844168] [] nf_ct_iterate_cleanup+0xcb/0x160 [nf_conntrack]
[289778.844237] [] nf_ct_l3proto_pernet_unregister+0x1d/0x20 [nf_conntrack]
[289778.844308] [] ipv4_net_exit+0x19/0x50 [nf_conntrack_ipv4]
[289778.844368] [] ops_exit_list.isra.1+0x39/0x60
[289778.844423] [] cleanup_net+0x110/0x260
[289778.844480] [] process_one_work+0x17b/0x460
[289778.844524] [] worker_thread+0x11b/0x400
[289778.844574] []? rescuer_thread+0x400/0x400
[289778.844624] [] kthread+0xcf/0xe0
[289778.844669] []? kthread_create_on_node+0x140/0x140
[289778.844730] [] ret_from_fork+0x7c/0xb0
[289778.844773] []? kthread_create_on_node+0x140/0x140
Kernel crashes after several days (about 3-4 days in my case). I have some short-lived docker containers (created and destroyed every 15 mins), so it's netns is destroyed every 15 mins.
[289778.843818] Call Trace:
[289778.843865] [] __nf_ct_ext_destroy+0x44/0x60 [nf_conntrack]
[289778.843923] [] nf_conntrack_free+0x25/0x60 [nf_conntrack]
[289778.843976] [] destroy_conntrack+0xbd/0x110 [nf_conntrack]
[289778.844031] []? nf_conntrack_helper_fini+0x30/0x30 [nf_conntrack]
[289778.844102] [] nf_conntrack_destroy+0x17/0x20
[289778.844168] [] nf_ct_iterate_cleanup+0xcb/0x160 [nf_conntrack]
[289778.844237] [] nf_ct_l3proto_pernet_unregister+0x1d/0x20 [nf_conntrack]
[289778.844308] [] ipv4_net_exit+0x19/0x50 [nf_conntrack_ipv4]
[289778.844368] [] ops_exit_list.isra.1+0x39/0x60
[289778.844423] [] cleanup_net+0x110/0x260
[289778.844480] [] process_one_work+0x17b/0x460
[289778.844524] [] worker_thread+0x11b/0x400
[289778.844574] []? rescuer_thread+0x400/0x400
[289778.844624] [] kthread+0xcf/0xe0
[289778.844669] []? kthread_create_on_node+0x140/0x140
[289778.844730] [] ret_from_fork+0x7c/0xb0
[289778.844773] []? kthread_create_on_node+0x140/0x140
Ну про оркестровку я пожалуй, в понедельник пост попробую выкатить, когда n+ сервер и надо этим всем управлять, у меня немного наработок на эту тему есть
Приватный docker registry, скажу я вам, штука оч. сырая. Как его, например почистить? Удалить ненужные образы. А хрена с два!!! Текущая версия 0.9, а удаление обещают только в 2.0…
У меня вот такой чайниковый вопрос. Я с докером пока не работал, вполне допускаю, что вопрос имеет простой ответ, но сходу я как-то его не нашёл.
Предположим, у есть 100500 сервисов, каждый в своём контейнере, всё работает. Внезапно в openssl находят критический баг, нужно его срочно обновить. Openssl используется, скажем, в 100400 из 100500 контейнеров. Как правильно произвести обновление?
Предположим, у есть 100500 сервисов, каждый в своём контейнере, всё работает. Внезапно в openssl находят критический баг, нужно его срочно обновить. Openssl используется, скажем, в 100400 из 100500 контейнеров. Как правильно произвести обновление?
Самый очевидный ответ, это перебилдить образы из которых развернуты контейнеры. И перенакатить контейнеры. В реальной жизни 100400 контейнеров в которых уязвимость можно эксплуатировать не бывает. Придется скорее всего обновить пару тройку образов, и просто запутить их. Ну это все задачаспецифично.
Спасибо!
И как этот процесс выглядит в реальной жизни? В той, в которой интернет сломан, и обновлять образы из соображений безопасности нередко нужно практически ежедневно (во время shellshock у меня пакет с bash обновился, по-моему, 4 раза за одни сутки).
Сейчас у нас есть, предположим, 3-4 группы однотипно настроенных серверов. И внутри каждой группы гетерогенность среды поддерживается не ради ленивого DevOps, а потому, что абсолютно нереально уследить за настройками, безопасностью и стабильностью обновлений нескольких десятков серверов если все они разные. И здесь не имеет абсолютно никакого значения, физические это сервера, или виртуальные — если в каждом, фактически, полноценная ОС с полным окружением и при этом она настроена под специфические нужды одного работающего в ней приложения, то с точки зрения обновления ОС мы имеем необходимость регулярно обновлять столько разных ОС, сколько у нас используется разных приложений и разных версий одного приложения.
Сейчас у нас есть, предположим, 3-4 группы однотипно настроенных серверов. И внутри каждой группы гетерогенность среды поддерживается не ради ленивого DevOps, а потому, что абсолютно нереально уследить за настройками, безопасностью и стабильностью обновлений нескольких десятков серверов если все они разные. И здесь не имеет абсолютно никакого значения, физические это сервера, или виртуальные — если в каждом, фактически, полноценная ОС с полным окружением и при этом она настроена под специфические нужды одного работающего в ней приложения, то с точки зрения обновления ОС мы имеем необходимость регулярно обновлять столько разных ОС, сколько у нас используется разных приложений и разных версий одного приложения.
Создать новые образы, запустить инстансы с новых образов, завернуть на них траффик, стопнуть инстансы каждого старого образа, дропнуть старые образы,
Или же собирать автоматически. Я не нашел ничего, что собирает контейнеры, поэтому вот, есть мною собранный велосипед под названием lumper
packer.io/docs/builders/docker.html
Вы его пробывали? Как ваши ощущения? Как работа с Docker Registry? Если быть честным, я не нашел ничего что собирает контейнеры как мне нужно. Потому и еще один велосипед на гитхабе. И я честное слово, никому его не навязываю. Наоборот — вскользь упоминаю.
Я оставил ссылку с целью обратить Ваше внимание и внимание читателей на этот проект, а не высмеивать Ваш велосипед. Я по началу так же сел писать скрипт, но потом нашел вот этот проект.
В продакшене не использую еще контейнеры, но активно к этому готовлюсь, собственно именно поэтому и заинтересовала Ваша статья. Обязательно напишу свою, как буду тестировать.
Исходя из статьи, Вам нужно немногим более, чем tag и push. Это все отлично делается через пост-процессоры. Логин и тп настройки поддерживаются, так что с приватным хабом проблем не будет.
Имейлы не шлет, это да :-)
В продакшене не использую еще контейнеры, но активно к этому готовлюсь, собственно именно поэтому и заинтересовала Ваша статья. Обязательно напишу свою, как буду тестировать.
Исходя из статьи, Вам нужно немногим более, чем tag и push. Это все отлично делается через пост-процессоры. Логин и тп настройки поддерживаются, так что с приватным хабом проблем не будет.
Имейлы не шлет, это да :-)
«Вы DevOps на постоянной основе.… Почему заменять — вам не ведомо. Скорее всего «как обычно криворукий» разработчик написал только для libxx, и вместе с libyy оно не работает.
…
Представим себе банальную ситуацию, вы все тот же DevOps,… собираете его привычным методом, запускаете и… не работает. Связываетесь с разработчиком, ругаете его по первое число, что он как обычно «криворук». А он вам все обратно, и «криворук» уже вы. У разработчика все работает. С точки зрения вашего начальника, вы не можете запустить проект. Именно вы. Так как тестировщики, проект, развернутый на компьютере разработчика, все приняли.»
Хм, не пробовали DevOps?
en.wikipedia.org/wiki/DevOps
> DevOps is a software development method that stresses communication, collaboration, integration, automation and measurement cooperation between software developers and other information-technology (IT) professionals.
…
Представим себе банальную ситуацию, вы все тот же DevOps,… собираете его привычным методом, запускаете и… не работает. Связываетесь с разработчиком, ругаете его по первое число, что он как обычно «криворук». А он вам все обратно, и «криворук» уже вы. У разработчика все работает. С точки зрения вашего начальника, вы не можете запустить проект. Именно вы. Так как тестировщики, проект, развернутый на компьютере разработчика, все приняли.»
Хм, не пробовали DevOps?
en.wikipedia.org/wiki/DevOps
> DevOps is a software development method that stresses communication, collaboration, integration, automation and measurement cooperation between software developers and other information-technology (IT) professionals.
Хм, не пробовали DevOps?
Пробовали, именно поэтому так и написал. Когда в вашей компании уже есть админы, их сложно переквалифицировать в программистов, которые работают по методу DevOps. Да и NOC все равно не будет программировать, а любой компании где есть железо просто необходим NOC. Отсюда и получаются «DevOps на постоянной основе». Хотите, давайте назовем их программисты инфрастуктуры?
automation and measurement cooperation between software developers and other information-technology (IT) professionalsПочему этим не может заниматься отдельный человек?
Почему этим не может заниматься отдельный человек?
Судя по википедии девопс это взаимодействие, интеграция, и кооперация. Для всех этих вещей нужно как минимум 2 субъекта. Поэтому этим не может заниматься отдельный человек.
Программировать инфраструктуру один человек конечно может.
Вы походу не поняли в чем смысл этой концепции. Она не про то, что админы должны программировать, она про то, что админы и программисты — часть одной комманды, а не двух, которые вечно футболят друг друга с резолюшном «проблема не на моей стороне».
Как в эту концепцию укладываются ребята, делающие IPSecи и Cisco IOSы для инфраструктуры? Концепцию я прекрасно понимаю, и стараюсь всем разработчикам вокруг себя задавать вопросы на митингах вроде:
А как это должно взлетать? А сколько компонентов требуется для тестирования? А как это масштабировать горизонтально? А как ты думаешь, что в твоем решении бутылочное горлышко? А что мы будем резервировать, и как твой модуль будут работать с этим «резервированием»?
Просто DevOps из википедии, как методика, работает только в стартапах. В компаниях чаще всего нет ресурсов чтобы каждой команде нанаять девопса. Обычно есть штат девопсов и их вводят в команду разработчиков так: «Ребята, это Вася. Он наш девопс и будет заниматься CI и деплоем. А еще он будет вместе с вами писать для этого код.»
Опять-же чисто личный опыт. Вы просто представьте, вот есть у вас junior. Он пишет вам JS. Расскажете ему как ваши бекенды раздают его js? Или расскажите как настраивать nginxы? Конечно нет, вы скажете Васе: «Вася, поможешь автоматизировать деплой статики для нашего junior фронтендера?»
И в конечном итоге, DevOps не работает.
А как это должно взлетать? А сколько компонентов требуется для тестирования? А как это масштабировать горизонтально? А как ты думаешь, что в твоем решении бутылочное горлышко? А что мы будем резервировать, и как твой модуль будут работать с этим «резервированием»?
Просто DevOps из википедии, как методика, работает только в стартапах. В компаниях чаще всего нет ресурсов чтобы каждой команде нанаять девопса. Обычно есть штат девопсов и их вводят в команду разработчиков так: «Ребята, это Вася. Он наш девопс и будет заниматься CI и деплоем. А еще он будет вместе с вами писать для этого код.»
Опять-же чисто личный опыт. Вы просто представьте, вот есть у вас junior. Он пишет вам JS. Расскажете ему как ваши бекенды раздают его js? Или расскажите как настраивать nginxы? Конечно нет, вы скажете Васе: «Вася, поможешь автоматизировать деплой статики для нашего junior фронтендера?»
И в конечном итоге, DevOps не работает.
И в конечном итоге, DevOps не работает.Просто он из методологии для программистов и админов, которая может сработать в некоторых компаниях, вырождается в отдельную профессию, которая сработает везде.
У нас в стартапе был админ, к которому пришли и сказали: теперь ты девопс. И, вы знаете, он очень быстро стал разбираться в тонкостях разработки и при этом понимал администрирование. Админ, естественно, тоже появился, но другой человек.
И вы ещё забываете про отдел тестирования, с ним тоже нужно уметь взаимодействовать.
По вашим сообщениям я понимаю, что у вас просто неправильно их, DevOps'ов готовили. Либо же люди не смогли переключиться с разработки/администрирования/тестирования/DBA/NOC на менеджмент. Я лично знаю нескольких бывших руководителей, которые добровольно ушли в обычных программистов, т.к. осознали, что не могут заниматься менеджментом.
DevOps — это маленький технический директор, если корректно проводить параллели.
И вы ещё забываете про отдел тестирования, с ним тоже нужно уметь взаимодействовать.
По вашим сообщениям я понимаю, что у вас просто неправильно их, DevOps'ов готовили. Либо же люди не смогли переключиться с разработки/администрирования/тестирования/DBA/NOC на менеджмент. Я лично знаю нескольких бывших руководителей, которые добровольно ушли в обычных программистов, т.к. осознали, что не могут заниматься менеджментом.
DevOps — это маленький технический директор, если корректно проводить параллели.
Насчет dependency hell — всё решаемо, вот только затратно по времени. Можно пакет обозвать как libxxx2 вместо libxxx-2, положить саму библиотеку в /usr/lib64/libxxx.so.2 вместо /usr/lib64/libxxx.so. Да, придется программистам сказать, чтобы при сборке приложения явно указывали версию.
Вопрос любителям Docker'а, а многие ли используют Docker + rpm/deb? Если собирать приложение/библиотеку непосредсвтенно в контейнере из исходников, то получаем большой оверхед по *-dev зависимостям, кои нам не очень то и нужны при работе в production. Пакетировние же помогает этих зависимостей избежать.
Вопрос любителям Docker'а, а многие ли используют Docker + rpm/deb? Если собирать приложение/библиотеку непосредсвтенно в контейнере из исходников, то получаем большой оверхед по *-dev зависимостям, кои нам не очень то и нужны при работе в production. Пакетировние же помогает этих зависимостей избежать.
Я использую Docker + пакеты. Делаю два отдельных образа: сборочный со всеми зависимостями для сборки (в том числе RPM/deb) и образ для запуска приложения (только runtime зависимости). Второй, конечно же, будет заметно меньше первого.
Насчет dependency hell — всё решаемо, вот только затратно по времени.Вы же знаете, что это самый дорогой и невосполнимый ресурс?
Я использую Docker для сборки проектов (не самая очевидная, но очень удобная идея: скачав из локальной корп. сети заранее подготовленный сборочный образ можно собрать проект на любой машине с Docker), быстрого разворачивания демо-стендов и интеграционного тестирования.
Интересно, как сама эволюция библиотечного подхода сейчас «расщепляется» на два варианта. Изначально была простая идея, что реюзать библиотеку — это круто. Сохраняет место. Упрощает админинье (пофиксил openssl — и у тебя все что с openssl — сразу «само» пофиксилось).
А Докер, virtualenv и прочие — в обратную сторону идут. И тоже вроде логично и обоснованно, ибо самая свежая либа не всегда так уж однозначно лучше предыдущей.
А Докер, virtualenv и прочие — в обратную сторону идут. И тоже вроде логично и обоснованно, ибо самая свежая либа не всегда так уж однозначно лучше предыдущей.
С сетью конечно там пока печально
А зачем вам там сеть, если не секрет? Мне кажется, что то, что там есть сейчас полностью покрывает все кейсы его применения.
Как я помню он настройки днс не сохраняет, да и хостнейм, это так на вскидку. В общем если проще ту нужно велосипеды прикручивать чтоб всё гладко работало, я не говорю что это плохо, не поймите меня не правильно, просто пока ещё не доросли до конкурентоспособного решения, я конечно буду на него посматривать регулярно, но пока увы на уровне эксперимента.
Хостнейм не должен пробрасываться, поскольку докер явно изолирует сеть для контейнера. Если очень нужен хостнейм сервера, его несложно пробросить внутрь приложения, например, флагом.
С DNS сложнее, в нашем случае пришлось явно в маунтах пробрасывать для контейнера сокет nscd.
Крупный продакшн, всё работает.
С DNS сложнее, в нашем случае пришлось явно в маунтах пробрасывать для контейнера сокет nscd.
Крупный продакшн, всё работает.
поскольку Docker registry это, мягко говоря, кусок не очень хорошего приложения, рекомендую посмотреть на Artifactory, настоящий бинарный репозиторий с полной поддержкой Docker. (дисклеймер — я оттуда).
Класс. Было бы круто, если бы вы или сами написали, как это развернуть у себя на сервере (с поддержкой докера разумеется). Или дали годный tutorial. С огромным удовольствием добавил бы это в саму статью.
В принципе Артифактори ставится простым unzip-ом.
Но, конечно, с Докером всё непросто. Из-за достаточно странного решения, что хост: порт откуда скачивать и куда заливать являются частью тэга, поддержка нескольких репозиториев в одном менеджере становится сложной.
Артифактори по дефолту устанавливается под host:port/artifactory/название-репозитория, a в докере можно только host:port.
Решается это с помощью апача/нжникса с virtual host, это всё достаточно подробно прописано, но всё равно не фан ни разу.
Хорошие новости состоят в том, что на следующей неделе можно будет просто установить Docker image Артифактори, полностью сконфигурированным под Докер (ждем поддержку Докера в Бинтрее, чтобы скачивать оттуда).
Я скину линк, когда будет.
Но, конечно, с Докером всё непросто. Из-за достаточно странного решения, что хост: порт откуда скачивать и куда заливать являются частью тэга, поддержка нескольких репозиториев в одном менеджере становится сложной.
Артифактори по дефолту устанавливается под host:port/artifactory/название-репозитория, a в докере можно только host:port.
Решается это с помощью апача/нжникса с virtual host, это всё достаточно подробно прописано, но всё равно не фан ни разу.
Хорошие новости состоят в том, что на следующей неделе можно будет просто установить Docker image Артифактори, полностью сконфигурированным под Докер (ждем поддержку Докера в Бинтрее, чтобы скачивать оттуда).
Я скину линк, когда будет.
Артифактори по дефолту устанавливается под host:port/artifactory/название-репозитория, a в докере можно только host:port.Странно докеровцы как раз говорят что host:port/repo/project. Зачем host:port/artifactory/ ???
Эти repo/project будут уже в рамках docker registry (также можно использовать просто project, если вы держите свой репозиторий).
Т. е. докер считает, что репозиторий доступен от корня (host:port), а artifactory разносит разные репозитории (например, докер и мавен) по разным путям.
Пусть докер-репозиторий доступен на artifactory-host:port/docker/. Если выполнить docker pull artifactory-host:port/docker/some-project, то докер побежит дергать artifactory-host:port/v1/_ping, что не даст ему ожидаемого ответа, после чего решит, что это не репозиторий. Вообще, федерализация и доступ к репозиториям — одна из важных причин возникновения appc/rocket.
Т. е. докер считает, что репозиторий доступен от корня (host:port), а artifactory разносит разные репозитории (например, докер и мавен) по разным путям.
Пусть докер-репозиторий доступен на artifactory-host:port/docker/. Если выполнить docker pull artifactory-host:port/docker/some-project, то докер побежит дергать artifactory-host:port/v1/_ping, что не даст ему ожидаемого ответа, после чего решит, что это не репозиторий. Вообще, федерализация и доступ к репозиториям — одна из важных причин возникновения appc/rocket.
Получается что artefactiory не совсем поддердивает докер.
Sign up to leave a comment.
Как жить с Docker, или почему лучше с ним, чем без него?