werf - наш инструмент для CI/CD в Kubernetes (Дмитрий Столяров, Флант, DevOpsConf 2019)

[@AlexandrKozhin]

Доклад как всегда отличный. Всегда с удовольствием слушаю. Куча опыта синтезированного в кейсы, без воды и тягомотины. Спасибо.

[@DziuCasTV]

Обожаю его доклады

[@bigvandi]

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

[@freundallein9646]

Как всегда отлично. Спасибо.

[@fabasoad]

Мониторы перестали работать именно когда пришло время рассказывать про werf 😄 это саботаж! 😂 Шучу, но на самом деле эта техническая заминка сбила и меня как слушателя, и немного докладчика тоже 😰 но вообще отличный доклад. С удовольствием послушал. Спасибо 💪

[@eugenechernyshenko4933]

Уверен что вы знаете, просто сказали как будто этого в хельме нет, но у хельма же есть --wait. --wait: Waits until all Pods are in a ready state, PVCs are bound, Deployments have minimum (Desired minus maxUnavailable) Pods in ready state and Services have an IP address (and Ingress if a LoadBalancer) before marking the release as successful. It will wait for as long as the --timeout value. If timeout is reached, the release will be marked as FAILED. Note: In scenario where Deployment has replicas set to 1 and maxUnavailable is not set to 0 as part of rolling update strategy, --wait will return as ready as it has satisfied the minimum Pod in ready condition. helm.sh/docs/intro/using_helm/

[@davidmagton]

Привет. Очень обидно, но к сожалению это настолько не юзабельно, что можно считать, что его там нет. Во-первых timeout - если маленький, то получаются false-позитивы, если большой - то чрезмерно долгое ожидание ошибки. Во-вторых обратная связь - совсем не понятно, чего ждем, совсем не понятно, почему упало. То есть поставили timeout в 10 минут, через 10 секунд уже понятно, что образ не может pull'нуться, но мы будем висеть 10 минут и ждать. Просто попробуйте этим воспользоваться.

[@eugenechernyshenko4933]

@@davidmagton очень развернутый ответ, да действительно все эти грабли собирали. Попробовали kubedog, нам понравилось! Спасибо

[@xonicov]

@@eugenechernyshenko4933 На самом деле спасибо за комментарий.

[@xonicov]

@@davidmagton И спасибо за ответ, потому что было не понятно чем плох --wait

[@aapotokin]

10:30 нет, мы ставим вперед всего этого set -x et voila

[@xonicov]

Кстати спасибо

[@tumarsal]

На 25 мин видео говорится что можно сделать слой с метаданными и далеее об этом не вспоминается. Можно об этом по подробнее?

[@timofeykirillov1158]

Имеется в виду вот что. Werf сначала собирает набор stages. Stages выступают в роли кеша. Затем идет т.н. процедура публикации. При процедуре публикации пользователь выбирает стратегию тегирования - эта штука влияет на то как будет именоваться итоговый образ в docker registry и влияет на то по каким правилам его надо будет чистить (например, образы собранные из git-tag хранятся в количестве не более N штук, не более какого-то времени; образы собранные из git-branch хранятся пока в git существует этот branch и т.п.). Так вот служебная информация о выбранной схеме тегирования сохраняется в специальном слое поверх stages, из которого уже получается итоговый опубликованный image. Статьи для справки: * werf.io/documentation/reference/stages_and_images.html * werf.io/documentation/reference/publish_process.html

[@tumarsal]

@@timofeykirillov1158 Спасибо.

[@alexleyn]

46:10 в первом ряду опытный Ops сидит. Даже костыли всегда с собой носит.

[@spiritcxz]

так и не понял для чего werf нужен. Мы юзаем GitLab CI/CD..

[@dmitriysolodukha9646]

Офигенный доклад! Пойду изучу верфь :) Кстати, а Terraform не делает то же что и верфь?

[@Flant]

TerraForm ­- это про *инфраструктуру* вообще, это IaC для развёртывания буквально всех серверов, виртуалок и т.д. werf - это про цикл *доставки приложений* вообще и про Kubernetes-инфраструктуру для их деплоя в частности. В werf реализуется весь цикл доставки приложения: сборка Docker-образов, потом их публикация в реестре контейнеров, потом их деплой в Kubernetes, а затем - поддержка этого цикла как GitOps (по новому коммиту изменения снова выкатываются вместо старых образов; старые образы из реестра удаляются). В смысле инфраструктуры/деплоя werf подразумевает, что Kubernetes у вас уже где-то запущен и работает, а werf в нем только разворачивает ресурсы (которые нужны для запуска собранного приложения).

[@dmitriysolodukha9646]

@@Flant огромное спасибо за подробный комментарий! Очень полезно.

[@yoshiekb1]

если чо, RUN set -x && ... чтобы не гадать где упало :) kzbin.info/www/bejne/mXyWkpahfLqHgtk

[@spiritcxz]

что делает set -x?

[@yoshiekb1]

@@spiritcxz печатает выполняемые команды

[@alexromanov9437]

40:55 - failures-allowed-per-reLplica - typo, extra "l" in replica

[@dobermanpharaoh7567]

Очень и очень интересно, но нихрена не понятно 😁 (я фронт))

[@greentubedog]

Ребята, спасибо! вопрос вот по этому моменту kzbin.info/www/bejne/mXyWkpahfLqHgtk я понимаю такую структуру папок кода: service1/ helm/ ansible/ прочий_код_сервиса/ ... service2/ helm/ прочий_код_сервиса/ ... service3/ helm/ прочий_код_сервиса/ ... в папках helm чарты для деплоя конкретного сервиса (это может быть не helm, а просто набор yml-ек для kubectl) в чарте деплоймент в котором написано как запускать сервис (если не helm то запуск просто в деплойменте) и здесь вопросы: 1. правильно-ли я понимаю структуру папок кода 2. IaaC build - про Dockerfile идёт речь? 3. IaaC run - этим разве не helm или просто набор yml-ек это решает? не совсем понимаю зачем нужно деплоить через api куба, если есть helm и kubectl и они уже умеют это делать

[@alexeyigrychev6613]

> 1. правильно-ли я понимаю структуру папок кода В приведённом примере не хватает конфигураций сборки сервисов (2.). В случае с Docker, это может быть отдельный Dockerfile для каждого сервиса, а в случае werf, werf.yaml в корне проекта для всего приложения. Что касается выката приложения, то правильнее описывать выкат для всего приложения в рамках одного чарта. > 2. IaaC build - про Dockerfile идёт речь? Да, это может быть Dockerfile, werf.yaml или конфигурация инфраструктуры и приложения альтернативного сборщика. > 3. IaaC run - этим разве не helm или просто набор yml-ек это решает? не совсем понимаю зачем нужно деплоить через api куба, если есть helm и kubectl и они уже умеют это делать В первую очередь надо понимать, что есть выкат приложения и в какой момент можно считать приложение выкаченным. Что касается helm и kubectl, это инструменты с определённой областью применения и исключительно на них правильный выкат построить не получится. Часть проблем освещена в докладе. Мы предлагаем комплексное решение и стараемся исключить необходимость использования других решений, как при разработке/отладке, так и при штатной работе. Почитать о выкате с помощью werf, а также об основных отличиях от Helm можно в соответствующих статьях нашей документации: * werf.io/documentation/reference/deploy_process/deploy_into_kubernetes.html * werf.io/documentation/reference/deploy_process/differences_with_helm.html

[@greentubedog]

@@alexeyigrychev6613 спасибо за ответы

[@maddjimi8854]

доклад хороший, но зачем же так дёргаться то? :)

[@bigvandi]

ну волнуется человек

[@НикитаДавыдов-д3ь]

Все комментаторы смогли бы выйти на сцену только в подгузниках