Мы напишем простейший веб-сервис из клиента и сервера на C++. На этом C++ часть закончится, и пойдет настройка окружения и инфраструктуры. Мы обеспечим детерминируемость сборки и прогона тестов. Облегчим последующее обновление зависимых библиотек. Автоматизируем статические проверки, верификацию кода, прогон тестов. Обеспечим доступность сервиса, настроим инфраструктуру, сбалансируем нагрузку, добавим автоматическое и ручное масштабирование. И под конец мы настроим continious delivery таким образом, что код будет на продакшене через 5 минут после реквеста, при этом даже невалидные изменения и ошибки программиста не смогут повлиять на его работу.
Legacy в коробочке. Dev-среда на базе Kubernetes / Илья Сауленко (Avito)Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Серге...Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2654.html
Даже небольшие сервисы рано или поздно сталкиваются с проблемой безопасного хранения и управления секретной информацией: паролями, сертификатами, ключами API.
В докладе будет сделан краткий обзор Hashicorp Vault, рассмотрены случаи автоматического и безопасного управления секретами с помощью puppet+hiera. Особое внимание будет уделено встроенным секретам Kubernetes: я обозначу проблемы управления ими и недостатки существующих решений для связки с Vault, а также расскажу, как мы преодолели все эти трудности с помощью простого самописного решения.
Доклад будет полезен тем, кто уже столкнулся с проблемой большого количества секретов, а также всем, кто уже использует Kubernetes, или ещё только думает о его внедрении.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
SPb Jenkins Meetup #5. Jenkins in da Cloud. ВнутренностиOleg Nenashev
Доклад о возможностях ядра Jenkins и плагинах, с помощью которых можно управлять инстансами Jenkins в облаке. Ключевые слова: Configuration as Code, Docker, External Logging, Pluggable Storage, Pipeline
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
This is a war-story about deploying and managing Jenkins instances in the cloud in our company. For this purpose, we use Mesos and Docker plugins. In the talk I focus on our requirements to Jenkins in the Cloud, prerequisites and the preparation process. The presentation also covers the current state of the deployment and the lessons learnt.
We are hiring! Msk and Spb: https://goo.gl/HjfOz5
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Legacy в коробочке. Dev-среда на базе Kubernetes / Илья Сауленко (Avito)Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Серге...Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2654.html
Даже небольшие сервисы рано или поздно сталкиваются с проблемой безопасного хранения и управления секретной информацией: паролями, сертификатами, ключами API.
В докладе будет сделан краткий обзор Hashicorp Vault, рассмотрены случаи автоматического и безопасного управления секретами с помощью puppet+hiera. Особое внимание будет уделено встроенным секретам Kubernetes: я обозначу проблемы управления ими и недостатки существующих решений для связки с Vault, а также расскажу, как мы преодолели все эти трудности с помощью простого самописного решения.
Доклад будет полезен тем, кто уже столкнулся с проблемой большого количества секретов, а также всем, кто уже использует Kubernetes, или ещё только думает о его внедрении.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
SPb Jenkins Meetup #5. Jenkins in da Cloud. ВнутренностиOleg Nenashev
Доклад о возможностях ядра Jenkins и плагинах, с помощью которых можно управлять инстансами Jenkins в облаке. Ключевые слова: Configuration as Code, Docker, External Logging, Pluggable Storage, Pipeline
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
This is a war-story about deploying and managing Jenkins instances in the cloud in our company. For this purpose, we use Mesos and Docker plugins. In the talk I focus on our requirements to Jenkins in the Cloud, prerequisites and the preparation process. The presentation also covers the current state of the deployment and the lessons learnt.
We are hiring! Msk and Spb: https://goo.gl/HjfOz5
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
- Краткая вводная про Docker (namespaces, cgroups и как Docker все это использует)
- Как заходить в Docker из вашего софта?
- Примеры: pam_docker и php_fpm_docker
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
TК°Conf. Микросервисы и Docker. Глеб Паньшин.TKConf
Когда вы пытаетесь следовать гибким методологиям, создавать небольшие автономные команды, микросервисы в вашем проекте появляются естественным путем. Или нет. Обязательно поговорим о "Монолит vs. Микросервисы". И хотя эти маленькие трудяги помогают вам scale и достигать agility они неплохо добавляют вам проблем с доставкой и разработкой.
В заключении попробую ответить на вопрос как деплоить 5 или 50 микросервисов? Не знаю, но давайте попробуем Docker.
Материалы со встречи:
https://getdev.net/Event/docker
Docker: зачем нужен и почему выстрелил? Контейнеры против виртуальных машин - кто лучше? Docker на Windows: как и когда? А также демо: создание и deploy контейнера на ваших глазах
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
Михаил Боднарчук "Docker для PHP разработчиков" Fwdays
Это не рассказ о том, как из разработчика стать крутым DevOpsом. Это доклад о том, как можно сделать процесс разработки и развертки приложения комфортнее и эффективнее вместе с прогрессивной технологией контейнеризации - Docker.
В этом докладе я затрону следующие темы:
Docker - это то модное слово, которое все должны знать
Дирижирование оркестром вместе с Docker Compose
Создание и настройка рабочего окружения в Docker
Построение сервисно-ориентированых приложений
Безболезненное развертывание приложений с Shipyard
То, чего не хватало для Continuous Integration - запуск параллельных билдов
В докладе рассказывается об опыте применения «инверсия управления» (Inversion of Control) при разработке новой версии KES. Этот подход заключается в том, что более высокоуровневый код не зависит напрямую от конкретной реализации нижележащего слоя. Вместо этого он зависит от абстрактного протокола (интерфейса), конкретный же компонент подставляется конфигурационным кодом-клиентом. Эта практика позволяет понизить loose coupling программных модулей и применяется практически в любых крупных проектах.
При разработке новой версии KES было принято решение изменить подход к реализации инверсии управления. Было решено отказаться от централизованного обобщенного реестра доступных компонентов (шаблон (паттерн) Service Locator) в пользу явной передачи зависимостей конфигуратором (ручная инъекция зависимостей (manual Dependency Injection)). При это возникли проблемы с использованием готовых библиотек Dependency Injection Frameworks. Применение подобных библиотек стало стандартом в мире разработки Java/C# за последние 10-15 лет, но в мире C++ они пока не получили подобного распространения. В докладе делается обзор и сравнение актуальных DI-Framework’ов на C++, анализируется их применимость к практическим задачам ЛК. Анализируется, что могут привнести стандарты C++11/14 для упрощения решения таких задач.
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
Сейчас только ленивый не говорит про DevOps, краеугольным камнем которого является организация потока непрерывной доставки ценности клиенту. Continuous Delivery перестаёт быть опцией и становится обязательным требованием.
В докладе будут рассмотрены:
- общие подходы к организации Continuous Delivery на базе Jenkins-а в совсем не тепличных условиях
- практики и подходы, которые позволяют быстро настраивать и собирать десятки микросервисов
- подводные камни, с которыми пришлось столкнуться, и способы борьбы с ними
Зачем нужен и что такое докер. Чем он отличается от виртуальных машин. Как создать, сохранить и запустить свой докер-контейнер.
Обновленная презентация с шестого 4front митапа в Минске.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Контроль окружения сборки C++ проектов с помощью Docker. Павел Филонов. CoreH...corehard_by
При сборке C++ проектов под различные компиляторы и операционные системы часто возникает необходимость контролировать окружение (версии компиляторов, ОС и библиотек), в котором происходит сборка проекта. В докладе рассмотрен подход к этой задаче с помощью упаковки сборочного окружения в Docker образы.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
- Краткая вводная про Docker (namespaces, cgroups и как Docker все это использует)
- Как заходить в Docker из вашего софта?
- Примеры: pam_docker и php_fpm_docker
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
TК°Conf. Микросервисы и Docker. Глеб Паньшин.TKConf
Когда вы пытаетесь следовать гибким методологиям, создавать небольшие автономные команды, микросервисы в вашем проекте появляются естественным путем. Или нет. Обязательно поговорим о "Монолит vs. Микросервисы". И хотя эти маленькие трудяги помогают вам scale и достигать agility они неплохо добавляют вам проблем с доставкой и разработкой.
В заключении попробую ответить на вопрос как деплоить 5 или 50 микросервисов? Не знаю, но давайте попробуем Docker.
Материалы со встречи:
https://getdev.net/Event/docker
Docker: зачем нужен и почему выстрелил? Контейнеры против виртуальных машин - кто лучше? Docker на Windows: как и когда? А также демо: создание и deploy контейнера на ваших глазах
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
Михаил Боднарчук "Docker для PHP разработчиков" Fwdays
Это не рассказ о том, как из разработчика стать крутым DevOpsом. Это доклад о том, как можно сделать процесс разработки и развертки приложения комфортнее и эффективнее вместе с прогрессивной технологией контейнеризации - Docker.
В этом докладе я затрону следующие темы:
Docker - это то модное слово, которое все должны знать
Дирижирование оркестром вместе с Docker Compose
Создание и настройка рабочего окружения в Docker
Построение сервисно-ориентированых приложений
Безболезненное развертывание приложений с Shipyard
То, чего не хватало для Continuous Integration - запуск параллельных билдов
В докладе рассказывается об опыте применения «инверсия управления» (Inversion of Control) при разработке новой версии KES. Этот подход заключается в том, что более высокоуровневый код не зависит напрямую от конкретной реализации нижележащего слоя. Вместо этого он зависит от абстрактного протокола (интерфейса), конкретный же компонент подставляется конфигурационным кодом-клиентом. Эта практика позволяет понизить loose coupling программных модулей и применяется практически в любых крупных проектах.
При разработке новой версии KES было принято решение изменить подход к реализации инверсии управления. Было решено отказаться от централизованного обобщенного реестра доступных компонентов (шаблон (паттерн) Service Locator) в пользу явной передачи зависимостей конфигуратором (ручная инъекция зависимостей (manual Dependency Injection)). При это возникли проблемы с использованием готовых библиотек Dependency Injection Frameworks. Применение подобных библиотек стало стандартом в мире разработки Java/C# за последние 10-15 лет, но в мире C++ они пока не получили подобного распространения. В докладе делается обзор и сравнение актуальных DI-Framework’ов на C++, анализируется их применимость к практическим задачам ЛК. Анализируется, что могут привнести стандарты C++11/14 для упрощения решения таких задач.
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
Сейчас только ленивый не говорит про DevOps, краеугольным камнем которого является организация потока непрерывной доставки ценности клиенту. Continuous Delivery перестаёт быть опцией и становится обязательным требованием.
В докладе будут рассмотрены:
- общие подходы к организации Continuous Delivery на базе Jenkins-а в совсем не тепличных условиях
- практики и подходы, которые позволяют быстро настраивать и собирать десятки микросервисов
- подводные камни, с которыми пришлось столкнуться, и способы борьбы с ними
Зачем нужен и что такое докер. Чем он отличается от виртуальных машин. Как создать, сохранить и запустить свой докер-контейнер.
Обновленная презентация с шестого 4front митапа в Минске.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Контроль окружения сборки C++ проектов с помощью Docker. Павел Филонов. CoreH...corehard_by
При сборке C++ проектов под различные компиляторы и операционные системы часто возникает необходимость контролировать окружение (версии компиляторов, ОС и библиотек), в котором происходит сборка проекта. В докладе рассмотрен подход к этой задаче с помощью упаковки сборочного окружения в Docker образы.
"How to build powerful CI / CD based on GitLab and Docker", Aleksandr Matkovs...Provectus
Aleksandr Matkovskiy – Head of IT Department lives and works with the motto "Scaling and load balancing is our all!". Therefore, he has 3 sons and dreams to find DEV for his OPS.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Vladislav Anikin – Team Leader & Software Architect, specializing in SAAS flexible and scalable solutions for business. Driving DDD/TDD oriented squad of awesome SOLID developers.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...corehard_by
Использование сторонних библиотек в языке C++ никогда не было простым - необходимо было правильно собрать их, имея дело с различными системами сборки, но с появлением пакетного менеджера conan.io процесс стал намного проще, так что теперь осталось только сделать пакеты для нужным библиотек, и в этом поможет команда bincrafter-ов.
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотниковcorehard_by
На предыдущих конференциях C++ CoreHard автор доклада рассказывал про Модель Акторов и опыт ее использования в C++. Но Модель Акторов -- это далеко не единственный способ борьбы со сложностью при работе с многопоточностью. Давайте попробуем поговорить о том, что еще можно применить и как это может выглядеть в C++.
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титовcorehard_by
Если вам важна скорость работы ваших программ, то вы обязаны понимать, как работает ваше "железо". Современный процессор -- это сложное устройство, многие механизмы которого могут неочевидным образом влиять на скорость исполнения вашего кода. В докладе дается обзорное представление основных структур современного процессора и подробно рассматривается работа иерархии памяти. Будут освещены следующие темы: организация кэш-памяти, принцип локальности, предподкачка данных, нежелательное общее владение данными, а также программные техники для эффективной работы с памятью.
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...corehard_by
Информационная безопасность все больше из отдельной сферы плавно перетекает в разработку ПО. А значит «обычным» программистам приходится понимать те требования и терминологию, которые специалисты по безопасности уже давно знают и используют. CWE, CERT, MISRA, SAST– для «обычных» программистов это непонятные аббревиатуры. Поэтому в обзорном докладе мы попробуем рассказать простым языком об этих понятиях так, чтобы все разработчики начали уверенно ориентироваться в этой теме.
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишковcorehard_by
Вот уже более двух лет мы создаём онлайн-специализацию по С++ на платформе Coursera. Её цель — обучить языку C++ с нуля до уровня, достаточного для решения практических задач, с которыми приходилось сталкиваться авторам в своей практике. В своём докладе я расскажу, как мы создаём наши онлайн-курсы, и уделю особое внимание техническим проблемам, которые нам пришлось решить в процессе создания автоматической системы проверки программ студентов.
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...corehard_by
В докладе обсуждаются способы улучшения времени сборки C++ проектов, опыт полученный в ходе ускорения сборки клиента и тулов World Of Tanks. Также описывается эффект, который они оказывают на организацию кодобазы (как позитивный, так и негативный) и затраты, которые необходимы для поддержки этих решений, т.к. не все они бесплатны. Методики, описываемые в докладе: ускорение линковки (Incremental Linking, Fastlink), ускорение компиляции(Include what you use, использование precompiled headers).
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...corehard_by
Доклад посвящён вопросам реализации пропозала Герба Саттера PR0707 (метаклассы в С++) за пределами компилятор - в виде отдельной утилиты. Будет продемонстрированы варианты использования метаклассов в реальной жизни, затронуты вопросы их реализации на базе Clang Frontend, а также возможные перспективы развития технологии и методики.
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...corehard_by
Все мы знаем, что компиляторы в настоящее время достаточно умные. И нам как программистам зачастую не нужно думать о каких-то незначительных оптимизациях - мы полагаемся на оптимизации компилятора. Что ж, настало время выяснить, действительно ли настолько компиляторы умны и узнать, в каких местах программист всё же (может быть) умнее.
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...corehard_by
В докладе будет рассмотрена генерация кода при компиляции различных языковых конструкций, как простых, так и сложных, на различных платформах, как общераспространённых x86/x64, так и тех, которым уделяется меньше внимания: ARM, AVR. Также будут встречаться примеры для совсем экзотических процессоров вроде PowerPC и даже MicroBlaze. Основной упор будет делаться не на обработку данных, а именно на сопоставление различных конструкций кода с инструкциями целевых платформ.
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...corehard_by
What do threads, atomic variables, mutexes, and conditional variables have in common? They are the basic building blocks of any concurrent application in C++, which are even for the experienced C++ programmers a big challenge. This massively changed with C++17 and change even more with C++20/23. What did we get with C++17, what can we hope for with C++20/23? With C++17, most of the standard template library algorithms are available in sequential, parallel, and vectorised variants. With the upcoming standards, we can look forward to executors, transactional memory, significantly improved futures and coroutines. To make it short. These are just the highlights from the concurrent and parallel perspective. Thus there is the hope that in the future C++ abstractions such as executors, transactional memory, futures and coroutines are used and that threads, atomic variables, mutexes and condition variables are just implementation details.
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...corehard_by
Язык C++, претерпев долгую эволюцию, обрёл ряд черт, характерных для функциональной парадигмы: функции стали полноправными объектами, над которыми могут выполняться операции, а аппарат шаблонов позволяет проводить вычисления на типах на этапе компиляции. Математический фундамент этих двух главных аспектов составляют, соответственно, ламбда-исчисление и теория категорий. Расширение языка этими средствами способствовало реализации на языке C++ ряда инструментов, известных из функционального программирования. Некоторые из этих реализаций вошли в стандартную библиотеку (std::function, std::bind), другие - в сторонние библиотеки, в том числе в коллекцию библиотек Boost (functional, hana). Важную роль в арсенале функционального программирования играют операции свёртки и развёртки, которые очевиднее всего определяются для списков, но также естественным образом обобщаются на другие индуктивные и коиндуктивные структуры данных. Например, суммирование списка чисел можно представить себе как свёртку списка по операции сложения, а построение списка простых множителей заданного целого числа - как развёртку. Обобщения свёртки и развёртки известны как анаморфизмы и катаморфизмы. Также в функциональном программировании находит применение понятие гиломорфизма - композиция развёртки некоторого объекта в коллекцию с последующей свёрткой её в новый объект. В докладе продемонстрировано, что свёртки, развёртки и их композиции допускают довольно простую реализацию на языке C++.
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филоновcorehard_by
Доклад посвящен часто используемому шаблону в моих проектах по анализу данных, когда обучение и настройка моделей происходят с использованием python, а вот их запуск в промышленное использование на языке C++. Предлагается рассмотреть несколько учебных примеров реализации такого подхода, от простой линейной регрессии до обработки изображений с помощью нейронных сетей.
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukićcorehard_by
This talk will be about the design and implementation of a reactive programming model inspired by ranges that allows easy implementation of asynchronous and distributed software systems by writing code that looks like a sequence of ordinary range transformations like filter, transform, etc. This programming model will be demonstrated along with the implementation of a simple asynchronous web service where the whole system logic is defined as a chain of range transformations.
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakovacorehard_by
Macros, templates, compile-time evaluation and code generation, reflection and metaclasses – C++ tends to hide the final code passed to the compiler under the tons of various names and aliases. Add here the preprocessor that shadows the actual running curve of your program with dozens of alternatives mixed in a non-trivial way. While this allows to avoid boilerplate code and reduce copy-paste and other errors, such an approach demands better tooling support to make the debugging process easier. To find an error in such a code, one has to continuously read-fix-run it and compare the results with some etalon, or to debug in order to find actual substitutions. But should you really wait until your code is run or even compiled to debug it? Or how to deal with the situations when the code can’t be run on the local machine? A text editor with code completion won’t help, while a smart IDE that “gets” your code can do a better job. In this talk we’ll see interesting approaches to solving cases like macro and typedef ‘debug’, understanding types when auto/decltype hide them, dealing with different code branches depending on the preprocessor’s pass-through, and other ideas. Some suggestions are already implemented as ready-to-use features in CLion and ReSharper C++, tools for C++ from JetBrains (that means I can show it in action), others are planned for the future. The aim of this talk is to share the workflows supported by the tools that can help C++ developers create better modern C++ code.
C++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухинcorehard_by
В C++11 добавили новое ключевое слово - constexpr. Выглядит оно весьма невзрачно, да и на первый взгляд кажется, что смысла в нём маловато... Для чего же оно нужно, какие у него есть тайные супер способности и какую роль оно сыграет в дальнейшем развитии языка C++ - обо всём об этом мы и поговорим.
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...corehard_by
Text formatting has been a favorite problem of C++ library authors for a long time. The standard C++ iostreams have been criticized for being difficult to use due to their statefulness and slow due to runtime polymorphism. Despite its age, printf is still popular because of simplicity and speed. The Boost library offers two more alternatives, Boost.Format and Boost.LexicalCast. And finally, the P0645 standard proposal sponsored by Facebook is currently finding its way through the C++ committee. All these approaches are still firmly based on standard containers and iterators. But the Standard Library is changing radically with the advent of ranges, range adaptors and functional style programming in C++. Generating optimized code with metaprogramming is becoming standard fare. In this talk, I want to convince you that the combination of ranges with a bit of metaprogramming makes for a very elegant solution to the text formatting problem. We introduce a form of ranges with internal iteration, which are generating their elements one by one rather than exposing external iterators. We can use these generator ranges to represent the values to be formatted, conceptually turning them into lazily evaluated strings. These can be used just like regular strings are used today: in function returns; as standard algorithm input; embedded into other, equally lazily evaluated strings; and so on, before they are finally expanded for display. By choosing the right interfaces, we can optimize this expansion at compile-time, making it no less pretty to write, but more efficient to expand than any text formatting approaches that rely on format strings that must be parsed at runtime. I believe that this approach is the natural extension of a range-based future standard library to text formatting.
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019corehard_by
Память в компьютере - это не только гигабайты оперативной памяти в слоте, но и занятная абстракция. В докладе мы рассмотрим, как можно эту абстракцию использовать необычным образом для моделирования других абстракций - регистровых файлов периферийных устройств. Доклад будет полезен не только embedded-разработчикам, но и, возможно, заставит переосмыслить свой взгляд на память.
Как помочь и как помешать компилятору. Андрей Олейников ➠ CoreHard Autumn 2019corehard_by
Как правило, можно положиться на то, что компилятор оптимизирует результирующий бинарный файл так, чтобы она работала максимально быстро. Но компилятор не знает на каких данных и на каком железе программа будет запущена. Плюс хотелось бы, чтобы компиляция занимала приемлемое время. Из-за этого результат может оказаться субоптимальным. Предлагаю на примерах для LLVM посмотреть как можно подсказать компилятору как оптимизировать программу и сделать результат лучше или хуже.
Статичный SQL в С++14. Евгений Захаров ➠ CoreHard Autumn 2019corehard_by
Xочу рассказать про разработку библиотеки ORM для SQLite3 на С++14 (https://github.com/fnc12/sqlite_orm). В докладе хочется поделиться своим опытом в попытке создать ORM с которой можно забыть про текстовые запросы и как это адаптируется в С++ при помощи шаблонов.
6. Проблемы?
● Пришел новый человек и ему нужно объяснить как собирается проект
● Надо обновить библиотеку т.к. старая версия небезопасна
● Билд сервер упал со скалы
● За билд сервером со скалы прыгнул единственный человек который
знает как это собирать для продакшена
9. Package manager conan find cmake api
Conanfile
Описание
зависимостей
findsomething.cmake
findboost.cmake
Информация где находятся
зависимости
Cmakelists
find_package
Уже собранные зависимости
11. Проблемы? Решены только две
● Пришел новый человек и ему нужно объяснить как собирается проект
● Надо обновить библиотеку т.к. старая версия небезопасна
● Билд сервер упал со скалы
● За билд сервером со скалы прыгнул единственный человек который
знает как это собирать для продакшена
● Версия GCC, Conan, Cmake
12. Docker
Что такое докер?
● Это не виртуальная машина.
● Это песочница
● способ описывать окружение в виде файлов
● возможность иметь везде одинаковое окружение
● способ изолировать ваше приложение от неявных зависимостей
14. Docker
Dockerfile для сборки
FROM centos:7.6.1810
COPY yum_packages.txt /tmp/yum_packages.txt
RUN xargs -a /tmp/yum_packages.txt yum install -y
ENV BOOST_ROOT=/home/devel/boost_1_60_0
USER=devel
15. Docker
Для работы с контейнером нужно 2 простых команды
docker build -t pcf_docker ./docker
docker run --rm -v $(pwd):/home/devel/build_dir -v /tmp:/tmp pcf_docker
./buildscript.sh
16. Docker
Но иногда приходится писать так
docker run --privileged --dns=1.1.1.1 --rm -v $(pwd):/home/devel/build_dir -v
/tmp:/tmp pcf_docker bash -c "snmpd; rsyslogd; ./docker/copy_mibs.sh; cd
/home/devel/build_dir/pcf; (su devel -c './buildscript.sh $command;')"
18. Можно:
Присоединяться к запущенному контейнеру и выполнять параллельно gdb
через docker exec
Запускать GDB в контейнере и открывать порт
Главное дать нужные параметры при запуске контейнера
--cap-add=SYS_PTRACE --security-opt seccomp=unconfined
Дебаг
19. CLion: удаленное подключение к контейнеру по ssh, закачивание исходников,
скачивание хедеров для быстрого локального резолва
VSCode: запуск серверной части внутри контейнера
Подсветка
20. Пример из VSCode: devcontainer.json
{
name": "kam",
"dockerFile": "../docker/dockerfile",
"runArgs":
["-u","1000","--cap-add=SYS_PTRACE","--security-opt","seccomp=unconfined"],
"extensions": ["ms-vscode.cpptools"]
}
Docker
21. Проблемы?
НЕТ
Полностью изолированное детерминированное окружение для сборки билда
как на машине разработчика, так и на билдсервере, билдсервер и есть докер
контейнер собранный из рецепта который находится рядом с исходниками
22. Проблемы?
Помимо сборки девелоперы запускают тесты
Добавим в контейнер:
Юнит тесты при сборке
Скрипт с несколькими приложениями внутри одного контейнера
34. Решение
Клиента теперь два.
Если клиент получил невалидный ответ, он пробует еще раз
Два сервера, распределение нагрузки между ними через лоад балансер
46. Docker контейнер для приложения
Dockerfile
Установи Cmake
Собери Boost
Скачай libxml
Docker image
Собранный образ готовый к
запуску сторонних приложений
Общая папка
Исходники
Кеш сборки
Docker image и есть
артефакт сборки
47. Отличия от контейнера для сборки:
● Минимальный размер
весь tmp остается за бортом контейнера
● Отсутствие лишнего
нет не используемых инструментов
● Простота использования
снаружи передается только несколько конфигурационных параметров
Docker контейнер для приложения
50. Kubernetes
kubectl create -f podtemplate.yml
POD template yaml
metadata:
name
labels: пары ключ значение
container: название контейнера
POD
Контейнер управляемый kubernetes
66. Объединим
merge request
build pvs
code
close and
merge into CD
branch
merge request
builds pvs
test
deploy
wait
30m
metrics
ok?
close
and
merge
deploy
rest
cd
branch
tests,
valgrind
tests,
valgrind
68. Вася
Вася ошибся в коде, за него это нашел статический анализатор и отправил
ему письмо. Почини вот тут.
Прошел месяц, он быстро фиксил баг и не запустил все тесты, а тесты
сломались… все
Через месяц он изменил систему конфигурации приложения и опечатался.
Проблема локализована во время замены одного тестового сервера и ни
один клиент не был затронут.
Потом всю команду уволили, ведь они теперь не обладают тайными
знаниями как все должно работать, знания документированы рядом с кодом.