🤔Как запустишь приложение в 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, которая показывает логи предыдущего запуска контейнера.

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

🤔 Где бы хранил tfstate если много разрабов?

Файл terraform.tfstate содержит текущее состояние инфраструктуры. Если его неправильно хранить, возможны конфликты и повреждение данных.

🚩Плохие решения

Локально (terraform.tfstate в репозитории)
Потеря данных, если разработчик сменит машину.
Конфликты, если несколько человек применяют terraform apply.
Невозможно откатиться к старому состоянию.
Не поддерживает блокировки (terraform lock).
Возможны проблемы с одновременным доступом.

🚩Лучшие решения для хранения `tfstate`

🟠S3 + DynamoDB (AWS) → Самый популярный способ
S3 хранит tfstate, а DynamoDB предотвращает конфликты.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

🟠Terraform Cloud/Enterprise → Официальное SaaS-решение
Terraform Cloud хранит tfstate в облаке HashiCorp.

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
  }
}

🟠Google Cloud Storage (GCS) + Firestore (GCP)
Для GCP аналог AWS S3 — это Google Cloud Storage (GCS), а DynamoDB заменяется Firestore.

terraform {
  backend "gcs" {
    bucket  = "my-tfstate-bucket"
    prefix  = "terraform/state"
  }
}

🟠Azure Storage + Azure CosmosDB (Azure)
Для Azure можно использовать Azure Storage и блокировки через Azure CosmosDB.

terraform {
  backend "azurerm" {
    resource_group_name  = "my-rg"
    storage_account_name = "myterraformstate"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

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

🤔 По какой причине inode могут закончиться

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

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

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

По умолчанию Ansible выполняет задачи последовательно, но можно ускорить выполнение с помощью параметра forks или асинхронных задач (async).

🚩Увеличение параллельных подключений (`forks`)

forks – это количество серверов, на которых Ansible выполняет задачи одновременно.

ansible-playbook -i inventory.ini playbook.yml --forks=10

Установить forks в ansible.cfg:

[defaults]
forks = 10

🚩Асинхронное выполнение (`async` + `poll`)

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

Пример асинхронного выполнения установки пакета

- name: Установить nginx параллельно
  apt:
    name: nginx
    state: present
  async: 300
  poll: 0

async: 300 – запускает задачу и дает ей 300 секунд на выполнение
poll: 0 – не ждет завершения, сразу переходит к следующей
Проверить статус запущенных задач:

ansible all -m async_status -a "jid=1234567890" -i inventory.ini

🚩Использование `&` в Shell-командах (`shell` + `nohup`)

Пример запуска задачи в фоновом режиме

- name: Запустить долгий процесс
  shell: "nohup long_script.sh &"

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

🤔 Что такое маска подсетей и зачем она нужна?

Маска подсети определяет, какая часть IP-адреса — это сеть, а какая — узел (host).
Например, маска 255.255.255.0 говорит: первые 3 октета — сеть, последний — устройства в ней.
Используется для разделения сети на подсети, маршрутизации и управления доступом.

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

🤔 В каком файле по дефолту будет хранится инормация об ОС, версии в линуксе?

В Linux информация о версии дистрибутива и ядра хранится в нескольких файлах.

🟠Основной файл — `/etc/os-release`
Этот файл есть во всех современных дистрибутивах (Debian, Ubuntu, RHEL, CentOS, Fedora).

cat /etc/os-release

Пример содержимого /etc/os-release

NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
PRETTY_NAME="Ubuntu 22.04.3 LTS"
VERSION_ID="22.04"
HOME_URL="https://www.ubuntu.com/"

🟠Альтернативный файл — `/etc/issue`
Некоторые дистрибутивы используют /etc/issue.

cat /etc/issue

Вывод

Ubuntu 22.04.3 LTS \n \l

🟠Информация о ядре — `/proc/version`
Этот файл содержит версию ядра и информацию о компиляции.

cat /proc/version

Вывод

Linux version 5.15.0-84-generic (buildd@lcy02-amd64-016) (gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0) #93-Ubuntu SMP

🟠Команды для проверки версии ОС
Проверить версию через lsb_release

lsb_release -a

Вывод

Distributor ID: Ubuntu  
Description:    Ubuntu 22.04.3 LTS  
Release:        22.04  
Codename:       jammy  

Проверить ядро через uname

uname -r

Вывод

5.15.0-84-generic

Можно также вывести полную информацию:

uname -a

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

🤔 Как остановить контейнер?

1. Обычное завершение – docker stop <container_id> (мягкий SIGTERM).
2. Принудительное завершение – docker kill <container_id> (SIGKILL).
3. Через Compose – docker-compose stop или docker-compose down.
4. Удаление контейнера – docker rm -f <container_id>.
5. Если завис в zombie state – kill -9 $(docker inspect --format '{{.State.Pid}}' <container_id>).

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