🤔 В чем разница Deployment и DaemonSet?
Deployment и DaemonSet являются двумя типами контроллеров, которые управляют развертыванием и обеспечением жизненного цикла подов (групп контейнеров). Они оба играют важные роли, но используются для разных целей и сценариев.
🚩Deployment
Это контроллер, который обеспечивает декларативное обновление подов и ReplicaSets (другой тип контроллера, который управляет одновременным запуском нескольких экземпляров одного и того же пода). Deployment поддерживает непрерывное развертывание, откат к предыдущим версиям, а также масштабирование подов.
🟠Масштабирование
Вы можете увеличивать или уменьшать количество подов в зависимости от нужд.
🟠Обновления
Поддерживает стратегии развертывания, такие как Rolling Update (постепенное обновление), которое помогает минимизировать простои при обновлении приложения.
🟠Самовосстановление
Автоматически перезапускает поды, которые перестали работать, находятся в ошибочном состоянии или не отвечают.
🚩DaemonSet
Это контроллер, который гарантирует, что на каждом узле кластера Kubernetes запущен экземпляр заданного пода. Когда добавляется новый узел, на нем автоматически запускается под, управляемый DaemonSet, и если узел удаляется, поды удаляются автоматически. Это идеально подходит для запуска служб мониторинга, сбора логов или других утилит, которые должны быть запущены на каждом узле.
🟠Гарантия запуска
Убедитесь, что каждый узел кластера запускает копию определённого пода.
🟠Автоматическое размещение
Когда добавляются новые узлы, на них автоматически размещаются необходимые поды.
🟠Службы уровня узла
Идеально подходит для запуска системных служб, таких как коллекторы логов, системы мониторинга и другие.
Ставь 👍 и забирай 📚 Базу знаний
Deployment и DaemonSet являются двумя типами контроллеров, которые управляют развертыванием и обеспечением жизненного цикла подов (групп контейнеров). Они оба играют важные роли, но используются для разных целей и сценариев.
🚩Deployment
Это контроллер, который обеспечивает декларативное обновление подов и ReplicaSets (другой тип контроллера, который управляет одновременным запуском нескольких экземпляров одного и того же пода). Deployment поддерживает непрерывное развертывание, откат к предыдущим версиям, а также масштабирование подов.
🟠Масштабирование
Вы можете увеличивать или уменьшать количество подов в зависимости от нужд.
🟠Обновления
Поддерживает стратегии развертывания, такие как Rolling Update (постепенное обновление), которое помогает минимизировать простои при обновлении приложения.
🟠Самовосстановление
Автоматически перезапускает поды, которые перестали работать, находятся в ошибочном состоянии или не отвечают.
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.14.2
ports:
- containerPort: 80
🚩DaemonSet
Это контроллер, который гарантирует, что на каждом узле кластера Kubernetes запущен экземпляр заданного пода. Когда добавляется новый узел, на нем автоматически запускается под, управляемый DaemonSet, и если узел удаляется, поды удаляются автоматически. Это идеально подходит для запуска служб мониторинга, сбора логов или других утилит, которые должны быть запущены на каждом узле.
🟠Гарантия запуска
Убедитесь, что каждый узел кластера запускает копию определённого пода.
🟠Автоматическое размещение
Когда добавляются новые узлы, на них автоматически размещаются необходимые поды.
🟠Службы уровня узла
Идеально подходит для запуска системных служб, таких как коллекторы логов, системы мониторинга и другие.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
containers:
- name: fluentd-elasticsearch
image: fluent/fluentd:v1.0
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
Ставь 👍 и забирай 📚 Базу знаний
🤔 Как сделать донастройку контейнера?
Донастройка контейнера может понадобиться, если:
Нужно изменить файлы конфигурации.
Установить дополнительные пакеты.
Задать переменные среды.
Подключить тома или сети.
Варианты донастройки: через Dockerfile, docker-compose, exec, тома и Entrypoint/CMD.
🟠Донастройка через Dockerfile (Лучший способ)
Если контейнер нужно модифицировать перед запуском, создаем свой
Собираем новый образ
🟠Донастройка через `docker-compose` (Гибкость)
Можно задать окружение, тома, команды.
Запуск
🟠Донастройка запущенного контейнера (`docker exec`)
Если контейнер уже работает, можно внести изменения прямо в него.
🟠Донастройка через тома (Volumes)
Если нужно изменять файлы без пересборки образа, подключаем тома.
🟠Использование `ENTRYPOINT` или `CMD`
Можно задать скрипт донастройки, который выполнится при старте контейнера.
В
Ставь 👍 и забирай 📚 Базу знаний
Донастройка контейнера может понадобиться, если:
Нужно изменить файлы конфигурации.
Установить дополнительные пакеты.
Задать переменные среды.
Подключить тома или сети.
Варианты донастройки: через Dockerfile, docker-compose, exec, тома и Entrypoint/CMD.
🟠Донастройка через Dockerfile (Лучший способ)
Если контейнер нужно модифицировать перед запуском, создаем свой
Dockerfile на основе существующего образа. FROM nginx:latest
COPY my-nginx.conf /etc/nginx/nginx.conf
CMD ["nginx", "-g", "daemon off;"]
Собираем новый образ
docker build -t my-nginx .
docker run -d -p 80:80 my-nginx
🟠Донастройка через `docker-compose` (Гибкость)
Можно задать окружение, тома, команды.
version: '3'
services:
db:
image: postgres:15
environment:
POSTGRES_USER: admin
POSTGRES_PASSWORD: secret
POSTGRES_DB: mydb
volumes:
- ./custom-postgres.conf:/etc/postgresql/postgresql.conf
command: postgres -c config_file=/etc/postgresql/postgresql.conf
Запуск
docker-compose up -d
🟠Донастройка запущенного контейнера (`docker exec`)
Если контейнер уже работает, можно внести изменения прямо в него.
docker exec -it my-container bash
apt update && apt install -y vim
🟠Донастройка через тома (Volumes)
Если нужно изменять файлы без пересборки образа, подключаем тома.
docker run -d -p 80:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf nginx
🟠Использование `ENTRYPOINT` или `CMD`
Можно задать скрипт донастройки, который выполнится при старте контейнера.
FROM postgres:15
COPY setup.sh /docker-entrypoint-initdb.d/setup.sh
RUN chmod +x /docker-entrypoint-initdb.d/setup.sh
В
setup.sh: #!/bin/bash
psql -U postgres -d mydb -c "CREATE TABLE test (id SERIAL PRIMARY KEY);"
Ставь 👍 и забирай 📚 Базу знаний
🤔 Что такое config map в кубере?
ConfigMap в Kubernetes – это механизм хранения конфигурационных данных. Он позволяет разделять код приложения и настройки, храня конфигурацию в виде ключ-значение. ConfigMap удобен для передачи переменных окружения, файлов конфигурации, командных аргументов без изменения образа контейнера.
🚩Основные способы использования ConfigMap
🟠Переменные окружения
передача настроек через ENV.
🟠Файлы конфигурации
монтирование в контейнер как файл.
🟠Параметры командной строки
передача аргументов в
🚩Как создать ConfigMap?
1⃣Создание из манифеста
2⃣Создание из командной строки
3⃣Создание из файла
🚩Как использовать ConfigMap в подах?
1⃣Как переменные окружения
2⃣Как монтируемый файл
Ставь 👍 и забирай 📚 Базу знаний
ConfigMap в Kubernetes – это механизм хранения конфигурационных данных. Он позволяет разделять код приложения и настройки, храня конфигурацию в виде ключ-значение. ConfigMap удобен для передачи переменных окружения, файлов конфигурации, командных аргументов без изменения образа контейнера.
🚩Основные способы использования ConfigMap
🟠Переменные окружения
передача настроек через ENV.
🟠Файлы конфигурации
монтирование в контейнер как файл.
🟠Параметры командной строки
передача аргументов в
command. 🚩Как создать ConfigMap?
1⃣Создание из манифеста
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
APP_ENV: "production"
LOG_LEVEL: "debug"
CONFIG_FILE: |
[settings]
mode = "production"
debug = true
2⃣Создание из командной строки
kubectl create configmap my-config --from-literal=APP_ENV=production --from-literal=LOG_LEVEL=debug
3⃣Создание из файла
kubectl create configmap my-config --from-file=config.ini
🚩Как использовать ConfigMap в подах?
1⃣Как переменные окружения
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app
image: my-app
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: my-config
key: APP_ENV
2⃣Как монтируемый файл
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app
image: my-app
volumeMounts:
- name: config-volume
mountPath: "/etc/config"
volumes:
- name: config-volume
configMap:
name: my-config
Ставь 👍 и забирай 📚 Базу знаний
🤔 Что за протокол http, зачем он нужен?
HTTP (HyperText Transfer Protocol) — это протокол передачи данных в интернете. Он используется для обмена данными между клиентом (браузером) и сервером.
🚩Пример работы HTTP
Браузер отправляет запрос →
Сервер отвечает → HTML-страницей (
Браузер отображает страницу.
🚩Основные принципы HTTP
Клиент-серверная модель → браузер запрашивает, сервер отвечает.
Без состояния (stateless) → каждый запрос независим (нет сессий).
Текстовый протокол → данные передаются в читаемом формате.
🚩Структура 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
Ставь 👍 и забирай 📚 Базу знаний
💊2
🤔 Как решить проблему, если Jenkins не видит merge request и ветки из GitLab?
- Убедиться, что используется GitLab Plugin.
- Включить webhook из GitLab.
- Установить refspec:
- +refs/merge-requests/*/head:refs/remotes/origin/mr/*
- Убедиться, что Jenkins имеет доступ к правильным permissions в GitLab.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
- Убедиться, что используется GitLab Plugin.
- Включить webhook из GitLab.
- Установить refspec:
- +refs/merge-requests/*/head:refs/remotes/origin/mr/*
- Убедиться, что Jenkins имеет доступ к правильным permissions в GitLab.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔 Что такое squash в Docker?
В Docker термин "squash" (от англ. "раздавить", "сплющить") относится к процессу объединения нескольких слоев образа Docker в один. Это делается для уменьшения размера итогового образа и оптимизации хранения.
🚩Зачем нужен `squash`?
Docker-образы состоят из последовательности слоев. Каждый слой создается на основе команд в
🚩Как использовать `squash`?
В Docker
Для включения экспериментального режима:
1. Открываем
2. Добавляем строку
3. Перезапускаем Docker:
🚩Пример с `squash`
Без
С
Ставь 👍 и забирай 📚 Базу знаний
В 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`
Без
--squashdocker history my-image
С
--squashdocker build --squash -t my-squashed-image .
docker history my-squashed-image
Ставь 👍 и забирай 📚 Базу знаний
💊1
🤔 Удалил файлы, но место не очищается, в чем дело?
Если вы удалили файлы, но место на диске не освободилось, это может происходить по нескольким причинам.
🚩Файл все еще используется процессом
Если файл удален, но он открыт каким-либо процессом, его содержимое остается в памяти или файловой системе до завершения работы этого процесса. Это называется "удаление с дескриптором".
🟠Как проверить:
Используйте команду
🟠Как исправить
Перезапустите процесс или завершите его с помощью
🚩Файл удален, но он находился в другом файловом пространстве
Например:
- Файл был удален внутри Docker-контейнера, но место занято в образе.
- Файл находился на смонтированном диске, и удаление произошло в другом контексте.
🟠Как проверить
Убедитесь, что вы работаете в правильной файловой системе:
🟠Как исправить
Убедитесь, что удаление происходит в нужной директории или файловой системе.
🚩Файл был удален из директории, но находится в другой ссылке (hard link)
Если файл имеет несколько жестких ссылок, удаление одного из них не освободит место до тех пор, пока не удалены все ссылки.
🟠Как проверить
Используйте команду
🟠Как исправить
Удалите все ссылки на файл.
🚩Файл был удален, но находился в файловой системе с квотой
Если используется файловая система с ограничением (например, квоты пользователей или групп), возможно, квота пользователя исчерпана, и это мешает очистке.
🟠Как проверить
Проверьте квоты:
🟠Как исправить
Убедитесь, что квоты настроены правильно, или освободите больше места.
🚩Кэшированные данные или временные файлы
Иногда удаленные файлы остаются в виде кэша, временных данных или не удаляются из корзины.
🟠Как проверить
Очистите кэш или проверьте корзину. Например, для очистки временных файлов
🟠Как исправить
Удалите временные файлы, очистите кэш:
Ставь 👍 и забирай 📚 Базу знаний
Если вы удалили файлы, но место на диске не освободилось, это может происходить по нескольким причинам.
🚩Файл все еще используется процессом
Если файл удален, но он открыт каким-либо процессом, его содержимое остается в памяти или файловой системе до завершения работы этого процесса. Это называется "удаление с дескриптором".
🟠Как проверить:
Используйте команду
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) не работает или ведёт себя странно, нужно уметь его дебажить.
🟠Проверить статус пода
Сначала смотрим, работает ли под вообще
🟠Посмотреть логи контейнера
Если под запустился, но работает странно, смотрим логи:
Если в поде несколько контейнеров:
Если под перезапускается, а нам нужны старые логи:
🟠Проверить события (`describe`)
Смотрим подробную информацию о поде:
🟠Зайти внутрь контейнера (`exec`)
Если под запущен, можно подключиться внутрь и посмотреть файлы, процессы:
Если в контейнере есть только
Полезные команды внутри контейнера:
🟠Проверить манифест пода (`get pod -o yaml`)
Если под ведёт себя странно, можно посмотреть его полное описание:
🟠Проверить ресурсы (describe node)
Иногда под не запускается из-за нехватки CPU или памяти. Проверяем узел (
Если проблема с ресурсами, будет что-то вроде:
🟠Проверить сеть (`nslookup`, `ping`, `curl`)
Если под не может достучаться до сервиса, тестируем сеть:
🟠Дебажить с помощью `kubectl debug` (Kubernetes 1.23+)
Если под не стартует, можно запустить дебажный контейнер
Ставь 👍 и забирай 📚 Базу знаний
Когда под (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
Ставь 👍 и забирай 📚 Базу знаний
👍2
🤔 Как бы вы настроили уведомления для сервисов которые находятся без интернета полностью локализованы закрыты от всего извне?
Для настройки уведомлений в изолированной сети без доступа к интернету используйте локальные инструменты и системы. Основные методы включают локальные почтовые серверы, мессенджеры и системы управления инцидентами.
🚩Локальный почтовый сервер (SMTP)
1⃣Установка
2⃣Настройка
Отредактируйте
3⃣Перезапуск Postfix
4⃣Проверка
🚩Локальный мессенджер (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
2⃣Установка Alertmanager
3⃣Настройка алертинга в Prometheus
4⃣Настройка Alertmanager
Ставь 👍 и забирай 📚 Базу знаний
Для настройки уведомлений в изолированной сети без доступа к интернету используйте локальные инструменты и системы. Основные методы включают локальные почтовые серверы, мессенджеры и системы управления инцидентами.
🚩Локальный почтовый сервер (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
Ставь 👍 и забирай 📚 Базу знаний
💊1
🤔 Назови инструменты для развернутого окружения и настройки серверов
В DevOps используются разные инструменты для автоматизации развертывания и конфигурации серверов.
🟠Инструменты управления конфигурацией (Configuration Management)
Используются для настройки ОС, пакетов, сервисов и приложений.
Ansible – прост в освоении, использует SSH, без агентов
Puppet – декларативный подход, работает по клиент-серверной модели
Chef – использует Ruby DSL, сложнее в настройке
SaltStack – быстрый, поддерживает master-minion и режим без мастера
🟠Инструменты инфраструктуры как код (IaC)
Используются для автоматического развертывания серверов и облачной инфраструктуры.
Terraform – лучший выбор для облаков (AWS, GCP, Azure)
CloudFormation – инструмент от AWS для управления ресурсами
Pulumi – позволяет писать инфраструктуру на Python, TypeScript
🟠Инструменты управления образами серверов (Image-based Deployment)
Используются для создания готовых образов ОС с предустановленным ПО.
Packer – создает образы для AWS AMI, Docker, VMware
Docker – контейнеризация для изолированных окружений
Vagrant – для локального тестирования инфраструктуры
🟠Инструменты оркестрации и контейнеризации
Используются для управления контейнерами и кластеризацией.
Docker Compose – для локального запуска нескольких контейнеров
Kubernetes – для управления контейнерами в продакшене
Nomad – альтернатива Kubernetes от HashiCorp
Ставь 👍 и забирай 📚 Базу знаний
В 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"
Ставь 👍 и забирай 📚 Базу знаний
👍1
🤔 В каких случаях удобно использовать Kubernetes, а в каких Docker Compose?
- Docker Compose — подходит для простых локальных окружений, отладки, микросервисов в одной машине.
- Kubernetes — для продакшн-окружений, масштабируемости, отказоустойчивости, автодеплоя.
Kubernetes нужен там, где требуется оркестрация, распределённость и гибкость.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
- Docker Compose — подходит для простых локальных окружений, отладки, микросервисов в одной машине.
- Kubernetes — для продакшн-окружений, масштабируемости, отказоустойчивости, автодеплоя.
Kubernetes нужен там, где требуется оркестрация, распределённость и гибкость.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔 Какие метрики стоит снимать с докер контейнеров?
Чтобы мониторить Docker-контейнеры, нужно отслеживать ключевые метрики, которые помогут определить нагрузку, утечки памяти, падения контейнеров и проблемы с сетью.
CPU (Нагрузка на процессор)
Memory (Использование памяти)
Network (Сетевой трафик)
Disk I/O (Диск и файловая система)
Container Lifecycle (Состояние контейнеров)
🟠CPU (Загрузка процессора)
Метрика в Prometheus (cadvisor)
🟠Memory (Использование памяти)
Метрика в Prometheus
🟠Network (Сетевой трафик)
Метрика в Prometheus
🟠Disk I/O (Чтение/запись на диск)
Метрика в Prometheus
🟠Container Lifecycle (Состояние контейнеров)
Метрика в Prometheus
Ставь 👍 и забирай 📚 Базу знаний
Чтобы мониторить 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"}Ставь 👍 и забирай 📚 Базу знаний
💊2
🤔 Для чего используются иниь контейнеры?
Init-контейнеры (init containers) – это специальные контейнеры в поде, которые запускаются перед основным приложением. Они выполняют подготовительные задачи, а затем завершаются.
🚩Основные сценарии использования Init-контейнеров
🟠Подготовка окружения
Создание директорий, загрузка конфигураций или файлов перед запуском основного контейнера.
🟠Ожидание зависимостей
Проверка доступности БД, API или других сервисов перед запуском приложения.
🟠Миграции БД
Выполнение
🟠Проверка и валидация данных
Убеждаемся, что все файлы и настройки корректны.
🚩Как работают Init-контейнеры?
Запускаются последовательно (поочередно).
Должны завершиться успешно, иначе весь под не стартует.
Не перезапускаются после завершения.
Не делят volume'ы с основным контейнером (могут передавать данные через shared volumes).
🚩Пример: Init-контейнер, проверяющий доступность БД
Ставь 👍 и забирай 📚 Базу знаний
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;']
Ставь 👍 и забирай 📚 Базу знаний
👍1
🤔 Как бы построили логирование только из определённых приложений с точки зрения EFK?
Можно настроить Filtre Fluentd/Fluent Bit или использовать labels в Kubernetes, чтобы:
- фильтровать только нужные логи по namespace, app label или по шаблону имени контейнера;
- настроить маршрутизацию в Elasticsearch через output-фильтры;
- исключить лишнее через конфиг на уровне сбора логов.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Можно настроить Filtre Fluentd/Fluent Bit или использовать labels в Kubernetes, чтобы:
- фильтровать только нужные логи по namespace, app label или по шаблону имени контейнера;
- настроить маршрутизацию в Elasticsearch через output-фильтры;
- исключить лишнее через конфиг на уровне сбора логов.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
💊1
🤔 Как бы построить выделение ресурсов, балансировку, нагрузку и всю масштабированность?
Чтобы система работала стабильно и эффективно, нужно правильно распределять ресурсы, балансировать нагрузку и масштабировать сервисы.
🚩Основные компоненты
Выделение ресурсов - CPU, RAM, диски, сеть
Балансировка нагрузки равномерное распределение трафика
Горизонтальное и вертикальное масштабирование
Авто-масштабировани – динамическое добавление/удаление мощностей
🟠Выделение ресурсов (CPU, RAM, Диск, Сеть)
В виртуализированных средах (Kubernetes, Docker, AWS, KVM, ESXi) выделение ресурсов настраивается через лимиты и квоты.
🟠Балансировка нагрузки
Балансировка уменьшает нагрузку на один сервер и равномерно распределяет запросы.
Пример терраформа для AWS ALB
🟠Масштабирование (Горизонтальное и Вертикальное)
Горизонтальное масштабирование (добавление новых инстансов)
Kubernetes Horizontal Pod Autoscaler (HPA)
🟠Авто-масштабирование (AWS/GCP/Kubernetes)
AWS Auto Scaling Group
Ставь 👍 и забирай 📚 Базу знаний
Чтобы система работала стабильно и эффективно, нужно правильно распределять ресурсы, балансировать нагрузку и масштабировать сервисы.
🚩Основные компоненты
Выделение ресурсов - 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
}
Ставь 👍 и забирай 📚 Базу знаний
🔥1
🤔 Что значит ванильный Kubernetes?
Это чистая, стандартная установка Kubernetes без обёрток или специфичных дополнений от облачных провайдеров (таких как GKE, EKS, AKS). Ванильный кластер предоставляет полный контроль, но требует ручной настройки всех компонентов.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
💊3👍1
🤔 Какие есть метрики для измерения качества системы?
Для измерения качества системы (особенно в 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 — процент пользователей, покинувших сайт без взаимодействия.
Ставь 👍 и забирай 📚 Базу знаний
Для измерения качества системы (особенно в 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 — процент пользователей, покинувших сайт без взаимодействия.
Ставь 👍 и забирай 📚 Базу знаний
🔥3
🤔 Какие коды ответа мы получаем от веб-сервера?
Коды ответа (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: Сервер, действуя как шлюз или прокси, не дождался ответа от вышестоящего сервера.
Ставь 👍 и забирай 📚 Базу знаний
Коды ответа (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: Сервер, действуя как шлюз или прокси, не дождался ответа от вышестоящего сервера.
Ставь 👍 и забирай 📚 Базу знаний
🔥1
🤔 Как в docker compose вместо yaml файла использовать json файл?
Docker Compose поддерживает использование JSON-файлов вместо стандартного YAML-файла. Формат JSON полностью совместим с YAML, так как YAML является надмножеством JSON. Для этого достаточно создать JSON-файл с описанием конфигурации контейнеров и передать его с помощью опции
🚩Шаги по использованию
🟠Создайте JSON-файл конфигурации
Файл должен содержать описание сервисов в формате JSON. Например, вместо YAML
В формате JSON будет так
🟠Запустите Docker Compose с этим файлом
Используйте флаг
🟠Проверка работы
Вы можете проверить статус контейнеров, как обычно:
🚩Почему использовать JSON?
🟠Совместимость
JSON часто используется в API, CI/CD-пайплайнах и других инструментах, которые могут генерировать конфигурации автоматически.
🟠Простота обработки
JSON легко парсить программно, что может быть полезно в скриптах и интеграциях.
🟠Стандартизация
Некоторые команды и проекты могут предпочитать JSON как более строгий и распространенный формат.
🚩Пример использования
1⃣Создайте файл
2⃣Запустите
Ставь 👍 и забирай 📚 Базу знаний
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
Если MAC-адрес есть → пакеты доходят до сервера, но он не отвечает.
Если MAC-адреса нет → возможны проблемы с сетью (кабель, порт, VLAN, DHCP, статика).
Дополнительно проверить соединение
3⃣Проверить, отвечает ли сервер на другие запросы (SSH, HTTP, RDP)
Если
Пробуем зайти по SSH (если это Linux)
Пробуем зайти по RDP (если это Windows)
Пробуем зайти через HTTP (если там веб-сервер)
4⃣Проверить сетевой интерфейс на сервере
Подключаемся к серверу (если возможно) и проверяем, есть ли у него сеть.
Проверяем IP-адрес сервера
или
Пробуем пропинговать шлюз с сервера
5⃣Проверить брандмауэр и iptables на сервере
Если сервер не отвечает на ICMP, его может блокировать брандмауэр.
Linux (firewalld, iptables, ufw)
Если ICMP запрещен → разрешаем его
Windows (Проверить ICMP в брандмауэре Windows)
Если правило отключено → включаем
6⃣Проверить маршрутизацию и сеть
Если сервер и клиент находятся в разных VLAN или подсетях, проверяем маршрут.
На клиенте
Проверить маршруты на сервере
Если маршрут отсутствует → добавляем вручную
Ставь 👍 и забирай 📚 Базу знаний
Если сервер не пингуется, это не значит, что он не работает – проблема может быть в сети, настройках брандмауэра или самом сервере.
🚩Пошаговая диагностика
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
Ставь 👍 и забирай 📚 Базу знаний
👍1
🤔 Как сделать rebase на main branch?
Выполнить rebase на main в Git означает "перенести" ваши изменения поверх актуального состояния основной ветки (
🟠Переключаемся на вашу текущую ветку
Допустим, вы работаете в ветке
🟠Выполняем rebase на `main`
Сначала убедимся, что
Теперь выполняем сам rebase:
🟠Разрешение конфликтов (если есть)
Если у вас есть конфликты, Git остановит процесс и попросит их решить.
Откройте файлы с конфликтами, исправьте их.
Добавьте исправленные файлы:
Продолжите rebase:
🟠Обновление удалённого репозитория
Если rebase прошёл успешно, вам нужно форсированно обновить удалённую ветку (так как история изменилась):
Ставь 👍 и забирай 📚 Базу знаний
Выполнить 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
Ставь 👍 и забирай 📚 Базу знаний