Linux Control Groups (Контрольные группы) -- механизм, позволяющий управлять группами процессов в Linux и их ресурсами. Это мощный инструмент о котором знают далеко не все. Презентация дает краткий обзор.
Виртуализация уровня операционной системы в Linux (так, называемые контейнеры) опирается на изоляцию ресурсов и на управление их использованием. Пространства имен в Linux (linux namespaces) тот инструмент, который позволяет изолировать ресурсы друг от друга на уровне имен. Например, именами процессов являются их идентификаторы (PIDs), которые можно организовать таким образом, что процессы никогда не могут узнать о существовании друг друга. Об этом и других интересных вещах рассказывается в презентации.
Linux Control Groups (Контрольные группы) -- механизм, позволяющий управлять группами процессов в Linux и их ресурсами. Это мощный инструмент о котором знают далеко не все. Презентация дает краткий обзор.
Виртуализация уровня операционной системы в Linux (так, называемые контейнеры) опирается на изоляцию ресурсов и на управление их использованием. Пространства имен в Linux (linux namespaces) тот инструмент, который позволяет изолировать ресурсы друг от друга на уровне имен. Например, именами процессов являются их идентификаторы (PIDs), которые можно организовать таким образом, что процессы никогда не могут узнать о существовании друг друга. Об этом и других интересных вещах рассказывается в презентации.
Непрерывная интеграция Python-проектов в ЯндексеAndrey Kazarinov
Рутинные операции тестирования, сборки и развёртывания заставляют в нервном ожидании толстеть на кофепоинте, а частый релизный цикл создаёт лёгкое головокружение? Чтобы помочь вам сохранить тело подтянутым, а голову светлой, я расскажу об организации и особенностях непрерывной интеграции в Python-проектах на примере популярных инструментов.
Лучшие практики 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?
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Полной автоматизацией процесса сборки приложения уже никого не удивишь. Не в последнюю очередь благодаря Maven – системе управления жизненным циклом проекта. Однако проекты растут очень быстро: увеличивается количество модулей, тестов, зависимостей, используемых плагинов. И всего лишь за год легковесный проект, на сборку которого уходило 5 минут, превращается в монстра, который пожирает время разработчиков 30-минутной сборкой. Чтобы справится с этой проблемой разработчикам приходится постоянно чистить свой код и бороться со скоростью выполнения тестов. Это верное решение, но не следует забывать о том, что и сам процесс сборки можно улучшить. В этом докладе будет рассмотрено, как при помощи простых и нехитрых шагов можно оптимизировать работу с зависимостями и обогатить скрипты сборки полезными плагинами. Также будут обсуждаться тонкости конфигурации основных плагинов и особенности работы с командной строкой, которые появились в последней версии Maven.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Непрерывная интеграция Python-проектов в ЯндексеAndrey Kazarinov
Рутинные операции тестирования, сборки и развёртывания заставляют в нервном ожидании толстеть на кофепоинте, а частый релизный цикл создаёт лёгкое головокружение? Чтобы помочь вам сохранить тело подтянутым, а голову светлой, я расскажу об организации и особенностях непрерывной интеграции в Python-проектах на примере популярных инструментов.
Лучшие практики 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?
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Полной автоматизацией процесса сборки приложения уже никого не удивишь. Не в последнюю очередь благодаря Maven – системе управления жизненным циклом проекта. Однако проекты растут очень быстро: увеличивается количество модулей, тестов, зависимостей, используемых плагинов. И всего лишь за год легковесный проект, на сборку которого уходило 5 минут, превращается в монстра, который пожирает время разработчиков 30-минутной сборкой. Чтобы справится с этой проблемой разработчикам приходится постоянно чистить свой код и бороться со скоростью выполнения тестов. Это верное решение, но не следует забывать о том, что и сам процесс сборки можно улучшить. В этом докладе будет рассмотрено, как при помощи простых и нехитрых шагов можно оптимизировать работу с зависимостями и обогатить скрипты сборки полезными плагинами. Также будут обсуждаться тонкости конфигурации основных плагинов и особенности работы с командной строкой, которые появились в последней версии Maven.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Приемы Сontinuous Integration при разработке приложений на CachéInterSystems CEE
Об организации автоматизированного рабочего процесса в InterSystems Caché, Лебедюк /
Implementing modern developement practices with InterSystems Caché, Eduard Lebedyuk
Approach on how make Continuous Integration development cycle with InterSystems Caché.
Caché Object Script solution for CI with Github
https://github.com/intersystems-ru/CacheGitHubCI
Open Source Testing Framework: real project example and best practicesAliaksandr Ikhelis
Summary: Presentation on open source testing frameworks (improved version, more focus on real project example) at Software Engineering Forum 2009 (SEF-1) conference by Aliaksandr Ikhelis. Sponte framework developer and owner is Stanislaw Wozniak, Expedia Limited, UK. Sponte project homepage: http://rubyforge.org/projects/sponte/; http://github.com/swozniak/sponte/tree/master
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
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-системами.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
6. 〉Частые релизы (2-3 раза в неделю) + хотфиксы
〉До 10 одновременных разработчиков проекта
〉Много подпроектов, микросервисов, библиотек, пакетов (>20)
〉Много зависимостей, включая бинарные (>10)
〉Debian-пакеты
6
Условия разработки
7. 〉Несколько окружений (development, testing, prestable, production)
〉Большое количество серверов (от 3-х до нескольких сотен)
〉Разные платформы Ubuntu (lucid, precise, trusty)
〉Необходимость переживать учения (N-1 датацентр)
7
Условия эксплуатации
8. 〉N-1 датацентр
〉Плановые – замена сетевого оборудования
〉Внеплановые – бешеный экскаваторщик, котик в подстанции
〉Периодически
8
Учения
Подробнее: Как и для чего Яндекс отключает собственные дата-центры – https://clck.ru/9aWTK
Сервис без downtime и желательно без read-only
11. 〉«Собираем всех в одно гнездо» – все разработчики и проекты
разрабатываются на одной dev-машине
〉«Virtualenv в каждый дом»
〉«Береги код смолоду» (pep8, flake8, … )
〉«Trust but check»
11
Наши принципы
13. 〉Микросервисы
〉Frontend + Backend API
〉HTTP/HTTPS, решительное нет CORBA
〉from XML to JSON
〉Infrastructure as a Service (OpenStack)
〉PaaS хостинг приложение (Cocaine)
13
Архитектурные принципы
16. 〉Unit-тесты пишутся разработчиками (unittest2, nose, pytest)
〉Code coverage (в среднем 70-80%, >10к тестов в одном из проектов)
〉Моки внешних сервисов
〉Часто запускаются разработчиками
〉Прогоняются при сборке
16
Unit-тесты
17. 〉Пишутся тестировщиками
〉Автоматизируем там, где это возможно
〉Ansible – тестовые сценарии
〉HTML Elements – тестирование интерфейсов
〉Allure Framework – построение отчетов
〉Запускаются тестировщиками перед релизом
17
Функциональное тестирование
18. 〉Оценка производительности для расчета количества серверов
〉Сравнение различных технологических решений
〉Выявление скрытых багов, проявляющихся под нагрузкой
〉Периодическая регрессионная проверка производительности
18
Нагрузочное тестирование
19. 〉Яндекс.Танк
мониторинг ресурсов
интерфейс для вывода графиков и управления «стрельбой»
модульность
различные профили нагрузки
поддержка различных протоколов (HTTP/SMTP/POP3/FTP/DNS)
〉«Стрельба» ведется на отдельном нагрузочном стенде
〉«Мишень» –микросервис или отдельный функционал сервиса
〉«Патроны» – подготовленные HTTP запросы
19
Яндекс.Танк
Подробнее: Яндекс.Танк – https://tech.yandex.ru/tank/
26. 〉Созданное окружение в pbuilder уничтожается
〉Прокидываем директории для кэша из системы при инициализации
образа
.pbuilderrc
BINDMOUNTS=<path to cache>
HOOKDIR=<path to hooks>
26
Хитрости кэширование Python Wheels
Подробнее: Pip install – почему так медленно? https://clck.ru/9ab2b
31. 〉Каждое изменение должно интегрироваться
〉Тесты
〉Быстрая сборка (<10 минут)
〉Интеграция на выделенной машине
31
Принципы непрерывной интеграции
32. 〉TeamCity
〉Агенты для проекта и есть общий пул агентов
〉Шаблоны сборок
〉Интеграция с GitHub
〉Conductor – установка пакета на сервера (внутренний продукт)
32
Система непрерывной интеграции
Подробнее: Непрерывная интеграция Python-проектов в Яндексе – https://clck.ru/9aWTZ
41. 1. Сборка пакета
1. Создание изолированного окружения
2. Сборка virtualenv с тестовыми утилитами
3. Тестирование с coverage
4. Сборка продакшен virtualenv
2. Публикация результатов coverage в GitHub (в pull request)
3. Загрузка debian-пакета на внутренний debian-репозиторий
4. Загрузка python-пакета на внутренний PyPI (в случае библиотеки)
5. Тикет в систему деплоймента пакетов (Conductor)
41
Шаги
47. 〉Выявление багов на раннем этапе – дешевле разработка
〉Частые релизы – ускоренный feedback
〉Аккуратный однотипный код – легче поддерживать
47
Для менеджеров
48. 〉На одной машине могут стоять пакеты с зависимостями различных
версий (virtualenv)
〉Пакет собирается в окружении близком к production (pbuilder)
〉Легко создавать новые сборки (унифицикация сборок, шаблоны)
〉Быстрая сборка пакета (до 10 минут) (кэширования Python Wheels)
48
Для разработчиков
51. 〉Контроль за стилем кода – https://events.yandex.ru/lib/talks/2444/
〉Как и для чего Яндекс отключает собственные дата-центры –
http://habrahabr.ru/company/yandex/blog/243033/
〉Pip install – почему так медленно? https://events.yandex.ru/lib/talks/3070/
〉Непрерывная интеграция Python-проектов в Яндексе –
https://events.yandex.ru/lib/talks/3071/
51
Источники