🤔 Какая разница между deployment и stateful set?

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

🚩Что такое Deployment?

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

🟠Бесстаточные приложения
Примеры: веб-серверы, микросервисы, обработка очередей. Каждый под одинаков, и потеря одного из них не нарушает работу приложения.
🟠Порядок развертывания
Поды запускаются и удаляются в любом порядке. Если под удаляется, создается новый с другой идентичностью.
🟠Сетевой доступ
Поды доступны через Service, но они не сохраняют фиксированные сетевые имена.
🟠Обновления
Поддерживает обновления без простоя (rolling updates). Умеет откатываться на предыдущую версию.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6

🚩Что такое StatefulSet?

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

🟠Состояние приложения
Примеры: базы данных (MySQL, PostgreSQL), системы очередей (Kafka), распределенные системы (Cassandra, Elasticsearch). Каждый под имеет уникальный идентификатор и связан с определенным хранилищем данных.

🟠Порядок развертывания
Поды запускаются, обновляются и удаляются строго в определенном порядке (0, 1, 2...). Это важно для приложений, где один узел должен быть доступен перед запуском другого.

🟠Сетевой доступ
Каждый под имеет фиксированное имя (например, pod-0, pod-1), что упрощает взаимодействие между подами.

🟠Обновления
Выполняются поэтапно, с учетом порядка.

🟠Постоянство данных
Поды используют PersistentVolumeClaim (PVC) для сохранения данных. Даже если под удален, данные остаются на диске и доступны после повторного запуска.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql-service"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

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

🟠Используйте `Deployment`
Бесстаточное. Требует быстрой масштабируемости. Не зависит от порядка запуска подов.
🟠Используйте `StatefulSet`
Требует сохранения данных между перезапусками. Зависит от фиксированной идентичности подов. Требует упорядоченного запуска или удаления.

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

🤔 Как автоматически деплоить Helm Chart?

Для автоматического деплоя Helm-чартов можно использовать:
- CI/CD инструменты (GitLab CI, GitHub Actions, Jenkins) с шагами helm install или helm upgrade;
- GitOps-подход через ArgoCD или Flux, где Helm-чарты подтягиваются и применяются при изменении Git-репозитория;
- Использование Helm-плагинов для управления релизами и версионированием.

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

🤔 Что слышали про rancher kubernetes?

Это платформа для управления Kubernetes-кластерами. Она позволяет развертывать, настраивать, мониторить и управлять несколькими кластерами Kubernetes из единой панели управления. Rancher упрощает работу с Kubernetes, предоставляя удобный UI, API и инструменты автоматизации.

🚩Зачем нужен Rancher?

🟠Управление несколькими кластерами
Rancher позволяет управлять кластерами Kubernetes, развернутыми в различных облаках (AWS, GCP, Azure) и на локальной инфраструктуре.
🟠Упрощенная установка и настройка
С помощью Rancher можно быстро развернуть Kubernetes-кластеры с минимальными усилиями.
🟠Безопасность и контроль доступа
Поддерживает аутентификацию через LDAP, Active Directory, GitHub и другие методы.
🟠Мониторинг и логирование
Встроенная поддержка Prometheus, Grafana и Fluentd для мониторинга и логов.
🟠Развертывание приложений
Поддерживает Helm-чарты и стандартные манифесты Kubernetes.

🚩Как работает Rancher?

🟠Rancher Server
центральный компонент, управляющий кластерами и предоставляющий UI/API.
🟠Kubernetes-кластеры
могут быть развернуты с помощью Rancher (RKE, RKE2) или добавлены вручную (например, EKS, AKS, GKE).
🟠Rancher Agents
агенты, установленные в кластерах для обеспечения связи с сервером Rancher.

🚩Пример развертывания Rancher

Для развертывания Rancher можно использовать Docker

docker run -d --name=rancher --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  rancher/rancher:latest

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

🤔 Как по access-логам Nginx понять, из какого location отдан контент?

По умолчанию в access.log не указывается location напрямую, но:
- Обычно можно различить по пути URL — если location /static/, location /cache/, location /backend/ — это отражается в строке запроса.
- Чтобы точно видеть, откуда был ответ, можно:
- Добавить пользовательский формат логов, где записывать $uri или специальные переменные ($request_uri, $upstream_addr и пр.).
- Логировать переменные, которые задаются внутри каждого location (например, set $source static → логируешь $source).

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

🤔 Как можно визуализировать логи?

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

🚩Почему нужна визуализация логов?

🟠Упрощает анализ
вместо просмотра тысяч строк логов можно быстро увидеть тенденции и аномалии.
🟠Помогает в мониторинге
можно отслеживать изменения в режиме реального времени.
🟠Ускоряет диагностику проблем
легче выявить причину ошибки, если видеть всплески или изменения в логах.
🟠Облегчает работу с большими объемами данных
миллионы строк логов можно представить в виде сводных диаграмм.

🚩Какие инструменты используются?

🟠ELK Stack (Elasticsearch + Logstash + Kibana)
Logstash – собирает и обрабатывает логи.
Elasticsearch – хранит и индексирует логи для быстрого поиска.
Kibana – визуализирует данные, строит графики и дашборды.
Пример: Можно создать график с количеством ошибок 500 за последние 24 часа.

🟠Grafana + Loki (альтернатива ELK)
Loki – хранит и обрабатывает логи.
Grafana – строит красивые дашборды с логами и метриками.
Пример: Можно создать панель с последними логами приложений, используя tail-подобное обновление.

🟠Graylog
Обрабатывает логи, хранит их в Elasticsearch, строит графики и отправляет алерты.
Пример: Можно отфильтровать логи по уровню ERROR и вывести их в виде диаграммы.

🟠Datadog, Splunk, New Relic
Коммерческие решения с мощными инструментами аналитики логов.
Пример: Автоматическая корреляция логов с метриками системы.

🚩Простой пример работы с ELK

Logstash конфиг (сбор логов из файла)

   input {
     file {
       path => "/var/log/app.log"
       start_position => "beginning"
     }
   }
   output {
     elasticsearch {
       hosts => ["http://localhost:9200"]
     }
   }

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

🤔 Что такое pod?

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

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

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

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

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

Выделение ресурсов - CPU, RAM, диски, сеть
Балансировка нагрузки равномерное распределение трафика
Горизонтальное и вертикальное масштабирование
Авто-масштабировани – динамическое добавление/удаление мощностей

🟠Выделение ресурсов (CPU, RAM, Диск, Сеть)
В виртуализированных средах (Kubernetes, Docker, AWS, KVM, ESXi) выделение ресурсов настраивается через лимиты и квоты.

yaml  
apiVersion: v1  
kind: Pod  
metadata:  
  name: my-app  
spec:  
  containers:  
  - name: app  
    image: my-app:latest  
    resources:  
      requests:  
        cpu: "500m"   # Минимально 0.5 CPU  
        memory: "256Mi" # Минимально 256MB RAM  
      limits:  
        cpu: "1000m"  # Максимально 1 CPU  
        memory: "512Mi" # Максимально 512MB RAM  

🟠Балансировка нагрузки
Балансировка уменьшает нагрузку на один сервер и равномерно распределяет запросы.

nginx  
upstream backend {  
  server app1:5000;  
  server app2:5000;  
}  
server {  
  listen 80;  
  location / {  
    proxy_pass http://backend;  
  }  
}  

Пример терраформа для AWS ALB

hcl  
resource "aws_lb" "example" {  
  name               = "my-load-balancer"  
  internal           = false  
  load_balancer_type = "application"  
  security_groups    = [aws_security_group.lb_sg.id]  
}  

🟠Масштабирование (Горизонтальное и Вертикальное)
Горизонтальное масштабирование (добавление новых инстансов)
Kubernetes Horizontal Pod Autoscaler (HPA)

yaml  
apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: Resource  
    resource:  
      name: cpu  
      target:  
        type: Utilization  
        averageUtilization: 70  

🟠Авто-масштабирование (AWS/GCP/Kubernetes)
AWS Auto Scaling Group

hcl  
resource "aws_autoscaling_group" "example" {  
  min_size             = 2  
  max_size             = 10  
  desired_capacity     = 2  
  launch_configuration = aws_launch_configuration.example.name  
}

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

🤔 Как ограничить ресурсы приложения в кубах?

Ограничения задаются в манифесте контейнера с помощью resources.limits и resources.requests.
requests — минимальные ресурсы, которые контейнеру гарантированы.
limits — максимум, который контейнер может использовать.

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

🤔 Как AWS работает с DevOps?

AWS предоставляет облачные сервисы для автоматизации CI/CD, управления инфраструктурой, мониторинга и безопасности.

🚩CI/CD (Непрерывная интеграция и развертывание)

AWS предлагает инструменты для автоматической сборки, тестирования и деплоя.
AWS CodePipeline – автоматизация CI/CD-процессов
AWS CodeBuild – сборка и тестирование кода
AWS CodeDeploy – автоматический деплой в EC2, ECS, Lambda
AWS CodeCommit – репозиторий Git в AWS
Пример CI/CD-пайплайна в AWS CodePipeline
1. CodeCommit получает новый коммит
2. CodeBuild собирает и тестирует код
3. CodeDeploy разворачивает приложение на EC2

🚩Управление инфраструктурой (IaC)

В DevOps важно автоматически создавать и управлять ресурсами AWS.
Terraform – создает инфраструктуру по коду
AWS CloudFormation – аналог Terraform от AWS
AWS CDK (Cloud Development Kit) – IaC на Python/TypeScript

hcl  
resource "aws_instance" "web" {  
  ami           = "ami-123456"  
  instance_type = "t2.micro"  
}  

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

AWS поддерживает управление контейнерами и Kubernetes.
Amazon ECS (Elastic Container Service) – контейнеры без Kubernetes
Amazon EKS (Elastic Kubernetes Service) – управляемый Kubernetes
AWS Fargate – запуск контейнеров без управления серверами
Пример развертывания контейнера в AWS ECS:
1. Собираем Docker-образ
2. Загружаем его в Amazon ECR (Elastic Container Registry)
3. ECS автоматически масштабирует и управляет контейнерами

🚩Мониторинг и логирование

Amazon CloudWatch – сбор метрик и логов
AWS X-Ray – трассировка запросов в микросервисах
AWS CloudTrail – аудит действий в AWS
Пример мониторинга EC2
1. CloudWatch собирает метрики CPU, RAM
2. Настраиваем авто-масштабирование на основе этих метрик
3. CloudTrail записывает все изменения инфраструктуры

🚩Безопасность и управление доступом

AWS IAM (Identity and Access Management) – контроль прав
AWS Secrets Manager – управление паролями и API-ключами
AWS KMS (Key Management Service) – шифрование данных

hcl  
resource "aws_iam_role" "s3_read" {  
  name = "s3-read-only"  
  assume_role_policy = jsonencode({  
    Statement = [{  
      Effect = "Allow"  
      Action = "s3:GetObject"  
      Resource = "arn:aws:s3:::my-bucket/*"  
    }]  
  })  
}

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

🤔 Когда выполняются факты в Ansible?

Факты (facts) — это информация о целевой машине (ОС, IP, пакеты и т.д.). Они собираются в начале каждого play, если включено gather_facts: true (по умолчанию включено). Также можно собирать их вручную через модуль setup.

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

🤔 Что такое debezium?

Она позволяет отслеживать изменения в базах данных (INSERT, UPDATE, DELETE) в реальном времени и передавать их в Kafka, Elasticsearch, MongoDB и другие системы.

🚩Как работает Debezium?

Подключается к базе данных
(PostgreSQL, MySQL, MongoDB, Oracle и др.).
Слушает лог изменений (binlog, WAL, oplog и т. д.)
Формирует события в формате JSON
Передаёт их в Kafka или другую шину данных.

🚩Где используется?

Синхронизация данных между базами
Репликация данных в реальном времени
Отправка изменений в аналитические системы (Elasticsearch, ClickHouse)
Аудит и логирование изменений

🟠Пример работы с Kafka
Запускаем Debezium Connector для PostgreSQL*

{
  "name": "inventory-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "localhost",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "dbz",
    "database.dbname": "inventory",
    "database.server.name": "dbserver1"
  }
}

При изменении данных в таблице, Kafka получит событие:

{
  "schema": { ... },
  "payload": {
    "before": { "id": 1, "name": "Old Name" },
    "after": { "id": 1, "name": "New Name" },
    "op": "u"  // Update
  }
}

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

🤔 Из чего состоит worker node?

Worker-нода содержит:
- kubelet — агент, управляющий подами.
- kube-proxy — сетевое взаимодействие и балансировка.
- container runtime — Docker, containerd, CRI-O.

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

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

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

🚩Локальный почтовый сервер (SMTP)

1⃣Установка

sudo apt update
sudo apt install postfix   

2⃣Настройка
Отредактируйте /etc/postfix/main.cf

myhostname = local.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
relay_domains = $mydestination   

3⃣Перезапуск Postfix

sudo systemctl restart postfix   

4⃣Проверка

echo "Test email" | mail -s "Test Subject" user@example.com

🚩Локальный мессенджер (Mattermost)

1⃣Установка Mattermost
Следуйте [документации](https://docs.mattermost.com/install/self-managed-install.html).

2⃣Настройка
Создайте каналы и пользователей.

3⃣Интеграция с мониторингом
Используйте веб-хуки Mattermost для уведомлений.

🚩Системы управления инцидентами (Zabbix)

1⃣Установка Zabbix
Следуйте [документации](https://www.zabbix.com/download).

2⃣Настройка
Настройте хосты, триггеры и действия.

3⃣Настройка уведомлений
Медиатипы: Настройте Email и SMS. Пользователи: Создайте пользователей и уведомления.

🚩Локальный стек мониторинга (Prometheus, Alertmanager)

1⃣Установка Prometheus

wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz
tar xvf prometheus-2.26.0.linux-amd64.tar.gz
cd prometheus-2.26.0.linux-amd64
./prometheus --config.file=prometheus.yml   

2⃣Установка Alertmanager

wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
tar xvf alertmanager-0.21.0.linux-amd64.tar.gz
cd alertmanager-0.21.0.linux-amd64
./alertmanager --config.file=alertmanager.yml   

3⃣Настройка алертинга в Prometheus

groups:
  - name: example-alerts
    rules:
      - alert: HighCPUUsage
        expr: avg_over_time(node_cpu_seconds_total{mode="idle"}[5m]) < 20
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High CPU usage detected"
          denoscription: "CPU usage is above 80% for more than 2 minutes"   

4⃣Настройка Alertmanager

global:
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@local.example.com'
route:
  receiver: 'email-notifications'
receivers:
  - name: 'email-notifications'
    email_configs:
      - to: 'admin@local.example.com'
        send_resolved: true

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

🤔 Как экспортёры отдают метрики?

Экспортёры собирают метрики из сервисов или ОС и предоставляют их по HTTP в формате, который Prometheus может опрашивать. Они работают по модели pull, где Prometheus забирает данные сам.

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

🤔 Какие микросервисы можно масштабировать горизонтально?

Горизонтальное масштабирование – это добавление новых экземпляров (реплик) сервиса для увеличения производительности. Оно хорошо работает для статeless (без состояния) микросервисов, где нет привязки к конкретному серверу.

🚩Какие микросервисы можно масштабировать горизонтально?

🟠Веб-серверы и API-шлюзы
Примеры: Nginx, Traefik, Kong, API Gateway (AWS, GCP)
Почему можно масштабировать?
- Обрабатывают независимые запросы
- Не требуют сохранения состояния между запросами
- Легко распределяются через Load Balancer

yaml  
apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: my-api  
spec:  
  replicas: 5  
  selector:  
    matchLabels:  
      app: my-api  
  template:  
    metadata:  
      labels:  
        app: my-api  
    spec:  
      containers:  
      - name: api-container  
        image: my-api:latest  

🟠Backend-сервисы (Stateless)
Примеры: REST API (FastAPI, Express, Spring Boot), gRPC-сервисы
Почему можно масштабировать?
Каждый запрос обрабатывается независимо
Нет привязки к конкретному серверу
Можно использовать Load Balancer (например, AWS ALB, Nginx)

nginx  
upstream backend {  
  server backend1:5000;  
  server backend2:5000;  
  server backend3:5000;  
}  
server {  
  listen 80;  
  location / {  
    proxy_pass http://backend;  
  }  
}  

🟠Очереди сообщений и брокеры событий
Примеры: RabbitMQ, Kafka, NATS, Redis Streams
Почему можно масштабировать?
Сообщения разбираются разными нодами
Можно увеличивать число консьюмеров
Поддерживают partitioning (разделение нагрузки)

python  
from kafka import KafkaConsumer  
consumer = KafkaConsumer('my_topic', group_id='workers', bootstrap_servers='kafka:9092')  
for message in consumer:  
    process_message(message)  

🟠Кэш-сервисы (Stateless)
Примеры: Redis (в режиме Cluster), Memcached
Почему можно масштабировать?
Каждый узел хранит часть данных
Можно распределять кэш по нескольким инстансам
Redis поддерживает Sharding (разбиение данных на ноды)

sh  
redis-cli --cluster create 192.168.1.1:6379 192.168.1.2:6379 192.168.1.3:6379 --cluster-replicas 1  

🚩Какие микросервисы **нельзя просто так масштабировать горизонтально?**

Некоторые сервисы сохраняют состояние (stateful) и сложны в горизонтальном масштабировании:
Базы данных → MySQL, PostgreSQL (нужны реплики или шардирование)
Сервисы с сессиями → Например, если пользователь всегда должен попасть на тот же сервер
Хранилища файлов → Например, локальное хранение логов на сервере

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

🤔 Что известно про workflow GitLab?

GitLab CI/CD workflow — это последовательность стадий (stages) и заданий (jobs), определённых в .gitlab-ci.yml. Стадии выполняются последовательно: build → test → deploy. Jobs могут выполняться параллельно внутри одной стадии. Также можно использовать правила (rules), переменные (env), артефакты и условия запуска.

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

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

Когда под (Pod) не работает или ведёт себя странно, нужно уметь его дебажить.

🟠Проверить статус пода
Сначала смотрим, работает ли под вообще

kubectl get pods

🟠Посмотреть логи контейнера
Если под запустился, но работает странно, смотрим логи:

kubectl logs pod-name

Если в поде несколько контейнеров:

kubectl logs pod-name -c container-name

Если под перезапускается, а нам нужны старые логи:

kubectl logs pod-name --previous

🟠Проверить события (`describe`)
Смотрим подробную информацию о поде:

kubectl describe pod pod-name

🟠Зайти внутрь контейнера (`exec`)
Если под запущен, можно подключиться внутрь и посмотреть файлы, процессы:

kubectl exec -it pod-name -- /bin/sh

Если в контейнере есть только bash:

kubectl exec -it pod-name -- /bin/bash

Полезные команды внутри контейнера:

ps aux           # Смотрим запущенные процессы  
netstat -tulnp   # Проверяем открытые порты  
env              # Проверяем переменные окружения  
cat /etc/resolv.conf  # Проверяем DNS  

🟠Проверить манифест пода (`get pod -o yaml`)
Если под ведёт себя странно, можно посмотреть его полное описание:

kubectl get pod pod-name -o yaml

🟠Проверить ресурсы (describe node)
Иногда под не запускается из-за нехватки CPU или памяти. Проверяем узел (node):

kubectl describe node node-name

Если проблема с ресурсами, будет что-то вроде:

Warning  FailedScheduling  insufficient memory

🟠Проверить сеть (`nslookup`, `ping`, `curl`)
Если под не может достучаться до сервиса, тестируем сеть:

kubectl exec -it pod-name -- nslookup service-name
kubectl exec -it pod-name -- ping 8.8.8.8
kubectl exec -it pod-name -- curl http://service-name:8080

🟠Дебажить с помощью `kubectl debug` (Kubernetes 1.23+)
Если под не стартует, можно запустить дебажный контейнер

kubectl debug pod-name -it --image=busybox

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

🤔 Чем проводить процедуру траблшутинга?

Процедура траблшутинга проводится с помощью логов (journalctl, kubectl logs), мониторинга (Prometheus, Grafana), сетевых утилит (netstat, tcpdump, nmap), профилировщиков (htop, top, iotop) и инструментов трассировки (strace, lsof). Также полезны APM-системы и средства централизованного логирования (ELK, Loki).

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

🤔 В каких случаях используется multi stage?

Multi-stage (многоэтапная сборка) — это метод создания Docker-образов, позволяющий уменьшить их размер и повысить безопасность.

🚩Когда используется?

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

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

Допустим, у нас есть приложение на Go. Мы сначала компилируем его в одном контейнере, а затем создаем минимальный образ для запуска.

# Этап 1: сборка
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Этап 2: минимальный образ для запуска
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

🚩Использование в React / Angular / Vue

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

# Этап 1: сборка приложения
FROM node:18 AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build

# Этап 2: деплой на nginx
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]

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

🤔 Что такое императивный подход?

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

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

🤔 Видим что места нет находим большой файл 5 Гб например удаляем его а пишет что места всё равно нет в чём причина?

В Linux удаленный файл может оставаться в памяти, если он все еще используется запущенным процессом. Это происходит, потому что файл не удаляется физически, пока его дескриптор (file denoscriptor) открыт.
Файл все еще используется процессом
Файл удален, но все еще открыт (deleted в /proc)
Файл удален, но был записан в смонтированный том

🚩Проверить, какие процессы держат удаленный файл (`lsof`)

Команда

lsof | grep deleted

Вывод

nginx     1234  www-data   4w   REG  8,1  5G   /var/log/nginx/access.log (deleted)

Решение: Перезапустить процесс:

systemctl restart nginx

или

kill -HUP 1234  # Закрыть процесс (PID = 1234)

🚩Освободить место вручную (`/proc`)

Если процесс нельзя перезапустить, можно освободить занятую память без перезапуска.

ls -l /proc/*/fd/ | grep deleted

Вывод

lrwx------ 1 root root 64 Feb 21 14:23 /proc/5678/fd/4 -> /var/log/nginx/access.log (deleted)

Очистить файл, не перезапуская процесс

> /proc/5678/fd/4

🚩Проверить монтирование (Docker, NFS, tmpfs)

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

df -h
mount | grep /var/log

Если файл был в Docker-контейнере, проверить объемы:

docker system df

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