DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.

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

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

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

Привет! Это очередной традиционый список книг, оказавшихся полезными за год. Сугубо субъективный, конечно. Но я серьёзно рассчитываю, что вы подскажете ещё классных штук почитать.



Думай медленно, решай быстро — Даниэль Канеман
Это самое волшебное, что случалось за последние годы в плане гиковой литературы. Эта штука последовательно открывает когнитивные искажения и учит настраивать мышление. При этом увлекательно. Вообще, подход к тому, что мышление — это набор техник, которые можно тренировать и оттачивать, он, наверное, правильнее подхода «это шаманство». Канеман в отличие от следующей в списке книги, показывающей особенности реверсивного мышления, не даёт новых техник — но показывает, где и какие ошибки мы совершаем при обычных процессах. Такой серьёзный дебаг мозга.

Многие игроки считают, что XIM Apex — это необнаруживаемое читерское устройство, которое портит видеоигры. Но для людей с нарушениями моторики это единственная возможность играть.

Мультиплеер игры Call of Duty получил репутацию «мясорубки». Игрок спаунится, делает один-два убийства, если он достаточно хорош, потом умирает, респаунится, и всё повторяется заново. Я уже очень давно не играл в Call of Duty на консолях, поэтому должен был стать лёгкой мишенью, но на самом деле я тащу.

Я играю в Call of Duty: WWII на Xbox One, и мой kill/death ratio (отношение убийств к смертям) выше среднего. В режимах Team Deathmatch и Kill Confirmed я занимаю второе место с K/D ratio 21/14, первое место с 18/15 и пятое место с 14/11. Я впервые играю в мультиплеер Call of Duty: WWII, то есть не знаю карту, у меня нет мышечной памяти оружия, его темпа стрельбы и отдачи. Но мне с лёгкостью удаётся вести бегущие к укрытиям цели. Когда враг подбирается ко мне, я способен легко направить на него прицел и первым убить его.

Я бы с радостью сказал, что это просто моё мастерство, но правда в том, что я пользуюсь устройством, позволяющим играть вместо стандартного контроллера с мышью и клавиатурой (и другими устройствами ввода, которые официально не поддерживаются). Обычно на консолях такое невозможно. Устройство под названием XIM Apex стоит 100 долларов и выглядит как USB-стик и концентратор, позволяющий подключить к Xbox One (или PlayStation 4) мои мышь и клавиатуру от PC, в то время как мои противники и напарники скорее всего играют обычными контроллерами Xbox One.

Всем привет. Я работаю ведущим системным администратором в ОК и отвечаю за стабильную работу портала. Хочу рассказать о том, как мы выстроили процесс автоматической замены дисков, а затем, как исключили из этого процесса администратора и заменили его ботом.

Эта статья является своего рода транслитерацией выступления на HighLoad+ 2018

Введение

В последнее время стремительно растет популярность Kubernetes — все больше и больше проектов внедряют его у себя. Я же хотел коснуться такого оркестратора, как Nomad: он отлично подойдет проектам, где уже используются другие решения от компании HashiCorp, например, Vault и Consul, а сами проекты не являются сложными в плане инфраструктуры. В данном материале будет инструкция по установке Nomad, объединения двух нод в кластер, а также интеграции Nomad с Gitlab.

В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

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



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Размышления о том, откуда берется желание сдать сертификацию AWS Solutions Architect Associate.

Мотив первый: «Топоры»

Один из самых полезных для любого профессионала принципов «Знай свои инструменты» (или в одной из вариаций «точи пилу»).

Мы в облаках уже давно, но до поры до времени это были просто монолитные приложения с базами, развернутые на инстансах EC2 — дёшево и сердито.

Но постепенно нам стало тесно в рамках монолита. Взяли курс на распил в хорошем смысле – на модуляризацию, а затем и модные нынче микросервисы. И очень быстро на этой почве «расцветают сто цветов».

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

• Клиентов в виде разнообразных приложений нашего продукта – от глухих уголков дремучего легаси до ультрамодных микросервисов на .Net Core.
• Очереди Amazon SQS, в которые складываются логи о том, что происходит с клиентами.
• Микросервис на .Net Core, который достает сообщения из очереди и отправляет их в Amazon Kinesis Data Streams (KDS). Имеет также Web API интерфейс и swagger UI как дублирующий канал и для ручного тестирования. Оборачивается в докеровский linux-контейнер и хостится под управлением Amazon ECS. Предусмотрен autoscaling на случай большого потока логов.
• Из KDS данные пожарными шлангами направляются в Amazon Redshift с промежуточными складами в Amazon S3.
• Операционные логи для девелоперов (дебаг-информация, сообщения об ошибках и т.п.) форматируются в приятный глазу JSON и отправляются в Amazon CloudWatch Logs

Работая с таким зоопарком сервисов AWS, хочется знать, что есть в арсенале и как это что-то лучше использовать.

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.

Введение

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

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

Уже больше 10 лет существуют и появляются разного рода профессиональные системы для подбора персонала. Это естественно. Специализированный софт уже разработан для многих отдельных профессий. Что касается рекрутинга, все понимают какие задачи помогает решить софт, от какой рутины и ошибок избавляет, но никто не понимает как измерить экономический эффект от его использования. Другими словами, компании могут посчитать сколько денег им обойдётся использование софта, но не понимают ROI или сколько денег принесёт или сэкономит софт. Слоганы типа “Закрывайте вакансии в 2 раза быстрее с (таким-то софтом)” — это от фонаря, это просто неправда.

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

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

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

Доброго всем дня!

Так уж сложилось, что в нашей компании в течении последних двух лет мы потихоньку переходим на микротики. Основные узлы построены на CCR1072, а локальные точки подключения компов на устройствах попроще. Само собой существует и объединение сетей по IPSEC tunnel, в данном случае настройка достаточно проста и не вызывает никаких трудностей, благо есть множество материалов в сети. А вот с мобильным подключением клиентов есть определенные трудности, вики производителя подсказывает, как использовать Shrew soft VPN client (по этой настройке все вроде понятно) и именно этот клиент использует 99% пользователей удаленного доступа, а 1% это я, мне стало просто лень каждый раз вводить логин и пароль в клиент и захотелось ленивого расположения на диване и удобного подключения к рабочим сетям. Инструкций по настройки Микротика для ситуаций, когда он находится даже не за серым адресом, а совсем за черным и может быть даже несколькими NAT в сети я не нашел. Потому пришлось импровизировать, а потому предлагаю посмотреть на результат.

Имеется:

1. CCR1072 как основное устройство. версия 6.44.1
2. CAP ac как домашняя точка подключения. версия 6.44.1

Главная особенность настройки в том, что ПК и микротик должны находиться в одной сети с одной адресацией, что и выдается основым 1072.

Обычно для мониторинга и анализа работы Nginx используют коммерческие продукты или готовые open-source альтернативы, такие как Prometheus + Grafana. Это хороший вариант для мониторинга или real-time аналитики, но не слишком удобный для исторического анализа. На любом популярном ресурсе объем данных из логов nginx быстро растет, и для анализа большого объема данных логично использовать что-то более специализированное.

В этой статье я расскажу, как можно использовать Athena для анализа логов, взяв для примера Nginx, и покажу, как из этих данных собрать аналитический дэшборд, используя open-source фреймворк cube.js. Вот полная архитектура решения:

TL:DR;
Ссылка на готовый дэшборд.

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

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

О чем, собственно, речь:

Всех, кому интересно, как из-за проектора, случайно направленного на стену, родилась навязчивая идея, которая, пройдя несколько этапов, вылилась в реализованный мини-проект по созданию некоего подобия домашнего кинотеатра – прошу под кат. Запаситесь чаем или кофе, захватите печенья и поехали!

Осторожно, трафик и длинный рассказ!

Наблюдаю за своим двухлетним сыном и диву даюсь, на сколько лихо он обращается с планшетами и телефонами. Невольно вспоминается известная шутка:

«- Мой ребенок в три года может сам включить компьютер и выбрать для себя мультик!
— А что делала ты в три года?
— Я ела песок…»

И действительно частенько задаюсь риторическим вопросом: «Это дети сейчас такие смышлёные?» или «Современные технологии настолько понятны и наглядны, что разобраться в них может даже карапуз?»

Современный ребенок получает от родителей свой личный первый телефон, планшет, часы-телефон в довольно раннем возрасте, лет с 5-6. Для чего? Что бы родитель смог всегда связаться со своим чадом. И как правило, и это естественно, модель, а вместе с тем и технические возможности остаются за выбором родителя. Родитель оплачивает сам аппарат, его обслуживание и в случае возникновения проблем (технических, программных) сам же занимается их устранением.

По данным ssh.com и Wikipedia, первая версия и реализация протокола SSH увидела свет в 1995 году. Задачей автора было разработать безопасную альтернативу использовавшимся тогда для удалённого администрирования rlogin, telnet и rsh. Любопытно, что появлению протокола SSH поспособствовал инцидент информационной безопасности, в результате которого злоумышленник собрал внушительную базу логинов/паролей от серверов, просто прослушивая университетскую сеть и выделяя пакеты аутентификации (пары логин/пароль в них передавались в незашифрованном виде).

Протокол быстро завоевал популярность и после длительного периода доработок и улучшений был стандартизован IETF в 2006 году. С тех пор он успел стать де-факто стандартом для удалённого управления системами с текстовой консолью. Помимо собственно текстовой консоли в протоколе предусмотрена масса других полезных функций, таких как передача файлов и переадресация портов. Именно о переадресации портов (port forwarding) и её не слишком очевидном применении пойдёт речь в этой статье.

К Load Balancers в системах оркестрации (Kubernetes, Nomad и других) предъявляется больше требований, чем просто балансировка нагрузки. Во-первых, Load Balancer должен уметь читать каталог со списком сервисов, на которые необходимо перенаправлять трафик (или, как вариант, давать возможность сервисам регистрироваться на включение их в трафик). Во-вторых, делать это динамически, т.к. системы оркестрации в любой момент могут увеличить или уменьшить количество реплик сервисов, или переместить их на другие адреса в сети. И, в-третьих, делать это без остановки трафика.

В сегодняшнем сообщении я опишу работу с двумя Load Balancers — Traefik и HAProxy. Эти Load Balancers имеют возможность работать с внушительным списком средств оркестрации. В примерах будет описана работа с системой оркестрации Nomad.

Было бы круто, если бы развертывание в формате копи-пейст осталось в прошлом, но, увы, дела обстоят иначе. Бывает, разработчикам предпочтительней именно такой метод поставки. Хоть сейчас пиши статью о том, почему это не есть гуд, но вы и без меня все знаете. С тенденцией к бессерверной (serverless) архитектуре пайплайны CI/CD играют важную роль в поставке приложений. Я еще писал о них в статье "3 лучших совета для вашего следующего бессерверного проекта".

Темой CI и CD я интересуюсь давненько, а впервые столкнулся с ней несколько лет назад — благодаря TeamCity. В настоящее время TeamCity по-прежнему используется для большинства наших пайплайнов CI/CD. Работает TeamCity прекрасно, ничего против не имею, но я всегда стремлюсь улучшить работу. Например, было бы хорошо собирать пайплайны в виде кода — это одно из направлений, в которых TeamCity не так хорош.

Инструменты интеграции и поставки на AWS я изучил какое-то время назад, и, хотя мы используем CodeDeploy для другого проекта, который работает на EC2, бессерверный проект я с ними еще не развертывал. Ознакомившись с инструментами повторно, я обратил внимание вот на что: теперь есть встроенная функция интеграции для развертывания CloudFormation и Lambda, предположительно, на основе SAM AWS; мы используем serverless framework, — она генерирует шаблоны CloudFormation, но с инструментами AWS она “из коробки” не работает.

Raspberry Pi — невероятно популярное устройство, известное своей доступностью, универсальностью, возможностями и активным сообществом. Легко найти фанатские сайты и статьи, но большинство людей не знают о его слабых местах, пока сами не пострадают от них и не поищут информацию на форумах.

Постараюсь рассказать о некоторых вопросах, с которыми я столкнулся лично, а также о некоторых типичных проблемах, которые чаще всего появятся у людей, ничего не подозревающих об этом. И, наконец, почему я не рекомендую Pi для некоторых приложений, в частности, NAS-услуг, таких как NextCloudPi и Open Media Vault. Надеюсь, это сэкономит мне время, чтобы не повторять всё это на форумах.