Это репозиторий aws2tf от AWS Samples, предназначенный для автоматического преобразования существующих ресурсов AWS в код Terraform. Он может помочь экспортировать инфраструктуру AWS в виде кода Terraform, что полезно для управления IaC (Infrastructure as Code).
Основные возможности aws2tf:
- Генерация Terraform-кода на основе существующей AWS-инфраструктуры.
- Поддержка множества сервисов AWS.
- Автоматическое создание зависимостей между ресурсами.
- Упрощение миграции и управления конфигурацией.
https://github.com/aws-samples/aws2tf
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Основные возможности aws2tf:
- Генерация Terraform-кода на основе существующей AWS-инфраструктуры.
- Поддержка множества сервисов AWS.
- Автоматическое создание зависимостей между ресурсами.
- Упрощение миграции и управления конфигурацией.
https://github.com/aws-samples/aws2tf
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2❤1🤔1
Docker для начинающих: простое развертывание приложения за несколько шагов
Всем привет! Для своей первой статьи я решил выбрать проблему, с которой сам столкнулся при изучении Java и попытке упаковки приложения в докер-контейнер. К сожалению не нашел ни одной исчерпывающей статьи, как это делать, поэтому решил написать свою.
Начну, пожалуй, с самого сервиса. Я написал достаточно простое веб-приложение на стеке - Java, Spring, Maven, REST, HTTP, Hibernate, Postgresql, JSP/JSTL. Пока приложение представлено достаточно в сыром виде, но для понимания, как оно упаковывается в контейнер, вполне подойдет. Если вкратце, то это сервис для голосования за лучший ресторан, где можно зарегистрироваться, добавить ресторан, его описание, оставить отзыв и проставить рейтинг. Также, в зависимости от роли, можно посмотреть информацию о пользователях и редактировать ее.
https://habr.com/ru/articles/888540/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Всем привет! Для своей первой статьи я решил выбрать проблему, с которой сам столкнулся при изучении Java и попытке упаковки приложения в докер-контейнер. К сожалению не нашел ни одной исчерпывающей статьи, как это делать, поэтому решил написать свою.
Начну, пожалуй, с самого сервиса. Я написал достаточно простое веб-приложение на стеке - Java, Spring, Maven, REST, HTTP, Hibernate, Postgresql, JSP/JSTL. Пока приложение представлено достаточно в сыром виде, но для понимания, как оно упаковывается в контейнер, вполне подойдет. Если вкратце, то это сервис для голосования за лучший ресторан, где можно зарегистрироваться, добавить ресторан, его описание, оставить отзыв и проставить рейтинг. Также, в зависимости от роли, можно посмотреть информацию о пользователях и редактировать ее.
https://habr.com/ru/articles/888540/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍3
SnapScheduler — это контроллер Kubernetes, который автоматически создает снапшоты PVC (PersistentVolumeClaim) по расписанию, используя встроенный механизм
Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.
Как это работает:
Вы создаете ресурс
- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает
Пример использования:
Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом
https://github.com/backube/snapscheduler
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
VolumeSnapshot. Он не зависит от CSI-драйвера, пока тот поддерживает VolumeSnapshot, и работает с любым сторедж-классом, поддерживающим снапшоты.Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.
Как это работает:
Вы создаете ресурс
SnapshotSchedule, в котором указываете:- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает
VolumeSnapshot объекты автоматически.Пример использования:
apiVersion: snapscheduler.backube/v1
kind: SnapshotSchedule
metadata:
name: example-schedule
spec:
schedule: "0 */6 * * *"
snapshotTemplate:
labels:
createdBy: snapscheduler
pvcSelector:
matchLabels:
snapshot: "true"
retention:
maxCount: 5
Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом
snapshot=true, и хранить максимум 5 последних.https://github.com/backube/snapscheduler
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍3
🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?
Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).
Казалось бы, что сложного? Написал
Разберем две крайности и как делать правильно.
❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)
Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.
🔘 Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода.
🔘 Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки.
🔘 Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса.
❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)
Вы решили быть умными и в
🔘 Сценарий: База данных немного приуныла (медленные запросы).
🔘 Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать.
🔘 Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself.
✅ Как делать правильно: Liveness vs Readiness
В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.
1. Liveness Probe (Я жив?)
🔘 Цель: Понять, не завис ли процесс намертво.
🔘 Действие при сбое: РЕСТАРТ контейнера.
🔘 Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться.
2. Readiness Probe (Я готов работать?)
🔘 Цель: Понять, можно ли пускать на меня трафик.
🔘 Действие при сбое: УБРАТЬ из балансировки (не убивать!).
🔘 Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров.
📝 Пример (K8s Manifest):
💡 Главный совет
Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он
#k8s #devops #fails #stability #bestpractices
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).
Казалось бы, что сложного? Написал
curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская.Разберем две крайности и как делать правильно.
❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)
Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.
❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)
Вы решили быть умными и в
/health эндпоинт засунули проверку коннекта к Базе, Редису и S3.✅ Как делать правильно: Liveness vs Readiness
В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.
1. Liveness Probe (Я жив?)
2. Readiness Probe (Я готов работать?)
📝 Пример (K8s Manifest):
livenessProbe:
httpGet:
path: /health/live # Максимально тупой ответ 200 OK
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready # Проверка БД, очередей и т.д.
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
💡 Главный совет
Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он
Ready, или отдавать ошибку юзеру, оставаясь "живым".#k8s #devops #fails #stability #bestpractices
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2
Какую функцию выполняет ReplicaSet?
Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей.
Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений?
Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах.
Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом.
Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером.
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей.
Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений?
Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах.
Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом.
Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером.
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍1
Furiko
Это современный планировщик заданий Kubernetes, созданный с нуля для гибкости, расширяемости и надёжности. Он спроектирован для запуска заданий с различными политиками повторения, управления историей запусков и предоставления пользовательского интерфейса для просмотра и администрирования заданий.
Furiko состоит из следующих компонентов:
- QueueJob Controller: абстракция заданий, которые можно ставить в очередь с масштабируемой логикой запуска.
- CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой.
- Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями.
- CLI: утилита командной строки для взаимодействия с заданиями Furiko.
https://github.com/furiko-io/furiko
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Это современный планировщик заданий Kubernetes, созданный с нуля для гибкости, расширяемости и надёжности. Он спроектирован для запуска заданий с различными политиками повторения, управления историей запусков и предоставления пользовательского интерфейса для просмотра и администрирования заданий.
Furiko состоит из следующих компонентов:
- QueueJob Controller: абстракция заданий, которые можно ставить в очередь с масштабируемой логикой запуска.
- CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой.
- Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями.
- CLI: утилита командной строки для взаимодействия с заданиями Furiko.
https://github.com/furiko-io/furiko
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2❤1🔥1
Устранение проблем с отсутствующими логами Kubernetes в Elasticsearch
Отсутствующие логи могут стать настоящей проблемой для многих пользователей Kubernetes. В этой статье мы разберемся, почему это происходит, и как этого избежать.
Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов.
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Отсутствующие логи могут стать настоящей проблемой для многих пользователей Kubernetes. В этой статье мы разберемся, почему это происходит, и как этого избежать.
Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов.
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2
🛠 Git Cheat Sheet: 12 команд, которые должен знать каждый DevOps
📂 Начало работы
•
•
• Совет: Используйте
🔄 Основной цикл (Commit & Sync)
•
•
•
• Важно:
🌿 Ветвление и слияние
•
•
•
🔍 Диагностика и откат
•
•
•
• ⚠️ Осторожнее с флагом
💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в
#git #devops #cheatsheet #programming #automation
📲 Мы в MAX
Подпишись 👉@i_DevOps
📂 Начало работы
•
git init - создаем новый репозиторий. Помните, что это просто создает скрытую папку .git.•
git remote - связываем локальный код с удаленным сервером (GitHub/GitLab).• Совет: Используйте
git remote -v, чтобы проверить, куда вы пушите код.🔄 Основной цикл (Commit & Sync)
•
git add - добавляем изменения в индекс (staging).•
git commit - фиксируем изменения. Пишите осмысленные сообщения! "Fixed bug" - плохо, "Fix: update nginx config for timeout issue" - хорошо.•
git push / git pull - отправка и получение изменений.• Важно:
git pull - это на самом деле fetch + merge.🌿 Ветвление и слияние
•
git branch - работа с ветками. В DevOps мы часто используем feature-branches.•
git checkout - переключение между ветками. (Кстати, в новых версиях Git для этого чаще используют git switch).•
git merge - объединение веток.🔍 Диагностика и откат
•
git status - ваша любимая команда. Показывает, что происходит прямо сейчас.•
git fetch - забирает данные из репозитория, но не меняет ваш локальный код. Безопасный способ проверить обновления.•
git reset - откат изменений.• ⚠️ Осторожнее с флагом
--hard, он удаляет изменения безвозвратно!💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в
.bashrc или .zshrc. Например:alias gs='git status'alias gl='git log --oneline --graph --all'#git #devops #cheatsheet #programming #automation
📲 Мы в MAX
Подпишись 👉@i_DevOps
🔥4👍3❤1
🔥 Как ускорить docker build и сократить размер образа
Иногда
1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):
Образ получается меньше 10 МБ!
2. Минимизируй base image
Используй
Или вообще:
3. Правильно расставляй
Кешируй слои — сначала зависимости, потом исходники:
Так
4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:
5. Используй
Иначе в билд попадут
Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай —
#devops #docker #ci #optimization
📲 Мы в MAX
Подпишись 👉@i_DevOps
Иногда
docker build тянется вечность, а итоговый образ весит больше, чем база данных 🐘. Разбираемся, как ускорить сборку и оптимизировать размер образа без потери функциональности.1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):
# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app
# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]
Образ получается меньше 10 МБ!
2. Минимизируй base image
Используй
alpine, distroless, scratch, если не нужен полноценный дистрибутив:
FROM python:3.12-slim
Или вообще:
FROM scratch
3. Правильно расставляй
COPY и RUN Кешируй слои — сначала зависимости, потом исходники:
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
Так
pip install не будет повторяться при каждом изменении исходников.4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:
RUN apt-get update && apt-get install -y ... \
&& rm -rf /var/lib/apt/lists/*
5. Используй
.dockerignore Иначе в билд попадут
node_modules, .git, логи и прочее:
.git
node_modules
*.log
Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай —
docker build тоже надо профилировать.#devops #docker #ci #optimization
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍4🔥1
HULL - Helm Uniform Layer Library
Этот репозиторий содержит библиотечную диаграмму Helm под названием HULL. Она предназначена для упрощения создания, поддержки и настройки объектов Kubernetes в Helm-диаграммах и может быть добавлена к любой Helm-диаграмме в качестве дополнения для расширения функциональности без риска нарушения существующих конфигураций Helm.
Сама диаграмма и вся связанная с ней документация находятся в папке
https://github.com/vidispine/hull
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Этот репозиторий содержит библиотечную диаграмму Helm под названием HULL. Она предназначена для упрощения создания, поддержки и настройки объектов Kubernetes в Helm-диаграммах и может быть добавлена к любой Helm-диаграмме в качестве дополнения для расширения функциональности без риска нарушения существующих конфигураций Helm.
Сама диаграмма и вся связанная с ней документация находятся в папке
hull, которая является корневой директорией библиотечной Helm-диаграммы HULL.https://github.com/vidispine/hull
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Cilicon - это приложение для macOS, использующее фреймворк виртуализации Apple для создания, предоставления и запуска эфемерных виртуальных машин CI с производительностью, близкой к нативной. В настоящее время оно поддерживает Github Actions, Buildkite Agent, GitLab Runner и произвольные скрипты.
В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀.
https://github.com/traderepublic/Cilicon
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀.
https://github.com/traderepublic/Cilicon
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍1
CI/CD в 3 раза быстрее: секреты оптимизации GitHub Actions
GitHub Actions - мощный инструмент, но даже продвинутые пайплайны часто работают медленнее, чем могли бы. Потери времени = потери денег и developer experience. Вот как ускорить ваши воркфлоу без потери функциональности.
1. Используйте concurrency и cancel-in-progress
Это позволит отменять старые запуски одного и того же воркфлоу на той же ветке — особенно полезно при пушах в PR. Экономим минуты на каждом коммите.
2. Кешируйте всё, что можно
То же касается node_modules, cargo, .m2, gradle — любые зависимости можно кэшировать, особенно если они скачиваются каждый раз.
3. Не бойтесь matrix + fail-fast: false
Запускайте параллельно всё, что можно: тесты на разных версиях языка, разных ОС, разных архитектурах.
4. Reusable workflows > копипаста
Выносите повторяющиеся шаги в отдельные .yml-воркфлоу и переиспользуйте их через workflow_call. Это упрощает поддержку и уменьшает ошибки.
5. Запускайте воркфлоу только при нужных событиях
Зачем триггерить CI, если изменился только README?
Оптимизация CI/CD - это не про «поиграться с YAML». Это способ сэкономить время команды, ускорить релизы и избежать выгорания из-за бесконечного ожидания. Чем быстрее обратная связь - тем лучше продукт.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
GitHub Actions - мощный инструмент, но даже продвинутые пайплайны часто работают медленнее, чем могли бы. Потери времени = потери денег и developer experience. Вот как ускорить ваши воркфлоу без потери функциональности.
1. Используйте concurrency и cancel-in-progress
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueЭто позволит отменять старые запуски одного и того же воркфлоу на той же ветке — особенно полезно при пушах в PR. Экономим минуты на каждом коммите.
2. Кешируйте всё, что можно
- name: Cache pip packages
uses: actions/cache@v3
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-То же касается node_modules, cargo, .m2, gradle — любые зависимости можно кэшировать, особенно если они скачиваются каждый раз.
3. Не бойтесь matrix + fail-fast: false
Запускайте параллельно всё, что можно: тесты на разных версиях языка, разных ОС, разных архитектурах.
strategy:
matrix:
python-version: [3.10, 3.11]
os: [ubuntu-latest, macos-latest]
fail-fast: false4. Reusable workflows > копипаста
Выносите повторяющиеся шаги в отдельные .yml-воркфлоу и переиспользуйте их через workflow_call. Это упрощает поддержку и уменьшает ошибки.
5. Запускайте воркфлоу только при нужных событиях
on:
push:
branches: [main]
paths:
- 'src/**'
- '.github/workflows/**'Зачем триггерить CI, если изменился только README?
Оптимизация CI/CD - это не про «поиграться с YAML». Это способ сэкономить время команды, ускорить релизы и избежать выгорания из-за бесконечного ожидания. Чем быстрее обратная связь - тем лучше продукт.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍2
Media is too big
VIEW IN TELEGRAM
🚀 Разворачиваем Kubernetes-кластер за 5 минут с помощью Proxmox и k3s!
Автор статьи показывает, как быстро поднять кластер с помощью Proxmox и лёгкого дистрибутива K3s. Всё максимально просто:
- Устанавливаем Proxmox VE
- Создаём шаблон VM с Ubuntu
- Автоматизируем деплой через cloud-init
- Настраиваем кластер K3s в пару кликов
🔥 Идеально для домашней лаборатории или быстрой отладки!
00:04 Introduction
00:18 Why Use Mini PCs Over Cloud Computing for Personal / Hobby Projects
01:13 Installing Proxmox and Setting Up Cluster
02:12 Creating a VM for Kubernetes Worker Node
03:38 Installing Kubernetes on Ubuntu Server
04:14 Joining the New Node to the Kubernetes Cluster
05:19 Potential Applications of Your New Setup
05:30 Upcoming Projects and Channel Focus
06:02 Measuring Power Consumption with a Smart Plug
06:07 Conclusion and Farewell
https://dev.to/mihailtd/set-up-a-kubernetes-cluster-in-under-5-minutes-with-proxmox-and-k3s-2987
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Автор статьи показывает, как быстро поднять кластер с помощью Proxmox и лёгкого дистрибутива K3s. Всё максимально просто:
- Устанавливаем Proxmox VE
- Создаём шаблон VM с Ubuntu
- Автоматизируем деплой через cloud-init
- Настраиваем кластер K3s в пару кликов
🔥 Идеально для домашней лаборатории или быстрой отладки!
00:04 Introduction
00:18 Why Use Mini PCs Over Cloud Computing for Personal / Hobby Projects
01:13 Installing Proxmox and Setting Up Cluster
02:12 Creating a VM for Kubernetes Worker Node
03:38 Installing Kubernetes on Ubuntu Server
04:14 Joining the New Node to the Kubernetes Cluster
05:19 Potential Applications of Your New Setup
05:30 Upcoming Projects and Channel Focus
06:02 Measuring Power Consumption with a Smart Plug
06:07 Conclusion and Farewell
https://dev.to/mihailtd/set-up-a-kubernetes-cluster-in-under-5-minutes-with-proxmox-and-k3s-2987
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍7❤1
🆕 Bun Shell - кроссплатформенный shell прямо в JavaScript
Bun Shell - это встроенный интерпретатор shell-команд в Bun, позволяющий писать скрипты на JavaScript/TypeScript с лаконичным синтаксисом:
Основные возможности:
• Кроссплатформенность: работает на Windows, macOS и Linux.
• Поддержка переменных, редиректов, пайпов и шаблонов.
• Безопасность: автоматическое экранирование переменных.
• Взаимодействие с объектами JavaScript: Response, ArrayBuffer, Blob.
• Встроенные команды: cd, rm, echo и другие.
Пример использования с переменной:
https://bun.sh/blog/the-bun-shell
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Bun Shell - это встроенный интерпретатор shell-команд в Bun, позволяющий писать скрипты на JavaScript/TypeScript с лаконичным синтаксисом:
import { $ } from "bun";
await $`ls *.js`;Основные возможности:
• Кроссплатформенность: работает на Windows, macOS и Linux.
• Поддержка переменных, редиректов, пайпов и шаблонов.
• Безопасность: автоматическое экранирование переменных.
• Взаимодействие с объектами JavaScript: Response, ArrayBuffer, Blob.
• Встроенные команды: cd, rm, echo и другие.
Пример использования с переменной:
const filename = "example.txt";
await $`cat ${filename}`;https://bun.sh/blog/the-bun-shell
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍2
Kubernetes в проде: 7 ошибок, которые совершают даже опытные
Если ты деплоишь сервисы в Kubernetes, скорее всего, ты уже наступал на эти грабли. А если нет — вот чеклист, чтобы не наступить.
1. Не включён
Без этих пробы Kubernetes не понимает, когда перезапустить контейнер или исключить под из сервисов. В итоге — трафик идёт в мёртвые инстансы, а ты ловишь 500-е.
2.
Если не выставить ресурсы, поды будут жрать всё подряд, а kube-scheduler может завалить ноды. Определи baseline и поставь лимиты с запасом:
3. Один
Если у тебя только один реплика, ты не в HA. Любая перезагрузка = даунтайм. Минимум две — лучше три.
4.
5. Нет ограничений по
Без
6. Логи в
Всё, что не идёт в
7. Секреты хранятся в plaintext в Git
Kubernetes
Вывод:
Даже базовые настройки могут сыграть злую шутку, если их игнорировать. Сделай себе шаблон Helm-чарта или Kustomize-паттерн, в котором всё это будет по умолчанию. И не забудь периодически пересматривать best practices — K8s развивается 🔄
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Если ты деплоишь сервисы в Kubernetes, скорее всего, ты уже наступал на эти грабли. А если нет — вот чеклист, чтобы не наступить.
1. Не включён
livenessProbe и readinessProbe Без этих пробы Kubernetes не понимает, когда перезапустить контейнер или исключить под из сервисов. В итоге — трафик идёт в мёртвые инстансы, а ты ловишь 500-е.
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 10
2.
resources.requests и limits не заданы Если не выставить ресурсы, поды будут жрать всё подряд, а kube-scheduler может завалить ноды. Определи baseline и поставь лимиты с запасом:
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
3. Один
replica на под в проде Если у тебя только один реплика, ты не в HA. Любая перезагрузка = даунтайм. Минимум две — лучше три.
4.
latest тег образа image: myapp:latest — это лотерея. K8s не знает, что образ поменялся, и не перезапускает поды. Используй versioned теги (`v1.2.3`) или внедри CI, который автоматически делает новый тег и rollout.5. Нет ограничений по
PodDisruptionBudget Без
PDB можно случайно прибить все поды при drain'е ноды или апдейте. Добавь минимум 1 живой под:
minAvailable: 1
6. Логи в
/var/log или вообще stdout игнорируется Всё, что не идёт в
stdout/stderr, теряется. Используй sidecar'ы или shipper'ы типа Fluent Bit, если хочешь нормальный логинг.7. Секреты хранятся в plaintext в Git
Kubernetes
Secret — это base64, а не шифрование. Либо используй sealed-secrets, либо интеграцию с HashiCorp Vault, SOPS или AWS KMS.Вывод:
Даже базовые настройки могут сыграть злую шутку, если их игнорировать. Сделай себе шаблон Helm-чарта или Kustomize-паттерн, в котором всё это будет по умолчанию. И не забудь периодически пересматривать best practices — K8s развивается 🔄
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
3👍4❤1👎1🔥1
Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON.
Возможности
- Прослушивание изменений в PostgreSQL в режиме реального времени.
- Поддержка нескольких слотов репликации.
- Удобный вывод в формате JSON.
- Готов к использованию в качестве сервиса.
Пример использования
1. Создаём слот репликации:
2. Запускаем wal-listener:
3. Получаем JSON-объекты при изменениях в базе данных.
https://github.com/ihippik/wal-listener
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Возможности
- Прослушивание изменений в PostgreSQL в режиме реального времени.
- Поддержка нескольких слотов репликации.
- Удобный вывод в формате JSON.
- Готов к использованию в качестве сервиса.
Пример использования
1. Создаём слот репликации:
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
2. Запускаем wal-listener:
wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
3. Получаем JSON-объекты при изменениях в базе данных.
https://github.com/ihippik/wal-listener
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
1👍3
Kubernetes: как не угробить прод с неправильными Liveness/Readiness пробыми 🧟♂️
Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness, возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена.
📌 Пробы - не «просто пинги»
-
-
Неправильная настройка может привести к:
- бесконечным перезапускам (flapping),
- недоступности сервиса после деплоя,
- ненужной нагрузке на кластер.
🛠 Типичные ошибки
1. Тот же эндпоинт для обеих проб
Readiness может требовать больше инициализации. Разделяйте эндпоинты:
2. Слишком агрессивные тайминги
3. Тестирование только на dev/stage
На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии.
4. Liveness вместо retries
Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса.
✅ Как делать правильно
- Используйте простые GET-запросы, без heavy логики.
- Не тестируйте зависимости (БД, внешние API) в liveness - пусть это останется за readiness.
- Применяйте
🧩 Стартовый шаблон для readiness/liveness
Вывод: Настройка prob - это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику".
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness, возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена.
📌 Пробы - не «просто пинги»
-
livenessProbe отвечает за "жив ли под". Если не проходит - kubelet убивает контейнер.-
readinessProbe - "готов ли под принимать трафик". Пока не готов - не пускается в сервис.Неправильная настройка может привести к:
- бесконечным перезапускам (flapping),
- недоступности сервиса после деплоя,
- ненужной нагрузке на кластер.
🛠 Типичные ошибки
1. Тот же эндпоинт для обеих проб
Readiness может требовать больше инициализации. Разделяйте эндпоинты:
/healthz/live и /healthz/ready - хорошая практика.2. Слишком агрессивные тайминги
initialDelaySeconds, timeoutSeconds, failureThreshold - не забывайте учитывать холодный старт (особенно при Java, .NET, DB init).3. Тестирование только на dev/stage
На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии.
4. Liveness вместо retries
Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса.
✅ Как делать правильно
- Используйте простые GET-запросы, без heavy логики.
- Не тестируйте зависимости (БД, внешние API) в liveness - пусть это останется за readiness.
- Применяйте
terminationGracePeriodSeconds и preStop hook, чтобы избежать резкого отключения.🧩 Стартовый шаблон для readiness/liveness
livenessProbe:
httpGet:
path: /healthz/live
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet:
path: /healthz/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
Вывод: Настройка prob - это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику".
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
1👍2❤1🔥1
🚀 Ускоряем CI/CD пайплайны на GitHub Actions: кеширование по-взрослому
CI тормозит? Пайплайн гоняет
GitHub Actions — мощный инструмент, но без кеша даже самый простой билд превращается в черепаху. Разберёмся, как грамотно использовать
🔧 Основы кеширования
GitHub предоставляет официальный экшен actions/cache, который позволяет сохранять каталоги между запусками воркфлоу. Ключевое понятие здесь — ключ кеша (cache key).
Пример:
Что тут происходит:
-
-
-
⚡ Трюки для ускорения
1. Разделяй кеш по задачам. Не пихай всё в один архив. Кешируй отдельно
2. Для Docker-образов — кешируй слои. Используй BuildKit и флаг
3. Осторожно с ключами. Часто меняющийся ключ = каждый раз новый кеш = медленно. Сделай разумный баланс между стабильностью и свежестью.
4. Тестируй локально. Используй act, чтобы отлаживать воркфлоу на локалке — сэкономишь время и нервы.
✅ Вывод
Кеш в GitHub Actions — не волшебная пуля, но при правильной настройке он может сократить время CI в разы. Следи за размером кеша, обновляй ключи с умом и профилируй пайплайн. И не забывай: кеш — твой друг, пока ты его контролируешь.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
CI тормозит? Пайплайн гоняет
npm install по 5 минут? Пора серьёзно поговорить о кешировании в GitHub Actions.GitHub Actions — мощный инструмент, но без кеша даже самый простой билд превращается в черепаху. Разберёмся, как грамотно использовать
actions/cache, чтобы выжать максимум скорости.🔧 Основы кеширования
GitHub предоставляет официальный экшен actions/cache, который позволяет сохранять каталоги между запусками воркфлоу. Ключевое понятие здесь — ключ кеша (cache key).
Пример:
- uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
Что тут происходит:
-
path — папка, которую кешируем (`~/.npm`).-
key — уникальный ключ, зависящий от lock-файла.-
restore-keys — запасной вариант, если точного совпадения ключа нет.⚡ Трюки для ускорения
1. Разделяй кеш по задачам. Не пихай всё в один архив. Кешируй отдельно
npm, node_modules, dist/ — это гибко и эффективно.2. Для Docker-образов — кешируй слои. Используй BuildKit и флаг
--cache-to, --cache-from. Пример:
- name: Build Docker image
run: |
docker buildx build \
--cache-from=type=gha \
--cache-to=type=gha,mode=max \
-t my-app .
3. Осторожно с ключами. Часто меняющийся ключ = каждый раз новый кеш = медленно. Сделай разумный баланс между стабильностью и свежестью.
4. Тестируй локально. Используй act, чтобы отлаживать воркфлоу на локалке — сэкономишь время и нервы.
✅ Вывод
Кеш в GitHub Actions — не волшебная пуля, но при правильной настройке он может сократить время CI в разы. Следи за размером кеша, обновляй ключи с умом и профилируй пайплайн. И не забывай: кеш — твой друг, пока ты его контролируешь.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍4
💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.
McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.
• Поддерживает:
- Bash
- Zsh
- Fish
• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.
• Установка:
Доступен через Homebrew, AUR, Nix и другие.
https://github.com/cantino/mcfly
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.
• Поддерживает:
- Bash
- Zsh
- Fish
• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.
• Установка:
Доступен через Homebrew, AUR, Nix и другие.
https://github.com/cantino/mcfly
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
🔥3👍2❤1
Трюки для ускорения Docker-образов на проде
Контейнеры это сердце современных приложений. Но тяжёлые образы = медленные деплои и высокие затраты. Как ускорить образы без боли?
Мультистейдж билды - must have
Используй multi-stage builds, чтобы собрать приложение в одном контейнере, а продакшн-образ сделать минимальным:
Минимизируй базовые образы
Выбирай облегчённые базовые образы:
- alpine вместо ubuntu
- distroless для максимальной безопасности и минимального веса
Оптимизируй порядок слоёв
Чем выше изменяемость, тем ниже слой:
- Сначала COPY go.mod, npm package.json, установка зависимостей
- Потом COPY . . с кодом проекта
Это позволяет кэшировать большую часть слоёв даже при частых изменениях кода.
Чисть за собой
Всегда удаляй временные файлы и зависимости для сборки:
Сжимай образы
Используй docker-slim, он автоматически оптимизирует образ, удаляя всё ненужное:
Как применять и чего избегать
- В продакшне старайся держать образы <100MB
- Не добавляй лишние пакеты “на всякий случай”
- Проверяй образы на уязвимости: trivy image your-app:tag
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Контейнеры это сердце современных приложений. Но тяжёлые образы = медленные деплои и высокие затраты. Как ускорить образы без боли?
Мультистейдж билды - must have
Используй multi-stage builds, чтобы собрать приложение в одном контейнере, а продакшн-образ сделать минимальным:
# Сборка
FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app
# Продакшн
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/app .
CMD ["./app"]Минимизируй базовые образы
Выбирай облегчённые базовые образы:
- alpine вместо ubuntu
- distroless для максимальной безопасности и минимального веса
Оптимизируй порядок слоёв
Чем выше изменяемость, тем ниже слой:
- Сначала COPY go.mod, npm package.json, установка зависимостей
- Потом COPY . . с кодом проекта
Это позволяет кэшировать большую часть слоёв даже при частых изменениях кода.
Чисть за собой
Всегда удаляй временные файлы и зависимости для сборки:
RUN apt-get install -y build-essential && \
make build && \
apt-get remove --purge -y build-essential && \
apt-get autoremove -y && \
apt-get cleanСжимай образы
Используй docker-slim, он автоматически оптимизирует образ, удаляя всё ненужное:
docker-slim build --http-probe my-app:latestКак применять и чего избегать
- В продакшне старайся держать образы <100MB
- Не добавляй лишние пакеты “на всякий случай”
- Проверяй образы на уязвимости: trivy image your-app:tag
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3❤1🔥1