⌨️ STAT Жди, работай, спи

#process_management

Продолжаем искать в бытие процессов что-то хорошее, в прошлом и позапрошлом посте, выходило честно говоря не очень, но может быть в этом что-то получится. Итак статусы процессов. В этом посте рассмотрим только основные статусы процессов дополнительные флаги вроде (w,<,N, L, s) рассмотрим когда-нибудь ниже. сейчас набираем 'ps aux' и сосредотачиваем своё внимание на колонке STAT:

R — Running (Бегущий)
Это процесс в действии. Он либо выполняется прямо сейчас на одном из процессоров, либо ожидает своей очереди на выполнение. Развивая наши офисные метафоры, такой статус могут иметь белые воротнички активно что-то выстукивающие на клавиатуре, энергично идущие куда-то со своим отчетом или стоящие в очереди к копировальной машине.

S — Sleeping (Спящий)
Процесс ждёт события или ресурса. Возможно, он ожидает ввода от пользователя или данных из сети. Это лёгкий сон, из которого процесс легко пробудить. Представьте коллегу, который дремлет на рабочем месте, но сразу просыпается при звуке входящего письма.

D — Uninterruptible Sleep (Непрерывный сон)
Это глубокий сон, из которого процесс не может быть выведен сигналами. Обычно это происходит при ожидании операций ввода-вывода (записи на диск) на уровне ядра. Подобно человеку, в спрятавшегося от внешнего мира за амбушюры мощных наушников и смотрящего на экран монитора в ожидании завершения загрузки.

Z — Zombie (Зомби)
Процесс завершился, но его запись в таблице процессов ещё не удалена, так как родитель не забрал информацию о его завершении. Ресурсов этот призрак не потребляет, Это как сотрудник, который уже уволился, зарплату платить ему уже не надо, его рабочее место уже отдано другом, но всё ещё не убран из перечня штата отдела и еще парочки корпоративных списков.

T — Stopped (Остановлен)
Процесс приостановлен, обычно сигналом SIGSTOP. Он не выполняется, но может быть возобновлён сигналом SIGCONT. Представьте, что вы поставили фильм на паузу — действие замерло, но может продолжиться в любой момент.

I — Idle (Бездействующий)
Процесс не активен и находится в режиме ожидания. Это может касаться как системных процессов, так и пользовательских, которые временно не выполняют никаких операций и ждут определенного события, чтобы продолжить работу. Статус появился в некоторых версиях ядра Linux и относится к процессам, которые не требуют активных ресурсов. Например, это может быть фоновая задача, ожидающая запуска по расписанию, подобно тому, как человек бездействует, ожидая, когда закончится время его обеденного перерыва и придет время начать следующую задачу.

👰‍♀️ О моём опыте собеса на сисадмина (начало)

#изпервыхрук
#рекрутинг
#PersonalExperience

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

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

- Что вы знаете о компьютерных сетях?
- Честно? Ничего... - ответила я после долгого и тягостного молчания.

👰‍♀️ О моём опыте собеса на сисадмина (продолжение)

#изпервыхрук
#рекрутинг
#PersonalExperience

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

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

⌨️ Сигналы: 30 способов умереть или быть убитым

#process_management

Сегодняшний пост в формате Linux катехизиса.

1.Что такое сигнал?
Это уведомление посылаемое для оповещения о каком-либо событии

2. Уведомление кому?
Процессу

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

4. Что обычно посылает ядро?
Сигналы завершения и управления (умри сразу, умри, когда завершишь свои задачи, остановись, возобновись, управляющий тобой терминал закрылся, что чаще всего тоже значит умри, а если ты демон и тебе не нужен терминал - перезагрузись)
Ошибки (сегментации, арифметической операции, например, деление на ноль, некорректного доступа к памяти, недопустимой машинной инструкции)
Сигналы, касающиеся, взаимодействия с другими процессами (твой потомок умер, ты используешь канал (pipe), не имеющий адресата)
Таймеры и события (ты просил разбудить, пора что-то делать, ты сам знаешь что, если не знаешь что умри)
Прерывание пользователем (например , после нажатия Ctrl+C ядро посылает сигнал SIGINT он же может быть инициирован командой kill -2)

5. Какие сигналы чаще всего инициируются пользователем?
Кроме сигнала SIGINT,через Ctrl+C, который часто получают процессы, не желающие отдавать консоль терминала, это SIGTERM (kill без аргументов или kill -15), который чаще всего описывают как сигнал корректно завершения, но на самом деле предоставляет процессу возможность перехватить этот сигнал (подробнее в следующем посте) и сделать с ним всё что ему вздумается, по умолчанию он всё-равно убьет процесс, но всё-таки.
С сигналом безусловного завершения процесса SIGKILL (вызывается командой kill -9) всё проще, его невозможно перехватить, заблокировать или сообщить ему другой смысл; он просто завершает процесс.
Вводя команду ‘nginx -s reload’ вы посылаете процессу nginx SIGHUP (kill -1) вынуждая его перечитать собственную конфигурацию. А после закрытия управляющего терминала, такую команду получает связанный с терминалом процесс (и умирает).

6. Какие сигналы используются для таймеров?
Таймеры в Linux используют сигнал SIGALRM. Когда истекает время таймера, ядро посылает этот сигнал процессу. Этот сигнал часто используется для реализации ограничений по времени для различных операций, таких как ожидание ввода от пользователя или выполнения длительных задач.

7. Что происходит, если процесс не может обработать сигнал?
Если процесс не может обработать сигнал или не настроил его обработку, ядро выполнит действие по умолчанию для данного сигнала. Например, для SIGTERM или SIGHUP процесс завершится. Для SIGKILL и SIGSTOP нет возможности установить обработчик, и они всегда приводят к завершению или остановке процесса.

8. Целых 30?
Может быть даже больше, все посмотреть и почитать их сверхкраткие описания можно тут это для OS Debian и на русском.

Небольшое техническое сообщение

Статьи в канал пишут два человека. Подписывать посты, пользуясь стандартным инструментарием ТГ мы не хотим, поэтому принято стратегическое решение подписывать посты эмодзи.
👰‍♀️ - посты Кати
🧙‍♂️ или 👨‍💻 или👨‍💻или ⌨️ - посты Глеба
Предлагаю выбрать эмодзи для Глеба ниже. Он будет стараться помечать свои посты так, пока ему не нарисуют что-то более подходящее.

⌨️ Вопросы с реального собеседования #1

#реальные_вопросы #2024год

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

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

Крупные клиенты: Детский мир, М Видео, Билайн, HH, Рольф, Тануки, Fixprice, Магнит.

Размер компании: средний (300+ сотрудников)

Требуется: middle System Engineer (DevOps), удаленная работа 200 000 - 230 000 на руки

Задачи:
Администрирование серверов Linux (bare metal / виртуальные)
Проектирование, внедрение и развитие сервисов и IT-инфраструктуры компании
Эксплуатация и поддержка кластеров kubernetes

Требования:
Опыт администрирования Linux - от 3х лет
Инструменты оркестрации и контейнеризации (Kubernetes/Mesos) от 1 лет
Понимание стека TCP/IP, протоколов динамической маршрутизации (OSPF/BGP)
Опыт работы с системами настройки блочных устройств mdadm, DRBD
Системы управления конфигураций (Ansible, Pulumi)
Файловые системы: ZFS, ext4
Опыт с iptables, nftables, ipvs, DNS, DHCP
Языки программирования: Java/Python/Go

Полный список вопросов с собеседования: ссылка в telegra.ph

Подводя итоги: мне понравился список вопросов для этого собеседования. Он сбалансирован, требования к кандидату соответствуют содержанию вопросов, что позволяет хорошо подготовиться. В целом вопросы стандартные, не очень интересные, не слишком сложные. Есть упор на сопровождение серверов (из специфичных вопросов — только блок по ZFS). Вакансия, как и вопросы к ней, ближе к System Engineer, нежели к DevOps (и здесь описание не обманывает). Not good, not terrible. 6 из 10 (твёрдый средняк). Я ещё подумаю над шкалами оценки наборов вопросов.

👰‍♀️ Немного мотивации и добрых слов для джунов, которые ужасно устали от поиска работы 🥹

#мотивация

1. Лучше делать плохо, чем никак. Что угодно - откликаться на вакансии, проходить собеседования, решать тестовые.

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

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

Успехов тебе на этом нелегком пути! 💕

👰‍♀️А нужно ли сопроводительное?

#рекрутинг

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

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

- Куда меньший грех - копировать и вставлять одно и то безликое сопроводительное на все вакансии. Это тоже видно, но, если писать отдельный сопровод к каждому объявлению о поиске, можно поехать крышей, и мы, рекрутеры, тоже это понимаем 🙂

- Длинные сопроводительные вряд ли будут дочитаны до конца.

- На вакансии, предполагающие большое количество откликов (например, джуниор-позиции), часто стоит авторазбор. Старайся или не старайся в сопроводительном, в случае, если ты не соответствуешь выбранным критериям, оно улетит в никуда.

⌨️ Мета вопросов в технических собесах

#реальные_вопросы

Разберемся, что понимается под метой технического интервью. Как, возможно, читатели догадались “мета” - это греческая приставка или предлог. Её позаимствовали многие языки для обозначения чего-то, что абстрагирует и/или агрегирует знания о предмете, который следует за этой приставкой. Например, можно привести следующие слова: “метаданные” - данные о данных, “метаирония” - ирония над иронией. И самое близкое по значению к слову, которое я хочу ввести: “метагейминг” - то есть попытка игроков выйти за пределы геймплея, получить больше информации об игре и своих в ней соперниках, чтобы улучшить свой результат. Мета в конкретной игре означает данные о состоянии игры в целом и конкретных её элементов. Например, метовые колоды, в коллекционных карточных играх это самые сильные и часто встречающиеся наборы карт, мета в шутерах - выбираемое игроками оружие, в MOBA - герои, в батлроялях - точки высадки, и тому подобное.

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

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

Что такое load average? (с комплектом дополнительных вопросов, вроде что показывает эта метрика, почему там три значения, в чем измеряется показатель LA и тому подобное).

Его настолько затерли, что задавать его скоро станет плохим тоном.

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

Linux
- Порядок загрузки дистрибутива Linux (длинный вопрос, который уже всем надоел до зубного скрежета, вполне заслуженно)

- Что такое inode и какова его роль в файловой системе? (у вас когда-нибудь заканчивались inode на сервере? У меня тоже не заканчивались, но базовые концепции OC знать надо)

Сети
- Вы вводите в строке браузера <что-то>.com/ru (чаще всего это сайт компании, в которую вы устраиваетесь). Опишите процесс от нажатия клавиши до загрузки страницы (я знаком с людьми, которые принципиально отказываются отвечать на этот вопрос из-за его духоты и длины ответа на него).

- Объясните модель OSI и ее уровни (пресловутая семиуровневая модель, самое теоретическое, что вообще встречается среди вопросов, тем не менее, знать к какому уровню относятся коммутатор, а к какому маршрутизатор, строго обязательно).

K8s
- Опишите архитектуру кластера Kubernetes, из чего состоит? (надо перечислить основные компоненты control plane и worker nodes, рассказать про их взаимодействие и основные концепции, такие как Pod, Service, Namespace и т.д.).

- В чем разница между Deployment и StatefulSet? (вопрос на сравнение контроллеров Kubernetes)

- Какие существуют пробы в k8s (Readiness, Liveness, Startup), чем они отличаются?

Контейнеры
- Виртуализация vs контейнеризация (без комментариев)

- Каким образом в Docker реализована изоляция контейнеров друг от друга? (Namespaces, cgroups, сетевые интерфейсы, CoW, UnionFS, OverlayFS и так далее)

- Какие команды порождают слои? (те, которые изменяют файловую систему)

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

👰‍♀️Когда сопроводительное действительно нужно?

#рекрутинг

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

1. Первое и самое главное: когда в тексте вакансии прямым текстом указывается его необходимость и предполагаемое содержание.
2. Когда у вас скрыты контакты и в сопроводительном вы указываете их.
3. Если вакансия действительно (а не как те сто остальных, на которые вы отправили отклики) сильно запала вам в душу и вы хотите сообщить об этом.
4. Если по названиям компаний и описанию опыта не до конца понятно, чем вы занимались, в то время как в реальности эта сфера очень близка к описываемому проекту. Например, вы работали в компании-интеграторе на банковском проекте, а теперь откликаетесь на вакансию в самый настоящий банк.
5. Если вы точно знаете, что компания обращает внимание на них.

А помогали ли сопроводительные вам, и если да, то в какие компании? Давайте делиться опытом в комментариях ⬇️!

⌨️ Меняешь права - умножаешь на 2

#реальные_вопросы #docker

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

Задача:
На изображении мы видим Dockerfile, в котором за основу берется базовый образ alpine, в контейнер копируется файл размеров 1Gb, следующая инструкция меняет права файла. Вопрос: какого размера получится докер образ?

Ответ:
Образ будет весить ~2.01GB.

Подробный разбор:
Каждая инструкция в файле порождает новый слой, размер образа растет путем простого сложения их размеров.
Слой 1. FROM
Базовый образ Alpine (версия latest) занимает около 8 MB. Минималистичный дистрибутив, он очень популярен, благодаря своему небольшому размеру.
Слой 2. COPY
Файл testfile.img размером 1 GB копируется в контейнер. Docker добавляет новый слой (layer) для этой инструкции, и размер слоя равен размеру файла (в нашем случае случае 1 GB).
Слой 3. RUN
Вносит изменения в файл testfile.img. Docker создает новый слой для этой операции. Даже если изменяются только метаданные (например, права доступа), весь файл копируется в новый слой. Это связано с механизмом Copy-on-Write (COW), который требует копировать весь файл при любых модификациях.
Новый слой добавляет еще 1 GB из-за копирования нашего файла на новый слой.
Итого:
Размер Alpine: ~8 MB.
Слой с копированием файла: ~1 GB.
Слой с изменением прав: ~1 GB.
2.01 GB.

Как исправить?
Копировать файл сразу с нужными правами (заменить последние две инструкции на эту):

COPY --chmod=600 testfile.img /testfile.img

Немного о механизме Copy-on-Write (COW)
Я рассмотрю COW подробнее в другом посте, а пока расскажу о простом правиле. Слои в OverlayFS являются неизменяемыми, стратегия Copy-on-write, обеспечивает совместное использование и копирование файлов, если файл или каталог существует в нижнем слое образа, а другому слою требуется доступ к нему на чтение, он просто использует существующий файл. А когда другому слою потребуется изменить файл, файл копируется в этот слой и изменяется.

👰‍♀️Как впечатлить рекрутера своим английским?

#рекрутинг

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

1. Заранее напишите рассказ о себе и своем опыте на английском.
2. Посмотрите наиболее частые вопросы эйчар-интервью и напишите ответы на них тоже.
3. Добавьте в рассказ сложную лексику и грамматические конструкции, которые указывали бы на высокий уровень владения языком (conditionals, пассивный залог). Можете попросить сделать это кого-нибудь из знакомых или ChatGPT.
4. Учим все написанное - по возможности. Не подглядывая, рассказываем кому-нибудь из близких.
5. Готово, вы восхитительны 🎉

⌨️ SQL-инъекции: технология древних хакеров, которая до сих пор работает

#интересное

Легкий пятничный пост. Предвкушаем завершение рабочей недели

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

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

hi'); DROP DATABASE customers; --

hi'); Закрывает открытую ранее кавычку и скобку в исходном SQL-запросе. Это позволяет выйти из контекста ожидаемого строкового значения и создать новый запрос

DROP DATABASE customers; Это команда, которая при выполнении удалит базу данных customers. В идеале знать наименование bd, да и тип db тоже имеет значения.

-- Обозначает начало комментария в SQL. Все, что следует после этого, игнорируется СУБД. Это предотвращает возможные ошибки синтаксиса из-за оставшихся частей исходного запроса.

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

Застраховаться от такой атаки можно, используя параметризированные запросы (автоматическое экранирование вводимых данных), ограничение привилегий, валидацию и очистку вводимых данных, ну и просто вовремя обновляя свою СУБД.

Хотите разобраться в этой теме глубже, без вреда для себя и окружающих? У меня есть решение. Готовя этот пост, я создал небольшое тестовое приложение для демонстрации SQL-инъекций. Поля для ввода данных, вы можете увидеть на картинке в шапке поста, они за токсичной белкой. В сборку входит: Dockerfile, docker-compose, код приложения на python + конфигурация nginx. Сделка проста, тридцать 👍 и я приступлю к созданию репозитория с подобными интересностями, одним из первых выложу это тестовое web - приложение для SQL-инъекций. Прикручу подробную инструкцию и сборку одной-двумя командами. Ну и вообще, репозиторий канала, вещь, как мне кажется, просто необходимая. Не в постах же код публиковать.

Всем доброй пятницы, друзья, и приятных выходных.

⌨️ Не быть джуном

#карьера

Когда меня спрашивают, как устроиться junior DevOps, я часто пожимаю плечами и говорю о том, что вообще сомневаюсь в существовании таких вакансий. Чести стать junior DevOps удостаиваются, в массе своей, одна категория людей — выпускники профильных вузовских специальностей. Джунами они, правда, становятся не сразу, а после практики. О попадании на практику я напишу как-нибудь потом — это отдельная боль и "голодные игры".

Хорошо, путь в junior DevOps для нас закрыт, допустим. Но что ты предлагаешь?

Есть несколько вариантов ответа на этот вопрос. Разберем ситуацию, когда у вас вообще нет опыта работы в IT. Стоит ли откликаться на вакансии junior DevOps? Я думаю, нет. Подобные вакансии привлекают слишком много внимания и там слишком высокие требования. А еще там присутствует тестовое задание, что, казалось бы, могло быть плюсом вакансии, но о тестовых заданиях мы тоже ещё поговорим. А уж если там отсутствует требование к опыту работы (которого у вас, напомню, тоже нет), откликаться на неё точно не стоит. Немного контринтуитивные выводы, правда? Сейчас всё объясню.

Почему это не лучший путь?
Слишком много чужих откликов, слишком мало шансов.
Примите во внимание тот факт, что, скорее всего, вы не машина, а человек. В ситуациях, когда 95% ваших откликов будут полностью игнорироваться, тестовые задания будут отнимать кучу сил и времени, а после тех редких технических собеседований, на которые вы попадёте, вам будут приходить отказы — выгореть очень легко. Не каждый человек имеет достаточно воли ломиться в закрытую дверь на протяжении длительного времени.
Давайте постепенно идти к цели. Я сейчас опишу шаги в общих чертах, а подробно — в отдельных постах.

Начало начал
Ваша задача на первом этапе — не стать DevOps, а просто получить работу в IT или около IT. Благо на нашем направлении, а мы, вне зависимости от названия записи в трудовой книжке, все специалисты по эксплуатации (немного кондовое обозначение, но зато зонтичное), достаточно специальностей, пригодных для старта IT-карьеры. Обратите внимание на такие вакансии, как: специалист третьей линии поддержки, эникей, дежурный инженер мониторинга, и так далее.
Устроившись на эту вакансию, ваша задача — проработать там от одного года, попутно готовясь ко второму этапу.

Еще не девопс, но уже не джун
А вот теперь вторая часть нашего плана. Теперь нам нужна мидловая вакансия. Опять же, подойдет почти любая с приставкой "мидл", вне зависимости от того, указана она явно или предполагается опытом работы (который у вас уже есть): системный администратор, администратор серверов, сетевой инженер, DBA.
Устроились? Вы великолепны. У вас есть годик или чуть больше, чтобы подготовиться к последнему рывку.

Устраиваемся middle DevOps/SRE
Вот теперь вы готовы и близки к цели — получить высокооплачиваемую работу с большими перспективами.

Стоп, но ведь я не работал DevOps?

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

Если остались сомнения, что-то не поняли или что-то кажется нереалистичным, пишите в комментарии или записывайтесь на консультацию через GetMentor. Поговорим и разберем конкретно ваш кейс.

⌨️ Контейнеры и Zero Trust. Познаём безопасность, прокачиваем резюме

#docker #ImproveCV #ShowYourSkills

Фундаментальная идея модели безопасности Zero Trust заключается в том, что к внешним и внутренним объектам следует относиться одинаково. Это означает выход за рамки традиционного подхода к безопасности, основанного на «периметре», когда пользователям или серверам во внутреннем периметре компании можно автоматически доверять. В модели Zero Trust привилегии предоставляются исключительно на основе идентификации и роли, мы никому и ничему не доверяем по умолчанию.

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

Контейнеры, такие как Docker, предоставляют изолированные среды для приложений, однако их изоляция не абсолютна, что делает их уязвимыми для атак. Применение модели Zero Trust обеспечивает строгий контроль для каждого взаимодействия как внутри контейнерной инфраструктуры, так и для каждого контейнера отдельно. Это минимизирует риски несанкционированного доступа и последовательного взлома систем по схеме «одну за одной», «одну через другую» в одной сети (lateral movement).

Давайте рассмотрим некоторые базовые механизмы и принципы:

Принцип наименьших привилегий — это фундаментальный подход к безопасности, утверждающий, что пользователь, программа или процесс должны иметь только минимальные разрешения, необходимые для выполнения своей предполагаемой функции, и не более. Что касается работы с контейнерами, эффективная реализация этого принципа требует использования AppArmor/SELinux и профилей seccomp. Это позволит обеспечить невозможность запуска контейнеров с root-правами, недопустимость запроса и получения контейнерами повышенных привилегий.

Дополнительно управление привилегиями в Linux осуществляется через механизм capabilities. По умолчанию Docker предоставляет контейнерам ограниченный набор таких привилегий, однако для повышения безопасности рекомендуется явно запрещать все привилегии и затем разрешать только необходимые. Это достигается с помощью опций --cap-drop и --cap-add при запуске контейнера. Например, команда:

docker run --cap-drop ALL --cap-add CHOWN <image_name>

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

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

А теперь самый главный вопрос: зачем тебе это знать, разбираться и практиковаться?

Всё просто — чтобы добавить в своё резюме и уметь защитить следующую строчку, например:

Настройка контейнеров Docker в соответствии с принципом минимальных привилегий через управление Capabilities, профили AppArmor/политики SELinux, с автоматизацией сборки и развертывания посредством CI/CD (GitLab), а также анализом уязвимостей контейнерных образов с помощью Clair/Trivy.

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

⌨️ docker.sock

#docker

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

dockerd
docker API
docker CLI

Давайте разберемся в каждом из этих пунктов. C dockerd всё более менее понятно, это фоновый процесс (демон), управляющий всеми аспектами работы docker на хосте. Обрабатывает запросы на создания контейнеров, создает контейнеры, уничтожает контейнеры. Командный центр, взаимодействующий непосредственно с ОС хоста в части изоляции, также управляет сетями и хранилищами.

Docker CLI (Command Line Interface) тоже затруднений вызывать не должен, самый базовый способ взаимодействия с docker. Если вы знакомы с командами docker run / ps / images / build / stop / rm / rmi, значит с CLI вы уже работали.

Эти две сущности должно что-то связывать и эту работу берет на себя REST API через UNIX сокеты или сетевой интерфейс. По умолчанию сокет докера располагается в /var/run/docker.sock и готов принять запросы не только от Docker CLI, но и любого другого клиентского приложения.

Возможность обращаться к сокету напрямую, очень удобна, но является благодатной почвой для разного рода уязвимостей. Владельцем данного ресурса должен быть пользователь root. Предоставлять доступ к docker.sock другому пользователю означает, означает выдать ему root-привилегий хоста, поскольку сам демон dockerd запускается с такими правами. Кроме того, не следует монтировать этот сокет внутрь контейнера (например, через volume), по сути подобное действие означает передачу контроля над хост системой контейнеру.