DevOps *

На дворе 2017 год, а в различных статьях и, тем более, комментариях к ним то и дело приходится встречаться с мнением, что Docker — удел неопытных энтузиастов, экзотических компаний-однодневок и каких угодно экспериментов, максимально удалённых от реального production. И вот пока коллеги готовят новые технические материалы, я решил на публично доступных примерах и фактах показать, что это скорее миф и стереотип, чем мир, в котором живёт ИТ сегодня.

Масштабы и тенденции докеризации

Отправная точка для этой статьи — статистика от сервиса мониторинга Datadog, которая впервые появилась в 2015 году и в последний раз была обновлена буквально на днях, в апреле 2017 года. Datadog — это не какая-то традиционная аналитическая компания, а известная своей дружелюбностью к облачным окружениям система мониторинга (код её агента написан на Python и опубликован как Open Source).

Наряду с развитием механических систем автомобиля инженеры постояно стремились добавить что-то в электроную начинку, сделать машину безопаснее, управляемее и умнее. Сегодня для этого есть все предпосылки: ИТ-отрасль развивается огромными темпами, автопроизводители готовы сотрудничать и вести перспективные разработки, корпорации вкладываются в развитие автотранспорта. Между тем, «ум» автомобилей развивался поступательно, на протяжении более полувека. Всё это время он принимал разные формы и уходил в разные концепции: от безопасности до развлечений. Современый виток эволюции зашёл так далеко, что уже непонятно, софт определяет железо или железо — софт. А значит, пора написать об автомобилях на Гиктаймс

Согласно данным, которые представил на Dockercon 2016 CEO компании Docker Бен Го́луб (Ben Golub), количество работающих в контейнерах Docker приложений за последние два года выросло на 3100%. Docker обеспечивает функционирование 460 тысяч приложений по всему миру. Это невероятно!

Если вы еще не начали использовать Docker, прочтите этот впечатляющий документ о его внедрении. Docker изменил подход к созданию приложений и стал крайне важным инструментом для разработчиков и DevOps-специалистов. Эта статья рассчитана на тех, кто уже использует Docker, и призвана открыть еще одну причину, по которой стоит продолжать это делать.

Мы бы хотели поделиться своим опытом использования docker-compose в больших проектах. Применив этот инструмент для автоматизации задач, связанных с разработкой, тестированием и конфигурированием, мы за несколько простых шагов смогли сделать нашу команду более эффективной и сфокусироваться непосредственно на разработке продукта.

При балансировке нагрузки важный вопрос — сохранение сессии клиента. Особенно, если за балансировщиком стоит какой-то интерактивный backend. И тем более, если захотелось сделать A/B тестирование и гибко регулировать порции клиентов к различному содержанию. "Nginx plus" предлагает такие возможности, но что делать, если хочется дёшево и быстро?

На помощь приходит возможность расширить функционал Nginx с помощью Lua.

В команде эксплуатации подумали, что наш опыт с Microsoft SQL в нагруженной среде больше нельзя скрывать, и потому родилась эта статья. В ней я расскажу о нюансах работы с этой СУБД из практики.

Microsoft SQL Server давно нашел свое место в семействе продуктов Яндекс.Денег и успешно решает задачу сбора разрозненной информации обо всех операциях из множества отдельных сервисов. Без такой сборки воедино нельзя было бы отследить платеж, собрать статистику или решить проблему.

Все сказанное далее будет полезно администраторам крупных БД – тем, кто заботится о быстрой и точной работе аналитики Microsoft SQL Server 2012-2014.

Если информация окажется вам полезной и интересной — обязательно дайте знать в комментариях, чтобы автор не расслаблялся.

Проблема stateful-приложений в Kubernetes

Конфигурация, запуск и дальнейшее масштабирование приложений и служб осуществляются просто, если речь идёт о случаях, классифицируемых как stateless, т.е. без сохранения данных. Такие сервисы удобно запускать в Kubernetes, пользуясь его стандартными API, потому что всё происходит «из коробки»: по стандартным конфигурациям, без привлечения какой-либо специфики и магии.

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

• RFC 791 – Internet Protocol
• RFC 793 – Transmission Control Protocol

Мы уже упоминали, что в этом году тематика конференции PG Day’17 Russia значительно расширилась. Совместно с компанией Percona мы сформировали отдельный поток выступлений по MySQL/NoSQL. Помимо докладов от ведущих специалистов по открытым базам данных и no sql решениям, в рамках конференции состоятся также 2 эксклюзивных мастер-класса от ведущих специалистов Percona — Петра Зайцева и Светы Смирновой.



На мастер-классах будут рассмотрены самые различные темы по базам MySQL: создание и использование тестового сервера, тонкости отладки медленных запросов, особенности систем блокировок, влияние оборудования и конфигурации на производительность, сбор данных с минимальной нагрузкой на сервер.

Сегодня предлагаем вашему вниманию перевод небольшого обзора, в котором Света Смирнова ‒ старший инженер службы технической поддержки Percona и Анастасия Распопина, специалист по маркетингу, сравнивают как PostgreSQL и MySQL справляются с миллионами запросов в секунду.

5-го июля для участников PG Day’17 Светлана более подробно расскажет про архитектуру MySQL сервера и специфику работы с разными его частями, такими как оптимизатор, табличные движки, системы блокировок.

Анастасия: Могут ли базы данных с открытым исходным кодом справиться с миллионом запросов в секунду? Многие защитники открытого исходного кода ответят «да». Однако утверждений недостаточно для обоснованных доказательств. Именно поэтому в этой статье мы делимся результатами тестов от Александра Короткова (директора отдела разработки, Postgres Professional) и Светы Смирновой (главный инженер по техническому обслуживанию, Percona). Сравнительное исследование производительности PostgreSQL 9.6 и MySQL 5.7 будет особенно полезно для сред с несколькими базами данных.

В этой статье рассматривается простой способ создания и тестирования образов docker. По ходу повествования, используя Goss, мы напишем тесты, с помощью которых можно проверить официальный образ Nginx всего за ~0,5 с.

В кластере Kubernetes нода может умереть или перезапуститься.

Инструменты вроде Kubernetes обеспечивают высокую доступность, спроектированы для надёжного функционирования и автоматического восстановления в подобных сценариях, и Kubernetes действительно прекрасно со всем этим справляется.

Однако вы можете заметить: когда нода падает, поды сломанной ноды на протяжении какого-то времени всё ещё запущены и получают запросы, которые уже не выполняются.

И по умолчанию это время, как мне кажется, слишком велико — его можно уменьшить. На него влияют несколько параметров, настраиваемых в Kubelet и Controller Manager.

Ghost это очень мощная и в то же время лаконичная платформа для блогинга, а docker-compose прекрасный инструмент для установки и конфигурирования программ с помощью одного .yml файла. В этой статьей я хочу коротко рассказать о том как мы быстро настроили блог для нашего проекта с помощью docker-compose.

Начнем!

Привет! Объявляем регистрацию на митап открытой. Мы в очередной раз принимаем в нашем офисе сообщество Zabbix. Ниже – описание выступлений. Начало мероприятия в 12:00.

В середине марта стало известно, что компания Docker предложила свой проект containerd независимому фонду Cloud Native Computing Foundation (кстати, произошло это одновременно с rkt от CoreOS). Событие последовало за обещанием компании, данным в декабре прошлого года, когда containerd был официально отделён от Docker Engine. Что же это за компонент и зачем его отделили?

Как устроен containerd

containerd — это бывшая часть Docker, а ныне самостоятельное решение, реализующее исполняемую среду для запуска контейнеров. При его создании, как утверждают разработчики, они стремились к простоте, надёжности и портируемости.

Настройка непрерывной доставки (Continuous delivery CD) для вашего проекта c github.com

Hеобходимо:

• Репозиторий на github.com
• Сервер для Ansible (для примера ip: 1.1.1.1)
• Сервер для развертывания вашего проекта (для примера ip: 2.2.2.2)
• Локальная машина с настроенным проектом
• Базовые знания работы в командной строке, Travis CI и Ansible

Мы продолжаем цикл публикаций о внедрении инструментов и практик DevOps в нашей компании. Недавно мы рассказывали о том, как анализируем уязвимости с помощью нейронных сетей и нечеткой логики, а сегодня поговорим о внедрении системы мониторинга Zabbix в процессы разработки и тестирования.

Необходимость мониторинга должна быть очевидна практически для любой компании, однако я не раз сталкивался с примерами, когда к такому выводу ребята приходили только после падения продакшна. Причем нередко команда узнавала об этом уже постфактум — от своего генерального директора, которому на недоступность проекта пожаловались его друзья, решившие вдруг взглянуть на стартап. И вот он в гневе звонит членам команды с вопросом даже не «почему все упало», а почему он об этом знает, а они — нет. И тут им в голову приходит мысль, а почему бы не настроить мониторинг? Казалось бы, что может быть проще…

Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.

Но правильный, настоящий мониторинг пишется кровью системного администратора и разработчика. Каждый кейс, каждый факап и даже внутренние процессы, включая количества тонера в картридже принтера, должны быть описаны сценарием мониторинга. Я решил немного рассказать о том, с чем мы столкнулись при организации этого процесса, а также как выстроили работу сисадминов, снизив количество дежурств и улучшив их качество. При этом упор будет сделан на подходе к мониторингу, тогда как настройка той или иной системы легко гуглится и без посторонней помощи.

22 марта в Avito прошёл второй митап московского Kubernetes коммьюнити, а сегодня мы делимся материалами встречи. Денис Измайлов сделал обзор последних изменений инструмента, Евгений Ольков и Павел Селиванов рассказали про то, как используется Kubernetes, соответственно, в Avito и Центре Недвижимости от Сбербанка, а Сергей Орлов сделал короткий доклад про пакетный менеджер Helm. Приятного просмотра!

Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 в секции «DevOps и эксплуатация».



Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.

Что мы хотим от Docker-образов?

Как объяснить контейнеру docker-а сколько у него есть ресурсов?

К написанию этой небольшой заметки меня подтолкнула статья-перевод Java и Docker: это должен знать каждый и скудный на результаты поиск информации по теме. Я давно использую LXC, который тоже ограничивает ресурсы контейнеров средствами cgroup, и там эта проблема уже решена.

Site Reliability Engineer в Dropbox Леонид Васильев четыре года живёт и работает в Ирландии. Леонид рассказал, как переехал в Ирландию, почему перешёл из Amazon в Dropbox, как устроен их офис в Дублине, и каким он видит будущее DevOps.


До переезда Леонид отучился на мат-мехе УрГУ и пять лет проработал в Яндексе