Saboteur

джун девопс - моветон.

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

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

"Пожалуйста, не пишите что надо знать всё, что девопс это не профессия, а практика, что надо помимо линукса знать CI/CD, Kubernetes, Docker и т.д. Я и так это понимаю, но конкретно сейчас меня интересует вопрос выше."

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

Посмотреть заголовки, а точнее https://en.wikipedia.org/wiki/HTTP_referer

Хочу понять что именно нужно знать и уметь писать на Python чтоб я смог считаться Junior DevOps инженером.

Можно вообще не знать питон.
Devops не разработчик на питоне. Это сисадмин в области настройки ci/cd, для чего надо уметь работать с инструментами, которые позволяют в CI/CD, разбираться в том, как разрабатываются сейчас продукты и как они запускаются, разбираться в мониторинге.

И вообще Junior Devops - это моветон. В девопсы приходят или после опыта системного администрирования или опыта разработки. Ну еще изредка могут из L3 перейти.
Но никак не с нуля и сразу в девопсы. Исключения крайне редки и чем-то всегда обоснованы.

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

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

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

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

Следовательно, джуниор-девопс звучит странно.

А значит - нужно начинать с админа, набираться опыта, потом уже подучить ci/cd инструменты и уже потом смотреть в девопс.
Также в девопс можно прийти из разработчиков или тестировщиков (если занимался автоматизацией и настройкой тестовых окружений).
Но в любом случае стадию джуниор нужно пройти до того, как начинаешь думать про ДевОпса.

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

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

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

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

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

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