ДевОпс Інженер 🇺🇦
5.05K subscribers
31 photos
4 videos
293 links
ДевОпс Інженер - авторський канал @mukolaich - Head of DevOps у SQUAD.

Я розглядаю технології та рішення, роблю огляд архітектурних проблем, включаючи контейнери, оркестратори, скейлінг, моніторинг, etc.
Download Telegram
Всем привет!
Меня зовут Олег, и я ДевОпс инженер. 🙈
Я веду 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. В народе нас часто именуют "Девопсами". Как вы к этому относитесь?