Всем привет!
Меня зовут Олег, и я ДевОпс инженер. 🙈

Я веду DevOps дайджест на dou.ua, пишу статьи на хабр, и периодически выступаю с докладами на конференциях 💪💪💪

Тут планирую публиковать выборки из качественных статей, решения задач над которыми сейчас работаю, и интересные мысли. 🤔
Stay tuned! 🤓

Сегодня крутил 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?

Интересно?