- Краткая вводная про Docker (namespaces, cgroups и как Docker все это использует)
- Как заходить в Docker из вашего софта?
- Примеры: pam_docker и php_fpm_docker
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
— Как сделать сеть между Docker контейнерами и дать доступ к ней во вне без спецрешений;
— Какие есть решения в Docker для сетевого взаимодействия;
— сравнение weave, docker netwirking, macvlan.
Лучшие практики 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?
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Артем Первухин "Язык программирования GO"
В докладе будет рассказано, чем сможет заинтересовать Python-разработчика язык программирования Go. Будут описаны базовые идиомы языка Go и даны ответы на следующие вопросы: Насколько применим к Go "Zen of Python"? Какая у этого языка область применения? В чём можно выиграть, использовав Go вместо Python?
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
- Краткая вводная про Docker (namespaces, cgroups и как Docker все это использует)
- Как заходить в Docker из вашего софта?
- Примеры: pam_docker и php_fpm_docker
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
— Как сделать сеть между Docker контейнерами и дать доступ к ней во вне без спецрешений;
— Какие есть решения в Docker для сетевого взаимодействия;
— сравнение weave, docker netwirking, macvlan.
Лучшие практики 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?
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Артем Первухин "Язык программирования GO"
В докладе будет рассказано, чем сможет заинтересовать Python-разработчика язык программирования Go. Будут описаны базовые идиомы языка Go и даны ответы на следующие вопросы: Насколько применим к Go "Zen of Python"? Какая у этого языка область применения? В чём можно выиграть, использовав Go вместо Python?
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Распространено мнение, что навык пакетирования своих наработок необходим только гуру в Open Source. Стас развенчал этот миф и показал несколько практических задач, решаемых при помощи пакетирования кода.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Возможности современных дебаггеров на примере дебаггер Google Chrome.
Точки останова, трассировка, события.
Video: https://www.youtube.com/watch?v=8eIKtIypLJc
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
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-системами.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
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.
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Спросите любого программиста и он честно вам ответит, что 90% процентов его времени уходит на поиск ошибок. Подпишусь под этим и я, сменивший за долгие годы множество языков и фреймворков. Действительно, "человеку свойственно ошибаться". Так что же делать, если из человека это свойство не выбить? Как сократить это бездарно потраченное время?
Тот же программист вам и ответ: "отлаживать, конечно". Это искуство сродни магии, доступно всем и покоряется немногим. Но к счастью, помимо проверенной временем практики "вставь сюда print" к услугам питонистов целый зоопарк инструментов.
В этом докладе я постараюсь обобщить самые частые практики отладки, описать их плюсы/минусы и как они соотносятся с Python. Кроме этого, мы совершим обзорный экскурс по экосистеме и посмотрим, чем можно помочь себе в этой нелегкой борьбе. Для особенных эстетов мы рассмотрим техники получения информации из уже запущенного кода. Buckle up!
======
Ссылки
======
Python Debugger Uncovered
https://www.youtube.com/watch?v=2sEPipctTxw
How I built a power debugger out of the standard library and
things I found on the internet
https://www.youtube.com/watch?v=g8kF9tuYZ6s
Architecture of Open Source Applications: GDB
http://www.aosabook.org/en/gdb.html
Advanced Python Debugging Techniques Using GDB
https://www.youtube.com/watch?v=rB9rPdMRxIA
pdb – Interactive Debugger
https://pymotw.com/2/pdb/
bdb — Debugger framework
https://docs.python.org/2/library/bdb.html
Распространено мнение, что навык пакетирования своих наработок необходим только гуру в Open Source. Стас развенчал этот миф и показал несколько практических задач, решаемых при помощи пакетирования кода.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
Возможности современных дебаггеров на примере дебаггер Google Chrome.
Точки останова, трассировка, события.
Video: https://www.youtube.com/watch?v=8eIKtIypLJc
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
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-системами.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
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.
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Спросите любого программиста и он честно вам ответит, что 90% процентов его времени уходит на поиск ошибок. Подпишусь под этим и я, сменивший за долгие годы множество языков и фреймворков. Действительно, "человеку свойственно ошибаться". Так что же делать, если из человека это свойство не выбить? Как сократить это бездарно потраченное время?
Тот же программист вам и ответ: "отлаживать, конечно". Это искуство сродни магии, доступно всем и покоряется немногим. Но к счастью, помимо проверенной временем практики "вставь сюда print" к услугам питонистов целый зоопарк инструментов.
В этом докладе я постараюсь обобщить самые частые практики отладки, описать их плюсы/минусы и как они соотносятся с Python. Кроме этого, мы совершим обзорный экскурс по экосистеме и посмотрим, чем можно помочь себе в этой нелегкой борьбе. Для особенных эстетов мы рассмотрим техники получения информации из уже запущенного кода. Buckle up!
======
Ссылки
======
Python Debugger Uncovered
https://www.youtube.com/watch?v=2sEPipctTxw
How I built a power debugger out of the standard library and
things I found on the internet
https://www.youtube.com/watch?v=g8kF9tuYZ6s
Architecture of Open Source Applications: GDB
http://www.aosabook.org/en/gdb.html
Advanced Python Debugging Techniques Using GDB
https://www.youtube.com/watch?v=rB9rPdMRxIA
pdb – Interactive Debugger
https://pymotw.com/2/pdb/
bdb — Debugger framework
https://docs.python.org/2/library/bdb.html
How to run linux on atmel/microchip sama5d3 platform: selecting toolchain, building rootfs and boot components. Using NAND for data storage with hardware Error Correction Coding (MPECC module).
Разработка декстопных приложений для linux (Владимир Яковлев)IT-Доминанта
Владимир Яковлев - Python Developer / Odesk / Россия, Санкт-Петербург
- выбор фреймворка: TkInter/PySide/PyQt/PyGI; - что делать если не хватает одного потока; - взаимодействие с системой и другими приложениями; - сборка и публикация пакетов.
http://www.it-sobytie.ru/events/2040
Опенсорс-инструменты на страже безопасности бэкенда — Петр ВолковYandex
Антивирусная система Яндекса ежедневно обнаруживает тысячи взломанных сайтов. Периодически среди них встречаются крупные и известные интернет-ресурсы.
Администраторы сайтов часто оказываются не готовы к тому, что злоумышленник может пробраться через внешний периметр и исполнить произвольный код на стороне сервера. В результате перед ними встаёт нелегкая задача: обнаружить последствия и предотвратить дальнейшие проблемы.
Доклад посвящён практикам и инструментам, которые могут существенно повысить эффективность противодействия вредоносной активности, и профилактике её возникновения.
Автор - Дмитрий Бородаенко (Debian Project, ex-SaM Solutions Dept6 head). Краткий вводный курс по пакетированию программного обеспечения средствами Debian/Ubuntu. Прочитан в апреле 2012 года для сотрудников отдела Linux & Embedded SaM Solutions. Публикуется по договоренности с лектором.
Видео: http://bit.ly/13Tw24s
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
Perl для не программистов. Николай Мишин. Moscow.pm 4 июля 2013Moscow.pm
- Как создать презентацию не вылезая из любимого текстового редактора (notepad++, padre, vim).
- Как perl помогает автоматизировать работу без написания кода.
- Пара скриптов, которые облегчают работу на разных платформах.
- Те же скрипты на perl6.
- Автоматизация и тестирование Firefox.
В докладе рассматривается текущее состояние механизмов поиска и установки необходимых библиотек и утилит. Мы пробежим по общему определению менеджера пакетов и рассмотрим несколько распространенных примеров. Взглянем на типичные сценарии использования и на то, какие возможности были использованы в качестве критериев сравнения, а также составим представление о существующих решениях в мире С++ их конструктивных особенностях и примерах решаемых задач.
Готовим начинку для облака (cloudinit/cloudbase иное...)Andrey Fesenko
Облаков нынче много, от больших, до просто запускалок на лаптопе, а вы в курсе как сделать что бы образ был не банальным, а с плюшками и бантиками? Не Опенстеком единым как говорится…
Доклад о том какие нововведения появятся в релизе FreeBSD 11
Первая версия доклада была подготовлена для IT Global Meetup #8, данная версия расширена для SpbLUG
poudriere или как я перестал волноваться и полюбил pkg
1. poudriere или как я перестал волноваться и
полюбил pkg
Андрей Фесенко
f0andrey@gmail.com
SPbLUG
Санкт-Петербург
July 29, 2015
2. Вводная ports pkg poudriere Заключение
Как всё начиналось
1993: pkg_install/ 1994: ports (jhk@ Jordan K. Hubbard)
1995: около 200 портов
1999: около 2000 портов
2013-2014: порядка 20 тысяч
Сейчас: 25085 (даже, после довольно массовых чисток)
poudriere или как я перестал волноваться и полюбил pkg
3. Вводная ports pkg poudriere Заключение
Чем собирать
пакеты, собираются из портов
2003: portbuild - набор скриптов, пока не начал составлять
доклад и не знал
2005: Tinderbox - серьёзный инструмент, куча
зависимостей (NFS, BD, Perl, PHP, www)
2001/2011: portupgrade/portmaster - скорее для личного
пользования, на десктопе
2012: poudriere - нынешний мейнстрим
poudriere или как я перестал волноваться и полюбил pkg
4. Вводная ports pkg poudriere Заключение
Хронология и утилиты
1994: первые коммиты, как портов так и пакетов
2001: portupgrade (pkgtools) - более ориентирован на
пакеты, в том числе расширяет возможности (требует ruby
для работы)
2011: portmaster - скрипт отслеживания зависимостей и
управления портами/пакетами
(настройка/установка/удаление), последнее время почти
не поддерживается, хотя поддержка основного
функционала сохраняется и актуализируется (очень
разросся, простой sh)
2012: portsnap - утилита, для скачивания и обновления
портов, из сжатых образов/снапшотов
poudriere или как я перестал волноваться и полюбил pkg
5. Вводная ports pkg poudriere Заключение
Развитие ports
2013: OPTIONSng
простое вкл/выкл
единичный или множественный выбор
опции могут задаваться как для единичного порта, так и
глобально
USES - для пользователей незаметно, но весьма важный
функционал для портмантейнеров
poudriere или как я перестал волноваться и полюбил pkg
6. Вводная ports pkg poudriere Заключение
Развитие ports
StageDir - порты теперь не устанавливаются в корневую
систему, а устанавливаются в “DESTDIR”, позволяет
собирать пакеты без root привилегий и улучшает
отслеживание файлов. При внедрении многие порты были
исключены из дерева.
внедрение CPE (Common Platform Enumeration), для
систематизации и облегчения отслеживания обновлений
безопасности.
poudriere или как я перестал волноваться и полюбил pkg
7. Вводная ports pkg poudriere Заключение
Этапы внедрения pkg
Всякие цитаты
“src/usr.sbin/pkgne ladd/perform.c
/*
* This is seriously ugly code following. Written very
* fast![And subsequently made even worse.. Sigh!
* This code was just born to be hacked, I guess.. :) ]
*/
–
jhk@
Jordan K. Hubbard
18 July 1993“
“Здесь. Должна быть цитата, о том что, то ли пакеты, то ли
порты, ужасны и их надо срочно править“
poudriere или как я перестал волноваться и полюбил pkg
8. Вводная ports pkg poudriere Заключение
Этапы внедрения pkg
Sept. 2010: Первый коммит
January 2012: 1.0 beta1 pkg добавлено в дерево портов
ports-mgmt/pkg
August 2012: 1.0
October 2012: по умолчанию в CURRENT
June 2013: 1.1
January 2014: 10.0 на основе pkg
July 2014: 1.3
September 2014: pkg_install EOL
December 2014: 1.4
April 2015: 1.5
pkg в отличии от pkg_install не поставляется в составе
системы, там находится только заглушка, для
саморазвёртывания
poudriere или как я перестал волноваться и полюбил pkg
9. Вводная ports pkg poudriere Заключение
Этапы внедрения pkg
Не только FreeBSD
PC-BSD начиная с 2014, PBI стал всего лишь фронтендом
к pkg
DragonflyBSD
начиная с 2012 внедрение DPorts (форк pkg)
в конце 2013 полный переход на DPorts, отказ от pkgsrc
2014 - начальная поддержка в OS X и Linux
2015 - начальная поддержка в NetBSD/EdgeBSD
poudriere или как я перестал волноваться и полюбил pkg
10. Вводная ports pkg poudriere Заключение
Что имеем
FreeBSD.org pkg mirror использует DNS SRV,
распределённый кластер US/UK/RU (для 8.4 EoL август,
оставлена возможность обновления ftp)
бранчи - например для 10-ки
latest
quarterly
release
release_0
release_1
pkg -o DEBUG_LEVEL=2 (4) если что то пошло не так
pkg upgrade ‘pkg query -e ’%n = perl5.20’ %ro | cut -d “/” -f
2-‘
portmaster –list-origins > /home/user/my-port-list
nginx имеет более 80 опций,
77,371,252,455,336,267,181,195,264 комбинаций
/usr/local/etc/pkg/repos/ - для включения выключения
каждого репо свой .conf
poudriere или как я перестал волноваться и полюбил pkg
11. Вводная ports pkg poudriere Заключение
Зачем?
BSD License
Сборка пакетов (.txz) для всех версий начиная с 8.3
Тестирование
Кроссборка
Построение репозитория, локального, с изменёнными
опциями, собственными патчами
Очень прост в настройке и использовании
poudriere или как я перестал волноваться и полюбил pkg
12. Вводная ports pkg poudriere Заключение
Как
Каждый пакет собирается в “чистом окружении” (jail copy)
Дерево портов, возможны варианты
Set - “окружения” возможны различные конфигурации (-z)
DUD - обработка, запрещённых/сломанных портов
опциональный AJAX веб интерфейс
poudriere или как я перестал волноваться и полюбил pkg
13. Вводная ports pkg poudriere Заключение
Как
Требования
FreeBSD>= 8.3
Желательно ZFS pool >= v15 (возможна работа и на UFS)
и не менее 8Gb места на диске
Версия системы на которой производится сборка, должна
быть больше или равна, той пакеты которой собираетесь
собирать
общее правило чем больше тем лучше/быстрее
CPU,
RAM (1-2Гб, если собирать в памяти),
Disk 1.5Гб на каждый jail,
4Гб дерево портов, плюс место под исходные коды и
готовые пакеты (МНОГО)
Сеть, для загрузки исходных кодов и обновления
веб-сервер, если нужен удалённый доступ к репозиторию и
хочется смотреть красивые логи/статусы
poudriere или как я перестал волноваться и полюбил pkg
14. Вводная ports pkg poudriere Заключение
Как
POUDRIERE(8) - наш лучший друг (и немного
/usr/local/etc/poudriere.conf.sample)
настройки для окружений хранятся в
/usr/local/etc/poudriere.d/
<jailname>-<setname(tree)>-make.conf(src.conf,options/)
для конкретного setname(tree)
<setname(tree)>-make.conf(src.conf,options/) для всех
одноимённых setname(tree)
make.conf(src.conf,options/) - общие
по такой же схеме возможно задание poudriere.conf,
blacklist
Если собрались собирать пакеты, такие же как уже
установленные порты, просто скопируйте /var/db/ports/ в
/usr/local/etc/poudriere.d/*-options/ формат одинаковый
poudriere или как я перестал волноваться и полюбил pkg
15. Вводная ports pkg poudriere Заключение
Как
Заглянем под копот
Заготовленный ранее, образцовый jail, монтируется ro (так
что не изменяется)
Для каждого билдера создаётся отдельный джейл (по
умолчанию =nCPU) (zfs clone/cp)
перед сборкой каждого пакета, билдер откатывается до
образцового состояния (чистится)
kill -9, после сборки
Сетевой доступ, только на этапе скачивания пакета (если
он не закеширован)
Зависимости устанавливаются из пакетов, собранных
ранее (начинается с pkg)
После завершения возможна, отладка в интерактивном
режиме, так же сохранение отладки
poudriere или как я перестал волноваться и полюбил pkg
16. Вводная ports pkg poudriere Заключение
Как
Установка возможна из пакетов, портов, github (самое
свежее и интересное)
poudriere ports -c
poudriere jail -c -j 10amd64 -v 10.1-RELEASE -a amd64
poudriere ports -u
poudriere bulk -j 10amd64 -f origins.list % сборка нескольких
портов (категория/имя по одному на строку)
poudriere bulk -j 10amd64 -o ports-mgmt/pkg
poudriere options -j 10amd64 -c ports-mgmt/portmaster
Это конечно самый простейший вариант, настроить, как
при создании, так и при запуске, можно довольно много
poudriere bulk -v -j 110amd64 -z x220 -f x220-port-list
возможен запуск в режиме демона
poudriere или как я перестал волноваться и полюбил pkg
17. Вводная ports pkg poudriere Заключение
Как
Кроссборка
Довольно легко и непринуждённо
Устанавливаем emulators/qemu-user-static (или просто
отмечаем опцию/отключена)
kldload imgact_binmisc
Страшное колдунство, что бы “появился” процессор нужной
архитектуры
“binmiscctl add armv6 –interpreter
"/usr/local/bin/qemu-arm"–magic
"x7fx45x4cx46x01x01x01x00x00x00x00x00x00x00x00x00x02
x00x28x00"–mask "xffxffxffxffxffxffxffx00xffxffxffxff
xffxffxffxffxfexffxffxff"–size 20 –set-enabled“
poudriere или как я перестал волноваться и полюбил pkg
18. Вводная ports pkg poudriere Заключение
Как
Не Шмагла
не реализована чистка логов, если собирать что то часто,
то всё же копятся (rm -Rf)
по утверждению одного из разработчиков, не очень
хороший код для работы в jail
иногда какие либо стопорения, лечимые перезапуском
не очень доходчивое разрешение зависимостей, так как
порты в этом месте пока оставляют желать лучшего,
приходится поломать голову
не может “населить” репозиторий пакетами с опциями по
умолчанию, для уменьшения бесполезной работы
Если используете не актуальные версии, аккуратнее с
именами jail
poudriere или как я перестал волноваться и полюбил pkg
19. Вводная ports pkg poudriere Заключение
Подборка ссылок
При подготовке слайдов, вероятно, использовались материалы
доступные по следующим ссылкам.
Handbook Chapter 5. Installing Applications: Packages and
Ports
Handbook 5.6. Building Packages with Poudriere
FreeBSD: 5 years of pkg A end less journey
Third-party software management under BSD (EuroBSDCon
2006)
Video ports tree 20th anniversary
The Ports Management Team (блог не обновляется)
FreeBSD Ports and Packages – Getting Back Being the Best
(2011)
Embedded FreeBSD Development and Package Building via
QEMU
PKG note bapt (2011)
poudriere или как я перестал волноваться и полюбил pkg
20. Вводная ports pkg poudriere Заключение
Подборка ссылок
При подготовке слайдов, вероятно, использовались материалы
доступные по следующим ссылкам.
Tinderbox and Poudriere - Automatic Ports Testing and
Package Building on FreeBSD
Poudriere: The future of Package Building (2013)
How to build and use QEMU User Mode on FreeBSD
FreshPorts (очень удобный “вебинтерфейс” к портам)
poudriere или как я перестал волноваться и полюбил pkg
21. Вводная ports pkg poudriere Заключение
Вопросы?
Спасибо за внимание!
Вопросы? :-)
poudriere или как я перестал волноваться и полюбил pkg