Необходимость использования средств управления конфигурацией в процессе эксплуатации сложных веб систем быстро становится очевидной, тем не менее, использование различных средств управления конфигурацией имеет свои нюансы и тонкости. Разные системы управления конфигурацией создавались с учетом различающихся требований их создателей, и они по-разному решают возложенные на них задачи. Доклад посвящен обобщению практического опыта применения четырех средств управления конфигурацией — Chef, Puppet, SaltStack и Ansible в гетерогенных окружениях разного размера, построенных на базе различных UNIX-подобных платформ, от FreeBSD и Linux до SmartOS.
Целевая аудитория доклада: веб-разработчики, инженеры отделов эксплуатации.
Ее примерный уровень: средний.
Необходимость использования средств управления конфигурацией в процессе эксплуатации сложных веб систем быстро становится очевидной, тем не менее, использование различных средств управления конфигурацией имеет свои нюансы и тонкости. Разные системы управления конфигурацией создавались с учетом различающихся требований их создателей, и они по-разному решают возложенные на них задачи. Доклад посвящен обобщению практического опыта применения четырех средств управления конфигурацией — Chef, Puppet, SaltStack и Ansible в гетерогенных окружениях разного размера, построенных на базе различных UNIX-подобных платформ, от FreeBSD и Linux до SmartOS.
Целевая аудитория доклада: веб-разработчики, инженеры отделов эксплуатации.
Ее примерный уровень: средний.
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
SERP или просто страница результатов поисковой выдачи — это действительно большой проект с огромной аудиторией. Над ним работают около 40 фронтендеров из разных городов. Эта страница показывается больше 200 000 000 раз в день. При таких размерах даже модульная архитектура уже не слишком спасала нас от странных, неочевидных зависимостей, лишних стилей и нескольких разных реализаций почти одинаковых компонентов.
Процесс разработки новой, даже довольно простой на первый взгляд фичи занимал чудовищное количество времени и представлял из себя хаотичное взаимодействие большого количества людей: фронта, бэкенда, дизайнеров и менеджеров.
Стала закрадываться мысль, что пора что-то менять. И мы поменяли.
В докладе я расскажу о том, как мы с помощью проекта на стыке фронтендеров, менеджеров, и дизайнеров, навели во всем этом идеальный порядок. Каким образом поменяли наш код процессы и инструменты, а также что нам это дало, и как будем жить с этим дальше.
Если вам знакомы похожие проблемы, то наш опыт может оказаться вам чертовски полезным.
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
SERP или просто страница результатов поисковой выдачи — это действительно большой проект с огромной аудиторией. Над ним работают около 40 фронтендеров из разных городов. Эта страница показывается больше 200 000 000 раз в день. При таких размерах даже модульная архитектура уже не слишком спасала нас от странных, неочевидных зависимостей, лишних стилей и нескольких разных реализаций почти одинаковых компонентов.
Процесс разработки новой, даже довольно простой на первый взгляд фичи занимал чудовищное количество времени и представлял из себя хаотичное взаимодействие большого количества людей: фронта, бэкенда, дизайнеров и менеджеров.
Стала закрадываться мысль, что пора что-то менять. И мы поменяли.
В докладе я расскажу о том, как мы с помощью проекта на стыке фронтендеров, менеджеров, и дизайнеров, навели во всем этом идеальный порядок. Каким образом поменяли наш код процессы и инструменты, а также что нам это дало, и как будем жить с этим дальше.
Если вам знакомы похожие проблемы, то наш опыт может оказаться вам чертовски полезным.
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
«Масштабируемый DevOps» Александр КолесеньIT Share
Типичные подходы к развертыванию приложений: как правильные, так и неправильные, но повсеместно применяемые.
Как сделать так, чтобы развертывание не стало проблемой с линейным ростом количества поддерживаемых окружений.
Методы обновления проекта с нулевым временем простоя: когда это уместно и принципиально возможно.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление ок...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление окружениями в сложном проекте: Chef и другие", Александр Чистяков (ведущий разработчик Cezurity).
Аннотация
Облачный антивирус, который мы делаем в партнерстве с vk.com, отличается от типичного веб-проекта наличием большого числа специализированных и не очень специализированных подсистем. Это ставит перед отделом эксплуатации принципиально новые вызовы: нужно не только уметь реагировать на случайные сбои и предсказывать неслучайные, но и просто помнить где что лежит и какую задачу выполняет. О том, как мы отвечаем на эти вызовы в компании Cezurity - мой доклад.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Dmytro Nemesh "Building the perfect infrastructure with Kubernetes"Fwdays
Every company comes to a point where it’s infrastructure no longer fits team and business needs, and kludges are not working anymore. That’s the time to re-think and redesign the whole infrastructure. This is exactly where our company was half a year ago. I will talk about our experience dealing with this challenge while balancing between existing technology, costs, today’s reality and future needs.
"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.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
1. Соль как средство от боли:
SaltStack и его отличия от Chef
(c) Alexander Chistyakov,
Senior Cloud Engineer, Git in Sky
2. Докладчик
DevOps, что бы это ни значило
●
Ко-фаундер митапа DevOps-40
●
^ шутят ли в Сибири шутки про
смузи и коворкинг?
●
Ведущий (куда?) инженер
компании Git in Sky
●
7. Ущипните меня, я сплю!
Никто не привез доклад про
Chef? Как такое возможно!
●
Chef – это такой “старший брат”,
на которого я буду постоянно
оглядываться
●
^ 1.5 с лишним года...
●
8. Как это работает?
Любая* система управления
конфигурацией выглядит как:
●
Сервер – хранилище шаблонов
и правил генерации
●
Клиент – активный агент,
применяющий правила
●
*не любая (chef-solo, etc)
●
12. Как установить клиент?
“Однострочники” и там, и там
●
Регистрация на сервере
●
В SaltStack:
●
salt-key -L – список ключей
●
salt-key -A – подтверждение
●
В Chef не сложнее
●
13. Как выглядит клиент?
●
В Chef (это какой-то баг):
●
В SaltStack:
один процесс, ~30m RES
●
Клиент Chef лучше не
запускать как сервис
●
14. Общение сервера и клиента
Chef:
●
REST API на сервере
●
Клиенты ходят по HTTP,
инициируют коммуникацию
сами
●
Salt – все иначе
●
15. Клиент и сервер в Salt
Salt начинался как parallel
execution tool
●
Клиент всегда соединен с
сервером через 0MQ
●
Коммуникацию всегда
инициирует сервер
●
16. Parallel execution
В Chef тоже возможно сделать
●
Но очень, очень неприятно
●
Через SSH – клиенты должны
быть доступны
●
Символические имена - DNS
●
Через рубишный SSH
●
^ А он очень плох
●
17. Как описать конфигурацию
В Chef – свой DSL поверх
обычного Ruby
●
Исполнить Chef-рецепты без
Ruby на клиенте нельзя!
●
В Chef сто разных способов
связать ноду с конфигом
●
^ Роль, рецепт, атрибуты
●
18. Как описать конфигурацию
В SaltStack – DSL поверх YAML
●
На практике без вставок на
Python не обойтись
●
19. Как управлять конфигурацией
В Chef – команда knife со
специальной ноды (в любом
месте)
●
В Salt – управление только с
сервера командой salt:
●
salt '*' state.highstate
●
20. Как выглядит конфигурация
В Salt:
●
/srv/salt/pillar – данные
●
/srv/salt/states – стейты
●
Данные – это тоже YAML,
который описывает
(внезапно) данные
●
22. Как выглядят стейты
●
states/ntp/init.sls:
ntp:
<- имя реализации стейта
pkg:
<- имя стейта
- installed <- функция стейта
service:
- running
- enable: True
- require:
- pkg: ntp <- атрибут функции стейта
23. SaltStack лучше Chef?
Пока что я почти все время
хвалил SaltStack и ругал Chef
●
Но я не назвал доклад “Salt как
средство от Chef”
●
Если Salt во всем лучше, то
почему он не вытеснит
Chef?
●
24. Светлая сторона Chef
Кукбуки есть для решения
любой задачи
●
Внедрений гораздо больше
●
Процесс управления кукбуками
построен гораздо лучше
●
Есть юнит-тестирование
●
25. Управление кукбуками в Chef
Центральный репозиторий
●
knife cookbook site download
●
Другие репы – librarian-chef
●
^ Рубисты – это такой bundler
●
Ничего этого в Salt нет!
●
Кроме центральной репы
●
26. Темная сторона Salt
Проект очень молодой, в
документации есть не все
●
^ Глава про юнит-тестирование
состоит только из заголовка
●
Есть дружелюбный форум
●
С большим трафиком
●
27. Серебряной пули нет!
Chef – большие проекты,
выделенная роль “инженера по
кукбукам”, юнит-тестирование
кукбуков
●
Salt – небольшие проекты,
скорость, простота, ad-hoc
выполнение
●