Хочу изучить DevOps. Какие курсы выбрать?

Вот, ознакомься с кратким перечнем требований

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

Стоит ли смотреть на всякие яндекс практикумы и скиллбоксы?

у них не плохие курсы и если ты начинаешь с 0, то время не будет потрачено в пустую… плюс они иногда объявляют акции в виде гарантированного трудоустройства, что так же важно, так как курсы как правило могут не интересовать работодателей так, как это делает реальный опыт работы

Термин DevOps ничего не означает. Нет такого направления, нечего там учить.

для начала поговорить с программистами и узнать какие у них будут ожидания от devops-ов

Поэтому вот это.

+1

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

Девопс = ленивый админ с тремя работающими извилинами. Принцип примерно такой:

- Накодить один раз, что бы оно было совместимо со всеми юз-кейсами и что бы добавление чего-то там, лимитировалось добавлением переменных.

- Лень делать повторяющуюся работу. Все переменные «в одной папочке», струкрурированны так, что бы юзеры (админы) могли сами добавлять то, что им надо и деплоить не тыкая в тебя палочкой. Если пятилений даун не может задеплоить сам, твой код - говно.

- Гит - единый источник правды. Если чего-то нету в гите, значит юзвери(админы) накосячили и надо провести беседу об автоматизации, тыкнуть носом в папочку переменных или тыкнуть себя носом в то, что ты не автоматизировал или автоматизировал криво.

- Если фича в софтине не существует, всегда есть питон.

- Слушай своих юзверей и автоматизируй то, что им будет улучшать качество жизни.

- Тирлимка от PagerDuty для твоих творений должна идти тебе, а не админам, ты накодил, сам разгребай.

TL;DR: git, python, ansible (~200 хостов), salt/chef (200+ хостов), мозга, ухо работающее, подключенное к мозге. Когда осилишь и запустишь в прод, смотри в контейнеры.

Стоит ли смотреть на всякие яндекс практикумы и скиллбоксы?

Теория без практики - потраченное в пустую время. Смотри на то, что больше всего орёт в PagerDuty и думай как это исправить не используя человеков.

Моя компания разделилась на 2 компании. У первой компании вся инфраструктура остается за ней, а в моей, второй компании нужно системы деплоя, мониторинга, оповещений создать на основе чего-то. Мне хочется узнать какие решения уже есть для этого и на основе чего это сделать.

Например, вопрос: где хранить пароли от базы данных? В самом коде или в ini файлах или в файле docker-compose.yaml или в .env самого сервера?

Или другой вопрос: как лучше делать деплой: поставить gitlab, настроить gitlab-runner, который бы после коммита в мастер создавал docker образ и его отправлял на сервера. А сервера бы этот образ запускали. Оптимально ли это? Какие есть еще варианты и есть какие у других вариантов плюсы и минусы?

Вопросов очень много и цельная картина как что должно работать у меня не складывается.

А что мешает посмотреть как сделано в старой компании и повторить?

В той компании, как и в этой я работаю программистом. В той компании девопса не было, был сис.админ, который перегружен работой.

К каким-то вещам у меня нет доступа на сервер, например к графане. А каких-то вещей просто не было, но они нужны. Например, автодеплой.

Например, вопрос: где хранить пароли от базы данных? В самом коде или в ini файлах или в файле docker-compose.yaml или в .env самого сервера?

Хранить пароли в файлах можно, если они зашифрованные. Все файлы должны быть в гите, включая паролевые, ини, ямлы и т.д. У некоторых тулзов есть встроенная шифровалка типо ansible-vault, salt pillar, etc. У амазона есть SSM paramether store, можно хранить пароли там и тянуть их при деплое. У ажура и жЫсЫпЫ должно быть что-то аналогичное (не работала с ними в проде)

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

Или другой вопрос: как лучше делать деплой: поставить gitlab, настроить gitlab-runner, который бы после коммита в мастер создавал docker образ и его отправлял на сервера.

А как деплоится сейчас? Gitlab неплохой «сферический» вариант «в вакууме». Но подходит ли конктетно тебе, я хз.

Стоит продумать ситстему деплоя по «окружению» (dev, qa, pre-prod, prod). Накатывать код везде одновременно - некомильфо. Клиент может найти багу в пре-проде. Если оно уже в продакшене, это плохо. Да и продакшенов может быть несколько, в разных часовых поясах, изза чего деплоить везде одновременно нельзя. Теги тебе в помошь (git tag). Теги гита можно привязать к тегам амазона (ты же не с жезом работаешь, да? ДА?!).

А сервера бы этот образ запускали.

На чем крутятся твои сервера?

Оптимально ли это? Какие есть еще варианты и есть какие у других вариантов плюсы и минусы?

У амазона есть Code Deploy на пример. Оно может тянуть код из гита или распаковывать файл. Советовать что-то по оптимальности не зная что у тебя там за зоопарк - глупо и по нубски. То что работает у меня, может быть костыолём у тебя и наоборот.

Самая большая ошибка девопсов (даже «самых опытных»)- накодить крутых гламурных фич и бросить это всё дело в сисадминов, мол пользуйтесь и поддерживайте сами, а мы пойдем накодивать дальше. Часто проэкты изза этого протухают, у админов и так дел дохуа, а тут еще непонятная хрень, в которой надо разобраться и потом еще её ковырять... и постигать дзен, когда оно упало в проде в 3 часа ночи, когда до дев не дозвониться.

Начинай с малого. Где у тебя проблемы? 3х часовой деплой? PagerDuty орёт «по расписанию»? Мониторинг ложится изза того, что админы правят конфиги ручками и тупят?

Если ты пришел красивый и сказал «ща я всё запихаю в контейнеры и будет вам счастье!», когда у тебя апач на железном сервере крутится и админы заливают сайты через scp, ты внедришь проблемы, а не решения.

В той компании, как и в этой я работаю программистом

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

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

Читай про икону DevOps-а: https://12factor.net/ru/ Отсюда ты узнаешь про основы и про то, что в коде не должно быть секретов. Каждый раздел этого списка 12 факторов это статья с деталями, например раздел 1 https://12factor.net/ru/codebase Часть из них ты начнёшь понимать потом, после того как набьёшь шишек.

Параллельно изучению дальнейшего прочитай книгу «Проект «Феникс». Как DevOps устраняет хаос и ускоряет развитие компании | Ким Джин, Бер Кевин», она подарит тебе понимание важных концепций, в том числе про важность общения. Она читается как художественная и достаточно быстро, но правильно ориентирует мышление.

Ставь gitlab и учись собирать, тестировать и деплоить им: он сейчас стандарт де-факто, хотя есть ещё 100500 вариантов. В нём нет ничего сложного: по сути пайплайн это шаги из shell-команд. Так ты быстро научишься решать насущные задачи программистов локально и прокачаешься в unix shell scripting. Заодно гитлаб тебе на первое время поможет решить задачу хранения секретов не в коде, а в своих секретах проекта. Есть куча готовых курсов на Udemy или их копий в торрентах.

Затем научись упаковывать твоё хозяйство в докер и затем запускать его на VM с помощью gitlab runner да хоть через docker-compose. Это избавит тебя от проблем конфликта версий в окружениях и отвяжет от конкретных linux-машин.

Если тебе сразу доступен kubernetes, то пропускай этап изучения Ansible, иначе учись конфигурировать свои машины с его помощью и забудь про настройки через ssh. В сторону устаревших chef/puppet/salt даже и не смотри, если у тебя нет лишнего времени на изучение немейнстримных вещей.

Где-то тут стоит научиться в prometheus + grafana для мониторинга и в elasticsearch+filebeat/logstash+kibana для логов.

Дальше разбирайся с Kubernetes, лучше через курс Мумшада https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ В нём самое ценное это лабораторные, которые надо проделать руками. В процессе выполнения лаб научишься работать с https://kubernetes.io/docs/home/ Кластер на kubeadm сейчас поднимается и апгрейдится на раз-два: найди себе 3 виртуалки и подними кубер в них, если недоступен managed kubernetes откуда-нибудь из облака или от инфраструктурщиков.

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

Затем подойдёт время изучения облаков и terraform. И ты уже начнёшь сам понимать что тебе дальше надо качать.

у них не плохие курсы и если ты начинаешь

курсы у яндекс? мой бывший одногруппник, после того как его отчислили пытался записатьс к ним... они тебе скидывают задания, которые ты выполняешь и отсылаешь им. и это стоило около 95тр. это не курсы, а еще один сравнительно честный способ по отъему денег у населения. я был о яндексе лучшего мнения когда-то.

Например, вопрос: где хранить пароли от базы данных? В самом коде или в ini файлах или в файле docker-compose.yaml или в .env самого сервера?

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

Или другой вопрос: как лучше делать деплой: поставить gitlab, настроить gitlab-runner, который бы после коммита в мастер создавал docker образ и его отправлял на сервера. А сервера бы этот образ запускали. Оптимально ли это? Какие есть еще варианты и есть какие у других вариантов плюсы и минусы?

Лучше, если ты собранный образ зальешь в какой-нибудь локальный docker-репозиторий, а сервера уже сами будут из него вытаскивать. Тут как-раз в дело оркестратор обычно вступает - kubernetes, nomad, да даже ansible.

И главное не забыть про мониторинг - поднятые сервисы должны в нем регистрироваться, и отдавать статусы healthcheck’ов. Иначе вся твоя автоматизированная инфраструктура превратится в черный ящих Шредингера

Например, вопрос: где хранить пароли от базы данных? В самом коде или в ini файлах или в файле docker-compose.yaml или в .env самого сервера?

Можно в секретах.

Disclaimer - все нижесказанное основано на моем опыте и является субъективным. Основной упор на прокачку навыков по облачным технологиям, в основном, AWS.

Всегда стоит помнить, что «Хлеб за брюхом не бегает». Пожалуйста, если вы не можете решить проблему, не стоит сразу прибегать в телеграм-каналы и засорять их в стиле «Бен, Ай нид хелп». Уделите малость времени и загуглите вопрос. Также стоит выделить время и выучить английский язык.

Рекомендую следующие книги:

1. Ansible for DevOps: Server and configuration management for humans
2. Terraform: Up & Running: Writing Infrastructure as Code
3. Mastering AWS CloudFormation: Plan, develop, and deploy your cloud infrastructure effectively using AWS CloudFormation
4. Perl Best Practices: Standards and Styles for Developing Maintainable Code
5. Data Structures and Algorithms in Python
6. Test-Driven Infrastructure with Chef, 2nd Edition
7. Infrastructure as Code: Managing Servers in the Cloud

Рекомендую следующие курсы:

1. Adrian Cantril
2. Stephane Maarek
3. Алгоритмы и структуры данных

Рекомендую телеграм каналы:

1. DevOps
2. DevOps Jobs
3. Elasticsearch
4. Kubernetes
5. Docker
6. Церковь метрик
7. AWS

perl в 2022? aws и cloudformation для россиян после 24 февраля? мёртвое и недоступное.

Алгоритмы и структуры данных тому, кто въезжает в devops? Это программерам надо.

Chef в эпоху kubernetes & serverless? Время на ветер.

Добрый день. В моей организации в ближайшем будущем потребуется DevOps. Хочу в этом направлении поработать. Поэтому у меня вопросы к бывалым: с чего начать и какие курсы смотреть? Стоит ли смотреть на всякие яндекс практикумы и скиллбоксы?

побухать с руководством, выйти сразу в начальника местных DevOps`ов - профит :-)

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

1. https://github.com/wmariuss/awesome-devops#resources

2. https://roadmap.sh/devops

3. https://github.com/devsecops/awesome-devsecops

https://devopsdirective.com/posts/2020/11/credential-management/

Термин DevOps ничего не означает. Нет такого направления, нечего там учить.

+2 не более чем очередная свободно трактуемая орг форма.

побухать с руководством, выйти сразу в начальника местных DevOps`ов - профит :-)

Или на поиск работы :) Всё зависит от характера руководства. :)

Disclaimer - нижеописанное является моим мнением и может быть субъективным.

Суть:

1. Все perl счастливы одинаково, все shell несчастливы каждый по своему.
2. Сколько DevOps не корми, все на Запад смотрит.

Perl

Рассмотрим популярные версии дистрибутивов и версии perl.

Во всех версиях есть поддержка perl и в отличие от Python2 никто убирать perl не собирается.

Сейчас perl занимает особую нишу, как язык программирования C. Нет необходимости использовать в повседневной жизни, но знать его нужно. Чтобы понять, что написано в том или ином скрипте, который придется поддерживать. Язык очень стабильный, библиотеки также стабильные и все изменения задокументированы в CPAN. Все что было написано 20 лет будет также работать. С shell, я сталкивался с различными проблемами, например, /bin/sh - это не всегда /bin/bash. Также кроме bash существуют другие оболочки, где некоторые вещи сделаны лучше или хуже. Но если ты написал что-то на perl, то проблем не возникнет нигде.

Отмечу, что указанная мной книга даст лучшее представление о языке и как лучше всего и красиво программировать на perl. Ведь многих от perl отталкивает как многие уродливо программируют на нем.

Я думаю, что и через 10 лет perl-base будет присутствовать во многих дистрибутивах.

AWS

Я не являюсь гражданином РФ, не живу в РФ, не являюсь налоговым резидентом в РФ. Поэтому могу свободно использовать услуги AWS и оплачивать их. Но даже если вы являетесь гражданином РФ, живете в РФ, то следует заниматься изучением AWS - потому что это флагман облачных технологии.

CloudFormation

Мой опыт говорит мне, что хейтеры CF также не освоили Terraform.

Алгоритмы и структуры данных

Алгоритмы и структуры данных нужно знать. Не на пятерку конечно же, можно и на троечку.

А зачем? - Работа DevOps - это взаимодействие с программистами и часто бывают конфликты с программистами, у которых все на их компьютере работает, а в проде не работает. Нужно аргументированно критиковать их работу и показывать, что они не совсем корректно реализовали свои программы.

Chef

Даже в 2022 году существуют корпорации с жестким регламентом работы и внедренным ITSM, Complaince и прочими ограничениями. В этих организациях не принято писать плейбуки на Ansible и самовольно пушить их в инфраструктуру. В таких организациях нужны централизованные системы управления конфигурации. Вышеуказанная книга поможет понять как все же правильно настроить и реализовать такую централизованную систему.

В добавок, не все можно затащить в K8S. Остальные системы тоже нужно поддерживать в рабочем состояние, желательно, чтобы еще был аудит действий для СБ. Остальные системы могут быть даже важнее чем кластер(ы) K8S, например, базы данных, accounting.

DevOps смотрит на запад

Однажды один умный человек сказал, что у каждого человека есть своя капитализация. И есть вполне рабочие способы поднять/уронить капитализацию. Считаю, что каждый человек в ДевОпс/Администатор должен стремится улучить свою капитализацию через освоение новых навыков и технологии. А еще лучше получить работу за рубежом, где бюджеты больше и стек технологии более актульный.

Новые книги

1. The Art of Monitoring by James Turnbull
2. Monitoring with Prometheus by James Turnbull

Для работы за рубежом начинающим девопсом нужно осилить kubernetes и пройтись по DevOps и Developer сертификациям AWS. Architect потом, для души. 100500 инструментов as a service хватит на безбедное существование без копания в экскрементах ушедших эпох (не забывайте повторять это на собеседованиях чтобы удвоить или даже утроить шансы найма). А уже после этого можно подтягивать кастомные вещи: хочу всё это сам, поэтому shell scripting, gitlab, prometheus & grafana, loki, elk, jaeger, terraform, vault, nexus, ansible, python. А то ж послушать форумы, так ещё и операционные системы писать на ассемблере писать и 1С на всякий пожарный изучить предложат прежде чем думать о работе девопсом.

Уважаемый, а сколько у вас жизней? По стеку технологии даже коту не хватит его жизней на освоение. ;(

Уважаемый, а сколько у вас жизней? По стеку технологии даже коту не хватит его жизней на освоение. ;(

Именно потому, что ресурсы ограничены и надо специализироваться, я и предлагаю тем, кому по-прежнему доступен AWS не распыляться на 100500 вещей, каждую из которых можно осилить потом по мере её необходимости, а сфокусироваться на распространённой специализации, обучение которой давно поставлено на поток. Есть готовые курсы подготовки Kubernetes CKA где тебя научат в Kubernetes и есть куча подготовительных курсов по AWS-сертификациям Developer & Devops пути, где тебя научат строить инфраструктуру из готовых кубиков и пайплайны. На выходе за фиксированное время получится умение очень много чего сделать прямо здесь и сейчас и появится понимание концепций этого «очень много чего». А там уже по потребностям можно эти отдельные концепции заменять на сторонние решения.

DevOps это ни что иное как перекладывание ответственности ради экономии средств. «Пусть разработчики(dev-) сами займутся поддержкой(-ops).».

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