🤔 Что такое SLA, SLO, SLI?

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

🚩SLI (Service Level Indicator) – Показатель уровня сервиса

SLI – это метрика, которая показывает, насколько хорошо работает сервис.
- Доступность (например, uptime 99.9%)
- Время ответа API (например, менее 200 мс)
- Ошибки запросов (например, не более 1% 5xx ошибок)

🚩SLO (Service Level Objective) – Целевой уровень сервиса

SLO – это цель, которую компания ставит для SLI.
Доступность 99.9% сервиса в месяц.
Среднее время ответа API ≤ 200 мс.

🚩SLA (Service Level Agreement) – Соглашение об уровне сервиса

SLA – это официальное соглашение между клиентом и провайдером сервиса, которое описывает обязательства и штрафы за их невыполнение.
- Если доступность меньше 99.9%, клиент получает возврат денег.
- Если среднее время ответа API больше 500 мс, клиент получает скидку.

🚩Как они связаны?

SLI (метрика) → измеряет, насколько хорош сервис.
SLO (цель) → устанавливает, каким должен быть сервис.
SLA (договор) → фиксирует обязательства и штрафы.

Ставь 👍 и забирай 📚 Базу знаний

🤔Как запустишь приложение в Kubernetes?

Чтобы запустить приложение в Kubernetes:
1. Подготовь манифест YAML с описанием (обычно это Deployment или StatefulSet).
2. Убедись, что есть нужный Service, чтобы обеспечить доступ к приложению.
3. Применяешь манифест командой:
4. kubectl apply -f <файл>.yaml
Приложение развернётся в виде подов, которые будут управляться контроллером.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Может ли быть несколько контейнеров в поде?

Да, в Kubernetes Pod можно запускать несколько контейнеров, и это обычная практика. Pod — это минимальная единица развертывания в Kubernetes которая может содержать один или несколько контейнеров.

🚩Зачем запускать несколько контейнеров в одном Pod?

🟠Sidecar-контейнеры
вспомогательные контейнеры, дополняющие основное приложение (логирование, прокси, безопасность).
🟠Init-контейнеры
выполняют задачи перед запуском основного контейнера (например, подготовка базы данных).
🟠Общий файловый кэш
контейнеры могут использовать общие тома (volumes) для хранения данных.
🟠Общий сетевой стек
контейнеры в одном Pod разделяют IP-адрес и порты.

🚩Пример: два контейнера в одном Pod (Nginx + логирование)

Допустим, у нас есть Nginx и отдельный контейнер, который собирает его логи.

yaml  
apiVersion: v1  
kind: Pod  
metadata:  
  name: nginx-pod  
spec:  
  containers:  
  - name: nginx  
    image: nginx  
    volumeMounts:  
    - name: log-volume  
      mountPath: /var/log/nginx  

  - name: log-collector  
    image: busybox  
    command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]  
    volumeMounts:  
    - name: log-volume  
      mountPath: /var/log/nginx  

  volumes:  
  - name: log-volume  
    emptyDir: {}  

🚩Как работают контейнеры внутри Pod?

Все контейнеры внутри Pod имеют один IP-адрес и могут взаимодействовать через localhost.
Например, если в одном контейнере работает Node.js на порту 3000, другой контейнер внутри Pod может обращаться к нему через localhost:3000.
Контейнеры могут делиться файлами через volumes, как в примере выше.
Если нужно выполнить команду перед запуском основного контейнера, используют initContainers.

yaml  
apiVersion: v1  
kind: Pod  
metadata:  
  name: app-pod  
spec:  
  initContainers:  
  - name: wait-for-db  
    image: busybox  
    command: ["sh", "-c", "until nc -z db-service 5432; do sleep 1; done"]  

  containers:  
  - name: app  
    image: my-app

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что произойдёт с контейнером, если будет превышен лимит по памяти?

Контейнер будет немедленно остановлен, и статус пода отразит ошибку OOMKilled. Это защита от выхода за пределы выделенных ресурсов. Такой лимит жёсткий, и превышение приводит к завершению процесса.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В чём преимущество Kubernetes как платформы?

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

🚩Основные плюсы

➕Автоматизация управления приложениями
Kubernetes автоматически запускает, останавливает и перезапускает контейнеры при сбоях. Поддерживает заданное число экземпляров (реплик) приложений, перезапуская или создавая их при необходимости.

➕Масштабирование (горизонтальное и вертикальное)
Ручное: Легко увеличить или уменьшить количество контейнеров (поды) для приложения. Автоматическое: Используя Horizontal Pod Autoscaler (HPA), Kubernetes добавляет ресурсы при увеличении нагрузки.

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

➕Платформонезависимость
Kubernetes работает в любых средах: Локальных (например, Minikube). В публичных облаках (AWS, Google Cloud, Azure). В гибридных и on-premise инфраструктурах.

➕Управление конфигурацией и секретами
Kubernetes упрощает работу с настройками: ConfigMaps: Для управления конфигурационными данными.
Secrets: Для безопасного хранения конфиденциальной информации, например, ключей API или паролей.

➕Эффективное использование ресурсов
Kubernetes помогает оптимизировать потребление CPU и памяти: Устанавливая минимальные и максимальные лимиты ресурсов для каждого приложения. Перераспределяя ресурсы между приложениями.

➕Расширяемость
Kubernetes поддерживает плагины и кастомизацию: Сетевые плагины (Calico, Flannel) для настройки сети. Системы мониторинга (Prometheus, Grafana). Операторы для автоматизации сложных задач.

➕Сообщество и экосистема
Kubernetes поддерживается большинством крупных облачных провайдеров. Обширная экосистема инструментов: Helm для управления шаблонами, ArgoCD для GitOps, Istio для сетевых взаимодействий.

🚩Когда особенно полезен?

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

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое Prometheus?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 На каких принципах работает докер?

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

🚩Основные принципы

🟠Контейнеризация
Контейнеризация позволяет запускать приложения и их зависимости в изолированных окружениях. Контейнеры предоставляют легкие и эффективные среды, которые включают все необходимое для запуска приложений.
Контейнеры: Легковесные, изолированные окружения, которые работают поверх ядра хостовой операционной системы.
Namespace: Механизм ядра Linux, обеспечивающий изоляцию процессов, сети, PID, пользовательских идентификаторов и монтирования файловых систем.
Cgroups: Контрольные группы в Linux, которые ограничивают и отслеживают использование ресурсов контейнерами, включая процессорное время, память и I/O.

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

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

🟠Управление сетями
Docker предоставляет гибкие возможности управления сетями для контейнеров, включая создание изолированных сетей и подключение контейнеров к различным сетям.
Bridge Network: Создает изолированную сеть для контейнеров на одном хосте.
Host Network: Контейнер использует сетевые интерфейсы хостовой операционной системы.
Overlay Network: Позволяет контейнерам на разных хостах взаимодействовать друг с другом.
Macvlan Network: Контейнеры получают собственные MAC-адреса и ведут себя как физические устройства в сети.

🟠Хранение данных
Docker поддерживает различные механизмы хранения данных для обеспечения сохранности и доступности данных контейнеров.
Volumes: Независимые от контейнеров хранилища данных, которые могут быть подключены к одному или нескольким контейнерам.
Bind Mounts: Позволяют монтировать директории хостовой файловой системы в контейнеры.
Tmpfs: Использует память хоста для хранения данных контейнера, что полезно для временных данных.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что означает "сделать rebase на main branch"?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое PaaS?

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

🚩Примеры PaaS-платформ

Heroku → Легкий деплой веб-приложений.
Google App Engine → Запуск приложений в облаке Google.
AWS Elastic Beanstalk → Автоматическое управление инфраструктурой.
Microsoft Azure App Services → Запуск приложений в Azure без управления серверами.

🚩Когда использовать PaaS?

Если хотите быстро развернуть приложение без настройки серверов.
Когда важна автоматическая масштабируемость.*
Если не хотите заниматься управлением ОС и базами данных.

🚩Пример работы с PaaS (Heroku)

1⃣Устанавливаем Heroku CLI

curl https://cli-assets.heroku.com/install.sh | sh

2⃣Авторизуемся

heroku login

3⃣Разворачиваем приложение

git push heroku main

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем бы вы заменили Logstash на Windows?

На Windows Logstash часто заменяют на Filebeat, поскольку он легче, проще настраивается и эффективно выполняет задачи по пересылке логов, особенно если преобразование логов минимально.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какие коды ответа мы получаем от веб-сервера?

Коды ответа (HTTP status codes) от веб-сервера представляют собой числовые коды, которые отправляются клиенту (обычно веб-браузеру) в ответ на его запрос. Эти коды помогают клиенту понять, что произошло с его запросом: был ли он успешен, произошла ли ошибка, требуется ли дополнительное действие и т.д.

🚩HTTP-коды ответа разделены на пять основных категорий:

🟠1xx (Информационные):
Запрос принят, продолжается обработка.
100 Continue: Сервер получил начальную часть запроса, и клиент должен продолжать.
101 Switching Protocols: Сервер принимает запрос на изменение протокола.

🟠2xx (Успех):
Запрос успешно обработан.
200 OK: Запрос успешно обработан, и сервер возвращает запрошенные данные.
201 Created: Запрос успешно выполнен, и в результате создан новый ресурс.
202 Accepted: Запрос принят для обработки, но обработка еще не завершена.
204 No Content: Запрос успешно выполнен, но сервер не возвращает никакого содержимого.

🟠3xx (Перенаправление):
Для завершения обработки запроса требуется дальнейшее действие со стороны клиента.
301 Moved Permanently: Запрашиваемый ресурс был перемещен на новый постоянный URL.
302 Found: Запрашиваемый ресурс временно доступен по другому URL.
304 Not Modified: Запрашиваемый ресурс не изменился со времени последнего доступа (кэширование).
307 Temporary Redirect: Запрашиваемый ресурс временно доступен по другому URL. Клиент должен использовать исходный метод для нового запроса.

🟠4xx (Ошибка клиента):
Ошибка в запросе клиента.
400 Bad Request: Сервер не может обработать запрос из-за неверного синтаксиса.
401 Unauthorized: Запрос требует аутентификации.
403 Forbidden: Сервер понял запрос, но отказывается его выполнять.
404 Not Found: Запрашиваемый ресурс не найден на сервере.
405 Method Not Allowed: Метод, указанный в запросе, не разрешен для запрашиваемого ресурса.
409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.

🟠5xx (Ошибка сервера):
Ошибка на стороне сервера при попытке обработки запроса.
500 Internal Server Error: Общая ошибка сервера. Сервер не может выполнить запрос.
501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
502 Bad Gateway: Сервер, действуя как шлюз или прокси, получил неверный ответ от вышестоящего сервера.
503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания.
504 Gateway Timeout: Сервер, действуя как шлюз или прокси, не дождался ответа от вышестоящего сервера.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как задать права на всё?

Если ты хочешь дать максимальные права всем (rwx):
- Числовая форма: chmod 777 файл
- 7 = 4 (r) + 2 (w) + 1 (x)
- Символьная форма: chmod a+rwx файл
- a = all
Осторожно: такие права дают полный доступ всем, включая анонимных пользователей.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Куда идет деплой из релизных веток?

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

🚩Что такое релизные ветки?

Это ветки, которые создаются на этапе, когда функционал и исправления, готовые к выпуску, отделяются от основной ветки разработки (например, main или develop). Они позволяют:
Заморозить текущий набор изменений для подготовки к релизу.
Отделить доработки и исправления релиза от активной разработки.
Упростить процесс тестирования и последующего деплоя.

🚩Куда обычно идет деплой из релизных веток?

🟠Тестовое окружение (QA environment)
На тестовое окружение деплой из релизной ветки осуществляется для прохождения проверок качества: Автоматизированное и ручное тестирование.
Проверка производительности, безопасности и других аспектов.

stages:
  - test
deploy:
  stage: test
  script:
    - echo "Deploying release branch to QA"
    - ./deploy.sh qa
  only:
    - release/*

🟠Стейджинговое окружение (Staging)
После успешного прохождения тестов релизную ветку деплоят в стейджинг. Это окружение максимально похоже на продакшн и используется для финального тестирования: Проверка совместимости с продакшн-системами.
Демонстрация функционала заказчикам или заинтересованным сторонам.

stages:
  - staging
deploy:
  stage: staging
  script:
    - echo "Deploying release branch to Staging"
    - ./deploy.sh staging
  only:
    - release/*

🟠Продакшн (Production)
После прохождения всех этапов тестирования изменения из релизной ветки деплоятся в продакшн: Обычно это делается автоматически после финального подтверждения.
В некоторых командах финальный мерж релизной ветки в main инициирует деплой.

stages:
  - production
deploy:
  stage: production
  script:
    - echo "Deploying release branch to Production"
    - ./deploy.sh production
  only:
    - release/*

🚩Зачем это нужно?

🟠Изоляция релиза
Релизные ветки позволяют избежать включения новых, неподготовленных изменений в текущий релиз.
🟠Гибкость
Если в процессе тестирования или релиза найдены баги, их можно исправить прямо в релизной ветке без влияния на разработку.
🟠Управление рисками
Релизные ветки упрощают управление разными стадиями разработки и релиза.

🚩Пример использования

1⃣Разработчик создает ветку release/1.0.0 от develop.
2⃣Выполняются тесты на QA окружении.
3⃣Исправляются баги в release/1.0.0, и изменения деплоятся на стейджинг.
4⃣После успешного тестирования ветка мержится в main, и начинается деплой в продакшн.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как организовать метод хранения ролей, чтобы они были доступны плейбуку, когда он вызывается?

Роли должны находиться в директории roles, либо можно задать путь к ним через параметр roles_path в файле ansible.cfg.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что используется внутри докер контейнера?

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

🟠Файловая система
Каждый контейнер имеет собственную файловую систему, основанную на многослойной архитектуре. Это изолированное пространство предоставляет доступ к: Образу Docker (image): Базовый набор файлов, определенных в Docker Image. Copy-on-write (COW): Контейнеры используют copy-on-write слой для изменений. Базовый образ остается неизменным, а любые изменения записываются в слой контейнера. Точки монтирования: Возможность монтировать директории хоста или сетевые тома (volumes) для сохранения данных.

docker run -v /host/path:/container/path nginx

🟠Процессы
В контейнере запускаются процессы, как в обычной операционной системе. Главный процесс контейнера (например, команда из CMD или ENTRYPOINT) работает с PID 1 и отвечает за выполнение приложения. Процессы внутри контейнера изолированы от процессов на хосте благодаря использованию Linux namespaces.

docker exec <container_id> ps aux

🟠Сетевые интерфейсы
Docker-контейнеры используют виртуальные сетевые интерфейсы для связи:
veth-pair: Каждый контейнер имеет виртуальный интерфейс, подключенный к мосту (docker0 по умолчанию).
Типы сетей:
bridge (по умолчанию): Локальная сеть между контейнерами.
host: Контейнер использует сетевой стек хоста.
none: Полностью изолированный контейнер без сети.
overlay: Сеть для соединения контейнеров на разных хостах.

docker network create my_network
docker run --network my_network nginx

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

docker run --cpus="2" nginx

Память: Лимит на использование оперативной памяти.

docker run -m 512m nginx

I/O (диск): Возможность ограничения операций чтения/записи.

docker run --device-read-bps=/dev/sda:1mb nginx

🟠Изоляция (Namespaces и Control Groups)
Docker использует технологии изоляции, встроенные в ядро Linux:
Namespaces: Обеспечивают изоляцию пространства имен (PID, сети, файловой системы и т.д.). Control Groups (cgroups): Управляют использованием ресурсов (CPU, RAM, I/O).

lsns

🟠Среда выполнения (Runtime)
Docker-контейнеры работают благодаря среде выполнения, например:
runc: Легковесное средство выполнения контейнеров, совместимое со стандартом OCI. containerd: Менеджер для запуска контейнеров, который Docker использует для взаимодействия с низкоуровневыми компонентами.

🟠Настройки и переменные среды
Контейнер может быть настроен с использованием:
Переменных среды: Устанавливаются через ENV в Dockerfile или с помощью флага -e.

docker run -e ENV_VAR=value nginx

Аргументов при сборке: Используются в Dockerfile через ARG.

ARG BUILD_VERSION

🟠Приложение или служба
Главное, что работает внутри контейнера, — это само приложение: Например, веб-сервер (Nginx, Apache) или база данных (MySQL, PostgreSQL). Контейнеры упрощают запуск приложений с предсказуемыми зависимостями.

🟠Логи и мониторинг
Docker предоставляет возможность просматривать логи контейнера и собирать метрики
Логи

docker logs <container_id>

Информация о контейнере

docker inspect <container_id>

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как дебажить поды?

Для отладки подов в Kubernetes сначала можно посмотреть их логи командой kubectl logs <pod-name>. Если в поде несколько контейнеров, нужно указать имя контейнера через -c. Чтобы попасть внутрь контейнера, используют kubectl exec -it <pod-name> -- /bin/sh или /bin/bash. Также важно использовать kubectl describe pod <pod-name>, чтобы получить подробную информацию об ивентах, причине ошибок и статусе. Если под перезапускается, пригодится команда kubectl logs --previous, которая показывает логи предыдущего запуска контейнера.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний