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 #девопс

🛠 25+ FTP-вопросов для собеседований: разбор с ответами

Если ты DevOps-инженер, системный администратор или сетевой специалист, то протокол FTP (File Transfer Protocol) тебе наверняка знаком. На собеседованиях часто задают вопросы по его устройству, безопасности и конфигурации. Команда Tecmint собрала ключевые FTP-вопросы с ответами, которые стоит выучить. Вот основные из них:

🔹 Что такое FTP?
File Transfer Protocol — это стандартный сетевой протокол, используемый для передачи файлов между клиентом и сервером по TCP/IP.

🔹 На каких портах работает FTP?
По умолчанию:
• Порт 21 — управляющее соединение
• Порт 20 — передача данных (в активном режиме)

🔹 Чем отличается активный и пассивный режим FTP?
В активном режиме сервер инициирует соединение для передачи данных, в пассивном — клиент сам подключается к случайному порту сервера.
💡 Пассивный режим чаще используют за NAT/фаерволами.

🔹 Что такое анонимный FTP?
Это доступ к FTP-серверу без пароля (обычно используется anonymous или ftp в качестве логина). Часто применяется для публичных загрузок.

🔹 Какие популярные FTP-серверы в Linux?
• vsftpd
• proftpd
• Pure-FTPd

🔹 Как обеспечить безопасность FTP?
Обычный FTP передаёт данные в незашифрованном виде. Для защиты используют:
• FTPS (FTP over SSL/TLS)
• SFTP (через SSH) — это вообще другой протокол
Также: ограничение по IP, chroot jail, шифрование паролей, запрет анонимного доступа.

🔹 Различия между FTP и SFTP?
• SFTP работает через SSH (порт 22)
• Обеспечивает полное шифрование
• Безопаснее, но несовместим с обычными FTP-клиентами

🔹 Какие команды FTP стоит знать?
• get, put — загрузка и выгрузка
• ls, cd, pwd, mget, mput
• passive / active — переключение режима

🔹 Как ограничить пользователя FTP в своём каталоге?
Через chroot jail: chroot_local_user=YES в vsftpd.conf

🔹 Как протестировать FTP-сервер?
Можно использовать:
• ftp (CLI)
• lftp — продвинутый CLI
• GUI-клиенты: FileZilla, WinSCP

📚 Все 25+ вопросов с ответами ты найдёшь тут → https://www.tecmint.com/ftp-interview-questions-and-answers/

⚙️ Отличный чеклист для подготовки к собеседованию или аудиту инфраструктуры!

#FTP #DevOps #Linux #Собеседование #Sysadmin #SFTP #Безопасность


@devopsitsec

🧩 DevOps-задача с подвохом: всё работает, но тормозит

У вас в Kubernetes кластере работает микросервис orders. Всё "зелёное":
- ✅ нет ошибок 5xx
- ✅ логи чистые
- ✅ CPU и RAM в норме
- ✅ Pod'ы не рестартятся
- ✅ HPA не срабатывает

Но пользователи жалуются: ⚠️ заказы проходят с задержкой до 1.5 сек.

🔍 Что под капотом:
- 3 реплики orders
- Зависимость: inventory (всего 1 реплика)
- Один из `orders`-подов иногда теряет сетевое соединение на ~30 сек
- Readiness-проба — /healthz, всегда 200 OK
- HPA срабатывает только по CPU > 80%
- Есть метрика queue_size, но она нигде не используется


🎯 Что происходит?
Kubernetes считает проблемный под "живым", потому что /healthz отвечает.
Но этот под не может достучаться до inventory.
Часть трафика уходит в никуда и тормозит.

CPU низкий, ошибок нет — HPA не срабатывает.
Проблема остаётся невидимой, пока пользователи страдают.


✅ Как починить:

1. ✂️ **Проверять зависимости в Readiness:**
```yaml
readinessProbe:
exec:
command: ["sh", "-c", "curl -sf http://inventory/healthz || exit 1"]
```

2. 📈 **Добавить алерты на latency, queue size и gRPC ошибки**

3. ⚖️ **Настроить HPA по бизнес-метрикам:**
```yaml
type: External
metric:
name: queue_size
```

4. 🧬 **Добавить 2+ реплики в `inventory`** — избавляемся от SPOF

5. 🧠 **Включить tracing (например, Jaeger)** для отслеживания зависаний

💡 **Урок:** Даже без ошибок система может работать нестабильно.
DevOps-инженер должен уметь **видеть деградацию до того, как её заметит пользователь.**

#DevOps #Kubernetes #SRE #Monitoring #CI_CD #HPA

Полезная таблица инструментов DevSecOps

Если ты учишься с нуля, устраняешь пробелы или заменяешь существующие инструменты, начни с Периодической таблицы, чтобы подобрать оптимальные решения для своей DevOps-пайплайна.

#devops #девопс

@devopsitsec

🚀 Sneak Peek: Что нового в Kubernetes v1.34

Официальный блог уже поделился предварительным обзором релиза!
Что ждать от Kubernetes 1.34?

🔹 Новый API для runtime класса (RuntimeClass v1 GA)
🔹 Оптимизация pod scheduling и NUMA-архитектуры
🔹 Стабилизация нескольких ключевых фич
🔹 Улучшения в kubelet и kube-proxy
🔹 Больше прозрачности в контроллерах

🛠️ Полный обзор от команды Kubernetes:
https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek/

#Kubernetes #DevOps #CloudNative

💡 Продвинутый совет для Linux-админов:
Хочешь узнать, какие процессы используют больше всего памяти (включая shared libraries, кэш и swap) — но не по PID, а по исполняемому бинарнику?

Вот способ сгруппировать потребление памяти по программам, а не по процессам.

sudo ps -e -o pid,comm --no-headers | while read pid cmd; do  
  grep -q "^Name:\s\+$cmd$" /proc/$pid/status 2>/dev/null &&  
  awk '/^RssAnon:/ {rss+=$2} END {if (rss) printf "%s %d MiB\n", "'$cmd'", rss/1024}' /proc/$pid/status  
done | sort -k2 -nr | uniq  

📊 Использование RAM по исполняемым программам (не PID)

📌 Отлично подходит для выявления прожорливых демонов, особенно если у вас десятки fork-процессов одного сервиса.

#linux #memory #admin #devops #monitoring

💡 Ещё один продвинутый совет для Linux-админов:
Проверь, какие процессы активно используют swap — даже если в системе вроде бы хватает RAM.

Это поможет найти медленные службы, которые вы не ожидали увидеть в свопе, и улучшить производительность.

for pid in $(ls /proc | grep -E '^[0-9]+$'); do  
  cmd=$(cat /proc/$pid/comm 2>/dev/null)  
  swap=$(grep VmSwap /proc/$pid/status 2>/dev/null | awk '{print $2}')  
  if [ "$swap" != "" ] && [ "$swap" -gt 0 ]; then  
    echo "$swap KB swap used by $cmd (PID $pid)"  
  fi  
done | sort -nr | head  

🐌 Процессы, активно использующие swap (swap hog detector)

📌 Даже если swap включен "про запас", вы удивитесь, сколько "вроде бы активных" сервисов частично выгружены на диск — отсюда тормоза, задержки в API, медленные реакции.

Решения:
– пересмотреть vm.swappiness
– перезапустить эти процессы
– увеличить RAM или выделить hugepages

#linux #performance #swap #memory #sysadmin #devops

🐧 Быстрый Linux совет

Нужно повторять команду каждые несколько секунд?

Используй:
$ watch -n 2 df -h

Эта команда запускает df -h каждые 2 секунды.
Удобно для контроля за диском, нагрузкой или изменением логов.

Нажми q, чтобы выйти.

#Linux #DevOps #Tips

🚀 Git Pro совет

Хотите быстро узнать, какие файлы или папки в репозитории занимают больше всего места?
Используйте встроенную команду git вместе с rev-list и objects:

# Самые большие файлы в истории репозитория

git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  grep '^blob' | \
  sort -k3nr | head -10

💡 Это помогает найти «тяжёлые» файлы, случайно закоммиченные в историю (например, большие датасеты или бинарники).
После нахождения ненужного файла можно использовать git filter-repo или BFG Repo-Cleaner, чтобы очистить историю и уменьшить размер репозитория.

#DevOps #Tips #git

📌 Git Revert vs Git Reset: В чём разница? 🔄

Когда вы делаете ошибку в Git, важно понимать, как правильно её исправить. Два самых популярных способа — git revert и git reset. Но они работают по-разному!

### 🔹 Git Revert
- Создаёт новый коммит, который отменяет изменения из проблемного коммита.
- История сохраняется полностью — всё видно, даже ошибка.
- Безопасный вариант для публичных веток (например, `main`).
- Не удаляет коммиты — просто "откатывает" их эффект.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C4: Revert C3
> Результат: ошибка отменена, но история остаётся полной.

🔹 Git Reset
- Удаляет коммит(ы) из истории.
- Изменяет историю репозитория — может быть опасно, если уже был пуш.
- Подходит только для локальных изменений или ещё не опубликованных коммитов.
- Есть три режима: soft, mixed, hard.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C3 убрано
> Результат: история обрезана, как будто коммит никогда не был.

💡 Вывод:
revert — безопасный и прозрачный способ отменить изменения.
reset — мощный инструмент, но требует осторожности.

📌 Понимание этих команд — ключ к уверенной работе с Git!

#Git #DevOps #Programming #SoftwareEngineering

Timeweb Cloud запустил агентов, совместимых с OpenAI

Провайдер сделал то, что может всерьез упростить жизнь разработчикам и девопсам — персональных агентов с OpenAI‑совместимым API. Это значит, что к агентам можно легко подключить готовые программы. Например, Cursor — умный редактор кода. А благодаря RAG получится собственный код-ассистент, обученный на внутренней документации, мануалах и кодовой базе компании.

Как это работает

1. Создаете агента в панели управления
2. Загружаете в базу знаний свои данные – документацию, стандарты кодирования, конфиги, мануалы по деплою. А дальше просто подключаете базу к агенту
3. Получаете API-эндпоинт совместимый с OpenAI
4. Подключаете агента к любому инструменту из экосистемы готовых решений Все, теперь AI-эксперта можно встроить прямо в вашу IDE и рабочий процесс.

Что под капотом

● Технология RAG: агент не просто болтает, а ищет ответы в предоставленных вами материалах, что гарантирует релевантность и точность
● Выбор моделей: от экономной GPT-4.1 nano до мощной GPT-5. Можно также подключить DeepSeek, Claude, Grok или Gemini
● Предсказуемый биллинг: оплата только за токены, пакеты обновляются каждый месяц

Как итог — не нужно самим поднимать, обучать и поддерживать инфраструктуру для корпоративного AI. Можно получить своего код-помощника за несколько кликов, не покидая привычную среду разработки.

Настроить своего агента

#devops #ai #openai #api #timewebcloud

📌 20 ключевых навыков для Linux-администратора

Если хочешь уверенно работать с Linux в DevOps/инфраструктуре — вот карта, по которой можно идти:

— Командная строка: cd, ls, ps, top, tmux, ssh
— Права и пользователи: chmod, chown, группы, sudo
— SSH-ключи и безопасность доступа
— Firewall: iptables, ufw
— Резервные копии: rsync, cron
— Bash/Python скриптинг для автоматизации
— Package managers: apt, yum, dnf
— Network troubleshooting: ping, traceroute, netstat, ss, ip
— Процессы: ps, top, systemd
— Диски: df, du, fdisk, LVM
— Git и контроль версий
— Контейнеры: Docker, Podman + основы Kubernetes
— Конфигурационное управление: Ansible, Puppet, Chef
— Облака: AWS/Azure/GCP
— CI/CD: Jenkins, GitLab CI, GitHub Actions
— Мониторинг: Prometheus, Grafana, ELK
— IaC: Terraform, CloudFormation
— Оркестрация: Kubernetes, Docker Swarm
— Сертификации: AWS, RHCE, CKA
— Постоянное обучение и практика

Linux — это фундамент для DevOps, SRE и облачной инфраструктуры.
Освой базу, автоматизируй рутину и прокачивайся каждый день 🚀

#linux #devops #sysadmin #infrastructure #cloud

7 бесплатных ресурсов, чтобы прокачаться в Linux и DevOps 👇

1) Bash → blog.sysxplore.com
2) Linux → linuxopsys.com
3) AWS → explore.skillbuilder.aws
4) Azure → learn.microsoft.com
5) DevOps → edx.org/learn/devops
6) Docker → docker-curriculum.com
7) Kubernetes → kubernetes.io

Фундамент DevOps = Linux + Shell + облака + контейнеры + оркестрация.
Начни с базиса — дальше всё соберётся.

#linux #devops #cloud #docker #kubernetes