Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС2ГИС ТехнологииЕсли наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Chef wtfVsevolod PolyakovKyivOps #0 at Ciklum, Sep 26, 2015
A story about why we in Grammarly abandoned development chef, as a configuration management system.
Путь мониторинга: модульность, гибкость, devopsVsevolod PolyakovДоклад на rootconf концеренции, о том как мы в grammarly устроили мониторинг на базе influx, graphite, sensu, statsd, logstash
«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков2ГИС ТехнологииОсобенности модели Github-flow и нюансы её внедрения в основную ветку разработки.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)OnticoВ этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)OnticoВ нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Chef по обе стороны Bamboo / Артем Семенов (Align Technology)OnticoСтроим CI/CD в Bamboo, используя Chef
-----
Мы покажем эволюционный путь нашего CI/CD-процесса от маленького скрипта на python, до фреймворка на ruby:
+ рассмотрим типичные трудности, возникающие при построении CI/CD процесса с помощью CI-движка и Configuration management tools.
+ покажем реализованные решения на примере связки Chef + Bamboo:
o унификация деплоймент-процесса компании;
o деплойменты на гетерогенные environment'ы, включая Linux/Windows системы;
o инструментарий для построения CD-процесса в Bamboo.
Управление билд-фермой Bamboo с помощью Chef
-----
Для поддержки SDLC-процесса компании мы эксплуатируем большую географически распределенную гетерогенную билд-ферму агентов (80+ агентов на базе Windows, Linux и MacOS). С ростом количества билд-конфигураций и агентов мы столкнулись с задачей управления конфигурациями билд-агентов, с которой успешно справляемся с помощью решения на базе Chef.
Примеры решаемых задач:
+ настройка Bamboo-агентов с нуля;
+ сapability management при помощи ohai;
+ повышение эффективности использования билд-фермы.
Caché github continuous intergrationInterSystemsApproach on how make Continuous Integration development cycle with InterSystems Caché.
Caché Object Script solution for CI with Github
https://github.com/intersystems-ru/CacheGitHubCI
Приемы Сontinuous Integration при разработке приложений на CachéInterSystems CEEОб организации автоматизированного рабочего процесса в InterSystems Caché, Лебедюк /
Implementing modern developement practices with InterSystems Caché, Eduard Lebedyuk
DevOps и системы управления конфигурацией. SECON 2015Ivan EvtukhovichЧто такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Docker in Production with AWS ECSDmitry KataevThe last couple of years the technology of containerization via Docker has gained incredible popularity. Many teams already successfully use infrastructure services, staging, testbed in containers, but many people are afraid of using containers to deploy applications in production. The community still lacks success-stories, especially for applications without microservice architecture. The huge number of approaches and recipes does not as well add confidence in what you are doing.
This report is about our fears, successes and solutions for the dockerization of the classical monolith in production..
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Инженерны...IT-Portfolio20 апреля DEV {highload} - конференция о Highload веб-разработке, "Инженерный дзен. DevOps на практике", Александр Титов (DevOps-эксперт "Экспресс 42")
Аннотация
Разработать программное обеспечение в веб-индустрии - это еще не все, надо его еще выкатить в производственное окружение и при этом не разочаровать пользователей. Обычно этот процесс происходит раз в месяц или две недели и сопровождается стрессом для всех участников, а часто заканчивается очень неприятной процедурой отката изменений, далеко не всегда безболезненной.
Проведем параллель с эволюцией в природе, разве там происходит так? Что-то меняется слишком резко и происходит откат? Нет, природа плавно меняет себя, делая небольшие изменения и пропуская их через проверку временем.
Инженерам, работающим в сфере программного обеспечения, дан уникальный шанс, они могут вносить изменения в работающий продукт каждый день, но для этого надо выполнить несколько условий:
- наладить в команде доверительные отношения;
- постоянно интегрировать продукт в тестовой среде;
- поддерживать непрерывный контекст при интеграции;
- использовать подходящие инструменты для управления конфигурацией и деплоя.
Доклад будет про то, как подобрать подходящие инструменты и процессы для работы и начать регулярно выкатывать ваш продукт. В мире принято такие практики называть DevOps.
Биография
Совладелец компании по внедрению DevOps-инструментов и процессов "Экспресс 42". Александр был техническим директором первого облака в России "Оверсан-Скалакси", потом руководил отделом системного администрирования в компании Скайп, подготовил инфраструктуру для запуска проекта видеосообщений.
Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)OnticoВ нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Chef по обе стороны Bamboo / Артем Семенов (Align Technology)OnticoСтроим CI/CD в Bamboo, используя Chef
-----
Мы покажем эволюционный путь нашего CI/CD-процесса от маленького скрипта на python, до фреймворка на ruby:
+ рассмотрим типичные трудности, возникающие при построении CI/CD процесса с помощью CI-движка и Configuration management tools.
+ покажем реализованные решения на примере связки Chef + Bamboo:
o унификация деплоймент-процесса компании;
o деплойменты на гетерогенные environment'ы, включая Linux/Windows системы;
o инструментарий для построения CD-процесса в Bamboo.
Управление билд-фермой Bamboo с помощью Chef
-----
Для поддержки SDLC-процесса компании мы эксплуатируем большую географически распределенную гетерогенную билд-ферму агентов (80+ агентов на базе Windows, Linux и MacOS). С ростом количества билд-конфигураций и агентов мы столкнулись с задачей управления конфигурациями билд-агентов, с которой успешно справляемся с помощью решения на базе Chef.
Примеры решаемых задач:
+ настройка Bamboo-агентов с нуля;
+ сapability management при помощи ohai;
+ повышение эффективности использования билд-фермы.
Caché github continuous intergrationInterSystemsApproach on how make Continuous Integration development cycle with InterSystems Caché.
Caché Object Script solution for CI with Github
https://github.com/intersystems-ru/CacheGitHubCI
Приемы Сontinuous Integration при разработке приложений на CachéInterSystems CEEОб организации автоматизированного рабочего процесса в InterSystems Caché, Лебедюк /
Implementing modern developement practices with InterSystems Caché, Eduard Lebedyuk
DevOps и системы управления конфигурацией. SECON 2015Ivan EvtukhovichЧто такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Docker in Production with AWS ECSDmitry KataevThe last couple of years the technology of containerization via Docker has gained incredible popularity. Many teams already successfully use infrastructure services, staging, testbed in containers, but many people are afraid of using containers to deploy applications in production. The community still lacks success-stories, especially for applications without microservice architecture. The huge number of approaches and recipes does not as well add confidence in what you are doing.
This report is about our fears, successes and solutions for the dockerization of the classical monolith in production..
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Инженерны...IT-Portfolio20 апреля DEV {highload} - конференция о Highload веб-разработке, "Инженерный дзен. DevOps на практике", Александр Титов (DevOps-эксперт "Экспресс 42")
Аннотация
Разработать программное обеспечение в веб-индустрии - это еще не все, надо его еще выкатить в производственное окружение и при этом не разочаровать пользователей. Обычно этот процесс происходит раз в месяц или две недели и сопровождается стрессом для всех участников, а часто заканчивается очень неприятной процедурой отката изменений, далеко не всегда безболезненной.
Проведем параллель с эволюцией в природе, разве там происходит так? Что-то меняется слишком резко и происходит откат? Нет, природа плавно меняет себя, делая небольшие изменения и пропуская их через проверку временем.
Инженерам, работающим в сфере программного обеспечения, дан уникальный шанс, они могут вносить изменения в работающий продукт каждый день, но для этого надо выполнить несколько условий:
- наладить в команде доверительные отношения;
- постоянно интегрировать продукт в тестовой среде;
- поддерживать непрерывный контекст при интеграции;
- использовать подходящие инструменты для управления конфигурацией и деплоя.
Доклад будет про то, как подобрать подходящие инструменты и процессы для работы и начать регулярно выкатывать ваш продукт. В мире принято такие практики называть DevOps.
Биография
Совладелец компании по внедрению DevOps-инструментов и процессов "Экспресс 42". Александр был техническим директором первого облака в России "Оверсан-Скалакси", потом руководил отделом системного администрирования в компании Скайп, подготовил инфраструктуру для запуска проекта видеосообщений.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya DenisyukМы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Zero Downtime PHP Deployment with Envoyer And ForgeYehor HerasymchukThis is a presentation for conference RIT++
Zero Downtime Deployment of our Laravel Apps with Envoyer
And Easy management of servers with Forge
Микросервисный фронтендViacheslav SlinkoПоследние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
В своем докладе я расскажу про архитектуру фронтенда (и так называемого миддленда) в ЦИАН: какие задачи перед нами стояли, что мы решили, где мы находимся сейчас и с какими проблемами мы столкнулись.
Микросервисный фронтенд / Вячеслав Слинько (ЦИАН)OnticoHighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2867.html
Последние несколько лет в продуктовой разработке проблемы масштабирования решаются через переход на микросервисную архитектуру. На эту тему было сказано много про подходы, плюсы и минусы, но мало кто рассматривал эту проблематику со стороны фронтенда.
В ЦИАН мы идем по пути перехода от монолита к микросервисам, в том числе и на фронтенде. Задачи и проблемы, с которыми мы сталкиваемся, очень близки к аналогичным на бэкенде, но в то же время совершенно другие.
Практика разработки веб-серверов на RustMichael PankovRust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
3. Qik
• 2 DEV команды
• 3 OPS
• 1 продукт
• 1 датацентр, 2 окружения
• 10 сервисов
• 50 серверов
Надежные решения для сложной инфраструктуры
3
4. Skype
• 2 DEV команды
• 5 OPS
• 2 продукта
• 3 датацентра
• 20 сервисов (Java/Python/C/C++)
• 200 серверов
• 100Tb данных в месяц
Надежные решения для сложной инфраструктуры
4
5. Skype Ops
• 3 OPS
• Scrum
• 5 OPS
• 3 Infra OPS
• 1 dedicated OPS per team
• CEN, TSG, On-call
• Передача проекта
• devopstopologies.com
Надежные решения для сложной инфраструктуры
5
6. Skype infra repo
• 1 репозиторий
• 3 репозитория
• base
• team1
• team2
• N репозиториев
• base
• team1
• teamN
• component1
• componentN
Надежные решения для сложной инфраструктуры
6
7. Skype
• PaaS
• Chef and Zabbix
• DBaS
• InfoSec
• TPS
• Internal and external endpoints
• Deployment
• PreQA, QA, CAB, Live
• DR, incidents and post-mortems
Надежные решения для сложной инфраструктуры
7
8. Express 42
Chef
• Workflow
• Testo
• Berkshelf
• Community cookbooks
• Test Kitchen and tests
Надежные решения для сложной инфраструктуры
8
9. Chef
• Chef DK
• Knife
• Berkshelf
• Chef клиент
• всегда запущен и run проходит без ошибок
• настраивает окружение
• не деплоит
• Chef сервер на окружение (knife-block)
Надежные решения для сложной инфраструктуры
9
10. Chef workflow
• Chef RFC
• https://github.com/chef/chef-rfc
• rfc019-chef-workflows
• Chef Policies
• https://www.chef.io/blog/2015/10/05/
policyfiles-why-what-and-how/
• Roles/Environments/Runlist
Надежные решения для сложной инфраструктуры
10
11. Chef проблемы
• Монолитные кукбуки
• Изменения не доходят до всех окружений
• Данные на Chef и в Git не совпадают
• Аудит изменений на Chef сервере и на
клиенте
• Версионирование
Надежные решения для сложной инфраструктуры
11
17. Community cookbooks
• Platforms (Ubuntu 14.04)
• Init systems and restart
• Chef 11/12
• LWRP and wrapper support
• Dependencies
• Templates
• Tests and Chef Supermarket
• Issues and pull requests
Надежные решения для сложной инфраструктуры
17
18. Tests
• Любое изменение на GitHub
• Запуск тестов в Travis CI
• Вызов Rubocop и Foodcritic проверок
• Запуск виртуалки в Digital Ocean через Test Kitchen
• Выполнение Serverspec тестов
• Загрузка в Chef Supermarket
• Нотификация в Slack чат и обновление статуса
сборки
Надежные решения для сложной инфраструктуры
18
21. Мониторинг
Надежные решения для сложной инфраструктуры
21
Zabbix Live
• Number of hosts 134
• Number of items 74754
• Number of triggers 20775
• New values per second 1186
Zabbix PreQA/QA
• 79/28920/4968/454
22. Мониторинг
Надежные решения для сложной инфраструктуры
22
• Много триггеров для поиска проблемы, но
только две нотификации о наличии
• End-to-end тесты:
• Full flow тест
• Harness тест