— Как сделать сеть между Docker контейнерами и дать доступ к ней во вне без спецрешений;
— Какие есть решения в Docker для сетевого взаимодействия;
— сравнение weave, docker netwirking, macvlan.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Лучшие практики 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?
— Краткий экскурс в предыдущие доклады;
- Описание нашей системы сбора статистики с контейнеров и рассказ почему мы решили отказаться от cadvisord;
- Автоматическая система сборки контейнеров и интеграция с teamcity;
— Наброс о системе генерации и хранения конфигураций.
- Краткая вводная про Docker (namespaces, cgroups и как Docker все это использует)
- Как заходить в Docker из вашего софта?
- Примеры: pam_docker и php_fpm_docker
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.
Процесс разработки и тестирования с Docker + gitlab ciАлександр Сигачев
Доклад - https://www.youtube.com/watch?v=lJsqRwULRVA
Какие проблемы решаем?
быстрый вход нового разработчика в проект
стандартизация настроек разработчиков
переключение между проектами - разные версии ПО и библиотек (mysql 5.6/5.7, node 0.12/7.2)
приучаем разработчиков к сетевому взаимодействию компонентов
Microservice - масштабирование/разделения разработки
Делим ресурсы staging среды между проектами
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
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-системами.
Михаил Боднарчук "Docker для PHP разработчиков" Fwdays
Это не рассказ о том, как из разработчика стать крутым DevOpsом. Это доклад о том, как можно сделать процесс разработки и развертки приложения комфортнее и эффективнее вместе с прогрессивной технологией контейнеризации - Docker.
В этом докладе я затрону следующие темы:
Docker - это то модное слово, которое все должны знать
Дирижирование оркестром вместе с Docker Compose
Создание и настройка рабочего окружения в Docker
Построение сервисно-ориентированых приложений
Безболезненное развертывание приложений с Shipyard
То, чего не хватало для Continuous Integration - запуск параллельных билдов
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.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Депрокрастинируем Docker: контейнеры здесь и сейчасRuslan Sharipov
Депрокрастинируем Docker: контейнеры здесь и сейчас (мастер-класс). Руслан Шарипов (7bits), Денис Нелюбин (Avelix).
При подходе к любому важному делу или к изучению интересной технологии очень важно сделать первый шаг. Этот шаг может быть совсем шажочком, небольшим движением вперёд, но, часто бывает, что именно такие шаги позволяют добиваться завершения дел до конца.
В последнее время часто наши коллеги и знакомые грозятся погуглить, изучить, разобраться, исследовать, ознакомиться, попробовать, начать использовать Docker, и постоянно откладывают это дело в долгий ящик. Кто-то боится новизны технологии, кто-то хочет задать тонну вопросов, а кто-то просто не понимает, нужна ли технология для него.
В рамках этого мастер класса мы сделаем первый шаг к тому, чтобы попробовать на практике то, что есть сейчас Docker. Мы рассмотрим, что у него под капотом: какие технологии стоят за популярным названием, как работает Docker изнутри, обсудим и научимся использовать на практике контейнеры, registry и инструменты, упрощающие процесс доставки и запуска контейнеров на серверах, обсудим и найдём решения для возникающих проблем, напишем тесты и научимся тестировать инфраструктуру в контейнерах.
Presented: 6th June, 2015
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Эволюция php code coverage в Badoo. Доклад Ильи Агеева на LoveQA РИТ.Badoo Development
Рассказали о том как у нас эволюционировала сборка code-coverage для php-кода за 4 года, каких успехов мы достигли на этом поприще и как боролись со скоростью сборки с учетом постоянно растущего количества тестов. Доклад будет полезен как тем, кто только начитает покрывать свой код тестами, так и тем, кто давно этим занимается и сталкивается с проблемами производительности при сборке покрытия.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
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.
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
— Реальная история из жизни о том, как мы внедряли Docker;
— Хочешь чтобы все коллеги узнавали тебя? Займись внедрением Docker в своей компании!;
— Собрать все шишки? Легко… или «Даунтайм, как неотъемлемая часть внедрения»;
— Будь сильным и смелым, если уверен в перспективах и необходимости своего внедрения;
— «Делать новое не ломая старого» – основная цель любого внедрения;
— Чекпоинт, как инструмент промежуточной оценки результатов;
— Как растут наши аппетиты или о новых инфраструктурных идеях;
— Мы сделали это, значит это вполне осуществимо;
— Самое сложное позади или какие приятные результаты вас ожидают, если все пошло правильно.
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
This talk discusses Linux profiling using perf_events (also called "perf") based on Netflix's use of it. It covers how to use perf to get CPU profiling working and overcome common issues. The speaker will give a tour of perf_events features and show how Netflix uses it to analyze performance across their massive Amazon EC2 Linux cloud. They rely on tools like perf for customer satisfaction, cost optimization, and developing open source tools like NetflixOSS. Key aspects covered include why profiling is needed, a crash course on perf, CPU profiling workflows, and common "gotchas" to address like missing stacks, symbols, or profiling certain languages and events.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
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-системами.
Михаил Боднарчук "Docker для PHP разработчиков" Fwdays
Это не рассказ о том, как из разработчика стать крутым DevOpsом. Это доклад о том, как можно сделать процесс разработки и развертки приложения комфортнее и эффективнее вместе с прогрессивной технологией контейнеризации - Docker.
В этом докладе я затрону следующие темы:
Docker - это то модное слово, которое все должны знать
Дирижирование оркестром вместе с Docker Compose
Создание и настройка рабочего окружения в Docker
Построение сервисно-ориентированых приложений
Безболезненное развертывание приложений с Shipyard
То, чего не хватало для Continuous Integration - запуск параллельных билдов
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.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Депрокрастинируем Docker: контейнеры здесь и сейчасRuslan Sharipov
Депрокрастинируем Docker: контейнеры здесь и сейчас (мастер-класс). Руслан Шарипов (7bits), Денис Нелюбин (Avelix).
При подходе к любому важному делу или к изучению интересной технологии очень важно сделать первый шаг. Этот шаг может быть совсем шажочком, небольшим движением вперёд, но, часто бывает, что именно такие шаги позволяют добиваться завершения дел до конца.
В последнее время часто наши коллеги и знакомые грозятся погуглить, изучить, разобраться, исследовать, ознакомиться, попробовать, начать использовать Docker, и постоянно откладывают это дело в долгий ящик. Кто-то боится новизны технологии, кто-то хочет задать тонну вопросов, а кто-то просто не понимает, нужна ли технология для него.
В рамках этого мастер класса мы сделаем первый шаг к тому, чтобы попробовать на практике то, что есть сейчас Docker. Мы рассмотрим, что у него под капотом: какие технологии стоят за популярным названием, как работает Docker изнутри, обсудим и научимся использовать на практике контейнеры, registry и инструменты, упрощающие процесс доставки и запуска контейнеров на серверах, обсудим и найдём решения для возникающих проблем, напишем тесты и научимся тестировать инфраструктуру в контейнерах.
Presented: 6th June, 2015
Алексей Фомкин, Практическое применение Web WorkersAleksey Fomkin
WebWorkers имеют глобальное покрытие в 92% по данным http://caniuse.com. Тем не менее, не всякое современное веб-приложение использует их.
В своем докладе я постараюсь передать двухлетний опыт использования WebWorkers в нашей команде для написания веб-приложений с функциональностью, которая требует выполнения тяжелых вычислений, таких как преобразование бинарых файлов из одного формата в другой и шифрование.
Расскажу про эксперименты по переносу в воркер расчета diff'ов в React-подобной системе рендеринга и покажу наивную реализацию модели акторов на основе воркеров.
Также постараюсь подготовить слушателей к новым проблемам, которые могут возникнуть при использовании веб-воркеров.
Эволюция php code coverage в Badoo. Доклад Ильи Агеева на LoveQA РИТ.Badoo Development
Рассказали о том как у нас эволюционировала сборка code-coverage для php-кода за 4 года, каких успехов мы достигли на этом поприще и как боролись со скоростью сборки с учетом постоянно растущего количества тестов. Доклад будет полезен как тем, кто только начитает покрывать свой код тестами, так и тем, кто давно этим занимается и сталкивается с проблемами производительности при сборке покрытия.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
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.
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
— Реальная история из жизни о том, как мы внедряли Docker;
— Хочешь чтобы все коллеги узнавали тебя? Займись внедрением Docker в своей компании!;
— Собрать все шишки? Легко… или «Даунтайм, как неотъемлемая часть внедрения»;
— Будь сильным и смелым, если уверен в перспективах и необходимости своего внедрения;
— «Делать новое не ломая старого» – основная цель любого внедрения;
— Чекпоинт, как инструмент промежуточной оценки результатов;
— Как растут наши аппетиты или о новых инфраструктурных идеях;
— Мы сделали это, значит это вполне осуществимо;
— Самое сложное позади или какие приятные результаты вас ожидают, если все пошло правильно.
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
This talk discusses Linux profiling using perf_events (also called "perf") based on Netflix's use of it. It covers how to use perf to get CPU profiling working and overcome common issues. The speaker will give a tour of perf_events features and show how Netflix uses it to analyze performance across their massive Amazon EC2 Linux cloud. They rely on tools like perf for customer satisfaction, cost optimization, and developing open source tools like NetflixOSS. Key aspects covered include why profiling is needed, a crash course on perf, CPU profiling workflows, and common "gotchas" to address like missing stacks, symbols, or profiling certain languages and events.
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract:
A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding uses for security auditing and enforcement, enhancing networking (including eXpress Data Path), and performance observability and troubleshooting. Many new open source tools that have been written in the past 12 months for performance analysis that use BPF. Tracing superpowers have finally arrived for Linux!
For its use with tracing, BPF provides the programmable capabilities to the existing tracing frameworks: kprobes, uprobes, and tracepoints. In particular, BPF allows timestamps to be recorded and compared from custom events, allowing latency to be studied in many new places: kernel and application internals. It also allows data to be efficiently summarized in-kernel, including as histograms. This has allowed dozens of new observability tools to be developed so far, including measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more.
This talk will summarize BPF capabilities and use cases so far, and then focus on its use to enhance Linux tracing, especially with the open source bcc collection. bcc includes BPF versions of old classics, and many new tools, including execsnoop, opensnoop, funcccount, ext4slower, and more (many of which I developed). Perhaps you'd like to develop new tools, or use the existing tools to find performance wins large and small, especially when instrumenting areas that previously had zero visibility. I'll also summarize how we intend to use these new capabilities to enhance systems analysis at Netflix.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
Linux Performance Analysis: New Tools and Old SecretsBrendan Gregg
Talk for USENIX/LISA2014 by Brendan Gregg, Netflix. At Netflix performance is crucial, and we use many high to low level tools to analyze our stack in different ways. In this talk, I will introduce new system observability tools we are using at Netflix, which I've ported from my DTraceToolkit, and are intended for our Linux 3.2 cloud instances. These show that Linux can do more than you may think, by using creative hacks and workarounds with existing kernel features (ftrace, perf_events). While these are solving issues on current versions of Linux, I'll also briefly summarize the future in this space: eBPF, ktap, SystemTap, sysdig, etc.
Talk for PerconaLive 2016 by Brendan Gregg. Video: https://www.youtube.com/watch?v=CbmEDXq7es0 . "Systems performance provides a different perspective for analysis and tuning, and can help you find performance wins for your databases, applications, and the kernel. However, most of us are not performance or kernel engineers, and have limited time to study this topic. This talk summarizes six important areas of Linux systems performance in 50 minutes: observability tools, methodologies, benchmarking, profiling, tracing, and tuning. Included are recipes for Linux performance analysis and tuning (using vmstat, mpstat, iostat, etc), overviews of complex areas including profiling (perf_events), static tracing (tracepoints), and dynamic tracing (kprobes, uprobes), and much advice about what is and isn't important to learn. This talk is aimed at everyone: DBAs, developers, operations, etc, and in any environment running Linux, bare-metal or the cloud."
Video: https://www.youtube.com/watch?v=FJW8nGV4jxY and https://www.youtube.com/watch?v=zrr2nUln9Kk . Tutorial slides for O'Reilly Velocity SC 2015, by Brendan Gregg.
There are many performance tools nowadays for Linux, but how do they all fit together, and when do we use them? This tutorial explains methodologies for using these tools, and provides a tour of four tool types: observability, benchmarking, tuning, and static tuning. Many tools will be discussed, including top, iostat, tcpdump, sar, perf_events, ftrace, SystemTap, sysdig, and others, as well observability frameworks in the Linux kernel: PMCs, tracepoints, kprobes, and uprobes.
This tutorial is updated and extended on an earlier talk that summarizes the Linux performance tool landscape. The value of this tutorial is not just learning that these tools exist and what they do, but hearing when and how they are used by a performance engineer to solve real world problems — important context that is typically not included in the standard documentation.
Broken benchmarks, misleading metrics, and terrible tools. This talk will help you navigate the treacherous waters of Linux performance tools, touring common problems with system tools, metrics, statistics, visualizations, measurement overhead, and benchmarks. You might discover that tools you have been using for years, are in fact, misleading, dangerous, or broken.
The speaker, Brendan Gregg, has given many talks on tools that work, including giving the Linux PerformanceTools talk originally at SCALE. This is an anti-version of that talk, to focus on broken tools and metrics instead of the working ones. Metrics can be misleading, and counters can be counter-intuitive! This talk will include advice for verifying new performance tools, understanding how they work, and using them successfully.
[Defcon Russia #29] Михаил Клементьев - Обнаружение руткитов в GNU/LinuxDefconRussia
Руткиты в мире основанных на ядре Linux операционных систем уже не являются редкостью. Рассказ будет о том, как попытки в современных реалиях определить то, скомпрометирована ли система, привели к неожиданному результату.
Опенсорс-инструменты на страже безопасности бэкенда — Петр ВолковYandex
Антивирусная система Яндекса ежедневно обнаруживает тысячи взломанных сайтов. Периодически среди них встречаются крупные и известные интернет-ресурсы.
Администраторы сайтов часто оказываются не готовы к тому, что злоумышленник может пробраться через внешний периметр и исполнить произвольный код на стороне сервера. В результате перед ними встаёт нелегкая задача: обнаружить последствия и предотвратить дальнейшие проблемы.
Доклад посвящён практикам и инструментам, которые могут существенно повысить эффективность противодействия вредоносной активности, и профилактике её возникновения.
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
This is a war-story about deploying and managing Jenkins instances in the cloud in our company. For this purpose, we use Mesos and Docker plugins. In the talk I focus on our requirements to Jenkins in the Cloud, prerequisites and the preparation process. The presentation also covers the current state of the deployment and the lessons learnt.
We are hiring! Msk and Spb: https://goo.gl/HjfOz5
Пора ли отправлять С на свалку истории? Пишем демонов на PHP с использованием...Vadim Kruchkov
Вадим Крючков [Long], руководитель группы разработки, компания Agunga
Считается (в общем случае — вполне справедливо), что писать демонов на PHP — моветон. Использовать для прототипирования интерфейсов взаимодействия — можно, а вот в продакшене ни-ни. Именно с таким представлением мы начинали разработку новой версии игры — проработаем интерфейсы взаимодействия с демоном, который к запуску будет переписан на высокопроизводительном С. Однако, первые тесты демона, написанного на PHP с использованием libevent, заставили нас серьезно задуматься — а нужен ли нам переход на С? Какую производительность нам удалось достичь? Течет ли память? Обо всем этом будет рассказано в докладе. А так же - особенности использования и недокументированные возможности расширения, облегчающие рутинные операции
This document discusses the history and current approach to parallel iOS automation testing at Badoo. It describes moving from a single simulator approach that took 15 hours to run 500 tests to using multiple desktops in parallel, reducing the runtime to 2 hours with 10 simulators. It then discusses further optimizing to run multiple simulators on one desktop using Facebook's WebDriverAgent, reducing runtime to 90 minutes with 16 simulators. The approach combines Calabash and WebDriverAgent, termed "Facebash", allowing parallel testing while retaining Calabash backdoors and cross-app functionality.
Документация на тему архитектуры языка PHP скудна и разрозненна, несмотря на то что тема интересна многим. В моем докладе я постараюсь заполнить этот пробел и рассказать о модулях PHP: как они работают, зачем и как их пишут. В процессе мы рассмотрим опыт Badoo в этой сфере на примерах двух модулей. И еще напишем очень небольшой собственный модуль.
— Что такое модули PHP, как они работают
— Как начать писать свой модуль PHP
— Скелет модуля — Функции, классы, методы
— Разбор параметров функции
— Сборка модуля
— Подгрузка модуля
— Простой пример модуля из Badoo
— Сложный пример модуля из Badoo
Тема: Как перестать беспокоиться и начать запускать фичи
Запуск новых фич для любого продукта – довольно опасная штука, ведь столько всего может пойти не так: может вылезти огромное число разных багов (от device specific до багов в самой фиче), могут не выдержать сервера и в конце концов пользователям может просто не понравиться фича.
Я расскажу о том, как мы запускаем новые фичи, какие проблемы, связанные с запусками, у нас возникали и как это всё работает в Android-клиенте.
Тезисы:
– feature toggles: что это, зачем это и как мы сделали своё;
– как мы мониторим и оцениваем запуски;
– как feature toggles дружат с ручным тестированием и как учитываются в автотестах.
Тема: Измерение энергопотребления мобильных и внедрение в Continuous Integration
Во время выступления я буду говорить про:
– проектирование устройства измерения энергопотребления;
– применение устройства анализа энергопотребления смартфона;
– автоматизацию процесса тестирования энергопотребления;
– поиск энергозатратных функций браузера;
– оптимизацию и контроль потребления энергии в браузере.
Тема: Компонентные тесты: как сделать жизнь вашего QA немного проще?
В докладе речь пойдёт о компонентных тестах, в том числе я поделюсь лучшими практиками, которые выработала наша команда, и расскажу, как они помогают нам делать более качественный продукт.
В частности поговорим о том:
– что такое компонентный тест? В чем отличия между юнит-, компонентным и функциональным тестом?
– для чего хороши компонентные тесты и какие проблемы они помогают нам решать?
– как минимизировать стоимость поддержки компонентных тестов без экономии на их надежности.
Я расскажу о нестандартных особенностях языка для реальных проектов. Речь пойдет о том, зачем усложнять себе жизнь и какие преимущества это может дать.
- Protocol-Oriented Programming и его дилеммы
- Когда и зачем использовать обобщения и вложенные типы
- Настоящее и будущее Swift
Cocoaheads Meetup / Kateryna Trofimenko / Feature developmentBadoo Development
Я расскажу о том, что такое feature flags, как они нам в Badoo помогают разрабатывать большие фичи итерационно, силами нескольких разработчиков, и не переживать из-за кода, уходящего в релизы.
И вы узнаете о том, как система таргетированной раскладки фич переросла в систему a/b-тестирования и как все это выглядит со стороны iOS-клиента
Hadoop framework is a popular solution to such tasks as distributed data storage and running. Map/Reduce tasks on cluster. High scalability, mature ecosystem and large community make Hadoop one the most popular framework in distributed data processing. But the more responsibility you put on it, the more important it becomes to provide its fault-taulerance and high availability. This presentation will be useful to those, who have already been using Hadoop. For the rest it will be interesting to learn some architectural solutions applied in Hadoop.
In my presentation I will cover aspects of high availability implementation for Hadoop.
Besides, I will talk on:
– “The zoo” we have to deal with;
– Why we should provide high availability: points of system failure and its consequences;
– Tools and solutions to such problems;
– Our practical experience of implementation: preparation, deploy, testing.
Вероятно, многие пробовали использовать решение Zabbix для мониторинга баз данных. Из моего доклада вы узнаете о нашем опыте его применения, и к чему мы в итоге пришли.
1. Штатный Zabbix-мониторинг баз данных: особенности реализации/настройки в промышленных масштабах
2. Преимущества/недостатки решения мониторинга баз данных от Zabbix SIA
3. Преимущества/недостатки существующих расширений Zabbix для мониторинга баз данных
4. Подробнее о расширении DBforBix v2.3 beta: конфигурирование, возможности
5. Доработка DBforBix: сохраняем преимущества и устраняем недостатки штатного мониторинга баз данных Zabbix
6. Варианты развития идеи
Тема: Как перестать бороться с графиками и начать жить
Я расскажу вам про интеграцию Zabbix и Grafana, чтобы вы могли улучшить возможности визуализации данных мониторинга с помощью Grafana.
1. Зачем нужны графики?
2. Как нарисовать 100 графиков за 10 секунд? (Query Editor, Regex, Templating)
3. И что потом с этим делать? ( Max Data Points, Functions, Performance)
4. События – это тоже Time Series (Annotations)
5. Seek & Destroy (Alerting в Grafana)
6. Бонус: Heatmap
Илья Аблеев – Zabbix в Badoo: реагируем быстро и качественноBadoo Development
В условиях большой инфраструктуры и немалого количества критичных компонентов, время реакции на инцидент должно быть как можно меньше. В докладе я расскажу, какие инструменты помогают увеличить скорость реакции и уведомить о проблеме качественнее.
Паша Мурзаков: Как 200 строк на Go помогли нам освободить 15 серверов» Badoo Development
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Highload2016
"Как мы готовим MySQL", Николай Королев
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Highload2016
"Архитектура хранения и отдачи фотографий в Badoo", Артём Денисов
В докладе будет рассмотрен процесс построения масштабируемой отказоустойчивой системы хранения, отдачи и обработки фотографий с точки зрения разработчика.
На примере Badoo, я расскажу о стандартном пути эволюции такого рода проектов. Детально разберу каждый этап и остановлюсь на основных сложностях и неочевидных проблемах.
Вместе с рассказом о наших решениях и подходах будут рассмотрены возможные альтернативы, их плюсы и минусы (вплоть до "мы небольшой стартап, как сделать что-нибудь похожее, но по-быстрому и на коленке").
Основные тезисы:
- Эволюция и типичные узкие места каждого из 3-х компонентов системы (хранение, отдача, обработка).
- Как отдавать фотографии? Когда лучше использовать сторонний CDN, а когда написать свой?
- Что лучше - хранить оригинал фото и ресайзить его на лету или заранее нарезать типовые размеры?
- Как сделать эффективное кэширование? Что такое consistent hashing и зачем он нужен?
- Где лучше хранить фотографии? Локальные диски, облачные хранилища, кластерные ФС?
- Надо ли их бэкапить и как часто? Что может пойти не так?
Highload 2016
"5 способов деплоя PHP-кода в условиях хайлоада", Юрий Насретдинов
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать 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.
— Анализ применимости и производительности способов деплоя.
— Выводы.
QA-конференция heisenbug.ru
ChromeDriver Jailbreak, Александр Баяндин (Badoo)
Chrome DevTools — один из наиболее полезных инструментов веб-разработчика. Он позволяет получать исчерпывающую информацию о странице и запросах и эмулировать мобильные браузеры на медленных устройствах. ChromeDriver использует тот же Chrome Debugging Protocol, что и DevTools для реализации Selenium JSON Wire Protocol взаимодействия с браузером. Этот протокол описывает самый базовый набор методов для взаимодействия со страницей, который несомненно уже всего набора методов, доступных в DevTools. В своём докладе Александр расскажет о том, как можно использовать (почти) всю мощь DevTools в Selenium-тестах и как сделать их отладку наиболее удобной.
84. Что нужно чтобы войти в Docker?
Узнать pid и id контейнера
# docker inspect -f '{{.State.Pid}} {{.Id}}' container_name
85. Что нужно чтобы войти в Docker?
Добавить в cgroup`ы
Узнать pid и id контейнера
86. Что нужно чтобы войти в Docker?
Добавить в cgroup`ы
Узнать pid и id контейнера
for f in $(ls /sys/fs/cgroup/*/docker/$CONTAINER_ID/tasks)
do echo $$ > $f
done
87. Что нужно чтобы войти в Docker?
Добавить в cgroup`ы
Узнать pid и id контейнера
Сменить namepsace`ы
88. Что нужно чтобы войти в Docker?
Добавить в cgroup`ы
Узнать pid и id контейнера
Сменить namepsace`ы
Снять лишние capabilities