Блог DevOps → Полезные материалы по DevOps | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Разработчик на Spring Framework
-5%
iOS Developer. Professional
-8%
Golang Developer. Professional
-6%
Базы данных
-12%
Agile Project Manager
-5%
C# ASP.NET Core разработчик
-6%
Android Developer. Basic
-10%
React.js Developer
-4%
MS SQL Server Developer
-8%
Scala-разработчик
-8%
Java Developer. Basic
-8%
Алгоритмы и структуры данных
-9%
Разработчик IoT
-13%
PostgreSQL
-8%
Подготовка к сертификации Oracle Java Programmer (OCAJP) Python Developer. Professional Разработчик программных роботов (RPA) на базе UiPath и PIX Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов Node.js Developer Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes iOS Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool"
Инфраструктура
DevOps практики и инструменты
-12%
Базы данных
-12%
Network engineer. Basic
-10%
Network engineer
-4%
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Administrator Linux. Professional
-6%
Разработчик IoT
-13%
Основы Windows Server Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP NoSQL Супер-практикум по использованию и настройке GIT Супер-интенсив «СУБД в высоконагруженных системах» Экспресс-курс «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02
Trunk-based Development

DevOps_Deep_11-5020-1f219d.09_site.png

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

Ansible: формируем переменные на всех хостах с Custom facts

DevOps_Deep_21.08_site.png

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

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

Модуль setup и Gathers facts в Ansible

DevOps_Deep_17.08_Site.png

В системе управления конфигурациями Ansible есть специальный модуль setup. Он выполняется первым, собирая информацию (Gathers facts) обо всех подключённых узлах (нодах). При выполнении модуля на хосте он собирает разные факты, включая дисковое пространство, версию и тип операционной системы, hostname машины, количество доступной памяти, архитектуру процессора, IP-адреса, сетевые интерфейсы и их состояние.

Trytravis: тестируем без коммитов и пушей в удалённый репозиторий

DevOps_Deep_LAST_11.07_1_site.png

TravisCI – популярный распределённый веб-сервис для сборки и тестирования кода. Многие используют его, т.к. для OpenSource-проектов он доступен бесплатно и обеспечивает удобную интеграцию с GitHub.

При этом отлаживать билды в Travis не всегда удобно. Для упрощения данной задачи Seth M. Larson разработал прекрасную утилиту trytravis. Она позволяет тестировать изменения в репозитории без коммитов и пушей в удалённый репозиторий.

Системы логирования

VKDevOpsDeep.png

К логам сервисов и приложений обращаются абсолютно все: администраторы читают логи, чтобы выяснить причину сбоя сервиса; программисты ищут в них исключения; «безопасники» проверяют, что в них нет каких-нибудь необычных записей, характерных для взлома.

Пока у вас один сервер, всё хорошо: каждый специалист может открыть файлы в vim и посмотреть, что ему нужно. А что если серверов у вас много? А что если по этим серверам разбросаны кучи сервисов и приложений? Как людям читать логи со всего этого?

Придётся же читать логи каждого сервиса, каким-то сложным методом находить логи того запроса, что сломался, и искать где именно что-то пошло не так. Как решить эти проблемы?

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 2

DevOpsDeep11.05_Site.png В первой части мы обсудили проблемы, которые решаются с помощью IaС-инструментов. Определив задачи и результаты их решения, в этой заметке я хотел бы рассказать о том, как можно управлять миграциями с помощью liquibase. Есть два способа: 1. Описывать и запускать их при помощи CLI liquibase в процессе деплоя; 2. Описывать миграции вместе с кодом приложений и запускать их применение во время запуска приложений.

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 1

DevOpsDeep3Site.png

Используя IaС-инструменты, мы можем поднимать и деполитизировать окружения с необходимыми версиями приложений по кнопке. Но ряд приложений помимо изменений кода требуют изменения структуры данных или самих данных в БД. Работать с ручным выполнением миграций в рамках процесса непрерывной поставки неэффективно.

Zabbix: мониторинг дисковых хранилищ DELL MD36XX

DevOps_Deep_10.07_SITE.png

Задача

Необходимо настроить мониторинг нагрузки на дисковые хранилища DELL MD36XX. Есть проблема – полки не умеют отдавать данные по snmp. Кстати, подобные проблемы также встречаются у хранилищ IBM, HP и других вендоров.