🤔 Как определить опции запуска пайплайна при редактировании определенных ресурсов в гите?
При работе с CI/CD (GitHub Actions, GitLab CI, Jenkins) часто нужно запускать пайплайн только при изменении определенных файлов. Это помогает оптимизировать сборку, экономить ресурсы и время.
🚩В GitHub Actions (on: push, paths)
В GitHub Actions можно указать файлы, изменения в которых запустят пайплайн.
🚩В GitLab CI/CD (only: changes)
В GitLab можно настроить запуск пайплайна по изменению файлов с помощью
🚩В Jenkins (when { changes })
В Jenkins Declarative Pipeline можно использовать
Ставь 👍 и забирай 📚 Базу знаний
При работе с CI/CD (GitHub Actions, GitLab CI, Jenkins) часто нужно запускать пайплайн только при изменении определенных файлов. Это помогает оптимизировать сборку, экономить ресурсы и время.
🚩В GitHub Actions (on: push, paths)
В GitHub Actions можно указать файлы, изменения в которых запустят пайплайн.
name: Infra Pipeline
on:
push:
paths:
- 'infra/**'
- 'k8s/**'
pull_request:
paths:
- 'infra/**'
- 'k8s/**'
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Deploy Infrastructure
run: ./deploy.sh
🚩В GitLab CI/CD (only: changes)
В GitLab можно настроить запуск пайплайна по изменению файлов с помощью
only: changes. stages:
- deploy
terraform:
stage: deploy
script:
- terraform apply -auto-approve
only:
changes:
- terraform/**
🚩В Jenkins (when { changes })
В Jenkins Declarative Pipeline можно использовать
when { changes } для проверки измененных файлов. pipeline {
agent any
stages {
stage('Deploy Ansible') {
when { changes path: 'ansible/**' }
steps {
sh './deploy_ansible.sh'
}
}
stage('Deploy Helm') {
when { changes path: 'helm/**' }
steps {
sh './deploy_helm.sh'
}
}
}
}Ставь 👍 и забирай 📚 Базу знаний
🤔 Кластер БД висит, запросы копятся, но другие выполняются быстро. Что происходит?
Скорее всего:
- Приложение удерживает блокировку, из-за чего остальные запросы висят в очереди.
- Блокировки возникают при долгих UPDATE, INSERT, TRANSACTION, особенно без COMMIT.
Что делать:
1. Проверить активные сессии и блокировки (pg_stat_activity — для PostgreSQL).
2. Выяснить какой запрос держит блокировку.
3. Убить зависшие транзакции или перезапустить зависший компонент.
4. Настроить таймауты транзакций и контроль количества соединений от приложения.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Скорее всего:
- Приложение удерживает блокировку, из-за чего остальные запросы висят в очереди.
- Блокировки возникают при долгих UPDATE, INSERT, TRANSACTION, особенно без COMMIT.
Что делать:
1. Проверить активные сессии и блокировки (pg_stat_activity — для PostgreSQL).
2. Выяснить какой запрос держит блокировку.
3. Убить зависшие транзакции или перезапустить зависший компонент.
4. Настроить таймауты транзакций и контроль количества соединений от приложения.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
💊1
🤔 Как бы вы настроили уведомления для сервисов которые находятся без интернета полностью локализованы закрыты от всего извне?
Для настройки уведомлений в изолированной сети без доступа к интернету используйте локальные инструменты и системы. Основные методы включают локальные почтовые серверы, мессенджеры и системы управления инцидентами.
🚩Локальный почтовый сервер (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
Ставь 👍 и забирай 📚 Базу знаний
🤔 Где бы хранил tfstate, если много разработчиков?
При совместной работе tfstate лучше хранить в удалённом бекенде, чтобы:
- Избежать конфликтов и потерь данных.
- Обеспечить блокировку (state locking) и доступ из разных точек.
Наиболее популярные варианты:
- Amazon S3 + DynamoDB (для блокировок)
- Terraform Cloud / Enterprise
- Google Cloud Storage (GCS)
- Azure Blob Storage
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
При совместной работе tfstate лучше хранить в удалённом бекенде, чтобы:
- Избежать конфликтов и потерь данных.
- Обеспечить блокировку (state locking) и доступ из разных точек.
Наиболее популярные варианты:
- Amazon S3 + DynamoDB (для блокировок)
- Terraform Cloud / Enterprise
- Google Cloud Storage (GCS)
- Azure Blob Storage
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔1
🤔 Что такое 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
🤔 Как работать с VictoriaMetrics?
VictoriaMetrics — это высокопроизводительная time-series база данных. Чтобы с ней работать:
- Писать метрики можно через:
- Prometheus Remote Write API (/api/v1/write),
- vmagent (аналог prometheus с проксированием),
- вручную через HTTP POST.
- Читать метрики:
- по PromQL (совместим с Prometheus),
- через vmui (веб-интерфейс),
- или Grafana + Prometheus data source.
- Развёртывание:
- может быть один бинарник (для single-node),
- или кластерная версия (vmselect, vminsert, vmstorage).
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
- Писать метрики можно через:
- Prometheus Remote Write API (/api/v1/write),
- vmagent (аналог prometheus с проксированием),
- вручную через HTTP POST.
- Читать метрики:
- по PromQL (совместим с Prometheus),
- через vmui (веб-интерфейс),
- или Grafana + Prometheus data source.
- Развёртывание:
- может быть один бинарник (для single-node),
- или кластерная версия (vmselect, vminsert, vmstorage).
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔 Какие есть метрики для измерения качества системы?
Для измерения качества системы (особенно в 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 — процент пользователей, покинувших сайт без взаимодействия.
Ставь 👍 и забирай 📚 Базу знаний
🤔1
🤔 Как хранить Helm шаблоны в GitLab?
- В отдельном репозитории (infrastructure/helm-charts).
- Или внутри проекта в папке helm/, charts/.
- Можно сделать GitLab Pages Registry:
- упаковывать чарты (helm package)
- публиковать (helm repo index . + pages)
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
- В отдельном репозитории (infrastructure/helm-charts).
- Или внутри проекта в папке helm/, charts/.
- Можно сделать GitLab Pages Registry:
- упаковывать чарты (helm package)
- публиковать (helm repo index . + pages)
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔 Как мы можем с помощью cloudfront сохранить бюджет на использование сервисов?
Amazon CloudFront — это CDN (Content Delivery Network), которая помогает оптимизировать затраты на трафик и нагрузку на серверы. Использование CloudFront позволяет экономить бюджет на AWS-сервисах следующими способами:
🟠Кеширование контента (уменьшение нагрузки на бэкенд)
CloudFront кэширует статический и динамический контент, что снижает количество запросов к вашим основным серверам (например, EC2, S3, API Gateway, Lambda).
Меньше запросов к S3 (меньше операций
Меньше запросов к API Gateway и Lambda (так как CloudFront может кешировать ответы API).
Экономия на EC2 и RDS, так как нагрузка перераспределяется.
🟠Использование бесплатного трафика между CloudFront и S3
Когда CloudFront забирает файлы из S3 в том же регионе, за исходящий трафик из S3 не взимается плата. Исходящий трафик из S3 в интернет стоит ≈ $0.09 за ГБ. Исходящий трафик из CloudFront в интернет дешевле (например, первые 1 ТБ в месяц — бесплатно).
🟠Снижение стоимости глобального трафика
Если у вас клиенты в разных странах, CloudFront дешевле, чем стандартный AWS-трафик. Исходящий трафик из CloudFront в интернет в среднем на 30-50% дешевле, чем прямой выход из EC2 или S3. AWS часто снижает цены на CloudFront трафик в рамках программ оптимизации.
🟠Фильтрация ненужного трафика (ботов, DDoS, парсеров)
CloudFront позволяет использовать AWS WAF (Web Application Firewall) для блокировки вредоносных запросов. Меньше запросов к бэкенду (EC2, API Gateway, Lambda). Защита от DDoS (AWS Shield Standard бесплатен для CloudFront).
🟠Кеширование динамического контента
CloudFront поддерживает TTL (Time-to-Live) для кэширования даже динамических API-ответов. Вместо запроса к API Gateway/Lambda, CloudFront может вернуть кэшированный ответ. Можно настроить "Stale While Revalidate" — клиент получает устаревший контент, пока идет обновление.
🟠Гибкое управление ценой через региональные edge-локации
CloudFront позволяет управлять ценами, ограничивая определенные регионы. Можно исключить дорогие регионы (например, Южную Америку, где трафик дороже). Можно использовать AWS Origin Shield для дополнительного кеширования между регионами.
🟠Использование CloudFront Functions вместо AWS Lambda
CloudFront поддерживает CloudFront Functions, которые выполняются прямо на edge-узлах и дешевле, чем Lambda@Edge. CloudFront Functions работают быстрее и стоят $0.10 за миллион запросов. Lambda@Edge стоит $0.60 за миллион запросов + плата за выполнение.
Ставь 👍 и забирай 📚 Базу знаний
Amazon CloudFront — это CDN (Content Delivery Network), которая помогает оптимизировать затраты на трафик и нагрузку на серверы. Использование CloudFront позволяет экономить бюджет на AWS-сервисах следующими способами:
🟠Кеширование контента (уменьшение нагрузки на бэкенд)
CloudFront кэширует статический и динамический контент, что снижает количество запросов к вашим основным серверам (например, EC2, S3, API Gateway, Lambda).
Меньше запросов к S3 (меньше операций
GET, а они платные). Меньше запросов к API Gateway и Lambda (так как CloudFront может кешировать ответы API).
Экономия на EC2 и RDS, так как нагрузка перераспределяется.
🟠Использование бесплатного трафика между CloudFront и S3
Когда CloudFront забирает файлы из S3 в том же регионе, за исходящий трафик из S3 не взимается плата. Исходящий трафик из S3 в интернет стоит ≈ $0.09 за ГБ. Исходящий трафик из CloudFront в интернет дешевле (например, первые 1 ТБ в месяц — бесплатно).
🟠Снижение стоимости глобального трафика
Если у вас клиенты в разных странах, CloudFront дешевле, чем стандартный AWS-трафик. Исходящий трафик из CloudFront в интернет в среднем на 30-50% дешевле, чем прямой выход из EC2 или S3. AWS часто снижает цены на CloudFront трафик в рамках программ оптимизации.
🟠Фильтрация ненужного трафика (ботов, DDoS, парсеров)
CloudFront позволяет использовать AWS WAF (Web Application Firewall) для блокировки вредоносных запросов. Меньше запросов к бэкенду (EC2, API Gateway, Lambda). Защита от DDoS (AWS Shield Standard бесплатен для CloudFront).
🟠Кеширование динамического контента
CloudFront поддерживает TTL (Time-to-Live) для кэширования даже динамических API-ответов. Вместо запроса к API Gateway/Lambda, CloudFront может вернуть кэшированный ответ. Можно настроить "Stale While Revalidate" — клиент получает устаревший контент, пока идет обновление.
🟠Гибкое управление ценой через региональные edge-локации
CloudFront позволяет управлять ценами, ограничивая определенные регионы. Можно исключить дорогие регионы (например, Южную Америку, где трафик дороже). Можно использовать AWS Origin Shield для дополнительного кеширования между регионами.
🟠Использование CloudFront Functions вместо AWS Lambda
CloudFront поддерживает CloudFront Functions, которые выполняются прямо на edge-узлах и дешевле, чем Lambda@Edge. CloudFront Functions работают быстрее и стоят $0.10 за миллион запросов. Lambda@Edge стоит $0.60 за миллион запросов + плата за выполнение.
Ставь 👍 и забирай 📚 Базу знаний
👍2
🤔 Что нужно сделать, чтобы использовать любую питон-библиотеку?
- Установить её через pip install имя_пакета.
- Лучше — в виртуальной среде:
- python -m venv venv && source venv/bin/activate && pip install
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
- Установить её через pip install имя_пакета.
- Лучше — в виртуальной среде:
- python -m venv venv && source venv/bin/activate && pip install
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
💊6
🤔 Где хранятся данные о группах которые существуют в системе?
В Linux информация о группах пользователей хранится в файле:
🚩Как посмотреть список групп?
Вывести содержимое файла
Формат строк в файле
Пример
Найти группу по имени
Выведет
Узнать, в каких группах состоит пользователь
или
Выведет
🚩Где ещё хранятся группы?
🟠Файл `/etc/gshadow`
хранит пароли групп
Если у группы есть пароль (редкость), он хранится здесь.
Формат:
Пример:
Посмотреть содержимое
🟠LDAP или Active Directory (если система подключена к домену)
Если используется корпоративный домен, данные о группах могут храниться в LDAP или Active Directory.
Ставь 👍 и забирай 📚 Базу знаний
В Linux информация о группах пользователей хранится в файле:
/etc/group — основной файл, содержащий список всех групп системы. 🚩Как посмотреть список групп?
Вывести содержимое файла
/etc/group cat /etc/group
Формат строк в файле
имя_группы:x:GID:пользователи
Пример
root:x:0:
sudo:x:27:alice,bob
developers:x:1001:john,mary
Найти группу по имени
grep '^sudo:' /etc/group
Выведет
sudo:x:27:alice,bob
Узнать, в каких группах состоит пользователь
groups alice
или
id -Gn alice
Выведет
alice sudo developers
🚩Где ещё хранятся группы?
🟠Файл `/etc/gshadow`
хранит пароли групп
Если у группы есть пароль (редкость), он хранится здесь.
Формат:
имя_группы:пароль:GID:админы_группы
Пример:
sudo:!:27:
developers:!:1001:john
Посмотреть содержимое
sudo cat /etc/gshadow
🟠LDAP или Active Directory (если система подключена к домену)
Если используется корпоративный домен, данные о группах могут храниться в LDAP или Active Directory.
getent group
Ставь 👍 и забирай 📚 Базу знаний
🤔 Что такое IaaS?
Infrastructure as a Service — модель, в которой пользователю предоставляются виртуальные машины, диски, сети и прочее, а он сам управляет ОС и ПО. Пример: AWS EC2, Google Compute Engine.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Infrastructure as a Service — модель, в которой пользователю предоставляются виртуальные машины, диски, сети и прочее, а он сам управляет ОС и ПО. Пример: AWS EC2, Google Compute Engine.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
🤔 Для чего используются иниь контейнеры?
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;']
Ставь 👍 и забирай 📚 Базу знаний
👍2
Нужны актуальные вопросы с собеседований ?
DevOps | Собеседования - твой незаменимый помощник в подготовке к собеседованиям.
🔊 Обзоры собеседований c вилками на позиции:
🔵 DevOps инженеров (Junior, Middle, Senior).
🔵 С комментариями автора, как человека, который активно собеседует кандидатов.
🔊 В ближайшее время:
🔵 Записи реальных собеседований (не моки и открытые собеседования).
🔵 Гайды и рекомендации по обходу частых ошибок при выступлении на техническом интервью.
➡️ Подписаться
DevOps | Собеседования - твой незаменимый помощник в подготовке к собеседованиям.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1