Библиотека девопса | DevOps, SRE, Sysadmin
Open in Telegram
1 273
Subscribers
+124 hours
+37 days
+330 days
Posts Archive
🔧 Популярные средства оркестрации
1. Kubernetes
- Описание: Де-факто стандарт оркестрации контейнеров.
- Кейсы:
- Микросервисная архитектура.
- Автоматическое масштабирование на основе нагрузки.
- Blue-Green и Canary-развертывания.
- Высокая отказоустойчивость.
2. Docker Swarm
- Описание: Встроенная система оркестрации в Docker.
- Кейсы:
- Простая кластеризация Docker-контейнеров.
- Быстрые POC и MVP без лишней сложности.
- Небольшие команды или проекты.
3. Nomad (от HashiCorp)
- Описание: Легковесная альтернатива Kubernetes, поддерживает разные типы нагрузок (не только контейнеры).
- Кейсы:
- Микс контейнеров, VMs и standalone-приложений.
- Высоконагруженные и распределённые системы.
- Интеграция с Consul и Vault.
4. Apache Mesos / Marathon
- Описание: Платформа для запуска распределённых приложений.
- Кейсы:
- Big Data ворклоады (Hadoop, Spark).
- Оркестрация большого количества различных ресурсов.
5. OpenShift
- Описание: Коммерческая PaaS от Red Hat на базе Kubernetes.
- Кейсы:
- Корпоративные решения с сильной безопасностью и интеграцией.
- Платформа для CICD.
- Разработка в приватных облаках.
Подпишись 👉@devopslib
Как бороться с конфигурационным дрейфом в инфраструктуре?
Конфигурационный дрейф – это скрытый враг стабильности инфраструктуры. Он возникает, когда фактическое состояние системы начинает расходиться с описанным в коде (IaC). Причины могут быть разные: ручные правки, неучтённые обновления, забытые изменения.
🔥 Как выявить и устранить дрейф?
1️⃣ Используйте периодический аудит
• Terraform: terraform plan поможет выявить разницу между текущим состоянием и кодом.
• Ansible: запустите с флагом --check для проверки соответствия.
2️⃣ Внедрите GitOps-подход
• Используйте ArgoCD или Flux для автоматического применения изменений и приведения системы в соответствие с репозиторием.
3️⃣ Логируйте и мониторьте изменения
• AWS Config, HashiCorp Sentinel, Open Policy Agent помогут отслеживать отклонения от желаемого состояния.
4️⃣ Ограничьте ручные изменения
• Доступ только через IaC.
• Обязательное ревью кода через PR в Git.
5️⃣ Автоматизируйте откат
• Автофиксы через CI/CD при обнаружении дрейфа.
• Используйте immutable-инфраструктуру (замена вместо правок).
Конфигурационный дрейф – это не баг, а особенность живой инфраструктуры. Но держать его под контролем можно и нужно!
Подпишись 👉 @devopslib
🔥 DevOps-антипаттерны, которые мешают вашей инфраструктуре
DevOps — это не только про автоматизацию, но и про культуру. Однако некоторые решения и привычки могут привести к хаосу. Давайте разберем топ антипаттернов, которые могут испортить вашу инфраструктуру.
🔹 Хрупкая инфраструктура
Вы выкатываете изменения в прод без тестов, мониторинга и резервных копий? Поздравляю, у вас хрупкая инфраструктура, которая рухнет при первом же сбое.
🔹 Один DevOps-инженер на все задачи
"У нас есть DevOps, он все делает". Такой подход быстро приводит к выгоранию и техническому долгу. DevOps — это культура, а не человек.
🔹 Отсутствие IaC (Infrastructure as Code)
Если вы настраиваете серверы руками, вы уже проиграли. Terraform, Ansible, Pulumi — вот ваши лучшие друзья.
🔹 Логирование в "черную дыру"
Вы собираете логи, но никто их не смотрит? Или, что еще хуже, нет нормального логирования? Тогда успехов в поиске багов "на ощупь".
🔹 "Работает — не трогай"
Этот принцип может убить ваш прод. Обновления закрывают уязвимости, повышают стабильность и улучшают производительность. Если у вас все еще Kubernetes 1.18 или Ubuntu 16.04 — пора задуматься.
🔹 CI/CD с кучей ручных шагов
Если ваш деплой требует 10 шагов в Confluence и ручного одобрения от трех человек, это не CI/CD, а боль. Автоматизируйте!
🚀 Что делать?
Пересмотрите свою инфраструктуру, уберите устаревшие практики и не допускайте этих ошибок. DevOps — про эффективность, а не про героизм в 3 часа ночи.
Подпишись 👉@devopslib
🔹Как DevOps может ускорить CI/CD?
Каждый DevOps-инженер рано или поздно сталкивается с проблемами долгих сборок и развертываний. Чем больше микросервисов, тем сложнее их быстро катить в прод. Давай разберем ключевые методы ускорения CI/CD!
🚀 Кэширование артефактов
Используй кэш для зависимостей и промежуточных сборок. Например, в GitHub Actions можно хранить кэш NPM-модулей или Docker-образов.
⚡ Параллельные джобы
Запускай тесты и сборки в параллель, если твой CI/CD позволяет. Например, в GitLab CI можно указать
parallel: 4, чтобы запустить 4 одинаковых джобы.
🐳 Оптимизация Docker-образов
1. Правильный порядок команд в Dockerfile – сначала COPY package.json и RUN npm install, потом сам код.
2. Меньше слоев – объединяй команды RUN через &&.
3. Используй легковесные базовые образы – Alpine вместо Debian.
🔄 Incremental Builds
Используй механизмы buildx в Docker и Bazel для сборки только измененных частей кода. Это снижает нагрузку на CI/CD.
🌍 Локальные runner'ы
Если GitHub Actions или GitLab CI тормозят из-за облачных ресурсов, разворачивай self-hosted runners. Это особенно полезно для проектов с высокой нагрузкой на CI.
📊 Мониторинг CI/CD
Включай метрики (Prometheus + Grafana) и анализируй узкие места пайплайна. Иногда проблема – не в коде, а в ресурсах билд-агентов.
Подпишись 👉@devopslib🔥 Как мониторить логи в реальном времени?
Мониторинг логов в реальном времени — одна из важнейших задач DevOps-инженера. Если сервис падает или выдаёт ошибки, нужно быстро понять, что произошло. Давайте разберём несколько инструментов, которые помогут оперативно анализировать логи.
🔹
tail -f и less +F
Классика UNIX. tail -f позволяет следить за последними строками лога, а less +F даёт возможность как мониторить в реальном времени, так и быстро пролистывать вверх для анализа.
🔹 multitail
Продвинутый вариант tail -f, который позволяет следить за несколькими логами одновременно в одном терминале.
🔹 journalctl -f
Если у вас systemd, используйте journalctl -f -u <service> для слежения за логами конкретного сервиса.
🔹 lnav
Очень мощный CLI-инструмент для логов с синтаксическим разбором, цветовой разметкой и возможностью фильтрации.
🔹 Grafana Loki + Promtail
Если нужен централизованный сбор и визуализация логов, то связка Loki + Promtail отлично подойдёт. Loki индексирует метаданные логов, а Promtail забирает их с серверов.
🔹 ELK (Elasticsearch + Logstash + Kibana)
Если нужно что-то мощнее и удобнее для анализа, то ELK-стек — отличный вариант. Kibana позволяет гибко фильтровать и строить дашборды по логам.
🔹 Vector
Современная альтернатива Logstash и Fluentd, очень эффективен для передачи логов в S3, Kafka, Elasticsearch и другие хранилища.
🔹 Sentry и New Relic
Если нужна агрегация логов и ошибок приложений, используйте Sentry или New Relic. Они позволяют быстро находить проблемные места в коде.
Подпишись 👉@devopslib🚀 Зачем DevOps инженеру уметь писать код?
Часто можно услышать мнение, что DevOps — это про инфраструктуру, пайплайны и кубер, а кодить должны разработчики. Но на практике хороший DevOps инженер неизбежно сталкивается с кодом и скриптингом. Почему это важно?
🔹 Автоматизация всего
Ручные операции = баги и потери времени. Написание CI/CD пайплайнов, автоматизация деплоя, инфраструктура как код (IaC) — все это требует хорошего знания Python, Bash, Go или даже Ruby.
🔹 Глубокое понимание приложений
Если ты можешь прочитать код, понять его логику, то тебе проще решать проблемы в продакшене. Debugging, логирование, мониторинг — все это связано с кодом.
🔹 Эффективный troubleshooting
Зачастую DevOps инженер — первый, к кому приходят с проблемами продакшена. Понимание кода помогает быстро локализовать ошибки, а не просто перезапускать контейнеры в надежде, что "само пройдет".
🔹 Разработка внутренних инструментов
Часто приходится писать собственные тулзы: CLI утилиты, API сервисы для инфраструктуры, кастомные плагины для Kubernetes, Terraform или Ansible.
🔹 Общение с разработчиками
Если ты говоришь с разработчиками на одном языке (и в прямом, и в переносном смысле), то взаимодействие между командами становится более продуктивным.
💡 Вывод: кодинг — это не просто полезный навык, а must-have для современного DevOps. Если еще не кодишь — самое время начать!
Подпишись 👉 @devopslib
🔥 Kubernetes: Как уменьшить время старта подов? 🔥
Одной из распространенных проблем в Kubernetes является длительный запуск подов, особенно если в кластере много сервисов. Давайте разберёмся, как можно ускорить этот процесс.
🚀 1. Используйте лёгкие образы
Выбирайте образы с минимальным количеством зависимостей. Вместо
ubuntu:latest лучше взять alpine или distroless.
⚡ 2. Настройте readinessProbe и livenessProbe
Некорректные пробки могут заставить Kubernetes перезапускать поды или считать их неготовыми дольше, чем нужно. Используйте их осознанно.
🎯 3. Предзагружайте образы (Image Pull Policy)
Если ваши поды используют публичные образы, включите ImagePullPolicy: IfNotPresent или Never, чтобы не скачивать образ при каждом старте.
containers:
- name: app
image: my-registry/app:latest
imagePullPolicy: IfNotPresent
InitContainers для подготовки окружения
Если поду требуется что-то до старта (например, миграции БД), лучше использовать InitContainers, чтобы основное приложение стартовало быстрее.
📦 5. Настройте ресурсы
Ограничения CPU и памяти (requests и limits) могут повлиять на скорость старта пода. Если ресурсов мало, контейнеру придётся ждать, пока Kubernetes выделит ему место.
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
preStopHook для graceful shutdown
Чтобы уменьшить задержки при перезапуске подов, обрабатывайте завершение работы приложения через preStopHook.
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 5"]
startupProbe для долгозапускающихся сервисов
Если приложение стартует долго, лучше использовать startupProbe, чтобы Kubernetes не убивал его раньше времени.
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 5
🚀 GitOps: революция в управлении инфраструктурой
GitOps — это подход к управлению инфраструктурой и развертыванию приложений, основанный на использовании Git как единственного источника правды. Все изменения проходят через pull request'ы, что дает прозрачность, контроль версий и автоматизацию.
🔹 Как это работает?
1️⃣ Вся конфигурация хранится в Git-репозитории.
2️⃣ Изменения происходят через коммиты и pull request'ы.
3️⃣ Автоматические агенты (ArgoCD, FluxCD) следят за репозиторием и применяют изменения в кластер.
🔹 Преимущества GitOps:
✅ Полная история изменений — легко откатиться назад.
✅ Автоматизация CI/CD — минимум ручной работы.
✅ Единая точка правды — все изменения в Git.
✅ Повышенная безопасность — политика pull request'ов предотвращает случайные ошибки.
🔹 Лучшие инструменты для GitOps:
🔸 ArgoCD — мощный инструмент с UI для визуального управления деплоями.
🔸 FluxCD — легковесное решение, полностью интегрируемое с Kubernetes.
🔸 Terraform + GitHub Actions — для инфраструктуры как кода.
GitOps — это не просто хайп, а будущее управления инфраструктурой! А ты уже внедрил его в проде?
Подпишись 👉@devopslib
🔹 DevOps: секреты работы с Terraform State 🔹
Terraform — мощный инструмент для управления инфраструктурой, но работа с его state-файлом требует особого внимания. Сегодня разберем, как правильно управлять состоянием и избегать проблем.
🚀 Основные проблемы с Terraform State
1️⃣ State-файл локально – потеряешь файл = потеряешь инфраструктуру.
2️⃣ Конфликты изменений – если несколько людей работают с одним state-файлом, возможны проблемы.
3️⃣ Частичная поломка state – если во время apply что-то пойдет не так, можно остаться с "битым" состоянием.
🔧 Как правильно работать с state?
✔️ Храни state в удаленном бекенде (S3 + DynamoDB, GCS, Azure Blob) – это защитит от потерь.
✔️ Включай блокировку state – например, DynamoDB table предотвратит конфликты.
✔️ Используй команды
terraform state – они помогут править state без лишних apply.
✔️ Настрой шифрование – если хранишь state в облаке, включай AES-256.
✔️ Разделяй стейты по окружениям – лучше иметь отдельные файлы для dev, staging, prod.
⚠️ Лайфхак: как восстановить state?
Если state поврежден, попробуй:
🔹 terraform state pull > backup.tfstate – сохранить текущий state.
🔹 terraform import – добавить ресурсы вручную.
🔹 terraform refresh – попытаться синхронизировать текущее состояние с реальными ресурсами.
💡 Привычка правильно работать с Terraform State спасет тебе кучу нервов!
Подпишись 👉@devopslibКак мониторить сервер без Prometheus?
Не всегда есть возможность поднять полноценный стек мониторинга, особенно если нужно быстро проверить состояние сервера. В таких случаях можно обойтись стандартными утилитами Linux.
🔥 1. Нагрузка на процессор
top -o %CPU
htop
top покажет общую картину, htop— более детализированную с цветами.
🔥 2. Использование памяти
free -h
vmstat -s
free -h выведет статистику по RAM в удобном виде.
🔥 3. Диск и файловая система
df -h
du -sh /var/log
du -sh /path поможет найти, куда оно ушло.
🔥 4. Сетевые соединения
netstat -tulnp
ss -tulnp
ss -tulnp поможет.
🔥 5. Нагрузка на дисковую систему
iostat -dx 1
iotop
tail -f /var/log/syslog
journalctl -f
🔥 Как не попасть в ад Kubernetes? 🔥
Все любят Kubernetes, пока он не начинает тащить вас в бездну бесконечных YAML-файлов и неожиданных фейлов. Держи чек-лист, чтобы не превратить кластер в хаос:
✅ RBAC с первого дня – без ограничений все контейнеры вдруг получают суперспособности (и это не круто). Разграничивай доступ сразу!
✅ Readiness & Liveness Probes – не будь тем, кто деплоит сервис без проверки его живучести. Без этих проб — гарантированные проблемы с балансировкой.
✅ Resource Requests & Limits – хочешь, чтобы один под сожрал все CPU и мем? Нет? Тогда ставь лимиты!
✅ Поднимай мониторинг раньше, чем тебе понадобится – Prometheus, Grafana, Loki… Не жди, пока что-то сломается.
✅ Network Policies – не будь дырявым – если не ограничить трафик, твои поды будут общаться как захотят. Взломать такой кластер проще простого.
✅ Backup etcd – всегда! – потеря etcd = потеря всего. Делай бэкапы, иначе одна ошибка и привет, восстановление с нуля.
✅ Автоматизируй деплои и GitOps – ручные правки в манифестах — путь к страданиям. ArgoCD, FluxCD в помощь!
📌 Kubernetes – мощь, но без дисциплины он превращается в боль. Делай всё с умом!
Подпишись 👉 @devopslib
Как DevOps-у не сгореть на работе? 🔥🚒
DevOps — это бесконечный поток задач, инцидентов и улучшений. Но если постоянно тушить пожары и не заботиться о себе, можно быстро перегореть. Как этого избежать?
1️⃣ Автоматизируй всё, что можно
Если ты делаешь одну и ту же рутину более двух раз — это кандидат на автоматизацию. Bash-скрипты, Ansible, Terraform, GitHub Actions — твои лучшие друзья.
2️⃣ Логи и мониторинг – твой щит 🛡️
Не жди звонка в 3 ночи из-за того, что прод лег. Настрой Prometheus + Grafana, Loki, ELK или OpenTelemetry. Ставь алерты заранее, чтобы проблемы решались до того, как их заметит бизнес.
3️⃣ Не будь "героем", работай в команде 🤝
Нет ничего хуже, чем быть единственным, кто знает, как работает инфраструктура. Делегируй, пиши документацию, проводи knowledge-sharing сессии.
4️⃣ Баланс между работой и жизнью 🌿
Если ты постоянно на связи 24/7, это путь в никуда. Разделяй работу и личную жизнь. Учись говорить «нет» и отдыхать без чувства вины.
5️⃣ Следи за трендами, но не будь их рабом
Kubernetes, Istio, eBPF, AI в DevOps — технологии меняются быстро, но не надо бежать за каждым хайпом. Оценивай их пользу для своего проекта, прежде чем внедрять.
Береги себя, DevOps! И помни: лучший DevOps — это отдохнувший DevOps. 😉
Подпишись 👉@devopslib
🔥 Kubernetes vs Docker Compose: Что выбрать? 🔥
Когда приходит время управлять контейнерами, многие задаются вопросом: использовать Docker Compose или Kubernetes? Разбираемся!
🚀 Docker Compose
✅ Простота развертывания — один YAML-файл, одна команда
docker-compose up.
✅ Идеально подходит для локальной разработки и тестирования.
✅ Быстрый старт без сложных конфигураций.
❌ Не поддерживает автоматическое масштабирование и самовосстановление контейнеров.
❌ Ограниченные возможности оркестрации.
🏗️ Kubernetes
✅ Масштабируемость и отказоустойчивость из коробки.
✅ Автоматическое управление состоянием контейнеров (перезапуск, балансировка нагрузки).
✅ Гибкость за счет Helm, CRD и сложных политик.
❌ Сложность в настройке и сопровождении.
❌ Требует значительных ресурсов.
💡 Вывод
👉 Docker Compose — лучший вариант для разработки и небольших проектов.
👉 Kubernetes — когда нужна продакшен-инфраструктура, масштабирование и высокая доступность.
Подпишись 👉 @devopslibКак проверить, что твои бэкапы не просто занимают место?
Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?
🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.
🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.
🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.
🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.
🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.
Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!
Подпишись 👉@devopslib
Как мониторить API без лишних затрат?
Мониторинг API – одна из важнейших задач DevOps-инженера. Когда сервис падает, критично знать об этом раньше, чем пользователи начнут жаловаться. Но как организовать мониторинг, не раздувая бюджет и не перегружая систему?
🔹 1. Uptime-мониторинг
Самый простой вариант – проверка доступности API с определённой периодичностью. Можно использовать:
✅ UptimeRobot – бесплатно даёт 50 мониторов с проверками каждые 5 минут.
✅ Zabbix/Prometheus + Blackbox Exporter – кастомный вариант для продвинутых.
✅ AWS CloudWatch Synthetics – если API крутится в AWS, хороший вариант.
🔹 2. Логирование ошибок
Один из ключевых параметров – количество 5xx ошибок. Инструменты:
✅ ELK (Elasticsearch + Logstash + Kibana) – мощно, но требует ресурсов.
✅ Loki + Grafana – отличный лёгкий вариант для Kubernetes.
✅ Sentry – хороший SaaS-вариант для детального анализа ошибок.
🔹 3. Тестирование API-запросов
Хороший мониторинг включает проверку корректности ответов. Можно:
✅ Postman Monitor – запускает запросы по расписанию и валидирует ответы.
✅ New Relic – мощное APM-решение с возможностью трассировки запросов.
✅ k6 + Prometheus/Grafana – скриптуем нагрузочные тесты + метрики.
🔹 4. Определение аномалий в метриках
Используем машинное обучение и продвинутые подходы:
✅ Prometheus + Thanos + Anomaly Detection – ищем неожиданные пики.
✅ Datadog – AI-алгоритмы для обнаружения аномалий в логах.
✅ AWS DevOps Guru – ML-анализ проблем в AWS-инфраструктуре.
Итог
Мониторинг API – это не просто проверка доступности, а комплексная стратегия, включающая логи, трассировку, тестирование и машинное обучение. Выбирайте инструменты под свой стек, чтобы минимизировать время реакции и избежать критических простоев.
Подпишись 👉@devopslib
🔧 Как быстро проверить доступность множества хостов?
Иногда нужно оперативно проверить доступность нескольких серверов. Конечно, можно делать
ping по одному, но это долго и неудобно. Ловите лайфхак на bash, который поможет за секунды проверить целый список хостов.
🖥️ Однострочник для массовой проверки
cat hosts.txt | xargs -I {} -P 10 sh -c 'ping -c 1 {} > /dev/null && echo "{} is up" || echo "{} is down"'
cat hosts.txt — считываем список хостов из файла
- xargs -I {} -P 10 — запускаем до 10 параллельных проверок
- sh -c 'ping -c 1 {} > /dev/null && echo "{} is up" || echo "{} is down"' — выполняем ping, скрываем вывод, пишем статус
📌 Альтернативный вариант на fping:
Если установлен fping, то можно еще быстрее:
fping -q -c1 -t100 < hosts.txt | awk '{print $1, "is up"}'
fping изначально заточен под массовые проверки.
Пользуйся! Надеюсь, сэкономит тебе время 🚀
Подпишись 👉@devopslib🔥 Как управлять хаосом в инфраструктуре?
Каждый DevOps рано или поздно сталкивается с бардаком в инфраструктуре: неконтролируемые деплои, забытые сервисы, баги, которые никто не фиксит. Как с этим бороться?
1️⃣ GitOps — все в коде
Описывай инфраструктуру в Git. Terraform, Ansible, Helm — твои лучшие друзья. Код можно версионировать, откатывать и автоматически применять.
2️⃣ Мониторинг и алерты
Не жди, пока тебе напишут в 3 часа ночи, что "сайт лежит". Prometheus + Grafana + Alertmanager помогут реагировать на проблемы заранее.
3️⃣ CI/CD как обязательный ритуал
Если код не проходит через CI/CD, он не должен попадать в прод. Проверяй тесты, линтеры, сканируй на уязвимости.
4️⃣ Автоматизация и self-healing
Используй Kubernetes с подами, которые перезапускаются при сбоях, или Lambda-функции для автоматического восстановления сервисов.
5️⃣ Документация и коммуникация
Не будь тем, кто на вопрос "как это работает?" отвечает "без понятия". Веди вики, оставляй README и учи коллег пользоваться инструментами.
DevOps — это не про тушение пожаров, а про их предотвращение. Автоматизируй и контролируй хаос, пока он не контролирует тебя! 🚀
Подпишись 👉@devopslib
Оптимизация Docker-образов: 5 правил для DevOps
Docker — это мощный инструмент, но неоптимизированные образы могут съедать ресурсы и замедлять деплой. Вот несколько правил, которые помогут уменьшить размер контейнеров и ускорить их работу.
🚀 1. Используйте lightweight базовые образы
Выбирайте
alpine, distroless или scratch вместо тяжелых ubuntu и debian. Это сэкономит сотни мегабайт.
🔄 2. Минимизируйте количество слоев
Объединяйте команды в RUN, чтобы не создавать лишние слои:
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]
RUN adduser -D myuser
USER myuser
📌Регулярное выражение для поиска и проверки правильных IPv4-адресов
\b(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\b
Разбор регулярного выражения:
• \b – граница слова, чтобы избежать нахождения частей IP-адресов в тексте.
• (25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?) – шаблон для чисел от 0 до 255.
• 25[0-5] — числа от 250 до 255.
• 2[0-4][0-9] — числа от 200 до 249.
• 1?[0-9][0-9]? — числа от 0 до 199 (учитывает 0-9, 10-99, 100-199).
• \. – точка, экранированная \, так как . в регулярных выражениях обозначает любой символ.
• Четыре таких блока, разделенных точками, формируют полный IPv4-адрес.
Пример использования в Python:
import re
pattern = r"\b(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|1?[0-9][0-9]?)\b"
test_ips = ["192.168.1.1", "255.255.255.255", "256.100.50.25", "192.168.300.1", "abc.def.ghi.jkl"]
for ip in test_ips:
if re.fullmatch(pattern, ip):
print(f"{ip} - валидный IPv4")
else:
print(f"{ip} - НЕ валидный IPv4")
Этот код проверяет, какие IP-адреса корректны, а какие нет.
Подпишись 👉@devopslib🔥 Kubernetes: 5 секретных команд, которые спасут тебе нервы
💡 1. Перезапуск всех подов в неймспейсе
Если нужно быстро перезапустить все поды в конкретном неймспейсе:
kubectl delete pods --all -n my-namespace
Completed или Evicted:
kubectl get pods --all-namespaces | grep -E 'Completed|Evicted' | awk '{print $2 " -n " $1}' | xargs -I {} kubectl delete pod {}
kubectl exec -it my-pod -- /bin/sh
distroless`-образ, попробуй `kubectl debug!
💡 4. Слежение за логами всех подов одновременно
Когда нужно посмотреть логи сразу от всех подов в неймспейсе:
kubectl logs --tail=100 -l app=my-app --all-containers -f
kubectl get pod my-pod -o yaml | kubectl apply -f -
