Мои ощущения от процесса работы

Недавно я решил заняться ускорением восстановления нашей базы данных в dev-окружении. Как и во многих других проектах, база вначале была небольшой, но со временем значительно выросла. Когда мы начинали, ее размер было всего несколько мегабайт. Теперь упакованная база занимает почти 2 ГБ (несжатая — 30 ГБ ). Мы восстанавливаем dev-окружение в среднем раз в неделю. Старый способ проведения операции перестал нас устраивать, а вовремя подвернувшаяся в Slack-канале картинка “DB restore foos?” побудила меня к действию.

Ниже описано, как я ускорял операцию восстановления базы данных.

Чтобы отслеживать состояние работающих приложений, необходимо проводить их постоянный мониторинг. А если приложения выполняются в таком хорошо масштабируемом окружении, как Docker Swarm, то потребуется также и хорошо масштабируемый инструмент мониторинга. В этой статье говорится о настройке именно такого инструмента.

В процессе работы мы установим агенты cAdvisor на каждой ноде для сбора метрик хоста и контейнеров. Метрики будут сохраняться в InfluxDB. Для построения графиков на основе этих метрик воспользуемся Grafana. Эти инструменты распространяются с открытым исходным кодом и могут быть развернуты в виде контейнеров.

Для построения кластера мы будем использовать Docker Swarm Mode и развернем необходимые сервисы в виде стека. Это позволит организовать динамическую систему мониторинга, которая способна автоматически начинать мониторинг новых нод по мере их добавления в рой (swarm). Файлы проекта можно найти здесь.

Кадр из фильма «Матрица: Революция»

В этой статье мы подробно рассмотрим детали одной интересной находки: два часто используемых системных вызова (gettimeofday, clock_gettime) в AWS EC2 выполняются очень медленно.

В Linux реализован механизм по ускорению этих двух часто используемых системных вызовов, благодаря которому их код выполняется в пространстве пользователя, что позволяет избежать переключениям в контекст ядра. Это сделано с помощью предоставляемой ядром виртуальной общей библиотеки (virtual shared library), которая отображается в адресное пространство всех запущенных программ.

Два вышеназванных системных вызова не могут использовать vDSO (virtual Dynamic Shared Object) в AWS EC2, поскольку виртуализированный источник временных меток (virtualized clock source) в xen (и некоторых конфигурациях kvm) не поддерживает получение информации о времени через vDSO.

Обойти эту проблему не получится. Можно поменять источник информации о времени на tsc, но это небезопасно. Далее мы рассмотрим вопрос более подробно и проведем сравнительное тестирование с помощью microbenchmark.

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

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

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

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

Источник изображения

В конце 2016 компания Gitlab сообщила, что собирается уходить из облака (мы делали перевод этой статьи на Medium). Также был представлен весьма подробный план по покупке аппаратного обеспечения. Пользователи с интересом следили за развитием событий, активно комментировали опубликованные статьи и в итоге убедили GitLab отказаться от этой идеи.

У этой истории есть дополнительная интрига. Компания GitLab, которая сама по сути является поставщиком облачных услуг (правда, предоставляя пользователям приложение, а не вычислительные ресурсы), вдруг решила, что ей как потребителю подобная схема работы больше не подходит, но все же в итоге передумала.

В этой статье говорится о том, как настроить обратный прокси-сервер NGINX или NGINX Plus в качестве балансировщика нагрузки для хранилища объектов (object storage) на базе Minio.

Источник: 'Nova typis transacta navigatio' (Linz: s.n., 1621), p.12 (British Library, G.7237).

Часто во время разговоров о Docker я слышу мнения, с которыми не совсем согласен.

«Docker по своей сути предназначен для крупных компаний»

«под OSx у него экспериментальная поддержка, под Windows работает еле-еле»

«Я не уверен, что смогу быстро развернуть его локально»

… и еще много всякого.

В этих утверждениях есть доля истины (см. ниже мифы 3 и 5), но она мала, и по большей части реальная картина получается искаженной.

А есть еще и наполненные жаргоном статьи о том, как при использовании немалого количества фреймворков обрабатывать 10к миллионов запросов в секунду. И это с помощью всего лишь 30к контейнеров при автоматизации 5к микросервисов, размещенных на шести сотнях облачных виртуальных машин…

Что ж, нетрудно догадаться, почему Docker окружен таким количеством мифов.

К сожалению, эти мифы очень живучи. И главное их достижение заключается в том, что они пугают разработчиков и не дают им решиться на использование Docker.

Давайте поговорим о самых распространенных мифах – тех, с которыми я сталкивался и в которые верил, – и попробуем найти в них истину, а также решения, если таковые имеются.

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Разработанная инженерами Uber система хранения данных Schemaless используется в нескольких самых важных и крупных сервисах нашей компании (например, Mezzanine). Schemaless — это масштабируемое и отказоустойчивое хранилище данных, работающее поверх кластеров MySQL¹. Когда этих кластеров было 16, управление ими было несложным делом. Но в настоящий момент у нас их более 1 000, и в них развернуто не менее 4 000 серверов баз данных. Управление такой системой требует инструментов совсем другого класса.

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

В работе системного администратора, занимающегося внедрением систем телефонии на базе Asterisk, рано или поздно может возникнуть ситуация, когда аппаратных возможностей одного сервера для обработки всех вызовов уже недостаточно. Соответственно, возникает необходимость разделить нагрузку на несколько серверов. Одним из способов решения такой задачи является использование SIP proxy, но стоит признать, что в отличие от Asterisk, информации по SIP proxy, форумов, примеров и описаний, меньше как минимум на порядок. Цель этой статьи — показать на простом примере возможность использования SIP proxy Kamailio в связке с Asterisk так, чтобы максимально облегчить освоение SIP proxy для новичков.

В этой статье я описал создание в AWS состоящего из трех нод кластера Docker Swarm и подключение к нему общего для всех нод реплицируемого тома GlusterFS.

Он пьянел медленно, но все-таки опьянел, как-то сразу, скачком; и когда в минуту просветления увидел перед собой разрубленный дубовый стол в совершенно незнакомой комнате, обнаженный меч в своей руке и рукоплещущих безденежных донов вокруг, то подумал было, что пора идти домой. Но было поздно.

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...

По причине важности и во многих смыслах поучительности этого случая мы решили целиком перевести на русский язык его журнал-отчет, сделанный сотрудниками GitLab.com в процессе работы над инцидентом. Результат вы можете найти под катом.

— Сударь, каким образом вас взломали?
— Не образом, а контейнером.
Старинный анекдот

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

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

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

В такой ситуации успешное внедрение DevOps-практик может оказаться практически невозможным.

В качестве альтернативы я хотел бы предложить новую методологию под названием Swarming, которая уже готова к внедрению в крупном бизнесе и идеально подходит для выполнения задач технической поддержки в эру DevOps.

Linkerd, наша сервисная сетка (service mesh) для облачных приложений, по долгу службы обязана на протяжении длительного времени справляться с большими объемами сетевого трафика. Перед выпуском очередного релиза соответствие этому требованию необходимо тщательно проверять. В этой статье мы опишем стратегии нагрузочного тестирования и использованные нами инструменты, а также рассмотрим несколько обнаруженных проблем. В итоге будет представлен slow_cooker — написанный на Go инструмент нагрузочного тестирования с открытым исходным кодом, который был создан для выполнения длительных нагрузочных тестов и выявления проблем жизненного цикла (lifecycle issue identification).

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

1. Сколько уникальных исходящих TCP-соединений установили ваши серверы за последний час?
2. Какие процессы и пользователи инициировали установку этих соединений?

Если вы в состоянии ответить на оба вопроса, отлично — дальше можете не читать. А если ответа нет, то получить эту информацию поможет go-audit.

ansistrano.deploy и ansistrano.rollback — роли Ansible, предназначенные для управления процессом развертывания приложений, созданных на скриптовых языках программирования (например, PHP, Python и Ruby). По сути это реализация Capistrano в Ansible.

Использование Ansistrano дает следующие преимущества:

• откат за секунды (с ролью ansistrano.rollback);
• настройка процедуры развертывания с использованием методов-обработчиков событий «до» и «после» критически важных шагов;
• оптимизация использования дискового пространства за счет хранения ограниченного количества релизов;
• выбор между SCP, RSYNC, GIT, SVN, HTTP Download или S3 GET-стратегиями развертывания (в дополнение возможно использование unarchive).

У нас используется система управления проектами и задачами Redmine. Мы продолжаем допиливать ее под свои нужды, чтобы повысить удобство работы и расширить функционал. Очередной задачей стало ускорение поиска.

С тех пор как количество задач в Redmine выросло до нескольких сотен тысяч, время на обработку поискового запроса стало занимать десятки секунд, что недопустимо долго для нас. Поэтому мы решили внедрить полнотекстовый поиск на основе Elasticsearch. Про это и будет данный пост.