Архив рубрики: О программировании

Настраиваем Internal Load Balancer через Deployment Manager

Прикольно, как некоторые относительно продвинутые инструменты и фрейморки стараются выглядеть проще и понятнее, и в результате превращаются во что-то ещё более зубодробительно невнятное. Давным-давно так было с git, когда мне пришлось перейти на командную строку и прочитать ‘Pro GIT’ целиком, чтобы гитовские GUI клиенты обрели хоть какую-то логику. Та же ерунда позже получилась с kubernetes, когда с более «простыми» kubectl run и kubectl expose было совсем непонятно, что же происходит на самом деле, в то время как перейдя на уровень ниже, к kubectl apply и YAML конфигурациям, всё стало на удивление простым логичным.

И вот теперь пришла очередь гугловых балансировщиков нагрузки — GCP load balancers. Глядя на все эти чекбоксы и кнопочки в гугловых визардах, я иногда чувствую себя младшим бухгалтером советского колхоза. С одной стороны, непонятно, что же именно я делаю. С другой стороны, непонятно — зачем. А вот как только создашь всё руками через файлы конфигурации, так всё снова кажется логичным. Читать далее Настраиваем Internal Load Balancer через Deployment Manager

Расширяем Deployment Manager через провайдеры типов

Прошло всего 2 недели после того, как я жаловался, что Гугловый Deployment Manager не поддерживает свежую версию гуглового же Cloud Functions API, как случайно наткнулся на фичу, которая может это обойти. Прикол в том, что если у вас есть RESTful CRUD API и OpenAPI спецификация для него, то такой апи можно зарегистрировать в DM в качестве провайдера типов (Type Provider) и пользоваться им так же как и любым другим типом. Cloud Functions API v1 полностью подходит под эти требования, так что его можно регистрировать и пользоваться свежайшим апи столько, сколько душе угодно.

Читать далее Расширяем Deployment Manager через провайдеры типов

Пара багов (или фич?), которые я умудрился найти в GCP

баги в GCPРаз уж приходится в последнее время работать с Deployment Manager из Google Cloud Platform, то как-то тяжело не заметить, что гугл иногда…  делает баги. Серьёзно. Не то, чтобы очень много, я определённо сделал больше, но достаточно, чтобы время от времени сталкиваться с чем-то загадочным. За последний месяц я их нашёл штуки четыре. Ещё что-то нашли мои товарищи по проекту, так что баги действительно есть. Вот, например, что мне попалось.

Читать далее Пара багов (или фич?), которые я умудрился найти в GCP

Python шаблоны в гугловом Deployment Manager

Вот допустим у меня есть файл конфигурации для гуглового Deployment Manager, который создаёт виртуальную машину из убунтового образа, даёт ей временную внешнюю айпишку и отправляет в облако. Ну примерно такой:

А что делать, если я захотел пять таких? Ну или просто похожих. Это что, теперь копировать эту конфигурацию пять раз, меняя по паре строк вроде имени, образа и, возможно, зоны?

Но нет, Deployment Manager поддерживает Jinja и Python шаблоны, так что копипасты можно избежать. Давайте смотреть как это делается, например, на Питоне. Читать далее Python шаблоны в гугловом Deployment Manager

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

deployment manager

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

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

Новые технические посты и летающие роботы

смена парадигмы

Когда я запускал технический раздел своего блога, то первоначальная задумка была писать в основном о том, с чем я работаю. Даже список из первых пятидесяти тем составил. Первая половина была про JavaScript — всё-таки большая часть работы проходила именно в нём. А вторая — про NoSQL базы данных, потому что.. ну как раз как раз книгу про них дочитывал.

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

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

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

Сказ о .NET Core и ошибке его package downgrade

vimdiffЗа последние шесть или около того недель Майкрософт, конечно, отличились: выпустили целую кучу версий .NET Core 2.1 SDK (Preview 2, Release Candidate 1, Early Access, RTM), которые мы все и попробовали. Так как всё происходило в спешке, к выходу финальной версии мой кластер CI серверов выглядел как зоопарк. Там были RC1 сервера, выглядевшие как Early Access. EA сервера, пытающиеся быть похожими на RTM. Ну как и не упомянуть тот единственный RTM сервер, который старался быть похожим на всех. Ну а что, бывает.

Проблемы начались тогда, когда я попытался разгрести этот бардак и поудалять пререлизные машины, поубирать P2, RC1 и EA SDK теги с релизных веток, ну и выкатить свежие билд-сервера с новейшим и стабильным .NET Core SDK 2.1 на них. Ну и ничего, естественно, на них не скомпилировалось.

Читать далее Сказ о .NET Core и ошибке его package downgrade

Service mesh, работающий через iptables

Воображаемое распределённое приложение подключённое к service mesh
Воображаемое распределённое приложение, подключённое к service mesh

В общем, в прошлый раз я упомянул, что другой, совместимый с Kubernetes сервис меш — Conduit, работает по иному принципу. В отличие от Linkerd, он не устанавливает прокси на каждую машину и не заставляет клиентов общаться с ним, задав переменную окружения http_proxy. Этот кадр мало того, что подключает клиентские сервисы к мешу по-одному, так ещё и совсем другим способом. Мне нравятся такие идеи, ставящие всё с ног на голову, так что я решил разобрать Conduit на части и посмотреть, что же там у него внутри. Читать далее Service mesh, работающий через iptables

Играем в service mesh

service mesh на хостНамедни я высматривал, с чем бы таким новым поиграться, и случайно наткнулся на штуку под названием service mesh. Непонятно, правда, как нормально перевести её на русский. Сервисная сеть? Сервисный меш? Служебный мышь? Но даже с учётом того, что концепция мешей вряд ли принесёт мир всему миру, задумка действительно интересная. Давайте смотреть. Читать далее Играем в service mesh