🤔 Что за протокол http, зачем он нужен?

HTTP (HyperText Transfer Protocol) — это протокол передачи данных в интернете. Он используется для обмена данными между клиентом (браузером) и сервером.

🚩Пример работы HTTP

Браузер отправляет запрос → "GET /index.html HTTP/1.1".
Сервер отвечает → HTML-страницей (200 OK).
Браузер отображает страницу.

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

Клиент-серверная модель → браузер запрашивает, сервер отвечает.
Без состояния (stateless) → каждый запрос независим (нет сессий).
Текстовый протокол → данные передаются в читаемом формате.

🚩Структура HTTP-запроса

Пример запроса от браузера к серверу

GET /index.html HTTP/1.1  
Host: example.com  
User-Agent: Mozilla/5.0

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

🤔 Как решить проблему, если Jenkins не видит merge request и ветки из GitLab?

- Убедиться, что используется GitLab Plugin.
- Включить webhook из GitLab.
- Установить refspec:
- +refs/merge-requests/*/head:refs/remotes/origin/mr/*
- Убедиться, что Jenkins имеет доступ к правильным permissions в GitLab.

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

🤔 Что такое squash в Docker?

В Docker термин "squash" (от англ. "раздавить", "сплющить") относится к процессу объединения нескольких слоев образа Docker в один. Это делается для уменьшения размера итогового образа и оптимизации хранения.

🚩Зачем нужен `squash`?

Docker-образы состоят из последовательности слоев. Каждый слой создается на основе команд в Dockerfile. Например, если ваш Dockerfile выглядит так:

FROM ubuntu:latest
RUN apt update && apt install -y nginx
RUN echo "Hello, World!" > /usr/share/nginx/html/index.html

🚩Как использовать `squash`?

В Docker squash можно выполнить с помощью флага --squash при сборке образа:

docker build --squash -t my-squashed-image .

Для включения экспериментального режима:
1. Открываем /etc/docker/daemon.json (или создаем, если его нет).
2. Добавляем строку "experimental": true.
3. Перезапускаем Docker:

systemctl restart docker

🚩Пример с `squash`

Без --squash

docker history my-image

С --squash

docker build --squash -t my-squashed-image .
docker history my-squashed-image

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

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

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

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

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

🟠Как проверить:
Используйте команду 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

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

🤔 Как дебажить поды в 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

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

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

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

🚩Локальный почтовый сервер (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"
          description: "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

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

🤔 Назови инструменты для развернутого окружения и настройки серверов

В DevOps используются разные инструменты для автоматизации развертывания и конфигурации серверов.

🟠Инструменты управления конфигурацией (Configuration Management)
Используются для настройки ОС, пакетов, сервисов и приложений.
Ansible – прост в освоении, использует SSH, без агентов
Puppet – декларативный подход, работает по клиент-серверной модели
Chef – использует Ruby DSL, сложнее в настройке
SaltStack – быстрый, поддерживает master-minion и режим без мастера

yaml  
- name: Установка Nginx  
  hosts: web  
  tasks:  
    - name: Установить Nginx  
      apt:  
        name: nginx  
        state: present  

🟠Инструменты инфраструктуры как код (IaC)
Используются для автоматического развертывания серверов и облачной инфраструктуры.
Terraform – лучший выбор для облаков (AWS, GCP, Azure)
CloudFormation – инструмент от AWS для управления ресурсами
Pulumi – позволяет писать инфраструктуру на Python, TypeScript

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

🟠Инструменты управления образами серверов (Image-based Deployment)
Используются для создания готовых образов ОС с предустановленным ПО.
Packer – создает образы для AWS AMI, Docker, VMware
Docker – контейнеризация для изолированных окружений
Vagrant – для локального тестирования инфраструктуры

json  
{  
  "builders": [{  
    "type": "amazon-ebs",  
    "region": "us-east-1",  
    "source_ami": "ami-123456",  
    "instance_type": "t2.micro",  
    "ssh_username": "ubuntu"  
  }]  
}  

🟠Инструменты оркестрации и контейнеризации
Используются для управления контейнерами и кластеризацией.
Docker Compose – для локального запуска нескольких контейнеров
Kubernetes – для управления контейнерами в продакшене
Nomad – альтернатива Kubernetes от HashiCorp

yaml  
version: '3'  
services:  
  web:  
    image: nginx  
    ports:  
      - "80:80"

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

🤔 В каких случаях удобно использовать Kubernetes, а в каких Docker Compose?

- Docker Compose — подходит для простых локальных окружений, отладки, микросервисов в одной машине.
- Kubernetes — для продакшн-окружений, масштабируемости, отказоустойчивости, автодеплоя.
Kubernetes нужен там, где требуется оркестрация, распределённость и гибкость.

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

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

Чтобы мониторить 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"}

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

🤔 Для чего используются иниь контейнеры?

Init-контейнеры (init containers) – это специальные контейнеры в поде, которые запускаются перед основным приложением. Они выполняют подготовительные задачи, а затем завершаются.

🚩Основные сценарии использования Init-контейнеров

🟠Подготовка окружения
Создание директорий, загрузка конфигураций или файлов перед запуском основного контейнера.
🟠Ожидание зависимостей
Проверка доступности БД, API или других сервисов перед запуском приложения.
🟠Миграции БД
Выполнение migrations перед стартом веб-приложения.
🟠Проверка и валидация данных
Убеждаемся, что все файлы и настройки корректны.

🚩Как работают Init-контейнеры?

Запускаются последовательно (поочередно).
Должны завершиться успешно, иначе весь под не стартует.
Не перезапускаются после завершения.
Не делят volume'ы с основным контейнером (могут передавать данные через shared volumes).

🚩Пример: Init-контейнер, проверяющий доступность БД

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: main-app
    image: my-app:latest
    ports:
    - containerPort: 8080
  initContainers:
  - name: wait-for-db
    image: busybox
    command: ['sh', '-c', 'until nc -z db-service 5432; do echo waiting for DB; sleep 2; done;']

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

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

Можно настроить Filtre Fluentd/Fluent Bit или использовать labels в Kubernetes, чтобы:
- фильтровать только нужные логи по namespace, app label или по шаблону имени контейнера;
- настроить маршрутизацию в Elasticsearch через output-фильтры;
- исключить лишнее через конфиг на уровне сбора логов.

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

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

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

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

Выделение ресурсов - 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  
}

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

🤔 Что значит ванильный Kubernetes?

Это чистая, стандартная установка Kubernetes без обёрток или специфичных дополнений от облачных провайдеров (таких как GKE, EKS, AKS). Ванильный кластер предоставляет полный контроль, но требует ручной настройки всех компонентов.

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

🤔 Какие есть метрики для измерения качества системы?

Для измерения качества системы (особенно в DevOps, SRE и разработке) используют различные метрики производительности, надежности и доступности.

🚩Основные метрики качества системы

🟠Метрики "Четырёх ключевых показателей" (DORA)
Эти метрики помогают оценить эффективность процессов DevOps:
Lead Time for Changes (Время доставки изменений) — время от написания кода до его выхода в прод.
Deployment Frequency (Частота развертываний) — как часто изменения попадают в прод.
Mean Time to Restore (MTTR) (Среднее время восстановления) — как быстро исправляются инциденты.
Change Failure Rate (Процент неудачных изменений) — доля развертываний, вызывающих сбои.

🟠Метрики надежности и доступности (SRE)
Эти метрики помогают измерять надежность системы:
SLA (Service Level Agreement) — договорное время доступности (например, 99.9%).
SLO (Service Level Objective) — целевое значение доступности (например, 99.95%).
SLI (Service Level Indicator) — фактические измеренные показатели (например, 99.93%).
Error Rate — процент ошибок в системе (HTTP 500, таймауты и т. д.).
Latency (Задержка) — время ответа системы на запросы.

🟠Метрики производительности
Они показывают, насколько быстро работает система:
CPU Utilization — загрузка процессора.
Memory Usage — использование оперативной памяти.
Disk I/O — скорость чтения/записи на диск.
Network Throughput — пропускная способность сети.
Response Time — время отклика системы.

🟠Метрики пользовательского опыта
Оценивают удобство работы пользователей с системой:
Apdex (Application Performance Index) — индекс удовлетворенности пользователей (0–1).
TTFB (Time to First Byte) — время до получения первого байта ответа от сервера.
Page Load Time — время полной загрузки страницы.
Bounce Rate — процент пользователей, покинувших сайт без взаимодействия.

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

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

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

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

🤔 Как в docker compose вместо yaml файла использовать json файл?

Docker Compose поддерживает использование JSON-файлов вместо стандартного YAML-файла. Формат JSON полностью совместим с YAML, так как YAML является надмножеством JSON. Для этого достаточно создать JSON-файл с описанием конфигурации контейнеров и передать его с помощью опции -f.

🚩Шаги по использованию

🟠Создайте JSON-файл конфигурации
Файл должен содержать описание сервисов в формате JSON. Например, вместо YAML

version: "3.9"
services:
  web:
    image: nginx
    ports:
      - "80:80"

В формате JSON будет так

{
    "version": "3.9",
    "services": {
        "web": {
            "image": "nginx",
            "ports": ["80:80"]
        }
    }
}

🟠Запустите Docker Compose с этим файлом
Используйте флаг -f, чтобы указать Docker Compose, какой файл использовать

docker-compose -f docker-compose.json up

🟠Проверка работы
Вы можете проверить статус контейнеров, как обычно:

docker-compose -f docker-compose.json ps

🚩Почему использовать JSON?

🟠Совместимость
JSON часто используется в API, CI/CD-пайплайнах и других инструментах, которые могут генерировать конфигурации автоматически.
🟠Простота обработки
JSON легко парсить программно, что может быть полезно в скриптах и интеграциях.
🟠Стандартизация
Некоторые команды и проекты могут предпочитать JSON как более строгий и распространенный формат.

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

1⃣Создайте файл docker-compose.json

{
    "version": "3.8",
    "services": {
        "app": {
            "image": "python:3.9",
            "volumes": ["./app:/app"],
            "working_dir": "/app",
            "command": "python app.py"
        }
    }
}

2⃣Запустите

docker-compose -f docker-compose.json up

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

🤔 Как диагностировать проблемы с локальным сервером который не отвечает на ping?

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

🚩Пошаговая диагностика

1⃣Проверить, действительно ли сервер включен
Подойти к серверу и проверить:
Горят ли индикаторы сети (LAN) на сервере?
Реагирует ли на клавиатуру/монитор?
Не завис ли сервер? (Может помочь Hard Reboot).

2⃣Проверить, есть ли связь на L2-уровне (MAC-адреса)
Проверяем, видит ли наш компьютер MAC-адрес сервера через `arp`.
Запрос ARP

arp -a | grep 192.168.1.100

Если MAC-адрес есть → пакеты доходят до сервера, но он не отвечает.
Если MAC-адреса нет → возможны проблемы с сетью (кабель, порт, VLAN, DHCP, статика).
Дополнительно проверить соединение

ethtool eth0  # Проверить состояние сетевого адаптера
ip link show eth0  # Интерфейс должен быть UP

3⃣Проверить, отвечает ли сервер на другие запросы (SSH, HTTP, RDP)
Если ping отключен (ICMP заблокирован брандмауэром), но сервер работает, попробуем другие протоколы.
Пробуем зайти по SSH (если это Linux)

ssh user@192.168.1.100

Пробуем зайти по RDP (если это Windows)

rdesktop 192.168.1.100

Пробуем зайти через HTTP (если там веб-сервер)

curl -I http://192.168.1.100

4⃣Проверить сетевой интерфейс на сервере
Подключаемся к серверу (если возможно) и проверяем, есть ли у него сеть.
Проверяем IP-адрес сервера

ip a

или

ifconfig -a

Пробуем пропинговать шлюз с сервера

ping 192.168.1.1

5⃣Проверить брандмауэр и iptables на сервере
Если сервер не отвечает на ICMP, его может блокировать брандмауэр.
Linux (firewalld, iptables, ufw)

iptables -L -n | grep DROP  # Проверяем правила iptables
ufw status  # Проверяем UFW (если используется)
firewall-cmd --list-all  # Проверяем firewalld

Если ICMP запрещен → разрешаем его

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

ufw allow proto icmp

firewall-cmd --add-icmp-block=echo-reply --permanent
firewall-cmd --reload

Windows (Проверить ICMP в брандмауэре Windows)

netsh advfirewall firewall show rule name="File and Printer Sharing (Echo Request - ICMPv4-In)"

Если правило отключено → включаем

netsh advfirewall firewall add rule name="ICMP Allow" protocol=icmpv4:8,any dir=in action=allow

6⃣Проверить маршрутизацию и сеть
Если сервер и клиент находятся в разных VLAN или подсетях, проверяем маршрут.
На клиенте

traceroute 192.168.1.100  # Linux
tracert 192.168.1.100  # Windows

Проверить маршруты на сервере

ip route show

Если маршрут отсутствует → добавляем вручную

ip route add 192.168.1.0/24 via 192.168.1.1

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

🤔 Как сделать rebase на main branch?

Выполнить rebase на main в Git означает "перенести" ваши изменения поверх актуального состояния основной ветки (main).

🟠Переключаемся на вашу текущую ветку
Допустим, вы работаете в ветке feature-branch:

git checkout feature-branch

🟠Выполняем rebase на `main`
Сначала убедимся, что main обновлена:

git checkout main
git pull origin main

Теперь выполняем сам rebase:

git checkout feature-branch
git rebase main

🟠Разрешение конфликтов (если есть)
Если у вас есть конфликты, Git остановит процесс и попросит их решить.
Откройте файлы с конфликтами, исправьте их.
Добавьте исправленные файлы:

   git add <файл>
   

Продолжите rebase:

   git rebase --continue
   

🟠Обновление удалённого репозитория
Если rebase прошёл успешно, вам нужно форсированно обновить удалённую ветку (так как история изменилась):

git push origin feature-branch --force

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

🤔 Как проверять, что запрошенные пару сервисов видят друг друга?

1. Ping – проверяет, доступен ли хост (ping <IP>).
2. Traceroute (traceroute/mtr) – показывает маршрут пакетов.
3. Nslookup/Dig – проверка DNS-резолвинга (nslookup domain.com).
4. Telnet/NC – проверка доступности порта (nc -zv <IP> <PORT>).
5. Curl/Wget – проверка HTTP-доступа (curl -I http://service).
6. Tcpdump/Wireshark – анализ сетевого трафика.
7. Kubernetes Debug (kubectl exec, logs, describe) – если сервисы в K8s.
Если сервисы не видят друг друга, проверяют маршрутизацию, iptables, firewall, DNS.

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

🤔 Какой командой можно показать все работающие процессы на Linux?

Для отображения всех работающих процессов в Linux можно использовать несколько команд. Самые популярные из них: ps, top, htop и pgrep. Каждая из них имеет свои особенности.

🚩Команда `ps`

ps выводит снимок (snapshot) текущих процессов в момент выполнения команды.
🟠`ps aux`
Показывает все процессы, запущенные в системе, включая пользователей и системные демоны.

ps aux

🟠`ps -ef`
Альтернативный стиль вывода всех процессов с более детальной информацией.

ps -ef

🚩Команда `top`

top — интерактивная утилита для отображения всех запущенных процессов в реальном времени. Вывод обновляется автоматически.

Запуск

top

🚩Команда `htop`

htop — более современная и удобная версия top. Требуется предварительная установка:

sudo apt install htop  # Для Ubuntu/Debian
sudo yum install htop  # Для CentOS/RHEL

Запуск

htop

🚩Команда `pgrep`

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

Пример

pgrep -a ""

🚩Команда `systemctl` (для сервисов)

Если вы хотите посмотреть системные службы

systemctl list-units --type=service

🚩Какую команду выбрать?

🟠Для быстрого снимка
ps aux.
🟠Для мониторинга в реальном времени
top или htop.
🟠Для поиска конкретного процесса
pgrep <имя процесса>.

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

🤔 Как решать проблему, если ваш коллега удалил /usr/bin/chmod, и нет ОС-донора?

- Если chmod удалён, изменить права файла невозможно стандартным способом.
- Возможные варианты:
- Найти бинарник chmod в другой директории (например, в /bin, /sbin, /usr/local/bin).
- Использовать busybox chmod, если busybox установлен.
- Если есть root-доступ — попробовать выполнить через python, perl или bash:
- python -c 'import os; os.chmod("file", 0o755)'
- Или через find с -exec (если chmod встроен туда).
- В крайнем случае — смонтировать диск на другой системе (если физически возможно).

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