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

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

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

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

NixOS - дистрибутив Linux, вдохновленный идеей Infrastructure as a code. 

Если вы используете Linux в качестве рабочей системы, то наверняка сталкивались с необходимостью настройки системы под себя после свежей установки 👽. Особенно это критично, если вы используете для работы несколько устройств. В голову приходят идеи вроде ansible или самописных скриптов, которые установят пакеты и накатят конфигурацию. Однако, это не лучший вариант, т.к. он императивный. Вы говорите что нужно сделать, вместо того, что вы хотите получить в итоге.

👉 Рекомендую рассмотреть интересный дистрибутив NixOS, в  основе которого лежит менеджер пакетов Nix с самым большим количеством доступных пакетов среди всех дистрибутивов. Конфигурация вашей системы включая набор пакетов, сетевые настройки, поддержка docker, список пользователей и всего остального задается в файле /etc/nixos/configuration.nix на функциональном языке nix. Придется повозится, чтобы настроить все под себя, но после этого вы просто будете получать готовую к работе ОС всего лишь одной командой:

nixos-rebuild switch

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

На моем горизиноте эта ОС появилась пару лет назад, но только теперь, спустя множество лет работы на традиционных Debian based дистрибутивах, я решил осуществить переезд на нее. Пока еще многое предстоит сделать, но это будет как минимум интересно 👾👀

DevopsTrain

Work-life balance в devops

Немного отвлечемся от сугубо технических тем сегодня. Расскажу о том, почему devops - это лучшая сфера IT, если вы хотите соблюдать здоровый баланс работы и отдыха и при этом остальные отделы компании будут рады 👽😁.

Раньше врачам платили пока человек не болеет, так и девопсам должны платить пока все работает.

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

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

То есть стремление снизить количество работы - это очень здоровое и выгодное для всех занятие.

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

📌 Небольшое объявление: в программе обучения появилась опция оплачиваемой стажировки после прохождения 🤌.

Как создавалась платформа DevopsTrain

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

Сразу были сформированы требования:

✔️ удобный интерфейс, с упором на практическую часть
✔️ возможность автоматической проверки
✔️ универсальность в плане текстового наполнения, а также в плане бекенда, который проверяет задание
✔️ расширяемость

Исходя из этих требований была разработана архитектура из нескольких сервисов, нарисован макет и составлено задание для frontend разработчика, т.к. я занимаюсь только бекендом и инфрой. Первая версия вышла в начале 2021 года, и включала в себя в качестве пилотного курса - "Kubernetes на практике".

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

С марта 2023 года на платформе произошли значительные изменения: улучшена как программная часть, так и образовательная, добавлены новые курсы, доработаны старые. Появился open-source инструмент для проверки заданий - kurator.

👀🔥 Ближайший релиз новой версии состоится в течение 2 недель, и будет включать в себя некоторые долгожданные функции, включая запуск кластера по отдельной кнопке.

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

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

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

1. Причины переезда
2. Подготовка
3. Переезд
4. Результаты

Итак, начнем с причин, почему я спустя более чем 10 лет работы на Ubuntu в качестве основной десктопной ОС отказался от нее в пользу NixOS:

👉 1. Ubuntu, как мне кажется, катится не в ту сторону.

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

Кстати, про обновления: даже когда ты сам хочешь что-то обновить тут тоже есть проблемы. Я использовал только LTS версии, которые выходят раз в 2 года, поэтому большая часть пакетов устаревает пока новая версия еще не вышла. Это также можно обойти подключив сторонние репозитории или ручной установкой, но такой подход не самый удобный. А еще есть риск, что система при общем обновлении до следующего релиза обновится с ошибками, которые придется каким то образом самостоятельно исправлять. Пару последних обновлений проходили гладко, но все таки всегда боязно это делать. Именно поэтому LTS расшифровывают как Less Time Stressed =).

👉 2. Все перечисленное выше нужно умножать на 2, т.к. у меня 2 ноута для работы: один большой и мощный 17", который я не таскаю в дальние поездки или на короткие вылазки, а второй - легкий 15" чтобы оставаться максимально мобильным. К примеру, в отель или за границу я беру только легкий ноут, он и дешевле и легче, а езжу я нередко.

👉 3. Исходя из 1. и 2. мне стало критически важно иметь систему, которая не умничает и конфигурируется через код. Да, именно код, на каком-то тьюринг-полном языке, а не yaml, чтобы я мог взять и накатить конфигурацию на любой из моих компов и получить идентичную систему со всеми нужными мне конфигами и пакетами.

👉 4. Обновление и вмешательство в настройки не должно ломать систему безвозвратно. И как раз nixOS это умеет: он создает отдельную версию системы в момент пересборки, и я всегда могу откатиться, если что-то пошло не так.

〰️ Кроме nixOS также этим критериям с виду соответствует guix, но она более экзотичная и с меньшим комьюнити и количеством доступных руководств. К тому же использует язык scheme (по сути как emacs lisp), который меня своими скобочками несколько нервирует.

DevopsTrain

Как закон Мерфи работает в devops

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

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

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

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

Мда, подумал я.

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

🚬 Другим не менее прекрасным днем я случайно заметил, что у нас в одном из продовых кластеров k8s отвалился vault. А чтобы его поднять нужно знать unseal ключи.

Я пошел спрашивать, но никто мне их не дал. Дело в том, что волт настраивал сотрудник который уже около года как уволился, а сам волт не перегружался 1.5 года. То есть у нас есть черный ящик с секретами для приложения, но достать их оттуда никак не получится 😑.

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

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

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

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

DevopsTrain