Environment as a Service
Александр Призов и Максим Огрызков из Яндекс.Денег рассказали об особенностях эксплуатации и оркестрации высоконагруженных инсталляций OpenStack для разных типов тестовой среды.
Таймкоды с подробностями
О нашем подходе
0:20 — Что такое Environment as as Service?
1:00 — Как подготовить инфраструктуру к изменениям?
1:30 — Что делать со старыми тестовыми стендами?
3:55 — Требования к новым тестовым стендам
4:30 — Почему мы выбрали OpenStack? Немного о Murano
5:50 — Про наш подход к автоматизации создания тестовых схем
7:30 — Пример декларативного описания выкладки
8:20 — Про Jenkinks, Grafana, kibana и отслеживание обновлений
9:10 — К каким цифрам мы пришли?
OpenStack и highload
9:40 — Что случилось, когда мы подняли 50 виртуальных машин одновременно?
11:25 — Нужно разносить выполнение cron-задач. О работе планировщика
Neutron и highload
13:45 — Мы используем dual stack. Что это такое, и почему там не нужен NAT?
15:33 — Бывает, что функциональности инструмента не хватает. Что можно сделать?
18:00 — Много разных сервисов, которые затрагивают работу друг друга. Как быть?
22:00 — Пишите код как документацию. Как мы нашли настройку, которой нигде нет
23:35 — Решение «no response to inactivity probe after 10 seconds, disconnecting»
25:31 — Как настроить размер mac-таблицы
26:00 — Как включить rx-flow-hash
26:37 — О глобальных и персональных правилах безопасности
Pod, Cloud and two Smoking Hubs
Алексей Бойко из Wrike рассказал, как они сэкономили время и деньги на масштабировании Selenium-фермы за счёт использования Google Cloud Engine и Kubernetes.
Таймкоды с подробностями
Предыстория
0:15 — Что такое Wrike и где там Selenium
2:20 — Что было у Wrike, когда появилась задача масштабирования?
3:20 — Очереди в браузеры, отказы Selenium Hub и медленный пак регрессионных тестов
4:50 — Требования к масштабированию и способы их реализации
7:30 — Почему выбрали Google Cloud: kubernetes, короткоживущие ноды и экономия?
8:50 — Почему выбрали kubernetes?
Про то, как смешать коктейль из технологий
9:50 — Про autoscaling и зачем нужен?
12:00 — Как работает автомасштабирование
14:40 — Preemptible nodes — низкая цена и опасные ограничения
18:00 — Зачем нужен балансировщик нагрузки?
19:00 — Как всё это работает вместе. TeamCity.
21:00 — Роль TeamCity в процессе
21:30 — Подробное описание процесса
23:40 — Что получили в итоге?
CI vs CD: гонка вооружений
Василий Созыкин (экс-Яндекс.Деньги), Дмитрий Зинин (Яндекс.Деньги)
Приводим описание доклада от авторов без изменений.
Война. Суть войны никогда не меняется, а вот релизный цикл, автоматизация и микросервисы — сколько угодно.
Начало. Раньше спокойно жилось с релизами раз в месяц, но потом этот хрупкий мир пошатнулся.
Хроника. Когда стало по сорок релизов в день, отношения разработки и эксплуатации начали накаляться. Это привело к вооружению сторон, новым инструментам автоматизации и оптимизации и симметричным ответам.
Перезагрузка. Стороны заключили мирное соглашение, и противостояние осталось в прошлом.
Заложники войны. Мирному населению из соседних отделов во время противостояния пришлось не сладко.
Таймкоды с подробностями
1:40 — О роли регуляторов в автоматизации финтеха
3:10 — «Релизинг», когда компонентов и разработчиков мало
4:30 — Распределение ролей при релизах
6:40 — Nexus, Gradle, jacoco и мокренькая кисонька
8:50 — Jenkins и два релиза в день
9:30 — Автоматизация интеграционного и нагрузочного тестирования. Зона 21.
10:15 — Дежурный по релизам. Зачем он нужен?
11:10 — Ansible Playbook для релизов
12:20 — Об отмене «релизного комитета». Автоматизация уведомлений
13:30 — Новое распределение ролей при релизах. Два релиза в неделю.
14:30 — И два релизных мастера. А это-то зачем?
16:00 — 20 релизов в день и наш первый бот.
18:00 — Релизы по коммиту. Каждые 30 минут.
19:00 — Многопоточная выкладка со стороны CD
20:30 — Про CI и CD без людей
21:50 — Про будущее релизов еще больше без людей
24:00 — Выводы — от релиза раз в месяц до релиза каждый час.