💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.

McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.

• Поддерживает:
- Bash
- Zsh
- Fish

• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.

• Установка:
Доступен через Homebrew, AUR, Nix и другие.

https://github.com/cantino/mcfly

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Трюки для ускорения Docker-образов на проде

Контейнеры это сердце современных приложений. Но тяжёлые образы = медленные деплои и высокие затраты. Как ускорить образы без боли?

Мультистейдж билды - 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

Bruno — это новый, современный и удобный инструмент для работы с API. В отличие от Postman и аналогов, Bruno хранит все данные локально в виде обычных файлов и папок, что позволяет легко версионировать их с помощью Git.

Основные особенности:
- Локальное хранение данных без облака
- Полная совместимость с Git
- Высокая производительность и минималистичный интерфейс
- Открытый исходный код

https://github.com/usebruno/bruno

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀

GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.


Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.


1. Кэшируй разумно
Используй actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.


2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй needs: там, где реально нужно, а не везде.


3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй matrix:

strategy:
  matrix:
    node-version: [16, 18, 20]

Это масштабирует проверку без дублирования кода.


4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй on: грамотно:

on:
  push:
    branches:
      - main
  pull_request:
    paths:
      - 'src/**'

Это поможет не перегружать runners.


5. Используй workflow_dispatch для ручных запусков
Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:

on:
  workflow_dispatch:

6. Логи и таймауты — твои друзья
Добавляй timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли.


Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

🚨 Helm: как не сломать прод — 5 ошибок, которые делают все

Helm — must-have инструмент для деплоя в Kubernetes. Но даже опытные инженеры наступают на одни и те же грабли, особенно в проде. Разберём, какие ошибки чаще всего приводят к падениям и багам.


🔸 1. helm upgrade без флага --atomic
Без --atomic Helm не откатывает релиз при ошибке — в кластере остаётся полусломанное состояние.
Решение: всегда используйте --atomic на проде:

helm upgrade my-app ./chart --atomic --install

🔸 2. Забытый values.yaml с тестовыми значениями
Нередко инженеры коммитят values.yaml с включёнными debug-логами, выключенным HPA и отключённым SSL.
Решение:

* Разделяй values по окружениям (values-prod.yaml, values-staging.yaml)
* Используй .gitignore для временных файлов
* Применяй валидацию с helm-schema-gen

🔸 3. Не pinned зависимости в Chart.yaml
Если чарты-зависимости подтягиваются без фиксации версий (version: ^1.2.3), то обновления могут неожиданно всё сломать.
Решение:
Фиксируй зависимости чётко: version: 1.2.3 и контролируй обновления вручную.

🔸 4. Отсутствие pre-upgrade и post-upgrade хуков
Если приложение требует миграций БД или прогрева кэша, а хуки не заданы — велика вероятность получить нерабочий релиз.
Решение:
Определи хуки в templates/hooks.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  annotations:
    "helm.sh/hook": pre-upgrade

🔸 5. Helm secrets хранятся в чистом виде в Git
Распакованный secrets.yaml в Git — это инцидент.
Решение:

* Используй helm-secrets с sops
* Шифруй secrets.yaml и расшифровывай только при деплое:

helm secrets upgrade my-app -f secrets.enc.yaml

✅ Вывод:
Helm — мощный, но не прощающий ошибок инструмент. Настрой atomic деплой, следи за values и зависимостями, автоматизируй pre/post-хуки и защищай секреты. Это минимальный чеклист для прод-готовности.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Netshoot — набор инструментов для устранения сетевых проблем с Docker и Kubernetes.

Отладка сетей Docker и Kubernetes может быть сложной. Однако при правильном понимании принципов работы сетей Docker и Kubernetes, а также наличии подходящих инструментов, вы сможете эффективно выявлять и устранять сетевые проблемы. Контейнер netshoot включает в себя мощный набор инструментов для диагностики сетевых проблем в Docker. Вместе с этими инструментами идут практические примеры, демонстрирующие, как netshoot можно использовать в реальных сценариях.

https://github.com/nicolaka/netshoot

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Crd-to-sample-yaml or cty ( city )

Утилита для генерации манифестов YAML из CRD.

Это простая утилита, написанная на Go, которая читает CRD-файлы и создает из них YAML-образцы.

Она использует controller-tools/pkg/crd/schema и controller-tools/pkg/crd/markers для интерпретации и разбора схемы.

Установка:

go install github.com/Skarlso/crd-to-sample-yaml@latest

Использование:

crd-to-sample-yaml -path ./path/to/crds > output.yaml

https://github.com/Skarlso/crd-to-sample-yaml

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

💡 Как DevOps'у не утонуть в логах

Когда в продакшене случается затык, первое, что мы делаем - лезем в логи. Но с микросервисами, десятками подов и различными компонентами инфраструктуры, логов становится столько, что можно утонуть.

Вот несколько проверенных приёмов, которые реально спасают время:

🔹 Стандартизируй формат логов. JSON - твой друг. Структурированные логи можно парсить, фильтровать и индексировать.

🔹 Сразу думай про central logging. Loki + Grafana, Elasticsearch + Kibana или даже простой Fluent Bit + S3. Главное - не SSH на 20 серверов.

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

🔹 Фильтры, фильтры, фильтры. Хорошие правила фильтрации в Grafana или Kibana - это как хороший кофе с утра. Делают день лучше.

🔹 Логи - это не помойка. Не пиши туда print("Hello from service X"). Пиши полезное: ошибки, статусы, идентификаторы.

И напоследок: не забывай про ротацию и retention. Логи не должны жить вечно, особенно если ты не хочешь платить лишнее за storage.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

🔧 Про grep, который умеет больше, чем ты думаешь

Все знают grep как утилиту “найди мне это слово в этих логах”. Но давай копнём глубже — вот тебе пара трюков, которые удивят даже видавшего виды девопса:


📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?

grep -C 3 "ошибка" /var/log/syslog

Покажет 3 строки до и после найденной.


📍 Ищем по слову, а не по вхождению
Не хочешь ловить ошибка, если в логе есть предошибкака?

grep -w "ошибка" файл.log

Совпадение только по целому слову.


📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:

grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' лог.txt

📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:

grep -rIn --exclude-dir={.git,node_modules} "TODO" .

📍 Цвет для глаз
Визуально быстрее цепляться за результат:

grep --color=auto "fail" журнал.log

Если ты думаешь, что grep — это просто "найди слово", то, возможно, ты не используешь весь его потенциал. А зря 😉

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Как проверить, что твои бэкапы не просто занимают место?

Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?

🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.

🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.

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

🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.

🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.

Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps