Как стать DevOps engineer. Задачи для junior DevOps.

[аплодисменты] [музыка]

Мы проведём тебя через путь от вдохновлённого профессии новичка до начинающего профессионала. Это история о том, как я и многие-многие другие, такие как ты, новички, становятся частью девоop сообщества. В этом видео мы пройдёмся по всем основным навыкам, технологиям, тулзам, которые необходимы для того, чтобы стать devopsнером. Можно сказать, это такой мини-гайд по профессии, но мы не просто перечислим то, что можно найти и так на просторах интернета. Мы хотим поделиться нашей экспертизой и показать конкретные примеры, которые необходимо иметь в опыте, в своей практике для того, чтобы претендовать на роль джуна.

DevOps профессия, она действительно сложная и многогранная. Это так и есть, потому что тебе нужно знать огромное количество технологий, разбираться во многих сферах. Тебе нужно понимать не только в инфраструктуру, тебе нужно понимать желательно хотя бы в разработку компьютер science, безусловно, потому что это инженерная IT-профессия. Помимо того, что у тебя огромный пул разноплановых задач, у тебя ещё огромная ответственность, потому что часто на плечах инфраструктуры лежит вся компания, все сервера, на которых работают, там приложения, сервисы, базы данных, в которых крутятся данные. Чаще всего это вот ты Devops инженер, который за всё это отвечает.

Но самое важное и главное, что каждый, кто начинает свой путь, в целом может добиться успеха, несмотря на то, что это большая безграничная профессия, нет вообще ничего невозможного. Я когда начинал, у меня не было с Девопсом связанного ничего. До того, как я начал учиться и пробовать в Дevops, я его боялся как огня. Он меня манил своей магией. Но на самом деле в рамках вот инфраструктурных вопросов абсолютно с низкой самооценкой. Мне казалось, что это просто недостижимые вещи, неподъёмные. Разобраться без какого-то роудмапа или ментора или людей, которые могли бы подсказать и выправить на путь, это реально сложно.

DevOps профессия, она напрямую связана с общением с людьми, с решением вопросов, разных инцидентов. Ну, в общем, я думаю, ты понял, что DevOps - это очень широкая профессия. У нас кейсы в DevOps фабрики были, где люди из продаж, из, э, строительной сферы, они добивались успеха и становились девопсами и сейчас работают в этой сфере. Количество таких студентов, к счастью, только растёт. Раньше для меня это был шок, потому что люди из абсолютно разной диаметрально противоположной профессии переходят и становятся депс инженерами, причём вообще без айтишного опыта.

>> Сегодня с позиции лида нанимающего менеджера будет вещать Александр со своим плюс двадцатилетним опытом стажа в IT в инфраструктуре. Александр расскажет, что именно он ждёт от Джуна, начинающего девоспециалиста, который приходит в профессию. А я буду рассказывать со стороны своего опыта, через что я прошёл. То, что мы будем описывать здесь, в нашем мини-гайде, по тому, как стать девопсом. Это был мой путь, в том числе. Конечно, много из того, что мы обсудим сегодня, мы разбираем на курсах DevOps фабрики, готови настоящих специалистов, готовых приносить пользу и решать необходимые задачи в рамках работы над инфраструктурой.

[музыка]

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

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

>> Безусловно, в DevOps профессии самая основная операционная система - это Linux. Какой дистрибутив, это уже, понятно, зависит от компании, там Redхату, Бунту Debion и так далее. Это не так важно, особенно когда мы только начинаем, потому что начинающему необходимо, в принципе, познать азы и базу по администрированию серверов. И, понятное дело, это Linux сервера. И если мы говорим про Linux сервера, там за ручку ходит вместе с ним баш, потому что по сути своей баш - это как раз-таки язык, благодаря которому или с помощью которого мы можем общаться с сервером, давать ему определённые команды, задачи.

Когда ты только начинаешь, часто возникает вопрос: что же конкретно мне нужно знать? Что собой подразумевает база Линукса? Какие команды? А какие задачи я должен уметь решать? Что, собственно говоря, есть такое база Linux? Когда я начинал свой путь, для меня Linux был вообще чёрным ящиком, несмотря на то, что я работал в разработке. Просто у меня не было необходимости его использовать, потому что чаще всего у меня был либо рабочая машина - это Windows, либо э MacOS. И Linux я в целом и не трогал. И самое важное, что я уяснил, что выучить и понять всё действительности невозможно, и никогда ты не будешь ощущать достаточный уровень владения тем или иным инструментом. Поэтому самый лучший вариант - это брать определённые задачи, которые делают администраторы Линукса, Devоops инженеры чаще всего и делать их, потому что через эти задачи, а задачи чаще всего комплексные, это не просто введи команду ls или посмотреть список файлов директории. Нет, чаще всего это задачи, связанные с настройкой сервера, написание скриптов, которые автоматизируют работу, какие-то кронзадачи, то есть задачи по расписанию, создание пользователей, создание СШ ключей, СШпар, раздача их пользователям или использование их публичных ключей для предоставления доступа и так далее.

Возможно, много из того, что я тебе сказал, вообще непонятно. Наша история заключается в том, что я, ты начинающий инженер, который попал в компанию и находится тут вообще первый раз. Знаний нет. Неважно, как ты попал. Возможно, это стартап твоего знакомого, родственника. Он тебя посадил и сказал: "Всё, ты интересовался девопсом, системным администрированием. Всё, занимайся. Но знаний у тебя ноль, и ты не понимаешь, как и что делать, и вообще с чего начать". И это вообще один из самых эффективных методов, способов обучения, когда с головой ты погружаешься полностью в проект, получаешь за него ответственность, ты добываешь эти знания и формируешь свою базу практики.

Итак, в общем, какие задачи у тебя могут быть условно связаны с администрированием? Через эти задачи ты сможешь поднять те необходимые навыки работы с командной строкой, фото, с башем, с логами, умением крепать, умение работать с седом AWK. Итак, первая задача. Нужно развернуть Angex сервер. И он нам нужен для того, чтобы работал сайт компании, в которой ты работаешь, в которой ты устроился, и он нужен на сервере. сервер новый, это может быть виртуалка, это может быть железный сервер, твой личный компьютер, что-то арендованное у провайдера, это не суть важно. Далее, Enginex, как и любой другой сервер, приложение, нормальное приложение, сервис какой-либо, пишет логи. Логи, логов может быть большое количество, они могут переполнить, заполнить всё пространство э твоего жёсткого диска. Поэтому обязательно нужно проводить ротацию логов. Вторая задача - это настроить ротацию engine Xлогов, чтобы они не переполнили твой жёсткий диск, твой сервер. И третья задача - это создание пользователей. Например, может быть кейс, когда набрали сразу нескольких разработчиков и необходимо создать новую группу пользователей, настроить им подключение по SS. руками делать это очень всё неудобно. Поэтому лучшим вариантом это будет написать скрипт автоматизацию на баше, которая позволит автоматически при необходимости создавать юзеров с нужными правами, с нужными группами, чтобы у них были доступы ограничены. То есть всем давать, например, рута не стоит, всем давать суда не стоит. А как стоит, почему стоит и что стоит делать? Это как раз-таки нужно изучить и разобраться. Ну вот такое третье задание - это вот эта вся автоматизация.

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

>> В рамках линк Сабаши, во-первых, нужен уверенный терминал. То есть человек должен уверенно пользоваться терминалом. Это означает, что у него должны быть вот прямо вот он прямо должен уметь вводить простые консольные команды. Там операции с файлами, а операции с процессами, операции с пользователями. А, ну там, знаете, классическая эта история, когда человека просишь: "Эй, дружище, давай я тебе добавлю доступ на какой-нибудь инстанс, скажи свой ключ или вот мой ключ, добавь его туда". Он должен это сделать вот прямо, ну, как аутиная операция, обычная операция, которую человек делает. Вот, ну вот прямо взял и сделал там за там минуту дветче пять. Это не должно быть типа: "Ой, а что-то у меня акция сденает. Ой, я там не не скопировал там там вот там скопировал тебе приватный ключ по ошибке". Ну все над над этим смеются, но при этом э- новички регулярно копируют тебе приватный ключ. Когда ты просишь вотправить ключ, он тебе искренне копирует приватный ключ. Вот это как бы такого не должно быть.

Обязательно должны быть навыки диагностики и понимания того, а в каким же образом понять неприятность, которая происходит в системе. То есть вот у тебя есть тех, э, ресурса, да, в системе. То есть это сеть, это а память, это дисковая подсистема. А четвёртый ещё какой-то есть процессор. Процессор. Вот. Аэ, и, э, эти вот, эээ, э, четыре основных ресурсах надо уметь диагностировать, то есть понимаете, какой в каком они состоянии, какая степень загрузки, в чём она измеряется, сколько там ещё осталось свободного, сколько занято, э, и кто это главное грузит. Вот для этого нужны вот понимание этих простых команд, там типа топ, там SS, там DF, там Eostat, вот эта вот вся фигня - это то, что типа человек вот ты прямо заходишь, вводишь и сразу понимаешь, что там написано, а не такое типа, ну вот эта вот история, когда люди говорят: "Ну я это сейчас погуглю за полчаса и точно я это расскажу". И ещё обижается на тебя, типа вот ты на простой команде человека обидел, типа это же можно просто загуглить, но типа ну конечно можно просто загуглить, но не так и просто.

Network, сеть - это неразрывно связанные с Линуксом вещи. Потому что когда у нас есть один сервер - это одно дело, но часто в работе у нас их несколько этих серверов, и они должны между собой взаимодействовать. Для того, чтобы они это делали, ну, я как понимаю, ты догадываешься, нам нужна сеть и умение её настроить. И, соответственно, знания, которые здесь будут необходимы - это из теоретических понимание, что такое TCP, UDP, что такое сетевая маска, публичные адреса, приватные адреса, сетевые политики, например, IPAles, NFTes, DNS, диагностика разных сетевых проблем, как работать с курлом, что такое Pink, что такое trace road, например, как посмотреть открытые порты, порты, которые используются приложениями, каким приложени Нужно уметь делать закрытую сеть или понимание того, как это работает. Часто, если повезёт, есть всегда сетевой инженер, который вот всё это настроит и там проконсультирует. Но понимание, как это работает, нужно обязательно, потому что часто может быть, что пропал доступ на сервер у какого-нибудь из клиентов или, например, у тебя случился какой-то разрыв соединения. Нужно понимать, как измеряется нагрузка сети. Нужно понимать структуру оси модели и где что используется, на каком уровне что работает.

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

>> Знание по сетке - это в первую очередь, э ну первоначальная конфигурация каких-то сетей, неважно, это Cloud или Onpay Setup. В Клауде тебе обязательно нужно VPC сконфигурировать, обязательно нужно какие-то штуковины сконфигурировать в onpмес. Понятно, ты там вообще, ну, много чего можешь сделать. Вот поэтому 100% тебе нужно понимать, э, как ты будешь назначать IP-адреса на какие-то сетевые устройства, если даже это сетевое устройство твой сервера. То есть, что у этого у этого этот IP-адрес, он может быть приватный, он может быть публичный, нужно на глазок его отличить, это не так сложно. Э, но это тоже очень быстро показывает, э, человек вообще с сетями что-то делал или нет. Нужно понимать, что такое сетевая маска, зачем она нужна и как из сетевой маски осуществляется аэ маршрутизация трафика. То есть она будет проходить там одним способом или другим. Э обязательно нужно понимать, что такое сетевые политики. А то есть сетевые политики, они 100% человеку встретятся в каком-то виде. То есть, если это Linux, то это точно там IP tables, NF tables, V, ээ, Firewall Day. Обязательно что-нибудь такое встретится 100%. Если это какие-нибудь клауды, 100% встретятся какие-то secкюрити группы, в которых есть или какие-то арилы, которые типа настраиваются. А, ну если куберс, понятно, твой полисе встретится. Вот поэтому, а, мм, вот этот сам концепт, что есть исходящий трафик, что он есть входящий, что они разных типов есть, что там есть какие-то порты, что там есть какие-то сессии. Вот это вот всё это всё, конечно, нужно знать.

Вот. Ну и, конечно, вот процессе там заговорили, да? То есть понятно, что нужно отличать понимать, ну вот этот классический вопрос, чем отличается TCP от ODP, а и понимать, когда применяется TCP и когда принимается у DP и почему он применяется. А неплохо было бы там в качестве новеллы, наверное, почитать, э, что же такое модель, потому что это, мм, ну, такая абстракция, с большой бородой, то есть она достаточно старая и не всегда там отражает реальный мир, но именно с точки зрения, ээ, таблшутинга, диагностики и понимания, как вообще сетка работает, это очень важно, потому что оно позволяет выставить общепатийное аппарат и понять, на каком этапе конкретно случается проблема, потому что, ну, любой, э, чувак, который занимается опешеном, э, он 100 пудов будет, ээ, разбирать проблемы с сеткой. То есть как там, почему же пули вылетели, но не прилетели, почему э сайт не открывается, э, в сетке обязательно придётся поковыряться, поэтому неплохо было бы это понимать. Ну и, соответственно, поэтому тебе нужны диагностические тулы, то есть типа тебе нужно понимать койл, как им пользоваться, э вот прямо взять коилом и показать хедер ответа там удалённого веб-сервера. Не так, что типа ой, дайте я погуглю, а вот прямо взять показать, э, посмотреть там ещё какие-то штуковины, да, там типа дико nlup pпи pink, э, понимать, что такое там пакет, а что такое время ответа, потери, в чём изменяется вообще сеть, то есть это байты, это пакеты. Это ещё какие-то хейновины. Ну, это тебе это поможет э понять, почему какое-то приложение медленно отвечает пользователям или быстро отвечает пользователь. То есть это вопрос во многом тайблшутинга, когда ты пытаешься понять, почему твоя мегасистема, она медленно работает. И, ну, если ты как бы оперируешь просто юайкой и типа вот у меня есть график, а, и вот там, короче, мм, вот там вроде как у меня ээ десятигабитный интерфейс, а, а, занято всего на гигабит, но почему-то больше не прокачивается. Типа ты такой: "О, ну на этом мои мои полномочия. Всё, надо звонить маме вот". Ну или папе. Там приходит кто-то настоящий devopс и начинает, короче, эту проблему дальше исследовать. Вот. Но если ты, например, понимаешь, что есть, э, э, что загрузка сетевых интерфейсов она во многом или сетевой подсистемы, она во многом связана с количеством пакетов, их средним размером, фрагментацией или вот такого рода делами, то твои дела сильно лучше, потому что ты можешь хотя бы вот эту штуковину продиагностировать и понять, что, мм, несмотря на то, что тебя там а у тебя вроде как всего 1 интерфейсов занята А по пропускной способности изменяемой в байтах, тебе почему-то наваливается куча пакетов маленького размера, и, скорее всего, тебя досит Вася из там какой-нибудь страны.

DevOps фабрика - это ламповая комьюнити DevOps инженеров, которые уже давно в профессии, и также те, кто только начинает свой путь. Мы обмениваемся опытом, решаем практические задачи, которые выходят каждую неделю. Причём после ваших ответов, решений мы также предоставляем ревью. Это не просто работа вслепую. Мы также комментируем, рассказываем о лучших решениях, что можно было исправить, какие-то ошибки или, например, наоборот, очень интересные находки. Мы обсуждаем собеседование, процесс найма, того, как это происходит. Люди делятся своим опытом, рассказывают, как они пробовали себя в разных компаниях. Что меня очень радует, это когда участники сообщества пишут: "Да, мой офер, я получил офер" или не один офер, а несколько оферов и выбираю между ними. Поэтому обязательно подписывайся на наш канал, присоединяйся к нашему devops сообществу, клубу фабрики и приходи на наши курсы, где мы на практике без теории, а именно на практических задачах в режиме реального проекта свчаться и разбирать эту прекрасную профессию devobs на тех кейсах, которые, собственно, я, Александр и много-много других девопсов решают каждый день и получают от этого большое удовольствие.

[музыка]

I - это основа основ вообще всего IT. То есть это то пространство, где код программно обеспечения разных конфигураций инфраструктуры, который описан, он, собственно, хранится в одном каком-то определённом месте. И это место репозиторий. С ним ты взаимодействуешь, когда вносишь какие-то изменения, когда хочешь что-то задеплоить, протестировать. Всё время гит, гит, гиit, гитгиit. То есть это must have чаще всего даже его нигде не указывают, не пишут. Это так же, как, не знаю, сотруднику, который работает в офисе, писать знания Microsoft Word, Excel или там Google Sheets, Google Docs.

Так вот, по поводу гита понятно, что он тоже имеет свои сложности и непонятности, но всё начинается с малого. Во-первых, нужно сначала этот гиту себе установить, потом попробовать создать репозиторий, попробовать с Git сделать, создать репозиторий в гитхабе и попробовать свой репозиторий с какими-то файлами, которые вы закомитили, которые вы добавили, закомитили и запушили. Потом нужно попробовать создать новую ветку, запушить новую ветку. Потом нужно попробовать сделать из новой ветки имейна или мастера, как бы подписано, сделать merge requст или requкст. смёржить это всё, потом снова перейти в свой локальный репозиторий, собрать изменения, то есть сделать пул, знать отличие между пулом и Фэтчем, знать, что такое мge, что такоес. Понимаете, это на самом деле простые команды, но они ускоряют и упрощают код. Конечно, вы можете это делать через тклиенты. Иногда это бывает удобно, кому как. Я лично работаю чаще всего через консоль. Ээ, ну это просто быстрее, потому что я не делаю каких-то сверхъестественных команд обычно в своей работе. Поэтому часто консоли мне достаточно.

Так вот, задание, которые нам необходимо сделать, у вас есть сервера, но есть и приложения, которых разработка разрабатывает. Вам нужно, чтобы потом в будущем эти приложения развернулись у вас на сервере. То есть вам нужно забрать их этот код, нужно его спулить себе. Но смотрите, в будущем мы будем делать работать с докером. Для того, чтобы практика с докером была такой многогранной, я рекомендую найти три простых приложения на трёх разных языках. Это Go, Python и Note JS. Можно сейчас не поддаваться в подробностях, почему, что, зачем и как. В будущем, в следующих шагах вы поймёте. Но сначала я предлагаю вот эти вот репозитории вам найти простые, обычные простые приложения. Почему веб-приложения? Потому что когда вы их развернёте, вы увидите результат работы. Это всегда приятно. Вот найдите три приложения. веб-приложения простых, склонируйте их себе на локальную машину и потом сделайте пуш этих репозиториев в свой личный репозиторий, и тогда эти проекты как бы станут частью вашего репозитория личного, который относится к вашей компании. Вы же сейчас работаете в компании, поэтому вам нужно создать свой репозиторий, где будет код вашего приложения. И вот эти вот три приложения, которые вы создадите, это как раз-таки и будет ваша имитация труда разработки.

>> Если честно, я, когда вот я провожу собеседование, я часто быва бывает, что даже забываю проверить знания гита. Потому что, ну, кажется, это настолько базовый навык, э, что его вот, ээ, ну, очень стрёмно не знать. То есть человек обязательно, если он находится в наших там devops делах или там в разработке, он 100% свои наработки куда-то публикует. Публикует он куда? Конечно, в гитаропозиторе. Поэтому он должен уметь делать комиты. Он должен делать мешие квесты, писать комитсообщения, делать ребейзы, э, витвиться, понимать, что такое фог. Особенно, если ты девопс, к тебе 100стопудов придёт какой-нибудь ээ э- разработчик, который попросит -э объяснить разницу между авторизацией по HTTP и авторизацией по SSH в Гите, и неплохо было бы ему объяснить так, чтобы он понял. Вот поэтому м это, конечно, очень важный навык и ну тоже такой, знаешь, маркер для а для тех, кто попадает в нашу профессию, да? То есть, если ты считаешь, что гит - это там, ну, вот прямо, э, вот столб какой-то, на который нужно забираться, то с точки зрения уже вот инженеров, которые там, ну, давно находятся, ээ, ну, гит - это считается прямо основой, которую даже особо, ну, не обсуждает никогда.

Компании обычно чаще всего не один сервер, не 5, не 10, а, например, 100, 50, тыся, десятки тысяч. И надо за каждым из них следить, контролировать, менять конфигурации. Конечно же, мы не можем лазить постоянно в каждый сервер по отдельности, э, менять там какие-то настройки. Время не так важно, как важен человеческий фактор. Фактор ошибки, который может нанести непоправимый ущерб. Так вот, ENSB - это инструмент, который является менеджером конфигурации, то есть он нам позволяет автоматизировать любые настройки, связанные с серверами, сразу для всего парка серверов или для определённого пула IP-адресов, определённого пула хостов, который нам нужен, о чём я говорю. Например, у нас есть, например, веб-сервера, то есть сервера, на которых стоят, а, хостятся наши сайты, например. И если мне нужно внести изменения в конфигурацию на каждом из них, например, там добавить пользователя, а, сделать какой-нибудь апгрейд какой-нибудь библиотеки, которую использует этот сервис, я использую этот Antible CД и для того, чтобы как раз-таки внести все эти изменения на все эти сервера, с Ансиблом действительно важно уметь работать. есть его аналоги Патшеф, но мы говорим про такой основной инструмент в индустрии и этим инструментом является C. И он является одной одним из основных инструментов девоopпса, потому что так как мы постоянно взаимодействуем с инфраструктурой, серверами, то нам нужно ими управлять.

Итак, у тебя уже есть настроенные сервера, настроенная сеть между ними. То есть ты уже вносил какие-то конфигурации руками, добавлял пользователя, изменял IP tables, например, добавлял какие-то сервисы. у тебя уже живые рабочие сервера. Но тут возникает ситуация, когда тебе дают ещё пять серверов, где ты должен развернуть то же самое в моменте. Тебе говорят: "Вот, вот эти пять серверов, сделай на них то же самое". Как поступить? Но, как мы уже обсудили, без антибла далеко ты не уйдёшь, и это будет достаточно сложно сделать. Одно основное задание, которое можно предложить сделать для практики - это перенести все ручные действия, которые ты делал в блоке с Линуксом башем, которые ты делал с настройкой сети. Всё, что ты делал руками, автоматизировать и переписать в unible. То есть

Нужно сделать так, чтобы у тебя были плейбуки, например, или роли. Также необходимо будет попрактиковаться в том, чтобы выполнять команды. Если подрезюмировать, задача в том, чтобы шаги, которые были связаны с Линуксом, башем, которые были выше, их автоматизировать и перенести в ENB.

Нужно уметь запускать ээ какой-нибудь Enible код э с разными м опциями и демонстрировать, что ты понимаешь, что там написано. Вот. То есть люди часто говорят: "Я типа, а, ну, ты просишь человека на интервью, а запусти мне, пожалуйста, ну, какой-нибл код, тот такой раз и не может это сделать". И такой говорит: "Ну я же могу это нагуглить". Ну да, конечно, ты можешь нагуглить, но очевидно, что если человек, ну, как-то писал что-то на интебли, да, то он неизбежно, ну, как-то это проверял и, ну, то есть ты там как, ну, любой процесс разработки, да, происходит. Ты пишешь какой-то кусочек, запускаешь, смотришь, эта часть она заработала или не заработала, пишешь ей кусочек, снова запускаешь, запускаешь, запускаешь, запускаешь. То есть как бы, ну, если ты 1.000 раз запустил условный enle там playбук там для того, чтобы свой плебук, роль там коллекцию там подебажить, то, вероятнее всего, э такие вещи у тебя должны прямо вылетать ну мм из-под руки очень быстро.

Вот поэтому обязательно нужны, конечно, ну типовые операции уметь выполнять э с помощью м командной строки. Точно нужно уметь писать простые плейбуки из раздела: "Ну, давайте установим веб-сервер, давайте там что-нибудь настроим, а напишем что-нибудь, какой-нибудь темплейт, который конфигурирует какой-нибудь конфигурационный файл, мм, ну, какого-то демона, который ты там решил, э, приучить, как там пользуются переменные, какие-то групповые переменные, хостовые переменные, инвентори файлы. Э, всё это вот, ну, базовая концепция, которую человек, э, должен, э, ну, прямо знать, знать, знать, знать, знать и уметь и ими оперировать. Э, соответственно, м, если условно человек, ну, не может ответить на вопрос, что такое групповые переменные, но, очевидно, он никогда не ну не не оперировал энсибом какую-то инфраструктуру. То есть, типа, ну, если он типа, ну, вот эти штуковины концепты не понимает, это как бы тоже сразу же ну чело говорит об опыте человека. То есть, если человек говорит: "Я могу это загуглить". Ну, это опять же говорит об опыте человека и о том, что, вероятнее всего, он начнёт тренироваться на кошках, и эта кошка твоя любимая инфраструктура, которую ты там с друзьями, друзьяшками, кинтярами и своими прекрасными профессионалами полировал там, не знаю, очень долго. Вот поэтому это всё, конечно, нужно знать.

А важно, конечно, знать того слова там идымпотентность. Конечно, его надо знать, да, там про него все говорят и считают очень важным это слово применить. Э, обычно я чаще всего я так вспоминаю, обычно джуниоры об этом это слово применяют. Синьоры почему-то эже сыпят такими сложными тяминами, потому что они могут, ну, какой-то опыт свой показать практически. которые, ну вот, ну прикольно было бы подемонстрировать, конечно. Такая вот история.

Построение пайплайнов - это огромная часть работы DevOps инженера, потому что очень важно донести код от разработки до конечного пользователя и без на сегодняшний день в современных компаниях, ну, ещё в целом, наверное, уже во всех компаниях без пайплайнов, без CCD, то есть Continuous integration, Continuous Delivery, Continuous Deployment, уже не обойтись. Самое главное практически из основных навыков - это умение понимание этапов, этапов пайплайна, основных этапов. То есть там, где у нас есть линтеры, тестирование, сборка, а там деплой. В разных компаниях, понятно, эти стадии могут отличаться, какие-то шаги могут добавляться, расширяться, где-то, может быть, там какая-нибудь компиляция отдельно, где-то очистка и так далее, и так далее. В общем, самый главный основной посыл, понимание принципов, по каким строится пайплайн, что нам всегда нужно что-то сначала проверить, прежде чем куда-то что-то отправить. И ещё нам бы как бы собрать и где-то хранить, чтобы, если что, это не потерялось. В общем, такие основные моменты чаще всего пайплайны любые покрывают.

Всё это реализуется на известных популярных э сервисах, э, таких как Gitlab C, GitHub Actions, можно добавить туда Boo от Атласиана и ещё ряд, например, Дженкинс и наверняка ещё ещё есть какой-то ряд, а, сервисов, которые я не озвучил. Я предлагаю остановиться на двух, а, и выбрать из них. Это GitHub Actions и GitLab C. На мой вкус, на мой опыт, через что проходил я, я начинал с GitLap C, поэтому я рекомендовал бы его и говорил о том, что в компании, в которую сейчас ты попал, заводится GitLab C. Вот ты делал репозитории, возможно, у тебя были репозитории в Гитхабе, тогда можешь в целом оставить GitHub Actions, если не хочешь всё нести в Gitlab, но попрактиковаться тоже в целом, а, было бы очень даже неплохо с двумя системами.

У тебя есть GitLab или GitHub репозиторий, там необходимо построить pipйeline. Pipeline пока простой, без деплоя на сам сервер, но с тестами и с проверками. Это может быть линдер, который будет связан с конкретным языком программирования, на котором написан твой сервер. Сервис, который будет проверять как раз-таки качество кода, а его правильное написание. И, возможно, например, какой-нибудь джоб, который имитирует тест. После прохождения всех этих пайплайнов выходит там ответ: "О'кей, что всё, тесты пройдены.

Нужно попрактиковаться с умением, а, создавать разные рулы, по которым будут джобы запускаться, понимать, что такое manual, понимать, что такое запуск по мастеру, то есть только, например, запуск конкретного шага после мрджа в мастер или, например, если у нас ветка не маер или main, то нам необходимо тогда вручную запускать или, наоборот, мы деплом только вручную. В общем, позаниматься, повзаимодействовать с тем, как работает синтаксис. в Gitlab или в GitHub Actions. Что это за блоки? Какие есть у него возможности? Как использовать переменные окружение? Конечно же, позже мы прикоснёмся к Докеру и после взаимодействия с ним дополним наш CICD необходимыми шагами для деплоя. И это очень важно.

В будущем, когда мы уже, а, пройдём до докера и дальше, нужно будет всё упаковать в Gitlab C таким образом, чтобы приложение, чтобы оно собиралось, тестировалось, разворачивалось. И была проверка о том, что вот это развёртывание произошло успешно, деплоймент. То есть обязательно нужно настроить, задеплоить runр, чтобы runр был self hosted. Run, который запускает все эти джоб, все эти пайплайны, должен находиться на вашем окружении, на вашем сервере. Поэтому здесь тоже нужно будет взять в руки, потому что у нас уже всём. Создать, возможно, или отдельную виртуалку, выделить под runner, или это сделать на своей какой-то общей виртуалке из пула, которых у вас есть в компании, появились в компании, и туда deплоить симб.

Вот тема этого CSD очень важная, потому что, э, любые, мм, инфраструктуры мы строим по сути ради одного, чтобы туда задеплоить какое-то приложение, которое, соответственно, и образует сервис, который, э, ну, организация предоставляет кому-то. Вот поэтому CCD - это очень важно, его нажно нужно уметь писать и 100%, ну, DevOps его будет писать. Типа многие считают, что задача дивопсов - это только писать C ICD, что, конечно, ну, ээ, часто разбивается суву действительность. Вот поэтому тут очень важно, э, м, понимать, какие стадии, их для себя чётко разделять и понимать, как они описываются. То есть есть некие там билды всякие тест-тесты, деплои, там автоматическое тестирование, там всякие там э различные э штуковины, как это на практике работает, как это запускается. То есть какие-то этапы запускаются мануально, которы какие-то этапы запускаются автоматически, а каким-то образом там есть некие данные, которые считаются секретными. А, то есть, во-первых, что такое секреты, да, вот в этом контексте это неплохо было бы понимать, а, и приводить это как примеры. Обязательно нужно, мм, понимать, как их хранить, какие бывают способы альтернативы, а, и как сделать так, чтобы секреты оставались секретами. -э, э, между различными этапами передавать какие-то, а, артефакты, будь то какие-то переменные или какие-то прямо, ну, артефакты, которые мы собрали, как их правильно передавать, куда их помещать, каким образом э вот твой CCD, собственно, как какая именно процедура обновления кода, то есть как это конкретно выглядит, то есть как как ты берёшь, какие команды там, как какой механизм вот этого А обновление новой версии происходит при твоём мм в твоём CD пайплайне. А обязательно нужно знать какие-то кондишены, да, то есть условия, по которым запускается а деплои, то есть, ну вот типичный пример, да, там условно из одной ветки мы деплоим ээ в stageж, из другой ветки мы деплоим там в а те мы, например, деплоим в продакшн. Ээ, тут привет, привет. Все, кто думает, что Git - это UI UI, да. Ээ, неплохо было бы с ходу сказать, что такое тег, да, Gitк и, э, без подглядываний.

Вот поэтому тут важно понимать, наверное, ну, Gitlapci - это очень хорошее понимание, потому что по сути это такой более или менее стандарт C, достаточно востребованный, и он или используется в проекте или там есть точно инженеры, которые умеют на этом языке говорить. Если ты там, ну, потребляешь какой-нибудь Ситинкис, э, или что-то подобное, то, ну, спорно, скорее всего. Ну, дженкинсовод тоже найдётся, но как ни крути, это считается не слишком свежим решением. Вот. Но Gitlab C учить очень хорошо, потому что 100стопудов ты сможешь об этом поговорить и тебя смогут предветно поспрашивать и, скорее всего, смогут поспрашивать по каким-то конкретным э вещам, которые есть именно в конструкциях э Gitlap Seyam.

Сегодня почти все приложения, да и в целом кажется, что вообще весь мир живёт в контейнер. Контейнеризация, да и виртуализация - это достаточно важные части Devops работы. Но в этом блоке мы будем говорить про докер, про контейнеризацию, про необходимость её уметь реализовывать и какие же задачи нам нужно решать с этой контейнеризацией. В теории, конечно, тоже нужно разбираться, знать, понимать, что такое контейнеризация, чем он отличается от виртуализации. Это очень популярный и нужный, вероятно, вопрос на собеседованиях, потому что таким образом можно определить человека, который близко или не близко, или просто постоял, посмотрел рядом с этой технологией, а с ней нужно будет взаимодействовать очень часто и очень много.

Что касается практики, то, ну, как основной инструмент докер. Соответственно, нужно уметь работать с докером, с его командами, знать, понимать, как посмотреть список контейнеров, список иджей, посмотреть волю, посмотреть, проинспектировать контейнер, посмотреть переменное окружение контейнера, посмотреть, э, понимать работу сети, э, как какой именно драйвер сети используется у конкретного контейнера или какой нужный, какой лучше, какой хуже. уметь работать с волюмами, как открывать парты и биндить их, каким образом пишутся докер файлы, как работают слои, что нужно делать, чтобы образ был меньше, чем он получился в итоге. Что такое мультистайageбиildдинг? Я говорю, исходя из своего опыта, популярные языки, которые я контеннеризировал больше всего - это Python, это GoNJS. И у них у всех есть свои особенности. И как задание такое полноценное, связанное с докером, необходимо найти три простых приложения. Можно просто так и писать. Simple Application, а on Python, это JS и Go. Найти в гитхабе приложение в свободном доступе. Если в блоке с гитом ты не брал все эти приложения на всех этих языках, не клонировал и не пушил э в свою репу, то вот здесь, на этом этапе, это кажется важно сделать. То есть найти три приложения на трёх разных языках лучше всего и желательно, чтобы они не были докеризированы или вообще, если ещё лучше, если таких не находится, то удалить прямо docker файл и написать свой. Склонируешь эти приложения, напишешь им doкеer файлы, соберёшь образы и запустишь контейнеры так, чтобы они работали.

С докером в первую очередь нужно уметь докеризировать э какие-то приложения. То есть ээ ну уже зачастую. То есть это тоже настолько такой базовый навык, что, э, часто сам разработчик, он тебе уже выдаёт, э, doкерфайл для твоего для твоего приложения, то для своего приложения. То есть типа он сам его написал и типа подразумевает, что все могут писать докер файлы. Э поэтому ну, devobs тоже должен уметь писать и как бы это не особо обсуждается э и должен вообще-то понимать что там надо пооптимизировать, что такое слои, там, что такое мультич. А-а, ну, имеется, имеют ли место какие-то секюрити-концепты, э-э, типа там запуска приложений нет ута, э, правильное выставление там каких-то других пермишенов, повышение привилегий при запуске контейнеров при необходимости, особенно если это, например, контейнер мониторинга. И это всё то, что человек ну, вот прямо должен знать и спокойно этим оперировать. Э, неплохо было бы, соответственно, для того, чтобы проверить, что человек это когда-то как-то делал, э-э, ну, у себя на локоле, мы опять же применяем простую простую штуковину. То есть, если человек у себя разрабатывал doкеer файл и делал это, ну, не знаю, там раз 10, то он 100 пудов запускал какой-то докер билд у себя на машине и докера у себя на машине. Ну, то есть он собирал контейнер, извините, собирал имидж, потом запускал из этого имиджа контейнера. И это означает, что типа он должен знать эти базовые команды, каким образом собирается, каким образом запускается, что там есть важного. А, и это типа то, что можно спросить, и человек это может ответить. То есть, если он там условно очень хорошо понимает, что такое doфайл, э, какие там есть там, ну, вот этот любимый вопрос, типа, чем отличается копия от, и он такой тебе рассказывает, э, некуй некий стих о том, чем они отличаются, а потом как бы ты его просишь ээ ну запустить контейнер из имеджа, а он не может, то мы понимаем, что он выучил это как стих. То есть у него, ну, он у себя на локоле, да, ну, хотя бы на локоле это никак, ну, не покрутил. То есть он просто там, ну, как к экзамену готовится и выучивает набор слов в надежде, что это станет ответом. Ну, как бы так как у нас не урок там литературы, то тут, конечно, какие-то практические знания подразумеваются. Поэтому, ну, важно знать команды, важно понимать всякие концепты обязательно, да, там всякие волю. типы сетей, а всякие статполитики, э всякие концепции, связанные с изоляцией.

Классический вопрос: чем отличается виртуализация от контейнеризации? А и вот эти вот все концепты, их обязательно, ну, надо понимать, чтобы человек мог на это ответить и ответить э что-то внятное с ходу, чтобы продемонстрировать свой опыт. То есть задача продемонстрировать опыт, который человек будет использовать dayту в своей работе. Определённо любой специалист будет заниматься тем, что ему нужно запустить, точнее, собрать какой-нибудь образ. Обязательно он будет понимать, он будет призываться в ситуации, когда образ почему-то не собирается. И, мм, неплохо бы было бы, если бы в этот момент он там мог понять, что такое докеer, например, и почему он, например, не работает. И неплохо было бы понять, а как для там автотестов каких-нибудь, как запускается временный контейнер и почему он там не запустился, как появляется, что с ним какая-то беда или не беда, а как какие-то сетевые настройки там произошли или не произошли, как конкретно там вытащили под приложение наружу или не вытащили. Это всё как бы, ну, имеет значение. И неплохо было бы, если человек это из головы достанет и сразу же ну, то есть поймёт, ээ, не решение, то есть понятно, ты, ну, не можешь сразу же решение всегда, ну, говорить, но ты хотя бы поймёшь, о чём речь и в какие стороны возможно покопать. Потому что, если ты, типа, ну, просто, э-э, смотришь на ошибку и тут же её заносишь в чат GPT, и это твоё единственное, э, действие, которое, которым ты обладаешь, то, э, получается, что с неизвестной ошибкой, которую чат GPT тебе, ну, не может подсказать, ты, ну, не имеешь возможности разобраться, потому что, типа, у тебя, ну, нет ручка. Вот поэтому м важно вот это вот, да, уметь делать.

В мире инфраструктуры появилось большое количество отдельных специалистов, которые занимаются теми или иными вопросами. Это сеть нетворки инженеры, DBA, которые занимаются базами данных, релиз инженеры и так далее, и так далее. Но понимание и умение работать с базами данных - это тоже, безусловно, является нужным, ээ, и необходимым навыком. Часто вообще работы по администрированию баз данных ложатся на плечи инженера. Не всех, не во всех компаниях база данных имеет огромные терабайтные размеры, кучу кластеров и так далее. Но если у тебя есть несколько баз, несколько кластеров, то в целом простой м не DBA, а просто обычный инженер, обычный devсн инженер, может на ура справиться со всеми этими задачами. Но для этого нужно уметь и работать с этими базами данных. А одни из основных таких баз данных - это MySQL, например, и Posгс. Конечно же, нужно знать типы разных BD, что такое Node SQL, SQL базы данных. Неплохо бы иметь опыт работы с рейдисом, например.

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

В качестве задания я предлагаю развернуть базу данных Посрос, на нейписать SQL запрос, который создаст базу, создаст некоторые таблицы пользователей, выдаст им права и, ну, и всё это вы напишете в SQL-файле, выполните, и у вас заполнится база. Ну и как задание со звёздочкой, это сделать вторую базу данных рядом на другом сервере, так чтобы они взаимодействовали между собой в отношениях мастер реплика, где реплика будет собирать состояние мастер базы данных для того, чтобы в случае чего, например, если у нас мастер умрёт каким-то образом, там взорвётся сервер, не знаю, то реплика, она всегда будет актуальной, и мы можем переключить приложение на неё. Идеально было бы, конечно, поднять базу данных так, чтобы она могла взаимодействовать с приложениями, которые вы, а, используете и деплойте. Ну и, конечно же, всё это нужно сделать через enable для того, чтобы ничего руками не заводить.

Тут обязательно нужно понимать типичные операции, которые ну точно придётся выполнять. То есть любое приложение, оно опирается на какую-то систему хранения данных. То есть, ну, ну базу данных, да, то есть обычно какая-то база данных. Если мы говорим о каких-то, э, веб-проектах, то есть не каком-нибудь там супертерпрайзе с Oraclм, то чаще всего это мм постгрес. То есть постгрес учи, не ошибёшься и в принципе всё будет. Точно надо понимать типичные операции, как создать базу данных, как создать пользователя, как этому пользователю выдать прав, а как проверить условно там, ну, какие-то список таблиц, может быть, которые у тебя в базе данных есть. Как понять, это большая таблица или маленькая? А как понять, э какая какая вообще сейчас ситуация на базе данных? она бездействует или, может быть, есть какие-то сQL запросы, кото которые вот выполняются, да, то есть типичные сделать эту типичную диагностику э состояния базы данных, когда ты вывозишь список процессов или список скорил запросов и пытаешься там найти те, которые выполняются больше определённой определённого времени. А, то есть, в принципе, это то, что точно ждёт. И если это умеешь делать, то это прекрасно. Обязательно понимать, каким образом делаются бэкапы и восстановление базы данных. То есть типа, если там это пост, каким конкретно командами, какими конкретно способами это делается, это всё достаточно важно. А, ну и, соответственно, [музыка] ина сейчас, сейчас я, честно говоря, сам не напишу сходу, поэтому мне потребуется с помощь документации, но 100пудов, э, или очень хорошо, если для компании важны базы данных, э, вот эти базовые сQL, они всё-таки не лишние будут. То есть, э, посмотреть, разметь таблицы, то есть сделать селект, э, посмотреть значение какой-то записи, потому что, возможно, настройки приложения могут храняться в базе данных. То есть условно какой-нибуд Фифлаг, он может храниться в базе данных, и его значение оно определяет ээ поведение приложения. Соответственно, типа тебя могут спросить: "А что там на проде? Какое значение?" Э скажи его. Ты должен сказать, какое значение. То есть для этого тебе нужно знание там select from ID такое-то. Вот это как бы неплохо. А тут, конечно, прилетят любители UI и скажут: "Я там установлю какой-нибудь UI у себя на компьютер и с этого юая, ну, потыкаю, да, там, э, пальцем". Ну, скорее всего, это не проканает в продакшене, потому что прямой доступ к порту базы данных в продакшене с компьютера человека, э, это необычно. Это это необычная ситуация. Вот поэтому, конечно, в терминале нужно быть готовым написать селик. А это всё, что касается базы данных для джуниоров. Следующие этапы там всякие, ну понимание индексов, понимание там анализа производительности, запросов, всякие репликации, масштабирование и это всё, это всё обычно, ну, от джуниора не ожидается, но базовые вещи, типа создание пользователей, создание базданных, э, понимание состояния, там список процессов, список запросов, это то, что нужно делать. 100 пудов придётся делать, надо уметь делать.

Мониторинг и логирование. По-другому можно ещё сказать, obserсербиility. Также часть DevOps работы, которая целиком и полностью или хотя бы на 90% уж точно ложится на плечи devops инженера. Нужно уметь работать с лог-файлами, с системами логирования, системами мониторинга. Помимо того, что мы умеем просто мониторить ресурсы на нашем сервере, на нашем приложении, например, посмотреть топом ч топом ресурсы серверов и так далее, но это сложно делать, когда у нас много серверов, когда у нас много приложений. Для того, чтобы это всё централизовать в одну какую-то систему, для этого и существует система мониторинга. Они нам для этого и нужны.

Какие основные моменты нужно понимать про мониторинг? Мониторинг. Нужно понимать про мониторинг. Что такое экспортеры, что такое алерты, как они строятся, что такое метрики, что такое лейблы, каким образом я могу, э, пометить определённые сервисы, что это, например, prodдаction или это def окружение. А как я могу вот эти все метрики где-то посмотреть? Что такое графана? Как я создаю дашборды, откуда их брать? Мм, как там придумывать какие-то формулы? Что это за формулы? Что это за синтаксис, которым пишутся разные запросы? В прометеус, как я могу метрики собирать? Если говорить про логирование, то в логировании важный момент. Во-первых, каким образом я могу собирать логи и как я могу очистить логи от ненужной информации и использовать только нужные. отправлять в систему, где я посмотрю это, где будет, в каком виде и как будут храниться эти логи. Что там будет за формат логов Jonли какой-то другой. Что такое вообще JSON формат, э, тоже бы неплохо знать. Но, думаю, к этому моменту, если вы дошли до мониторинга, логирования, скорее всего, вы уже понимаете, что такое Jon.

Главная задача, которая будет стоять перед вами, когда у вас уже есть инфраструктура, есть приложение, всё деплоится, крутится, вам нужно это всё мониторить и логировать. И, безусловно, вам нужно будет поднять эти системы у себя на своём локальном окружении. Идеальным вариантом, конечно, является развернуть это всё через Enible, либо с помощью уже готовых коллекций. В принципе, попрактиковаться в них это неплохо. Либо с помощью того, что вы сами напишете роли или руками развернёте. В общем, главное, чтобы у вас было развёрнуто окружение для мониторинга, для алертинга, для логирования и просмотров. Простых два экспортера, один из которых будет мониторить у вас систему - это Node Exспотер известно, и найти какой-нибудь экспортер, который будет мониторить э ваше приложение, либо написать его самостоятельно. Тоже, кстати, отличная практика. Например, в рамках изучения языка программирования можно написать, например, экспортер на Python. Это достаточно просто. Даже если вы особо языка не знаете, то можно его сфарганить или найти и под любое приложение поднастроить. Это не так сложно, поверьте мне.

У вас должны быть хотя бы несколько дашбордов в графане, которые показывают состояние вашего сервера и ваших приложений. Соответственно, у вас должны быть метрики, которые от приложения и от сервера идут. У вас должны быть настроены алерты на определённые трэшхолды, то есть на определённые значения, после которых нужно бить тревогу. Например, если у нас кончается меory или память на тачке или, например, огромное количество там 502 статус-кода в запросах или там 404 или чего-то ещё. логи, как они будут. Соответственно, это надо будет поправить где-то формат логов либо использовать текущий, сделать умение работать с парсингом, отпарсить логиней информации и забирать только необходимое вам. То есть эта практика, она поможет очень сильно прокачаться в том, как вообще настраивать это обсервабилити. Надо понимать само слово, да, то есть ну мониторинг, логинг, да, то есть что-то такое и там само понимание метрики, э откуда они берутся,

каким образом они попадают в систему мониторинга? Потому что, ну, джун, вероятнее всего, будет ставить какие-то агенты мониторинга, э-э, там, экспортёры, э-э, или какие-то агенты логинга. И стопудово он должен понимать, каким образом эти данные попадают вот в то место, в котором все любят смотреть графики и делать визуализации. То есть вот эти принципы, э-э, они точно должны быть понятны.

Э-э, точно должно быть, должно быть э-э какой-то минимальный опыт с любым мониторинг-стеком. Ну, то есть там самые популярные, да, то есть там Prometheus, Grafana, Alertmanager, там, Zabbix. Есть люди, места, где ещё используется Zabbix. И Zabbix тоже можно знать, но это как бы э-э на любителя. Вот. Ну, поймите, Grafana, Alertmanager — это как бы то, что м-м, на чём говорит весь мир. И если ты вот это вот штуковину попробовал и можешь э-э объяснить, как конкретно в Grafana, э-э, откуда в Grafana берутся данные для того, чтобы построить график по загрузке, да, какого-нибудь ресурса, то, в принципе, это уже достаточно неплохо. Вот.

Или каким образом э-э, условно, ну, то есть тоже типовая задача — это когда ты, а-э, сидишь, и тебе приходит какой-то алерт о том, что вот там какое-нибудь количество ошибок в работе какого-то сервиса, оно стало больше, чем нужно. А, и тебе приходит алерт, там, ну, там какой-нибудь Slack, в Telegram, э-э, на почту, э-э, позвонило оно тебе или так далее. Ну, то есть это то, что типа регулярно происходит. И неплохо было бы рассказать, каким конкретно образом э-э происходит от того, что типа вот эта аномалия произошла, как конкретно мониторинг увидел её, как конкретно он понял, что это аномалия, и как конкретно он, э-э, послал тебе, а-э, "письмо счастья". Вот. Потому что это то, что происходит ежедневно.

То же самое касается логинга, да? То есть, э-э, тоже нужно понимать, как конкретно люди получают доступ, э-э, к логам. То есть понятно, что там в продакшене никто не даёт всем заинтересованным доступ к сырым логам на конечной системе, да, то есть там ни по SSH, ни такой, его очень редко или никогда не дают. Есть те, есть противники, которые прямо вообще очень против такого. Вот. Поэтому какой-то есть способ э-э демонстрации логов тем, всем, кто заинтересован. Есть какие-то агенты логинга, есть какие-то хранилки логинга, есть какие-то визуализаторы логинга. Ну, тут прежде всего, конечно, это ELK. Эн, ну, активно его теснят всякие Loki и Victoria Logs. Э-э, но а, м-м, опять же, человек, который знает ELK, то есть Kibana, а, и какой-нибудь Logstash, Filebeat, там, Vector, там, Fluentd, ну, в общем, любой агент, который доставляет метрики, он, в принципе, понятен всем. И понятно, что если человек работал с этим, он, в принципе, разберётся с тем, что конкретно тут используется. Э-э, поэтому это тоже нужно знать и конкретно понимать, да, то есть вот как конкретная сырая строчка лога -э м на сервере или там в логе Docker'а или где-то ещё там, она попадает в условную Kibana. А это как бы то, что прямо нужно достаточно детально понимать.

Kubernetes — это, можно сказать, стандарт в индустрии для деплоя приложений. 100%, что нужно знать — это все компоненты Kubernetes и как они взаимодействуют друг с другом. Тут надо понимать, что на самом деле компонентов Kubernetes основных не так-то и много. Понимание того, как они работают между собой, просто вот так в теории, если почитать, будет проблематично, пока ты не столкнулся с проблемами, с дебагом, с ошибками, которые происходят у тебя в кластере, в работе приложений там и так далее, работе между собой. Но вот, конечно, без реального проекта, прямо вот чисто локально у себя дома, все шишки набить вряд ли получится.

Основные пункты, на которые я бы обратил внимание — это, во-первых, понимание, работа, очень активная работа с Kubernetes как пользователь, то есть используя `kubectl` и все его необходимые или часто встречающиеся команды: посмотреть поды, посмотреть список ресурсов, заглянуть в их манифесты, посмотреть `ConfigMap`, `Secret`, переменные, залезть внутрь пода, точнее, внутрь контейнера, который внутри подов. Умение быстро ориентироваться в уже поднятом кластере, в уже развёрнутой инфраструктуре в целом достаточно для того, чтобы приносить пользу, будучи как джун. Потому что во многих компаниях кластеры на свой вкус и цвет, и все по-разному деплоят. Есть, понятно, там такие вещи, как `kubeadm`, какие-то стандарты по деплою, но так или иначе всегда везде будут свои различия. И, конечно же, круто уметь это. Круто поднять свои виртуальные сервера, сделать эту инфраструктуру, состоящую из мастер-ноды, worker-нод и так далее. В рамках обучения это может быть не всегда удобно или возможно, но в любом случае есть очень много ресурсов, которые предоставляют уже открытые Kubernetes-кластера. Также есть кластера немножко под урезанным функционалом, которые позволяют попрактиковаться с как раз-таки `kubectl` и прочими инструментами. Kubernetes можно развернуть на локалке, и гайдов в интернете, статей и так далее полно, безусловно. Поэтому конкретно на этом я останавливаться не буду. Просто хочу подсветить те моменты на практике, которые ты можешь сделать.

Конечно же, тут нужно ещё иметь в виду, что вот если вся работа, которая, о которой мы говорили выше, будет проделана, то работу с K8s, скорее всего, ты легко освоишь уже, будучи на работе с оффером на руках. Идеальное было бы задание — это, конечно же, развернуть или взять уже развёрнутый кластер и попробовать задеплоить приложение, которое у тебя в GitLab или в GitHub, ну, вообще в принципе, которое ты выбрал для деплоя на свои сервера и задеплоить его в K8s, написав манифест деплоймента без использования CI/CD и вот этих всех вещей, если ты до этого K8s никогда не трогал, потому что важно сначала потрогать всё руками. Если всё пройдёт успешно, хорошо и комфортно, то именно после взаимодействия того, как ты это сделаешь своими ручками, через команды, через набивание в руки, прямо вот в мышечную память того, как нужно там что помониторить, посмотреть, вот тогда можно будет уже это всё упаковывать в CI/CD. Конечно же, ты найдёшь гайдов кучу, где сразу весь полный фарш тебе предлагает, но, а, делая просто за человеком, ты с трудом можешь чему-то научиться. Поэтому просто бери вот это вот задание: развернуть приложение в Kubernetes и сделай его так, как у тебя получится. И уже потом приходи к более э-э лучшим формам, к бест-практисам: "А как лучше нужно было сделать? А как можно ещё улучшить? Более автоматизировать твой процесс."

>> То есть, во-первых, нужно понимать основные концепции, да? То есть основные какие-то э-э объекты, которые есть в Kubernetes, из каких частей он состоит. Э-э, я не думаю, что для джуниора важен конкретный навык понимания, как же конкретно работает self-hosted Kubernetes, как конкретно его там деплоить. Но компоненты, э-э, обязательно нужно знать, какие там сервисы его образуют. Обязательно нужно понимать какие-то концепции и какие-то конкретные операции, которые ты можешь day-to-day делать. Ну, то есть самая простая история: ты должен в деталях понимать, каким образом сервис, который появляется в репозитории, каким образом он оказывается опубликован наружу. То есть какие там конкретные шаги, каким конкретно образом стартует, э-э, деплой, а кто это конкретно делает, какие конкретно существуют стратегии деплоя. Э-э, и из этого как бы у тебя исходят, э-э, опять же штуковины, с которыми мы сталкиваемся там тоже регулярно. То есть почему э-э новый плей не произошёл? Э-э, почему там конкретный какой-то там э-э под не стартует? Почему же там в Argo CD мы видим какие-то там красненькие хреновины? Как там делать конкретные штуковины, связанные с обновлением данных?

Как саму вот концепцию GitOps, её очень важно знать, потому что, а-э, мм, управление, а, такого рода, э-э, системами, оно часто связано с тем, что, а, любой ручной доступ и вот эти вот э-э штуковины, которые люди часто делают, э-э, на локалке, типа: "Давайте мы сделаем `apply`, и у нас всё получится". Такие подходы, конечно, в продакшн-системах практически невозможны. И если мы делаем такие оркестрации, у нас исключены любые ручные изменения. Нужно понимать вот этот сам сам принцип, понимать, каким образом это всё готовится, а, и, э-э, как бы это принять для себя, потому что есть вещь, которая типа, ну, на локалке делается просто, но которая в GitOps делается с большим обвесом э-э различных практик и приседаний. Эти все вещи нужно понимать. Очень неплохо, если человек понимает, э-э, Helm, умеет написать простенький Helm, и умеет понимать основные концепции вот этого YAML-девелопмента. Это всё тоже достаточно важно. А поэтому, ну, то есть, если резюмировать, то это краткий ну, пул такой из двух вещей, которые нужно понимать. Джуниор: как деплоится приложение из состояния, вот у тебя есть репозиторий, и вот мы по HTTPS зашли с каким-то конкретным доменным именем. А, и второе — это, а что делать в ситуации, когда а у тебя этот деплой не произошёл? То есть типа человек должен уметь обсудить, э-э, типа: "Вот у меня там аа перестал открываться по этостачке, что там может быть?" Поэтому это две вещи, которые, мм, точно надо знать, с которыми точно придётся столкнуться и поработать.

Конкретная прямо вот практика с клаудами, она зависит от того, какое облако ты выберешь, какого провайдера. На самом деле для уровня джуна, конечно, достаточно изучить базу одного клауда, всего лишь одного. Везде своя особая инфраструктура, везде нужно адаптироваться, приспосабливаться, обучаться. Но если основные концепты ты будешь понимать, у тебя уже будет какой-то практический опыт, свичнуться туда и или сюда, в то или иное облако, будет не такая уж большая проблема. О какой базе речь? Про все типовые ресурсы облака. Это инстансы, то есть там виртуальные машины, которые создаются, это базы данных, VPC, сеть, хранилище, разные бакеты, стримбакеты, роли доступа, политики безопасности, `network policy`, роли, понимание биллинга, вот этих счетов, чего сколько стоит, какие типы инстансов бывают и так далее. Многие клауды предлагают свои курсы, а, нативные курсы и документацию к обучению. Ну и самое главное, э-э, самое славное и прекрасное, что часто клауды предлагают бесплатные тарифы, ну, тарифы или кредиты на это обучение. И в целом, м-м, если с умом подходить, создавать ресурсы, тут же их удалять и вообще следить за тратой, за тем, что ты создаёшь и сколько тратишь, это может вообще всё это обучение обойтись в ноль. Клауды часто пугают либо своей вот этой непонятностью, непонятно, как применить, как с ними работать. И второй момент — это то, что они очень дорогие, и не хочется из своего кармана платить. Поэтому тут нужна, конечно, внимательность, чтение, а не документации.

Вся инфраструктура, которую мы создали до, компания работает, ты уже стал достаточно профессиональным DevOps'ом, системным администратором. У тебя есть многие инструменты, всё работает, мониторинг крутится, логирование, тачки и прочее, прочее, прочее, базы данных. И теперь по непонятным причинам появился дедлайн, когда железные сервера все умрут, и необходимо всю железную, вообще всю инфраструктуру перевести в облака. Это начало той самой замечательной практики. То есть все шаги, которые вы выполняли до с конфигурацией Ansible, с настройкой серверов и так далее, и так далее, и так далее, вот это всё, что вы уже сделали, нужно перевести в клауды и настроить. Всё это наверняка не составит труда, потому что вы сделали, и вам с этим всем поможет, и будет вам счастье. Поэтому приступаем к практике.

Тут очень важна оговорка, что мы типа говорим про ситуацию, когда cloud — это вот прямо основная история в какой-то конкретной компании. То есть я бы, ну, то есть если мы изучаем э-э что-то с нуля, э-э, было бы здорово не начинать с клауда также и не начинать с Kubernetes, потому что, ну, на выходе получится весьма, э-э, весьма малок. Всё-таки подходы облачные, они весьма специфичные и нацеленые на то, чтобы у человека достаточно высокий уровень абстракции, в котором он решение достаточно простых операций делегирует в cloud. То есть основная фишка клауда, что типа он экономит время на operations. В первую очередь, когда мы говорим о клауде, тут нужно понимать, что человек должен понимать infrastructure as code. И тут, конечно, Terraform и подобного рода мм штуковины. То есть человек, любой cloud-инженер должен достаточно бодро отвечать про то, как Terraform управляет конкретное облако, то с которым он работал. То есть, если ты работал с AWS, то, ну, про AWS. Если ты работал там с Яндекс.Клаудом, то про Яндекс.Cloud. Должен понимать эти концепты. Должен понимать концепт, в котором, ну, типа, э-э, какие конкретно шаги и какие конкретно ресурсы тебе нужно, мм, настроить для того, чтобы вот в этом кладе инфраструктура, необходимая для а какого-то конкретного сервиса, потому что, ну, самая типовая задача: мы берём какой-то веб-сервис и его в cloud пытаемся засунуть. То есть, как мы это будем делать? А какие конкретно вот там элементы? То есть ты там, условно, ты должен понимать, что такое VPC, что такое какой-нибудь, э-э, м-м, managed database и как он называется в том клауде, которое ты изучаешь, как к нему коннектится э-э приложение, какие существуют `network policy`, какие существуют типы инстансов или методы деплоев. Если там ты Kubernetes крутишь в клауде, то какие конкретные методики или специфики Kubernetes конкретно в этом клауде? Ну, в первую очередь, специфики авторизации, конечно, э-э, там обычно интересуют. И вот это всё, оно мм позволяет понять, что человек действительно что-то крутил. То есть, если ты покрутил достаточно плотно, то ты, скорее всего, э-э основные эти объекты припоминаешь. Если ты опять же прочитал книгу, э-э, Cloud какой-нибудь Infrastructure Engineer, в котором тебе рассказывают умные слова, то, скорее всего, оно не складывается в какую-то концепцию, потому что, ну, в принципе, для джуниора важно не понимание академическое систем дизайна, а это умение делать что-то руками. То есть это прямо вот отличие представителя профессии от того, кто читал, оно заключается в том, что ты что-то можешь сделать руками, то есть ты можешь взять и что-то сделать. То есть там все мы, ну, там все, кто физику в школе изучали, примерно понимают, каким образом от гидроэлектростанции попадает электричество ко мне домой и светит лампочка там у меня. Да. Но, а, м-м, никому не приходит в голову заявляться, что я вот сейчас полезу на ЛЭП и там возьму и какой-нибудь изолятор поменяю. Ну, типа, я готов к этому. И для этого, ну, в профессии предусмотрены, э-э, ну, простые механизмы защиты. Ну, сертификация на определённое там количество, э-э, вот этих самых L3 там, да, существует определённые у специалиста. Вот. Но при этом люди почему-то думают, что достаточно почитать книжку про какой-нибудь Amazon и говорить, что всё, я теперь могу оперировать инфраструктуру, которая генерирует там а э десятки тысяч долларов в минуту. Ну, фиг знает. Вот. Поэтому э-э ну, то есть я к чему вот этот пример привожу. Э-э, очень важно, э-э, демонстрировать практические знания и умение вот что-то сделать руками, которое подтверждает, что ты не читал про управление самолётом, а реально этим самолётом управлял. А, и это как бы вот ключевая штуковина.

Infrastructure as Code — это то, что позволяет нам, как и Ansible, держать наши изменения, наши вообще в принципе описания нашей инфры в документе, в коде, который мы можем контролировать, фиксировать, изменять, и всё это будет подконтрольно. И после вот работы с клаудами, как раз-таки Terraform призван тому, чтобы вот тыкательный UI-ный метод, которым ты разворачивал облака, перевести в код. Я лично рекомендую это делать, конечно же, сначала после того, как ты поковырялся руками, потыкал, посмотрел, и только потом переходить в Terraform. Потому что, как я говорил, необходимо иметь понимание и практику в руках, помнить, видеть, как эти ресурсы появляются, что они собой представляют, почитать описание ресурсов и так далее. Можно сразу перейти в документацию и делать всё через Terraform, потому что часто у провайдеров, которые предоставляют взаимодействие между облаками и Terraform, есть документации, которую можно сразу применять, но лучше всего это сделать постепенно, когда уже в руках есть какой-то опыт. Именно вот чисто с панелей управления. Помимо того, что нужно понимать синтаксис языка, также нужно понимать, что такое state-файл, как он формируется, зачем он нужен и как его лучше всего хранить. Что такое `terraform plan`, `terraform apply`, `import`? То есть какой-то перечень основных команд стоит попробовать на практике и попробовать, а как оно будет, а как оно работает, каким образом можно без копипаста вот э-э создать несколько там инстансов или баз данных для другого сервиса, то есть с другим названием, но чтобы это не было копирование всего-всего кода, чтобы это было как это было переиспользование, то есть что такое модули, как взаимодействовать и работать ресурсами с циклами и так далее. В общем, вот эти основные инструменты нужно попробовать. Чтобы это сделать и испытать, так сказать, на себе удовольствие автоматизации клауда, нужно те задачи, которые ты выполнял с в предыдущем шаге, связанные с клаудами, перенести в Terraform. И в таком случае у тебя получится полезная, а, очень эффективная практика работы с Terraform.

Второй форме, конечно, нужно понимать, во-первых, зачем нужен state-файл, то есть, что это такое, э-э, и что там хранится. И и главное, к ну, что будет, если она пропадёт, например. Э-э, нужно понимать основные команды. То есть какие есть команды для того, чтобы какие-то изменения применить, какие есть команды для того, чтобы изменения применить частично, а какие есть, э-э, мм, так сказать, проблемы при оперировании Terraform, как с этими проблемами разбираться. Очень прикольно, э-э, ну, понимать, а каким конкретным образом описывается инфраструктура в Terraform, а, и какие там существуют отличия между, например, провайдером и ресурсом, а между, например, что такое модули и как эти модули версионируются. А, и это всё, как эти модули подключаются, какие тут есть тоже особенности по работе с модулями. А эти все вопросы достаточно базовые. И я бы сказал, что, э-э, ну, такое не часто ожидаешь от джуниора э-э в ситуации, если твоя инфраструктура не стопроцентно Cloud Native. То есть понятно, что, ну, есть такие, где, ну, только K8s, ничего, кроме клауда. И в такой ситуации, конечно, для джуниора есть некая специфика. То есть он должен специально готовиться к клаудам и вот то, что я и писал, прямо специально изучать. Но если ты, э-э, ну, какой-то General DevOps, то, вероятнее всего, а, с первого дня джуниора такого не будет ожидать. Ну, если ты, короче, вот целишься, то вот то, что я перечислил, это нужно учить, да, и пробовать на практике. Не учить, а пробовать на практике. Извините, обязательно нужно пробовать на практике и э-э со всякими фритайрами или там 5.000 руб. на счету того клаудного провайдера, которым ты решил попользоваться, обязательно нужно потыкаться, вот прямо поделать это и убедиться, что ты знаешь, как с помощью Terraform поднять инфраструктуру для типового веб-сервиса. Как это описать прямо целиком, как это удалить, как изменить, то есть изменить размер какой-нибудь чего-нибудь. Это всё нужно вот прямо объяснить, как ты это делаешь, потому что, ну, без этого, ну, знания Terraform — это не знание Terraform.

>> Если ты работаешь в IT-технологиях, то есть информационных технологиях, в сфере, где компьютер — это если не первый, то то второй уж точно после человека э-э инструмент, можно так сказать. И тебе нужно, ты обязан уметь с ним взаимодействовать на глубоком уровне, на уровне вот действительно такого настоящего профессионала. Поэтому базовые основы хотя бы одного языка программирования нужно знать. Того языка программирования, который тебе кажется актуальным, который тебе кажется интересным, удобным. Ведь в начале, в начале обучения языкам программирования ты больше работаешь как лингвист. Ты учишься понимать вот этот вот язык компьютерный, понимать, что где переменные, что такое там структуры данных, какие типы данных бывают, там разные алгоритмы, какие-то вот такие вещи, которые они не требуют высоких знаний в математике, в физике, в каких-то дисциплинах, которые действительно там криптографии. Нет, тебе нужно абсолютно базовые вещи, просто найти общий язык с компьютером, с программным обеспечением. Но, конечно же, когда я говорю про DevOps, это не самый первый и не самый основной, не самый главный важный навык. И, конечно, можно найти оффер, имея все те знания, о которых мы поговорили выше, без проблем можно иметь оффер, не зная языков программирования. Хотя, честно говоря, кажется, что пройдя все вот эти этапы, волей-неволей ты в эти языки погружаешься так или иначе. Но классно иметь какую-то такую основу и уже собранный базис. Навык не обязательный в начале пути. Но в дальнейшем, мне кажется, в будущем любой уважающий себя или жаждущий становиться более большим профессионалом, он так или иначе будет учить язык программирования.

Можно, конечно, сказать, что Bash — это язык программирования. Это, конечно, скриптовый язык, и прямо полноценным языком программирования назвать его сложно. Там тоже действуют определённые законы, которые присущи другим языкам программирования. Поэтому на неплохом уровне знать скриптинг, Bash-скриптинг — это уже что-то, чего-то стоит, это уже неплохо.

>> Во-первых, есть целая категория э-э DevOps-инженеров, которые пришли из какой-нибудь бэкэнд-разработки. И, конечно, такие ребята обычно говорят: "Мы как DevOps-инженеры можем, когда нам нужно что-то сделать, что-то нужно от владельца сервиса, мы берём и делаем пулреквест с тем, чтобы там это реализовать". И они, конечно, будут говорить, что неплохо было бы это знать, уметь делать сразу же "из коробки" и понимать, чем `env` конфигурация отличается от `flag` конфигурации. Но, э-э, это очень специфично. На практике м-м любые языки программирования, они скорее в DevOps'е, а они скорее играют роль скриптовых языков автоматизации, то есть штуковины, которые делают автоматизацию рутинных действий. Э-э, там надо по крону, э-э, посчитать, э-э, какую-нибудь небольшую штуковину, там, какую-нибудь метрику выплюнуть в мониторинг. Нужно сделать какую-нибудь очистку, нужно сделать какую-то рутинную автоматизацию, которая там будет что-то делать регулярно. То есть самый типовой э-э мм применение любых скриптовых языков — это сделать бэкап по крону. Его можно делать с помощью Bash, его можно делать с помощью Python и с помощью там любого языка, который, э-э, ну, типа хочется делать. Но тут важно понимать, что э-э ну, международный язык, наверное, это всё-таки Bash, Python, поэтому всякие, ну, там, Go-программисты или программисты, которые говорят: "Я вообще-то могу делать автоматизации скриптовые на Node.js". Ну, безусловно, можешь, но вряд ли найдётся много DevOps'ов, которые способны будут это поддерживать. Это является существенным блокирующим фактором. Вот именно количество инженеров, которые готовы поддерживать такую вот разработку. Поэтому Bash, Python на уровне скриптовом из раздела операции с файлами, операции с процессами, э-э и циклы, операции с текстами, э-э, регулярки, э-э, которые, мм, ну, можно использовать. В принципе, этого достаточно для того, чтобы, э-э, эту базовую скриптовую потребность э-э закрывать. Дальше там начинается, ну, то есть следующий этап — это там начинаются свои отдельные микросервисы, которые выполняют какую-то суперважную функцию инфраструктурную, свои отдельные Kubernetes-операторы. "А давайте напишем их, это же так очень необходимо". А, и но этот путь выбирают, во-первых, далеко не все инфраструктурные команды, а, во-вторых, это 100% не то, что требуется от джуниоров. Поэтому, ну, надо рассматривать именно как скриптовый язык для автоматизации рутины.

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