OpenStack: от enterprise к сервис-провайдеру / Сергей Пимков (Селектел)Ontico
При работе над одним проектом обычно не возникает проблем с распределением ресурсов, так как все ресурсы принадлежат одному проекту, но когда появляется второй, третий и т.д., то всегда возникает вопрос контроля и учета ресурсов по каждому проекту в отдельности. Что немаловажно - это удобство процесса распределения.
В докладе будет описан процесс адаптации ванильного OpenStack под нужды сервис-провайдера и представлено наше видение виртуального приватного облака, которое было построено нами на базе OpenStack.
Мы затронем проблемы ванильного OpenStack и расскажем с чем столкнулись на пути его адаптации.
А также представим новую услугу, которую мы запустили, - "Виртуальное приватное облако" - и расскажем о проблемах, которые мы помогаем решать при её помощи.
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
OpenStack: от enterprise к сервис-провайдеру / Сергей Пимков (Селектел)Ontico
При работе над одним проектом обычно не возникает проблем с распределением ресурсов, так как все ресурсы принадлежат одному проекту, но когда появляется второй, третий и т.д., то всегда возникает вопрос контроля и учета ресурсов по каждому проекту в отдельности. Что немаловажно - это удобство процесса распределения.
В докладе будет описан процесс адаптации ванильного OpenStack под нужды сервис-провайдера и представлено наше видение виртуального приватного облака, которое было построено нами на базе OpenStack.
Мы затронем проблемы ванильного OpenStack и расскажем с чем столкнулись на пути его адаптации.
А также представим новую услугу, которую мы запустили, - "Виртуальное приватное облако" - и расскажем о проблемах, которые мы помогаем решать при её помощи.
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
Слайды с моего выступления на HDConf в Минске 17 октября 2015 года. Я рассказывал из чего состоит PaaS, как запускать контейнеры в облаке и чем отличаются Mesos, Cloud Foundry и 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 без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Александр Ломов-«Как перестать беспокоиться и начать использовать Cloud Foundry»Tanya Denisyuk
Многие согласятся, что писать велосипеды - плохо, а автоматизировать трудоемкие задачи - хорошо. Другие повторяют одно и то же и не задумываются об этом. Cloud Foundry - открытая платформа, которая позволяет радикально сократить время развертывания приложений и сделать разработчиков и бизнес счастливее. В моем докладе я раскажу вам почему через несколько лет весь мир будет использовать CF при разработке приложений.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС2ГИС Технологии
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Continuous Delivery, или волшебная кнопка для релизов по запросу — Денис Яков...2ГИС Технологии
Для нас CD — это когда менеджер или релиз-менеджер с помощью одной «кнопки» может выкатить весь продукт «в бой». При высокой связности, распределённости продукта и всех проверках выполнить такую задачу непросто, и делается это небыстро.
На примере Справочного API 2ГИС я расскажу, как мы сделали для менеджеров эту «кнопку». Расскажу про workflow, о том, как мы используем Jenkins для сборки, Rundeck для администрирования релиза, Яндек.Танк для нагрузок, Chef для конфигурирования серверов.
Слайды с моего выступления на HDConf в Минске 17 октября 2015 года. Я рассказывал из чего состоит PaaS, как запускать контейнеры в облаке и чем отличаются Mesos, Cloud Foundry и 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 без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Александр Ломов-«Как перестать беспокоиться и начать использовать Cloud Foundry»Tanya Denisyuk
Многие согласятся, что писать велосипеды - плохо, а автоматизировать трудоемкие задачи - хорошо. Другие повторяют одно и то же и не задумываются об этом. Cloud Foundry - открытая платформа, которая позволяет радикально сократить время развертывания приложений и сделать разработчиков и бизнес счастливее. В моем докладе я раскажу вам почему через несколько лет весь мир будет использовать CF при разработке приложений.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС2ГИС Технологии
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Continuous Delivery, или волшебная кнопка для релизов по запросу — Денис Яков...2ГИС Технологии
Для нас CD — это когда менеджер или релиз-менеджер с помощью одной «кнопки» может выкатить весь продукт «в бой». При высокой связности, распределённости продукта и всех проверках выполнить такую задачу непросто, и делается это небыстро.
На примере Справочного API 2ГИС я расскажу, как мы сделали для менеджеров эту «кнопку». Расскажу про workflow, о том, как мы используем Jenkins для сборки, Rundeck для администрирования релиза, Яндек.Танк для нагрузок, Chef для конфигурирования серверов.
This file tells you about oil panel paintings how they are manufactured, were you can get them, and alot more. You can check out Art Addiction's complete collection of modern artwork at http://www.artaddiction.biz/
Shifting Consumption: Lessons from market transformationsFrancois Stepman
Shifting Consumption: Lessons from market transformations by Daniel Vennhard, World Resources Institute
11 October 2016. Brussels. The role of consumers in the sustainable consumption and production in Europe and in developing countries
14 March 2016. Brussels. DevCo External Cooperation InfoPoint. An overview of the situation of food and nutrition security in the world today was presented. Special emphasis was given to the current situation of El Niño, current droughts in Africa South of the Sahara, and potential policies that need to be put in place in the future to minimize these and associated risks.
Introduction: Jean-Pierre Halkin, Head of Unit - DEVCO C1- Rural development, Food security, Nutrition
Presentation: Maximo Torrero, Director, Markets, Trade and Institutions Division, International Food Policy Research Institute
Владимир Русинов, Алексей Капранов "Яндекс.Диск: архитектура, синхронизация и...Yandex
Доклад о том, как решалась задача надёжного хранения файлов и данных миллионов пользователей. Рассказ про развитие архитектуры кластера Диска: от первого черновика к реальности
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
IBM Cloudant и Apache CouchDB: NoSQL базы данных эпохи облаковMaxim Zinal
Какой должна быть NoSQL СУБД эпохи облаков? Что такое IBM Cloudant и Apache CouchDB?
Как они связаны друг с другом, и есть ли польза для Open Source проекта от коммерческого облачного сервиса на его основе?
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
"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.
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
Борис Павлович - Производительность и масштабируемость OpenStack Yandex
В докладе прозвучали ответы на вопросы о том, что такое OpenStack, зачем он нужен, что подразумевается под его производительностью и масштабируемостью и как тестировать эти качества, если у вас нет своего дата-центра. На примере проекта Rally вы узнали, как полностью автоматизировать тестирование. Было рассказано о проблемах, которые возникли при разработке Rally. Завершился доклад рассказом о том, с какими сложностями, касающимися масштабируемости и производительности OpenStack, ещё предстоит справиться.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Similar to DevOps в проекте Upsource. Андрей Сизов, System Administrator (20)
2. План
—
• Несколько слов про Upsource
• С чего мы начинали
• Что мы имеем сейчас
• Планы на будущее
• Заключение
2
3. Upsource в числах
—
150 проектов (18K reviews)
2 площадки:
• публичная на AWS
• внутренняя DYOC*
Объем базы данных ~500Gb
Доступность 24x7x365
* Drink Your Own Champagne
3
5. В самом начале (09/2014)
—
2 VMs на vSphere:
•1 App
•1 HyperTable
CentOS 6, Docker 0.x
Монолитный контейнер с приложениями
Деплоймент из TeamCity
5
6. В самом начале (09/2014)
—
6
Плюсы:
• Быстрый старт
• Стали понятны требования
• Разработчики могли выкладывать
билды самостоятельно (но боялись)
7. В самом начале (09/2014)
—
7
@JetBrains. Все права защищены
Проблемы:
• Риск потери данных при редеплое:
- “плохой” билд
- проблемы базы
• Downtime ~15 минут в момент деплоймента
• Вся инфраструктура еще в ручном режиме
17. Текущая инфраструктура
—
Плюсы:
• Инфраструктура и деплоймент полностью автоматизированы
• Все в коде => новые стеки создаем из TeamCity, меняя параметры
• Моментальное переключение Green/Blue стеков
• Ansible - легко управлять инфраструктурой
• Никаких ручных действий
• Все действия записаны: изменения в git, результаты в TeamCity
buildlogs
17
18. Разработчики:
—
«Круто, теперь поговорим о планах на будущее.
Хотим включить развертывание
инфраструктуры в продукт!
Чтобы пользователи тоже могли ее
использовать!»
18
19. Планы на будущее
—
• Кластеризация приложения
• Автоматическое масштабирование stateless-компонент
• Поддержка K8S/Swarm/etc
• Публичные docker имиджи на hub.docker.com
• Объединение площадок в AWS
19
20. Итоги
—
• Разработчики вовлечены в задачи инфраструктуры
• Переиспользуемые код и паттерны в других проектах
• CI/CD => минимальное время деплоймента новых фичей
• Каждая задача - конфигурация в TeamCity
• Разработчики выкладывают новые версии на разные стеки сами
и без страха!
• 99,96% uptime по версии StatusCake
20