#основыDevOps

Сетевые утилиты в Linux

Сеть в Linux можно проверять и диагностировать десятками способов, но эти 4 утилиты — базовый «джентльменский набор».

1️⃣ ping — жив ли хост?

Команда отправляет специальные пакеты (ICMP Echo Request) и ждёт ответ (Echo Reply).

Пример:

ping ya.ru

Что покажет:
🟣 работает ли хост вообще,

🟣 через какое время приходят ответы (latency, задержка),

🟣 сколько пакетов потерялось.

Полезно, если нужно быстро понять:

«а он вообще жив?»

2️⃣ netstat — кто и куда подключён

Старая, но до сих пор встречающаяся утилита.

Пример:

netstat -tulnp

Флаги:

-t — TCP

-u — UDP

-l — слушающие порты

-n — показывать IP и порты цифрами (без DNS-имен)

-p — показать, какой процесс держит порт

🔜 Можно увидеть: «у меня nginx слушает 80-й порт» или «ой, у меня какой-то непонятный процесс висит на 12345».


3️⃣ ss — современный netstat

ss делает то же самое, что netstat, только быстрее и с большим количеством деталей.

Пример:

ss -tulnp

Почти те же флаги, но вывод чище.

Ещё пример:

ss -s

Покажет краткую статистику соединений (сколько TCP/UDP активных, закрытых и т.п.).

🔜 Если привык к netstat, переходи на ss.


4️⃣ tcpdump — что реально летает по сети

Самая мощная из этих утилит. Она перехватывает сетевые пакеты и показывает их содержимое.

Пример:

tcpdump -i eth0 port 80

Здесь:

⏩-i eth0 — интерфейс (обычно eth0, ens33, wlan0)

⏩port 80 — фильтр (смотрим только трафик на 80-й порт)

Можно поймать пакеты и сохранить в файл:

tcpdump -i eth0 -w dump.pcap

А потом открыть в Wireshark для удобного анализа.

🔜 Используется для диагностики, отладки сервисов и даже расследования атак.


✅ Итого:

ping — проверить, жив ли хост и какая задержка

netstat — старый способ посмотреть порты и соединения

ss — новый и быстрый способ

tcpdump — сниффер пакетов, полная картинка сетевого трафика

#devops #linux #network

#основыDevOps

Настройка сервисов: systemd, cron, journalctl

📌В Linux всё крутится вокруг сервисов и планировщиков. Если знать три инструмента — systemd, cron и journalctl, то можно управлять почти всей жизнью сервера.


systemd — повелитель процессов

systemd — это главный диспетчер, который запускает сервисы и следит, чтобы они не падали.

Запустить сервис:

systemctl start nginx

Остановить:

systemctl stop nginx

Включить автозапуск при старте системы:

systemctl enable nginx

Посмотреть статус:

systemctl status nginx

📎 Помни: systemd — это сердце Linux, без него никуда.



cron — планировщик дел

cron — это твой личный секретарь. Он делает задачи по расписанию: бэкапы, чистки логов, скрипты.

Файл расписаний:

crontab -e

Формат:

минуты часы день_месяца месяц день_недели команда

Примеры:

Каждый день в 3 ночи:

0 3 * * * /usr/bin/backup.sh

Каждую минуту (для теста):

* * * * * echo "Живой!"

journalctl — лупа для логов

Все, что делают сервисы под крылом systemd, пишется в журнал.

Логи конкретного сервиса:

journalctl -u nginx

Последние записи (режим tail):

journalctl -u nginx do

Логи после перезагрузки:

journalctl b

📎 Это твой главный друг, когда что-то не запускается.


⏩ В связке они работают так:

systemd запускает сервисы,

cron автоматизирует задачи,

journalctl помогает разобраться, почему всё сломалось

#devops #Linux #cmd

#основыDevOps

Настройка сервисов в Linux: systemd, cron, journalctl

В любой системе есть три вещи, без которых жить сложно:
🟢 сервисы, которые должны работать стабильно,
🟢задачи, которые надо выполнять по расписанию,
🟢логи, где видно, что пошло не так.

И вот тут на помощь приходят systemd, cron и journalctl.


🔜 systemd — главный диспетчер сервисов.

Команды:

systemctl start nginx — запустить сервис
systemctl stop nginx — остановить
systemctl enable nginx — запускать при старте системы
systemctl status nginx — посмотреть состояние

👉 Если сервис падает, то именно через systemd можно настроить автоперезапуск (Restart=always в юните).


🔜 cron — планировщик задач.

Нужно запускать скрипт каждый день в 3 ночи? Пиши в crontab:

0 3 * * * /usr/bin/python3 /home/user/backup.py 

⏰ Формат расписания:
минуты часы день_месяца месяц день_недели команда


🔜 journalctl — просмотр логов.

Все события systemd пишутся сюда

journalctl -u nginx — логи конкретного сервиса
journalctl -f — “хвост” логов в реальном времени
journalctl --since "1 hour ago" — события за последний час

✔️ Итог:

systemd = управление сервисами
cron = автоматизация по времени
journalctl = быстрый доступ к логам

❗️Зная эти три инструмента, ты уже на голову выше обычного пользователя Linux

#SuperGuides

PowerShell vs CMD: что реально нужно DevOps?

Многие, кто впервые сталкивается с Windows-администрированием, открывают чёрное окошко CMD и думают: «Ну вот, как в Linux — терминал, только с другой стороны».
Но на самом деле всё немного сложнее.


😕 CMD

Это пережиток прошлого. По сути, командная оболочка с минимальным набором возможностей: запустить exe, пройтись по каталогам, что-то скопировать. Скрипты на .bat — боль и страдание, особенно если ты привык к удобству bash.
CMD нужен только в редких случаях, когда запускается какой-то очень старый софт или скрипт.


🐈 PowerShell

А вот тут начинается магия. PowerShell — это не просто командная строка, это полноценный объектно-ориентированный шелл.

🟣В отличие от CMD, который возвращает текст, PowerShell работает с объектами. Это значит, что можно легко фильтровать, парсить и обрабатывать данные без костылей.

🟣Встроенные команды называются cmdlets — и их очень много: для работы с файлами, реестром, сетевыми настройками, процессами, сервисами.

🟣Есть поддержка модулей, автодополнение и интеграция с .NET — всё, что нужно для автоматизации.


❓ А что DevOps?

Если ты работаешь с инфраструктурой, CI/CD и автоматизацией — забудь про CMD.
PowerShell — это:
⏩автоматизация развертывания и конфигураций на Windows,
⏩работа с Azure и облаками (есть отдельные модули),
⏩кроссплатформенность (есть PowerShell Core, который работает и на Linux, и на macOS).

По сути, PowerShell для Windows — это то же, чем Bash является для Linux. А CMD — просто исторический багаж.

✔️Вывод:

Если хочешь быть настоящим DevOps, учить PowerShell must-have. А CMD пусть останется для дедов на галере.

#основыDevOps

Автоматизация задач в Windows через PowerShell: топ-20 команд

❗️ PowerShell — это не просто «терминал для Windows». Это мощный инструмент для автоматизации рутинных задач: от управления файлами и сервисами до работы с планировщиком и журналами событий.

👇Ниже я собрал 20 команд, которые помогут тебе почувствовать силу PowerShell.

# 1. Получить справку по команде
Get-Help Get-Process -Full     

# 2. Найти все доступные команды
Get-Command                    

# 3. Список сервисов
Get-Service                    

# 4. Запустить сервис
Start-Service -Name spooler    

# 5. Остановить сервис
Stop-Service -Name spooler     

# 6. Перезапустить сервис
Restart-Service -Name spooler  

# 7. Список процессов
Get-Process                    

# 8. Завершить процесс по имени
Stop-Process -Name notepad     

# 9. Последние 20 событий из системного журнала
Get-EventLog -LogName System -Newest 20  

# 10. Показать файлы и папки (аналог dir)
Get-ChildItem                  

# 11. Скопировать файл
Copy-Item C:\file.txt D:\backup  

# 12. Переместить файл или папку
Move-Item C:\old D:\new        

# 13. Удалить файлы (например, логи)
Remove-Item C:\temp\*.log      

# 14. Создать новый файл
New-Item -ItemType File test.txt  

# 15. Проверить сеть (аналог ping)
Test-Connection google.com     

# 16. Прочитать содержимое файла
Get-Content file.txt           

# 17. Перезаписать файл текстом
Set-Content file.txt "Hello"   

# 18. Добавить строку в конец файла
Add-Content file.txt "New line"

# 19. Список задач планировщика
Get-ScheduledTask              

# 20. История команд
Get-History

✔️ Итог:
Эти 20 команд закрывают 80% базовых задач по автоматизации Windows:
⏩управление сервисами и процессами
⏩работа с файлами
⏩анализ логов
⏩сетевые проверки
⏩задачи по расписанию.

PowerShell = автоматизация + контроль

Удаленка в IT: рай или западня?

Когда-то мы мечтали: «Ах, если бы работать из дома, в пижамке, с котом и без этого дурацкого офиса…»
Я всю свою IT-карьеру работаю на удаленке и хочется рассказать, что это не только удобный стол и «работаю из любой точки мира», но и куча подводных камней.

🐈 Ну и сначала хочется начать с плюсов:
⏩Нет дороги до офиса. Твои 2 часа жизни в день снова твои. Можно спать, можно кодить, можно скролить рилсы или тик-ток.
⏩Работать хоть с Бали, хоть с дивана. Главное — интернет, а дальше все упирается только в фантазию
⏩Гибкость. У кого-то пик продуктивности в 6 утра, у кого-то — в 2 ночи. Удалёнка позволяет работать «под себя». Есть конечно нюансы с созвонами, но все решаемо.
⏩Более удобно совмещать с учебой. Я параллельно с работой учусь в университете. И я вообще не представляю, как я совмещал бы эту историю с офисом.

На этом этапе можно подумать, что удалёнка - это плюс вайб, но не все так просто!

🥲Минусы удаленки:
⏩Дом превращается в работу. И иногда это невыносимо, потому что ты спишь, ешь и учишься "на работе"
⏩Социализация. Никакой зум звонок не заменит реального общения. С удаленкой иногда получается, что за неделю ни разу не выходил из дома)
⏩Прокрастинация. В офисе вряд ли у кого то появится желание поспать по середине рабочего дня, а вот на удалёнке такое случается, и это явно не та прикормка, с которой дуреет тимлид.


Удалёнка — это не рай и не ад, а скорее испытание на зрелость.
Она даёт свободу, но вместе с ней приходит ответственность: за своё время, дисциплину и даже за собственное психическое здоровье.
Если умеешь держать баланс и не превращать дом в вечный open space — будешь кайфовать. Если нет — легко скатиться в прокрастинацию, одиночество и выгорание.

#SuperGuides

Мониторинг за 5 минут: Prometheus + Grafana

❗️❗️❗️
Данный пост сделан совместно с каналом:

Linux | Network | Devops

подписывайтесь🙂

Хотите быть уверены, что сервер не падает в самый ответственный момент, CPU не забит на 100%, а место на диске не заканчивается внезапно?
Для этого в мире DevOps есть три классических героя: Prometheus, Grafana и Node Exporter.

❓ Что это такое?
⏩ Prometheus - база данных для метрик + «мозг» мониторинга.
Он опрашивает приложения, сервисы и экспортеры, хранит числовые ряды и позволяет писать запросы (PromQL).
⏩ Node Exporter - агент, который запускается на сервере и отдаёт данные о его состоянии: CPU, RAM, диски, сеть. Без него Prometheus будет «слепым» к железу.
⏩ Grafana - удобная панель визуализации. Она умеет подключаться к Prometheus (и не только) и рисовать красивые графики, дашборды и алерты.

В связке это работает так:
Node Exporter 🔜 отдаёт метрики ➡️ Prometheus их собирает 🔜 Grafana отображает.

Шаг 1. Готовим окружение
Установи Docker и Docker Compose.
Проверка:

docker --version docker compose version 

Создай папку проекта:

mkdir monitoring && cd monitoring 

Шаг 2. docker-compose.yml
Файл docker-compose.yml:

version: "3.8"
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  node-exporter:
    image: prom/node-exporter
    ports:
      - "9100:9100"

  grafana:
    image: grafana/grafana-oss
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

✔️ 3 контейнера:
Prometheus собирает метрики,
Node Exporter отдаёт состояние сервера,
Grafana рисует графики.

Шаг 3. Конфиг Prometheus
Файл prometheus.yml - это основной конфигурационный файл Prometheus. В нём указываются, какие сервисы опрашивать, с какой частотой и по каким адресам забирать метрики.
Без него Prometheus не будет знать, откуда брать данные для мониторинга
Файл prometheus.yml:

global:
  scrape_interval: 15s   # глобальный интервал опроса: каждые 15 секунд Prometheus будет забирать метрики

scrape_configs:          # список "job" (задач), которые Prometheus будет опрашивать

  - job_name: 'prometheus'   # имя задания (для удобства в метках и интерфейсе)
    static_configs:          # список статических таргетов (адресов, которые нужно опрашивать)
      - targets: ['prometheus:9090']  
        # здесь мы говорим: опрашивай сам Prometheus по адресу prometheus:9090
        # (контейнер prometheus внутри docker-compose доступен по имени сервиса)

  - job_name: 'node'         # второе задание — сбор метрик с Node Exporter
    static_configs:
      - targets: ['node-exporter:9100']  
        # адрес node-exporter, который отдаёт метрики о состоянии хоста
        # (CPU, память, диски, сеть и т.д.)

Шаг 4. Запуск

docker compose up -d 

✔️ Проверяем:
Prometheus ⏩ http://localhost:9090
Grafana ⏩ http://localhost:3000 (логин/пароль: admin/admin)
Node Exporter ⏩http://localhost:9100/metrics

Шаг 5. Настройка Grafana
Войти в Grafana.
Data Sources ➡️ добавить Prometheus (http://prometheus:9090).
Импортировать готовый дашборд (Node Exporter Full, ID: 1860).
Теперь у тебя полный обзор сервера: CPU, RAM, диски, сеть.


💡 Что дальше?
Подключить Alertmanager, чтобы слать уведомления в Telegram.
Добавить экспортёры для Postgres, Redis, Docker.
Настроить хранение метрик подольше (retention).

✅ Итог:

Node Exporter следит за сервером,
Prometheus собирает данные,
Grafana превращает их в графики.
И всё это — за 5 минут 🪐

#Prometheus #Grafana #Devops #monitoring

#основыDevOps

Git для DevOps: must-have навык

💡Если DevOps — это про автоматизацию, то Git — это про порядок в хаосе кода и конфигов.
Без Git любой проект превращается в папку «финал_версия2_точно_версияПоследняя.zip» 🐤


❓ Что такое Git?
Это система контроля версий. Она хранит все изменения в коде и даёт возможность:
⏩вернуться к любой прошлой версии;
⏩работать в команде без криков «Кто поломал билд?!»;
⏩быстро откатывать ошибки.


🤪 Базовые команды, которые нужны DevOps каждый день:

# Клонировать репозиторий
git clone https://github.com/user/project.git

# Проверить статус изменений
git status

# Добавить файлы в индекс
git add .

# Сделать коммит
git commit -m "Добавил конфиг для CI/CD"

# Отправить изменения в удалённый репозиторий
git push origin main

# Забрать последние изменения
git pull origin main

# Переключиться на другую ветку
git checkout feature-branch

☀️ Зачем DevOps знать Git?

*️⃣хранение инфраструктуры как кода (Terraform, Ansible, Helm чарты);

*️⃣CI/CD пайплайны работают только с Git;

*️⃣логирование изменений: всегда видно, кто что сделал.

#devops #git #cicd #network

#основыDevOps

Git Hooks: Автоматизируем проверки перед Push

Сегодня поговорим о том, как сделать свою жизнь чуть проще, а код значительно чище. Речь пойдет о Git Hooks - мощном инструменте, который многие недооценивают.

❓ Что такое Git Hooks?

Простыми словами, это скрипты, которые Git запускает автоматически при определенных событиях (коммит, пуш, мерж и т.д.). Они живут в папке .git/hooks вашего репозитория.

Самый полезный для нас хук — pre-push. Он срабатывает перед тем, как ваши коммиты улетят на удаленный сервер. Идеальный момент, чтобы провести быструю проверку и не затолкать в main кривой код!

⚡️ Зачем это девопсеру?

Мы не просто пишем код, мы выстраиваем процессы.
Внедряя хуки в проекты, мы:
✔️ Экономим время и ресурсы CI/CD: Простейшие проверки (синтаксис, секреты) проходят локально, не загружая раннеры.
✔️ Стандартизируем код: Все в команде коммитят код по одним правилам.
✔️ Предотвращаем ошибки: Меньше шансов навернуть билд или прод из-за мелочи.

Что можно проверять в pre-push?

Вот несколько идей для вашего скрипта:
🟢 Запуск линтеров: eslint, pylint, shellcheck.
🟢 Проверка синтаксиса: python -m py_compile, terraform validate.
🟢 Поиск закоммиченных секретов: с помощью truffleHog или git-secrets.
🟢 Запуск модульных тестов
🟢 Проверка форматов комитов


✅ Вывод:

Git Hooks — это ваш личный автоматизированный код-ревьюер, который работает мгновенно и бесплатно. Потратьте 15 минут на настройку — и вы будете реже краснеть

📱 В следующем посту приведу реальные примеры....

#git #devops #automation #cicd #git #hooks #codequality #программирование #инфраструктураммирование #инфраструктура

#основыDevOps

Git Hooks: часть 2

🔥Как и обещал, вот готовые примеры для вашего pre-push хука. Просто скопируйте код в файл .git/hooks/pre-push и сделайте его исполняемым:

chmod +x .git/hooks/pre-push

▶️ Базовый пример: проверяем синтаксис Python и Terraform

#!/bin/bash
echo "🔍 Запуск pre-push проверок..."
if find . -name "*.py" -exec python -m py_compile {} \; 2>/dev/null; then
    echo "✅ Python синтаксис в порядке"
else
    echo "❌ Ошибка в Python коде!"; exit 1
fi

# Проверяем terraform (если есть файлы)
if find . -name "*.tf" -exec terraform validate {} \; 2>/dev/null; then
    echo "✅ Terraform валиден"
else
    echo "❌ Ошибка в Terraform!"; exit 1
fi

▶️ Ищем утерянные секреты перед отправкой на сервер

#!/bin/bash
echo "🕵️ Проверяем на наличие секретов..."
# Используем git-secrets или аналоги
if git log -p -n 10 --oneline | grep -E "(password|token|key)"; then
    echo "❌ Возможный секрет в истории коммитов!"; exit 1
else
    echo "✅ Подозрительных строк не найдено"
fi

🔜 Запускаем линтер для Shell-скриптов

#!/bin/bash
echo "🧹 Проверяем shell-скрипты..."
if find . -name "*.sh" -exec shellcheck {} \; ; then
    echo "✅ ShellCheck прошел успешно"
else
    echo "❌ ShellCheck нашел ошибки"; exit 1
fi

💡 Важно:

Хуки не копируются в репозиторий. Чтобы команда могла ими пользоваться, сохраните эти скрипты в папке scripts/git-hooks и настройте их копирование при клонировании проекта.

#git #devops #automation #security #coding

#thing

Не так давно проходил собеседование...

Я несколько месяцев назад проходил собеседование в один крупный банк. И там мне сходу задали вопрос, который вроде бы и простой, но поставил немного в тупик и заставил задуматься.🐸

💡 Так вот вопрос такой:

«Что будешь делать, если сервис на сервере не работает?»

Мой первый ответ был стандартным: «Посмотрю логи, проверю статус systemctl...» Но интервьюер тут же перебил: «А если этоа не поможет?» 🩹

И вот тут началось самое интересное. Мы развернули целый детектив. Оказалось, они ждали не просто заученного списка команд, а системного подхода и понимания всех слоёв. Мой ответ в итоге ребяток устроил, но времени на него ушло много)

❗️Вот что я в итоге выделил для себя как идеальный ответ:

1️⃣ Не бегу перезагружать! Это последнее дело.
2️⃣ Определяю границы проблемы: Он не работает только для меня? Для всех? На одном сервере или на всех?
3️⃣ Иду по цепочке снизу вверх:
🔵 Сервер: ping, ssh (жив ли вообще?)
🔵 Ресурсы: htop, df -h, dmesg -T | tail (не упёрлись в лимиты CPU, RAM, диска?)
🔵 Процесс: systemctl status, ps aux | grep ... (висит ли процесс?)
🔵 Порт: ss -tlpn | grep :port (а слушает ли он тот порт?)
🔵 Логи: journalctl -u service -f --since "5 min ago" (что кричит в логах?)
🔵 Сеть: curl -v localhost:port (а изнутри-то отвечает?), проверяю цепочку фаерволов (и облачный, и iptables).
🔵 Зависимости: А живы ли база данных, кеш, соседние микросервисы? telnet db_host 5432
🔵 Конфиги: Не менялось ли что недавно? Дежурный сразу смотрит в git log на предмет свежих коммитов.

✅ Вывод:

Очень часто начинающие инженеры очень углубляются в теорию, команды, утилиты.
А тут вопрос не про команды, а про структурное мышление. Нужно показать, что ты не просто оператор, а понимаешь всю цепочку: от железа до сетевых правил и конфигов.

Кстати, мне в итоге предложили оффер, но я отказался по личным причинам! 🐥


#собеседование #devops #linux #опыт #карьера #sysadmin

#основыDevOps

GitLab vs GitHub vs Bitbucket — кого выбрать?

Каждый, кто начинает работать с git, в какой-то момент задаётся этим вопросом. Давайте разберёмся коротко и по делу:

🔜 GitHub — это как TikTok для кода.
Все сидят, лайкают, делают pull requests и спорят, кто круче. Идеально, если хочешь, чтобы твой pet-проект увидели миллионы (или хотя бы три айчара, которым кинул резюме🐸).

➡️ GitLab — это швейцарский нож DevOps.
Здесь и репа, и CI/CD, и пайплайны, и registry, и ты сам себе DevOps за один вечер. Компании любят за то, что можно поднять свой GitLab и стать "суверенной IT-державой".

🔜 Bitbucket — тихий интроверт, который живёт рядом с Jira.
Если у вас вся жизнь — это тикеты, спринты и боль от Confluence, то Bitbucket встанет, как родной.

✅ Итог:

Хочешь хайпа и open-source — GitHub.
Хочешь контроль и автоматизацию — GitLab.
Хочешь жить в мире Jira — Bitbucket.

#thing

Все IT-работяги не любят HR скрининг

И это не мое мнение, так считают почти все. Ну и я думаю каждого сводил с ума вопрос:

Кем вы себя видите через 5 лет?

Так вот, пару дней назад я попал еще в больший ад и оказался на айчар скрининге, который проводила..... НЕЙРОНКА👁

Когда я это увидел, был очень удивлен и решил, что надо попробовать и оценить, да и дорогим падпищикам рассказать🐤

Ну вот и поехали, забиваю слот для собеседования через телеграмм бота. И за несколько минут до назначенного времени приходит ссылка на сайт с ai-рекрутером. Подтверждаю согласие о персональных данных и начинаю собес.

Сначала нейросеть попросила рассказать о себе. Я подробно рассказал о своих проектах, текущем месте работы и задачах там, вроде все круто. Ну и следующий вопрос убил. Она меня попросила рассказать о задачах на предыдущем месте работы.... Эммм🐥. Ладно, еще раз рассказал. Потом спросила, при каких условиях я готов работать 60 часов в неделю? Эээ, я вам что робот что ли❓❓❓ Ответил уверенно, нет, ни при каких не готов. Дальше она зациклилась и раза 3 мне перезадала этот вопрос...

На этом моменте у меня дико сгорело, для себя я понял, что это не уважение к кандидатам и прекратил собес.

Ну вот и конец истории)

В итоге хочется отметить:
▶️Нейросеть совершенно не понимала контекст и действовала по скрипту
▶️Так и не понял прикол вопроса про 60 часов, надеюсь ai просто поломалась, а не ждала положительного ответа, в таком случае у меня просто нет слов тогда👻
▶️Когда я рассказывал о себе, было ощущение, что говорю в пустоту. О себе хочется все таки рассказывать человеку, а не роботу
▶️Осталось полностью негативное впечатление

❗️ Одним словом, на такие собесы я больше не пойду

#основыDevOps

CI/CD для чайников: что это и зачем

Представь, что у тебя команда разработчиков. Все кодят как боги (ну почти🐤), но каждый коммит — как придется:

– «У меня работает!»
– «А у меня — прод лег!»

Чтобы больше не жить в аду ручных проверок и релизов в 3 ночи, придумали CI/CD.


💡 CI — Continuous Integration
Непрерывная интеграция, aka “не даём багам плодиться”.
Каждый раз, когда кто-то пушит код, CI тут же проверяет:
собирается ли проект,
проходят ли тесты,
не развалилось ли ничего.
Если всё ок — получаешь зелёную галочку ✅
Если нет — уведомление в стиле: «Поздравляем! Ты снова всё сломал.» ❌

Зачем это нужно:
▶️ Код всех участников постоянно сливается, и мы видим, где что упало.
▶️ Ошибки ловятся сразу, а не через месяц, когда никто уже не помнит, кто это написал.


⚡️ CD — Continuous Delivery / Deployment
CD — это CI на стероидах. Он не просто проверяет, а ещё и развёртывает новую версию приложения туда, куда надо.
Например:
после успешного теста — на staging;
после апрува — в прод (и пусть прод будет с тобой).
Раньше релизы выглядели так:

“Собери билд, скопируй, деплойни, молись.”

Теперь это делает робот.


❓ Почему CI/CD — мастхэв
▶️ Нет “ручных” релизов — всё автоматом.
▶️ Меньше стресса — можно спать ночью, а не деплоить новую версию.
▶️ Баги ловятся раньше — пользователи даже не успевают пожаловаться.
▶️ Продукт обновляется быстрее — бизнес доволен, команда счастлива.


🔥 В итоге:

CI/CD — это не просто модный DevOps-ритуал.
Это как нанять себе дисциплинированного помощника, который
проверяет, тестирует и выкатывает за тебя,
пока ты пьёшь кофе и споришь в чате, чей код лучше. ☕

#devops #python #cicd #yml #Dev #coding #automation #инфраструктура #git

#основыDevOps

Какую платформу для CI/CD выбрать?

CI/CD — это как отношения: если всё автоматизировано, ошибок меньше, а жизнь стабильнее. Но вот вопрос — на какой платформе строить эти отношения?

⚡️ Разберём топовые варианты и кому что подойдёт:

1️⃣ GitHub Actions
Лучше всего подходит: для open-source и небольших команд.
Плюсы:
🔘 Интеграция прямо в GitHub — ничего настраивать не нужно.
🔘 Marketplace с кучей готовых действий (actions).
🔘Бесплатные минуты для публичных репо.
Минусы:
🔘 Меньше гибкости, если хочешь всё «по-взрослому».
🔘 Лимиты на ресурсы.

💬 Отличный старт, если у тебя всё крутится в GitHub и не хочется возиться с Jenkins’ом.

2️⃣ GitLab CI/CD
Лучше всего подходит: для компаний и энтерпрайза.
Плюсы:
🟡 Всё в одном: репо + CI/CD + трекинг задач.
🟡 Удобные пайплайны с YAML-конфигом.
🟡 Поддержка self-hosted runner’ов.
Минусы:
🟣 Конфиги со временем превращаются в мини-язык программирования.
🟣 Интерфейс иногда подлагивает (классика😍).

📎 Если хочешь полный контроль и интеграцию со всем циклом разработки — бери GitLab.

3️⃣ Jenkins
Лучше всего подходит: если ты хочешь абсолютную гибкость.
Плюсы:
🟢 Поддерживает вообще всё (plugins спасут любой use case).
🟢 Работает офлайн, на своих серверах.
Минусы:
🔵 Настройка = боль.
🔵 Интерфейс из 2000-х.
🔵 Требует постоянного ухода, как старый сервер.

📌 Jenkins — это как Linux: мощно, но не для слабонервных.

4️⃣ CircleCI / Travis / Drone / TeamCity
Подходит: для тех, кто хочет быстро и без заморочек.
Плюсы:
🔘Быстрая интеграция с GitHub/GitLab.
🔘 Простота конфигурации.
Минусы:
🔘 Платно (и иногда немало💔).
🔘 Меньше контроля и кастомизации.


✅ Вывод:

Хочешь быстро — GitHub Actions.
Хочешь мощно — GitLab CI/CD.
Хочешь полный контроль — Jenkins

А вообще, не платформа делает DevOps — DevOps делает платформу ✈️

#devops #python #cicd #yml #Dev #coding #automation #инфраструктура #git

#основыDevops

GitHub Actions: автоматизация без боли

Когда код собирается, тесты проходят, а деплой крутится — и всё это без твоего участия…
Это не сон, это GitHub Actions 🧙‍♂️

❓ Что это вообще такое
GitHub Actions — это встроенный в GitHub CI/CD.
Он реагирует на события вроде push, pull request, release и запускает нужные тебе сценарии: тесты, сборку, деплой, публикацию пакета и даже, если сильно захочешь — автоматическую чистку багов после релиза 😅

🔜 Мини-пример, который уже делает магию

name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: pytest

Каждый пуш — и у тебя тесты запускаются на чистом окружении.
Без Docker, без Jenkins, без боли.

💡 Почему это удобно
🟡 Всё в GitHub - Не нужно поднимать отдельный CI-сервер
🟡 Marketplace - Тысячи готовых экшенов: от деплоя на AWS до поста в Telegram
🟡 Легко кастомизировать - YAML, шаги, секреты, кэш — всё под контролем
🟡 Бесплатно для open source проектов

🔥 А если хочется посерьёзнее
GitHub Actions умеет:
• Собирать образы
• Деплоить контейнеры
• Триггерить другие пайплайны
• Строить целые DevOps-конвейеры
• Вызывать workflow из другого репозитория

✏️ Итог:

Если ты до сих пор тестируешь руками или деплоишь через SSH — пора в XXI век.
GitHub Actions — это CI/CD, который реально не бесит.

#github #linux #actions #cicd #dev #developer #devops