Дисклеймер

Все эксперименты проводились на CentOS Linux release 7.2.1511 в качестве основной системы, с последними доступными из стоковой репы systemd (systemd-219-19.el7_2.13). Надеюсь, часть приведенных данных будет неактуальна уже на момент публикации статьи.

Вводная часть

Начав захватывать linux-дистрибутивы с выпуска Fedora 15, systemd окончательно победил. Зубры и аксакалы понемногу приучаются к unit'ам и systemctl. Скрежещат зубами последние защитники Старого Доброго. В этих реалиях невозможно обойти дочерние продукты systemd. И сегодня давайте поговорим, например, про journald.

Контейнеры Docker хороши тем, что они немутабельны (immutable). Docker поставляется с файловой системой типа copy-on-write, поэтому базовый образ может быть изменен только в том случае, если вы сами создали соответствующий коммит.

Эта особенность может пригодиться, например, при расследовании хакерских атак. Давая возможность легко проверить расхождение файловой системы контейнера с базовым образом, она позволит увидеть сделанные атакующей стороной изменения.

Источник фотографии

Все умеют считать, но не все умеют считать быстро. В этой статье мы подробно рассмотрим методы оптимизации count в PostgreSQL. Существуют приемы, которые могут позволить ускорить подсчет количества строк на порядки.

Если подходить к вопросу со всей серьезностью, необходимо выделить несколько вариантов count, у каждого из которых есть собственные методы. С чем нужно будет определиться:

• требуется ли точное количество строк или оценочного значения будет достаточно;
• следует ли учитывать дубликаты или интересуют только уникальные значения;
• нужно ли посчитать все строки таблицы или необходимо выбрать только удовлетворяющие определенному условию.

Мы проанализируем решения для каждой конкретной ситуации, а также сравним их скорость и потребление ресурсов. Разобрав ситуацию с централизованной БД, мы воспользуемся Citus, чтобы продемонстрировать параллельное выполнение count в распределенной базе данных.

Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.

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

Каждый год появляется столько новых технологий (таких как Kubernetes или Habitat), что легко забыть о тех инструментах, которые тихо и незаметно поддерживают наши системы в промышленной эксплуатации. Одним из таких инструментов, который мы используем в Stripe на протяжении нескольких лет, является Consul. Consul помогает в обнаружении сервисов (то есть помогает находить тысячи работающих у нас серверов с запущенными на них тысячами различных сервисов и сообщать, какие из них доступны для использования). Это эффективное и практичное архитектурное решение не было чем-то совсем новым и особенно заметным, но оно верой и правдой служит делу предоставления надежных сервисов нашим пользователям по всему миру.

В этой статье мы собираемся поговорить о следующем:

• Что такое обнаружение сервисов и Consul.
• Как мы управляли рисками, возникавшими при внедрении критически важного программного продукта.
• Вызовы, с которыми мы столкнулись, и наши ответы на эти вызовы.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Недавно мы перевели Zabbix на работу с БД PostgreSQL. Вместе с переездом на сервер с SSD это дало существенный прирост скорости работы. Также решили проблему с дублирующими хостами в базе данных, bug request. Здесь статья могла бы закончиться, но мы заметили, что Zabbix использует много дискового пространства, поэтому ниже я расскажу, как это вышло. И как мы с этим разобрались.

“Не трудности “ломают” вас, а то, как вы их переносите” —  Lou Holtz

В соавторстве с Emmet O’Grady (основателем NimbleCI и Docker Ninja)

В книге Франца Кафки “Превращение” (“Метаморфозы”) человек просыпается однажды утром и обнаруживает, что он превратился в гигантское насекомоподобное существо. Как у инженеров DevOps, у нас есть такие же сюрреалистические моменты в жизни. Мы находим экзотические ошибки “под ковриком” (скрытые в самых труднодоступных местах) или бываем атакованы червями либо другими опасными сущностями. Если вы занимаетесь этим достаточно долго, у вас рано или поздно появится ужасная история, или даже две (поделитесь ими с нами!). В такой момент мы не можем сидеть и ждать, когда наступит кризис, мы должны действовать быстро. Торопясь исправить это как можно раньше, мы должны развернуть (deploy) новую сущность и выпустить новую версию нашего сервиса, устраняя проблему.

В этом июне, в качестве лейтмотива конференции DockerCon мы видели демо, в котором 3-узловой Swarm-кластер был создан за 30 секунд используя набор инструментов для кластеризации Swarm, интегрированную в Docker Engine 1.12.

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

Всем привет! Мы продолжаем серию статей про DevOps и ищем наиболее эффективные способы управлять конфигурацией, делясь с вами опытом. В прошлых статьях мы рассматривали, как выстроить управление конфигурацией Ansible с помощью Jenkins и Serverspec, а теперь по вашим просьбам рассмотрим, как организовать управление конфигурацией с помощью GitLab-CI.

Ansible-lint — это утилита для проверки корректности синтаксиса плейбука и стиля кода, которую можно интегрировать в CI-сервис. В нашем случае мы внедряем её в gitlab-ci для проверки плейбуков на этапе принятия Merge-Request и выставления статуса проверок.
GitLab (GitLab Community Edition) — это opensource-проект, менеджер git-репозиториев, изначально разрабатывающийся как альтернатива платной корпоративной версии Github.

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

Недавно разработчики Ansible анонсировали новый проект Ansible Container. Проект нас очень сильно заинтриговал, и мы решили рассмотреть его поближе.
Ansible уже давно стал незаменимым инструментом в вопросах создания, сборки, деплоя образов docker-контейнеров и самих docker-контейнеров, благодаря соответствующему модулю.
Ранее для провиженинга docker-контейнеров с помощью Ansible необходим был запущенный в контейнере sshd, но в версии 2.1 в Ansible был добавлен Docker connection plugin, благодаря которому стало возможно запускать плейбуки не только на физических/виртуальных машинах, но и внутри docker-контейнеров и отпала необходимость использования sshd внутри docker-контейнера.

Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?



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

1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.

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

Думаю, любой системный администратор, использующий Ansible для управления своим зоопарком серверов задавался вопросом о проверке корректности описания конфигурации своих серверов. Как же не бояться вносить изменения в конфигурации серверов?
В серии статей, посвященных DevOps, мы расскажем об этом.

В последнее время клиенты нашей компании все чаще обращаются с просьбой осуществить переход с MySQL на PostgreSQL. Действительно, активное развитие PostgreSQL дает повод разработчикам задуматься о смене СУБД. Зачастую при этом встает вопрос о переносе больших объемов данных, которыми «обросла» существующая база под MySQL.

Мы сами являемся активными пользователями Redmine и разработчиками плагинов для него, потому и выбрали эту CRM для иллюстрации процесса миграции.

Ниже описывается один из способов миграции с БД MySQL на PostgreSQL 9.5 для Redmine на ОС CentOS 6.

Если вы храните конфиденциальные данные в Wiki Redmine, наверняка задумывались, что случится, если кто-то сможет получить доступ к серверу и загрузить БД.
Предлагаю вашему вниманию, разработанный нашей компанией, плагин redmine_wiki_encryptor. С помощью этого плагина Redmine будет расшифровывать на лету данные из таблиц Wiki, таким образом, даже если кто-то и получит дамп БД, без ключа ничего прочитать не сможет.

Если вы являетесь активным пользователем Redmine, содержимое которого наверняка конфиденциально, вы наверняка задумывались над усилением безопасности приложения.

В этой статье описана процедура настройки авторизации в Redmine через одноразовые пароли (OTP) с помощью мобильного приложения Google Authenticator.

Статья описывает установку и настройку Google Authenticator, а так же плагина redmine_pam_auth для Redmine 2.2 под ОС CentOS 6.

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

На картинке изображен наглядный пример графика нагрузки сети. До 18:00 сжатие было отключено, в 18:00 — включено.

В нашей компании возникла необходимость оповещения по SMS о задачах, поставленных в трекере Redmine, с приоритетом «Авария!». Очень удобно получать такие оповещения, когда требуется мгновенная реакция.

Совместно с командой разработчиков из secoint.ru мы разработали плагин redmine_status_notifier, о котором я и расскажу под катом.

Самый частый вопрос при выборе зарубежного хостера (на примере Hetzner): «Не будет ли сайт тормозить»? Несмотря на то, что ping к Hetzner из России достаточно мал, статика (особенно тяжелая или если ее много) с серверов, размещенных в России, отдается быстрее.

Есть несколько вариантов увеличения скорости оставаясь в Hetzner:

1. Использование российских CDN-сервисов.
2. Проксирование/кэширования статики через сервер/vps, размещенный в России.

Я расскажу, как технически реализовать проксирование/кэширование статики с помощью nginx через сервер, размещенный в России.