Архив метки: quick guide

docker-compose для Swarm: docker stack

docker stack

Допустим, вы уже создали свой новенький Docker кластер и морально готовы заполонить своими приложениями. Такой вопрос: как именно вы будете это делать? Не руками ведь, через docker service create, правда? Кластер же большой, а приложение, которому он потребовался, явно будет состоять не из одного сервиса.

В обычном Docker была такая прекрасная штука как docker-compose, с которой можно было описать все контейнеры и их параметры в одном docker-compose.yml файле и потом запустить всё одним махом через docker-compose up. Вот бы можно было сделать так и в кластере.

Оказывается, можно. Читать далее docker-compose для Swarm: docker stack

Краткое введение в Docker Swarm mode

docker swarmDocker — прекрасен. С ним можно упаковать приложение по контейнерам, забросить их на случайный хост, и всё будет просто работать. Но на одном хосте особо не отмасштабируешься. Да и если хост прикажет долго жить, всё приложение отправится на тот свет вместе с ним. Конечно, для масштабирования можно завести сразу несколько хостов, объединить их при помощи overlay сети, так что и места больше будет, и возможность для контейнеров общаться останется.

Но опять же, как всем этим управлять? Хосты всё ещё могут отмирать. Как быстро определить, какой именно? Какие контейнеры на нём были? Куда теперь их переносить?

Начиная с версии 1.12.0 Docker может работать в режиме Swarm («Рой». В старых версиях был просто Docker Swarm, но тот работал по-другому), и потому способен решать все эти проблемы самостоятельно. Читать далее Краткое введение в Docker Swarm mode

Создаём образ для виртуальной машины с Packer

packer logoКак правило, создавать виртуальную машину с нуля — не совсем разумно. Всё-таки процесс долгий. Например, создание с нуля одного билд-сервера в моём мини-зоопарке занимает 40 минут. Это включает в себя установку пары-тройки SDK, всех доступных обновлений и сертификатов. Но в реальности, чтобы добавить новый, полностью сконфигурированный сервер в кластер, мне нужно минуты три. Как же так?

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

Так уж исторически сложилось, что мы пользуемся своим, домашним инструментом для подготовки образов, но во вселенной есть и бесплатные и open source. Например, Packer. Читать далее Создаём образ для виртуальной машины с Packer

Vagrant для автоматизации Windows хостов

Vagrant Windows

Использовать Vagrant для создания Consul кластера на линуксовых машинах было, конечно, здорово. Но как быть с виндовыми машинами? Всё-таки больше половины разработчиков разрабатывают в Windows. Так что смотреть, как кто-то создаёт пачки линуксовых VM,  — прикольно, но бесполезно.

Но есть хорошие новости: Vagrant поддерживает и Windows. Давно поддерживает. Конфигурация детища Майкрософт практически ничем не отличается от конфигурации пингвинов, но есть, как и во всём, связанным с Windows, некоторые нюансы. Читать далее Vagrant для автоматизации Windows хостов

Создаём Consul кластер в Vagrant

Vagrant logo

Для двух последних постов про Consul мне пришлось делать простую, но при этом нудную вещь: создавать Консул-кластер руками. Все три виртуальные машины. Дважды. То есть нужно было создать три VM, на каждую скачать Consul, распаковать, узнать IP адрес, скопировать файл настроек… В общем, скука.

С другой стороны, создание контейнеров в Docker — без пяти минут маленьких виртуальных машин — полностью автоматизировано. Есть Dockerfile для конфигурации одного контейнера, есть docker-compose для целой стайки. В общем, красота. Вот бы существовало что-нибудь похожее для конфигурации хостов целиком. Читать далее Создаём Consul кластер в Vagrant

Поиск и регистрация сервисов с Consul

Consul logoДопустим, есть у нас распределённое приложение, в которое входят два вида сервисов: web и db. Для большей надёжности они запускаются сразу в нескольких экземплярах, на разных хостах, иногда приходят в онлайн, иногда уходят, какие-то подвисли, какие-то ещё нет… В общем, хаос. Как в таком случае отдельно взятому сервису web отыскать себе живой db?

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

А если сервис «упал», или сети не стало, он же тогда не сможет себя удалить из списков… Ну тогда можно ввести ещё один сервис, который будет проверять, живы ли ещё все остальные. А если..

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

Но её и не обязательно решать самому, когда для этого уже есть инструменты. Например, Consul. Читать далее Поиск и регистрация сервисов с Consul

Kibana: окно в Elasticsearch

Kibana - логотипСегодня мы поговорим о последнем компоненте ELK стэка от Elastic — Kibana. Хотя Logstash отлично справляется обработкой логов и прочих потоков данных, а Elasticsearch поможет их сохранить, проиндексировать и запустить парочку поисковых запросов, ни у одного их них нету пользовательского интерфейса. А анализировать данные и искать закономерности из командной строки — удовольствие для любителей. Очень странных любителей…

И тут на помощь приходит Kibana.

Читать далее Kibana: окно в Elasticsearch

Обрабатываем логи в Logstash

Logstash лого

Итак, с Elasticsearch, гибридом гугла и NoSQL базы данных, мы разобрались, самое время перейти к следующей букве ELK стэка от Elastic — Logstash.

Читать далее Обрабатываем логи в Logstash

Краткое введение в Elasticsearch

ElasticsearchНасколько замечательно Grafana, Graphite и Prometheus справляются с численными данными мониторинга, вроде загрузки процессора по времени, настолько же они бесполезны для работы с логами. А ведь с теми приходится работать даже чаще, чем с метриками.

Инструментов для работы с логами тоже навалом, но сегодня мы посмотрим в сторону ELK стека от Elastic. А именно: Elasticsearch, Logstash и Kibana — хранилище/поисковик, обработчик данных и тулза для их визуализации. А начнём, естественно, с первой буквы этого трёх-буквенного алфавита — «E».

Читать далее Краткое введение в Elasticsearch

Собираем метрики приложения с Prometheus

PrometheusЕсть два концептуально разных подхода к сбору метрик приложения. Есть PUSH подход, при котором хранилище тихо сидит где-нибудь и надеется, что случайный провайдер метрик в него что-нибудь да положит. Например, Graphite сам по себе не занимается сбором данных. Он ждёт, что их доставит прямо к порогу кто-нибудь вроде collectd.

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

Prometheus использует PULL подход. Читать далее Собираем метрики приложения с Prometheus