⬇️Навигация по каналу⬇️

Ну и вот пришло время задуматься о будущем канала и о постах в нем⭐️

💡 Каждый пост канала будет сопровождаться одним из хештeгов:

#основыDevOps - тут будет по порядку и структурированно освещаться все, чтобы войти в профессию

#DevOpsStories - спонтанные и чиловые истории из жизни

#SuperGuides - простенькие шпаргалки и гайды

#ITmemes - мемчики, ну а куда без них🙂

#think - просто мысли о житухе, развитию и work die life balance

#challenge - вызовы и челенджи, просто развлекаемся тыкая кнопочки


Во всех категориях постов кроме #основыDevOps, посты будут выходить спонтанно и по мере вдохновения и сочинения Даней🐸



❗️А вот по основам хочу сделать четкий план развития
(в будущем будет дополняться ссылками по мере написания):

➖ БАЗА 
🟢Linux: ключевые команды, процессы, сети 
*️⃣Linux: главный друг DevOps и 20 команд, которые спасают задницу
*️⃣Логи в Linux: как читать и не утонуть в /var/log
*️⃣Права в Linux простыми словами
*️⃣Сетевые утилиты в Linux
*️⃣Настройка сервисов: systemd, cron, journalctl

🟢Windows: PowerShell, автоматизация 
🟢Python: скрипты для автоматизации 

➖ ОСНОВЫ DEVOPS 
🟢 Git, CI/CD (Jenkins, GitHub Actions) 
🟢Docker: от основ до оптимизации 
🟢Kubernetes: кластеры, деплой 

➖ АВТОМАТИЗАЦИЯ 
🟢Terraform: облачная инфраструктура 
🟢Ansible: настройка серверов 

➖МОНИТОРИНГ И БЕЗОПАСНОСТЬ 
🟢Prometheus + Grafana 
🟢DevSecOps: сканирование кода и контейнеров 

➖ PRO-ТЕМЫ 
🟢GitOps (ArgoCD) 
🟢Облака (AWS/GCP) 
🟢Оптимизация затрат и производительности

#основыDevOps

Linux: главный друг DevOps и 20 команд, которые спасают задницу


🔜 Что такое Linux простыми словами?
Linux📱— это операционная система, но не одна штука, а целая экосистема.
В основе — ядро (kernel), которое рулит железом.
Сверху — разные «сборки» (дистрибутивы): Ubuntu, Debian, CentOS, Fedora, Arch (для самых смелых 👻).

90% серверов в мире работают на Linux. Даже если у тебя Windows на ноуте — всё равно в облаке, где живёт твой код, будет Linux.


❓Почему DevOps обязан знать Linux?
Серверы = Linux.
Docker = Linux (контейнеры используют ядро Linux).
Kubernetes = Linux.
Jenkins, GitLab, Ansible, Terraform — всё это работает лучше на Linux.

Если ты не знаешь Linux, ты как хирург без скальпеля. Можно попробовать работать ложкой, но… результат будет так себе ☹️.




⚡️ 20 команд, без которых ты не DevOps
🟡 1–4: Основы навигации

pwd — показать, где ты находишься (Print Working Directory).

ls -la — список файлов и папок (с правами, владельцами и скрытыми файлами).

cd /путь/ — перейти в директорию.

tree — показать структуру папок (не везде предустановлен, но must-have).

❗️ Без этого ты как в лесу без карты.

🟡 5–8: Работа с файлами

cat file.txt — вывести содержимое.

less file.txt — читать файл с прокруткой.

head -n 20 file.txt — показать первые 20 строк.

tail -f logs.txt — читать логи «вживую» (must-have для продакшена😀).

🟡 9–12: Управление файлами и правами

touch new.txt — создать пустой файл.

mkdir new_folder — создать директорию.

chmod 755 script.sh — изменить права доступа.

chown user:group file.txt — сменить владельца файла.

⚡️ Права в Linux — это святое. Если не знаешь chmod, будешь долго материться.

🟡13–15: Процессы и системы

ps aux — список процессов.
top или htop — мониторинг загрузки системы.

kill -9 PID — убить зависший процесс (и да, иногда прод падает именно после этого 🙃)

👉 Без этого ты не сможешь понять, кто жрёт всю память или почему сервер висит.

🟡16–18: Сеть

ping google.com — проверить, доступен ли хост.

curl http://site.com — отправить HTTP-запрос.

ss -tulnp или netstat -tulnp — показать открытые порты.

🟡 19–20: Админские must-have

systemctl status service — проверить, работает ли сервис.

journalctl -u service -f — читать логи конкретного сервиса в реальном времени.

🍀 Если у тебя не запускается nginx или docker — это твои лучшие друзья.


💡 Итого
Linux — это не просто ОС. Для DevOps это 🗿 «базовый уровень».
Выучив эти 20 команд, ты:
😀 научишься ориентироваться в системе,
😀 поймёшь, как читать и дебажить логи,
😀 сможешь управлять процессами и сервисами,
😀 не будешь паниковать, когда всё упало.

#основыDevOps


Логи в Linux: как читать и не утонуть в /var/log

В мире DevOps есть два состояния:
Всё работает 👍
«Почему всё упало?» 🧑‍💻

И вот именно во втором случае тебе нужны логи.
Логи — это дневник системы. Они честно записывают всё:
кто заходил,
что запускалось,
почему сервис умер,
и кто всё это сломал.

❓ Где живут логи в Linux?

По умолчанию — в папке /var/log.

Там можно найти целый зоопарк:

/var/log/syslog # системные события (Ubuntu/Debian)
var/log/messages # системные события (CentOS/RHEL) 
/var/log/auth.log # авторизация, ssh-логины 
var/log/kern.log # ядро Linux 
var/log/nginx # логи nginx
var/log/mysql # логи MySQL

💡 Совет: если что-то не работает — первым делом загляни в /var/log.

❗️ Как читать логи?

1️⃣ tail — смотри последние строки

tail -f /var/log/syslog # новые записи в реальном времени

2️⃣ less — удобно листать

less /var/log/syslog

👉 Навигация: Space (вниз), b (назад), q (выйти).

3️⃣grep — ищем конкретно

grep "error" /var/log/syslog # найти ошибки 
grep -i "nginx" /var/log/syslog # игнор регистра 
grep -r "fatal" /var/log/ # искать во всех файлах

👉 Экономит часы жизни: не надо глазами искать слово «ERROR» среди тысячи строк.

4️⃣ journalctl — системные логи через systemd

journalctl -u nginx.service --since "10 min ago" # логи nginx за последние 10 минут
 journalctl -xe # последние ошибки системы 
journalctl -f # новые записи (как tail -f)

👉 Если сервис запущен через systemd, то это лучший способ понять, почему он не стартует.

5️⃣ dmesg — ядро Linux

dmesg | tail -n 20

👉 Полезно, если проблемы с железом или драйверами (например, диск отвалился).


💡 Практический сценарий
Представь: ты выкатываешь новую версию сервиса, и он не запускается.

План действий DevOps:
Проверяешь статус сервиса:

systemctl status myapp

Смотришь его логи:

journalctl -u myapp for

Если там пусто — лезешь в /var/log/.
Ищешь ошибки:

grep "error" /var/log/syslog

🍒 В 90% случаев уже на этом этапе находишь причину.


⭐️ Итого
Логи — это твои глаза в Linux.
✔️ Запомни:

без логов ты слепой DevOps.

С ними ты всегда можешь понять: «почему всё упало» и «кто виноват».

#SuperGuides

Vim для DevOps: как не выйти из себя


Vim — редактор текста, который встречает тебя пустым экраном и вопросом:
🔜«А как отсюда выйти?»


Вот небольшая шпаргалка, чтобы выжить:
🟡 Открыть файл

vim filename.txt

🟡Режимы

i — вставка (печатаем текст)
Esc — вернуться в командный режим
: — ввод команд

🟡 Выход из Vim

:q # выйти (если без изменений) 
:q! # выйти без сохранения 
:wq # сохранить и выйти 

🟡 Полезное

dd # удалить строку 
yy # скопировать строку 
p # вставить скопированное 
u # отмена (undo)

💡 Запомни:

Vim либо полюбишь, либо будешь ненавидеть, но знать его должен каждый DevOps.

#основыDevOps

Права в Linux простыми словами


💡 Представь, что файл – это комната. У неё есть три категории гостей:

🐤Владелец – хозяин комнаты

🐥🐸 Группа – его друзья

🏠 Остальные – все остальные люди


Каждому гостю можно дать разные возможности:

r (read) – можно заглянуть (читать файл / смотреть, что в папке)

w (write) – можно переставить мебель (изменять/удалять)

x (execute) – можно включить свет и пользоваться (запустить программу / зайти в папку)


✏️ Как менять права

chmod – «какие ключи дать гостям»

chmod u+x script.sh   # дать владельцу право запускать
chmod g-w file.txt    # забрать у группы право менять
chmod o+r notes.txt   # разрешить остальным читать

u = user (владелец),
g = group (группа),
o = others (остальные).


chown – «кто хозяин комнаты»

chown dan:devops file.txt

Теперь хозяин – dan, его друзья – группа devops.


ACL – «пропуск по именам»
Если нужно дать доступ конкретному человеку:

setfacl -m u:alex:rw file.txt

Теперь alex может читать и менять файл, даже если он не владелец и не в группе.


✅ Итого:

chmod – раздаём ключи (читать, менять, запускать)

chown – меняем хозяина

ACL – даём доступ конкретным людям

#основы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