Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Недавно у департамента эксплуатации Яндекс.Денег прошло значимое событие. Наша компания быстро растет, и оказалось, что перемен требуют не только наши сердца, но и дата-центр. А точнее, перемен требовала его локация. И вот уже три месяца, как один из дата-центров живет в новом месте.

О том, как Яндекс.Деньги переезжали в новый дата-центр, расскажу я, руководитель департамента эксплуатации, и Иван, начальник отдела ИТ-инфраструктуры и внутренних систем.

Под катом — хронология событий, важные вехи переезда, неожиданные повороты и разбор полетов. Делимся, как мы пережили это.

Всем доброго времени суток!

Как-то, холодным тоскливым вечером, почитывал я статью про высококачественный усилитель класса D c Aliexpress. И пришла мне в голову мысль рассказать про свою DIY-поделку. А вот теперь дошли и руки. Ниже приведен ворклог об изготовлении очередного-сколько-уже-можно лампового (и не только) усилителя. Статья изобилует несерьезностью и петросянством, но все же пару, возможно, полезных схем вы здесь сможете найти.

Предупреждения:

1. ОСТОРОЖНО, трафик! Много картинок.
2. ОСТОРОЖНО! В представленых схемах используются опасные для жизни напряжения. Воспроизводя приведённые схемы, вы делаете это на свой страх и риск. Автор не несёт ответственности за последствия, наступившие в результате дублирования как всего устройства, так и отдельных его частей.

В начале этой недели состоялся очередной релиз Kubernetes, который окрестили «ангельским», — 1.13. Такое название связано с числом 113, которое считается «ангельским» и, со слов разработчиков Kubernetes, символизирует «новые начинания, трансформацию и конец одной главы перед открытием новых». Не вдаваясь в дальнейший анализ символизма происходящего, по уже сложившейся для нашего блога традиции, мы в седьмой раз расскажем о ключевых изменениях в новой версии Kubernetes, что призваны порадовать DevOps-/SRE-инженеров, работающих с этим продуктом.

В качестве источников информации мы оперировали данными из таблицы Kubernetes enhancements tracking, CHANGELOG-1.13 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP).

В MongoDB несколько обижены тем, что некоторые облачные провайдеры, особенно в Азии, используют их открытый код и предлагают коммерческую версию их базы данных в облаке своим пользователям, не играя по правилам открытого ПО. Чтобы бороться с этим, MongoDB сегодня объявила о выпуске новой лицензии на программное обеспечение — Server Side Public License (SSPL), которая будет использоваться во всех новых релизах их MongoDB Community Server, а также во всех патчах к предыдущим версиям.

Я люблю Ceph. Я работаю с ним уже 4 года (0.80.x — 12.2.6, 12.2.5). Порой я так увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
 Я сталкивался с различными проблемами в этом продукте, а с некоторыми продолжаю жить и по сей день. Порой я радовался легким решениям, а иногда мечтал о встрече с разработчиками, чтобы выразить свое негодование. Но Ceph по-прежнему используется в нашем проекте и не исключено, что будет использоваться в новых задачах, по крайней мере мной. В этом рассказе я поделюсь нашим опытом эксплуатации Ceph, в некотором роде выскажусь на тему того, что мне не нравится в этом решении и может быть помогу тем, кто только присматривается к нему. К написанию этой статьи меня подтолкнули события, которые начались примерно год назад, когда в наш проект завезли Dell EMC ScaleIO, ныне известный как Dell EMC VxFlex OS.

Это ни в коем случае не реклама Dell EMC или их продукта! Лично я не очень хорошо отношусь к большим корпорациям, и черным ящикам вроде VxFlex OS. Но как известно, всë в мире относительно и на примере VxFlex OS очень удобно показать каков Ceph с точки зрения эксплуатации, и я попробую это сделать.

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

Картинка: источник

Привет, Хабр! Меня зовут Илья Аблеев, я работаю в отделе мониторинга Badoo.

Можно долго холиварить на тему того, какая система мониторинга круче. Основным инструментом для реакции на проблемы в Badoo является Zabbix, и мы неоднократно делились опытом его кастомизации.

«Из коробки» узнавать о новых проблемах можно либо через веб-интерфейс, либо по почте/SMS. Это хорошо работает и до определённого момента нас устраивали эти способы.

На сегодняшний день в нашей системе несколько инстансов сервера, тысячи хостов, сотни тысяч проверок и примерно столько же триггеров, на которые нужно как можно более оперативно реагировать. После ряда инцидентов, когда только на обнаружение проблемы мы тратили до десяти минут (что совершенно недопустимо), мы осознали, что нам жизненно необходимы другие способы уведомления о проблемах. Тогда, возможно, наша реакция была бы быстрее.

Оптимальным решением, на наш взгляд, был бы вывод важных уведомлений поверх всех окон (браузеров, чатов, консолей). В этой статье речь пойдёт о том, как мы допилили Zabbix, научив отправлять их прямо на рабочий стол.

Кому подойдёт данное решение:

• дежурным администраторам, которые не только круглосуточно смотрят в монитор, но и занимаются решением других задач;
• всем остальным администраторам, которым не нравится просматривать простыню PROBLEM и OK`ов в почте или SMS, но которые хотят своевременно узнавать о критичных проблемах.

Придётся потратить время на установку, но, думаю, если вы используете Zabbix и уже использовали кастомные скрипты, для вас это не составит труда.

В пятницу начинается Слёрм, интенсив по Кубернетес. Если не подведет местный интернет, мы будем транслировать все лекции.

Расписание трансляций:

3 августа, 9:00—13:00
— Автоматизация развертывания инфраструктуры. Ansible
— Docker, основы практической работы
— Знакомство с Kubernetes, основные компоненты (Pod, ReplicaSet, Deployment, Service, Ingress, PV, PVC, ConfigMap, Secret)

3 августа, 16:00—19:30
— Знакомство с Kubernetes: продолжение
— Kubespray, тюнинг и настройка кластера Kubernetes

4 августа, 9:00—11:00: Ceph, настройка кластера и особенности работы в продакшен
4 августа, 15:00—16:00: Введение в Helm
4 августа, 17:30—18:30: Траблшутинг кластера

5 августа, 9:00—10:15: CI/CD, построение деплоя в кластер с нуля

Я буду публиковать ссылки на трансляции по мере их появления.

О Слёрме и планах на Слёрм-2

Предыстория

Существует небольшая локальная сеть предприятия, в которой лет 10 назад на Debian 5 был поднят домен на 3-й «Самбе» + LDAP + BIND(на шлюзе). По сути от нее нужна была только аутентификация пользователей, да файловые шары. Все эти годы сервер без проблем апгрейдился до новых версий Debian. На данный момент на нем Debian 8 и Samba 4.2 из пакетов.

Со времен Windows 7 введение компьютеров в домен, без всем известного костыля с правкой реестра, не получалось. Тот же костыль работал в Win 8 и Win 10 до версии 1803. Помимо невозможности ввода компьютеров в домен, накопились и другие проблемы и в итоге было решено провести classicupgrade. Ввиду простоты структуры ЛВС было принято решение использовать внутренний DNS «Самбы».

Сразу хочу сказать, что статья не является точным руководством, а скорее опытом проведения данной операции. Стадия предварительного тестирования крайне рекомендуется. В моем случае для тестирования были сняты образы серверов и развернуты на виртуальных машинах VirtualBox.Также, для тестирования поведения существующих клиентов домена, были созданы клиентские машины Win XP SP3 и Win 10 1709 и 1803.

Также хочу заметить, что неоднократно ошибки были вызваны банальными опечатками. Будьте внимательны.

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

Правда на пике популярности Ceph и GlusterFS, которые работают в принципе неплохо, а главное сразу и из коробки, все просто немного подзабыли про него. Тем более что предыдущая версия не поддерживала репликацию более чем на два узла, и из-за чего часто встречались проблемы со split-brain, что явно не добавило ему популярности.

Решение и правда не новое, но вполне конкурентоспособное. При относительно небольших затратах на CPU и RAM, DRBD предоставляет реально быструю и безопасную синхронизацию на уровне блочного устройства. За все это время LINBIT — разработчики DRBD не стоят на месте и постоянно дорабатывают его. Начиная с версии DRBD9 перестает быть просто сетевым зеркалом и становится чем-то бОльшим.

Во первых, идея создания одного распределенного блочного устройства для нескольких серверов отошла на задний план, и теперь LINBIT старается предоставить инструменты оркестрации и управления множеством drbd-устройств в кластере, которые создаются поверх LVM и ZFS-разделов.

Например DRBD9 поддерживает до 32 реплик, RDMA, diskless-ноды, а новые инструменты оркестрации позволяют использовать снапшоты, online-миграцию и много чего другого.

Несмотря на то что DRBD9 имеет инструменты интеграции с Proxmox, Kubernetes, OpenStack и OpenNebula, на данный момент они находится в некотором переходном режиме, когда новые инструменты еще не везде поддерживаются, а старые уже очень скоро будут объявлены как deprecated. Речь идет о DRBDmanage и Linstor.

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

Техническое задание

Имеется сеть географически разбросанных дата-центров с вагоном VRF и постоянно изменяющимся списком OSPF соседей. Необходимо отслеживать их:

1. Состояние, делать alarm если состояние соседа не FULL
2. Количество, то есть если сосед пропал, нужно также делать alarm

Система мониторинга уже есть — Zabbix 3.4, желательно использовать именно её, ОС Linux Debian 9.x

В среду состоялся релиз Kubernetes 1.11. Продолжаем нашу традицию и рассказываем о наиболее значимых изменениях, основываясь на данных из CHANGELOG-1.11 и многочисленных issues, pull requests и design proposals. Что нового в K8s 1.11?

Решение данного квеста навеяно этой статьей.

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

Итак, вкратце, постановка задачи следующая: поднять в качестве виртуальной машины (гостя) на MetaROUTER урезанную версию OpenWRT и уже на нем поднять связку DNS + DNSCrypt, которую использовать для шифрованного обмена данными с внешними DNS серверами.

Это мой конспект, в котором коротко и по сути затрону такие понятия Kafka как:

— Тема (Topic)
— Подписчики (consumer)
— Издатель (producer)
— Группа (group), раздел (partition)
— Потоки (streams)

Kafka — основное

При изучении Kafka возникали вопросы, ответы на которые мне приходилось эксперементально получать на примерах, вот это и изложено в этом конспекте. Как стартовать и с чего начать я дам одну из ссылок ниже в материалах.

Apache Kafka – диспетчер сообщений на Java платформе. В Kafka есть тема сообщения в которую издатели пишут сообщения и есть подписчики в темах, которые читают эти сообщения, все сообщения в процессе диспетчеризации пишутся на диск и не зависит от потребителей.

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

Начало истории вы можете вспомнить в первой статье, я же кратко напомню, что происходит.

Все началось с перевода монолитных приложений на микросервисы, когда налаженный процесс накатки новых релизов на тестовую среду начал сбоить из-за резко возросшей «детализации». Чтобы разработчики не ссорились из-за общих тестовых стендов и все работало быстро и гладко, мы запустили проект автоматизации.

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

Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.

Большое и хорошо организованное Open Source-сообщество, стоящее за разработкой Kubernetes, приучило нас ждать значимых и многочисленных изменений от каждого релиза. И Kubernetes 1.8 не стал исключением, представив на радость DevOps-инженерам и всем сочувствующимучастникам улучшения и новые возможности практически во всех своих компонентах.

Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.