Офигеть вы шустрые!

(ушел готовить материал)

Я вам так скажу, готовить простенький мастер-класс занятие очень увлекательное. Приходится вспоминать многое из того, что не трогал довольно давно. %)

Сложнее всего начать. Поскольку в Нидерах сейчас аномальная жара, просто заставить себя сесть за работу невозможно, на ноуте так вообще можно яичницу жарить.
Для тех, у кого проблемы с мотивацией или не знаете с чего начать проект, пусть даже небольшой, есть полезный совет из прекрасной книжки “A subtle art of not giving a fuck”.

Совет очень простой: Сделайте что-нибудь.

Вот именно так - что-нибудь. Хоть что-нибудь. Ну хоть малюсенькое что-нибудь.
Когда вы смотрите на задачу или проект, кажется, что работы там настолько много, что непонятно с какой стороны копать. Тут в принципе и кроется суть - начинайте копать с любой стороны.

Ведь мне для мастер-класса что нужно? Найти платформу для вебинара, надо подготовить окружение-песочницу, нарисовать презентацию, написать пару местных приложений. Глядишь на все вместе - кажется задачей на пару спринтов.
А как садишься описывать конфигурацию вагрантовых коробок, там уже и ансиблевые плейбуки прут, и на вебинар.ру зарегистрировался, и приложения решил не писать, а брать готовые (благо на Github всяких hello-world навалом).

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

Если у вас есть животрепещущие вопросы, вы знаете куда писать. ;)

Я начинаю понимать любовь творческой интеллигенции к столице Франции. Город впитал в себя многолетнюю культуру государства, и гуляя по улицам, особенно в темное время суток, чувствуешь себя героем фильма Вуди Аллена “Ночь в Париже”.
Одним из главных пунктов “посмотреть, иначе считай не был” был Лувр. Музей настолько огромный, что меня хватило только на четверть, хоть я и увидел предметы искусства, которые меня интересовали больше всего: Нику, Венеру Милосскую и всем известную Джоконду.

Когда я добрался до экспозиции одного из самых известных трудов да Винчи, я в очередной раз (как это обычно со мной бывает в музеях) познал дзен. Не потому что я увидел саму картину - Джоконда это самый яркий пример оверхайпа во всем мире, который вы когда-либо увидите, посетив Париж. Пространство вокруг картины, надежно спрятанной за бронированным стеклом, кишело туристами, которые стояли напротив картины минутами, снимая ее на телефон (причем некоторые даже снимали на видео).
Надо встать рядом. Надо смотреть на нее в упор. Надо сделать селфи. Надо позвонить дальнему родственнику: “Посмотри на меня, я стою напротив Моны Лизы, она прекрасна и у нее нет бровей!”.

Но дзен не в этом. Напротив Моны Лизы, окруженной сотней человек, если не больше, выставлена картина Паоло Веронезе “Брак в Кане Галилейской”, поистине огромная и прекрасная во всем, начиная с кошки, дерущей вазу, заканчивая изображением Христа посередине стола, словно его скопировали с “Тайной Вечери”.
И пока Мона Лиза держалась под натиском толп китайцев и британцев, результат работы Паоло Веронезе стоял одиноко, и всего лишь пара человек остановилась, чтобы разглядеть изображенных на ней псов.

И в этом весь наш мир. “Мона Лиза” в Лувре - это семейка Кардашьян, концерт Джастина Бибера и очередь людей за новым айфоном. “Брак” - Илья Кочергин, взявший золото олимпиады по физике в Цурихе, русские студенты, выигравшие кубок ICPC, Дмитрий Маковкин, закрывший собой смертницу, в Волгограде в 2013-ом году.
Что объединяет этих людей с картиной Веронезе? То что всем на них плевать. Как и на Les Noces de Cana.

Миграционные проекты - одни из моих самых любимых. За всю свою карьеру я занимался “переездами” во всех возможных проявлениях: от тяжелых legacy кластеров до в буквальном смысле переездов из одного офиса в другой.

Миграция позволяет не только “перетащить” приложение в лучший мир, но и решить много проблем технического долга, которые вылезают словно гнойники. Огрехи приложений, hardcoded настройки, незадокументированные связи приложений друг с другом - все это вылезает, словно грибы во время дождя, и разработчики, хоть и нехотя, находят время их решить.

Миграцию при этом надо делать по-умному. Повезло, если у приложения есть окно обслуживания, когда его можно просто выключить на часок-другой. Хуже - когда приложение обслуживает клиентов 24/7, и не дай Бог гламурная нимфетка не сможет с первого раза выложить свое личико на всеобщее обозрение.
В таком случае конторы обычно нанимают под это дело консультантов или контрактников, чья работа заключается в переманивании клиентов на свою платформу и помощи пережить migration pain. Если нет денег на “наемника”, контора делает шаг в пропасть и пытается переехать своими силами. Чаще всего - с огромными репутационными и финансовыми потерями. Поэтому если вам предстоит переезд, выбейте у бизнеса денег хотя бы на обучение.

Миграция делится на два типа: переделывание приложений с нуля под архитектуру новой платформы (читай - переписываешь все под тот же Амазон) и lift-and-shift (перетаскиваем как есть).
Оба способа имеют свои недостатки, и не смотря на “некрутость” lift-and-shift считается самым оптимальным по стоимости и скорости.
Переписывая все с нуля под новую платформу, вы рискуете попасть в неприятную ситуацию, потому что:
1. Неправильно спроектированная архитектура, в виду отсутствия компетенций.
2. Старые проблемы могут быть так же переписаны в новом коде.
На выходе вы получите такой же велосипед на костылях, но зато с IAM ролями вместо API ключей.

Lift-and-shift тоже не лишен проблем (особенно с крупными монолитными приложениями - их вообще переносить тяжело), но по крайней мере дает возможность решить проблему переезда, а технической долг будет выплачен уже после.

Если же контора решает устроить переезд своими силами, то обычно организуется своеобразный taskforce - группа людей из разных команд с разными навыками.
Хорошо, когда новая команда сначала проходит обучение. Тогда каждый, набрав определенные компетенции, может предложить идею, которая будет соответствовать best practices. Хуже - когда команда ничему не учится и лезет напролом, гугля разные порции документации.

Вот вам пример - нам нужно перетащить старый MySQL от хостинга в Амазон с минимальным downtime (речь идет о mission critical системе).
Что сделал один из разработчиков-stakeholder’ов? Нагуглил прикольную доку: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

Правильный ли это подход? Может быть, не могу подтвердить или опровергнуть сразу. Но поскольку Амазон не меньше вашего заинтересован посадить клиента на свою инфраструктурную иглу, тот он наверняка предусмотрел этот сценарий и предложил решение в виде Database Migration Service, где весь этот процесс сделан автоматически, да и к тому же поддерживается репликационная миграция (читай продолжительная).
Чем поднимать руками ЕС2 и настраивать там MySQL мне гораздо проще развернуть репликационный таск и выключить его, когда приложение будет готово работать с промышленной базой в Амазоне. Весь downtime - один рестарт приложения.

Что в миграционных, что в любых других проектах или задачах стоит применять золотое правило: “Предложи вариант B” - если вы уже нашли способ решить проблему, пусть и самый удобный, найдите еще один. На всякий случай.

Поднабив руку в Terraform и Cloudformation, внезапно понял, что мне больше не удобно пользоваться консолью AWS. O_O

Мое состояние, пока в Амстердаме бушует прайд.

Друзья, хорошие новости! Я закончил работу над вебинаром!

Важная информация: Вебинар пройдет 15 августа в 20.00 по Московскому времени.
Вебинар займет около 2 часов, но на всякий случай я бронирую 3 часа.
Стоимость участия - 750 рублей.

Чтобы оплатить и попасть на вебинар, нужно сделать следующее:
1. Отправить на карту 5100690020146821 сумму равную стоимости участия.
2. Сделать скриншот (с компа или телефона) подтверждения перевода.
3. Отправить этот скриншот мне на электронную почту: thomas.storm@protonmail.com. На адрес, с которого вы отправили скриншот, 11 августа придет ссылка на регистрацию на вебинар.
4. Дальнейшие инструкции будут отправлены по эл. почте в индивидуальном порядке.

Важно! Регистрироваться на вебинар нужно будет с того же адреса, с которого вы отправили скриншот.
На вебинаре будет подтверждение участников, так что нет смысла делиться ссылкой с другими людьми.

Ниже - небольшая адженда по вебинару.
P.S. Если по каким-то причинам метод платежа выше вам не подходит, пишите в личку, что-нибудь придумаем.

Пока готовил материалы для демонстрации CI/CD в AWS, вдоволь наигрался с CodePipeline и Fargate.

На что обратил внимание:
1. CodeBuild использует похожую с TravisCI и Gitlab модель настроек. Если в Teamcity и Jenkins вы можете задать цепочку тестирования через пользовательский интерфейс, то в CB нужно прописать инструкции в buildspec.yml. Файл интуитивно понятный, но понадобится некоторое время покорпеть над документацией, чтобы не ошибиться с параметрами.
2. Сам CB не имеет в себе возможности сборки нескольких проектов. Если вам нужно прогнать тесты с несколькими приложениями (например интеграционные тесты), то нужно делать два отдельных проекта в СВ и связывать их с CodePipeline.
3. Fargate же построен типично по модели Kubernetes. Когда вы создаете task definition, вы задаете лимиты по ресурсам, а внутри него можно запустить несколько контейнеров (читай тот же Pod). Создавая сервисы, вы можете выбрать варианты развертывания REPLICA и DAEMON, что тонко намекает на концепцию Кубера (replicaset и daemonset).
4. CodePipeline позволяет связать все сервисы сборки и развертывания в одну цепочку, связываясь с GitHub по hook’ам, которые служат триггером для начала цепочки (что в принципе и есть основное ядро CONTINUOUS integration).
5. А вот с чем не понравилось работать, так это с CodeDeploy. Мало того, что appspec.yml (инструкции по развертыванию) гораздо сложнее “вкурить” чем buildspec, так еще очень много приходится возиться с ролями и настройками инстансов, на которые нужно разворачивать приложение. Изначально я хотел провести демо связки CodePipeline (CodeBuild + CodeDeploy G/B) + ASG, но после плюнул и решил уйти поглубже в контейнеры.

И все же, Fargate - one love. Буду топить за переезд на него в следующем году.

Я уже говорил, что у меня на работе есть коллега-архитектор?

Дядечка с 30+ лет опыта работы, помнит UNIX, съел собаку на AWS и нежно любит Bash. Я зову его ласково «Дед» (не в лицо разумеется, иначе поймают на эйджизме).
У меня порой бывали комплексы по поводу своего возраста, особенно потому что некоторые товарищи считали и до сих пор считают, что я не «дорос» до своей должности, но с Дедом никогда проблем не было.
Прикольнее всего смотреть, как Дед работает. Человек отпахал немало лет в Philips и прекрасно знает, как надо делать архитектуру уровня Enterprise.
Но поскольку я гораздо моложе его, то мое преимущество в скорости мышления. Поэтому с Дедом у нас этакий тандем. Дед рисует «скелет» любого проекта, а я, этакий Медведев на минималках, подкидываю туда всяких новомодных плюшек в лице всяких инфраструктур-как-код с этими вашими пайплайнами.
Ну и вишенка на торте - исправлять за дедом опечатки и прочие косяки. Ощущение, как учишь бабушку пользоваться Телеграмом.

Когда я работал в Coolblue в моей команде появилось вакантное место тимлида.

“Почему бы и нет?”- подумал я и подготовил небольшое эссе, которое было тестовым заданием для этой позиции. На одной странице нужно было указать, что по моему мнению есть команда, и какие цели преследует тимлид.

Для меня команда всегда была, есть и будет небольшим отрядом отмороженных ублюдков, пожирающих души своих врагов и тянущей продукт наверх, к Луне.

Что я в принципе и написал в своем эссе. Команда - отряд, а тимлид в ней - сержант, главной целью которого является даже не миссия, а сплоченность и здоровье его команды.
Что об этом подумала комиссия, которая оценивала эссе? Что я хренов милитарист и люблю строгую субординацию и подчинение. Голландцы, как вы помните, крайне демократичные и очень любят свое право голоса. Разумеется, я не прошел.

Что написал мой коллега, который тоже претендовал на эту должность? Он сравнил тимлида с Царем Леонидом, а команду с 300 спартанцев.

Мораль: военщина - плохо, 300 спартанцев и другие псевдоисторические аналогии - хорошо.

Опять же многоуважаемый @CarrolCox балует меня крутым контентом.

Очень классная лекция о том, почему у ИТшников едет крыша (Спойлер: вы в числе этих безумных.) - https://youtu.be/K6oZuB8_dU8

Для себя вынес полезный совет:
Делайте сами все правильно и исправляйте коллектив. Давайте другим звездюлей, будьте проактивными.

Всем, оплатившим вебинар, было выслано приглашение. Если вы оплатили, а письмо никакое не прилетело, пишите в личку.

Тем, кто еще не оплатил, но все равно хочет поучаствовать - не волнуйтесь, время еще есть.

Ребятки, из тех, кому выслал приглашение, зарегистрировались не все.
Потратьте пару минуток, чтобы пройти по ссылочке, чтобы я успел всех “подтвердить".

Для работы мне нужно было написать один “умный” скрипт по развертыванию наших приложений в DCOS.
Раньше наша система сборки попросту отправляла HTTP вызов в DCOS и фиксировала развертывание, как прошедшее успешно. Если приложение по каким-то причинам валилось или вовсе не поднималось, мы об этом узнавали только из мониторинга.

Другой проблемой были разные конфиги приложений. DCOS использует небольшой spec-файл в формате JSON, и в наших репах лежало по одному (или более) файлику для каждого приложения. От такого тоже нужно было уйти, поскольку разные json-чики порождали комплексную инфраструктуру конфигов, которую нам (Ops) было тяжело отслеживать и управлять.

Написав и протестировав свой скрипт, я выкатил его в промышленное использование, перенастроил пайплайны, да так и оставил все это дело на пару месяцев.

Время шло, мы стали выкатывать не только http микросервисы, но и TCP приложения с несколькими портами, и настало время обновить скрипт.
Когда я открыл проект, я понял всю боль программистов, которые месяц не трогали свой код. Куча велосипедов, костылей и “грязно” написанных строчек вызывали у меня страшную фрустрацию. “Кто мог написать такое говно?!” - думал я и сокрушенно смотрел на имя автора коммита.

Спустя полчаса самобичевания, я познал дзен (наверное уже 6-ой раз за этот месяц) и принялся переписывать свое творение. Через пару часов мой скрипт был переделан, а новая структура создания конфига позволяла добавлять новые “фичи” без надобности переписывать все с нуля.

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

Любите рефакторинг.

Чем больше я работаю в ИТ, тем больше я понимаю, что ничего не знаю.

У нас два build агента, оба клонируют репозитории для сборки, используя ключи SSH.
В какой-то момент у нас случилась проблема с SCM (Bitbucket), и нам пришлось заменить ключи на агентах. В итоге Агент 2 может клонировать репозитории, а Агент 1 не может. Валится по SSH auth.

Полез проверять, ключи одинаковые, с правами на файлики все в порядке. Оказалось в .ssh лежал еще публичный ключ id_rsa.pub, который сервер отправлял как публичную часть, и естественно публичная часть ключа была вообще не с тех степей. Убрал публичный ключ из директории, и все заработало. Почему он берет отдельный файл, и отправляет его как публичную часть ключа - вообще не понимаю.

Я знаю, что ничего не знаю.

Спасибо всем пришедшим на вебинар.

Надеюсь, это было интересно и познавательно. Я приобрел ценный опыт, понял, что гарнитуру надо менять, и похоже сорвал голос.
Материалы по вебинару были разосланы его участникам по почте. Если вы по какой-то причине не получили письмо, свяжитесь со мной.

Кстати, пока подчищал свой амазоновский аккаунт, нарвался на то, что не могу удалить Private Hosted Zone .local, который создается автоматом, когда мы поднимаете сервис в Fargate. Причина этому - этой зоной “владеет” подсервис ServiceDiscovery (один из компонентов ECS), который не дает вам его удалить. В принципе, логично.

Но если вы больше не используете Fargate и не хотите лишний раз тратить 50 центов, то нужно удалять сервисы и namespace через AWS CLI. Через консоль это сделать нельзя.

Подробнее о том, как это дело подчистить, написано тут: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html

Чуть позже продублирую информацию по тренировочной программе, о которой я говорил на вебинаре и тут https://t.me/manandthemachine/282.

Теперь по поводу программы тренировок (или менторства - кому как проще), о которой я говорил ранее.

Я уже говорил, что обладаю желанием и возможностью помочь своим молодым читателям (и не только молодым, и не только читателям) в карьерном, профессиональном и личностном росте. Целью вебинара было показать свой опыт и навыки, чтобы потенциальные “ученики” могли оценить для себя, нужно им это или нет.

Что я буду делать:
1. Я помогу вам определиться со своими среднесрочными и долгосрочными целями.
2. На базе этого я подготовлю для каждого “ученика” план развития.
3. Этот план развития затем будет обрастать направлениями на прохождение курсов (разумеется онлайн), чтение различной литературы, выполнение всякого рода домашних заданий.
4. Я со своей стороны буду этот процесс регулировать контролировать.

Воспринимайте это как найм персонального тренера для фитнеса.

Чего же я не буду делать (и обещать тоже):
1. Я не буду гарантировать вам трудоустройство во время или после прохождения программы. Я не обладаю административным ресурсом, чтобы проталкивать людей на нужные им должности, равно как и не являюсь авторизованным центром обучения с гарантированным трудоустройством (Хотя буду помогать в подготовке к собеседованию и выполнению технического задания)
2. Делать вашу работу. Я заинтересован помогать вам в решении своих рабочих проблем, но делать это придется вам сами. Я смогу только направить в нужную точку.
3. Я так же не буду вам помогать, если вы сами этого не хотите. Тут, я думаю, очевидно почему.

По условиям.

Программа будет длится либо 6 месяцев, либо 12 с возможностью продления. За 6 месяцев - 20 000 рублей, за 12 - 30 000 рублей.
Способы и расписание оплаты, а так же прочие условия прохождения программы будут обсуждаться с каждым индивидуально.

Заранее предвкушая вопрос “Почему так дорого?” - просто потому, что для плодотворного сотрудничества нужна жесткая мотивация. И практика показывает, что мотивация “рублем” - самая надежная. Отдав левому анониму из Телеграмма 20 или 30 тысяч рублей, вы будете гораздо более мотивированы грызть гранит науки, проходить обучение и развиваться.

Для того, чтобы стать участником, нужно будет отправить мне на почту (thomas.storm@protonmail.com) свое резюме (без указания персональных данных - я не подписывался ни под ФЗ 152, ни под GDPR) и сопровождающее письмо, в котором надо ответить на два вопроса: чего вы хотите достичь, и почему вы этого еще не достигли.


Как я писал ранее - эта программа больше подходит для молодых (с точки зрения опыта, а не возраста) специалистов, которые либо только начали, либо вообще не начали осваивать DevOps.

На данный момент всего свободно 5 мест. Если я пойму, что “потяну” больше людей, я сообщу об этом в отдельном сообщении.

Если есть вопросы - смело пишите.