Решил я тут выделить преимущества своего наставничества и DevopsTrain перед популярными образовательными платформами 😎.

Давайте пробежимся по пунктам:

Индивидуальный подход
✖️ у других: обучение в группе, зачастую довольно большой
✅ у меня: обучение 1 на 1 с ментором (это я, если что)

График занятий
✖️ у других: определенный, с дедлайнами
✅ у меня: вы занимаетесь в своем темпе

Старт занятий
✖️ у других: в определенные сроки
✅ у меня: в любой день

Время занятий
✖️ у других: строго в определенное время
✅ у меня: вы сами бронируете удобное время в календаре

Стоимость
✅ у меня: Х
✖️ у других: 2Х-3Х

Репутация
✖️ у других: терять уже нечего
✅ у меня: крайне важна

Процесс обучения
✖️ у других: большое кол-во видео с минимальной практикой
✅ у меня: интерактивная платформа для выполнения задач, без видео

Возврат средств
✖️ у других: хрен вернешь чего
✅ у меня: согласно формуле расчета по оферте. Прецедентов не было пока.

Так что задумайтесь, у кого вы хотите учиться 😁.

☝️На апрель, кстати, осталось 1 место.

Подробнее о наставничестве можно почитать тут: https://devops.lifeisfile.com/post/mentorship/

Моя платформа: https://devops.lifeisfile.com

📎 Написать мне можно на почту devops@lifeisfile.com или в телегу.

Из каких профессий приходят в девопсы 👻

📎 Информация собрана из разных мест, включая общение с людьми, которые проходят обучение в devopstrain.

📈 Из тех. поддержки

Человек работал в ТП бок о бок с командой девопсов, нахватался у них разного, тема стала интересовать и плавно начал вкатываться.

📈 Из пехоты

Человеку 67 лет, служил в армии США на разных позициях. В 81-м начал интересоваться армейскими компьютерами, стал изучать язык BASIC. Затем прокладывал телефонию и LAN, и стал админить Windows NT. Потом переключился в Unix, и только потом уже в Devops. Вот такая интересная и долгая карьера. Те, кто думает, что уже опоздал - напрасно.

📈 Из QA (тестирование)

Автоматизировал тесты на Python и Docker, чуть касался инфраструктуры, которая выполняла эти тесты. Через 2.5 года перешел в devops.

📈 Из сисадминства

По наблюдениям, это самый очевидный путь для большинства.

📈 Из разработки (бекенд и даже фронт)

Собственно, автор этой заметки именно оттуда, хотя опыт сисадминства был и до этого еще.

📈 Из пекаря

Как вам такой путь: пекарь - официант - техподдержка - управление инцидентами - devops.

📈 Из DBA (администрирование баз данных)

Надоело готовить Oracle, перешел в Devops.

👾 Пишите в комментах, откуда вы к нам прибыли или собираетесь, интересно почитать.

🔒Основы безопасности в devops

Недавно прошло соревнование Pwn2Own 2024, результаты которого в очередной раз напоминают о главном правиле: абсолютно безопасных систем почти нет 👀, особенно если речь идет о приложении, в котором несколько сотен тысяч строк. Open source тут далеко не гарантия надежности.

Наша задача как devops инженеров - снизить вероятность взломов.

Для этого есть несколько правил:

1️⃣ Проблематично сломать то, к чему нет прямого доступа. Надежнее всего выключить сервер из сети, но это не всегда хороший вариант 😁.

Правило: наружу должно торчать только то, что необходимо. Например, если речь про сайт или мобильное приложение, то открыть нужно только доступ к 80 и 443 порту для браузера и аппки. Всякие служебные сервисы должны быть не просто закрыты файрволом, но желательно вообще сидеть во внутренней сети.

2️⃣ Бекенд и фронтенд должны быть спроектированы таким образом, чтобы известные методы взлома не работали, к примеру SQL инъекции, и прочие инъекции. Это не задача девопсов, но понимать этот вектор атаки важно.

3️⃣ Отказы в обслуживании или DDOS. Тут речь не про взлом, а про то что, приложение ляжет от паразитной нагрузки, что тоже так себе. Решением может стать фильтрация трафика своими средствами или внешними, вроде cloudflare.

4️⃣ Грамотное разделение доступов в компании: разработчикам не нужно (ну почти) иметь доступ к данным пользователей, поэтому не нужно и провоцировать их на это. Если нужно что-то поменять в базе, пусть пишут миграцию, которая будет применена в процессе CI/CD или через специальный хендлер

5️⃣ В git не должно храниться ничего, что представляет угрозу безопасности: пароли, ключи и тд. Приложение в момент запуска должно ходить в vault или аналог за всеми кредами, которые требуются для его работы.

А как у вас в компании с безопасностью? 👾

DevopsTrain

В продолжение поста про безопасность, сегодня поговорим про обновления, которые являются ключевым фактором обеспечения безопасности.

👽 Тут, кстати, все неоднозначно.

С одной стороны, нам все говорят: "обновляйтесь до последней версии", потому что в ней исправлены ошибки и уязвимости. Но забывают упомянуть, что вместе с этим могут быть добавлены новые ошибки и уязвимости 🫠.

Конечно, вы все уже наслышаны про недавний бекдор в архиваторе xz. Напомню, там была история, про то как один из разработчиков долгие годы втирался в доверие к мейнтейнеру проекта, в итоге, получил необходимые полномочия, чтобы добавить бекдор в исходный код. Но внимательный глаз Andres Freund обнаружил вредоносный код во время проведения бенчмарков и оповестил об этом сообщество. В итоге, версии 5.6.0 и 5.6.1 оказались уязвимыми.

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

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

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

А ведь это тянет за собой изменения функционала, поэтому, мы, девопсы, без работы не останемся 🤌.

DevopsTrain

Раз уж в прошлом посте речь зашла про обновления, то имеет смысл поговорить про версии и схемы версионирования.

Самая популярная схема - Semver . Пример: 2.0.1

Тут выделяют части:
▪️ Major, в данном случае это 2
▪️ Minor, в данном случае это 0
▪️ Patch, в данном случае это 1

Когда же инкрементировать каждую из частей в данной схеме?

Major обновляем только в случае серьезных и зачастую обратно несовместимых изменений.
Minor обновим, если внесли значимое изменение, но оно не рушит обратную совместимость.
Patch - для очень мелких изменений и исправлений ошибок.

Еще вариант схемы - Calver. Пример: 2023.04.2

Вариаций может быть много, версия может включать день, квартал и Patch на конце. Он может быть полезен в системах, где часто происходят изменения и желательно знать время их выпуска, либо наоборот вы знаете график релизов заранее. Пожалуй самый яркий пример: Ubuntu. Скоро как раз ожидается версия 24.04 👽🤌

И конечно, вы наверняка знакомы со схемой Sequence base versioning, то есть простое увеличение целого числа. Примеры Firefox 125, Fedora 40, Android 15.

Наткнулся на интересное обсуждение зарплат и уровня жизни DevOps инженеров в разных странах.

Различия существенные: в Европе от 35К евро в год и до $350К+ (включая различные компенсации) в США. Конечно, в северной Америке совсем другие зарплаты, цены правда тоже другие.

Но факт остается фактом, американский рынок самый платежеспособный 💵.

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

В РФ можно расcчитывать на ЗП от 300К, бывает до 500К (ну это верхняя планка, чаще всего меньше). Что соответствует примерно 36К-60К евро в год.

👌 Но цены в России ниже европейских, поэтому уровень жизни девопсов плюс-минус такой же.

☝️На зарплату сильно влияет опыт, поэтому джун будет зарабатывать меньше в любой точке мира, но уже спустя несколько лет можно рассчитывать на существенную прибавку.

🤌  В Devopstrain созданы практические курсы и все условия для получения практического опыта. В данный момент прорабатывается новый проект "стажировка", который будет представлять собой возможность погрузится в реальную работу со всеми типовыми процессами и инструментами. Ориентировочный срок запуска - осень 2024.

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

Какие планы на праздники?

Шашлыки - это само собой, но пора бы заняться обучением (отговорки работой больше не принимаются) 😏

Дабы придать вам мотивации решил запустить "майские акции":

1️⃣ 1 курс + еще 1 курс = 3 курса
Выбирайте 2 любых курса на платформе и забирайте третий в подарок 😎

2️⃣ Скидка 5% на Индивидуальное наставничество.
Хотели прокачаться в Devops? - самое время начать! 👾

*Cкидка на наставничество действительна только на 3 места. Акции действуют до 5 мая.

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

Сегодня представляю вам подборку ответов людей на вопрос: "Что вам больше всего нравится в вашей работе DevOps инженером?"

👉 Короткий ответ: "Зарплата" =)
Что ж, трудно не согласиться 😁

👉 "Если ты человек, которому интересно как все крутится, любишь решать пазлы, с возможностью иногда кодить, и за это ты еще и получаешь деньги, разве это не мечта? Ты можешь выстроить архитектуру по своему усмотрению, сесть и наблюдать как графики на мониторинге показывают как хорошо ты выполнил свою работу. А если ты разработчик, что ж, работай на следующий спринт."

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

👉 "Каждый день разный. Когда инфраструктура работает четко, я чувствую как усиливаю свою команду разработки. Мне не все нравится в этой работе, но ее невозможно бросить, когда ты делаешь такие интересные вещи."

👉 "Я просто занимаюсь своим хобби, а мне за это платят. Счастливчик."

👉 "Мне нравится, что мне доверяют решать самые сложные проблемы, а когда я их решаю люди в восторге.

👉 "Я родился деплоить kubernetes кластеры."

👉 "Круто, когда никто не знает, что ты делаешь, но ты «тот парень, который решил проблему». Также здорово иметь дело со срочными запросами и инцидентами, связанными с продуктом. Да, это стресс, но, черт возьми, ничто не сравнится с тем чувством, которое испытываешь, когда исправляешь чертову вещь, от которой пострадали почти полмиллиона пользователей."

👉 "Постоянное изучение новых инструментов очень затрудняет замену нас и требует также навыков межличностного общения и социальной инженерии."

И все они на самом деле правы 👽🤌

А каким бы был ваш ответ? 👇

Как безопасно хранить и использовать секреты

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

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

📎 А еще есть секреты инфраструктурные, то есть те, которые не требуются приложению для работы, но используются для создания и работы самой инфры, связанной с приложением или не очень связанной.

☝️Разделять по этим типам секреты имеет смысл по той причине, что подходы для их внедрения могут отличаться. Например, часто секреты в приложение добавляются уже в процессе деплоя, а хранятся в специализированных хранилищах типа Vault.

Если мы говорим про инфраструктурные секреты, то там есть разные подходы:

▪️Можно использовать интеграцию с тем же vault для тех инструментов, которые используются для деплоя: helm, helmfile, terraform. Тут непосредственно секреты хранятся в виде пути: pass: ref+vault://databases/postgres/gitlab#DB_PASSWORD

▪️Еще одним решением может быть sops, то есть хранение в зашифрованном виде.

❗️Не столь важно какой подход вы выберите, важно запомнить, что ни при каких обстоятельствах секреты не должны попадать в код, и уж тем более на публичные git репозитории.

👽😬 У нас был кейс, когда данные SMTP (AWS SES) попали в открытый доступ на github. Среагировали мы быстро, не более получаса прошло, но было уже поздно, суточная квота писем (а это 500К) была успешно использована спамерами.

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

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

Сегодня публикую некоторые из наиболее интересных вопросов:

1. Какой системный вызов завершается успешно, хотя код его завершения ненулевой?

Ответ: системный вызов fork() в Unix-подобных операционных системах, таких как Linux, создает новый (дочерний) процесс, дублируя текущий (родительский) процесс. У успешного выполнения этого системного вызова уникальное свойство отличается от большинства других системных вызовов: он возвращает разные коды в родительском и дочернем процессах. В родительском процессе fork() возвращает PID (идентификатор процесса) нового дочернего процесса, который является положительным числом. Это позволяет родителю идентифицировать и управлять его дочерними процессами.

2. Что происходит на системном уровне, когда вы выполняете в терминале ls -l?

Ответ: коротко так: Запуск shell-интерпретатора - Разбор команды - Поиск исполняемого файла - Запуск нового процесса - Замена образа процесса - Выполнение команды - Вывод результатов - Завершение процесса.

3. Сколько максимум процессов может быть в состоянии Running?

Ответ: максимальное количество процессов, находящихся в состоянии RUNNING (R) в системе Linux, определяется архитектурой системы и конфигурацией ядра. В непрерывном режиме в системе может работать только один процесс на каждое ядро процессора. Все остальные процессы имеют состояние S/D и ждут своей очереди на выполнение.

4. Какие технологии лежат в основе контейнеризации?

Ответ: две ключевые технологии лежат в основе контейнерного подхода в Linux: Namespaces и Control Groups. Пространства имен используются для изолирования рабочих процессов контейнера друг от друга и от хостовой системы. Технология control groups обеспечивает ограничение и изоляцию использования ресурсов (таких, как CPU, память, дисковое пространство, сеть и т. д.) каждым контейнером.

А теперь по кубу:

5. Что такое headless service?

Ответ: Headless Service - это особый тип service в Kubernetes, который не имеет собственного IP-адреса для обращения к нему. Вместо этого он делегирует управление прямо к подам. Наиболее полезен для приложений, где информация может быть сразу на всех узлах, и нагрузка будет распределяться между всеми узлами.

6. Сколько нод ETCD кластера оптимально запускать?

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

✅ Остальные популярные вопросы с подробными ответами можно посмотреть в моем Devops Roadmap.

А какие вопросы вам задавали на собеседованиях, на которые вы не смогли ответить? 👇

Пятничный видос про немцев и кубер 🍳🤓

Немного про Docker Hub.

Все наверное, уже слышали, что Docker отключил для российских IP свой Hub, где по дефолту хранятся образы.

👽 Это стало полной неожиданностью (с чего бы, да?) и коснулось многих.

📎 Ребята даже успели поднять свой proxy для всех.

А потом, спустя несколько дней, DockerHub снова заработал для российских IP.

👀 Что это было никто не понял, но не так важно.

👾 Я бы назвал это учениями, которые показали проблемы в компаниях.

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

И это несмотря на то, что мы уже давно используем Harbor для хранения образов, просто, оказалось что далеко не все приложения его используют.
😎 Оперативно пофиксили и возвращаться на DockerHub больше не планируем.

Мы поступили так: Harbor умеет работать в качестве кеширующего прокси, и ходить за образами во внешний Registry, если локально в кеше не нашел. Настроили его на зеркало докерхаба и это решило нашу проблему в моменте. Если зеркало отвалится, мы просто перенастроим его на другое.
Еще вариант: ходить на DockerHub с Harbor через VPN, но это просто чуть сложнее в настройке, поэтому не стали так делать.

Мораль такова: будьте готовы к любым резким движениям от любых компаний, особенно западных.

🤔 Автор канала задумался: а что будет, если CloudFlare перестанет работать с РФ?

🎉 6 июня Кубернетесу исполнилось 10 лет!

Да, как будто только вчера щупал первые версии, а это было аж в 2016. С тех пор много чего изменилось в самом кубе, в мире devops и облачных сервисах.

👨‍🍳 В пару кликов запустить кластер, как сейчас, было нельзя, но очень хотелось. Слабоумие и отвага позволяли уже тогда запускать продакшн нагрузку в k8s, и это выглядело фантастически на фоне обычных виртуалок с докером.

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

Немного истории:

Гугл давно использовал контейнеры в своей инфре, еще до появления докера. У них даже была своя платформа под названием Borg, которая стала прототипом для k8s.

6 июня 2014 года был сделан первый коммит в репозиторий Kubernetes, а через год, когда вышла версия 1.0, Гугл передал управление проектом Cloud Native Computing Foundation (CNCF), что позволило еще больше укрепить его статус открытого проекта. С тех пор Kubernetes стал стандартом для оркестровки контейнеров. Он поддерживается крупнейшими облачными провайдерами, Google Cloud, Amazon Web Services и многими другими, включая отечественные облака.

Немного цифр 👀:

88,474 - людей приняло участие в разработке
15,121 - людей, кто коммитил код
4,228,347 - вместе они сделали столько изменений

👉 Все это делает k8s вторым по величине open-source проектом в мире. Первый, я думаю вы назовете сразу)

☝️ Умение работать с k8s является сегодня ключевым для Devops инженера, и совершенно точно имеет смысл проинвестировать свои усилия в обучение этому инструменту.

Напомню, что Devopstrain поможет вам в этом: у нас есть 2 авторских курса по Kubernetes, ставшие хитами продаж: 👇❤️‍🔥

https://devops.lifeisfile.com/courses/kubernetes/
https://devops.lifeisfile.com/courses/kubernetes_advanced/

А вот и еще один отзыв по программе наставничества 👾🤌

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

Артем, 17.06.24

В DevopsTrain 👾

Ранее я делал пост о том, почему важно прокачивать скилл программирования для целей devops.

Теперь хотелось бы немного углубиться в тему, чтобы показать почему имеет смысл освоить Golang хотя бы на базовом уровне.

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

✅ Удобство развертывания

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

✅ Статическая типизация

Множество ошибок может быть поймано еще на этапе сборки, что сильно повышает надежность программы. В python тоже можно задавать типы, но можно и не задавать =)

✅ Эффективность

Go тупо быстрее чем интерпретируемые языки вроде Python или Ruby. Это факт. И памяти он ест меньше. Благодаря встроенной поддержки с первого релиза конкурентности, писать асинхронный код и запускать задачи в несколько потоков довольно просто и быстро.

✅ Стандартная библиотека

Под большинство ваших задач найдется решение в стандартной библиотеке Go. Она первоклассная. Но всегда есть возможность подключить сторонние решения, которых тоже очень много.

В целом экосистема и количество носителей языка Go хоть и уступает по размерам Python, но все же очень масштабная. Не даром эти известные проекты написаны на Go:
Kubernetes, terraform (и большинство продуктов HashiCorp), docker, minio, hugo, restic, grafana, prometheus и многие другие.

С чего начать изучение DevOps? 🤔

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

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

К фундаментальным вещам я отношу:

1️⃣ Основы операционных систем, в частности Linux, как безальтернативный вариант для devops. Сюда же относятся и файловые системы, и наборы популярных утилит для управления системой и траблшутинга. Работа в терминале - обязательно.

2️⃣ Компьютерные сети. В своей реализации они платформонезависимые (фундаментально), но уметь приложить к нужной ОС или оборудованию может быть полезно.

3️⃣ Виртуализация и контейнеризация. Нужно уметь различать их и знать области применения.

4️⃣ Основы автоматизации и программирование. Умение написать программу или скрипт на одном языке сильно поможет вам в освоении другого. Ведь главное - это сам принцип.

👉 Это, пожалуй, база, с которой вы сможете двигаться дальше и изучать уже более узкие и более оплачиваемые инструменты вроде этих ваших кубернетесов, ci/cd и терраформов.

На платформе Devopstrain из базовых есть курсы Linux & Networks, а также Docker 🤌.

А всегда ли нужен CI/CD?

Сегодня порассуждаем на эту тему.

Принципы devops практик рекомендуют выстраивать полные цепочки поставок: от коммита до деплоя. Но всегда ли нужно следовать этим принципам 👽?

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

〰️ Приведу пример: у нас есть служебный сервис (не тот который является частью приложения, а вспомогательный/инфраструктурный), который обновляется в лучшем случае раз в год. И обычно занимается этим один или два человека. Создание полного пайплайна в этом случае смысла не имеет. Потраченное на него время не окупится.

👾 Да и в целом, любая автоматизация оправдана только начиная с определенного масштаба, а разовые процедуры выполнить проще без нее. Ведь автоматизация требует разработки и отладки, а это не бесплатно. К тому же, в случае с CI/CD, определенные шаги пайплайна через год при следующей попытке ее использования могут просто не сработать, из-за того что инфра могла измениться за это время, а никто не вспомнил что надо подправить пайплайн. У часто используемых сервисов этого не будет, т.к. проблема будет замечена и исправлена быстро.

Но все таки, чтобы хотя бы раз в год не пришлось чесать репу: "а как же деплоить то этот сервис??", у меня есть рекомендации:

1️⃣ Обязательно в репозитории с кодом пишите доку в файле README.md, где должна быть инфа: что это такое, как собирать и куда деплоить, что проверить после деплоя.

2️⃣ Желательно иметь некий Makefile для упрощения деплоя с правилами make build, make deploy и тд.

📌 А если вы хотите научиться строить пайплайны и эффективно применять их в процессе разработки современных продуктов, то для вас есть курс СI/CD на практике.

Сегодня у нас не только пятница, но и международный Sysadminday! Поздравляю всех причастных!

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

❗️А от меня, по такому случаю, только сегодня, на все курсы платформы действует полюбившаяся вам акция: 1 + 1 = 3 ❗️

👉 А всем сисадминам, которые думают над сменой профессии в пользу DevOps, советую Программу Наставничества, которая за 6 месяцев сделает из вас уверенных девопсов. На нее сегодня тоже скидочка 5% 😎.

* Чтобы воспользоваться акциями напишите "СИСАДМИН" и список курсов/информацию для наставничества на почту devops@lifeisfile.com

В продолжении темы про CI/CD захотелось порассуждать на тему "Terraform в пайплайне".

О чем собственно я: имеет ли смысл терраформ операции заворачивать в пайплайн для изменения инфраструктуры?
В моей практике я несколько раз видел попытки сделать такое. Самое удивительное, что это даже работало, но как правило недолго (:trollface)

👽 Я могу понять мотивы, которые двигают людей такое делать.
Очень хочется git-ops подхода, когда что-то изменил в коде и оно поехало деплоить инфру само. При этом тебе не надо настраивать креды, токены и прочее, даже не надо иметь локально терраформ нужной версии. Но это в идеале.

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

👀 В итоге я давно пришел к мнению, что terraform и cicd лучше не смешивать, гораздо удобнее и безопаснее выполнять инфраструктурные изменения с localhost. Единственное, что все-таки человеческий фактор играет роль, и иногда после локального apply люди забывают запушить обновленный код, но это уже решается иными средствами.

〰️ Есть еще интересный на вид инструмент - crossplane, который позволяет управлять инфрой из k8s через кастомные ресурсы. Шанса попробовать его не представилось, но думаю что это может сработать для ограниченного управления ресурсами для нужд разработки.

DevopsTrain