я сначала думал, что кубер сам фетчит последний образ докера, потом понял что видимо нет и надо делать kubectl rolling update, нашел блог, там человек говорит, что вызывать kubectl из cd сервиса моветон (докер-в-докере) и надо юзать helm репозиторий, я немножко запутался и решил спросить у вас как надо делать вот блог: http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/

аааааарх как меня достал фаервол и кубер и фланель, оно так просто ломаеться

аааааарх как меня достал фаервол и кубер и фланель, оно так просто ломаеться

нормально делай - нормально будет

нормально делай - нормально будет

R!

памажите советом девопсоны ><

памажите советом девопсоны ><

юзай helm :) и будет тебе счастье

юзай helm :) и будет тебе счастье

helm гавно

что лучше?

почему гавно?

почему гавно?

https://t.me/openstack_ru

при чем тут это?

Аналогов helm нет:) А гавно потому что баг на баге. То wait сломают, то изменения не применяются при upgrade

ну видимо мы его пока не в том масштабе используем, чтобы так критиковать. Если его правильно использовать, замены ему пока нет

Аналогов helm нет:) А гавно потому что баг на баге. То wait сломают, то изменения не применяются при upgrade

wait всё еще сломан?

Уже починили, но было неприятно когда сломали)

Сделали свой wait в итоге

ну то есть чтобы не наткнуться случайно на проблемки лучше напряму из kubectl делать rolling-update в CD?

Если нет ощущения, что helm сильно нужен, то можно без него. Просто делать apply для deployment. Update сам запустится

поддерживаю, если можно обойтись без helm, то лучше без него

Мы резко захотели helm, когда второй кластер появился

другое дело, что темплейтить ресурсы захочется очень быстро :)

другое дело, что темплейтить ресурсы захочется очень быстро :)

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

у нас есть generic-app chart где много разной магии. приложения это пустые charts (в них нет templates), они подтягивают generic-app как зависимость и переопределяют её переменные

ну я использую helm только для развертывания софта, и он в этом плане норм... а для деплоя я deis юзаю например

темплейты можно так же helm'ом описывать, helm-template'ом генерировать, пушить в репу, а потом с помощью kubectl применять

И хранить в репе манифесты для всех окружений?

если требуется почему нет, по бранчам например

но мы так не делаем)

не обязательно, например хранить только манифесты для прода

Чатик, у кого нить крон джобы в кубике работают?

Работают у меня. (1.5.2 версия) Нужно врубить альфа фичи в апи и в шелдулере.(или контроллер манагер точно не помню)

DarkNet - блог о темной стороне интеренета. @darknets

порноторренты? нелицензионные песни ваенги? спс не надо

DarkNet - блог о темной стороне интеренета. @darknets

посмотрел, посмеялся, спасибо

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

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

храним в отдельном локальном репо, вытягиваем перед апплаем

у нас прямо в приложении лежит

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

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

у нас гитлаб. Пайплайн хранится в виде конфига внутри гитлаба, но гитлаб сейчас с кубом не связан. Планируем увязать в дальнейшем

а ещё вопрос, пишут DIND порочная практика, но у меня, например, пока так, и образ, и apply куба вызываю в контейнере дженкинса. как вообще принято подобное обходить? я вот задумываюсь, стоит ли CI доверять куб, ну или хотя бы вынести это в отдельный пайплайн, а не в пайпе приложения всё делать

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

интересно сравнение с https://github.com/alexellis/faas

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

хмм, не пользуетесь?)

привет) пользуетесь https://github.com/fission/fission ? стабильно/нет?

Тестировали, работает, но не супер стабильно, в прод не решились

а ещё вопрос, пишут DIND порочная практика, но у меня, например, пока так, и образ, и apply куба вызываю в контейнере дженкинса. как вообще принято подобное обходить? я вот задумываюсь, стоит ли CI доверять куб, ну или хотя бы вынести это в отдельный пайплайн, а не в пайпе приложения всё делать

DIND порочная практика?

DIND порочная практика?

неоднократно читал и слышал. хотя сам практикую)

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

Мы все инфраструктурные штуки потихоньку выносим в отдельный репозиторий, который подключаем гит сабмодулем в 3 приложения. Хочется монорепозиторий, но пока морально не готовы.

Кроме самих приложений есть десятки системных чартов и образов, типа Prometheus и graylog. С ними автоматизация хромает. Сборка и деплой руками с локальной машины.

DIND порочная практика?

Он не может полностью функционировать как обычный докер, к сожалению

https://twitter.com/b0rk/status/872658092818927616 b0rk что-то задумала

Чатик, у кого нить крон джобы в кубике работают?

сегодня как раз заработали, у меня 1.5.3 версия. Нужно api server запускать с —runtime-config=batch/v2alpha1=true и порестартить kubelet дока https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

у меня celery для этого крутится

а есть какое-нибудь решение чтобы контейнеры билдить? например есть репы где код + докерфайлы для билда. можно как нибудь сбилдить имадж докера внутри куба?

gitlab runner + gitlab ci

http://docs.gitlab.com/ce/ci/runners/README.html ну и там дальше .gitlab-ci.yml ложится в репу где описываются все шаги. runner можно запускать просто как docker контейнер или внутри куба. Но если в кубе запускать, то там кажется не работал кеш докера между промежуточными билдами, а с dind тоже какая-то трабла была

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

или пока никак?

А реестр и приложения как в аписервере оказываются?

А kubelet, kube-dns не из этого registry запускаются?)

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

разворачивайте registry на стадии разворачивания куба. т.е. кластер не готов, пока в нем нет kube-dns, registry и прочих обязательных для вас вещей

кстатити сам не пробывал, но точно помню были баги на гитхабе о том, что registry внутри куба работает как-то плохо

что-то насчет того , что докер не мог тянуть имаджи из регистри, который запущен под этим же самым докером.

ERROR: S client not available

Котаны, смотрите какая пепяка. Есть кубернетес кластер (1.5.7 на данный момент), развёрнутый через kops на AWS. Кластер разработческий, на нём много редеплоев в день. На нодах докер 1.12.3. Через некоторое время лютейшим образом увеличивается время скачивания свежих образов через docker. Реджистри значения не имеет, с любого тянется медленно. При этом сеть в принципе на ноде не деградирует вовсе.

Куда бы вы копали?

Некоторое время это +/- сутки

потом не возвращается в нормальное состояние?

рестарт демона исправляет ситуацию?

Нет

причём аффектятся все ноды

рестарт демона лечит

я подозреваю какой-то неприятный баг в докере, конечно

ну pprof его

благо гошечка православная, легко снимать дампы

Наблюдаю подобное же с версии 17.04 у соседа)

Каждый день рестартует докер

Засирается арпкеш

Засирается арпкеш

о, спасибо

Засирается арпкеш

рестарт как arp cache чистит?

Никак, это временная мера

Только рестарт демона по крону

тогда рестарт не помогал бы, если б дело в arp cache, разве нет?

Просто резолв занимает много времени

Скорость по сети та же

Пробовали и no_proxy

И /etc/resolv.conf на хостмашине в гуглоднс направлять

Скорость по сети та же

тогда это другоэ

у меня именно качает медленно

сегодня как раз заработали, у меня 1.5.3 версия. Нужно api server запускать с —runtime-config=batch/v2alpha1=true и порестартить kubelet дока https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

у меня 1.6.1, апи запускал как доке с --runtime-config=batch/v2alpha1=true . Джоба появляется, но никогда не стартует. Попробую на следующей недели еще поколбасить.

у меня 1.6.1, апи запускал как доке с --runtime-config=batch/v2alpha1=true . Джоба появляется, но никогда не стартует. Попробую на следующей недели еще поколбасить.

может ноду подходящую найти не может для пода?

describe job что-нибудь говорит?

у меня 1.6.1, апи запускал как доке с --runtime-config=batch/v2alpha1=true . Джоба появляется, но никогда не стартует. Попробую на следующей недели еще поколбасить.

Я уже пытался разбираться в этой магии: https://github.com/kubernetes/kubernetes/issues/45418