The report tells about one of the largest open-source projects written in the python language - OpenStack, what it consists of, how development is carried out. I also tell you how to become a member of the community and start contributing to the project. The report is very useful for novice developers who are just starting their steps in the world of OpenStack.
Abstract: https://conf.python.ru/2019/abstracts/4607
Video: https://www.youtube.com/watch?v=coD5f4ALGug
Как показывает практика, повсеместное применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход — с использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая код из асинхронного в синхронный.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Семинар по Node.js в КПИ 20 октября 2014. Докладчики: Тимур Шемсединов, Никита Савченко, Максим Петренко. Краткое содержание:
* Что такое Node.js и как работает JavaScript в V8
* Профессионалы расскажут, почему они выбрали Node.js
* Вы узнаете его сильные и слабые стороны и где его лучше применять
* Будет полный обзор особеностей и внутреннего строения Node.js
* Примеры внедрения и Highload-проекты
* Вопросы развертывания, хостинг, тестирования, и отладки
* Где и что учить, что читать, как осваивать
Ловля сетями. Инструменты отладки сетевых запросов приложений / Дмитрий Рыбак...Ontico
РИТ++ 2017, AppsConf
Зал Найроби + Касабланка, 5 июня, 11:00
Тезисы:
http://appsconf.ru/2017/abstracts/2584.html
Большинство современных мобильных приложений так или иначе работает с каким-то API (а зачастую и не с одним). Количество запросов при этом может достигать десятков в минуту и понимание того, что сейчас происходит в сетевом слое вашего приложения, становится непростой задачей.
Я расскажу и покажу весь диапазон современных средств для мониторинга и отладки сетевых запросов: от самых простых до узкоспециальных - с плюсами/минусами каждого из инструментов и областями их применения.
Как показывает практика, применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход, основанный на прозрачном использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая его в понятный, легко читаемый и структурируемый код.
Как показывает практика, повсеместное применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход — с использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая код из асинхронного в синхронный.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Семинар по Node.js в КПИ 20 октября 2014. Докладчики: Тимур Шемсединов, Никита Савченко, Максим Петренко. Краткое содержание:
* Что такое Node.js и как работает JavaScript в V8
* Профессионалы расскажут, почему они выбрали Node.js
* Вы узнаете его сильные и слабые стороны и где его лучше применять
* Будет полный обзор особеностей и внутреннего строения Node.js
* Примеры внедрения и Highload-проекты
* Вопросы развертывания, хостинг, тестирования, и отладки
* Где и что учить, что читать, как осваивать
Ловля сетями. Инструменты отладки сетевых запросов приложений / Дмитрий Рыбак...Ontico
РИТ++ 2017, AppsConf
Зал Найроби + Касабланка, 5 июня, 11:00
Тезисы:
http://appsconf.ru/2017/abstracts/2584.html
Большинство современных мобильных приложений так или иначе работает с каким-то API (а зачастую и не с одним). Количество запросов при этом может достигать десятков в минуту и понимание того, что сейчас происходит в сетевом слое вашего приложения, становится непростой задачей.
Я расскажу и покажу весь диапазон современных средств для мониторинга и отладки сетевых запросов: от самых простых до узкоспециальных - с плюсами/минусами каждого из инструментов и областями их применения.
Как показывает практика, применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход, основанный на прозрачном использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая его в понятный, легко читаемый и структурируемый код.
Занятие в Школе Сисадмина.
Основано на http://www.slideshare.net/IlyaAlekseyev/openstack-12003939
Событие: https://vk.com/shkola_sysadm
Лектор: https://vk.com/vse_v_moei_golove
Материалы со встречи:
https://getdev.net/Event/docker
Docker: зачем нужен и почему выстрелил? Контейнеры против виртуальных машин - кто лучше? Docker на Windows: как и когда? А также демо: создание и deploy контейнера на ваших глазах
Лабораторные работы (практикум) по операционным системам и средам. Материал разработан специально для ресурса www.studentam-in.ru на котором Вы можете найти бесплатные учебные материалы и получить качественные образовательные услуги: китайский и английский перевод; репетиторство; заказ курсовых, контрольных; создание презентации, баннера, контента, сайта и многое другое.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Занятие в Школе Сисадмина.
Основано на http://www.slideshare.net/IlyaAlekseyev/openstack-12003939
Событие: https://vk.com/shkola_sysadm
Лектор: https://vk.com/vse_v_moei_golove
Материалы со встречи:
https://getdev.net/Event/docker
Docker: зачем нужен и почему выстрелил? Контейнеры против виртуальных машин - кто лучше? Docker на Windows: как и когда? А также демо: создание и deploy контейнера на ваших глазах
Лабораторные работы (практикум) по операционным системам и средам. Материал разработан специально для ресурса www.studentam-in.ru на котором Вы можете найти бесплатные учебные материалы и получить качественные образовательные услуги: китайский и английский перевод; репетиторство; заказ курсовых, контрольных; создание презентации, баннера, контента, сайта и многое другое.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
4. ● совместная разработка Rackspace и NASA
● первый релиз 21 октября 2010
● написан на Python
● лицензия Apache License 2.0
● в настоящее время управляется Openstack Foundation
История
4
5. Миссия
5
"to produce the ubiquitous Open Source Cloud Computing platform that will meet
the needs of public and private clouds regardless of size, by being simple to
implement and massively scalable"
10. ● China Mobile
● eBay
● CERN
● Volkswagen AG
● AT&T
● VEXXHOST
● Adobe
● American Airlines
● Walmart
● Nike
● Oath/Yahoo!
● ...
https://www.openstack.org/user-stories
Кто использует?
10
11. ● > 12 млн. строк кода
● > 1 млн. коммитов
● > 15 000 контрибьюторов
● > 1500 проектов в целом
● 975 проектов Python
Размер в цифрах
11
12. Вклад комьюнити – Stackalytics
12 https://www.stackalytics.com/
Red Hat Other companies
VMware
Independent
developers
AT&T
Huawei
Canonical
Rackspace
SUSE
IBM
18. Devstack – маленький OpenStack для разработчиков
https://docs.openstack.org/devstack/latest/
$ sudo useradd -s /bin/bash -d /opt/stack -m stack
$ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
$ sudo su - stack
$ git clone https://git.openstack.org/openstack-dev/devstack
$ cd devstack
$ vim local.conf
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
$ ./stack.sh
18
19. Библиотеки OpenStack – Oslo
https://wiki.openstack.org/wiki/Oslo#Libraries
19
Mission Statement:
To produce a set of python libraries containing code shared by OpenStack projects. The
APIs provided by these libraries should be high quality, stable, consistent, documented and
generally applicable.
33. Oslo.report (Guru Meditation report)
https://docs.openstack.org/oslo.reports/latest/user/usage.html
from oslo_reports import guru_meditation_report as gmr
gmr.TextGuruMeditation.setup_autorun(version='13.0.0')
# kill -SIGUSR2 <process_id>
● показывает текущую конфигурацию (oslo_config)
● показывает threads и текущую точку выполнения
● показывает green threads (eventlet) и текущую точку выполнения
● Показывает процессы и их статусы
33
44. Taskflow – Flow-Based programming
44
● описывает декларативные процессы
● ведет контроль состояния
выполнения (контрольные точки)
● переносит данные между
несколькими workflow / task
● горизонтально масштабируется
● поддерживает удаленное
выполнение
● поддерживает версионирование flow
и task
https://docs.openstack.org/taskflow/latest/user/index.html
Это система для построения облачной инфраструктуры и управления пулами различных ресурсов: compute (виртуальные машины, контейнеры, bare-metal), storage, сетевыми ресурсами. Система позволяет управлять тысячами серверов как единым облаком, даже если эти сервера находятся в разных дата-центрах.
Openstack - это совместный проект начатый компаниями Rackspace и NASA в 2006 году. Первый релиз состоялся в 2010. В 2012 году была создана некоммерческая организация Openstack Foundation для развития проекта и его комьюнити. В настоящий момент более 600 компаний занимаются его разработкой, комьюнити насчитывает более 15000 разработчиков.
Основная миссия проекта: Создать облачную Open Source платформу которая будет соответствовать всем требованиям публичных и частных облаков вне зависимости от их размера.
Проект состоит из множества компонент. Каждый компонент - это отдельный репозиторий на github, со своей командой, со своей roadmap, core разработчиками, со своими правилами разработки, митингами и прочим. Каждый компонент выполняет определенную задачу. Например базовый-компонент Nova занимается всем что связано с compute ресурсами, то есть запускает виртуальные машины, управляет их настройками, миграциями и т.д. Другой базовый компонент Neutron занимается всем что связано с сетью: создает сети, адреса и управляет ими. В настоящий момент таких отдельных компонент-проектов больше 70.
Каждый компонент в свою очередь состоит из нескольких микросервисов и демонов запускаемых на разных серверах облака. Одни микросервисы выполняют роль REST API серверов, другие - worker-ы выполняют задания, третьи занимаются мониторингом, четвертые сбором мусора и освобождением ресурсов. В каждом отдельном компоненте количество таких микросервисов может достигать 20ти штук.
Также в сообществе Openstack принято давать каждому компоненту маскот - какое нибудь животное. Полный список можно найти по ссылке.
Микросервисная архитектура и четкое разделение функциональности на компоненты позволяет на базе OpenStack строить различные сервисы собирая их как конструктор. На базе OpenStack можно построить инфраструктуру для целой компании-провайдера причем услуги предоставляемые провайдером могут сильно отличаться друг от друга.
Среди таких компаний - пользователей OpenStack множество крупных знаменитых компаний из различных областей.
Сейчас опенстек это почти 1000 репозиториев с кодом на Python и множество дополнительных инструментов, от средств аркистрации в готовом репозитории ansible до собственного CI “Zuul” заточенного под тестирование OpenStack.
Для сбора статистики по вкладу в разработку такого большого проекта OpenStack комьюнити написало отдельный проект в котором ведется подсчет всего связанного с разработкой, от ревью кода одного человека до вклада каждой компании в целом в проект. На слайде диаграмма с этого сайта со статистикой вклада в проект по компаниям. Обратите внимание что 27 с небольшим процентов - это разработчики не привязанные к компании, то есть свободные разработчики.
Это статистика по количеству строк кода от отдельных разработчиков. В топе очень преданные делу разработчики :)
OpenStack с первых дней разрабатывался как Open Source проект и процесс разработки в комьюнити отлажен как часы. Есть документации которая сможет ответить на все вопросы разработчика. В документации можно найти информацию обо всем, как ревьюить код, как его писать, как работает CI и т.д.
В проекте предъявляются высокие требования к качеству кода и его стабильности, поэтому все изменения проходят через систему ревью и массу тестов от запуска unit тестов до интеграционного тестирования в реальных дата-центрах.
Раз в пол года комьюнити формирует релиз (каждая команда каждого компонента формирует релиз с кодовым названием у себя). В дальнейшем до 18 месяцев ведется поддержка этого релиза с правками багов.
В каждом релизе замораживаются определенные версии не только самих компонент OpenStack но и версии библиотек с указанием максимальной версии каждой библиотеки которая может быть в этом релизе. Делается это с помощью файла upper-constraints.txt который также формируется под каждый релиз. Таким образом все компоненты работают на заранее обговоренных версиях библиотек, что гарантирует стабильность и дает возможность запустить все компоненты в одном пространстве на используя контейнеризацию или virutalenv.
Кстати поддержка constraints file в pip была добавлена сообществом OpenStack.
Два раза в год все core команды всех компонент собираются вместе на PTG (Project Team Getherings) для обсуждения целей на следующий релиз.
При ревью кода в комьюнити тоже свои стандарты. После пуша кода в gerrit происходит запуск тестов. Тесты могут занять несколько дней, так как иногда полностью разворачивается маленький OpenStack. После того как тесты пройдены в ченж добавляются ревьюеры. Core-reviewer может поставить +2 тем самым разрешив мержить, обычные же разработчики комьюнити могут поставить только +1 либо написать комментарии и поставить -1.
Для разработки такой сложной микросервисной системы как OpenStack нужно хорошо понимать как компоненты связаны между собой и уметь тестировать эти связи. Но для этого надо установить весь OpenStack. Для упрощения жизни разработчикам комьюнити создало проект devstack который позволяет запуститься OpenStack у себя локально на компьютере и начать разработку.
Комьюнити поддерживает 35 собственных библиотек которые объединены общим названием oslo. ОСновная цель создания библиотеки как всегда: избежать копи-паста в проектах и вынести все в отдельные модули.
Библиотека предоставляет несколько инструментов для написания безопасных многопоточных и многопроцессорных приложений. Например декораторы для синхронизации или вотчдог для контроля вызова подпроцессов или выполнения длительных операций.
Библиотека реализована так что необходимую функциональность можно получить в одну строку.
Библиотека предоставляет обертку над стандартной библиотекой логирования с теми же интерфейсами, а также несколько дополнительных хендлеров, нативную поддержку контекста openstack и авторизационных данных при логировании.
В примере на слайде показано как двумя строками можно включить логирование с подсветкой, для этого используются хендлер и формартер из библиотеки.
Так как библиотека имеет нативную поддержку контекста OpenStack что очень помогает для поиска проблем на проде.
В результате в логе будет что-то такое.
Библиотека предоставляет два API: первое клиент-сервер RPC (oslo.messaging.rpc), второе API для генерации и получения нотификаций (oslo.messaging.notify). В обоих случаях библиотека предоставляет простой интерфейс, обработчик ошибок, поддержку версий, поддержку нескольких backend шин для передачи сообщений.На слайде пример RPC клиента
А так будет выглядеть сервер, то есть исполнитель RPC запросов для этих сообщений. Несколько строк которые позволяют получить сообщение из RabbitMQ например и запустить исполнение.
Библиотека предоставляет инструмент для управления политиками доступа на уровне API или определенных методов в коде. Обладает очень большой гибкостью, можно настраивать политики по ролям, по параметрам контекста, по отдельным полям данных и т.д. Позволяет хранить политики в виде JSON файла и обновлять их на лету.
Это пример инициализации дефолтных политик для одного эндпоинта API.
Библиотеки для создания сервисов работающих длительное время в системе. Позволяет запускать многопоточные и многопроцессорные сервисы, обрабатывать системные сигналы, делать graceful restart, запускать периодические задачи. Библиотека Cotyledon была написана также сообществом openstack но менее заточена под работу только с Openstack.
На слайде шаблон для создания сервиса, который имеет очередь обработчиков.
Так выглядит запуск этого сервиса.
Библиотека для отладки многопоточных сервисов которые запущены длительное время. Позволяет без перезагрузки сервиса получить отчет в котором будет информация о текущем конфиге, запущенных потоках и процессах с указанием их точки выполнения. Эта библиотека помогает проводить отладку основных сервисов OpenStack в которых как правило больше 10 запущенных процессов.
Библиотека позволяет выполнять кросс-сервисное профилирование, что очень важно когда в проекте несколько сотен отдельно работающих микросервисов. Во всех базовых сервисах OpenStack точки профилирования уже есть, но также их можно добавить в любой место добавлением нескольких строк.
Апи библиотеки позволяет строить точку получения информации для профайлера в любое место парой строк.
После чего профилирование можно запускать как часть CLI команды OpenStack.
В итоге будет сформирована такая карта вызовов, в которой видно какой сервис участвовал в выполнении задачи, сколько это заняло времени.
Также можно посмотреть детали каждой отдельной части. Эта детальная информация как раз может содержать любую вашу информацию из точки профилирования.
Существуют аналоги OsProfiler но не заточенные под OpenStack. Все они позволяет производить подобное профилирование в микросервисной системе,
Эта библиотека была разработана комьюнити OpenStack но не заточена под него и может быть использована в любом проекте. Библиотека позволяет создавать модульные приложения с различными типами расширений. Библиотека предоставляет три типа расширений:
Driver - представляет из себя основную функциональность которая может быть включена. Основной момент: только один драйвер может быть включен в один момент в одном неймспейсе.
Extension - или по другому плагины - функциональность которая работает параллельно в одном приложении в одном месте, но выполняет разные задачи
Hook - функциональность которая выполняется при получении определенного события
Пример создания драйвера для приложения. По шагам: описываем API драйвера обозначая основные методы и что должны передать туда.
пишем сам драйвер который соответсвует созданному ранее интерфейсу и создаем alias для драйвера в entry_points
После установки пакета этот драйвер будет доступен для любого приложения на Python нужно только знать namespace и alias драйвера. Таким образом приложения и сервисы написанные с использованием stevedore могут быть расширены сторонними программистами без изменения основного кода. Библиотека Stevedore используется практически во всех сервисах OpenStack.
Библиотека требует в зависимостях oslo_utils и oslo_serialization, но не привязана к OpenStack и активно используется в других проектах. Библиотека позволяет создавать декларативные workflow с контролем состояния выполнения каждого отдельного таска а также возможностью отката изменений если один из тасков сфейлился. Также есть поддержка удаленного запуска отдельных задач.
Библиотека используется при выполнении длительных и сложных операций, как правило с взаимодействием между различными сервисами. Один такой flow может выполняться несколько десятков минут и важно достигнуть необходимого результата, при этом если что-то пошло не так, все выполненные ранее шаги будут откатываться к первоначальному состоянию, что обеспечивает консистентность данных.
Также средствами самой библиотеки можно генерировать график flow. Это не график предыдущей схемы, а пример флоу из документации но думаю суть ясна.
Подключайтесь к разработке OpenStack и станьте частью большого комьюнити. Если возникнут проблемы со стартом, всегда можете написать мне, я расскажу с чего начать и как. Вопросы.