Практический roadmap по DevOps 2026 для русскоязычных, с акцентом на реальные навыки и требования рынка.
Key Takeaways
- Для успешного старта в DevOps не обязательно глубокое знание языков программирования.
- Git — базовый и обязательный инструмент для работы с конфигурациями и кодом.
- Практическое освоение Linux и понимание процессов — ключ к успешному трудоустройству.
- Мониторинг и управление процессами — важные навыки для работы и собеседований.
- Docker и Kubernetes — современные стандарты для девопс-инженеров.
What the video covers
- Видео предлагает уникальный и рабочий roadmap по DevOps, ориентированный на русскоязычный рынок.
- Отмечается, что глубокие знания языков программирования не обязательны для старта в DevOps.
- Рекомендуется начинать обучение с Git, так как это основа для работы с конфигурациями и кодом.
- Дается подробное руководство по изучению Linux с акцентом на практическое использование и ключевые темы, такие как процессы и systemd.
- Объясняется важность понимания процессов в Linux, включая команды ps aux, kill, и понятия зомби-процессов и процессов-сирот.
- Рассматриваются темы мониторинга системы с помощью top и htop, а также разъясняется работа oom-killer.
- Дается обзор практических знаний по RAID и сетевым технологиям, которые востребованы на собеседованиях.
- Подчеркивается важность понимания модели OSI и уровней сетевого взаимодействия.
- Обсуждается знакомство с Docker и Kubernetes как ключевыми инструментами для девопс-инженера.
- Видео предлагает полный roadmap с дополнительными материалами в Telegram-канале.
Chapters
- 00:00Введение и обзор DevOps roadmap
- 02:09Знакомство с Git и его роль в DevOps
- 04:23Основы работы с Linux и терминалом
- 06:49Управление процессами в Linux и systemd
- 09:25Мониторинг системы с помощью top и htop
- 12:00Основы RAID и сетевых технологий
- 17:00Модель OSI и сетевые уровни для собеседований
- 19:38Введение в Docker и Kubernetes
- 23:32Заключение и дополнительные ресурсы
Full Transcript — Download SRT & Markdown
Speaker A
Всем привет, друзья. Это канал Просто DevOps. И вам очень повезло, что вы смотрите именно этот ролик, потому что в нём мы расскажем единственный нормальный и рабочий roadmap по DevOps в русскоязычном сегменте. Пойдём с самого начала. Вот вы решили вкатиться в DevOps. Идёте
Speaker A
гуглить roadmap, чтобы как-то выстроить свой путь, и с высокой вероятностью вы найдёте DevOps roadmap на roadmap.sh. И дай бог, чтобы вы по нему не пошли. Ну, столько лишнего, особенно уж для рынка. Либо вы найдёте какой-нибудь другой roadmap, где наоборот будет
Speaker A
что-то типа: "Ну вот, короче, докер нужен. А что конкретно в этом докере? А зачем он нужен? А почему порядок изучения именно такой, а не другой? О, а ещё любят начать путь с изучения языков программирования в этих roadmapах. Прямо
Speaker A
вот обязательный фундамент. Ну да, ну да, спасибо, очень полезно. Верю. Короче, мы решили эту проблему.
Speaker A
Представляем вам первый полезный roadmap по девопсу на YouTube. И, как я уже сказал, для старта в девопсе глубокие знания языков программирования вам не нужны. Почему я так уверенно об этом говорю? Смотрите, наши ребята за последние 2 месяца прошли больше 200
Speaker A
собеседований, 200 реальных собеседований в разные компании. И знаете, сколько раз за эти 200 встреч их реально спросили хоть о чём-то, связанном с языками программирования?
Speaker A
Пять раз максимум. Потому что реальность рынка такова: задач на кодинг у девопса мало. А если такая задача вдруг и прилетает, то вы не сидите и не пишите код с нуля. Вы просто открываете любую нейронку, пишете промт, она генерит
Speaker A
скрипт, и вы его просто дописываете под свои нужды. Так что сегодня мы пойдём от обратного. Мы выкинем весь мусор и построим реальный рабочий roadmap.
Speaker A
Roadmap человека, который хочет устроиться на работу и начать зарабатывать деньги, а не учиться до пенсии. Мы пройдёмся по каждому пункту и честно скажем, что надо учить обязательно, а что можно скипать.
Speaker A
Кстати, полный roadmap из этого видео и даже чуть-чуть больше вы найдёте у нас в Telegram-канале. Ссылка в описании. А мы продолжаем. Здесь я скажу не самую популярную мысль, но тем не менее: не надо начинать с Linux. Лучше стартануть с Git, потому что изучить
Speaker A
его можно быстро, а заодно войти в рабочий ритм. Почему именно с Git и почему это важно именно для нас, а не только для разработчиков? Потому что все конфиги, пайплайны, манифесты, ямлики и так далее — это код. И этот код должен
Speaker A
где-то храниться, версионироваться и меняться. При этом неважно, будет это GitHub, GitLab, BitBucket или что-то ещё.
Speaker A
Важно, что всё это строится на одном и том же Git. К тому же, как я уже сказал, он учится за один вечер. Ну, плюс-минус. Вам нужна база, вот эти пять команд. Плюс понимать, что такое теги, ветки и как между ними переключаться.
Speaker A
Могу сказать, как я сам учился им пользоваться. Я просто сделал себе репозиторий и начал пушать туда свои конспекты в формате Markdown. Кстати, научиться оформлять md-файлы тоже лишним не будет, потому что в этом формате пишутся все README файлы, вся документация к
Speaker A
проектам, да и в конце концов все нейронки рендерят свои ответы тоже в формате Markdown. А профит тут в том, что далее, когда вы будете учить Linux, наш следующий пункт, а потом остальные инструменты и технологии, вы будете каждый день писать конспект, коммитить и
Speaker A
пушить и, может быть, ещё как-то экспериментировать. И тогда к моменту, когда вы закончите с теорией хотя бы по нескольким темам, все гитовые команды уже будете набирать на автомате. А сейчас мы как раз переходим к Linux.
Speaker A
Здесь самое главное — это быть аккуратным и не лезть в сложные вещи раньше времени, потому что Linux достаточно большой, чтобы погрузиться в него плавно. И самое главное, можно сказать, ключевое действие, которое надо сделать — это поставить Linux себе на
Speaker A
компьютер, в идеале второй системой. Но только не просто поставить, чтобы он лежал, а надо начать на нём жить.
Speaker A
Попробуйте выполнять свои обычные задачи там. И тут начнётся веселье, потому что, скорее всего, у вас отвалится звук или слетят драйвера, или разрешение экрана будет кривое. И пока вы будете гуглить, как починить это, как починить то, вы перелопатите кучу форумов, скопируете
Speaker A
сотни команд в терминал и ещё 100 раз их перепечатаете. И сами того не замечая перестанете бояться терминала и поймёте, что Linux максимально податлив, если знать, куда нажать и что написать в этот самый терминал. И сначала база команд будет простой: как переходить из одной
Speaker A
папки в другую, как создавать директории и файлы, как удалять папки и файлы, как запускать скрипты, как отредактировать файл прямо в терминале. И я не буду сейчас говорить, что лучше: Nano или Vim, однако, если выбрали Vim, то вот вам очень классный ресурс для его
Speaker A
изучения. Сами проходили, всем советуем, пройдите и вы тоже. И когда консоль станет привычной, надо переходить к темам, которые реально нужны в работе и которые, к тому же, спрашивают на собеседованиях. Их, на самом деле, не так много. И первое из них — это процессы.
Speaker A
Пожалуй, одна из самых важных и больших тем в Linux вообще. И в целом, это логично, потому что, во-первых, без понимания процессов вы не сможете понять, почему система тормозит или почему упало приложение. А, во-вторых, это, наверное, топ-одна тема на
Speaker A
собеседованиях по Linux. Вас будут гонять по ней очень плотно, и поэтому тут надо хорошо разобраться. Самый базовый инструмент здесь — это команда ps aux, потому что когда вы её вводите, вы видите снимок всех процессов в системе на тот момент, когда команда была
Speaker A
введена. И самое главное, что нужно оттуда выцепить — это PID, то есть уникальный номер процесса. По сути, весь траблшутинг строится на том, что вы находите зависший процесс или процесс, который упал с ошибкой. Смотрите его PID и если он не отвечает, прописываете
Speaker A
команду kill. В большинстве случаев процесс завершится. А на тех же собеседованиях по процессам могут задать вообще очень много вопросов. Если взять какие-нибудь самые заезженные из них, то это будет, например, что такое зомби-процесс? А это когда процесса уже нет, но запись в
Speaker A
таблице процессов о нём всё ещё осталась. Или что такое процесс-сирота? А это когда процесс-родитель умер раньше ребёнка. Дальше надо разобраться в systemd. Это система инициализации. По сути, главный процесс, который запускает всё остальное, если не вдаваться в
Speaker A
подробности. Вам, как человеку, который хочет стать девопсом, нужно понимать, что это такое, чем он отличается от старой системы init, и нужно уметь писать простой unit-файл или хотя бы знать, как он пишется. А знать это нужно как минимум для того, чтобы уметь
Speaker A
сделать так, чтобы сервис на Linux запускался автоматически после перезагрузки. Это прикладная задача, которая периодически нужна в работе.
Speaker A
Потом надо разобраться с oom-killer, потому что это важно и для работы, и для собеседований. К тому же он далее потребуется ещё и в Kubernetes. Ну а сам по себе killer — это механизм, который включается, когда на сервере заканчивается память.
Speaker A
Он выбирает жертву и убивает её. И вам нужно понимать, как он выбирает процесс для завершения и можно ли защитить важный процесс. Спойлер: можно. Ну а на собеседованиях, например, в последнее время часто задают вопрос, что такое директория /proc. И вам нужно знать, что
Speaker A
это псевдофайловая система, через которую можно посмотреть всю информацию о ядре и процессах. Все команды типа ps, aux и htop берут информацию именно из директории /proc. Разберётесь со всем этим и считайте, что 80% вопросов по Linux, именно по процессам, закроете.
Speaker A
Идём дальше. И после того, как вы разобрались с процессами, что это такое и как они себя ведут в системе, можно переходить к теме мониторинга системы.
Speaker A
Опять же, самая-самая база — команды top или её более новая версия htop. Или можно на каком-нибудь GitHub найти ещё более продвинутые утилиты мониторинга. Но самые популярные именно эти две. Они чаще всего будут на серверах на работе.
Speaker A
И ваша задача — изучить, что означают те или иные параметры в top, и научиться их декодировать. Кстати, сейчас самый популярный вопрос на собеседованиях именно про декодирование. Что означают все параметры в top, типа SI, VI и так далее. Ну а вообще понятно, что в мониторинге
Speaker A
первое, куд
Speaker A
нас, кстати, было подробное видео про Load Average. Вот оно в подсказке. И это крайне важная и удобная метрика, которой надо уметь пользоваться. И по нашей статистике Lot aage до сих пор остаётся самым популярным вопросом по Линуксу на собеседованиях. Причём спрашивают не
Speaker A
только, что такое Load Average, а дают различные ситуации. Типа у тебя Load average 200, а система работает нормально. Что это означает? И тут, кстати, мы возвращаемся к процессам, потому что надо знать, какие процессы учитывает Lot Average. А дальше мы
Speaker A
переходим к памяти. Из практических задач здесь нужно уметь диагностировать, например, проблему, когда какой-то сервис на условной Джаве или Питоне отожрал 90% всей оперативки, а цифры продолжают расти. Причём найти это очень просто. В том же топе или аж топе можно
Speaker A
отсортировать процессы по памяти и посмотреть на колонку. Там найдёте этот процесс и уже зная, как убивать процессы в Линуксе, сможете эту проблему порешать. Или, допустим, процессор работает нормально, с памятью всё хорошо, а сервер суперсильно лагает.
Speaker A
Тут, скорее всего, проблема с ожиданием ввода-вывода. Называется это его вейт. В том же топе есть параметр WA, как раз-таки вейт, и он позволяет увидеть эту проблему. Если этот параметр высокий, это значит, что процессор не работает, а ждёт, пока жёсткий диск
Speaker A
удосужится что-то записать или прочитать. И это часто возникает, например, с базами данных. Они чаще всего насилуют диск.
Speaker A
И вот мы поняли, что такое процессы, научились мониторить систему. И последний большой блок - это всё, что связано с диском. Тут действует такой закон, и вы наверняка понимаете, что место на серверах заканчивается всегда.
Speaker A
Это неизбежно. И обычно это происходит в самый неподходящий момент. Приходит арт, и мы видим, что всё плохо. Для работы с дисками в первую очередь существует две команды. Первая - это DF, команда, которая показывает общую картину по всем дискам. Вы её вводите и сразу видите в
Speaker A
процентах, сколько занято места на всех дисках и разделах. А вторая команда - когда мы уже нашли, в каком разделе проблема, идём туда и пишем вот эту команду. Она пробегается по всем директориям и выдаёт, что, например, вот эта директория весит 1 ГБ, а вот эта р
Speaker A
весит 50 ГБ. Заходим туда, повторяем ту же команду и находим, что какой-нибудь файл раздулся до невероятных размеров, потому что кто-то забыл настроить ротацию. А дальше от этого отталкиваемся и траблшутим проблему. Вот эта связка DF, чтобы посмотреть общее, и чтобы
Speaker A
найти конкретное - это абсолютная база в работе с дисками. Ещё важная тема - это айноды. На сабесах, кстати, очень любят спрашивать про ситуацию, когда DF показывает, что место есть, а система говорит, что диск переполнен. И это означает, что закончились как раз-таки
Speaker A
айноды. По сути, это записи о файлах в файловой системе. И такая ситуация может произойти, когда на диске миллионы мелких файлов. Плюс нужно понимать и знать типы файловых систем. Тут всё просто. Самое популярное - это XT4 для больших файлов. XFS и всякие доптипы,
Speaker A
например, TMPFS, которые пишет в оперативку, либо Overlay для докера. И ещё важная вещь, которую нужно понимать - это механика команды Маут. В Линуксе любой диск, флешка или сетевое хранилище - это просто блочное устройство, которое нужно примонтировать какой-то папке. Ещё
Speaker A
можно поверхностно изучить рейд-массивы. В проде диски сами по себе не живут, они могут умирать, и это нормально. Поэтому, чтобы данные не исчезли вместе с диском, используются как раз-таки рейд-массивы.
Speaker A
Не надо уметь их собирать, но знать уровни рейда было бы неплохо, особенно для собесов. Тут, в принципе, всё просто. Рейд один - это когда данные пишутся на два диска параллельно. Рейд ноль - когда пишутся последовательно. И это чередование и проблемный тип, потому
Speaker A
что если сдохнет один диск, то данные потеряются все. А самый популярный тип, особенно для баз данных, - это RID й 10, комбинация Rй 1 и Rй 0. Ещё есть Rй 5, но хрен с ним. Дальше можно было бы
Speaker A
изучить, что такое LVM и как он устроен, потому что он позволяет очень гибко работать с дисками, создавать physical волю, волюм группы и так далее. Можете почитать про это сами. На самом деле штука полезная. Ну и, наконец, одна из
Speaker A
возможных практик, достаточно хорошая и кайфовая. Чтобы закрепить всё это не только в теории, а на практике, можно сделать следующее. Попросите любую нейронку, там, GPT, Cloud и так далее, неважно, что есть сгенерировать вам код простейшего приложения фнд, бэкэнд и
Speaker A
база, но с одним условием. Никакого докера и никаких девавсовых штук. У вас должно быть только голое приложение. А ваша задача - запустить всё это дело на своём Линуксе руками. И вот здесь вы помучаетесь, но зато с огромной пользой,
Speaker A
потому что если приложение работает, например, на Пайthне, разберётесь с PP, как ставить зависимости и почему версии могут конфликтовать. Если это условный Note JS- это ещё лучше, узнаете про npm.
Speaker A
Если это Java, тоже хорошо, потому что, во-первых, много микросервисов на ней написано, а, во-вторых, разберётесь с Мавином. Ну, а в качестве базы лучше выбрать Pastгress, потому что он, во-первых, самый популярный, а, во-вторых, опять же, это полезно, как его установить, какую версию выбрать,
Speaker A
как создать пользователя, выдать права, открыть порт, создать базу и так далее. Если хотя бы раз пройти этот путь руками, при этом неважно, насколько сильно вы будете обращаться к нейронке или документации или ещё куда-то. Самое главное каждую непонятную вещь
Speaker A
разбирать, потому что всё это в совокупности даст вам понимание, как всё работает. И потом, когда мы перейдём к докеру, это ещё окажет большую услугу. И тут ещё хочу напомнить о том, что полный Radmap, что и как делать, зачем, в каком
Speaker A
порядке и насколько подробно лежит у нас в Telegram-канале. Ссылка в описании. А мы продолжаем. Кстати, на этом этапе мы подходим уже к сетям, потому что сети - это неотъемлемая часть Линукса, ну и неотъемлемая часть работы девопса. И обычно сети советуют учить по толстым
Speaker A
книгам тоненбаума, начиная с физики, с кабелей оптоволокна. Но нам это не нужно. Нам нужно изучить практические вещи с точки зрения того, что может встретиться на работе и теоретически, что чаще всего спрашивают на собесах с точки зрения сетей. И если вы будете
Speaker A
делать практику из предыдущего блока, вы в любом случае столкнётесь с сетями. Потенциальные ошибки могут быть такие.
Speaker A
эээнд не увидел базу, потому что порт закрыт или сайт не открылся в браузере, потому что не знаете свой IP или firewall блочит порт. И с этого можно начать практиковаться. И не нужно быть каким-то суперсетевым инженером, выучиваться на отдельную профессию и так
Speaker A
далее. Нужно знать базу диагностики и траблшутинга в Линуксе. Условные команды IPA, Pink, SS или Netstat с нужными флагами. И две последние команды, в том числе, понадобятся и для собесов, потому что часто спрашивают вопрос, что-то типа вот мы запустили приложение на Линксе и
Speaker A
оно упало, потому что порт уже занят каким-то другим сервисом. И как раз-таки, чтобы узнать, какой сервис забрал порт, мы используем SS либо же Netstat с вот этими флагами, которые показаны на экране, и узнаём, какой сервис занимает порт. Дальше стоит
Speaker A
перейти к очень важному инструменту в сетях и вообще в работе devopса. Это инжинкс. И здесь опять же его не нужно знать на уровне синьора, но нужно уметь настроить как реверс прокси. То есть это когда запрос приходит накс, а сам уже
Speaker A
перекидывает его на ваше приложение. Кстати, прожикс был ролик. Плюс надо понимать основы конфигов Enin, как он вообще работает, что в конфиге можно указывать, как его базово настроить. А ещё есть такая вещь, которую тоже часто спрашивают, как правильно применить
Speaker A
изменения в конфигурации. И здесь нужно знать разницу команды Reload и RestР, потому что убивает процесс и сбрасывает подключение клиентов, а Reload просто перечитывает конфиг на Литу, не разрывая соединение. Опять же, если хотите подробнее про это узнать, посмотрите, у
Speaker A
нас был ролик на канале про INС, там как раз-таки про это рассказывали. Второй практически важный инструмент - это, конечно, SS. Через него происходит всё, что связано с взаимодействием с серверами. И помимо базовых принципов подключения, просто написать SSH пользователь IP, нужно обязательно
Speaker A
разобраться с ключами. Как сгенерировать ключ с помощью команды ССШК и Ге? Как закинуть публичный ключ на сервер? Как отключить вход по паролю? Как отключить вход из-под рута? И с точки зрения практики, особенно в начале, на этом сети плюс-минус заканчиваются.
Speaker A
Теперь поговорим о том, что пригодится именно для собеседований. На собеседованиях, как ни странно, любят гонять по модели оси. По нашей статистике, это чуть ли не самый популярный вопрос из области сетей вообще в целом. И тут самое главное уделить внимание уровням третьему,
Speaker A
четвёртому и седьмому. Пойдём по порядку. Уровень три, сетевой. Тут обитают IP-адреса, и надо понимать разницу между белыми и серыми IP. Плюс есть вопрос с подковыркой. Иногда спрашивают, на каком порту работает Pink. Ответ: Pink работает на третьем уровне по IP. Соответственно, порта у
Speaker A
него нет, потому что порты появляются на четвёртом уровне. И как раз-таки, давайте поговорим про него. На четвёртом уровне живут TCP, UDP и как раз-таки появляются порты. Вопрос, в чём разница между TCP и UDP до сих пор существует на
Speaker A
сабесах и по популярности идёт сразу после вопроса про модель оси. И, конечно, четвёртый уровень на этом не заканчивается, но нам сейчас, на данный момент хватит. Давайте пойдём на следующий, на седьмой уровень. Он же прикладной. Тут живёт всё, чем мы
Speaker A
пользуемся: http, https, DNS и так далее. Тот же вопрос, чем отличается HTTP от HTTPS, тоже нередко звучит на сабесах. Что касается ДНСа, то нужно знать, во-первых, как эта система работает в целом. Во-вторых, нужно знать типы ДНС записей. А условно вопрос, что
Speaker A
происходит, когда вы вводите yandex.ru в браузер и нажимаете Enter, тоже задают очень-очень часто. И надо понимать полный путь, который проходит ДНС запрос, что там происходит, какие ответы возвращаются. Ещё большая тема в сетях - это всё, что касается TLS, SSL и
Speaker A
сертификатов. Сейчас сертификаты есть везде. Uber внутри себя общается по сертификатам. Кавка требует сертификаты. Engines требует сертификаты. Тут нужно понимать, что такое TLS handшеak, то есть как клиент и сервер договариваются о шифровании. А если вернуться к практике, то что можно поделать? Можно
Speaker A
настроить Нжинкс и не забывать про релоуд, поиграться с конфигами, посидеть с нейронкой, поразбирать параметры. Плюс сюда можно отнести различные фаервол. Мы не упомянули, но это само собой разумеющееся. Ещё можно установить fail to бан, утилиту, которая позволяет защищаться от брутфорса. И в принципе
Speaker A
вот этого набора практики и теории хватит и чтобы сабе пройти, и чтобы работать девопсом. А если хочется с теоретической точки зрения ещё дополнительно про сети почитать, то, конечно, нельзя не сказать про набор статей сети для самых маленьких. Сами в
Speaker A
том числе читали. Очень интересно, понятно и полезно. Все ссылки на ресурсы, которые мы упоминаем в этом видео, находятся в описании. А мы переходим дальше к докеру.
Speaker A
И после того, как вы помучились с Линуксом, вручную ставили зависимости и настраивали какой-нибудь, Docker покажется вам глотком свежего воздуха.
Speaker A
После Linux и сетей концепция контейнеров заходит очень легко. И если сказать по-честному, то Docker очень простая тема, если вообще не самая простая, на пути обучения DevOps. Что такое Docker? Это когда мы берём всё, что нужно для работы приложения, то есть
Speaker A
код, библиотеки, настройки, параметры и упаковываем в одну единую сущность. И тут есть одна особенность. В реальной работе devops инженер далеко не всегда пишет Docker файлы с нуля. Сейчас и уже достаточно давно тенденция такая: разработчики должны сами уметь писать
Speaker A
docker файл. Они пишут какой-то базовый, описывают, какой язык им нужен, библиотеки и так далее. А уже наша задача как девопсов просто его проверить, что он соответствует беспрактисам и оптимизировать в случае необходимости, потому что разрабу, по большому счёту, не так важны эти
Speaker A
бестпрактицы. Его задача - написать код, проверить, что он запускается, и отдать в том виде, в котором это можно развернуть. А задача Divпса в случае необходимости doкерфайл поправить.
Speaker A
Кстати говоря, на канале есть отдельное видео про бестпрактисы в докере. Обязательно гляньте, там мы это разбирали по полочкам. А что учить с точки зрения команд? И тут, на самом деле, всё просто. Если у вас есть готовый Docker файл, то всё, что нужно
Speaker A
знать - это Docker build, чтобы образ собрать, Docker тег, чтобы дать ему название. Docker login, чтобы подключиться к хранилищу образов, и Docker Push, чтобы образ запушить. Всё остальное, типа Docker Run, Docker Stop, Docker Ex, нужно тоже, но намного реже.
Speaker A
Кстати, про хранилище, а, правильнее сказать режистре, мы должны, как девопсы, понимать концепцию. Мы собрали образ, и в понимании девопса он является артефактом. Этот артефакт нужно где-то хранить. И как раз-таки место, где он хранится, называется regстry. И в компаниях практически всегда стоит свой
Speaker A
локальный режистри типа Nexus или Тlлабовский или артефактори. Для практики хватит докерхаба или встроенного в GitLab regджистре. А главное, что надо понять - это суть.
Speaker A
Собираем, пушим и скачиваем там, где это надо уже использовать. Кстати, по поводу практики. Одна из возможных практик по докеру - это поднять стек мониторинга Прометеуса и графаны. А к ним мы ещё вернёмся как раз-таки с помощью средств докера. Берёте Docker Compose. Это
Speaker A
инструмент для запуска нескольких контейнеров на одной машине, и с его помощью как раз-таки разворачиваете всеми нами любимые инструменты мониторинга. Да и для начала можно вообще взять готовый Docker Compose под это дело, запустить командой Docker Compose App и посмотреть, как оно
Speaker A
работает. А дальше начать усложнять, поставить туда какой-нибудь notкспортер для своей виртуалки, который будет собирать информацию для мониторинга, настроить какие-то графики, попробовать построить дашборды. И эта практика хороша тем, что убивает сразу двух зайцев. И с Docker практикуемся, и с
Speaker A
мониторингом базово разбираемся. А теперь смотрите, какая картина у нас складывается. Мы умеем чуть-чуть писать код, умеем настраивать сервер, умеем упаковывать приложение в контейнер, но делать всё руками, собирать, пушать, заходить на сервер, пулить и так далее, это долго и муторно. Поэтому переходим к
Speaker A
CCD, по сути, к одной из самых важных аббревиатур в нашей профессии. Суть у CICD на самом деле простая. CI, то есть continuous integration - это когда мы берём наш код и на выходе получаем готовый артефакт CD, то есть continuous
Speaker A
delivery, это когда мы этот артефакт куда-то выкладываем, деплоим, будь то сервер, Uber или что-то ещё. Но на самом деле CD ещё может означать continuous deployment, и разница между deployment и delivy только в степени автоматизации. И что тут нужно знать на старте?
Speaker A
Во-первых, это инструменты Gitlab S и Jenkins. По сути, два гиганта на рынке. Getlab сейчас более распространённый, но Дженкинс тоже существует во многих проектах и до сих пор живой. Дженкинс можно рассматривать как деда. Сам по себе он мощный, но обычно очень
Speaker A
громозкий. Плюс все его конфиги и пайплайны пишутся на груве. И частенько бывают проблемы с плагинами. Обычно он стоит во всяких банках, энтерпрайзах, надо знать о его существовании. Можно пару пайплайнов на грубе разобрать, но больше время ему уделять не стоит. По
Speaker A
крайней мере, на старте. лучше сразу перейти на Gitlab SIй, который является по сути сейчас стандартом, потому что, во-первых, GitLab как репозиторий очень распространён, во-вторых, Gitlab si интегрирован прямо в него и пайплайны на GitLubi описываются в ямле, что намного
Speaker A
проще, чем в гру. И логика такая: мы просто кладём файл тоitlabci yam в корень проекта, и вся эта CICD история начинает происходить в качестве практики. Здесь можно взять тот проект, который мы постепенно делали. сначала в Линуксе, потом в Докере и написать
Speaker A
какой-нибудь несложный пайплайн из нескольких стадий, например, билд для сборки образа, тест, в который закинуть какой-нибудь линтер в зависимости от языка и деплой. Но пока что-то простое.
Speaker A
Можно просто подключаться по SSH к серверу и обновлять контейнер. Этого будет достаточно, но вы уже будете понимать, что такое CCD. Кстати, что ещё можно посмотреть на тему CICD?
Speaker A
Во-первых, у нас на канале был ролик об этом, а во-вторых, на степике есть полностью бесплатный курс, в котором разобрана вся концепция CCD и два наших основных инструмента Gitlab C и Jenkins.
Speaker A
Ссылка в описании. Переходите, проходите, и у вас уже будет очень хорошее понимание о том, как вообще всё это устроено. Ну а если говорить про собеседование, то самый главный вопрос по CCD звучит следующим образом: как вы себе представляете идеальный пайплайн? И
Speaker A
это вопрос не столько технического характера, сколько понимания, потому что сам по себе идеальный пайплайн не существует в вакууме. Всё зависит от конкретного проекта, подхода к разработке, стратегии ветвления и ещё многим-многим аспектам. И на собеседованиях как раз-таки ожидается то, сколько таких аспектов вы можете
Speaker A
учесть при построении своего гипотетического идеального пайплайна. И к этому моменту картина складывается такая, что вы уже умеете работать с докером, понимаете CICD, можете работать с седишными инструментами и понимаете, как настраивать линуксовые сервера. Но есть один нюанс. Эти самые сервера надо
Speaker A
каким-то образом настроить. То есть все те действия, которые мы уже умеем выполнять, условно установить докеer, настроить SS, создать пользователя и так далее, кто-то должен выполнить на сервере. И если речь идёт о практике, то да, всё понятно. Вы заходите,
Speaker A
прописываете команды, и всё работает. Но вот на работе у нас явно будет не один сервер, а, например, 10 или 100 или ещё больше. И, соответственно, заходить на каждый по очереди никто не будет. Можно, например, написать баш скрипты, но когда
Speaker A
скрипт упадёт на середине, то будет непонятно в каком состоянии находится сервак. Поэтому этот вариант тоже не подходит, хотя раньше именно так и делали. И вот здесь появляется AnSible, инструмент для управления конфигурацией.
Speaker A
Он как раз-таки решает эти проблемы. Про анбл, кстати, есть отдельный видос, но давайте здесь вкратце тоже расскажем.
Speaker A
Во-первых, он работает без агента, то есть не нужно ставить никаких программ на целевые сервера, куда мы хотим что-то применить. Не нужно мучиться с установкой клиентов. Ansible нужен только SSH и Python, который есть на Линуксе по умолчанию. И по сути всё, что
Speaker A
нужно сделать, проверить подключение по SSH, и Anсиible будет подключаться и делать те задачи, которые мы ему опишем.
Speaker A
И эти самые задачи описываются в так называемом плейбуке, который пишется тоже в формате yaml. Инible, в том числе, относится к подходу или же методологии, которая называется инфраструктура как код. И в рамках этой всей методологии есть очень важное понятие идомпотентность. Про это,
Speaker A
кстати, тоже любят спрашивать на собесах. Но вещь это, на самом деле, до более простая. Идомпотентность - это свойство, при котором повторное выполнение какого-либо действия не меняет результат. Допустим, нам надо создать директорию с названием Фoldр.
Speaker A
Первый раз мы её создадим, а второй, третий, десятый, сотый раз при попытке создания ничего выполняться не будет, потому что папка уже существует. Итак, работает с любой задачей. Ничего не поменяется, если это уже есть. И это очень полезная фишка ансибла и некоторых
Speaker A
других инструментов. Есть файл Inventory, текстовый файлик, где мы перечисляем IP-адреса своих серверов, которые можно разбить на группы. Допустим, вот эти три сервера относятся к веб, а эти три к базам данных.
Speaker A
Unible на каждое действие есть готовый модуль. Не надо писать команды Linux и баш. Хотим установить пакет, есть APT или ям. Под каждый дистрибутив написан модуль. Хотим скопировать файл с нашей машинки на целевой сервер модуль копи.
Speaker A
Хотим поправить config модуль template. Это роль. роль - это способ взять и какую-то конкретную задачу обернуть в удобный структурированный формат, чтобы потом дальше из таких ролей можно было собирать плейбуки. И две проблемы, которые они решают - это, во-первых,
Speaker A
разрастание плейбука в целом, во-вторых, дубликация кода, если одну и ту же роль надо использовать в разных плейбуках. Ну а если же говорить о практике, то можно взять виртуалку, сделать новую и не ставить туда софт руками, а просто написать playбук, который, например,
Speaker A
обновит систему, поставит докер, создаст пользователя и сделает ещё какие-то задачи, запустить этот плебук и поиграть с ним. Либо можно сделать несколько виртуалок или вообще пойти в облако и посмотреть, как всё это работает в таком виде.
Speaker A
И следующий блок, к которому мы переходим, по сути, сейчас является самым важным в контексте devops как профессии. И это Kubernetis. Он сейчас повсеместно. Для больших компаний и проектов он уже давным-давно стал стандартом. Кто-то заканчивает переезд на него с Dockр Сварма, кто-то
Speaker A
переезжает с опытшифта, и даже небольшие компании сейчас используют кубер для своих проектов. Короче говоря, это база.
Speaker A
Начать в Кубере стоит с понимания архитектуры. Сначала изучить компоненты контролплейна, то есть сервер, ETCD, skдуuler, контроллерменеджер, а дальше компоненты workкерноды, кублетку, купрукси, контейнер, runтай. Компоненты куба взаимодействуют друг с другом, и вы сможете рассказать, какой контейнер Runтаймime сейчас используется в Кубере
Speaker A
по дефолту. Можно переходить к основным сущностям. Ну и здесь, конечно, надо начать с подов, которые являются минимальной базовой единицей. При этом в поде может быть больше одного контейнера. Прочитать про нит, про Сайка, про паузконтейнеры. После этого перейти к деплойменту. И тут надо
Speaker A
обязательно понимать, что такое роллиндейт и как его настраивать. Дальше стоит фулсеты. Там нужно понимать, как они работают, и обязательно знать, в чём отличие стоитфулсета от деплоймента.
Speaker A
Дальше демонсет, jобangнд. И также сразу надо разобраться с конфигмапами и секретами. Понять, что конфигмапы - это для данных конфигураций, а секреты для паролей и токенов. Но при этом секреты сами по себе не зашифрованы, и там уже вы начнёте знакомиться с тем, что такое
Speaker A
Seed Secrets и так далее. Плюс надо уделить внимание всем параметрам, которые могут настраиваться. Те же реквесты, лимиты или пробы. А дальше логичный шаг - это пощупать сеть в Кубере, изучить все типы сервисов, понять, зачем они нужны, как они
Speaker A
создаются и как вообще сеть в Кубере работает. Затем ингресс, и здесь вообще можно надолго утонуть. Такова жизнь, потому что сети в Кубере - это чуть ли не самое сложное, что в нём вообще есть.
Speaker A
Потом надо перейти к хранилищам. Всякие PV, PVC, стокласы, просто разобраться, кто за что отвечает и чем является. А чтобы практиковаться с кубом, как минимум, можно поставить Миникуб локально или, например, K3D кубернатис в Докере, но для него нужна более мощная
Speaker A
машинка. Дальше можно перейти на managed Uber, то есть арендовать кластер в облаке, потому что в том же небезызвестном зелёном облаке дают 4.000 всем новым пользователям. А практика должна заключаться в том, чтобы каждый манифест написать руками хотя бы один
Speaker A
раз, чтобы почувствовать каждый параметр и отложить себе в голову. А потом уже можно со спокойной душой генерировать всё через нейронки. Главное, чтобы вы понимали, что и как тут работает. И развивая тему практики, возвращаемся к тому, что мы делаем на протяжении всего
Speaker A
ролика. Берём наш фронтENд из эээнд и заставляем их заработать в Кубере. Базу данных можно оставить на сервере.
Speaker A
Главное настроить к ней подключение. А ещё в контексте Кубань невозможно пропустить такую штуку, как Helm. Сейчас это опять же стандарт индустрии. Идёт неразрывно с самим Кубером. Все новые проекты сразу идут с Хелмом. Никто сейчас вручную манифесты не пишет. И
Speaker A
знание хелма является таким же обязательным, как знание того, что такое пот. Плюс очень много всего, что в Uber ставится дополнительно, тоже идёт через Хэлм. Так что после того, как сможете затащить всё обычными манифестами в Кубер, можете сразу попрактиковаться и
Speaker A
написать хлмчарт для фронтенда и бэкэнда. И уже хелмом попробовать задеплоить, как делают на реальных проектах. А дальше уже можно переходить к более продвинутым вещам по типу сетевых политик, моделей доступа Airbug и так далее. Также большой совет изучить понятие сервис МШ, а конкретно, потому
Speaker A
что сейчас он активно используется в больших компаниях, и штука на самом деле очень важная. Также можно посмотреть в сторону операторов. Это как раз те штуки, с помощью которых можно затаскивать базы данных в Uber и как-то с ними работать. Но штука сложная, и
Speaker A
поэтому её стоит изучать в последнюю очередь. А также стоит изучить способы развёртывания кубера как на BR Metмеal, так и в облаках, как куба DM, так и кубспрей- это тоже очень полезное знание. Начать погружаться в Uber можно с нашего ролика на канале, ссылка на
Speaker A
него будет в описании. А также очень большая рекомендация посмотреть вот этот плейлист на канале Слёрма. Там реально очень классно разбирается сразу вместе с практикой. А мы переходим дальше.
Speaker A
Мониторинг и логирование. Прометеус играфана - главная связка мониторинга, по которой тоже был ролик. Промете остаётся стандартом для метрик. Что стоит изучить? Про QL, то есть язык запросов, чтобы уметь искать и агрегировать метрики. Тут даже важнее понять его логику, нежели сам синтаксис,
Speaker A
а также просто поработать с экспортёрами. Это как раз-таки те штуки, которые вытаскивают метрики с нужных нам мест. Not экспортер, про который мы говорили или например Pastgress экспортер и тому подобное. Это вот самое главное. Графана - это просто инструмент
Speaker A
для визуализации. Быстронько разобраться с дашбордами, панелями, публичной библиотекой всех возможных дашбордов и просто, по сути, смотреть на графике.
Speaker A
Ещё тут можно изучить аёртинг, но сильно на этом зацикливаться не стоит. Всё-таки тот стек, который мы обсуждали ранее, гораздо более приоритетный. Почему мониторинг и расположен так близко к концу нашего роудмапа? Дальше логирование. Традиционный стеклакшки бана или же его opench. Это самый
Speaker A
популярный стек для логов, но ещё сейчас активно развивается Локи, потому что интегрируется с графаной и плюс он легче. Но с логированием смысл такой, что самое главное научиться логи читать и плюс-минус понимать, куда копать, основываясь на инфе из них. Если
Speaker A
говорить про задачи, проще разбираться по ходу, чем заранее тратить кучу времени на глубокое изучение. Дальше у нас облака и инфраструктура, как код, которую мы частично уже упомянули.
Speaker A
Почему это идёт в самом конце? Потому что мы делаем упор на реальный спрос. Опыт работы с облаками нужен ох как далеко не везде. Да и даже если его нет, всем по большей части всё равно.
Speaker A
Поработать с облаками можно как раз во время изучения всех инструментов, арендуя машинки под свои нужды. Но вот именно в работе, если что, можно разобраться на ходу. Если говорить про сами облака, то картина примерно такая: Яндекс Cloud, TimeW, Selecttail,
Speaker A
Cloud.ru. Сами активно пользуемся всеми облаками из этого списка. В принципе, все хорошие, все нравятся. можно брать любое. А что касается тераформа, то надо знать вот что. Токаfstate - это файл, который описывает инфру. Хранить его надо, в идеале в S3, чтобы не потерять.
Speaker A
Кстати, про S3 тоже рекомендуем почитать. У Тераформы ещё есть модули для того, чтобы структурировать код для переиспользования. И плюс ещё стоит понять, как работать с параметрами для разных окружений и как эти самые окружения изолировать. Но опять же, недаром это всё находится в самом конце
Speaker A
Руадмапа. Переходить к этому стоит только после изучения всего остального. А полный Radmap вы найдёте у нас в Telegram-канале. QR-код на экране, ссылка в описании. Переходите, забирайте огромный файл, где по пунктам расписано, что и в каком порядке учить. Всем
Speaker A
спасибо за просмотр. Подписывайтесь на канал, пишите комментарии. Всем пока-пока.
Topics:DevOpsroadmapLinuxGitDockerKubernetesмониторингсобеседованиепроцессы Linuxрусскоязычный DevOps








![ChatGPT – Полный Курс по ChatGPT и OpenAI [12 ЧАСОВ] — Transcript](https://i.ytimg.com/vi/jaIGvR3jtxI/maxresdefault.jpg)


