Большинство администраторов, когда становятся уже слишком серьезными, чтобы просто так использовать DNS-сервера провайдера, часто выбирают bind в качестве DNS-сервера. Дальше bind подталкивает их к использованию не самых хороших практик, например, совмещению ролей резольвера и авторитетного DNS.

Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.

В докладе рассматриваются следующие конфигурации:

1. Просто (быстрый) резольвер. Области применения: организация, провайдер, ЦОД

Провайдеру и ЦОДу это нужно по-умолчанию. Организациям это нужно тогда, когда объем запросов к провайдерским DNS начинает жать спереди.

Здесь властвует unbound. Важные пункты:
- никаких форвардов на Яндекс или Гугл
- SO_REUSEPORT
- prefetch
- DNSSEC-валидация обязательно
- что мониторить?

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

2. Свои зоны. Области применения: организация, провайдер, иногда ЦОД

Своя DNS-зона рано или поздно появляется у каждого. Здесь, конечно, только PowerDNS. Важные пункты:
- почему только база данных, только хардкор
- почему никаких XFR, а только уровень базы данных
- почему репликация БД тут плохо, и что тут хорошо?
- и как насчет хранения зоны, гм, в git-репозитории?
- что мониторить?

3. Сочетание своих зон и резольвера

У провайдеров, да и часто в крупных организациях, возникает необходимость блокировать резолвинг каких-то записей. Причин тому масса - от требований закона до вирусов. Здесь нужно использовать PowerDNS и unbound в режиме Apache + nginx.

- PowerDNS принимает запрос изначально
- если может ответить на него, то отвечает
- а если не может, то отдает unbound для обработки

Web-отдел 2ГИС - это 5 команд разработки и более 20 проектов разного калибра. Это означает множество релизов каждый день и постоянные изменения.

Что мы имели раньше? Команда - bottleneck из нервных админов, работающих часто сверхурочно.
Что сейчас - команда инфраструктурных инженеров, предоставляющая сервисы для команд разработки.

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

Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.



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


1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.

3) Мы разрабатываем корпоративную ИТ-систему, и у нас DevOps уже с 1995 года.
4) DevOps — это "правильные" инструменты.
5) DevOps — это "философия", специальная культура, которая уникальна и не может быть повторена.
6) В ITIL уже этот ваш DevOps заложен и не надо старое выдавать за новое.
7) DevOps — это маркетинговое словечко, за которым ничего нет.

Мы снабдим эти мифы примерами из нашей практики, дадим советы, как мифов избежать, и представим свою версию ответа на вопрос, что такое DevOps, который в итоге приведет вас к действиям, а не бесконечным священным войнам.

Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.

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

Мы все делаем привычные вещи привычным для нас способом. Порой выполняя много ручной и неэффективной работы. Но что, если есть другой, радикальный подход. Можно ли формализовать свою деятельность и переложить её в код? Какие практики и инструменты для этого использовать?

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

В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.

Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.

Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.

Разбор того, что же получилось в итоге, и какие есть дальнейшие перспективы развития инфраструктуры.

Опыт эксплуатации Kubernetes в production есть пока далеко не у всех. Компании «Флант» удалось за последний год внедрить Kubernetes многим клиентам, и именно об этом мы хотим рассказать. Широкий и систематизированный опыт, собранный в этом докладе, должен вызвать интерес у всех тех, кто только слышал о контейнерах Docker или начинает их использовать, или только выбирает «платформу» (Marathon, Rancher, Kubernetes)… или уже давно что-то использует!

Доклад состоит из трёх частей:
1. Эволюция инфраструктуры приложений: как выглядела веб-инфраструктура раньше, а как — сегодня. Какие проблемы и вызовы привели инженеров к созданию Kubernetes?
2. Как устроен Kubernetes? Простыми словами изложена самая суть этой системы: её базовые компоненты, принципы работы, ключевые возможности. Как в Kubernetes запускаются современные приложения и почему решаются актуальные проблемы в инфраструктуре?
3. Практика использования Kubernetes в небольших проектах (от нескольких до сотен серверов). Как мы сами внедряем и обслуживаем Kubernetes: общая архитектура, основные принципы, связка с CI/CD, имеющиеся ограничения.

P.S. Мы так довольны результатом внедрения Kubernetes, что всерьез планируем уже в этом году перевести на него еще ~50 существующих проектов. А что останавливает вас?

На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.

Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.

Полная интеграция между между таск-трекером, хранилищем исходного кода, CI, хранилищем Docker-образов и CD позволит команде иметь всю информацию о состоянии staging- и production-окружений в одном единственном веб-интерфейсе. Такие современные SaaS, как github.com, travis-ci.org, circleci.com не дают достаточного контроля над окружением, поэтому я выбрал Gitlab-CE и Gitlab-CI для построения CI-CD pipeline.

Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".

В докладе будут рассмотрены практические примеры использование SDN/OpenFlow в реальной жизни и решение своими силами следующих задач: ACL (черные, белые списки), DPI (URL filtering), зеркалирование, QoS (приоритезация, ограничение полосы пропускания), балансировка нагрузки ("IPVS" на 10Gbps), защита от DDOS. Будет представлен используемый инструментарий (программные коммутаторы - Open vSwitch, Lagopus и OpenFlow контроллеры - Ryu, ODL, Runos), примеры скриптов и кода.

Цель такого workshop'а показать простоту, удобство и, главное, полезность существующего инструментария из мира SDN/OpenFlow.

В своём докладе я расскажу о том, почему мы решили использовать Docker в рамках Continuous Integration: ускорить тесты, повысить стабильность, улучшить контроль над окружением и используемыми библиотеками.

Доклад так же содержит подробности о многих сложностях, с которыми пришлось столкнуться в ходе миграции на Docker: борьба с растущим числом и размером образов, бесконтрольные обновления образов, нестабильное поведение, и другие.

В конце доклада я покажу, как именно мы следим за стабильностью Docker в нашей инфраструктуре. И насколько Docker стабилен на больших объемах (>100k билдов в сутки).

Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.

Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.

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

- Почему prometheus?
- быстрый (golang)
- time series database
- простота развертывания через scm (ansible/chef/puppet/salt)
- готовые exports & dashboars for grafana

- Внедряем
- переносим базовый мониторинг систем в prometheus (cpu/disk/net/mem)
- настраиваем discovery новых хостов и сервисов
- подключаем визуализацию
- настраиваем алертинг

- Дополнительно
- резервируем prometheus (alertmanager + prometheus instance)
- получаем информацию из собственных приложений
- получаем статистику из логов

- Заключение
- возможности масштабирования
- какую нагрузку держим

Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?

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

Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?

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

Мониторинг — это и cpu usage, iowait, load average, и времена ответа сайта и отдельных сервисов.

Тайминги ответа — среднее по всем запросам? Нет, подайте лучше медиану, а то и 99-перцентиль!

Но что такое перцентиль? Посмотрим в википедии и всё поймём! Не совсем.
Там тьма проблем, зачастую скрытых от наивных пытливых умов:
- При подсчете любой статистики от тысячи таймингов, будь-то среднее, перцентиль или что угодно, в любом случае теряются данные о распределении. Что нужно не терять и почему — зависит от решаемой задачи: когда и среднее сойдёт, а когда и перцентиль не поможет.
- Как это всё хранить и отображать на графиках? Для данных за неделю не хватит пикселей на вашем мониторе — как выбрать что оставить? А если много серверов ­— с каждого своя перцентиль?
- Вы, кажется, слышали, что за усреднение перцентилей выгоняют из приличного общества…

Когда со всем этим разобрались, то вы решили задать SLA на тайминги ответа сайта, допустим на 99-перцентиль. Не мало? Сколько 9-ок взять? 3, 5, 10? Что на самом деле происходит со временем ответа сервиса за пределами этих девяток?
Какое распределение у самих этих перцентилей? Насколько они шумные? Какая ошибка в минутных перцентилях накапливается за день, за неделю?
Может, есть что-то получше? Гистограммы! Но они не так гибки — надо заранее выставлять и угадать пороги.

В общем, если вам интересно знать, как сервисы _на самом деле_ ведут себя с точки зрения latency, то вам стоит прийти на мой доклад.

Знаете ли вы, что видят пользователи после деплоя вашего кода на продакшн?

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