DevOps

Закон Парето (принцип Парето, принцип 80/20) — «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
Wikipedia

Приветствую тебя, дорогой читатель!

Моя первая статья на Хабр посвящена простому и, надеюсь, полезному решению, сделавшим для меня сбор метрик в Prometheus с разнородных серверов удобным. Я затрону некоторые подробности, в которые многие могли не погружаться, эксплуатируя Prometheus, и поделюсь своим подходом по организации в нём легковесного service discovery.

Для этого понадобится: Prometheus, HashiCorp Consul, systemd, немного кода на Bash и осознание происходящего.

Если интересно узнать, как все это связано и как оно работает, добро пожаловать под кат.

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ
Как стать DevOps инженером за полгода или даже быстрее. Часть 5. Развертывание



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

Готовы к запуску?

Итак, у нас есть наш код, написанный, упакованный и где-нибудь развернутый. Я решил проигнорировать развертывание кода как неизменяемых артефактов машины (например, EC2) и сосредоточиться на контейнерах. Почему?

18 мая 2020 года компания GlobalSign анонсировала платформу PKI нового поколения под названием Atlas для автоматизации управления цифровыми сертификатами.

Это универсальная система на новом движке, куда в течение года будут добавлены все существующие решения GlobalSign по автоматизации управления сертификатами. Первым добавлен автоматизированный шлюз регистрации Automated Enrollment Gateway (AEG), который позволяет быстро и автоматизированно выпускать цифровые удостоверения и управлять ими.

Atlas послужит компаниям, которые сейчас вынуждены пользоваться решениями на основе, обычно, Microsoft CA и которым необходим собственный частный центр сертификации. Например, для регистрации каждого устройства Интернета вещей, оформления удостоверений на сотрудников или сертификатов на компьютеры, чтобы они могли безопасно и доверенно коммуницировать друг с другом и за пределами сети. Платформа GlobalSign Atlas предложит полностью готовое универсальное решение для таких ситуаций, чтобы компании сосредоточились на основном бизнесе, а не выделяли ресурсы на внедрение криптографии и PKI своими силами, рискуя информационной безопасностью.

Эта статья посвящена проблемам работы DNS в Kubernetes, с которыми столкнулась наша команда. Как оказалось, иногда проблема лежит гораздо глубже, чем кажется изначально.

Вступление

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

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

11 часов, начало рабочего дня. В системе мониторинга не хватает части сообщений от одного из приложений.

Качественные тесты обеспечивают скорость и стабильную работу мобильных приложений, но разнообразие устройств, операционных систем и их версий раздувает тестовые фермы, увеличивает стоимость разработки и отнимает много времени и сил. В этой статье мы расскажем, как сократить издержки тестирования с помощью облачного сервиса Visual Studio App Center, который объединяет более четырех тысяч устройств с разными ОС, и упростить дистрибуцию с помощью платформы Azure DevOps.

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ

Освежим память

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



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

Онлайн-митап состоится 26 мая в 19:00.

Вячеслав Швецов из DINS расскажет, какие процессы происходят при эволюции систем мониторинга, и подробнее остановится на архитектурных особенностях Prometheus и Zabbix. Глеб Гончаров из FunBox поделится опытом сборки логов Nginx с хранением в ClickHouse. Оба спикера приведут примеры из практики и ответят на вопросы аудитории.

Регистрируйтесь по ссылке, чтобы присоединиться.

Под катом — информация о спикерах и подробная программа.

Spyglass by Shorai-san

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

Это дает ряд преимуществ: просмотр определенных подмножеств данных, определение метрики с точки зрения ее дочерних элементов и установление соотношений между метриками.

Команда Mail.ru Cloud Solutions перевела статью, в которой рассматриваются свойства пространств имен метрик, позволяющие постепенно увеличивать детализацию запросов и переходить к подмножествам данных, а также просматривать метрику с точки зрения метрик, из которых она состоит. Многие из этих концепций вам знакомы, так как они реализованы в нативных решениях для облачного мониторинга, таких как Prometheus и DogStatsD.

Это доклады с Magento Meetup Kharkiv Online, где разработчики поделились опытом и рассказали, что такое Magento Cloud, чем хорош модуль Enhanced media gallery и как избежать ошибок в инфраструктуре, которые могут положить сайт в самый разгар сезона продаж.

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

Расшифровка доклада 2016 года Виталия Левченко "Prometheus мониторинг микросервисных приложений"

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

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

Фабиан Рейнарц (Fabian Reinartz) — разработчик программного обеспечения, фанат Go и любитель решать сложные задачи. Также он мэйнтейнер Prometheus и соучредитель Kubernetes SIG instrumentation. В прошлом он был production-инженером в SoundCloud и возглавлял группу мониторинга в CoreOS. В настоящее время работает в Google.

Бартек Плотка (Bartek Plotka) — инфраструктурный инженер в Improbable. Увлекается новыми технологиями и проблемами распределенных систем. Имеет опыт низкоуровневого программирования в Intel, опыт контрибьютора в Mesos и production-опыт SRE мирового масштаба в Improbable. Занимается улучшением мира микросервисов. Три его любви: Golang, open source и волейбол.

Глядя на наш флагманский продукт SpatialOS, вы можете догадаться, что для Improbable нужна высокодинамичная облачная инфраструктура глобального масштаба с десятками кластеров Kubernetes. Мы были одними из первых, кто начал использовать систему мониторинга Prometheus. Prometheus способен отслеживать миллионы метрик в реальном времени и поставляется с мощным языком запросов, позволяющим извлекать необходимую информацию.

Простота и надежность Prometheus является одним из основных его преимуществ. Однако, пройдя определенный масштаб, мы столкнулись с несколькими недостатками. Для решения этих проблем мы разработали Thanos — проект с открытым исходным кодом, созданный компанией Improbable, для бесшовной трансформации существующих кластеров Prometheus в единую систему мониторинга с неограниченным хранилищем исторических данных. Thanos доступен на Github здесь.

Minio это простое, быстрое и совместимое с AWS S3 хранилище объектов. Minio создан для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии. В minio также поддерживается распределенный режим (distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.

Цель этого поста настроить minio так чтобы каждый юзер мог работать только со своим bucket.

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

Использование review-окружений в CI/CD может быть весьма полезным, причём как для разработчиков, так и для системных инженеров. Давайте для начала синхронизируем общие представления о них:

1. Review-окружения могут создаваться из отдельных веток в Git-репозитории, определяемых разработчиками (так называемые feature-ветки).
2. Они могут иметь отдельные экземпляры СУБД, обработчиков очередей, кэширующих сервисов и т.п. — в общем, всё для полноценного воспроизведения production-окружения.
3. Они позволяют вести параллельную разработку, значительно ускоряя выпуск новых функций в приложении. При этом каждый день могут потребоваться десятки подобных окружений, из-за чего скорость их создания критична.

На пересечении второго и третьего пунктов зачастую и возникают сложности: поскольку инфраструктура бывает очень разной, её компоненты могут деплоиться долгое время. В это затрачиваемое время, например, входит восстановление базы данных из уже подготовленного бэкапа*. Статья — о том, каким увлекательным путем мы однажды отправились для решения такой проблемы.

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

В данной статье я расскажу как настроить source-based и policy-based routing для внешней сети вашего кластера.

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

Безопасность — это защита объектов и интересов от угроз. Когда кажется, что с ней всё хорошо, в интернете появляется много интересного: списки e-mail и телефонов из незащищённой базы данных крупных магазинов, записи колл-центров некоторых операторов, логины и пароли производителей оборудования из открытого репозитория или данные миллионов кредитных карт клиентов крупных банков.



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

Мона Архипова — соучредитель и COO в sudo.su (МИРЦ) и vCISO Anna Systems. Ранее работала на различных руководящих и экспертных должностях в IT и безопасности. Всё ещё играющий бизнес-тренер.

Всем привет! Меня зовут Тимур Гильмуллин, я заместитель руководителя отдела технологий и процессов разработки в компании Positive Technologies, занимаюсь автоматизацией и внедряю идеи DevOps. Сегодня расскажу, как я попал в профессию, как в нашем отделе мы видим карьеру DevOps-инженера, что такое карта компетенций, и как она помогает обеспечивать рост сотрудников.

Сделал dashboard Postgresql overview для postgres_exporter.

Чем отличается от других дашбородов postgres_exporter?

Я объединил все другие дашборды postgres_exporter в один.

Этот дашборд показывает общую информацию по кластеру.

Скриншоты и краткая инструкция по установке: postgresql, postgres_exporter, prometheus, grafana под катом.

DevOps-инженеры — это многопрофильные специалисты, которые умеют автоматизировать процессы и знают, как работают разработчики, QA и менеджеры. Они умеют программировать, быстро осваивают сложные инструменты и не теряются перед незнакомой задачей. DevOps-инженеров мало — им готовы платить по 200–300 тысяч рублей, но вакансий всё равно много.

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

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии



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

Несколько лет назад, для закрытия одного их предметов мне довелось перевести данный букварь. Де-факто этот вариант стал официальным переводом. Но развитию этого перевода мешает, тот факт, что он был написан в Google Drive и закрыт на редактирования. Сегодня я уделил время на переформатирования всего этого текста в MD формат с помощью редактора Хабра, с радостью публикую здесь и вскоре отдам текущим контрибьюторам.

Словарь

Node — нода — узел с каким либо ресурсом
Content — контент — данныe
Traffic — трафик — запрос/ответ, данные которые передаются от сервера клиенту и наоборот
Hardware — железо — аппаратная часть
Instance — инстанс — созданный объект какой либо сущности. Например инстанс сервера API
Headers — хедеры — заголовки (как правило TCP пакета, но может быть и HTTP запроса)

---