Отримуємо безкоштовний SSL/TLS-сертифікат від Let’s Encrypt та налаштовуєм Nginx

Встановлення залежностей
Встановимо certbot і плагін для Nginx, щоб він сам налаштував потрібні хости в Nginx:

Continue reading «Отримуємо безкоштовний SSL/TLS-сертифікат від Let’s Encrypt та налаштовуєм Nginx»

Запуск контейнерів без оркестраторів

Все більше сучасного ПО нативно працює в контейнерах і часто навіть поставляється тільки у вигляді Docker образу. Коли у вас в інфраструктурі є оркестратор, наприклад Kubernetes, на який можна перекласти управління життєвим циклом контейнерів, тоді все добре і прекрасно. Але в процесі руху до цього світлого майбутнього іноді потрібно підтримувати гібридну роботу сервісів, що працюють на класичних віртуалках і в докері.

Continue reading «Запуск контейнерів без оркестраторів»

Ключові метрики в моніторингу

Сучасний моніторинг далеко пішов від стандартів п’яти-десятирічної давності, коли вважалося, що досить збирати прості метрики по доступності хоста і пару системних метрик по використанню процесора і пам’яті. Алерти в той час були також дуже прості. Наприклад, хост не відповідає за останню хвилину або завантаження процесора більше 95%.

В останні роки з ростом складності проектів, збільшенням динамічності інфраструктури і швидкості релізів з’явилася потреба збирати набагато більше метрик, і не тільки системних. Алерти також значно ускладнилися, тому що завантаження процесора — це не явний симптом проблем в роботі сервісу.

А коли метрик дуже багато, як зрозуміти, що ми збираємо всі необхідні метрики до того, як вони знадобляться? І які метрики аналізувати при розборі інцидентів?

Continue reading «Ключові метрики в моніторингу»

Монтування файлової системи. Fstab

Файл /etc/fstab є в будь-якому дистрибутиві Linux: він пов’язаний з монтуванням файлових систем. Впринципі структура файлу неважка, але поява багатьох файлових систем значно його ускладнили. Добре перевірте файл fstab, адже коли його невірно відредагувати і зберегти система може не завантажитись взагалі. Отже, спробуймо в ньому розібратись.

Continue reading «Монтування файлової системи. Fstab»

Використання Logical Volume Manager (LVM)

LVM (Logical Volume Manager) — менеджер логічних томів, додатковий рівень абстракції між фізичними (/dev/sda1, /dev/sda2 і  т.д.) та логічними томами ( /home, /root, /boot і т.д.), що значно підвищує гнучкість файлової системи. Використовуючи менеджер логічних томів, можна відносно легко змінювати розмір вже існуючих логічних томів (додавши новий HDD, можна просто пододавати місця на уже створені розділи, таким чином вирішивши проблему браку місця) чи робити бекапи без перевантаження/вимкнення/зупинки сервісів. Створення розділів з LVM не обмежене розміром фізичного диска, тобто один розділ може займати розмір декількох вінчестерів чи розділ може знаходитись частково на декількох HDD.

Отже схематично рівні знаходяться так:

Continue reading «Використання Logical Volume Manager (LVM)»

Запуск Elasticsearch + Logstash + Kibana в Docker Compose

У цій статті ми запустимо стек для зручної роботи з вашими логами. Для реалізації нам знадобиться: Elasticsearch — одне з кращих рішень по повнотекстовому пошуку і фільтрації даних, Logstash — зручний інтерфейс до Elasticsearch для запису логів (фільтрація, збір і трансформація), ну а Kibana — це веб-інтерфейс для візуалізації і читання даних з Elasticsearch .

Весь цей стек простіше запустити в контейнерах, які контролюватиме Docker Compose. Для цих цілей добре підходить проект docker-elk, в який входить все що нам потрібно, налаштуємо його і запустимо.

Встановлення Docker Compose і ELK

Крім docker.io і docker-compose нам ще знадобиться git:

Тепер склонуємо docker-elk:

Я використовую свій приватний форк, в якому перевизначені настройки для Elasticsearch і Logstash, рекомендую вам мати теж свій форк, а не використовувати оригінал. Так ви зможете зберігати свої зміни і ділитися ними зі своєю командою.

Настройка ELK

Щоб була можливість роботи з Docker від вашого користувача, необхідно додати в групу «docker»:

Щоб після перезапуску контейнера не загубилися дані, які зберігаються в Elasticsearch, рекомендую підключити свій Volume. Для цього треба додати запис в volumes секції elasticsearch:

Тепер якщо перезапустити контейнер дані підчепляться до вашого Elasticsearch автоматично.

Запуск ELK

Перейдемо в каталог «docker-elk» і запустимо команду, яка підніме нам всі 3 сервіси, об’єднані в одну мережу:

Якщо все запустилось без помилок, то зупинимо контейнери по Ctrl + C і нижче напишемо service-файл для systemd, щоб після перезавантаження системи він сам запускав і стежив за станом запущених контейнерів.

Налаштуємо Nginx

Спочатку створимо htpasswd-файл для Базової HTTP авторизації. Вкажіть свій USERNAME і за запитом введіть пароль:

Для прикладу хост для Elasticsearch буде «elastic.example.org», а хост для Kibana «kibana.example.org». Тепер створіть файл /etc/nginx/sites-available/elk.conf і розмістіть в ньому наступний зміст:

Як отримати SSL/TLS ключі читайте в моїй іншій статті
« Отримуємо безкоштовний SSL/TLS-сертифікат від Let’s Encrypt і налаштовуємо Nginx«.

Якщо з якої-небудь причини ви не хочете використовувати HTTPS, то можна використовувати ось такий конфіг:

Створимо симлінк для активації конфіга і перезапустимо Nginx:

Зайдемо браузером за адресою kibana.example.org, ви повинні побачити приблизно наступний інтерфейс:

Перейдіть в Management> Index Patterns і натисніть на кнопку Create Index Pattern, введіть «logstash- *» в поле Index pattern, а в якості значення для поля Time Filter field name вкажіть «datetime», таким чином ви налаштуєте шаблон для матчінга всіх даних від Logstash

Автозапуск ELK

Створимо service-файл в директорії systemd:

І внесемо наступний вміст:

Тепер активуємо і запустимо наш сервіс:

Ви також можете дізнатися статус, зупинити або перезапустити сервіс:

Не забувайте після кожної зміни service-файлу перезапускати systemd:

Установка и настройка Ansible на Ubuntu server 18.04

В данной статье мы рассмотрим как установить Ansible на Ubuntu server 18.04 и настроить playbook с автоматической установкой обновлений на Windows и Ubuntu хосты.
Также рассмотрим простой пример как поднять веб сервер с nginx,php7,mysql и поднять роли iis, fileserver на Windows хостах с помощью playbook Ansible.

Continue reading «Установка и настройка Ansible на Ubuntu server 18.04»

Мониторинг Docker контейнеров в Zabbix

Мониторить хочу количество контейнеров в состоянии Running/Crashed/Available. Для нескольких особо важных контейнеров нужно иметь возможность мониторить их статус по имени.
Размещаем в /etc/zabbix/scripts такой вот скриптец под именем docker_status.sh:

Continue reading «Мониторинг Docker контейнеров в Zabbix»

Выбор подходящей DevOps топологии

Почему я должен это читать?

Вы работаете в организации, которая хочет раскрыть преимущества работы по DevOps принципам. Вы слышали такие термины, как “платформенная команда” и “SRE” и понимаете, что значит фраза “you build, you run it”. Однако эти термины делают ваше погружение в DevOps только сложнее и теперь вам нужно еще и выбирать как организовывать вашу команду/команды. В этой статье приводится обзор трех наиболее подходящих DevOps топологий иобъясняется в каких условиях каждая из них применима.

Для примера, публикация “DevOps topologies” от Matthew Skelton дает отличный обзор различных организационных топологий. Эти топологии так или иначе применялись во многих компаниях в их поисках гибкости и ускорения с помощью DevOps. Несмотря на большое количество топологий, я считаю, что они являются вариантами этих трех видов:

  1. Все команды продуктовые. Каждая продуктовая команда делает все необходимое для работы их приложений, включая использование любых инфраструктурных компонентов, обычно облачных PaaS сервисов.
  2. Платформенные команды и продуктовые команды. Продуктовые команды используют платформенные/инфраструктурные сервисы, которые предоставляет платформенная команда/ы. Сервисы могут быть самыми разнообразными от инфраструктурных до мониторинга, CI и дашбордов.
  3. Платформенные команды, продуктовые команды и команда SRE. Эта топология основана на лучших практиках компании Google.Продуктовые команды могут получить помощь от SRE команд в эксплуатации их приложений, если необходимо и при условии, что приложение удовлетворяет стандартам, определенным SRE командами. SRE команды могут разделять on-call вместе с продуктовыми командами. Платформенная команда/ы предоставляют платформенные/инфраструктурные сервисы.

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

Continue reading «Выбор подходящей DevOps топологии»