SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Слайды с моего выступления на HDConf в Минске 17 октября 2015 года. Я рассказывал из чего состоит PaaS, как запускать контейнеры в облаке и чем отличаются Mesos, Cloud Foundry и Kubernetes.
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Продуктовые проблемы при создании очередной Docker PaaS / Владимир Ярцев (Cas...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 16:00
Тезисы:
http://rootconf.ru/2017/abstracts/2826.html
Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Юрий Насретдинов-«Сбор логов в «облаке» в Badoo»Tanya Denisyuk
В нашей компании есть система для запуска PHP-скриптов по расписанию, которая позволяет распределять нагрузку на множество узлов и обеспечивать отказоустойвость. И в этой системе необходимо уметь собирать логи скриптов с сотен (и даже тысяч) машин, желательно в режиме реального времени. У нас раньше была система сбора логов, собранная «на коленке», и выдающая относительно невысокую производительность. Производительности стало не хватать, и мы переписали систему на Go. Новая система не использует scribe и обладает некоторыми уникальными фичами, например «вытесняющей многозадачностью» при доставке - если один из скриптов пишет столько логов, что мы не успеваем их всех доставить, логи всех остальных скриптов продолжают доставляться, с небольшой фиксированной задержкой. Система легко забивает гигабитную сетевую карту на нашем сервере-приемнике логов и не слишком «тормозит» доставку в случае, когда пропускной способности всё же не хваетает. В докладе я расскажу о том, как мы делали эту систему и про то, как она работает изнутри. Исходные тексты доступны на github: https://github.com/badoo/thunder
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Александр Крашенинников "Hadoop High Availability: опыт Badoo"IT Event
Инфраструктура Hadoop – популярное решение для таких задач, как распределённое хранение данных и вычисления Map/Reduce на кластере. Хорошая масштабируемость и развитая экосистема подкупают и обеспечивают Hadoop’у прочное место в инфраструктуре различных информационных систем. Но чем больше ответственности возлагается на этот компонент, тем важнее обеспечивать его отказоустойчивость и high availability.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
"How to build powerful CI / CD based on GitLab and Docker", Aleksandr Matkovs...Provectus
Aleksandr Matkovskiy – Head of IT Department lives and works with the motto "Scaling and load balancing is our all!". Therefore, he has 3 sons and dreams to find DEV for his OPS.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Vladislav Anikin – Team Leader & Software Architect, specializing in SAAS flexible and scalable solutions for business. Driving DDD/TDD oriented squad of awesome SOLID developers.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Слайды с моего выступления на HDConf в Минске 17 октября 2015 года. Я рассказывал из чего состоит PaaS, как запускать контейнеры в облаке и чем отличаются Mesos, Cloud Foundry и Kubernetes.
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Продуктовые проблемы при создании очередной Docker PaaS / Владимир Ярцев (Cas...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 16:00
Тезисы:
http://rootconf.ru/2017/abstracts/2826.html
Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Юрий Насретдинов-«Сбор логов в «облаке» в Badoo»Tanya Denisyuk
В нашей компании есть система для запуска PHP-скриптов по расписанию, которая позволяет распределять нагрузку на множество узлов и обеспечивать отказоустойвость. И в этой системе необходимо уметь собирать логи скриптов с сотен (и даже тысяч) машин, желательно в режиме реального времени. У нас раньше была система сбора логов, собранная «на коленке», и выдающая относительно невысокую производительность. Производительности стало не хватать, и мы переписали систему на Go. Новая система не использует scribe и обладает некоторыми уникальными фичами, например «вытесняющей многозадачностью» при доставке - если один из скриптов пишет столько логов, что мы не успеваем их всех доставить, логи всех остальных скриптов продолжают доставляться, с небольшой фиксированной задержкой. Система легко забивает гигабитную сетевую карту на нашем сервере-приемнике логов и не слишком «тормозит» доставку в случае, когда пропускной способности всё же не хваетает. В докладе я расскажу о том, как мы делали эту систему и про то, как она работает изнутри. Исходные тексты доступны на github: https://github.com/badoo/thunder
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Александр Крашенинников "Hadoop High Availability: опыт Badoo"IT Event
Инфраструктура Hadoop – популярное решение для таких задач, как распределённое хранение данных и вычисления Map/Reduce на кластере. Хорошая масштабируемость и развитая экосистема подкупают и обеспечивают Hadoop’у прочное место в инфраструктуре различных информационных систем. Но чем больше ответственности возлагается на этот компонент, тем важнее обеспечивать его отказоустойчивость и high availability.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
"How to build powerful CI / CD based on GitLab and Docker", Aleksandr Matkovs...Provectus
Aleksandr Matkovskiy – Head of IT Department lives and works with the motto "Scaling and load balancing is our all!". Therefore, he has 3 sons and dreams to find DEV for his OPS.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Vladislav Anikin – Team Leader & Software Architect, specializing in SAAS flexible and scalable solutions for business. Driving DDD/TDD oriented squad of awesome SOLID developers.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
7. Open source
• https://github.com/dotnet/
• https://github.com/dotnet/corefxlab
• Можно быстрее итерировать:
• Span<T>
• Скорость коллекций:
https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-
improvements-in-net-core/
8. xcopy публикация
• dotnet publish – единственный вариант
• Framework dependent deployment
• Self-contained deployment
9. Ограничения
• Нет WinForms, WPF, etc.
• Не все библиотеки доступны
• с .netstandard 2.0 стало сильно лучше
• Необходимо VS2015+, последний апдейт, .net461+
• Обёртки типа imagemagick пишем сами
10. Инструменты
• Microsoft IDE: VS2015, VS2017, VS for mac
• Jetbrains Rider
• Editors: vs code, atom, etc. + OmniSharp
11. А когда релиз?
• Release 1.0: 27.06.2016
• Release 2.0: 14.08.2017
12. Поддержка
• .net core 1.1, 1.0 – up to 27.06.2019
• .net core 2.0 – up to 14.08.2020
14. Контейнеры
• Они с нами давно (Jails, LXC, Solaris zones)
• Наиболее популярный вариант сейчас – Docker
• Docker for Windows/Mac – VM
• Windows containers
16. Разрушим мифы
• Практически никакого оверхеда по CPU и памяти
• Практически никакого оверхеда по IO, если использовать volume
• Достаточно серьёзный оверхед по сети (Project Calico)
Источник: IBM Research Report An Updated Performance Comparison of Virtual Machines and Linux Containers
https://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
17. Docker-образ
• Самое важное во всей экосистеме Docker
• Инкапсулирует в себе все зависимости
• Подписывается после сборки и неизменен
21. .net 46 => .net core1.1
• Несколько попыток, последняя – 3 месяца
• Пришлось поддерживать несколько форков OSS
• Невозможно работать с доменами
• Нет HttpContext
23. Что получилось на выходе?
• IIS приложение asp.net core application
• Windows службы asp.net core application
• Tools asp.net core application
• 55 проектов
25. А зачем всё это?
• Linux-native хранилища у нас будет линукс
• Если можно убрать windows, то меньше проблем с Ops
• Docker containers можно скачать и посмотреть (.env)
26. Выбор СУБД
• Нам подходят key-value
• Redis
• Tarantool
• Sql server
27. • Давно на рынке
• Хороший коннектор для .net [StackExchange.Redis]
• Очень быстрый
• Прекрасная документация
29. Недостатки Redis
• Нет вторичных индексов
• Данные со временем теряют консистентность
• Атомарная реализация через lua или транзакции – медленная
• Выкидываем Redis, берём Tarantool
30. progaudi.tarantool
• Поддерживаем net46, netstandard1.4, netstandard2.0
• Поддерживаем Windows, Linux и Mac OSX
• Поддерживаем почти полностью IProto, кроме:
• DDL
• сallv1.6 бросает исключение, если функция возвращает null
• Соединение держим только c одной нодой
31. Коннектор: планы старые
• Переименовать пакет
• Поддержать MsgPackValue (непрозрачный контейнер)
• Добавить более удобную сериализацию в MsgPack: mini-ORM
32. Коннектор: планы новые
• Распилить пакет на два
• Сделать более удобный интерфейс
• Ускорить, расширить и улучшить
33. Эксплутация: сервер приложений
• Это его основное назначение
• Мы используем только tarantool/queue
• Также у нас есть немного своей логики на lua
36. Эксплуатация: версионирование
• Версия докер-контейнера – 1.7.3. Версия тарантула?
• Версия тарантула – 1.7.3-х. Версия докер-контейнера?
• Мы перешли на самосборный контейнер.
39. Выводы?
• .net core работает на Linux, ARM, ARM64 (ну, почти ;))
• Tarantool – хорошая СУБД для .net приложений.
• Tarantool – хорошая очередь для .net приложений.
Каждый продукт в определённый момент своей жизни сталкивается с проблемой выбора СУБД. И наш продукт для сбора обратной связи и голосований совершенно не исключение. Модель данных у нас достаточно проста и укладывается в ограничения, которые накладывают key-value хранилища. Поэтому мы выбирали между Redis, Tarantool и плагином на mysql - handlersocket.
Эта СУБД давно на рынке. К ней есть хороший коннектор для .net (для Тарантула и handlersocket его не было). Работает Редис примерно также быстро, как и тарантул (если верить нашим бенчмаркам). Отличная документация на сайте. В общем, всё выглядело неплохо.
В пользу Тарантула говорила скорость, сравнимая с Редисом. Благодаря write-ahead logging запись на диск достаточно надёжна. Есть атомарно обновляемые вторичные индексы. Но нет коннектора.
Как обычно, спустя какое-то время, радужная картинка стала менее радужной, но более реальной. Несмотря на простоту модели данных, достаточно скоро нам потребовалось искать голосования, созданные каким-то автором. Эти вторичные индексы мы реализовали на редисе дополнительными списками. В результате мы столкнулись с тем, что отсутствие атомарности при этих изменениях приводит к нарушению консистентности данных. Использование транзакций или луа в редисе значительно снижало производительность. Поэтому мы стали смотреть на его ближайшего конкурента: Tarantool.
Второй основной проблемой было отсутствие коннектора. Мы написали свой. Наш коннектор доступен в nuget, поддерживает .net46 и .netstandard 1.4 для .net core. Работает на всех трёх основных ОС: windows, linux, mac osx. Проверяют это автоматические тесты на Travis CI. Практически полностью поддерживаем протокол тарантула, за исключением:
DDL (data definition language). Мы считаем, что разработчики должны создавать модель данных нативным образом для tarantool.
call v1.6, если функция возвращает null, приводит к исключению, мы пока не придумали как это распарсить
коннект держим пока только с первой переданной в конфиге нодой, это будет исправлено в ближайшее время
Если у вас в одной колонке разнотипные данные, мы пока не сможем их прочитать. Работы над этим ведутся.
Ближайшие планы по нашему коннектору примерно такие: для начала мы переименуем пакет при следующем релизе, так как текущее название, как выяснилось, вводит коллег в заблуждение. Во-вторых, мы поддержим специальный тип MsgPackValue, который – непонятно что и пользователь сможет сам решить что это. Нужно это для нормальной работы со scalar index. Ну и обязательно посмотрим в сторону более удобной сериализации POCO в MsgPack. Это резко упростит работу с нашим коннектором.
Ближайшие планы по нашему коннектору примерно такие: для начала мы переименуем пакет при следующем релизе, так как текущее название, как выяснилось, вводит коллег в заблуждение. Во-вторых, мы поддержим специальный тип MsgPackValue, который – непонятно что и пользователь сможет сам решить что это. Нужно это для нормальной работы со scalar index. Ну и обязательно посмотрим в сторону более удобной сериализации POCO в MsgPack. Это резко упростит работу с нашим коннектором.
Богатейшие возможности для использования тарантула в качестве сервера приложений. Это его основное назначение, если я верно понимаю. Мы используем, например, модуль очередей (https://github.com/tarantool/queue). Благодаря тому, как работают yield point в тарантуле, очереди в тарантуле дают нам exactly once семантику. Бизнес-логика на луа у нас есть, но очень немного. В основном из-за отсутствия вменяемых инструментов для разработки на луа.
Не всё безоблачно и в эксплуатации. Во-первых, нет синхронной репликации, поэтому возможна потеря небольшого количества данных, в случае выхода мастера из строя. Это для нас не критично, потому что в Редисе всё несколько хуже. Ждём bsync.
На Highload 2016 Илья Космодемьянский рассказывал зачем нужна мастер-мастер репликация. И его вывод заключался в том, что обычно она не нужна. В целом, я с ним согласен. Но у нас в одном из приложений, как раз тот случай, когда все ключи случайны, следовательно, записывать можно в любую ноду. Поэтому там у нас мастер-мастер используется. В версии 1.7.3-0, которая является первой версией 1.7.3, есть проблемы с поднятием кластера с одинаковой конфигурацией. Допустим, у нас простой кластер из трёх нод. Если все три ноды лежат, и мы запускаем их одновременно, то они не видят апстримы для репликации и через 30 секунд выключатся. Это уже исправлено в новых версиях, мы просто никак не обновим продакшен.
Крайне неочевидна для нашей команды связь между версией официального докер-контейнера и версией тарантула. Например, хотим мы версию контейнера 1.7.3, потому что туда новый модуль queue добавили. А какая внутри версия тарантула? Или, наоборот, хотим мы самую версию тарантула 1.7.3-80, например. Какую версию контейнера брать? Поэтому, мы перешли на самосборный контейнер.
Общий недостаток Редиса, Тарантула, handlersocket и прочих noSql решений - это специфический язык запросов. Товарищи сисадмины и тестировщики более привычны к SQL. При этом они не являются разработчиками и учить даже Lua им достаточно непросто. Поэтому, очень ждут, когда в tarantool появится хоть какой-нибудь sql-engine.
Для логирования и мониторинга происходящего в тарантуле там есть достаточно много инструментов. Мы используем логирование в stdout и собираем затем логи с помощью fluentd docker driver в центральное хранилище. Мониторинг у нас построен на prometheus, который сейчас является самым простым решением с точки зрения развёртывания и сбора данных для небольших команд. И очень удобно, что к тарантулу есть модуль tarantool/prometheus, который собирается различные метрики с запущенных тарантулов.
Какие выводы можно сделать? С развитием open source версии .net - .net core, которая прекрасно работает на самых разных ОС и архитектурах (например, x86, ARM, ARM64), .net разработчикам не следует ограничивать себя только Windows и необходимо рассматривать все доступные варианты на рынке и выбирать то, что больше подходит.
Тарантул – прекрасная и быстрая СУБД, которую можно использовать как исключительно СУБД, так и в качестве, например, очереди для любых приложений, в том числе, написанных на .net. В нашем проекте мы полностью удовлетворены работоспособностью Тарантула и продолжим миграцию основных данных в него.