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

Автоматизация инфраструктуры в GCP с Deployment Manager

deployment manager

Даже не знаю, как так получилось, но даже регулярно пересекаясь с Google Cloud Platform последние два года, я абсолютно упустил тот факт, что в GCP есть свой собственный инструмент для автоматизации развёртывания инфраструктуры: создания виртуальных машин, аккаунтов, сетей и прочего. Но он реально есть! В главном меню даже есть ссылка.
Инструмент называется Deployment Manager и он может автоматически создать практически всё, что есть Google Cloud. Прямо с одной команды. Так как DM разрабатывал Гугл, то у первого весьма извилистая кривая обучения, не всегда свежая документация, и иногда неочевидные логика. Но штука работает. Так как до этого я в основном автоматизировал развёртывание приложений от хоста и вверх — через всякие VagrantAnsibledocker-compose или kubectl, по посмотреть, как делать первую половину задачи — от хоста и вниз, — будет весьма интересно.

Читать далее Автоматизация инфраструктуры в GCP с Deployment Manager

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

helm пакетный менеджерЧто-то я давно ничего не писал о Kubernetes. А ведь в нём куча всего интересного происходит. Вот, например, посмотрели мы в прошлый раз как создавать k8s объекты через YAML конфигурацию, и было то хорошо. Но неудобно. Файлов же может быть много, копировать их туда-сюда тоже то ещё удовольствие. А если использовать менеджер пакетов helm, то как бы всё приятно сразу становится. Читать далее Краткое введение в helm

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

etcd лого

Такое чувство, будто в последние месяцы я черезчур уж сильно сосредоточился на дебаггинге и .NET Core, и как-то подзабил на топик, ради которого весь этот блог и затевался — DevOps и распределённые приложения. Ошибку осознал, и сегодня мы посмотрим на что-нибудь более релевантное. Например, etcd.

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

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

Отправляем .NET Core метрики в Graphite через StatsD

.NET Core StatsD

Уже прошло больше года с тех пор, как я подключил кусок JavaScript к collectd плагину и начал собирать данные мониторинга с нашей CI, чтобы потом хранить их в Graphite. И знаете что? Оно до сих пор работает. Даже JavaScript’овая часть. Но настали времена, когда мне нужно будет собирать метрики с .NET Core сервисов, и, чувствую, связкой JavaScript + collectd я уже не отделаюсь.

По идее, проблем быть не должно. В Graphite ведь можно отправлять данные хоть по TCP в виде текста, так что сервисы вполне могут заняться этим самостоятельно. Но можно сделать даже ещё проще. Читать далее Отправляем .NET Core метрики в Graphite через StatsD

Однократные задачи в Kubernetes

Задачи в KubernetesПока что все примеры, что я делал для Docker Swarm и Kubernetes постов, строились вокруг какого-нибудь сервиса: веб-сервера, очереди сообщений или шины сообщений. В принципе, оно и не удивительно, весь тот же Docker Swarm построен вокруг концепции сервисов. Да что там Swarm, сами «микро-сервисы», из-за которых мы контейнеры в облака забрасываем, ни о чём не говорят?

Но не всё есть «сервис» в облаках. Есть и эпизодические задачи: рутинное обслуживание, запланированные задачи, конечные вычислительные таски — всё, у чего есть начало и вполне определённый конец.

Читать далее Однократные задачи в Kubernetes

Разбираем Kubernetes пример

Kubernetes пример

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

Читать далее Разбираем Kubernetes пример

Настройка кластера машин с Ansible

Настройка кластера Ansible

Мне очень понравилось, как было просто конфигурировать виртуальную машину с Ansible. Вот теперь думаю, а что, если машин было бы несколько? Ведь оригинальный пример был о нескольких машинах: один Consul сервер и два рабочих агента. Сервер уже готов, так что будет интересно довести пример до конца. Так что приступим.

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

Читать далее Настройка кластера машин с Ansible

Конфигурация VM с Vagrant и Ansible

Ansible vagrant

А я тем временем продолжаю выискивать, чем бы ещё автоматизировать настройку хостов. До сих пор я пользовался связкой Vagrant + bash/PowerShell для линуксовых или виндовых хостов, но каким-то странным образом пропустил тулзу, которая подходит под это дело лучше, чем просто скриптовать всё подряд, — Ansible. Она существует уже лет пять, и, как я заметил, превратилась практически в синоним фразы «автоматическая конфигурация». Сегодня, наконец, я её пожмякаю. Посмотрим, так ли уж Ansible удобнее, чем старый добрый bash.

Читать далее Конфигурация VM с Vagrant и Ansible

Что же всё-таки такое kubernetes

kubernetesKubernetes (он же K8s) — это ещё одна инструментина для управления контейнерами в кластере. Она решает, в какой части кластера контейнер будет запущен, следит, чтобы его запрошенная конфигурация («запущен», «пять реплик») выполнялась, чтобы у контейнера была сеть и айпишка, настроен доступ извне (если нужно), обновления приходили в нужном порядке, и т.п.

Изначально Kubernetes разрабатывался Гуглом, но те передали его в open source, так что теперь K8s свободен, как бесплатное пиво. Читать далее Что же всё-таки такое kubernetes

Проверка состояния контейнера в Docker

Проверка состояния контейнераКаким-то непонятным образом я пропустил новость о том, что начиная с версии 1.12 Docker контейнерам можно навешивать проверку состояния. И речь тут идёт не о проверке, запущен ли ещё контейнер, а о том, делает ли он всё ещё то, ради чего создавался. Например, мы можем проверять, отзывается ли веб-сервер внутри контейнера на входящие запросы, вменяемое ли количество памяти он использует, встречаются ли в логах фразы вроде «epic fail!!!»… Много чего можно проверить, ведь проверка делается через запуск какого-нибудь стороннего скрипта или приложения, а её результат зависит от кода, с которым это приложение завершилось.

В обычном режиме контейнер, последние несколько проверок которого оказались «так себе», получит атрибут «unhealthy», в Docker events появится соответствующая запись (health_status), и на этом история закончится. Но если речь идёт о Swarm режиме, то проблемный контейнер без лишних разговоров усыпят и автоматически запустят новый. Вот так жестоко. Читать далее Проверка состояния контейнера в Docker