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

Автоматизация инфраструктуры в 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

Про собеседование в Нью-Йорке

TImes Square

Продолжая тему поиска новой работы, я-таки слетал в Нью-Йорк на финальный этап собеседования. В тот самый инвестиционный стартап, про который упоминал раньше. Забесплатно, в хорошую погоду и на Манхэттен — всё, что так любо сердцу белорусского эмигранта. То есть мне. Читать далее Про собеседование в Нью-Йорке

Дебаггинг .NET Core приложения из командной строки в Linux

дебаггинг из командной строки

Миллион лет тому назад, ещё в университете, я делал курсовую по Unix на C++ и в какой-то момент мне пришлось дебаггить всё это третьекурсное великолепие из командной строки. Это было офигенно. И ощущение тотальной гикнутости происходящего, и поразительная эффективность процесса. Оказывается, в отсутствие UI отвлекаться больше не на что, и дебаггинг становится удивительно сфокусированным действом.

С тех пор как у .NET Framework появился кросс-платформенный брат близнец .NET Core, я всё выжидал, как бы это повторить давнишний подвиг ещё раз, но уже для C#, и недавно это-таки случилось. Не совсем гладко, но тем не менее. Давайте смотреть.

Читать далее Дебаггинг .NET Core приложения из командной строки в Linux

Отправляем проактивные сообщения с Microsoft Bot Framework

Futurama восстание роботов

Я тут подумал ещё раз о том боте, который вроде как должен будет вместо меня следить за ненадёжными тестами, и внезапно понял одну штуку. Все сценарии, с которыми я игрался, были так или иначе построены на инициируемых пользователем диалогах. Тот шлёт сообщение, бот отвечает, шлёт ещё одно, бот опять отвечает, и т. п. Но в моём случае, получив задание, бот будет работать молча, и, лишь заметив что-нибудь любопытное, должен начать беседу сам. Microsoft называет такие сценарии проактивными сообщениями, и вот как это можно провернуть на Microsoft Bot Framework. Читать далее Отправляем проактивные сообщения с Microsoft Bot Framework

Разбираемся с Microsoft Bot Framework

Маленький Бендер

Так как конторский CI/CD висит на мне, то натурально я заинтересован в том, чтобы билд оставался зелёным. Не то, чтобы я тут же бросался к каждому упавшему тесту, но за ненадёжными точно присматриваю.

Когда ветка master держится красной чересчур уж долго, вот какие штуки начинают творится с её упавшими тестами:

  1. Ищем историю падений теста в нашем Google BigQuery (select Name, Result, count(*) from TestResults_...).
  2. Если исторически тест вел себя в большей степени как генератор случайных результатов, и в меньшей степени как тест, создаём для него тикет.
  3. Добавляем тест в игнор и указываем в качестве причины вновь созданный тикет.
  4. Находим, кто же написал это непотребство (git blame) и вешаем кейс на автора.

В общем, очень просто. И ещё очень скучно. Тестов-то у нас много. Я бы автоматизировал это всё, но есть одно небольшое «но» — не всегда можно определить, кто же текущий «владелец» теста. Программисты же увольняются, рефакторят чужое, ну и ломают git’овскую историю по праздникам. Я думал заморочиться и выкатить какое-нибудь machine learning решение для этого, но то попахивает перебором. А вот написать бота выглядит как-то более выполнимо. Он бы мониторил тесты, отслеживал статистику, и когда ему что-то непонятно, вроде на кого повесить кейс, спрашивал бы меня.

Осталось только понять, как этих ботов делают. Читать далее Разбираемся с Microsoft Bot Framework