Diary of a Madman
57 subscribers
73 photos
2 videos
114 links
Антон Рябов: doam.ru
Бот для обратной связи: @doam_ru_feedback_bot

Disclaimer: I do not speak on behalf of my employer.
Download Telegram
#DevopsTuesday

Написал в блог заметку в чем разница между Continuous Delivery и Continuous Deployment https://bit.ly/2xAzbgk

Если лень читать то картинка https://doam.ru/cdvscd должна все объяснить.
Чтобы легче было ориентироваться в канале, использую следующие теги:

#SREBook - заметки по ходу чтения книги "Site Reliability Engineering" от Google

#life - заметки из моей жизни

#бред - который постоянно крутится у меня в голове

#новости - короткие новости одной строкой

#рюкзакология - мои изыскания в теме качественных рюкзаков и EDC

#travel - все что связано с путешествиями

#DevopsTuesday - по вторникам пишу заметки по теме SRE/DevOps

#moscowtoday - фотографии Москвы

#book_notes - заметки и цитаты из прочитанных книг

#антон_хочет_знать - опросы

#экономика - мои подходы, правила и советы ведения хозяйства

#health - мнение и заметки по теме здоровья

#DIY - мои рукожопные поделки

#скетчноутинг - я рисую как дебил

#spam - все остальное, для чего у меня нет категории
#DevopsTuesday Ошибка шефа - банкротство ресторана

Рас
скажу короткую, но поучительную историю про систему управления конфигурацией Chef.

Каждый сервер в шефе это нода (node) и принадлежит какой-то роли (role) и окружению (environment). У ноды есть атрибуты, это как бы переменные со свойствами. Какие-то атрибуты заполняются шефом автоматически, другие задаются статически администраторами. По ролям, окружениям и атрибутам в шефе можно делать поиск.

В проекте, в качестве основного веб-сервера использовался Nginx, и апстримы (upstreams) для него заполнялись с помощью поиска из шефа. Т.е. конкретные запросы должны уходить на серверы в конкретной роли и окружении.

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

После долго поиска проблемы, выяснилось. Что Solr, который используется для поиска в Chef, при поиске в главном Nginx находил и те роли, которые прописаны в атрибуте roles для совершенно другой задачи. Чтобы устранить проблему, пришлось переименовать атрибут и еще долго прогонять везде шеф, чтобы записались правильные upstreams 😔.

Мораль: не используйте в названиях атрибутов слова из структуры Chef, такие role, environment и т.д. и хорошо продумывайте ваши поисковые запросы 🧐.
#DevopsTuesday

На новом проекте активно работаю с AWS SDK и все больше убеждаюсь, что инфраструктурные инструменты типа Chef, Ansible или Terraform, в случае работы с облаками, только добавляют лишнюю прослойку и усложняют проект. Со временем крепнет идея, что инфра код должен быть полноценной частью кода разработки.

Потому что через SDK, который Amazon написали под все популярные языки, я могу деплоить новую версию контейнера на ECS Fargate в пару строк, а через любой другой инструмент буду огород городить.

Или, например, чтобы приложение заработало, нужно чтобы была база данных, очередь и еще что-нибудь. Т.е. пока инфра скрипты не прогонишь приложение будет падать. Но ведь оно может само все зависимости для себя поднять если их нет, зачем намеренно блочиться сторонними инструментами?

Слежу за одним проектом, который двигается как раз в таком направлении - управлять инфраструктурой прямо из кода - Pulumi. Посмотрим как будет дальше, а пока пойду Terraform модули писать.
#DevopsTuesday

Решил сделать обратную связь в канале. Команда Telegram предлагает использовать для этого кнопки-реакции (уже внедрил) или отдельный чат. Я не отказываюсь от чатика своего канала, но пока критическая масса по подписчикам не достигнута, не вижу в нем смысла. Да и самое главное, что чат может быть удобен не всем.

Есть неофициальные боты, которые делают то, что мне нужно. Но они открытым текстом пишут, что вся переписка и данные будут сохраняться у них. Меня такой расклад не устраивает. Весь Open Source, что я нашел на Github очень примитивный и заканчивается на тупой пересылке сообщений.

Для своего бота я составил такой набор функций:
[x] пересылка сообщений в заданный чат
[x] анонимные сообщений (сохраняется только userId, который необходим для пересылки)
[ ] открытие данных - при желании, пользователь может открыть свои данные и тогда я увижу кто прислал фидбек/вопрос
[x] сохранение истории переписки
[x] ограничение скорости отправки сообщений
[ ] бан
[ ] удаление пользовательских данных - пользователь может запросить удаление всех данных, связанных с ним, которые хранятся в боте

[x] - уже сделано, пишу на Golang, когда причешу "лапшекод" открою репозиторий на GIthub.
#DevopsTuesday

Тут недавно развернулась дискуссия на счет того, должен ли cпециалист уровня senior знать devops. Основной замес был вокруг того, что мол full stack должен знать, а обычный разработчик, неважно какого уровня - нет, этим должны заниматься отдельные люди.

Во всей переписке я заметил несколько ошибок. Конечно же, ни кто ни кому ничего не должен. Скиллсет каждого сотрудника и готовность за него платить работодателя очень субъективное дело каждого конкретного случая. Но если мы говорим о построении качественной команды со здоровыми процессами и отношением, devops должны знать все участники процесса доставки ценностей.

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

Перефразируя классика, "лучший devops - отсутствие devops'a". Моя точка зрения здесь такая, что выделение конкретных людей, отвечающих за devops только построит стены. Мне нравится приводить в пример одну историю, услышанную либо на каком-то митапе, либо от кого-то из коллег.

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

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

Стройте центры компетенций, делитесь знаниями и опытом, используйте прошлые ошибки, думайте немного шире и наперед и будьте хорошими инженерами.
#DevopsTuesday Гонка в CI/CD пайплайне

Публиковал эту историю в Twitter в виде треда, пусть в канале тоже будет.

Сначала дисклеймер: не спрашивайте "почему так?", просто примите как факт, что у меня тут пайплайн в AWS CodeBuild по большей части на Bash с вызовом JavaScript скриптов в некоторых местах.

Цель была в уже существующий и нормально работающий пайплайн добавить отправку евентов в EventBridge по мере выполнения. По задумке, на разные евенты будут реагировать разные Lambda функции и делать всякие штуки.

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

Евенты не несут ни какой полезной нагрузки для пайплайна как такового. Поэтому их отправка должна по минимуму на него влиять и уж тем более, ошибки отправки евента не должны прерывать пайплайн.

Имея все это на руках, я написал отдельный скрипт, в который параметрами передаются фаза, шаг и статус пайплайна.
Грубо говоря вот так:

./send_pipeline_event.bash pre-build coverage success


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

Обрабатывать каждую строчку кода или отлавливать в каждом скрипте через trap - так себе занятие.

Я додумался вести файл с состоянием и перед каждой отправкой евента вычитывать текущие фазу и шаг, а ошибки перехватывать одним глобальным post build экшеном, который также сможет забрать последние фазу и шаг из этого файла.

Вызов скрипта изменился на:

./send_pipeline_event.bash "$(jq -r '.phase' state.json)" "$(jq -r '.state' state.json)" success &


Но теперь во время работы пайплайна я стал рандомно ловить евенты с неправильными phase и state. Долго не мог понять в чем причина, по пути исправил пару других косяков и только к вечеру допёр.

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

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

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

Вычитывание фазы и шага прямо в аргументах я сделал для компактности, но как часто бывает в Bash, многословность работает лучше.

Вынес получение аргументов явно в переменные перед запуском скрипта и теперь работает как надо.

phase=$(jq -r '.phase' state.json)
step=$(jq -r '.step' state.json)
send_pipeline_event.bash "$phase" "$step" success &


В общем, морали нет, я просто протупил с этим пол дня.
#DevopsTuesday

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

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

Очень быстро, процесс сборки контейнера переносится в CI, а точкой синхронизации становится Dockerfile. Мы начинаем думать, что вот есть Dockerfile, я могу собрать из него контейнер локально и протестировать, а потом из этого же Dockerfile собрать контейнер в CI и запустить в окружении.

И в этом то и есть обман. Контейнер или в терминах CI/CD - артефакт, собранный на локальной машине и на build сервере, даже из одного и тоже Dockerfile не являются полностью идентичными.

Сам факт того, что рабочая машина может быть на любой популярной ОС Windows/MacOS/Linux, а build сервер скорее всего только на Linux, уже должен наводить на мысли. Более того, я видел когда в Dockerfile есть условия и переменные, в зависимости от того где его собирают.

Я вижу два выхода из этой ситуации:

1. Сборка и, возможно, интеграция, должны проходить на машине инженера и именно этот артефакт должен отправляться по окружениям дальше. Я, кстати, задумывался над таким еще несколько лет назад и смотрел способы прогона Jenkinsfile локально.
2. Рабочая машина инженера вообще не должна участвовать в процессе сборки, а использоваться как тонкий клиент для доступа к редактированию кода. С учетом прогресса Cloud9 и VS Code, и интеграцией последнего в Github это вполне реалистично. CI при этом всегда и полностью будет на build сервере.
#DevopsTuesday

Про сертификацию

Месяц подготовки (в параллель с работой)
5 направлений, больше 100 сервисов, 75 вопросов
3,5 часа не вставая с кресла, перед ноутбуком и записывающей веб-камерой

Недавно я сдал экзамен AWS Certified Solutions Architect уровня Professional. Хочу записать зачем и какие выводы сделал.

Стоит сказать, что в прошлом году я сдал похожий экзамен Professional Cloud Architect по облаку Google. Так как это облака, в обоих много внимания уделяется Scalability и Reliability, но мне показалось что в GCP зачастую есть только один сервис/способ решения задачи и он скорее всего "google way", в то время как в AWS много адаптированных решений и вариантов несколько.

Например, у обоих есть сервис для управления SQL базами MySQL/PostgreSQL. Но они немного ограниченны как в размерах, нагрузке так и в отказоустойчивости. Если у вас большая нагрузка/объемы, нужно переходить на другой сервис.

В случае GCP это Cloud Spanner и не получится просто изменить подключение на новый сервис и перетащить данные, придется переписывать приложение. Тут отдельные клиентские библиотеки, изменение схемы и т.д.

А в AWS сервис такого уровня, с шардированием и кросс-регионами это Aurora, который заработает из коробки на тех же клиентах, а миграцию данных можно сделать хоть репликацией, хоть восстановлением из снепшота.

Следующее отличие, что в AWS больше внимания уделяется миграции из On-prem или гибридным схемам. Ну и последнее, что я хочу выделить, это то, что в AWS экзамене много про стоимость. Всегда есть несколько вариантов решения задачи и чтобы сдать экзамен, нужно понимать какое из них будет дешевле, а какое эффективнее и что из этого нужно клиенту/компании в данный момент.

Подводя итог сравнения, мне больше понравился экзамен AWS и если вы хотите сдать только один экзамен по облакам, берите его.

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

В свое время Mercaux не взяли меня без опыта AWS. Что не помешало мне стартануть на проекте в этом облаке почти без знаний и в одного, в короткий срок сделать хорошее решение. Сертификация для меня не изучение чего-то нового, а способ доказать всем тем, кто считает что для этого нужны какие-то особенные знания или скиллы, что это не так. Я считаю, что инженер, при желании, разберется с любой системой. Особенно если ему это интересно.

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

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

Что дальше? Сертификаты, имеют срок годности 2-3 года, но пересдавать конечно же я не буду. Из 3 крупнейших облаков остался Azure, но я решил что не буду его сдавать. Облака +- похожи, естественно есть свои особенности, но при необходимости я попробую компенсировать уже имеющимся опытом и своей способностью быстро учиться и разбираться.

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