Как должен выглядеть идеальный pipeline CI/CD, что в нём должно быть что за чем идти ?
Спросят с вероятностью 46%

Идеальный CI/CD (Continuous Integration/Continuous Deployment) пайплайн организует процесс разработки таким образом, чтобы максимизировать автоматизацию и минимизировать ручные задачи, увеличивая скорость разработки и обеспечивая высокое качество конечного продукта. Хорошо организованный пайплайн обеспечивает бесперебойное и быстрое внесение изменений в код, их тестирование, сборку и развертывание в производственную среду.

Этапы:

1️⃣Инициация изменений (Version Control System Integration)
✅Разработчики клонируют репозиторий и вносят изменения.
✅Изменения отправляются в репозиторий (например, через git push).

2️⃣Непрерывная интеграция (Continuous Integration)
✅Автоматический запуск пайплайна: Каждый push или pull request в репозиторий автоматически инициирует CI пайплайн.
✅Сборка проекта: Компиляция кода, если это необходимо для данного языка программирования.
✅Запуск модульных тестов (Unit Tests): Тестирование компонентов программы для проверки их корректности.
✅Статический анализ кода: Проверка кода на соответствие стандартам кодирования и поиск потенциальных ошибок.

3️⃣Артефакты
✅Сборка артефактов: Создание готовых для развертывания пакетов (например, Docker-образов).

4️⃣Непрерывное тестирование (Continuous Testing)
✅Интеграционное тестирование: Проверка, как различные части проекта работают вместе.
✅Тестирование безопасности (Security Testing): Проверка на уязвимости.
✅Тестирование производительности (Performance Testing): Проверка скорости и стабильности системы под нагрузкой.

5️⃣Непрерывная доставка (Continuous Delivery)
✅Автоматическое развертывание в тестовую среду: Автоматическое развертывание артефактов в тестовую среду для дополнительного тестирования.
✅Ручное одобрение: Опционально, требование ручного одобрения перед продвижением артефактов в продакшн.

6️⃣Непрерывное развертывание (Continuous Deployment)
✅Автоматическое развертывание в продакшн: После успешного прохождения всех тестов и одобрения код автоматически развертывается в продакшн.

7️⃣Мониторинг и обратная связь
✅Мониторинг: Непрерывный мониторинг производительности и стабильности приложения в производственной среде.
✅Логирование: Сбор и анализ логов для выявления потенциальных проблем.
✅Обратная связь: Системы уведомлений для информирования команды о состоянии пайплайна и производственной среды.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

В чем разница между подом и контейнером ?
Спросят с вероятностью 40%

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

Контейнер

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

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

Под

Это наименьшая и простейшая единица, которую можно создать или управлять. Он представляет собой группу одного или нескольких контейнеров с общими ресурсами, которые запускаются на одном узле (физическом или виртуальном сервере). Каждый под имеет свои IP-адреса, объемы данных (если таковые есть), и контейнеры в поде могут обмениваться состоянием и общаться друг с другом через localhost.

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

Основные различия

✅Сфера применения: Контейнер — это механизм, который напрямую связан с запуском отдельного приложения или процесса. Под же представляет собой уровень абстракции в Kubernetes, который включает один или несколько контейнеров, которые должны работать вместе.
✅Управление: Контейнеры управляются внутри подов. Kubernetes не управляет контейнерами напрямую; вместо этого он управляет подами, которые в свою очередь содержат контейнеры.
✅Совместное использование ресурсов: Все контейнеры внутри пода могут совместно использовать ресурсы, такие как сетевые подключения и дисковое пространство, что облегчает взаимодействие компонентов приложения.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Для чего нужны сайдкары ?
Спросят с вероятностью 13%

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

Назначение:

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

1️⃣Изоляция ответственности: Берут на себя специфические функции, такие как логирование, мониторинг, конфигурация, обновление безопасности и связь с другими сервисами. Это освобождает основное приложение от необходимости управления этими аспектами.

2️⃣Упрощение разработки основного приложения: Разработчики могут сосредоточиться на бизнес-логике основного приложения, не отвлекаясь на периферийные задачи.

3️⃣Повышение безопасности: Могут управлять безопасностью, например, управлять аутентификацией и шифрованием сетевого трафика, не внося изменений в бизнес-логику основного приложения.

4️⃣Гибкость обновлений: Могут быть обновлены независимо от основного приложения, что упрощает управление версиями и уменьшает риски для стабильности основного сервиса.

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

Примеры:

1️⃣Сайдкар для логирования: Сбор и агрегация логов от основного приложения без вмешательства в его работу.

2️⃣Сайдкар для мониторинга: Отслеживание производительности приложения и сбор метрик, отправка данных в системы мониторинга.

3️⃣Сайдкар-прокси: Управление сетевым трафиком, например, Envoy или istio-proxy в Istio, обеспечивающие маршрутизацию запросов, балансировку нагрузки, шифрование и другие сетевые функции.

4️⃣Сайдкар для конфигурации: Динамическое управление конфигурацией основного приложения, обновление конфигурационных файлов без перезапуска контейнера приложения.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое CI/CD ?
Спросят с вероятностью 40%

CI/CD — это сокращение от "Continuous Integration" (Непрерывная интеграция) и "Continuous Delivery" или "Continuous Deployment" (Непрерывная доставка или непрерывное развертывание), которые представляют собой ключевые концепции в современных методиках разработки ПО. Они помогают автоматизировать процессы разработки, тестирования и развертывания приложений, улучшая скорость, качество и эффективность процессов.

Непрерывная интеграция (Continuous Integration, CI)

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

Непрерывная доставка (Continuous Delivery, CD)

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

Непрерывное развертывание (Continuous Deployment)

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

Преимущества:

1️⃣Быстрое обнаружение и устранение ошибок: Благодаря частой интеграции и тестированию, ошибки обнаруживаются и исправляются на ранних этапах, что снижает стоимость их устранения.
2️⃣Улучшенное качество продукта: Постоянные тестирование и обратная связь способствуют повышению качества продукта.
3️⃣Сокращение времени на выход продукта на рынок: Автоматизация позволяет быстрее доставлять продукт пользователям.
4️⃣Улучшение процессов разработки: Разработчики могут сосредоточиться на улучшении продукта, а не на рутинных задачах.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

В чём разница между контейнеризацией и виртуализацией ?
Спросят с вероятностью 33%

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

Виртуализация

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

Примеры гипервизоров:
✅VMware ESXi
✅Microsoft Hyper-V
✅Oracle VirtualBox

Контейнеризация

В отличие от виртуализации, позволяет запускать несколько приложений и их зависимостей в изолированных процессах, называемых контейнерами, на одной операционной системе. Контейнеры разделяют ядро операционной системы хоста, но могут быть ограничены в использовании CPU, памяти и I/O. Контейнеры быстрее и легче, чем виртуальные машины, поскольку они не требуют отдельной операционной системы для каждого из них.

Примеры технологий:
✅Docker
✅Kubernetes (используется для оркестрации контейнеров)
✅LXC

Основные различия

1️⃣Уровень изоляции: Виртуализация предоставляет более полную изоляцию, так как каждая виртуальная машина имеет свою собственную операционную систему, в то время как контейнеры разделяют операционную систему хоста.
2️⃣Ресурсы: Виртуальные машины требуют больше ресурсов, так как каждая ВМ нуждается в собственных копиях операционной системы и её ресурсах, в то время как контейнеры более легковесные и быстрее загружаются.
3️⃣Портативность: Контейнеры обеспечивают большую портативность и легкость развертывания, так как они могут легко перемещаться между различными средами, поддерживающими контейнеризацию.
4️⃣Производительность: Контейнеры могут предложить более высокую производительность, поскольку они не страдают от накладных расходов, связанных с дополнительными уровнями абстракции и эмуляции аппаратного обеспечения.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое Prometheus ?
Спросят с вероятностью 33%

Prometheus — это открытая система мониторинга и оповещения, которая широко используется для сбора метрик с различных целевых объектов, таких как серверы, виртуализированные контейнеры и приложения, в режиме реального времени. Она была создана в компании SoundCloud в 2012 году и с тех пор стала частью Cloud Native Computing Foundation, что подчеркивает её популярность и признание в индустрии.

Основные характеристики:

1️⃣Модель данных:
✅Prometheus хранит данные в форме временных рядов.
✅Каждый временной ряд идентифицируется уникальным именем или идентификатором и может иметь набор ключ-значение, который называется метками (labels).

✅Язык запросов:
✅Prometheus имеет собственный язык запросов, PromQL (Prometheus Query Language), который позволяет пользователям выбирать и агрегировать данные по времени.

3️⃣Непрерывная сборка данных:
✅Prometheus регулярно собирает метрики с целевых объектов, используя pull-модель, то есть сам запрашивает данные у целевых объектов по HTTP.

4️⃣Цели мониторинга:
✅Цели (targets) конфигурируются для мониторинга через статическую конфигурацию или с помощью сервис-дисковери.

5️⃣Алерты:
✅Prometheus поддерживает возможности оповещения. Он может высылать уведомления о проблемах, которые необходимо устранить, по различным каналам связи, например, через Email, Slack и другие сервисы.

6️⃣Хранение:
✅По умолчанию Prometheus хранит данные локально на диске в высокоэффективном формате временных рядов. Также поддерживается интеграция с внешними системами хранения.

7️⃣Высокая доступность:
✅Для обеспечения высокой доступности можно запустить несколько экземпляров Prometheus, которые будут собирать данные параллельно.

Пример:

Prometheus может использоваться для мониторинга производительности приложений, анализа системных метрик, таких как использование ЦП и памяти, а также для мониторинга инфраструктуры в целом. Например, в кластере Kubernetes Prometheus может собирать метрики со всех узлов, подов и контейнеров, предоставляя централизованный взгляд на здоровье всей системы.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Ребят, напоминаю, что все вопросы, которые здесь публикуются можно посмотреть списком вместе с видео-ответами на моем сайте easyoffer.ru

Как происходит процесс загрузки Linux ?
Спросят с вероятностью 13%

Процесс загрузки Linux является многоэтапным и начинается с включения компьютера и завершается загрузкой операционной системы и запуском начального процесса. Вот основные этапы загрузки:

1️⃣BIOS или UEFI
Загрузка начинается с BIOS (Basic Input/Output System) или UEFI (Unified Extensible Firmware Interface), которые являются фирменными программами на материнской плате. BIOS/UEFI инициализирует аппаратные компоненты и проверяет их на наличие ошибок (POST - Power-On Self Test). После успешного прохождения POST, BIOS/UEFI ищет загрузочное устройство среди дисков, USB-накопителей, сетевых интерфейсов и других доступных устройств в порядке, указанном в настройках BIOS/UEFI.

2️⃣Загрузчик (Bootloader)
После того как BIOS/UEFI определяет загрузочное устройство, управление передаётся загрузчику. В случае с Linux наиболее распространёнными загрузчиками являются GRUB (GRand Unified Bootloader) или Syslinux. Загрузчик отображает меню выбора ядра (если настроено), где пользователь может выбрать версию ядра или операционной системы для загрузки. Загрузчик загружает в память ядро Linux и initramfs (инициализационную RAM файловую систему).

3️⃣Ядро Linux
Загруженное ядро начинает выполнение, инициализирует аппаратные устройства и драйверы, необходимые для дальнейшей загрузки системы. Ядро затем распаковывает initramfs в виртуальную файловую систему в памяти. Initramfs содержит временную корневую файловую систему и необходимые исполняемые файлы и библиотеки, которые нужны для монтирования настоящей корневой файловой системы.

4️⃣Initramfs и udev
Во время загрузки initramfs запускает udev (демон, управляющий устройствами), который динамически создает устройства в каталоге /dev, обеспечивая их доступность для ядра и процессов. Затем initramfs монтирует настоящую корневую файловую систему.

5️⃣Переключение корневой файловой системы
После монтирования настоящей корневой файловой системы initramfs переключает корневую файловую систему с временной на постоянную. Этот процесс называется переключением корня (switch_root).

6️⃣Init-процесс
После переключения на постоянную корневую файловую систему управление передаётся init-процессу (например, systemd или SysVinit), который является первым процессом, запускаемым в системе (с PID 1). Init-процесс отвечает за запуск всех остальных процессов и сервисов, необходимых для полноценной работы системы.

7️⃣Запуск сервисов
Init-процесс запускает различные скрипты и сервисы на основе уровня запуска или целей (в случае systemd), которые настраивают все аспекты работающей системы: сетевые настройки, графические интерфейсы, серверные службы и т.д.

Эти этапы описывают стандартный процесс загрузки большинства современных дистрибутивов Linux.

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое слои ?
Спросят с вероятностью 13%

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

1️⃣Сетевые слои (OSI модель)
Термин "слои" часто относится к уровням OSI (Open Systems Interconnection) модели, которая разделяет сетевую архитектуру на семь уровней, каждый из которых выполняет определенные функции. Эти слои включают:

✅Физический слой: Обеспечивает передачу и прием неструктурированных данных через физическое средство.
✅Канальный слой: Обеспечивает надежную передачу данных между двумя прямо подключенными устройствами.
✅Сетевой слой: Управляет адресацией, маршрутизацией и трафиком между сложными сетями.
✅Транспортный слой: Обеспечивает надежную передачу данных между точками в сети.
✅Сеансовый слой: Управляет сессиями связи между приложениями.
✅Представительный слой: Переводит данные из одного формата в другой.
✅Прикладной слой: Обеспечивает сетевые сервисы для приложений.

2️⃣Слои в архитектуре
В программной инженерии архитектура приложения может быть разделена на слои, каждый из которых имеет определенные обязанности. Например, типичное многослойное приложение включает:

✅Представление (Presentation Layer): Часть, которая взаимодействует с пользователем; например, пользовательский интерфейс.
✅Бизнес логика (Business Logic Layer): Обрабатывает данные приложения, выполнение задач и бизнес правил.
✅Доступ к данным (Data Access Layer): Уровень, который управляет хранением и извлечением данных из баз данных или других источников.

3️⃣Слои в контейнеризации (Docker)
В технологии контейнеризации, например, в Docker, образы контейнеров состоят из слоев. Каждый слой представляет собой набор изменений от предыдущего слоя, и вместе они формируют полный образ. Это позволяет эффективно использовать дисковое пространство и время при передаче образов.

4️⃣Слои в графическом дизайне
В программном обеспечении для графического дизайна, например, Photoshop или GIMP, слои используются для разделения различных элементов изображения, что позволяет независимо редактировать каждый элемент без влияния на другие.

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

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое inode ?
Спросят с вероятностью 33%

Inode (индексный дескриптор) — это структура данных в файловой системе UNIX и UNIX-подобных операционных систем, которая хранит важную информацию о файлах, кроме их имени и фактического содержимого. Каждый файл или каталог в таких системах имеет соответствующий inode, который описывает его атрибуты и расположение данных на диске.

Каковы атрибуты файла, хранящиеся в нем?

Он содержит различные метаданные файла, включая:
✅Тип файла: Например, обычный файл, каталог, символическая ссылка и др.
✅Права доступа: Это включает разрешения на чтение, запись и выполнение для владельца файла, группы и других пользователей.
✅UID (User ID) и GID (Group ID): Идентификаторы владельца файла и группы, к которой он принадлежит.
✅Размер файла: Общий размер файла в байтах.
✅Временные метки: Время последнего доступа к файлу, время последней модификации файла и время последней модификации inode.
✅Ссылки: Количество жестких ссылок, указывающих на inode.
✅Указатели на блоки данных: Адреса блоков данных на диске, где фактически хранится содержимое файла.

Как он работает?

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

Практическое значение

✅Управление файлами: Информация, хранящаяся в inode, позволяет операционной системе эффективно управлять файлами и каталогами.
✅Ограничения файловой системы: Количество inode на файловой системе обычно фиксировано при её создании, что означает, что максимальное количество файлов ограничено числом inode, даже если место на диске еще доступно.
✅Диагностика и анализ: Администраторы системы могут использовать команды, такие как ls -i для просмотра номеров inode файлов или df -i для проверки использования inode на диске, что помогает в диагностике проблем с файловой системой.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

👾 Ребят, напоминаю, у нас есть приватные группы где мы делимся реальными собеседованиями и тестовыми заданиями. Чтобы попасть в эти в группы воспользуйтесь ботами:
🤖 Доступ к базе собесов
🤖 Доступ к базе тестовых заданий

Что такое зомби процессы ?
Спросят с вероятностью 33%

Зомби процессы в операционных системах, представляют собой процессы, которые были завершены, но все еще остаются в системном списке процессов. Это происходит из-за особенностей управления процессами в этих системах.

Причины возникновения:

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

Характеристики:

✅Ресурсное потребление: Зомби процессы не потребляют системных ресурсов, таких как ЦП или память, но они продолжают занимать место в таблице процессов. Если зомби процессы накапливаются, они могут исчерпать лимит доступных слотов для процессов в системе.
✅Отображение в системе: В командной строке UNIX или Linux зомби процессы часто обозначаются буквой Z в списке процессов, который можно просмотреть с помощью команды ps.

Устранение

Обычно они исчезают из системы, когда родительский процесс вызывает wait() для сбора статуса завершения дочернего процесса. Если родительский процесс не делает этого, зомби процесс будет существовать до тех пор, пока родительский процесс не завершится. После завершения родительского процесса ответственность за обработку статуса дочерних процессов переходит к процессу init, который автоматически очищает зомби.

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

Зомби процессы — это неактивные процессы, которые не используют активные системные ресурсы, но сохраняются в таблице процессов до тех пор, пока их статус не будет собран родительским процессом. Они могут стать проблемой, если накапливаются и засоряют систему, но их легко устранить с правильным управлением процессами.

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что показывает load average ?
Спросят с вероятностью 33%

Load average (средняя нагрузка) — это показатель, который используется для оценки загруженности системы за определённые промежутки времени. Этот показатель обычно отображается с помощью команды uptime или top и представлен тремя числами, которые отражают среднюю нагрузку системы за последние 1, 5 и 15 минут.

Что означают эти значения?

Каждое из трёх чисел показывает среднее количество процессов, находящихся в состоянии ожидания выполнения или активно выполняющихся за последнюю минуту, последние 5 минут и последние 15 минут соответственно. Эти значения позволяют оценить текущую и историческую загруженность системы.

Как интерпретировать эти значения?

✅Значение равное количеству ядер CPU: Если значение load average равно количеству логических ядер CPU, это означает, что система загружена на 100%. Например, для системы с четырьмя ядрами значение 4.00 означает полную загрузку.
✅Значение меньше количества ядер CPU: Значения ниже количества ядер указывают на то, что у системы есть свободные ресурсы, и она не перегружена.
✅Значение выше количества ядер CPU: Если значение превышает количество логических ядер CPU, это означает, что процессы конкурируют за ресурсы CPU, что может приводить к задержкам в выполнении. Например, значение 6.00 на системе с 4 ядрами означает, что некоторые процессы ждут доступа к процессору.

Как используются эти данные?

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

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что будет происходить при kubectl apply ?
Спросят с вероятностью 13%

Команда kubectl apply — это инструмент для управления приложениями через командную строку для Kubernetes, который позволяет создавать и обновлять ресурсы в кластере на основе определений в YAML или JSON файлах. Это одна из наиболее часто используемых команд для работы, так как она поддерживает идемпотентность, что означает, что один и тот же файл конфигурации может быть применен несколько раз без изменения результата за пределами ожидаемого.

Как он работает:

1️⃣Чтение конфигурационного файла: Читает конфигурационный файл в форматах YAML или JSON, который описывает желаемое состояние ресурса или ресурсов, которые должны быть развернуты или обновлены в кластере.

2️⃣Сравнение с текущим состоянием: Сравнивает желаемое состояние, определенное в конфигурационном файле, с текущим состоянием ресурса в кластере. Это сравнение включает проверку всех атрибутов ресурса, чтобы определить, требуется ли создание нового ресурса, обновление существующего или не требуется никаких изменений.

3️⃣Обновление ресурса: Если конфигурация ресурса в файле отличается от того, что уже присутствует в кластере, kubectl apply обновляет ресурс в соответствии с этой конфигурацией. Это может включать изменение свойств, добавление или удаление компонентов и так далее.

4️⃣Аннотации и управление изменениями: Когда вы используете kubectl apply, Kubernetes автоматически добавляет специальные аннотации к ресурсу. Эти аннотации содержат предыдущую конфигурацию ресурса в сериализованном виде, что позволяет Kubernetes определять изменения между запусками команды.

5️⃣Отслеживание изменений: Если ресурс был изменен другими способами (не через kubectl apply), Kubernetes сможет определить эти изменения и интегрировать их, если они не конфликтуют с конфигурацией, применяемой через kubectl apply.

kubectl apply -f deployment.yaml

Это приведет к созданию или обновлению Deployment в соответствии с определениями в файле deployment.yaml.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое kafka ?
Спросят с вероятностью 33%

Apache Kafka — это распределённая платформа для потоковой обработки данных, ориентированная на высокую пропускную способность и надёжное хранение событий. Kafka разработана LinkedIn и впоследствии передана в Apache Software Foundation, где она стала одним из самых популярных проектов для обработки больших объёмов данных в реальном времени.

Основные компоненты:

1️⃣Продюсеры (Producers): Отправляют данные в Kafka. Продюсеры публикуют данные в топики (topics), которые можно сравнить с папками или категориями, где данные упорядочены и хранятся.

2️⃣Топики (Topics): Категории или каналы, в которые продюсеры публикуют свои данные. Топики в Kafka могут быть разделены на несколько сегментов, называемых партициями, что позволяет распределить данные между несколькими узлами для повышения производительности и надёжности.

3️⃣Партиции (Partitions): Сегменты внутри топика, которые позволяют данные топика быть распределёнными и параллельно обработанными. Каждая партиция может иметь одну или несколько реплик, что повышает доступность и устойчивость данных.

4️⃣Консьюмеры (Consumers): Подписываются на топики и читают данные, публикуемые продюсерами. Консьюмеры могут работать в группах для распределённой и параллельной обработки данных.

5️⃣Брокеры (Brokers): Серверы, которые хранят данные и обрабатывают запросы от продюсеров и консьюмеров. В распределённой среде Kafka может состоять из множества брокеров, управление которыми осуществляется через узел управления, называемый контроллером.

Особенности и преимущества:

✅Производительность: Способна обрабатывать сотни тысяч сообщений в секунду.
✅Масштабируемость: Систему можно масштабировать горизонтально, добавляя брокеров в кластер, что позволяет обрабатывать больше сообщений без простоя.
✅Надёжность: Данные автоматически реплицируются между брокерами, что обеспечивает высокий уровень доступности и устойчивость к сбоям.
✅Устойчивость к сбоям: Спроектирована так, чтобы выдерживать сбои отдельных компонентов без потери данных.
✅Временное хранение: Может хранить большие объёмы данных на определённый период времени, позволяя консьюмерам читать и перечитывать информацию по мере необходимости.

Использование

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

Apache Kafka — это мощная и гибкая система для работы с потоками данных в реальном времени, которая поддерживает высокие нагрузки, обеспечивает надёжность и позволяет масштабировать обработку данных на уровне крупных предприятий. Она обеспечивает комплексное решение для сбора и передачи больших объёмов данных с минимальной задержкой.

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Чем отличаются deployment, replicaset ?
Спросят с вероятностью 13%

Deployment и ReplicaSet являются ключевыми компонентами, используемыми для управления развертыванием и масштабированием контейнеризированных приложений. Хотя оба они связаны с управлением подами, между ними есть существенные различия в функциональности и предназначении.

ReplicaSet

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

Основные особенности:
✅Поддерживает стабильное количество подов, основываясь на шаблонах, определенных в спецификации.
✅Автоматически заменяет поды, которые были повреждены или удалены.
✅Не управляет обновлениями приложений в подах; требуется внешнее управление для обновления или изменения версий приложений.

Deployment

Это более высокоуровневый контроллер, который управляет развертываниями приложений в Kubernetes, включая их обновления и откаты. Deployment использует ReplicaSet для поддержания экземпляров, но добавляет множество дополнительных возможностей.

Основные особенности:
✅Управляет жизненным циклом приложений, включая развертывание, обновление, масштабирование и откаты.
✅Позволяет объявлять желаемое состояние приложения, и Kubernetes стремится поддерживать это состояние.
✅Поддерживает стратегии развертывания, такие как Rolling Update (постепенное обновление), что позволяет обновлять приложение с минимальными прерываниями.
✅Автоматически управляет ReplicaSets, создавая новые и удаляя старые при обновлении версии приложения.

Основные различия:

✅Уровень абстракции: Это более низкоуровневый компонент, фокусирующийся на поддержании количества подов. Deployment работает на более высоком уровне, управляя не только подами, но и их жизненным циклом, включая стратегии обновления и отката.
✅Обновление приложений: Не умеет управлять процессом обновления приложений; его задача — только поддержание числа работающих подов. Deployment предоставляет механизмы для безопасного обновления приложений, с минимальными прерываниями доступности сервиса.
✅Использование: В обычных операциях администрирования и управления приложениями в Kubernetes предпочтительнее использовать Deployment, так как он автоматически создает нужные ReplicaSets и обеспечивает больше возможностей для управления состоянием приложений.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Что такое kubernetes ?
Спросят с вероятностью 33%

Kubernetes (часто сокращенно K8s) — это открытая платформа для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Разработанная изначально в Google на основе их опыта работы с контейнерами в продакшене, он стал стандартом для оркестрации контейнеров в индустрии.

Основные концепции

1️⃣Поды (Pods): Базовая единица, которую создает и управляет Kubernetes. Под может содержать один или несколько контейнеров, которые разделяют сетевые настройки и хранилище.

2️⃣Узлы (Nodes): Физические или виртуальные машины, на которых запускаются поды. Каждый узел управляется мастер-узлом и содержит необходимые службы для запуска подов.

3️⃣Контроллеры (Controllers): Элементы для управления состоянием кластера. Они следят за тем, чтобы фактическое состояние кластера соответствовало желаемому. Примеры: ReplicaSet, Deployment, StatefulSet.

4️⃣Сервисы (Services): Абстракция, которая определяет логический набор подов и политику доступа к ним. Сервисы позволяют обращаться к подам, используя DNS или IP-адреса, и управляют балансировкой нагрузки.

5️⃣Пространства имен (Namespaces): Изоляция частей кластера. Позволяет разделять ресурсы кластера между несколькими пользователями.

6️⃣Конфигурационные данные (ConfigMaps and Secrets): Объекты для хранения конфигурационной информации и конфиденциальных данных соответственно, которые могут быть использованы подами.

Архитектура

✅Мастер-узел (Master Node): Управляет кластером и отвечает за основные решения о развертывании приложений (например, когда, где и как запускать поды).
✅Рабочие узлы (Worker Nodes): На этих узлах запускаются приложения. Узел содержит компоненты, необходимые для этого: Docker, kubelet, kube-proxy и другие.

Почему он стал популярен

1️⃣Масштабируемость: Kubernetes эффективно управляет тысячами контейнеров, работающих одновременно.
2️⃣Надежность и устойчивость: Автоматическое восстановление от сбоев (например, перезапуск неисправных контейнеров).
3️⃣Гибкость и портативность: Поддерживает различные среды — облака, виртуальные машины, физические сервера.
4️⃣Управление конфигурацией и секретами: Упрощает развертывание и управление конфигурационными данными и секретами.
5️⃣Самообслуживание и автоматизация: Упрощает разработку и операционную деятельность за счет автоматизации многих задач, связанных с развертыванием и масштабированием приложений.

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Чем отличаются роли от плейбуков ?
Спросят с вероятностью 33%

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

Плейбуки (Playbooks)

Это YAML-файлы, которые описывают задачи и процессы автоматизации, которые необходимо выполнить на одной или нескольких управляемых машинах. Они включают в себя одну или несколько "игр" (plays), каждая из которых может целиться на определённую группу хостов для выполнения заданных задач. Плейбук может описывать полную конфигурацию сервера, установку программного обеспечения, обновление системы и другие операционные задачи.

Пример простого плейбука:

- name: Update web servers
  hosts: webservers
  tasks:
    - name: Ensure nginx is at the latest version
      ansible.builtin.yum:
        name: nginx
        state: latest

Роли (Roles)

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

Стандартная структура роли включает:

✅tasks/ — Главные задачи роли.
✅handlers/ — Обработчики, которые вызываются по специальным триггерам.
✅defaults/ — Стандартные значения переменных, которые использует роль.
✅vars/ — Другие переменные, которые могут быть определены в роли.
✅files/ — Файлы, которые можно скопировать на управляемые машины.
✅templates/ — Шаблоны, которые можно обработать и скопировать на управляемые машины.
✅meta/ — Метаданные роли, включая зависимости от других ролей.

Основные отличия

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

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

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых

Чем отличается Terraform от Ansible ELK stack ?
Спросят с вероятностью 33%

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

Terraform

Это инструмент, разработанный HashiCorp, для создания, изменения и управления инфраструктурой как кодом (IaC). Он позволяет пользователям определять и предоставлять полную инфраструктуру (серверы, базы данных, сетевые устройства и т.д.) в различных облачных провайдерах (например, AWS, Azure, Google Cloud) с помощью конфигурационных файлов, которые описывают желаемое состояние инфраструктуры.

Основные характеристики:

✅Идемпотентность: Способен привести инфраструктуру в точное состояние, определённое в конфигурационных файлах, не внося повторных изменений в уже существующие ресурсы, если это не требуется.
✅Декларативный подход: Пользователь описывает "что" должно быть создано, а не "как" это должно быть сделано.
✅Управление состоянием: Отслеживает текущее состояние инфраструктуры и помогает управлять её изменениями.

Ansible

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

Основные характеристики:

✅Процедурный подход: Описывает серию "шагов" или "задач", которые необходимо выполнить для достижения желаемого состояния.
✅Идемпотентность: Как и Terraform, Ansible может повторно применять одни и те же настройки без внесения изменений, если текущее состояние уже соответствует желаемому.
✅Агентное-менее выполнение: Для своей работы Ansible использует существующую SSH-инфраструктуру и не требует установки дополнительных агентов на целевых системах.

ELK Stack

Это набор инструментов для сбора, агрегирования и анализа больших объёмов данных. ELK состоит из трёх основных компонентов: Elasticsearch (поисковая и аналитическая система), Logstash (инструмент для сбора, трансформации и хранения данных) и Kibana (инструмент для визуализации данных из Elasticsearch).

Основные характеристики:

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

Различия в использовании:

✅Terraform лучше использовать для создания и управления инфраструктурой на стадии инициализации проекта или при значительных изменениях инфраструктуры.
✅Ansible идеально подходит для непрерывного управления конфигурацией и автоматизации рутинных задач на уже существующих серверах и устройствах.
✅ELK Stack используется для мониторинга и анализа работы систем после их развёртывания, сбора логов и визуализации данных.

Terraform, Ansible и ELK Stack выполняют различные, но взаимодополняющие функции в управлении IT-инфраструктурой и обработке данных.

👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент

🔐 База собесов | 🔐 База тестовых