👆👆👆 Продолжение (выводы) 👆👆👆

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

2️⃣ Kubernetes и Swarm держат более 75% процентов рынка контейнеров. Это поддерживает гипотезу о MVP на докер сворм, а продакшн реди - на k8s. Получается странная ситуация - хоть Swarm и "мертвый" проект, но пользуется популярностью. Есть несколько вариантов - или Docker сам депрекейтнет поддержку (в ближайшее время сомнительно) или кубер станет сильно проще и удобнее для мелких проектов. Второй вариант прослеживается уже сейчас - появление кучи PaaS, оберток и врапперов возле кубера. Делать акцент на изучение Mesos/Nomad/другое я бы не стал.

3️⃣ Никто не хочет работать с компаниями в которых такой себе менеджмент, или технологии страдают. В то же время если зп сильно выше рынка - то все норм, можно работать.

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

Не переключайтесь!

Подготовил данные по нашим ЗП: https://goo.gl/AFyuoJ

Это я взял из исходников последнего опроса на доу.

Что получается (для Киева, и для DevOps):
- это беглый взгляд, без аналитики 😱
- если зп 5к+ - то типа это красава, в среднем по рынку чуть меньше 🔥
- очень много киевских ребят с дельтой 3-4к, это типа норма 😉
- если меньше 3к - прецедент подумать что можно улучшить 🤔

Есть очень интересные ребята:
- Киев, 6,9к, продукт (мем или нет?)
- Одеса, 8к, продукт
- Киев, 7к, продукт

Получается ... Очень даже неплохо) 💵💵💵

Если что - меня можете там не искать, я не голосовал 😂

Вообще - о ЗП говорить не принято. Но это во всем остальном мире, в канале - можно.

Заряжаю всех на зп побольше 😇

Ого! Совсем скоро Jenkins можно будет в yaml! 🔥

https://jenkins.io/blog/2018/07/17/simple-pull-request-plugin/

Что это значит для нас:
- Jenkins этим решением начнет отжимать клиентов у других CI
- меньше Groovy
- будут таски на импрувмент - “а перепишите нам дженкинсфайл”
- проще будет понимать, что же происходит
- эта штука полюбому будет ломаться и не работать в первых итерациях 😒

Советую сыграть на опережение, и закинуть таску в беклог. 😉

Best practices - как уметь в контейнеры! (от Google) 🔥

▶️ Детальнее как всегда по ссылке, а тут - самое мясо:
1. один контейнер - один процесс (и сабпроцессы)
2. нужно уметь хендлить сигналы правильно
3. обязательно использовать докер кеш
4. чистить контейнер от всего ненужного по-максимуму
5. делать контейнер как можно меньше
6. правильно тегировать и версионирвать контейнеры
7. акуратно выбирать родительский паблик-имедж

https://cloudplatform.googleblog.com/2018/07/7-best-practices-for-building-containers.html

Очень даже достойные советы, говорят все знаменитые архитекторы их знают наизусть. 😂

Прямо сейчас иду на Go митап, если будет что-то супер интересное - вы будете в курсе. Хорошего вечера! 👍

Тестирование Docker имеджей

Docker имеджи тестируют не только лишь все. Вернее мало кто может это делать. 😂

Я прочитал все первые 10 результатов из Google, которые относятся к тестированию образов, и кое-что понял. 👇

Почти никто не тистирует имеджи после сборки.

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

▶️История тестирования примерно такова:
1. Сначала никто не тестировал 😱
2. Потом решили писать скрипт test_image.sh, копировать его в имедж, и там же его запускать (фейспалм)
3. Поняли что и так слишком много bash в этом мире, и врапнули goss. Получился dgoss (эволюция)
4. Google посмотрел на это все, и запилил container-structure-test (зачем?)
5. Мы сейчас тут

Субъективно container-structure-test не очень юзер френдли, а вот dgoss очень даже ничего.

Сами посмотрите:
👉 goss: https://github.com/aelsabbahy/goss
👉 dgoss: https://github.com/aelsabbahy/goss/tree/master/extras/dgoss
👉 container-structure-test: https://github.com/GoogleContainerTools/container-structure-test

Hey guys! Ну что, как дела? 😉

Есть немного апдейтов:
👉 18-го числа будет девопс-дайджест, так что если у кого-то ивент или есть новости - фил фри ту нотифай ми
👉 сейчас у меня небольшой trip в USA, и вот до этого времени реально не получалось ничего отписать
👉 кокосовая вода очень неприятная и невкусная, несмотря на все "рай, кокос, наслаждение"
👉 пляж в LA реально как в GTA

Теперь по теме: livenessProbe, readinessProbe 😂

Хорошая статья на почитать вечером перед сном или на работе с чаем о хелсчеках в кубере.
Там описана разница между livenessProbe и readinessProbe, общие принципы настройки и примеры (http, shell).
Это одна из концептуальных основ которые нужно знать, и в этой статье в общем есть все что нужно.

https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e

Подписчик посоветовал еще статейку на тему хелсчеков кубера:

Ну, теперь мы точно покрыли эту тему. Спасибо, Игорь! 🔥

https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Setting-up-health-checks-with-readiness-and-liveness-probes.html

Друзья, девопсовое событие осени 🌧🌧🌧

Киев, 12-13 октября (это когда на улице все ужасно, а дома скучно) будет большая конфа DevOps Stage, с такими докладчиками:
▶️ Philipp Krenn из Elastic - отличный спикер, общался с ним в Натюрлихе, рекомендую
▶️ Jeffry Molanus - CTO at MayaData - считает себя Богом стореджей и спонсирует опенсорс, будет рассказывать про кубер
▶️ Thiago Assuncao de Faria - DevOps/AI Lead - готовил ML еще когда это небыло мейнстримом, и будет рассказывать как это все умное готовить в DevOps стиле
▶️ еще куча знаменитых чуваков, которых я не знаю

3 трека, 2 дня екшна, тусовка, куча пустых слотов в расписании, еда, троллинг - все как положено.

Пока еще можно купить билет за 150$ как early birds, но не забудьте спросить своего менеджера, есть ли у вас бюджет на конференции (а он скорее всего есть).

Лично я отношуcь очень тщательно к self-education и continious improvement, поэтому планирую быть на мастер-классе "The Phoenix Project DevOps Game" и 100% в первый день.

Как всегда, ссылка: https://goo.gl/UyMc5Q
И еще промокод на -10%: devopscommunity_promo_code 😱

Вас ожидает лучшее:
https://dou.ua/lenta/digests/devops-digest-21/

Как стать топовым Kubernetes contributor
Я не знаю, но кое-какими мыслями поделюсь.

Вчера сходил на местный Kubernetes митап в Palo Alto. Если бы сегодня еще один был, я бы тоже пошел. Еда вкусная (пицца, жареная курица), пивас нормальный (не запомнил), спикеры мощные. 🍕🍺

У нас часто бывает, приходишь на конфу - а там лажа какая-то, ну реально. В долине такое, наверное, не прокатывает - аудитория очень лояльная, все ведут себя очень сдержанно, даже на спорных моментах. Люди просто встают, и идут пить пивас с пиццей. (см. выше) 👆

Подсмотрел на митапе 2 практики, которые и так знал:
👉 1. Записать демку на видос, и показывать видос
👉 2. Иметь в запасе суперсильного архитектора, который поможет ответить на стремные вопросы

Также очень понравилось, что ведущий был из Google и помогал менеджить все острые углы.
И в нем я для себя открыл несколько инсайтов:
👉 - он тоже человек
👉 - он контрибьютит в kubernetes/kubernetes

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

Они тегают Issues, и среди этих тегов есть несколько интересных:
💥 help wanted: https://go.k8s.io/help-wanted
💥 good first issue: https://github.com/kubernetes/kubernetes/labels/good%20first%20issue

Если посмотреть немного дальше в Issues, то можно найти очень простые. Вот смотрите:
▶️ https://github.com/kubernetes/kubernetes/issues/58640

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

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

Для тех, кому скучно читать всю книгу Site Reliability Engineering

👇 всего одна глава (почти как саммари) 👇

https://landing.google.com/sre/book/chapters/service-best-practices.html

Ребята! Я заболел 🤒🤕

Но уже выздоравливаю. Прилетел, и на следующий день заболел. Очень обидно(

А пока я поправляюсь, посмотрите какую крутую статью написал Юра Рочняк в блоге на медиуме:
https://medium.com/preply-engineering/lambda-edge-and-where-to-find-it-92b7c9c37f22

🔹Во-первых, у него в Preply все очень неплохо, и хорошая экспертиза в serverless-related штуках;
🔹Во-вторых, завести блог, да еще и на английском - многого стоит.
🔹В-третьих, это действительно технически грамотная статья о Lambda@Edge + Cloudfront + Terraform;

Preply, you rock! 👍👍👍 (нажамкайте Юре пальцев вверх, и наверное он напишет еще что-то полезное)

Уууух как круто прошла конфа! 😎

Мне понравилось, что ребята из fwdays очень классно проработали все моменты: после обеда были лайтовые доклады на общие темы, а хардкор примерно в 12 (когда все уже проснулись, но еще не устали). Очень порадовали сами доклады и треки - сложно было выбрать что и куда идти, хотелось быть везде и одновременно))

Отдельно могу отметить юмор Александра Соловьева из "магазина одежды", топ-хедлайнера конференции, он очень позитивно завершил этот продуктивный день. 👆

В целом впечатления крайне положительные, не считая непонятного мне конфьюза с Svitla systems, однозначно пойду в 2019.

Для тех кто не попал, или был на OSDN есть записи докладов по трекам:
🔥main stage: https://www.youtube.com/watch?v=MbZgXZBxgV8
🔥track a: https://www.youtube.com/watch?v=sVhsY-kYi0Y
🔥track b: https://www.youtube.com/watch?v=i5-sFUqVhrs
🔥track c: https://www.youtube.com/watch?v=Lxop86CIfg0

Расписание докладов (для навигации) есть на сайте:
▶️ https://fwdays.com/en/event/highload-fwdays-2018#program-event

А я пошел внедрять на практике этих всех сферический коней в вакууме 🙈

Для тех, кто любит смотреть конференции на работе 😂

Подьехала запись докладов с OSDN (спасибо Mykola Marzhan).

Доклады удобно порезаны на видео, рекомендую посмотреть на Lennart Poettering - создателя systemd.

https://www.youtube.com/playlist?list=PL_O8YSX8ckffdJPhMNU87ZgVqq5Y-OAGj&disable_polymer=true

Если у вас github и kubernetes манифесты - эта штука будет очень кстати: она интегрируется прямо в репозиторий (вкладка Checks) и следит, чтобы все было в порядке.
▶️ https://github.com/urcomputeringpal/kubevalidator

Но даже если у вас не github, то можете запилить проверку прямо в CI процесс:
▶️ https://github.com/garethr/kubeval

Полезно?

Импорт/экспорт Grafana dashboards

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

И этих дашбордов более нескольких десятков.

Сразу дока, API - и погнали. Есть на импорт/экспорт, а значит кто-то уже писал автоматизацию.

Полез я в интернет, и сразу наткнулся на github gists, где разные ребята в коментах писали свои версии скриптов. Но вроде же дожно быть что-то более продакшн реди? И да, есть либа:
💥 https://github.com/hagen1778/grafana-import-export

Она заэкспортила дашборды, и пришла очередь фиксить json.

Для этого есть тулза jq, не самая удобная, но работает. Пример, где в slug меняется поле:
jq '(.meta.slug |= "aws-" + .)' $filename - на поиск синтаксиса ушло 2 чашки чая 🙁

Датасорсы в графиках лучше менять с помощью sed:
sed 's/"datasource": "influxdb"/"datasource": "new-datasource"/g' - через jq тяжело обойти все вложенные ключи, и не сломать лишнего

Обязательно нужно поменять title - иначе ничего работать не будет (упадет с ошибкой):
jq '(.dashboard.title |= "AWS | " + .)' $filename - тут добавляется 'AWS | ' и существующее имя дашборда

Это все очевидные вещи, но в конце ждал сюрприз. Ошибка The dashboard has been changed by someone else. Хм, что же это значит? Сразу мысль подсказала посмотреть на ключи version и id. Ключа с версией небыло, а вот id был. Где-то на гитхабе советовали засетить его как null, или вообще удалить. Ну я и удалил:
jq 'del(.dashboard.id)' $filename

После этого дашборды заэкспортились и все взлетело.

Надеюсь, сохранил вам несколько часов гугления и набивания шишек 😄

Давайте поменяем Bamboo на Concource CI

Если у кого-то проблемы проблемы с Jenkins/Travic/Circle/otherCI/etc, то скорее всего причина не в туле: причина в подходе

There’s no perfect CI. They all have different features

https://cintia.me/blog/post/ci-tool/

​​Знакомьтесь: это Volodymyr Tsap, у него своя девопс-контора и он зарабатывает явно больше 6.9к 💵💵💵

Как? Что нужно учить? Что нужно знать?

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

Думаю, такая инфа стоит явно дороже билета на конфу:

https://devopsstage.com/

P.S. Вова, будешь должен!

Если кто-то выпал на месяц и очень об этом сожалеет: актуальный девопс-дайджест:
https://dou.ua/lenta/digests/devops-digest-22/

Еще недавно проскакивала статейка, как стать девопсом (формулировка 😂):
https://dou.ua/lenta/articles/senior-devops/

И еще по версии DOU в разделе DevOps в среднем всего 1,6 отклика на вакансию: это отлично. Есть спрос, но маловато предложения. 😎

Нашел очень интересный топик на Stackoverflow, там есть сравнение основных решений по генерации Kubernetes манифестов: Helm vs Draft vs Ksonnet

https://stackoverflow.com/a/48896587/5004288

Что интересно, в SRE Workbook написано: для простых апок и инфраструктур делайте YAML (как удобно, helm etc - не важно), а для средне-сложных смотрите на jsonnet/ksonnet. (Это не точная цитата). Я задался вопросом, почему так - и нашел ответ по ссылке.

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