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

Это платформа для автоматизации развертывания, масштабирования и управления приложениями в контейнерах. Контейнеры позволяют изолировать приложения и их зависимости, обеспечивая легкую переносимость и консистентность окружения. Основные принципы работы 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>).

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

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

Чтобы мониторить Docker-контейнеры, нужно отслеживать ключевые метрики, которые помогут определить нагрузку, утечки памяти, падения контейнеров и проблемы с сетью.
CPU (Нагрузка на процессор)
Memory (Использование памяти)
Network (Сетевой трафик)
Disk I/O (Диск и файловая система)
Container Lifecycle (Состояние контейнеров)

🟠CPU (Загрузка процессора)
% использования CPU контейнером
% CPU в системе и пользователе
Throttling (ограничение CPU)

docker stats --format "table {{.Name}}\t{{.CPUPerc}}"

Метрика в Prometheus (cadvisor)

rate(container_cpu_usage_seconds_total{name="my-container"}[5m]) * 100

🟠Memory (Использование памяти)
RSS (реальная память, используемая процессами)
Cache (используемая кэшированная память)
OOM (Out of Memory kills)

docker stats --format "table {{.Name}}\t{{.MemUsage}}"

Метрика в Prometheus

container_memory_usage_bytes{name="my-container"}

🟠Network (Сетевой трафик)
Rx/Tx Bytes (входящий и исходящий трафик)
Количество соединений

docker stats --format "table {{.Name}}\t{{.NetIO}}"

Метрика в Prometheus

rate(container_network_transmit_bytes_total{name="my-container"}[5m])

🟠Disk I/O (Чтение/запись на диск)
Количество операций чтения/записи
Объем данных, записанных/прочитанных контейнером

docker stats --format "table {{.Name}}\t{{.BlockIO}}"

Метрика в Prometheus

rate(container_fs_writes_bytes_total{name="my-container"}[5m])

🟠Container Lifecycle (Состояние контейнеров)
Перезапуски контейнера (Restart Count)
Состояние контейнера (Running, Exited, Dead)

docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Restarts}}"

Метрика в Prometheus

container_start_time_seconds{name="my-container"}

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

🤔 Какие методы HTTP есть?

- GET — получить данные.
- POST — отправить (создать) данные.
- PUT — заменить данные.
- PATCH — частичное обновление.
- DELETE — удалить.
- HEAD, OPTIONS, TRACE — вспомогательные методы.

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

🤔 Удалил файлы, но место не очищается, в чем дело?

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

🚩Файл все еще используется процессом

Если файл удален, но он открыт каким-либо процессом, его содержимое остается в памяти или файловой системе до завершения работы этого процесса. Это называется "удаление с дескриптором".

🟠Как проверить:
Используйте команду lsof (list open files), чтобы найти процессы, удерживающие файл

lsof | grep deleted

🟠Как исправить
Перезапустите процесс или завершите его с помощью kill:

kill -9 <PID>

🚩Файл удален, но он находился в другом файловом пространстве

Например:
- Файл был удален внутри Docker-контейнера, но место занято в образе.
- Файл находился на смонтированном диске, и удаление произошло в другом контексте.

🟠Как проверить
Убедитесь, что вы работаете в правильной файловой системе:

df -h

🟠Как исправить
Убедитесь, что удаление происходит в нужной директории или файловой системе.

🚩Файл был удален из директории, но находится в другой ссылке (hard link)

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

🟠Как проверить
Используйте команду find, чтобы найти оставшиеся ссылки:

find / -samefile <имя_файла>

🟠Как исправить
Удалите все ссылки на файл.

🚩Файл был удален, но находился в файловой системе с квотой

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

🟠Как проверить
Проверьте квоты:

quota -u <username>

🟠Как исправить
Убедитесь, что квоты настроены правильно, или освободите больше места.

🚩Кэшированные данные или временные файлы

Иногда удаленные файлы остаются в виде кэша, временных данных или не удаляются из корзины.

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

sudo du -sh /tmp
sudo rm -rf /tmp/*

🟠Как исправить
Удалите временные файлы, очистите кэш:

sudo sync && sudo echo 3 > /proc/sys/vm/drop_caches

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

🤔 Как и где посмотреть логи какого-нибудь сервиса?

1. Если сервис использует systemd, логи можно посмотреть через journalctl -u <имя_сервиса>.
2. Для Nginx, Apache и других приложений логи находятся в /var/log/ или в директории, указанной в конфигурации сервиса.
3. Используйте команды tail, less или cat для просмотра логов.

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

🤔 Как примонтировать диск?

Чтобы использовать новый диск в Linux, его нужно разметить, создать файловую систему и примонтировать.

🚩Разметить диск (`fdisk`)

Запустить fdisk для диска sdb

sudo fdisk /dev/sdb

🚩Создать файловую систему (`mkfs`)

Форматировать раздел в ext4

sudo mkfs.ext4 /dev/sdb1

Если нужен xfs

sudo mkfs.xfs /dev/sdb1

🚩Автоматическое монтирование при загрузке (`/etc/fstab`)

Найти UUID диска

blkid /dev/sdb1

Вывод

/dev/sdb1: UUID="12345678-abcd-1234-efgh-56789abcdef0" TYPE="ext4"

Добавить в /etc/fstab

echo 'UUID=12345678-abcd-1234-efgh-56789abcdef0 /mnt/data ext4 defaults 0 2' | sudo tee -a /etc/fstab

Применить изменения

sudo mount -a

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