Первый открытый митап сообщества: представили DevOps Райффайзенбанка в цифрах, узнали про особенности применения ELK-стека в СБЕРе и об организации продуктовой разработки без DevOps-инженеров в ОТП Банке.

О чем поговорили

Особенности применения ELK-стека в СБЕРе

Сергей Артюхов и Павел Паранин

История про то, как мы построили несколько кластеров ELK для работы с данными производственного процесса и к чему это привело.

В докладе мы рассмотрели архитектуру ETL-процесса на стеке ELK+Kafka. Посмотрели на особенности работы с DevOps-инструментами СБЕРа (Nexus, BitBucket, Jira, Confluence, Jenkins, Sonar). Проговорили особенности работы с Legacy и узнали, какой путь нас ждет. Также затронули вопросы применения (и использования) централизованного сбора данных процесса разработки ПО для расчета DORA-метрик (LT, DF, MTTR, CFR).

ПРЕЗЕНТАЦИЯ

DevOps в Райффайзенбанке в цифрах

Сергей Печенко и Евгений Харченко

Рассказали о темпах миграции в GitlabCI. Показали среднее количество запущенных пайплайнов за сутки, за месяц и за все время. Рассказали о темпах роста разработки и непрерывной трансформации в Райффайзенбанке: что нам дает трансформация и что изменилось.

ПРЕЗЕНТАЦИЯ

Делаем DevOps без DevOps-инженеров в ОТП Банке

Константин Курочкин

Организация продуктовой разработки без DevOps-инженеров.

В докладе рассказал, как в ОТП Банке продуктовые команды организовали DevOps, с какими трудностями столкнулись и что из всего этого получилось на данный момент.

ПРЕЗЕНТАЦИЯ

ОТВЕТЫ НА ВОПРОСЫ

Вопрос: Какой рантайм используете для куба?

Ответ: Рантайм для куба — часть на docker-е, часть, которая более новые, или более продвинутые товарищи на containerd.

Вопрос: Как обновляете куб?

Ответ: Как обновляем куб — через плейбук kubepsray-а upgrade-cluster.yml. То есть абсолютно дефолтный способ апргейда для этого инструмента. Некоторые части кластера (например ingress-nginx или cloud-controller-ы) ставятся и обновляются через Helm.

Вопрос: Смотрели ли вы на другие решения кроме kubespray? Почему выбрали именно его и как устроена политика и стратегия обновления кубов? Если да, то кто ответственный за этот процесс?

Ответ: Другие решения смотрели. Ключевые требования которые мы выдвигали - это возможность кастомизации под требования ИБ, которые не было понятны к тому моменты, а также возможность ставится на разных окружениях. У нас была часть ВМок в облаке, часть ВМок в vSphere. С каждой платформой надо было как-то интегрироваться. Kubespray предлагал эту интеграцию из коробки, а также давал в перспективе допилить если что-то понадобится настройками — хитрые флаги для kubeapi, например, или кастомные PodSecurityPolicies. Опыт показал, что Кубспрей конечно все это может, но задачу ничуть не облегчает ничуть. В итоге пришли к тому, что полагаться на встроенные в него модули (например интеграцию с vSphere или Openstack-ом и даже Ingress) не стоит. У них старые версии и они глючно ставятся. В итоге, все равно пришли к тому, что эти модули ставить приходится отдельно Helm-ом. Стратегия обновления кубов — поправить переменные Kubepray-а, запустить cluster-upgrade, прорешать возникшие проблемы вручную.