It hasn't been that long since my last cheat sheet was published and this is the day for the new one. This time I got a task to find a solution for backing up Kafka to S3 bucket, following the terms:
Mikhail Skuditskiy @LazyFao
DevOps-engineer
Google SSO for Kibana straightforward way on basic license
Easy
5 min
Tutorial
As many times before, I keep writing cheat sheets after the tasks which made me search a lot and glue things together before I found a solution. Long story short, this time I was asked to set up Google SSO for Kibana without switching from a basic license to a paid one. Kibana, by the moment, already had authentication set up and the customer wanted to log in there with the use of Google Workspace user accounts. Along with that, the customer wanted to keep user account which was already there, in Kibana. There was no need for role mapping or other advanced features, just plain SSO and that's all. As you probably know Elastic provides SSO feature only on paid license, so I have had no other way to get it working except for using 3rd party software. But first things first, let's list the steps we should go over:
NiFi по красоте: HTTPS/LDAP/NiFi Registry/NiFi Cli + CI/CD
21 min
Tutorial
Давайте, я сразу объясню свою баянистость. Да, в интернетах полно мануалов. Да, полно пошаговых прохождений. Да, можете сказать, что все жевано пережевано. Но конкретно в моем случае, как это всегда и бывает, оказалась горстка "но":
Есть мануалы о том, как настроить связку NiFi и NiFi Registry со включенной аутентификацией и авторизацией. Но... используются самоподписанные серты.
Есть отдельные мануалы, как прикрутить коммерческий серт для NiFi; соответственно для NiFi Registry "кагбэ так же". Но взаимная аутентификация и авторизация будет происходить с использованием Two way SSL... а у нас же LDAP... и обеспечить потом связность сладкой парочки с использованием только внешнего каталога у вас на голой интуиции не получится.
Есть мануалы по связке с LDAP и для NiFi, и для NiFi Registry. Нооо... как и в предыдущем "но", возникают вопросы, как обойтись потом только LDAP'ом, потому что у нас же еще NiFi Cli, а он в LDAP не умеет.
Иными словами, во всех мануалах есть маааленький нюанс: они покрывают только простейшие сценарии. Документации по комплексным связкам просто нет. Более того, в ходе настройки связки я столкнулся со сложностями, которые в буржуйнете встречаются всего несколько раз и все они либо без ответов, либо ответы не релевантны.
Мастерим задание на деплой в GKE без плагинов, смс и регистрации. Одним глазком заглядываем Jenkins'у под пиджак
13 min
Tutorial
Все началось с того, что тимлид одной из наших команд разработчиков попросил в тестовом режиме выставить наружу их новое приложение, которое накануне было подвергнуто контейнеризации. Я выставил. Примерно через 20 минут поступила просьба обновить приложение, потому что там допилили очень нужную штуку. Я обновил. Еще через пару часов… ну, вы и так догадываетесь, что стало происходить дальше…
Я, признаться, довольно ленив (я же ранее в этом признавался? нет?), и, учитывая тот факт, что тимлиды имеют доступ в Jenkins, в котором у нас весь CI/CD, подумал: да пусть он сам деплоит, сколько заблагорассудится! Вспомнил анекдот: дай человеку рыбу и он будет сыт день; назови человека Сыт и он будет Сыт всю жизнь. И пошел мастрячить джобу, которая бы умела деплоить в кубер контейнер с приложением любой успешно собранной версии и передавать в него любые значения ENV (мой дедушка, — филолог, преподаватель английского в прошлом, — сейчас бы покрутил пальцем у виска и очень выразительно посмотрел бы на меня, прочитав это предложение).
Итак, в заметке я расскажу о том, как я научился:
Я, признаться, довольно ленив (я же ранее в этом признавался? нет?), и, учитывая тот факт, что тимлиды имеют доступ в Jenkins, в котором у нас весь CI/CD, подумал: да пусть он сам деплоит, сколько заблагорассудится! Вспомнил анекдот: дай человеку рыбу и он будет сыт день; назови человека Сыт и он будет Сыт всю жизнь. И пошел мастрячить джобу, которая бы умела деплоить в кубер контейнер с приложением любой успешно собранной версии и передавать в него любые значения ENV (мой дедушка, — филолог, преподаватель английского в прошлом, — сейчас бы покрутил пальцем у виска и очень выразительно посмотрел бы на меня, прочитав это предложение).
Итак, в заметке я расскажу о том, как я научился:
- Динамически обновлять задания в Jenkins'е из самого задания или из других заданий;
- Подключаться к облачной консоли (Cloud shell) с ноды с установленным агентом Jenkins'а;
- Деплоить рабочую нагрузку (workload) в Google Kubernetes Engine.
Восстанавливаем виртуальные машины с ошибочно инициализированного Datastore. История одной глупости с хэппи-эндом
5 min
Disclaimer: Заметка носит развлекательный характер. Удельная плотность полезной информации в ней мала. Была написана «для себя».
Лирическое вступление
Файловая помойка в нашей организации крутится на виртуальной машине VMware ESXi 6 под Windows Server 2016. И это не просто помойка. Это сервер файлового обмена между структурными подразделениями: тут и совместная работа, и проектная документация, и папки с сетевых сканеров. В общем, тут вся производственная жизнь.
И вот это вместилище всей производственной жизни стало виснуть. Причем гость мог тихо повиснуть сам, не затрагивая остальных. Мог повесить вслед за собой весь хост и, соответственно, все остальные гостевые машины. Мог повиснуть сам и повесить клиентские службы vSphere: то есть процессы остальных гостей живы, машины исправно работают и отвечают, а вот файлопомойка нет и vSphere Client к хосту не цепляется. В общем, никакой системы выявить не удавалось. Зависания могли произойти днем во время слабой загрузки. Могли ночью во время нулевой нагрузки. Могли ночью во время дифференциального резервного копирования и средней загрузки. Могли в выходные во время полного резервного копирования и высокой нагрузки. И наблюдалась явная деградация ситуации. Сначала это было раз в год, потом раз в полгода. Под конец моего терпения — дважды в неделю.
Поднимаем IDS/NMS: Mikrotik и Suricata c web-интерфейсом
9 min
Tutorial
У меня, видимо, такая карма: как ни возьмусь за реализацию какого-нибудь сервиса на опенсорсе, так обязательно найду кучу мануалов, каждый по отдельности из которых в моем конкретном случае не сработает, готовое решение толком не заведется или не понравится, случится еще какая-нибудь неудобоваримость, и в итоге приходится самому пробиваться к результату.
В этот раз все мануалы были на ELK5 или еще старше, а мне не очень хотелось ставить софтину пред-предыдущих версий. Мне хотелось взять софтину с наиболее перспективными сроками поддержки: желательно самое свежее из стабильного.
В итоге, чтобы в дальнейшем иметь возможность повторить совершенный подвиг без повтора всех мучений, приходится писать такие пошаговые шпаргалки, которыми и делюсь с вами.
Итак, сегодня Mikrotik (RouterOS), Suricata 4.1, Elasticsearch+Filebeat+Kibana 6.5.
В этот раз все мануалы были на ELK5 или еще старше, а мне не очень хотелось ставить софтину пред-предыдущих версий. Мне хотелось взять софтину с наиболее перспективными сроками поддержки: желательно самое свежее из стабильного.
В итоге, чтобы в дальнейшем иметь возможность повторить совершенный подвиг без повтора всех мучений, приходится писать такие пошаговые шпаргалки, которыми и делюсь с вами.
Итак, сегодня Mikrotik (RouterOS), Suricata 4.1, Elasticsearch+Filebeat+Kibana 6.5.
FusionPBX, или снова-здорово, FreeSWITCH
14 min
Tutorial
В ту же реку
Относительно недавно я написал себе шпаргалку по настройке FreeSWITCH. Описанный там процесс настройки привел к работоспособной в тестовых условиях конфигурации. Тест был необходим для составления предварительного представления о том, с чем придется иметь дело после переезда организации и запуске телефонии в продакшн. Однако, когда переезд состоялся и началось подключение в рабочем режиме, то первое же включение показало неработоспособность конфигурации: перестали ходить внутренние вызовы.
КОДОС: остаться в живых
7 min
Tutorial
Признаться, меня одолевали сомнения в нужности этого текста. Однако, вспомнив максиму «лучше сделать и жалеть, чем не сделать и жалеть», решил все же написать.
Речь пойдет об еще одной (наравне с офисной телефонией) очень любимой всеми системными администраторами (сарказм) зоне ответственности — системах контроля и управления доступом (СКУД).
Основной восторг вызывают три вещи:
Если вам знаком этот восторг, прошу под кат.
Речь пойдет об еще одной (наравне с офисной телефонией) очень любимой всеми системными администраторами (сарказм) зоне ответственности — системах контроля и управления доступом (СКУД).
Disclaimer: речь пойдет о СКУД Кодос версии 1.10.8.0. Возможно, в более поздних версиях пробелы в функциональности и производительности были устранены.Прелесть работы с такой софтиной образца десятилетней давности вытекает из немного внеземной эргономики интерфейса, немного нечеловеческой логики работы с фронт-эндом операторской части и из прочих плодов творчества людей, работавших под руководством людей в погонах (не могу представить себе идеолога разработки СКУД без погонов в прошлом).
Основной восторг вызывают три вещи:
- Отчет о проходах составляется более 10 минут.
- Ограничение длины отчета в 1000 записей.
- Отсутствие экспорта и импорта учетных записей.
Если вам знаком этот восторг, прошу под кат.
Freeswitch: по пути наименьшего сопротивления
13 min
Немного лирики
Сколько помню себя в кресле системного администратора (а общий стаж приближается уже годам к 15), столько вопросы офисной телефонии воспринимались мной строчкой из Californication калифорнийских же RHCP: hard core soft porn. Телефония всегда казалась параллельным измерением, в ее администрирование и настройку я старался не лезть. Точнее, вообще обходить все эти телефоновопросы по широкой дуге, скидывая все подобные задачи на «специально обученных людей».