Сегодня крутил https://github.com/coreos/prometheus-operator в GKE по совету @duoonp и что-то сразу не взлетело. Сначала были проблемы с clusterrolebinding и rbac, потом не заводились serviceMonitors, но это постепенно решалось и все завелось.
Захожу в UI прометеуса, на первый взгляд все ок. Но в таргетах проблема - не снимаются метрики с kubelet експортера (а это метрики kube-api + cadvisor). 😳
Начал разбираться, все ссылки указывают на rbac или неправильные сертификаты.
Но проблема была в чарте самого kubelet експортера: https://github.com/coreos/prometheus-operator/blob/master/helm/exporter-kubelets/values.yaml#L2 🙈

Поговорили с ребятами про inode.

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

Более подробно описано тут:
https://github.com/angrave/SystemProgramming/wiki/File-System,-Part-2:-Files-are-inodes-(everything-else-is-just-data...)

Упоролся в helm и наследование values. 🤓

Как я уже упоминал в презентации, helm позволяет сделать шаблонизацию и версионирование Ваших манифестов. Или насетапить какой-то готовый сервис, например, redis. Официальные и доступные чарты находятся тут: https://github.com/kubernetes/charts/tree/master/stable

Когда сетапишь один чарт, все в порядке. Указал --values и погнал. 😏
Но, если есть requirements.yaml с кучей дочерних чартов - все сложнее.

Мне нужно было поменять values дочернего чарта при установке корневого. Как оказалось, это можно сделать просто:
https://github.com/kubernetes/helm/blob/master/docs/charts.md#scope-dependencies-and-values

В переменных корневого нужно добавить такую конструкцию:

child_chart_name:
key_you_wanna_change: value

Этот ключ (key_you_wanna_change) пробросится в дочерний чарт (child_chart_name).
Hope it helps! 😝

#kubernetes_devopsengineer

В некоторых местах нашей инфраструктуры на AWS мы запускаем Lambda через Cloudwatch по крону.

Со стороны Terraform за это отвечает ресурс aws_cloudwatch_event_rule, детальнее в документации:
https://www.terraform.io/docs/providers/aws/r/cloudwatch_event_rule.html

Конструкция довольно проста:
schedule_expression = ‘cron(0 20 * * ? *) ‘

Меня немного смутило количество параметров … и да, оказывается у AWS крон не такой, как у всех:
https://docs.aws.amazon.com/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html

А вот для стандартных кронов есть отличный сервис (пользуюсь, и Вам советую):
https://crontab.guru/

#aws_devopsengineer #terraform_devopsengineer

Только вернулся с Варшавы. У нас там был гастро и алко тур 😂
В основном конечно алко, очень понравилась местная зубровка и дороги.
Пока фоткал девушку - в кадр случайно попала офигительная тачка.

Зацените, ззади справа красный Civic 5D. ⬆️

Обзор тачки есть тут (красный цвет агонь!):
https://www.topgear.com/car-reviews/honda/civic

Ну просто супер офигительная тачка! Уже собираю 35 к долл))

P.S. На следующую неделю кое-что для вас подготовил!

Хорошая статья на вечер:
https://habrahabr.ru/post/350374/

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

Например, строчки кода в фиче - это не интересно бизнесу. А вот сколько денег заработает компания на новой фиче - это прямой еффорт, и он очень понятен бизнесу. 💸

Формулировка "мы увеличили перформанс" - такое, а например "мы увеличили перформанс в 3 раза, добавили stateless, перенесли воркеры на spot инстансы, и теперь инфраструктура стоит на 20 000$/мес меньше" - это агонь! 🔥 Это мясо! То, что понятно бизнесу. Язык денег. 💵💴

Надеюсь, у чувака получиться сделать что-то очень крутое!
Это будет отличный пример и сильный пуш к действию. 🙈

В Кибану подвезли ну какие-то прямо невменяемые визуализации!
Если не верите - сами посмотрите:

https://www.elastic.co/blog/custom-vega-visualizations-in-kibana

DevOps vs DevOps Engineer

Развенчивание мифов! Самая холиварная тема! Осторожно, может быть полыхание. 🔥🔥🔥

Часто слышу, что "DevOps" - это не позиция, а методология. И я полностью согласен согласен с этим. Хантить "DevOps-ов", чтобы они сделали все круто - это не правильная позиция. Искать методологию? WAT? 😱
В то же время, те же ребята любят задвигать, что "DevOps Engineer" - это тоже не позиция, ведь не может быть инженера у методологии. Например, у Agile нету инженеров. Или еще какие-то рендомные доводы.

Я считаю (мое мнение), что сравнение с Agile не корректно. Единственное, где термины пересекаются - это то, что это методологии. Окей. 👌

В Agile отсутсвует техническая инженерная составляющая (Agile Coach, Scrum master) и все кто крутятся возле Agile - не пишут код. Они не инженеры.
В DevOps методологии есть несколько вариаций подобных специалистов. Например, DevOps Architect - это специалист, который тоже не пишет код, он управляет командами. Грубо говоря, как Agile Coach. DevOps Architect - это тоже (уже) не инженер, хотя раньше им был.

В то же время, утверждение DevOps Engineer - абсолютно корректно. Это специалист, который пишет код (занимается инженерной деятельностью) согласно концепции IaC. Это инженер, потому что он создает инженерную (техническую) ценность, которая крутится ВОКРУГ DevOps методологии. Ценность формируется вокруг создания инфраструктуры, так называемой платформы. И правильно настроенных процессов (CI/CD).

Резюмирую:
- должность "DevOps Engineer" - абсолютно правильная и логичная, потому что эти специалисты занимаются инженерной деятельностью;
- искать "DevOps" - это не правильно, т.к. невозможно искать методологию;
- искать "Agile Engineer" - тоже не правильно, т.к. эти специалисты инженерной деятельностью не занимаются.

P.S. В народе нас часто именуют "Девопсами". Как вы к этому относитесь?

Завтра едем с мужиками раздавать крутые штуки Одесским ребятам. 🔥🔥🔥

https://www.facebook.com/events/1927554550894116/

Уууууух! Я уже прямо это чувствую, эти помидоры, которые в меня летят 🍅😂

А вообще буду рассказывать про Kubernetes в GCE, и как мы там зарелизились без особых проблем. И все получилось очень даже ничего) Постараюсь запостить кое-что интересное Вам с митапа!

Также там будут выступать два моих дружбана, обязательно познакомлю) 🤝

Stay tuned!

Нужно ли DevOps Engineer уметь программировать? ❓❓

Опять нарываюсь, и рискую получить отписку или жесткую критику 😱😡

По моему личному (субъективному), (Вы можете с ним быть не согласны, и будете правы) мы должны уметь программировать. Причем довольно хорошо.

Почему я так считаю:

1️⃣ - это помогает понять, как должны работать процессы (воркфлоу разработки), пирамида тестирования, деплоймент;

2️⃣ - это дает сильное преимущество - помощь своей команде там, где их знания и экспертиза начинают проседать. Например: сетевое взаимодействие, работа с IO, архитектурные паттерны, оптимизация ресурсов;

3️⃣ - это очевидное конкурентное преимущество: с умея программировать мы можем не только использовать готовые интеграции между сервисами (github, jira, slack) а и писать свои, что в результате позволит сделать что угодно (и конкретно под Ваши задачи);

4️⃣ - это добавляет реактивную силу команды, когда мы можем подсапортить и помочь написать какой-то воркер, пофиксить баг в приложении, добавить ему отказоустойчивости, научить конфигурироваться более гибко или правильно обрабатывать сигналы;

5️⃣ - в конце концов, это интересно

Кто знает, куда Вас занесет через пару-тройку лет? Может, это будет свой стартап? Или свой продукт? 🙏

Для меня лично программирование дает уверенность и понимание, что я нахожусь на одной волне со своей командой, и мы вместе делаем нашего кастомера счастливее. 🤓💸

Я начинал с Python, и могу рекомендовать его как суперский язык для начинающих и продолжающих.
Он шикарен в быстроте разработки (а ведь для нас это важно!), простоте обучения и огромном количестве библиотек. В то же время, он не очень удобен для контейнерных штук (как и любой интерпритируемый язык), и достаточно слаб по производительности.
Сейчас мой фокус направлен на изучение Go, и в ближайшее время этот фокус точно не изменится.

А Вы умеете программировать? ❓

Нормально накачали Одесских ребят! 👍👍👍

Когда приехали - было +17, а когда уезжали - минус 5. Очень обидно( 🌬

Как и обещал - знакомлю с дружаней)

Игорь Бородин - это совем упоротый дядя на тему кубернетисов и контейнеров/оркестраторов. Он когда-то давно работал в Циклуме на адовом проэкте с Chef, потом свалил в Швецию, и вот вернулся назад. 🇸🇪

Сейчас пилит реализацию платформы Кубернетиса для всего Intellias.

Найти его можно в линкедине, на фб, в укропс клубе, на ютубе, много где)

Он может быть Вам полезен ответами на все вопросы, которые касаются кубика и современных архитектур.

Еще Игорь выглядит как планокур, но на самом деле никогда не пробовал. 🌱🌿☘️🍀
И страшно любит пивас (наверное, как и все мы). 🍺🍺

https://www.facebook.com/neuromood
https://www.linkedin.com/in/ihor-borodin-903706106/

На сам митап я к сожалению опоздал, и не успел сфоткать ничего нормального 😭Но как только появятся видосы - обязательно скину) 🙈

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

- как спроектировать гугл
- как сделать дропбокс
- как спроектировать что-то больше

Рекомендовано для лид позиций и хороших ЗП)

https://github.com/donnemartin/system-design-primer

Полезно?

Моя жизнь никогда не будет прежней! 😂

До этой статьи я думал, что знаю, как происходит DNS резолвинг:

https://dmenshikov.com/2018-03-16-hostname-resolving-on-linux/

Но сильно ошибался 😡😇

Дебаг, сорс код, полет мысли - все как Вы любите! 😳 🙈 😝

И еще пасхалка - почему некорректно проверять хостнейм, используя команду host?

Интересно?

Оказалось, есть люди, которые не шарят mysql датасорс в графане, и я решил с Вами тоже поделиться. 😎🤓🤗

https://docs.grafana.org/features/datasources/mysql/

Раньше, когда его небыло, и мы с ребятами делали мониторинг продуктовых метрик (а продакшн базка - мускуль), приходилось:
- писать кастомные чеки в системах мониторинга 🤢
- шедулить какие-то скрипты 🤢
- придумывать воркеров 🤢
- педалить сомнительные архитектурные решения 😂 (очень люблю эту фразу)

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

После того, как появилась поддержка mysql датасорса, это все можно мутить прямо из коробки!

Еще раз опишу юз кейс: натравить на продакшн слейва, и рисовать красивые бизнес-метрики.

Например:
- сколько юзеров зарегалось за последний час 👍
- сколько онлайн пользователей 👍
- сколько денег заработали за последний час 👍
- самый большой чардж 👍
- сколько важных задач мы обработали 👍
- в общем, все что интересно бизнесу в конкретный момент времени 🤑🤑

Ребят, агонь?

Бонжорно, тутто бене!

Кто думал что я пропал? Признавайтесь! Вообще-то нет, просто был в затяжном отпуске.

И хоть настроение у меня полное говно и паскудство, но порцией полезностей обязательно поделюсь. 😔

Так как я был в отпуске, то занимался (в свободное от отдыха время) не техническими вещами, а полезными для софт скилов штуками.

Самым большим и качественным открытием этого отпуска для меня стал Тим Урбан. Это такой дядя, который разбирается в какой-то концептуальной теме (карьера, прокрастинация, рабочие моменты) по 1-2 года, а потом делает суперский лонг-рид с офигительными иллюстрациями.

Пару недель назад у него в блоге вышла статья о том, как правильно выбрать карьеру. Оставляю ссылку: https://waitbutwhy.com/2018/04/picking-career.html

И тут я реально офигел. Стало сразу очень жалко, что я не увидел этого лет 5 назад. Для тех кому 30+ должно быть жалко, что не увидели лет 10 назад (моя фирменная шутейка про возраст и старые ведра, привет моим коллегам).

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

Определенные штуки я уже неосознанно использовал, и это очень радует. 😎

И в конце, упомяну про шеф-поваров и обычных поваров (опять концепция Тима Урбана). Суть такова: прикольно изобретать новое и крутое, а не наследовать тех, у кого получилось. Результат работы шеф повара - новое блюдо. Результат работы повара - еще одна котлета.

Как это применимо к нам:
- о, те ребята запилили istio, и мы тоже пойдем пилить, хотя не понимаем, зачем он нам нужен
- гугл юзает борг, значит нам тоже нужна оркестрация
- у всех графит, и у нас будет графит
- клаудформейшн 111!!!

Очень надеюсь, что статья и подходы описанные в ней помогут Вам стать шеф-девопс-инженерами. И мне тоже, заодно) 😜

Наверное, паблик клауды считают, что у всех должна быть своя реализация PaaS Kubernetes 😂

Даже у DigitalOcean появился early access, (к тому же бесплатный на все лето).

Понятно, что крутить продукты, которые должны работать нормально там не стоит, но пожамкать в свободное время - почему нет 🙂

Оставляю ссылку:
https://www.digitalocean.com/products/kubernetes/

Ребята, кто уже обновился на Grafana 5.1?

Натыкайте пальцев вверх, если уже обновились, пальцев вниз если нет, и краба - если еще не успели, но вот скоро будете 🔥

На всякий случай даю ссылку на релиз ноутс 😎
https://docs.grafana.org/guides/whats-new-in-v5-1/

А у нас кто-то есть с первой столицы? Я имею в виду с Харькова? 🤠

Мне написал некий Дима Лавриненко из СС, и сказал что будет выступать перед местными ребятами 26-го мая.

Вот ссылочка:
https://www.facebook.com/events/472708259891041/

На его доклад приходить не рекомендую (уж слишком нудный и непонятный тип), а все остальные можно и послушать. (шутейка 😂, он на самом деле норм)

Есть гипотеза, что ближе к митапу я тоже могу расчехлиться и понаехать. 😱

Очень прикольная и почти лайтовая статья о том, как делать быстрые сайты. 🏍

https://medium.baqend.com/the-technology-behind-fast-websites-2638196fa60a

Мне очень понравился момент, в котором есть данные о потерях при увеличении латенси загрузки страницы.

Например, ускорение в 100 ms на Amazon приносит +1% прибыли. На их масштабах - это 1 миллиард. Неплохо картиночки заоптимизировали?) 😂

А в Google +500 ms к результатам поиска - и 20% пользователей не дожидаются результатов и уходят. 🐎

Так что действительно есть смысл предложить Вашему бизнесу сделать акцент на скорости загрузки 😎🤓🤗

Что делать? Как правильно поступить? DevOps Factors 😱

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

Нигде нету готового пресета, по которому можно было следовать, и говорить - это ок, а это такое себе. А это - вообще очень плохо. 🤓

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

Как должен выглядеть CI процесс? Должен ли он делать гит пулл на конечных серверах? Или передавать готовые артефакты? Какой процесс деплоя оптимален? Сколько времени максимум может занимать сборка приложения?

Это все простые вопросы, и ответы на них есть в книге. Где-то очевидно и прямо, где-то между строк.

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

Еще очень сильно вымораживало то, что подобные наборы рекомендаций есть почти у всех кроме нас. У Scrum методологии - скрам гайд, у программистов - 12 factor app:

https://www.scrumguides.org/
https://12factor.net/ru/

А у нас нету такой штуки. Казалось бы - методология, у которой нету рекомендаций. Как хочешь - так и делай.

И именно в этот момент у меня возникла идея сделать набросок паттернов, которыми я руководствуюсь в работе.

Это переросло в 10 пунктов, которые мы с ребятами из UkrOps очень детально проработали и описали.

На данный момент это выглядит вот так:
https://github.com/Mykolaichenko/devopsfactors

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

А пока предлагаю Вам посмотреть на эту выжимку, если поддерживаете - звезду на гитхабе и лайк, если нет - форкайте и предлагайте правки 😂

Гайз, кто уже почитал статьи Тима Урбана и посмотрел видосы?

Знакомьтесь, это Максим Дорофеев: представитель высокого разума в стиле Урбана.
Айтишник-прокрастинатолог. Он рассказывает о том, как работать меньше и успевать больше.
И вообще кучу инсайтов о нас (выступление на хайлоаде):
https://www.youtube.com/watch?v=fWR5SFhBUWc

В любой непонятной ситуации - думай!