Заявки на доклады

Конференция RootConf проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока серверных технологий: конференции "HighLoad++ Junior 2018", "Backend Conf 2018".

Также мы формируем Программу++ — это программа митапов и небольших встреч, которую организуют сами участники фестиваля и всех его конференций. Вы предлагаете тему митапа, а организаторы подбирают для него площадку и зал.

Поиск по тегам:

Управление в эксплуатации

Оптимизация размещения виртуальных машин по мастер-серверам

Глеб Альшанский

В реальной среде (облаке, дата-центре) различные виртуальные машины (VM) выполнят различные процессы, имеющие различные профили нагрузки. Совместное размещение VM с максимально различными профилями нагрузки на одном мастер-сервере может серьезно увеличить утилизацию ресурсов мастер-сервера, как следствие, для выполнения того же количества задачи потребуется меньшее количество мастер-серверов.

Когда может быть полезна оптимизация размещения VM по мастер-серверам? Ответ: вы эксплуатируете десятки, а лучше сотни и больше серверов и
1. вам нужно заметно снизить затраты на серверную инфраструктуру;
2. нужно заметно поднять производительность существующей инфраструктуры.

В своем докладе я хочу рассказать:
- как определять профили нагрузки VM, учитывая случайный характер нагрузки;
- как предсказывать профили нагрузки VM;
- как определить с учетом заданного SLA, какие мастер-сервера являются перегруженными, а какие - недонагруженными;
- какие критерии оптимизации нагрузки существуют;
- как рассчитать оптимальное размещение VM с различными профилями нагрузки на мастер-серверах;
- какой экономический эффект можно ожидать от оптимизации размещения VM.

Также я расскажу о 2-3 внедрениях:
- минимально необходимый комплект метрик, собираемых с VM и мастер-серверов;
- инструменты для сбора метрик и хранения их;
- какие трудности возникали при внедрениях;
- как различные дополнительные требования могут влиять на результаты оптимизации размещения VM;
и дам практические советы по внедрению подобного ПО.

Программный комитет ещё не принял решения по этому докладу

Почему надежные дата-центры не надежны, или как выбирать на берегу?

Игорь Мызгин

В последнее время есть традиция, что почти каждую пятницу в ФБ идут очередные войны вида "ААА!!!111адинадинадин хостинг-провайдер XXXXXX упал! мы теряем миллионы! срочно спасите-помогите!!!".

В данном докладе я постараюсь систематизировать ответы на ряд вопросов:
1) какие хостинг-провайдеры бывают;
2) чем они отличаются;
3) какие "типовые" маркетинговые уловки есть в самопиаре большинства провайдеров;
4) как сравнить провайдеров до того, как вы начнете с ними работать (два переезда равны одному пожару - это и про миграцию с хостера на хостера тоже верно);
5) что такое Tier 2-3-4 и, вообще, какие сертификации / внешние рейтинги / независимые оценки "качества" для хостеров бывают?
6) что важно и не важно и на что посмотреть ДО, чтобы потом не задавать вопросов вида "но ведь нам же обещали в договоре два независимых дата-центра, почему же мы лежим?" в паблике ФБ.

По опыту предыдущих докладов - половина времени будет посвящена слайдам, вторая половина - ответам на вопросы аудитории.

Работа со внешним заказчиком/исполнителем
,
Работа с зарубежным заказчиком/рынком
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Программный комитет ещё не принял решения по этому докладу

Enable your team to do changes in production

Mark Heistek

DevOps, Continuous Delivery and Cloud solutions contribute to faster time to market, higher quality and more successful implementations of software. How do these team up to enable the engineer to make changes directly into your production environment? This talk will dive into multiple aspects of implementing DevOps and its pitfalls.

Программный комитет ещё не принял решения по этому докладу

DevOps by nature. How do we learn from ants and bees?

Mark Heistek

As a biomimicry expert I believe in changing in an organic way by empowering people.
In DevOps we talk a lot about culture and how to create a culture of continuous improvement. All to serve our clients best and to become an agile and sustainable organization.
Nature is agile and sustainable for 3.8 billion years. In this talk I will take nature as our DevOps teacher. Where do we find DevOps in nature and how can she teach us to become more DevOps. I will use some great DevOps examples of e.g. ants and bees, but there is more we can learn.
I will also provide some examples where I used nature as source of inspiration to lead a DevOps transition.

Программный комитет ещё не принял решения по этому докладу

Уважайте Пакт: Consumer-driven Contracts и Организационное Общение

Антон (Энт) Вайс

Договора, ориентированные на потребителя (Consumer-driven Contracts), являются важным подходом к тестированию и интеграции в микросервисной архитектуре, незаменимым для осуществления независимого развертывания каждого сервиса в отдельности. По мере того, как микросервисы становятся все более распространенным архитектурным паттерном, создаются и новые инструменты для их разработки. Такие, например, как Pact или Spring Cloud Contracts - созданные для упрощения описания, распространения и тестирования контрактов. Но, как это всегда бывает в DevOps, инструменты и механизмы являются лишь вспомогательными средствами. Для того, чтобы они работали, необходимы правильные процессы, отношения и модели общения между командами.

В этой презентации мы предоставим обзор инструментов, моделей и болевых точек, обнаруженных при внедрении процессов контрактного тестирования в крупных организация по разработке ПО.

Микросервисы, SOA
,
Оптимизация производительности
,
Распределенные системы
,
Методы и техника разработки ПО
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Большие проекты/команды
,
Интеграционное тестирование
,
Коллаборативная работа
Программный комитет ещё не принял решения по этому докладу

Sudo install DevOps

Mark Heistek

Let’s do DevOps because it sounds cool and you are cool if you do it. But how to implement DevOps? Can you implement DevOps? What is DevOps anyway?

DevOps is not an implementation. You cannot just simply give the command “sudo install DevOps”. Moving towards a DevOps organisation is a journey. A journey with a lot of success and even more failures.

This talk will bring you on this journey of successes and failures and provide you insights of real DevOps transitions.

Программный комитет ещё не принял решения по этому докладу

Частые ошибки архитекторов и администраторов Ceph

Михаил Плужников

В докладе рассказывается о основных ошибках при проектировании и эксплуатации Ceph, с которыми сталкиваются архитекторы и начинающие администраторы.

На примерах известных падений сервисов в облачных провайдерах, использующих Ceph, рассмотрим ошибки в архитектуре и администрировании.

Программный комитет ещё не принял решения по этому докладу

Непрерывное развертывание и деплой

.NET на Linux, а DevOps на коне

Александр Синчинов

В своем докладе я расскажу на примере реализованного проекта для крупного заказчика с более 100 000 конечных пользователей, как играючи доставлять проект в rpm, используя TFS, Puppet, Linux .NET core, и о том, как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра. О сломанных костылях и работающих решениях.

Расскажу о том, как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux, и что делать, когда ты девопс и обслуживать винду в продакшне нет ни сил, ни желания, да и ресурсы не резиновые. О методах разрешения идеологических конфликтов.

Как готовят TFS в Золотой Короне. Расскажу о практиках использования TFS в существующих проектах. Как интегрированы с Docker, о Web deploy, тестировании и CI.

Программный комитет ещё не принял решения по этому докладу

Автоматический, надежный и управляемый деплой с помощью простых инструментов

Даниил Мигалин

В 2018 году людей трудно удивить самим фактом наличия худо-бедно работающего CI/CD, благо, что всевозможных технических средств реализовать его сейчас хватает: SCM, контейнеры, всевозможная оркестрация и т.д.

Однако все становится интересней, когда приходят какие-нибудь скептично настроенные люди (аудиторы, безопасники, просто какое-нибудь начальство) и начинают задавать неудобные вопросы: а насколько это у вас автоматизировано? а кто может деплоить? а как это все логируется? а что вы будете делать, когда все сломается?

К сожалению, этих людей не всегда можно послать обратно в их душные кабинеты, чтоб не мешали работать, поэтому рано или поздно стройный и красивый процесс деплоя приходится портить разнообразной бюрократией. И если делать это неумело, то люди начнут разбегаться и потом на кофепоинтах чужих офисов рассказывать про вас всякие неприглядные истории.

Я расскажу о том, как эти проблемы решили в Skype, как мы организовали процесс доставки кода в продакшн так, чтобы он был одновременно не слишком обременительным для разработчиков, но в то же время гибким, управляемым и прозрачным. Речь пойдет не о каком-то конкретном решении, специфичном для Skype, а просто о самой проблеме и одном из способов ее решения, так что доклад будет полезен как тем, что только думает об организации CI/CD у себя, так и тем, кто нашел похожие симптомы в своей уже работающей системе.

Программный комитет ещё не принял решения по этому докладу

Масшабирование CI внутри большой компании

Александр Акбашев

* Очень большая компания = несколько сотен разработчиков

Доклад рассказывает об организационных и технических сложностях, возникших при внедрении единой CI-системы и обязательных пре-коммит-проверок в одном из самых больших подразделений HERE Technologies. А именно:
* в чём принципиальная разница между “всё делаем сами и вручную” и современными подходами в CI с точки зрения масштабируемости;
* почему мы всё ещё используем Jenkins, и что пришлось с ним сделать, чтобы запускать десятки тысяч билдов в сутки;
* как мы тестируем обновления и изменения конфигураций;
* как мы внедрили event-based-механизм для запуска билдов и нотификаций.

Доклад представляет собой логическое продолжение предыдущих докладов, но не повторяет их:
* Highload 2016: Continuous Integration на стероидах;
* RootConf 2017: Использование Docker в CI;
* Highload 2017: Мониторинг облачной CI-системы на примере Jenkins.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

В поисках идеального пайплайна

Илья Сауленко

Continuous Integration — важная часть современного процесса разработки. Сборка на каждый коммит, интеграционные тесты, деплой каждого коммита в продакшн, фиче-флаги — выглядит как идеальный пайплайн? Однако чаще всего разработка приложения не ограничивается написанием кода и запуском тестов.

Я расскажу о том, как и зачем внедрить в CI процессы разработки, которые там обычно не представлены: написание документации, обновление зависимостей, аудиты безопасности, capacity management и даже дизайн интерфейсов. Сравню возможности, которые предоставляют для этого популярные CI-серверы, разобью пайплайны на самые базовые составляющие и расскажу, чем TeamCity принципиально отличается от Concourse.

Команды с работающим процессом Continuous Deployment получат из доклада информацию к размышлению о том, каких процессов не хватает в их существующих пайплайнах, а разработчики, только планирующие внедрять CI — критерии для выбора наиболее подходящего для них сервера интеграции.

Методы и техника разработки ПО
,
Критерии выбора технологий для проекта
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Тестирование безопасности
,
Интеграционное тестирование
Программный комитет ещё не принял решения по этому докладу

Кастомизируем Jenkins, простые решения

Александр Метик

Расскажу про эволюцию энвайрмента одного проекта от Bash-скрипта к Jenkins. Как упростить и в то же время сделать Jenkins удобнее без пайплайна: создадим кастомный дашборд, поработаем с MultiJob-плагином и некоторыми другими.

Поделюсь своим опытом создания удобной среды для команды разработчиков, к чему это привело. Коснемся темы безопасности. Проведу краткий обзор плагинов в рамках своего топ-листа.

Программный комитет ещё не принял решения по этому докладу

Приватная облачная платформа, доступная каждому: цикл жизни типового микросервиса и его зависимостей в kubernetes

Максим Вихарев

Мы в Alytics, как и многие наши коллеги по отрасли, имеем монолит и микросервисы. Относительно недавно мы приняли решение о миграции всех наших микросервисов в Kubernetes. Переход завершен, и в итоге у нас получилось то, что мы назвали "платформой приложений" - это, по сути, базовая станция, облако, со всеми необходимыми зависимостями, в котором можно разместить любой сервис, указав в его конфигурации только точки входа в инфраструктурные сервисы. Получилось очень удобно, и это доступно каждому.

В этом докладе - рассказ о том, как все это организовано внутри в условиях нескольких продакшн-окружений, множества тестовых и отладочных. Как мы мигрировали, из чего, по нашему мнению, состоит и от чего зависит типовой веб-сервис. Как он должен интегрироваться в процесс доставки приложений и как, вообще, этот процесс доставки устроен. Как изменил докер и кубернетес наше представление о деплое приложений и их зависимостей, как это повлияло на типовые процедуры деплоя и обслуживания.

Доклад будет подан с позиции проактивного devops-инженера и разработчика, поэтому акцент будет на прикладную часть эксплуатации кубера, разработку и автоматизацию. Мы рассмотрим весь цикл существования приложения на примере python-сервиса, начиная от создания проекта и заканчивая эксплуатацией и мониторингом в проде, осветим все связанные и показавшие эффективность процессы и инструменты, которые мы используем в данный момент.

Python
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Методы и техника разработки ПО
,
Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Mobile DevOps: автоматизируем и улучшаем процесс мобильной разработки

Вячеслав Черников

Адепты DevOps утверждают, что этот подход применим только для больших команд, работающих со сложными проектами, желательно без UI. Мобильные приложение, вроде как, поменьше, команды всего по 3-5 человек на платформу, чистого Ops почти нет, однако проблем в проектах меньше от этого не становится. На помощь приходит Mobile DevOps!

Что такое Mobile DevOps? Очередная маркетинговая химера или реально полезный набор практик, которые могут упростить и ускорить процесс разработки мобильных приложений?

В рамках доклада вы узнаете о том, почему Mobile DevOps - это не только маркетинг, но и автоматизация CI/CD, тестирования и мониторинга. Мы рассмотрим, чем Mobile DevOps отличается от обычного DevOps, а самое главное - определим основные болевые точки мобильной разработки, чтобы грамотно перекрыть возможные проблемы с помощью автоматической сборки и тестирования.

На практике мы познакомимся с тем, как с помощью AppCenter.ms вы можете настроить сборку, функциональное тестирование, дистрибуцию и мониторинг. Отдельно мы рассмотрим автоматические UI-тесты на реальных смартфонах и планшетах - зачем это нужно, сколько стоит и как использовать.

Речь пойдет про iOS/Android без привязки к технологическому стеку: Objective C/Swift для iOS; Java/Kotlin для Android; ReactNative для iOS/Android; Xamarin для iOS/Android; Cordova для iOS/Android. В довесок немного рассмотрим, кто и что есть на рынке Mobile DevOps.

Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Особенности процессов разработки и тестирования мобильного ПО
,
Распространение приложений, магазины приложений
,
Мониторинг и эксплуатация мобильного приложения
Программный комитет ещё не принял решения по этому докладу

Где застревает софт? Применение измерений и системного анализа для выявления узких мест в конвейере доставки ПО

Антон (Энт) Вайс

Гибкое управление, бережливое управление, непрерывная интеграция, наконец - ДевОпс! Чего только мы не предпринимали для оптимизации сроков доставки ПО. Преимущество ДевОпс-принципов заключается в том, что они собрали в себе весь опыт предыдущих, не всегда, мягко говоря, удачных попыток.

Теория ограничений научила нас, что оптимизация цепочки доставленной ценности в любом месте, кроме самого узкого (так называемого бутылочного горлышка), не приведет к лучшим результатам. А зачастую и наоборот - приблизит крах.

ДевОпс зиждется на системном анализе и измерениях.

На лекции мы рассмотрим все части конвейера доставки ПО и обсудим:
* что измерять,
* как измерять,
* как использовать системный анализ для выявления этих узких мест.
* и как это поможет вам в оптимизации сроков доставки ценности вашей ИТ-организации.

Совместная работа, система контроля версий, организация веток
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Foreman, Smart Proxy и разработка плагинов

Анатолий Чмыхало

- Что такое Foreman?
- Как и где использовать Foreman.
- Что такое Smart Proxy?
- Что такое плагины для Foreman Smart Proxy?
- Пошаговая разработка DHCP-плагина.
- Деплой плагина и результат работы.

API
,
Прочие языки
,
Бэкенд / другое
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Логирование и мониторинг

Практика «провокации» и обнаружения вредоносного кода на сайтах

Григорий Земсков

В докладе рассматривается подход к мониторингу безопасности сайтов, включающий все возможные варианты пассивного и активного обнаружения вредоносных скриптов, вирусов и других типов заражений сайтов.

- Типы вредоносного кода: какие существуют серверные и клиентские "зловреды".
- Чем опасны клиентские и серверные "вредоносы" для хостинга, владельца и посетителей сайта.
- Проблемы обнаружения вирусов на сайте.
- Что такое "провокация" вредоносного кода, как активировать скрытого "зловреда".
- Детектирование вирусного и шпионского кода на клиентской стороне: динамический, статический и поведенческий анализ.
- Детектирование серверного вредоносного кода: сканеры, контроль целостности, эвристический анализ.
- Примеры современных клиентских и серверных "зловредов".
- Как обмануть защиту от обнаружения в вирусном коде.
- Что и как мониторить на сайте и сервере для своевременного обнаружения заражения.

Безопасность в браузере
,
PHP
,
Perl
,
Защита информации
,
Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

Мониторинг всего в условиях микросервисной архитектуры

Михаил Прокопчук

В докладе расскажу о том, как эффективно мониторить инфраструктуру и контейнеры, а также про summary-дашборды и ключевые метрики на основе нашего опыта эксплуатации. В конце я поделюсь опытом эксплуатации promethues и написания своих экспортеров на golang.

Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
Программный комитет ещё не принял решения по этому докладу

Как измерить успех?

Leon Fayer

Никто не оспаривает пользу в идентификации и устранении проблем, полагаясь на традиционные методы тестирования, но в эпоху масштабных систем с интенсивным трафиком этого не достаточно. Способность быстро выявлять и устранять проблемы в production, а не в development, имеет приоритетное значение и требует понимания моделей использования и тенденций по всей системе. С этой проблемой помогает справляться правильная стратегия по системному мониторингу. Но достаточно ли иметь всю информацию о работе систем и приложений, чтобы понять, преуспевает ли ваш бизнес?

Доклад принят в программу конференции

Долгосрочное хранение метрик Prometheus’а

Алексей Палажченко

За короткое время Prometheus стал одним из самых популярных средств для мониторинга благодаря, в том числе, и высокой скорости своей работы. Его локальное хранилище отлично подходит для краткосрочного хранения метрик и работы с ними. Но иногда хочется хранить их распределённо месяцы и годы, автоматически разрежая старые данные, но не меняя интерфейса работы с ними.

В своём докладе я расскажу про стандартные (но плохо документированные) средства Prometheus’а для решения этой проблемы, а также про возможности подключения внешних хранилищ (таких как InfluxDB и ClickHouse), их плюсы, минусы, подводные камни и производительность.

Миграции данных
,
API
,
Логирование и мониторинг
,
GO
Программный комитет ещё не принял решения по этому докладу

Revenue Based Monitoring

Василий Озеров

Все ИТ-компании давно пришли к тому, что необходимо собирать как много больше метрик из происходящих вокруг процессов. Я говорю не только о технических показателях, таких как количество запросов и cpu usage, но и о бизнес-метриках, таких как revenue, retention, quality и прочих.

К сожалению, очень часто эти метрики анализируются отдельно друг от друга, и никто не пытается их соотнести. Знаете ли вы, сколько денег вам приносит веб-сервер? Как увидеть проблемы, когда все системы технического мониторинга горят зеленым? Сколько денег теряет бизнес, когда база данных загружена на 90%? А на 50%?

Если интересно узнать про наш опыт - приходите, будет жарко!

Программный комитет ещё не принял решения по этому докладу

Мониторинг и Kubernetes

Дмитрий Столяров

С переходом на Kubernetes появляется возможность очень быстро и просто создавать новые сервисы, а значит их количество начинает расти “как на дрожжах”. Не менее быстро растут и требования к окружениям — начинается все обычно с трех (production, staging, testing), но очень быстро возникает желание сделать множество дополнительных (вплоть до review-окружений под каждый Merge Request). Так, даже в небольшом проекте с десятком сервисов мы очень быстро оказываемся в ситуации, что в нашем кластере уже 50 namespace’ов и 500 pod’ов. Но что они все делают и как понять, что все работает хорошо?

Последние полтора года мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающиеся как по масштабам, так и по технологиям. На данный момент (апрель 2018) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 120 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом настройки мониторинга, полученным в результате эксплуатации таких проектов.

Основные вопросы, которых коснется доклад:
* Почему мы используем именно Prometheus, и какие вопросы он решает?
* Как правильно интегрировать Prometheus с Kubernetes (и как сделать Service Discovery всего множества метрик и не запутаться)?
* Что именно в Kubernetes нужно мониторить, кроме состояния Pod’ов и результатов выполнения Job’ов?
* Как отделить разные окружения, чтобы, например, не получать алерты по review-окружениям вообще, а по staging и testing получать только в рабочее время?
* Всем и всегда хочется видеть данные с высокой детализацией, видеть тренды на больших периодах и одновременно оптимизировать затраты на инфраструктуру мониторинга, но как это сделать?
* Как сделать дашборды в Grafana так, чтобы всегда видеть необходимое сразу и быстро находить нужное среди обилия информации?
* Какие компоненты самого Kubernetes (самой платформы) стоит мониторить и на что стоит обращать внимание?
* На что стоит обратить внимание при мониторинге Ingress Nginx?
* Как мониторить инфраструктурные компоненты (Redis, RabbitMQ, MongoDB, etc.)?

Логирование и мониторинг
Программный комитет ещё не принял решения по этому докладу

Управление конфигурацией

Конвейер поставки виртуальных машин

Михаил Кузьмин

Идеи continuous delivery можно применять не только к процессу разработки приложений, но и к управлению инфраструктурой.

Я расскажу:
- как управлять виртуальными машинами так же, как и кодом продуктов - с компиляцией, тестированием, публикацией артефактов и релизами;
- как HashiCorp Packer помогает создавать машины и настраивать софт;
- чем immutable infrastructure отличается от классического configuration management с Ansible/Chef/Puppet;
- какие сложности возникают, когда машин становится сотни, а параллельных сборок - десятки. И как TeamCity помогает нам с ними справляться;
- как мы привлекаем разработчиков к администрированию инфраструктуры и внедряем DevOps-культуру.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Доклад принят в программу конференции

Инфраструктура как код, выигрываем на масштабе

Кирилл Ветчинкин

Мы занимаемся заказной разработкой. В основном это web-сервисы, требующие отказоустойчивости, горизонтального масштабирования и имеющие микросервисную архитектуру. Мы уже внедрили достаточно давно CI/CD/QA-автотесты - это все позволяет нам деплоить десятки сервисов, хоть каждый день гонять по 3-4 тысячи тестов перед релизом, но оставался единственный фактор ошибок - по-разному настроенные боевые и тестовые среды, выбор очевиден - внедрение IaC. Но после внедрения обнаружили много плюсов данного подхода. Об этом ниже.

Мы запускаем более 15 проектов в год и трудозатраты на инфраструктуру были огромными - много микросервисов, 4 среды, настроить это все, да еще и без ошибок, задача не из простых. Но инфраструктура любого проекта на 80% идентичная (да, мы жестко следим за зоопарком технологий). Да и каждый раз приходилось настраивать одни и те же системы по нескольку раз для каждого проекта. Мы внедрили и используем подход "DevOps-инфраструктура как код". Теперь вся инфраструктура - это код. Мы используем Ansible как средство, но можно и другие. Кодовая база разбита на модули - postgres, elk, haproxy, kubernetes, rabbitmq и т.п. - каждый модуль настраивает конкретную систему. Эти модули хранятся и развиваются в GIT. Модули используются в разных проектах и позволяют инфраструктуру нового проекта поднять за 4 часа - набрав из модулей новый проект и задав конфигурации (Ip-хостов и т.п. настройки, специфичные для каждого конкретного проекта). Этот подход дал нам такие плюсы - экономия времени - вся инфраструктура за 4 часа, отсутствие человеческого фактора - настройку делает машина, делает ровно то, что в коде - ни больше, ни меньше, живая документация - код, ревью кода инфраструктуры в GIT, историчность изменений, откаты.

Но вы помните, что мы таким способом настраиваем 80% инфраструктуры, а где же оставшиеся 20? - это Docker в сочетании с Kubernetes. Администраторы любят, хотят и хорошо настраивают что-то фундаментальное - их часть это Ansible и все модули, о которых мы говорили выше. Разработчики же хорошо знают и дотошно понимают прикладные системы - настройки nginx, node.js, какую версию .net Core поставить и т.п, а админам ну совсем этим заниматься не хочется. Поэтому весь приклад 20% разработчики самостоятельно настраивают внутри Docker-контейнеров и так же хранят все настройки в GIT. Таким образом удалось четко разделить обязанности и дать возможность каждому заниматься тем, что ему нравится, естественно, с перекрытием компетенций на стыке.

Это 100% практический опыт, которым я и хотел бы поделиться. Многие компании внедряют у себя CI/CD/QA, но забывают что CI/CD/QA никак не поможет если production-сервер настроен иначе чем staging, а идентичность настроек можно добиться только c IaC.

Второй момент. Многие считают, что IaС - это очень дорого и долго, отчасти они правы, но на масштабе - это гораздо дешевле, чем ручные операции и исправление ошибок и финансовые риски в случае падения системы.

ТЕЗИСЫ:
1. О себе и компании.
2. Проблематика - зачем это нужно, какие проблемы решает.
3. Суть подхода.
3. Конкретные проблемы, которые будем решать.
3.1 Много проектов, все похожи на 80%, модули.
3.2 Переиспользование модулей, хранение в Git, ревью, пересборка, удаление машин и т.п.
3.3 Ansible - смотрим на код, примеры.
4. 20% - что у разработчиков, идея отдать разработчикам приклад, зачем, почему администраторы не любят приклад и т.п
4.1 Смотрим на код, практическое решение Docker + Kubernetes.
5. Подводим итоги.
5.1 Экономика - финансовые выгоды.
5.2 Технические выгоды - горизонтальное масштабирование в 1 клик (допустим, добавили новую ноду в kubernetes, модуль хапрокси увидел, что в группе с нодами кубернетес добавилась новая и при запуске перенастроит свои конфиги уже на +1 ноду, контейнеры в кубернетес, естественно, переедут сами на новую ноду).

Возможно, что-то еще, план примерный, выгод от подхода много.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Миграция backend’а на Kubernetes или к вопросу о том, есть ли жизнь в production после внедрения K8S

Seva Morotskiy

В докладе будут рассмотрены use cases, когда развитие сложной ИТ-инфраструктуры продукта привело к новым вызовам, ответом на которые стало создание инфраструктуры, основанной на Kubernetes и Docker.

Мы поговорим о следующих проблемах, с которыми команда столкнулись в ходе реализации проекта, и о путях их решения:
• особенности написания custom tools для деплоя инфраструктуры системы и аргументы в поддержку переписывания данных tools на скрипты ansible;
• нюансы работы weave-сетей через WAN в K8S-кластерах;
• использование шифрования в weave-сетях для безопасного общения компонентов K8S-кластера между собой;
• фиксация/стабилизация версии kubeadm, weave и других компонент Kubernetes-инфраструктуры для обеспечения гарантии их корректной работы друг с другом;
• отказ от федерализации кластеров Kubernetes;
• безопасность хранения AWS-ключей на отдельных серверах инфраструктуры системы и контроль доступа компонентов системы, которые имеют full access к consul-кластеру для доступа к конфиг-данным системы;
• использование шаблонизаторов для установки K8S chart’ов и корректная генерация values-файлов для chart’ов;
• запуск Prometheus на каждом Kubernetes-кластере системы (backend/client-кластерах) и сложность консолидации этих данных в рамках центрального Prometheus-сервера;
• Prometheus vs InfluxDB – к вопросу о хранении оперативных и исторических данных.

Программный комитет ещё не принял решения по этому докладу

Как мы тестируем развертывание на Windows-машины при помощи docker

Олег Блохин

Наши сервера - в основном Windows и немного Linux’ов.
Наше приложение - 160 проектов на C#, которые собираются в ~30 разных сайтов.

Год назад весь процесс деплоя представлял 150 шагов в TeamCity. И требовал даунтайма. Теперь у нас есть деплой-скрипт, который позволяет деплоиться быстрее, выше, сильнее, но всё ещё требует разработки и поддержки.

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

Я расскажу, как мы построили процесс разработки деплой-скрипта так, что кодирование можно без страха доверить студентам, а обратную связь о его качестве получать за одну минуту. А также о том, с какими сложностями мы столкнулись при работе с docker-контейнерами под Windows, и какие плюшки можно от них получить.

Бэкенд / другое
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
,
Devops / другое
Доклад принят в программу конференции

Database as a Code!

Максим Грамин

В последнее время во все сферы разработки ПО все больше проникает концепция "Everything as a Code" - CI (Jenkins pipeline), инфраструктура (Ansible playbooks), тестирование (сценарии Cucumber и Spock), документация (AsciiDoc(tor)) и многое другое. Весь этот код, наряду с основным кодом разрабатываемого приложения, так же находится под управлением системы контроля версий, собирается на билд-серверах, участвует в автотестах.

В докладе я могу рассказать, как этот подход применим к разработке и сопровождению БД, и что под эту схему подходят не только старые-добрые инкрементальные миграции (liquibase, flyway), а также исходный код объектов (baseline), код манипуляции объектами и самим сервером(инстансом) БД.

Еще расскажу о своем opensource-проекте, в котором я пытаюсь воплотить некоторые описываемые идеи.

Фреймворки
,
API
,
Java
,
PostgreSQL
,
Oracle
,
Базы данных / другое
,
Микросервисы, SOA
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Разработка библиотек, включая open source библиотеки
,
Управление конфигурацией
,
Совместная работа, система контроля версий, организация веток
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Devops в коробочной разработке

Максим Лапшин

Сегодня на слуху термин devops и в его обсуждении, как правило, упоминаются сервисы и команды их разработки.

А что же с коробочными продуктами? Они с их релизами раз в полгода в стороне?

Мы не в стороне. Несмотря на релизы раз в месяц, у нас в Эрливидео внедрены полезные практики:
1) жесткое правило на отгружаемость мастер-ветки;
2) сборка в пакет каждого коммита;
3) прогон тестов;
4) методика ежедневной установки мастера пользователям.

Хочу рассказать о том, как это помогает снижать количество багов.

Непрерывное развертывание и деплой
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Технологии отказоустойчивости и катастрофоустойчивости

Cassandra: разделяй и властвуй

Никита Маслянников

Как правило, используется два подхода к построению кластеров - много нод в одном большом кластере и/или несколько независимых кластеров. Мы выбрали второй подход для уменьшения взаимного влияния кластеров друг на друга.

Не так давно мы закончили процесс разделения одного кластера Cassandra с данными на несколько. Процесс происходил без даунтайма приложения и без потери данных.

В докладе мы расскажем про то, какие трудности были на нашем пути, и как мы с ними справились.

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Ceph. Анатомия катастрофы

Артемий Капитула

Ceph - это не готовый "коробочный продукт", но инструмент для построения своего отказоустойчивого решения. В процессе построения такого решения можно упустить множество "подводных камней", которые способны привести к потере или недоступности данных.

В докладе будут разбираться механизмы функционирования кластера Ceph и неожиданные и иногда неприятные и опасные особенности поведения кластера Ceph в случае отказов компонентов кластера и инфраструктуры.

Программный комитет ещё не принял решения по этому докладу

Надежность World of Tansk Server. Как мы это делаем

Левон Авакян

В докладе я расскажу, как выглядит World of Tanks Server (кластер кластеров) со всеми веб-сервисами, которые существуют вокруг. Какие узкие места с точки зрения отказоустойчивости есть внутри кластера, между кластерами, во взаимодействии с внешними веб-сервисами. Как мы решаем возникающие проблемы технически, процессно, проектно.

Отказоустойчивость
,
Распределенные системы
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Доклад принят в программу конференции

Железо не подведет. Как я готовлю к бою десятки серверов в день

Артем Артемьев

Serverless - это все равно сервер. Выход из строя сервера под нагрузкой причиняет боль. Избыточность оборудования в облаке решает эту проблему.

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

Как я измеряю здоровье "железяки", какие показатели правильны для CPU, памяти и устройств хранения?

За 2017 год наша система проверила порядка 5000 серверов. Очевидные пути для проверки оборудования не подошли для пакетной работы. Методы пришлось подбирать экспериментальным путем. Как понять, какие метрики являются показательными? Стоит ли измерять скорость работы RAM?

Мы добились того, что в работу отдаются только исправные машины. Научу вас это делать в автоматическом режиме.

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Аппаратное обеспечение
Программный комитет ещё не принял решения по этому докладу

Тонкая настройка балансировки нагрузки

Николай Сивко

Практически любой инженер знает, как организовать балансировку нагрузки. Мы знаем, что есть балансировка на разных уровнях (от ethernet до протоколов уровня приложения), разные алгоритмы распределения нагрузки и различные способы работать с отказами.

Я расскажу о не очень популярных (пока) аспектах балансировки нагрузки:
- политика повторных попыток (retries);
- таймауты: connect/read/write/request timeout, tcp keep-alive* (чем они отличаются, как выбрать конкретные значения для своего сервиса);
- backoff, circuit breaker: как не убить нижележащие серверы в момент аварии/перегрузки;
- health checks: нужны ли они, достаточно ли их, что сервис должен проверять, прежде чем отдать HTTP-200;
- outlier detection в балансировке: способ работать при более сложных (плавающих) поломках нижележащих серверов.

В плане технологий: сначала мы мельком рассмотрим nginx, haproxy (а так же haproxy за nginx:), потом расскажу про наш опыт работы с envoy и балансировке внутри приложения (будет немного примеров на golang).

Программный комитет ещё не принял решения по этому докладу

Отказоустойчивость сети. M-LAG

Олег Блохин

Ничто так не ломает сервис, как сеть, поэтому требования к устойчивости сети нагруженных сервисов всегда повышены. Мы должны быть готовы к отключению питания в ЦОД-е, падению каналов связи, полному или частичному отказу оборудования.

Я собираюсь рассказать о разных технических (и не очень) вариантах защиты от отказов сети на примере опыта ivi.ru. Расскажу о нашем состоянии в 2017 году, почему мы захотели перемен и что мы в итоге сделали.

Расскажу, почему мы выбрали не "холодильники" и не стеки для нашего ядра. Расскажу о преимуществах и недостатках MLAG в оборудовании Huawei CloudEngine и ExtremeNetworks. А напоследок покажу тизер о наших планах развития сети в этом году.

Программный комитет ещё не принял решения по этому докладу

Особенности реализации доступа по протоколу iSCSI к СХД Ceph

Алексей Костин

В случае, если у вас имеется СХД ceph, и ваши клиенты не поддерживают rbd (например, клиент - это windows или vmware), вам приходится искать решения, какими еще способами можно отдать устройство клиенту и обеспечить отказоустойчивость этого решения.

Я расскажу, какие варианты решения проблемы есть, и какие существуют ограничения, расскажу, что такое tcmu-runner и почему его стоит использовать. Рассмотрю решение ceph-iscsi и сравню его с решением компании SUSE. Объясню, почему может потребоваться передавать Persistent Reservation через rbd-устройство, где это может понадобиться, в каком случае лучше подождать с внедрением этих технологий.

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Программный комитет ещё не принял решения по этому докладу

Технологии виртуализации и контейнеризация

Пакеты и пакетные менеджеры для k8s

Иван Глушков

Мы попытаемся перенести опыт работы с обычными пакетными менеджерами на k8s:
- нужны ли они вообще, или это блажь и хайп;
- в чём они могут помочь, а для каких целей неприменимы;
- текущее состояние пакетных менеджеров, их проблемы и возможные методы решения;
- тренды и ближайшее будущее пакетных менеджеров.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Devops / другое
Доклад принят в программу конференции

Сетевые базисы kubernetes

Александр Хаёров

Использование кластеров на основе контейнеров плотно вошло в нашу жизнь. Повальный интерес к микросервисной архитектуре приложений и массовое разделение монолита привело к оправданному использованию оркестраторов, в частности - kubernetes.

Сложности с разворачиванием кластера из множества серверных нод ложится на матёрых системных админов или «поручается» публичным облачным провайдерам. Локальная разработка основывается на minikube или kubetbetes in docker. А все это приводит к тому, что порой задаешься вопросом: «Как и почему это работает?», и так необходимые базовые сетевые понятия никому не знакомы.

Поговорим о сетевой магии kubernetes - от пода до ingress. Вы узнаете, чем руководствовались создатели оркестратора, для каких задач можно применить те или иные компоненты и почему не стоит бояться Ingress. После доклада все станет ясно!

Технологии виртуализации и контейнеризации
,
Аппаратное обеспечение
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

Как переехать с ESXi на KVM/LXD и не сойти с ума

Лев Николаев

Во многих организациях в качестве гипервизора используется VMware в разных его ипостасях. Чаще всего в его бесплатном виде - в виде ESXi. У себя в операторе связи мы использовали его достаточно давно, начиная с версии 5.0.

Разумеется, что у бесплатной версии есть ряд недостатков, которые успешно отсутствуют в платной версии продукта vSphere, однако модель лицензирования достаточно отпугивающая для малого бизнеса. А самое главное, что новые версии ESXi принесли целый ряд неудобств:
- веб-интерфейс, который не работает нормально (старый программный интерфейс не совместим с новыми версиями);
- сломан нормальный мониторинг RAID-массивов.

В итоге стало очевидно, что нужно сваливать и искать более универсальное и более открытое решение.

У нас уже был достаточно неплохой опыт и приятное впечатление от LXC, Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным, т.е. сочетать для разных нагрузок KVM и LXD, эволюционное продолжение LXC.

К сожалению, на просторах сети очень много идиотизма про KVM, а также много практик выстрела себе в ногу. Отбрасывание шелухи заняло какое-то время на тесты, но результат того стоил.

О чем будем говорить в докладе:

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

2. Хранилище
Сделайте общее сетевое хранилище. Даже если вы не готовы внутри сети использовать 10 Gbps, то даже 1 Gbps даст Вам 125 мегабайт в секунду стораджа. Для целого ряда нагрузок этого будет достаточно за глаза, а миграция виртуальных машин станет элементарным делом.

3. Контейнер или KVM?
Плюсы, минусы, подводные камни. Какие виды нагрузки лучше положить в контейнер, а какие лучше оставить в KVM?

4. LXD или LXC
А ведь LXD это LXC? Или это другая версия? Или надстройка? Или что это вообще? Развеиваем мифы и поясняем на пальцах, в чем заключаются отличия между LXD и LXC.

5. Удобный provisioning
Что удобнее: брать одинаковый образ или инсталлировать систему с нуля каждый раз? Как это делать быстро, четко, ровно каждый раз?

6. Как делать виртуалку хорошо внутри?
Здесь будут страшные рассказы о загрузчиках, разделах, LVM и прочем ужасе.

И еще куча всяких мелких вопросов:
- как быстро перетащить виртуалку c ESXi на KVM?
- как хорошо мигрировать?
- как правильно виртуализировать диски?

Программный комитет ещё не принял решения по этому докладу

Облако на "костях"...

Адрей Листопад

Вы когда-нибудь вскрывали «трупы» и потрошили железо? ;-) Вот и мы, получив задачу сделать облако на базе железа видавшей виды «великой китайской стены», подумали: «А почему бы и нет?».

Расскажу, как мы сделали проект GPUcloud.ru. В нем соединили несоединимые технологии OpenStack community и Hyper-V, создали отказоустойчивое объектное хранилище. Поведаю проблемы, с которыми столкнулись и решили, и, собственно, покажу результат того, что получилось.

Программный комитет ещё не принял решения по этому докладу

Лимиты ресурсов в Кубе

Иван Поддубный

Resources requests и limits. Когда их нужно прописывать и как именно. Что будет, если их не указывать.

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Технологии виртуализации и контейнеризации
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Проектирование информационных систем
,
Нагрузочное тестирование
Программный комитет ещё не принял решения по этому докладу

Построение вычислительного облака на современном ландшафте технологий

Евгений Потапов
Тимур Хасанов

Весной 2018 года к нам обратилась крупная производственная компания, которая попросила нас провести R&D-проект, в рамках которого мы попытались бы опробовать современные технологии контейнеризации, Continous Integration и понять, какие из них применимы для создания платформы приложений и обработки данных.

Перед нами возник вопрос — как скрестить одновременно потребность к быстрому и прозрачному деплойменту приложений и необходимость работы с big data (действительно бигдата). Скрестить так, чтобы это было как единая платформа, одновременно быстрая в масштабировании, легкая для разработчика и при этом полностью оторванная от конкретных ресурсов.

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

В своем докладе мы расскажем о том, что мы пробовали, что не подошло, какие были проблемы, и как это работает в итоге.

Используемые технологии:
k8s, consul, openstack, kafka, flink, cassandra, tarantool, ignite, mesos, marathon, grafana, gitlab, jenkins, zipkin, prometheus

Программный комитет ещё не принял решения по этому докладу

Кто живет на облаках, или что такое cloud-native infrastructure

Антон (Энт) Вайс

Облачные инфраструктуры пару лет как перестали быть инновацией. Сегодня вопрос уже не : “Лезть ли нам на облако?”, а “Как правильно жить в облаках?”.

Как и любая новая технология, облака дали нам новые возможности, но и поставили новые задачи, с которыми мы ранее не сталкивались.

Прорывы последних лет в контейнерной виртуализации и программируемых сетях, оркестрации и асинхронной коммуникации. Все более распределенные и слабо связанные архитектуры современных компьютерных систем. Всё это привело к рождению принципиально нового подхода к управлению инфраструктурой.

Именно это мы и обсудим:
* Что такое cloud-native infrastructure.
* Что такое cloud-native applications.
* Какие проекты входят в CNCF и почему.
* Зачем нужен service mesh.
* Чем "infrastructure as software" отличается от "infrastructure as code".
* Как все это проверять
* Как все это связано с ДевОпс.

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Web-scale IT / другое
Программный комитет ещё не принял решения по этому докладу

Сеть как кровеносная система облака. Строение, развитие, болезни и методы лечения

Вадим Пономарев

Сеть - это кровеносная система любого современного облака, а также это одна из самых сложных частей для понимания, настройки и администрирования в облаке. Быстрое развитие облачных технологий простимулировало появление специального сетевого оборудования, новых протоколов, новых технологий, и ИТ-специалистам, работающим с облаками, необходимо понимать, как это все работает, взаимодействует и управляется.

Основная цель доклада - рассказать в деталях, как работает сеть в современных облаках, какие технологии используются, как они развиваются, обозначить проблемы и дать рекомендации по их решению.

План доклада:
- небольшая историческая справка по облачным сетям, как они развивались, и почему современные решения именно такие, какие есть;
- общие понятия, используемые в облаках для сетевых ресурсов и управления ими;
- сеть "под капотом" - в деталях, как все устроено внутри, протоколы, технологии, топологии;
- небольшое отступление о физических сетях, какие изменения произошли там, какие решения используются у в bare-metal-устройствах;
- что будет в будущем - поговорим о светлом будущем, которое ждет сетевые облачные технологии.

В деталях будет рассказано про работу сети в облаке на базе OpenStack, но такие же технологии и принципы работы используются и в других проектах (таких как kubernetes, mesos), поэтому доклад будет полезен и ИТ-специалистам, не работающим с OpenStack. Доклад также будет интересен сетевым инженерам для понимания "серверной части" облака.

Технологии виртуализации и контейнеризации
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

k8s + enterprise = love

Сергей Бердников

В "enterprise"-среде, особенно финансовой, всегда принято перестраховываться и не внедрять новые технологии после их появления на рынке.Нужно выждать пару лет и после этого начинать использовать. И вот время контейнерных технологий и их оркестровки для нас настал.

K8s - это очень большой и сложный конструктор Lego. Самое главное - это "кубики", которые используются вместе с ним. В докладе будут освещены следующие вопросы:
- Зачем нам потребовался k8s.
- Как кубернетус может изменить ваши процессы внутри организации.
- Очень легко и просто развернуть кластер в облаке, но так ли все радужно, когда развертываешь все в своем ЦОД-е?
- Насколько безопасно размещать приложения в контейнерном окружении?
- Можно ли взять и переехать в k8s без доработок в приложениях?
- Как дружат между собой docker и Oracle database?
- Проблемы k8s и что в нем не нравится.

Программный комитет ещё не принял решения по этому докладу