Сегодня поговорим о тестовых стендах, для чего они нужны?

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

Можно выделить такие популярные окружения как
- dev - сюда сливают все изменения из feature-branch и тестируют на тестовом наборе данных
- stage (он же staging) - а тут тестируют уже в максимально приближенном к проду окружении, в идеале даже на копии базы данных из прода
- production - ну а тут тестируют на пользователях то, что не выловилось на более ранних стадиях =)

Кроме этого часто тестируют отдельные ветки (feature branch) где добавлена только одна какая-то фича.

По URL можно придерживаться такой схемы:
dev: dev.mycompany.com
stage: stage.mycompany.com
prod: mycompany.com
Одна фича: feat-123.mycompany.com

✔️ Таким образом тестировщики знают что именно они тестируют и в каком окружении

Конечно создание и обновление окружений должно быть автоматизировано, особенно это касается динамических фиче-окружений, ведь не будешь же под каждую задачу вручную все создавать. Существуют разные подходы для автоматизации в зависимости от платформы которую вы используете для деплоя. Проще всего это реализовать в контейнерной среде (docker/kubernetes).

А вы тестируете на стенде или сразу в продакшн? 👽

Как известно, люди делятся на два типа: кто делает бекапы и кто уже делает бекапы.

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

Вместо этого поговорим о базовых принципах:

Принцип №1: не храните яйца в одной корзине (они нынче дорогие).

▪️Лучше хранить как минимум в трех. Что это значит? Не очень много смысла в том, чтобы снять бекап базы данных и положить его на том же сервере, либо даже в том же дата-центре, либо в другом дата-центре у того же хостера. В идеале даже лучше в другой юрисдикции. По степени паранои и требованиям к рискам выбирайте хранилище в нужном месте.

Принцип №2: проверяйте

▪️Регулярно проверяйте бекапы на возможность восстановления и в целом мониторьте процесс создания. Если проверку бекапов можно делать раз в месяц, то мониторить создание надо постоянно, то есть требуется настроенный мониторинг.

Принцип №3: шифруйте

▪️Чтобы ваши данные никуда не утекли, важно шифровать бекапы перед их отправкой на хранение, но вы должны четко понимать как будете расшифровывать при необходимости.

Принцип №4: интервалы создания бекапов должны быть приемлемы с точки зрения потенциальных потерь.

▪️То есть если для вас ОК потерять не более часа истории, то значит бекап должен быть ежечасный.

Принцип №5: Определитесь со стратегией (полный или инкрементальный бекап)

▪️В зависимости от частоты создания бекапа и его объема, правильно выбранный вариант избавит вас от проблем типа race condition, то есть ситуации, когда вы создаете бекап, пока прошлая процедура создания еще не завершилась.

👾 Если ваш десктоп на linux, то удобно использовать DejaDup + Gnome backups для создания ежедневных инкрементальных бекапов. Для серверных решений подходят такие вещи как minio client, s3cmd, rclone. А если нужно инкрементальный - то restic.

Как у вас с бекапами?

Поскольку я решил меньше времени тратить на работу, а вместо этого больше посвящать времени своим проектам, в частности DevopsTrain, у меня для вас предложение.

Мне было бы интересно взять несколько человек на индивидуальное обучение профессии DevOps.

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

📌 Детально предложение можно изучить ТУТ.

Что входит в программу?

✔️ 4 консультации (час-полтора каждая), где мы оценим ваш опыт, умения, приоритеты, стремления и выстроим индивидуальный план с регулярными встречами для координации и коррекции обучения

✔️полный доступ на ВСЕ курсы платформы, а именно:

◽️CI/CD
◽️Terraform
◽️Docker
◽️Kubernetes
◽️Kubernetes advance
◽️Devops Roadmap

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

✔️ Доступ к базе DevOps кейсов, доступный только в рамках этого предложения, его нельзя купить отдельно. Это подборка из моей Devops практики.

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

✔️ Для решения текущих вопросов - оперативная и приоритетная поддержка по email на весь срок обучения

Цель - сделать практическое обучение на платформе максимально эффективным и помочь вам достигнуть желаемого.

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

🤝 Жду ваших вопросов и отзывов, приложите ваше резюме по возможности, если у вас оно уже есть. В ответ я пришлю индивидуальный расчет стоимости.

Обращайтесь по адресу devops@lifeisfile.com или в телегу

Стандартизация vs монополия

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

Конечно, они действуют хитро, давая взамен удобство, но иногда оно обходится слишком большой ценой. Вернемся к облакам (и все что можно к ним отнести, например SaaS), тут канал про devops вроде как. Такие штуки как собственные сервисы визуализации и сборки метрик/логов, API gateways, Lamda/Cloud functions (serverless) не позволят вам быстро отказаться от них, т.к. стандартных аналогов нет.

А зачем, спросите вы, отказываться? Причин может быть много, от политических до экономических, думаю, что сейчас уже нет ни у кого иллюзий на этот счет. Каждый раз, когда вы планируете использовать какой-либо продукт, особенно облачный, задайте себе вопрос: "А если что, у меня есть альтернатива, на которую я смогу перейти в разумные сроки?"

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

☝️Стандарт - это хорошо, а монополия - плохо.

Почему я считаю, что email до сих пор один из лучших способов обмена информацией, несмотря на проблемы вроде спама?

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

Конечно, многие используют gmail, в том числе и для коммерческой почты, чтобы самим не заморачиваться со множеством проблем, которые решает гугл. Он, кстати, и создает их при этом. Я тут недавно заметил, что теперь на gmail можно поставить реакцию, прям как в телеге. Серьезно? Особенно прикольно это работает когда ты ставишь реакцию на письмо, которое уйдет не на гугловский ящик. Попробуйте) 👾

DevopsTrain

Поговорим про ближайшее будущее Devops, каким его я его вижу в течении следующих 10 лет.

👽 Сразу скажу, что к астрологам я не обращался, а все нижеперечисленное является компиляцией информации, собранной из разных частей интернета и приправленной моим личным мнением.

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

Кубер на железе
▪️K8s on bare metal все больше будет набирать обороты исходя из пункта выше, поэтому придется разобраться в тонкостях развертывания кластера своими силами. Внезапно окажется, что облака нас сильно разбаловали, но куда деваться.

AI/MLOPS
▪️Еще одним следствием перехода от облачных решений будет усиление внедрения MLOPS, то есть операций для поддержания полного цикла работы с так называемым искусственным интеллектом. Уже сейчас многие компании готовят ML у себя, но из-за увеличения общего внедрения AI этот тренд только усилится.

Инструментарий
▪️Похоже что такие инструменты как Crossplane получат большее распространение. Также в пятки терраформу дышит похожий инструмент Pulumi, который позволяет описывать инфраструктуру используя языки общего назначения. Это снимает ограничение терраформа, где можно использовать только фирменный HCL, однако несет в себе необходимость знать какой-то еще язык. Это очередное подтверждение тому, что навык программирования девопсам очень желателен.

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

Заметил, что обо мне, авторе канала, вы почти ничего и не знаете 👻.

Сейчас расскажу кто я и что вообще тут делаю:

👋 Меня зовут Александр, сейчас работаю DevOps инженером, по совместительству Go разработчик (для нужд devops). В прошлым бывал на позиции CTO.

В IT с 1999 года, именно тогда начал заниматься разработкой, а также настройкой и поддержанием серверов. В те давние времена еще не было такого понятия DevOps, но часть практик уже существовали. Шли годы, и мне все больше хотелось уйти от разработки и наладить CI/CD процессы в компании, что в итоге и было сделано.

👽 За свою жизнь сделал довольно внушительное количество проектов, своих и коммерческих (нужное подчеркнуть), обо всем можно почитать тут: https://lifeisfile.com/en/

🤠 Несколько лет назад у меня появилась идея создания практических курсов на собственной платформе, благо опыт в разработке позволял реализовать это с легкостью. Уже тогда мне было очевидно, что популярные образовательные платформы движутся не в том направлении, а их цена/качество очень далеки от идеала. Так появился проект DevopsTrain. Я уверен, что будущее не за массовым сегментом, а за персональным подходом.

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

В этот раз я бы хотел затронуть тему так называемых софт-скиллов, то есть умения коммуницировать с людьми.

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

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

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

Да, работа в команде она такая, 50% времени - это коммуникации в разном виде.

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

К этому надо быть готовым, ведь коммуникация - тоже часть работы, нравится или нет.

Решил я тут выделить преимущества своего наставничества и 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