Автоматизация: Хватит копипастить! Укрощаем git alias для быстрой работы

Вы пишете git status, git commit -m "...", git push origin develop по 100 раз в день. Это рутина, которая отнимает время и силы.

git alias — это ваша личная "горячая клавиша" для Git-команд. С его помощью можно сократить самые длинные и сложные команды до пары символов.

Как настроить (файл ~/.gitconfig):
Ini, TOML

[alias]
    st = status -sb                   # git st покажет статус кратко
    co = checkout                     # git co branch_name
    br = branch                       # git br
    ci = commit                       # git ci -m "msg"
    ps = push                         # git ps
    pl = pull                         # git pl
    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit  # git lg - красивый лог
    undo = reset HEAD~                # git undo - отменить последний коммит (локально)
    amend = commit --amend --no-edit  # git amend - обновить последний коммит без изменения сообщения

Как использовать: Просто вводите git st, git lg, git undo вместо длинных команд.

Взгляд архитектора: Эффективность — это краеугольный камень работы архитектора. git alias — это микрооптимизация, которая влияет на производительность команды. Меньше опечаток, быстрее работа, больше времени на проектирование, а не на рутину.

#git #automation #productivity #cli #devops #скрипты

Проект на выходные: Запускаем свой GitHub! Ставим Gitea в Docker

Хватит хранить скрипты и Ansible-плейбуки в папке C:\Scripts_Final_v2. Путь архитектора начинается с контроля версий.

Gitea — это сверхлегкий, быстрый и простой self-hosted Git-сервер. Он написан на Go, потребляет минимум ресурсов и запускается за 30 секунд. Идеально для Home Lab или небольшой команды.

Зачем он вам?

* IaC: Хранить код Terraform, Ansible, PowerShell DSC.
* Документация: Вести свою Wiki по инфраструктуре в Markdown.
* Скрипты: Создать центральный репозиторий для всех ваших PowerShell/Bash скриптов.

Готовый docker-compose.yml для старта:
YAML

version: '3.8'

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    volumes:
      - ./gitea-data:/data
    ports:
      # Веб-интерфейс (HTTP)
      - "3000:3000"
      # SSH для Git
      - "2222:22"
    environment:
      - USER_UID=1000
      - USER_GID=1000

1. Сохраните как docker-compose.yml.
2. Запустите docker-compose up -d.
3. Откройте http://<ваш_ip>:3000 и пройдите простую веб-установку (можно использовать SQLite, чтобы не поднимать отдельную БД).
4. Важно: В настройках укажите, что SSH-сервер работает на порту 2222.

Взгляд архитектора: Это не просто "удобно". Это фундамент для GitOps и CI/CD. Когда ваш код инфраструктуры лежит в Git, вы можете автоматизировать его тестирование и развертывание. Вы получаете историю изменений, ревью кода и возможность отката.

#linux #docker #selfhosted #git #devops #weekendproject #гайд

Что такое GitOps?

Это не "Git". Это принцип, при котором ваш Git-репозиторий — единственный источник правды.

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

1. Инженер: Пушит config.yml в Git.

2. Автоматика (CI/CD): Видит изменение.

3. Система (Kubernetes/Ansible): Приводит инфраструктуру в соответствие с Git.

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

#architect #devops #gitops #git #iac #sre

Full-Stack: Управляем «зоопарком» конфигов. `chezmoi` — ваш личный IaC

У вас есть идеальный .bashrc на Linux-сервере, крутой .zshrc на macOS и мощный profile.ps1 на Windows. Как синхронизировать их, не копируя вручную? А что делать с секретами (ключами API, токенами) в .gitconfig ?

Решение: `chezmoi` (произносится "шей-муа") Это не просто "менеджер dotfiles", это декларативный инструмент, как Ansible или Terraform, но для вашей личной среды.

Почему он лучше, чем symlink-менеджеры (Stow) или bare-репозиторий Git:

1. Декларативность: Вы говорите chezmoi apply, и он приводит конфиги в нужное состояние.

2. Шаблоны: Он использует go-template для создания разных конфигов на разных машинах (например, git config с разным email для работы и дома).

3. Безопасность: Интегрируется с gpg, age или менеджерами паролей (1Password, Bitwarden, KeePass) для безопасного хранения секретов.

Как начать:
Bash

# Инициализируем (он создаст репо в ~/.local/share/chezmoi)
chezmoi init

# Добавляем ваш .bashrc в "желаемое состояние"
chezmoi add ~/.bashrc

Теперь ваш ~/.bashrc скопирован, и вы можете chezmoi apply его на любой другой машине.

Взгляд архитектора: Это Configuration as Code для инженера. Вы относитесь к своей рабочей среде так же, как к production-серверам: декларативно, версионируемо и безопасно. Это экономит часы при настройке новой машины и гарантирует консистентность.

#devops #automation #chezmoi #git #linux #windows #гайд

Full-Stack (DevOps): "Нет!" паролям в Git. Скрипт `pre-commit` hook

Боль: Ваш инженер случайно коммитит config.prod.yml с открытым паролем от базы данных. Через 30 секунд Gitleaks-боты на GitHub находят его, и ваша БД взломана.

Реакция админа: "Я поменяю пароль и буду ругать инженера".
Реакция архитектора: Предотвратить сам факт коммита.

Git Hooks — это скрипты, которые Git запускает автоматически при определенных действиях (например, pre-commit — перед тем, как коммит будет создан).

Код скрипта (Bash, положить в .git/hooks/pre-commit):
Bash

#!/bin/bash
# --- Простой Pre-Commit Hook для блокировки секретов ---

echo "--- Запускаю проверку на секреты... ---"

# 1. Запрещенные слова. Добавьте свои (api_key, password, etc.)
FORBIDDEN_PATTERNS=(
    "password:"
    "password ="
    "api_key:"
    "api_key ="
    "SECRET_KEY"
    "BEGIN RSA PRIVATE KEY"
)

# 2. git diff --cached: Показывает ТОЛЬКО те изменения, которые вы собираетесь коммитить
FILES_TO_CHECK=$(git diff --cached --name-only --diff-filter=ACM)

if [ -z "$FILES_TO_CHECK" ]; then
    echo "Нет файлов для проверки. Пропускаю."
    exit 0
fi

# 3. Проверяем каждый файл
for FILE in $FILES_TO_CHECK; do
    for PATTERN in "${FORBIDDEN_PATTERNS[@]}"; do
        if grep -q -i "$PATTERN" "$FILE"; then
            echo "=============================================="
            echo "[!!!] ОШИБКА: ОБНАРУЖЕН СЕКРЕТ В ФАЙЛЕ!"
            echo "Файл:   $FILE"
            echo "Паттерн: '$PATTERN'"
            echo "=============================================="
            echo "Коммит ОТКЛОНЕН. Удалите секрет перед коммитом (используйте Vault или .env)"
            exit 1 # <--- Главная магия. Ненулевой exit code БЛОКИРУЕТ коммит.
        fi
    done
done

echo "[OK] Секреты не найдены. Коммит разрешен."
exit 0

(Не забудьте сделать его исполняемым: chmod +x .git/hooks/pre-commit )

Взгляд архитектора: Это "Shift-Left Security" (Сдвиг безопасности влево). Вы не реагируете на утечку, вы встраиваете безопасность в процесс разработки.

#security #devops #git #automation #bash #скрипты #гайд

📝 Git: "Что я вообще делал на этой неделе?"

Пятница — время писать отчеты (Status Report). Но память подводит: кажется, что всю неделю только пили кофе и чинили принтеры. Давайте спросим у Git, чем мы реально занимались.

Алиас "git standup": Покажет список ваших коммитов за последние 7 дней во всех репозиториях текущей папки.

git log --all --since='7 days ago' --author="$(git config user.name)" --oneline --no-merges --date=short --pretty=format:"%ad: %s"

Сделаем красиво (добавьте в .gitconfig):

[alias]
    standup = !git log --all --since='7 days ago' --author=\"$(git config user.name)\" --oneline --no-merges --date=short --pretty=format:\"%ad: %s\"

Теперь просто пишем git standup — и отчет для менеджера готов за 1 секунду.

#git #productivity #alias #cli #devops #reporting

🧠 Skill: Git Bisect — находим, кто сломал прод, за 5 минут 🕵️‍♂️

Ситуация: вчера деплой Terraform/Ansible работал.
Сегодня утром падает с ошибкой.
За ночь коллеги сделали 50 коммитов.
Читать каждый? Нет.

Используй бинарный поиск по истории git.

Алгоритм действий:

1. git bisect start — начинаем охоту.
2. git bisect bad — говорим: "сейчас всё плохо".
3. git bisect good v1.2 — говорим: "вот в теге v1.2 (три дня назад) всё работало".

Git сам переместит тебя ровно в середину истории. Ты проверяешь (запускаешь план).
Работает? Пишешь git bisect good.
Не работает? Пишешь git bisect bad.

За 4-5 шагов Git найдет тот самый коммит из сотни и покажет автора.

Результат: Ты не гадаешь, а математически точно находишь проблему. Это навык сеньор-уровня. 💎

#git #devops #troubleshooting #skill #versioncontrol #infrastructure #debug

🧠 Skill: «Git-гигиена» — пиши коммиты для людей, а не для галочки

В 2026 году даже «чистый» админ живет в парадигме **Infrastructure as Code (IaC)**. Твои конфиги Ansible, Terraform или просто Bash-скрипты лежат в Git. Но есть проблема: коммиты типа `fixed bug`, `update` или `.....` — это мусор. Через полгода ты сам не поймешь, что там изменилось.

Как делать правильно:

1. Заголовок до 50 символов: Краткая суть (что изменилось).
2. Пустая строка после заголовка: Это стандарт Git для корректного отображения в логах.
3. Тело коммита: Опиши ПОЧЕМУ ты это сделал. Какой баг пофиксил или какой тикет в Jira закрыл.

Пример идеального коммита:

feat(network): переход на nftables для SSH-фильтрации

- Удалены старые правила iptables из конфига
- Внедрены динамические сеты для защиты от брутфорса
- Исправлена проблема с ложными срабатываниями на IP офиса (тикет #402)

Хорошая история коммитов — это лучшая документация твоей работы.

#skills #git #iac #devops #bestpractices #sysadmin #admin_future

🧠 Skill: Doc-as-Code — почему твоя документация должна лежать в Git 📖

Старые Word-файлы с инструкциями и пыльные страницы в Wiki умирают в тот момент, когда их создали. В 2026 году админ использует подход Documentation as Code (DaC). Это значит, что документация пишется в Markdown, хранится в Git и живет рядом с кодом или конфигами.

Техническая суть:

1. Версионность: Ты всегда видишь, кто и когда изменил инструкцию по восстановлению бэкапа.
2. Peer Review: Ты можешь создать Pull Request с описанием новой схемы сети, а коллеги проверят его на ошибки.
3. Автоматизация: При пуше в Git документация может сама собираться в красивый статический сайт (через MkDocs или Hugo).

Простой пример Markdown-структуры:

```markdown
# Инструкция: Восстановление БД из бэкапа
## Шаги:
1. Зайти на сервер `db-backup-01`.
2. Выполнить команду: `cat backup.sql | psql database`.
> Важно: Перед этим проверьте наличие свободного места в `/var/lib/postgresql`.

```

Вывод: Навык работы с Markdown и Git-флоу для документации делает тебя системным инженером нового уровня, чьи знания не потеряются при сбое Wiki-сервера.

#skills #documentation #markdown #git #devops #sysadmin #admin_future

🚀 Skills: GitOps Lite. Почему твой /etc должен быть репозиторием

Помнишь то чувство ужаса, когда ты поправил конфиг, сервис упал, а ты забыл, что именно изменил? В 2026 году фраза «я сейчас всё верну как было по памяти» звучит как признание в профнепригодности. Админ сегодня — это не тот, кто много помнит, а тот, кто всё записывает в Git.

Техническая суть:

Концепция Infrastructure as Code (IaC) начинается не с Terraform, а с обычного git init в папке с твоими скриптами или конфигами.
Под капотом: Использование Git дает тебе машину времени. Ты всегда видишь, кто, когда и зачем изменил параметр в nginx.conf или в настройках active_directory. В 2026-м это стандарт: любой аудит безопасности начинается с просмотра истории коммитов в инфраструктурном репозитории.

Практика:
Начни внедрять GitOps на минималках прямо сейчас. Это спасет твою нервную систему:

# 1. Инициализируем репозиторий для критических конфигов
cd /etc/myapp/
git init

# 2. Создаем понятный коммит (забудь про "fix", пиши суть!)
git add .
git commit -m "CHG: Изменен таймаут коннекта к БД для ARM-кластера (Ticket #404)"

# 3. Если всё сломалось — откат за одну секунду
git checkout HEAD^1 config.yaml
systemctl restart myapp

# 4. Просмотр "кто виноват" (blame)
git blame config.yaml

Зачем это нужно:

Личное спокойствие и коллективная ответственность. Когда в команде больше одного человека, Git становится единственным источником правды. Больше никаких config.bak, config.old.2, config_LAST_FINAL. Только чистая история изменений и возможность мгновенного отката.

#skills #git #iac #devops #bestpractices #admin_future

🧠 Skills: Docs-as-Code — почему Confluence умирает и что приходит на смену

Коллеги, понедельник — хороший день для темы которая отделяет зрелые инфраструктуры от хаотичных. Документация.

Главная боль технической документации известна каждому: во-первых, её нет. Во-вторых, если она есть — она не актуальна. Confluence-страница, обновлённая последний раз в 2023-м, хуже чем отсутствие документации — она вводит в заблуждение.

Docs-as-Code решает это радикально: документация живёт там же где код, в том же git, проходит те же review.

Docs-as-Code — это методология которая говорит документировать так же как ты обращаешься с кодом — используя те же инструменты, workflow и системы контроля версий что разработчики используют для написания кода. Документация хранится в plain text (Markdown, AsciiDoc), в git-репозитории, с современным тулингом для генерации HTML, PDF.

Честная оговорка чтобы не было иллюзий: Docs-as-Code не обновляет документацию автоматически так же как обновляется код. Когда разработчик добавляет новый API endpoint — документация не сгенерируется сама, если для этого не настроены конкретные workflow и автоматизация.

Практический старт для сисадмина — не нужен GitBook за деньги:

МИНИМАЛЬНЫЙ DOCS-AS-CODE СТЕК (всё бесплатно):

Хранение:    Gitea / GitLab (self-hosted)
Формат:      Markdown (или AsciiDoc если нужны include и переменные)
Генерация:   MkDocs (Material theme) — статичный сайт из .md
Диаграммы:   Mermaid / PlantUML (текстом, версионируются)
CI/CD:       git hook → автодеплой при push

СТРУКТУРА РЕПОЗИТОРИЯ:
  docs/
  ├── infrastructure/
  │   ├── network-topology.md      # + Mermaid диаграмма inline
  │   ├── servers-inventory.md
  │   └── backup-strategy.md
  ├── runbooks/
  │   ├── RB-001-db-failover.md
  │   └── RB-002-cert-renewal.md
  ├── procedures/
  │   └── onboarding-new-server.md
  └── mkdocs.yml

# Поднять MkDocs за 5 минут:
pip install mkdocs-material --break-system-packages

# Инициализируем проект:
mkdocs new infra-docs && cd infra-docs

# Правим mkdocs.yml — тема Material:
cat > mkdocs.yml << 'EOF'
site_name: Infrastructure Docs
theme:
  name: material
  features:
    - search.suggest
    - content.code.copy
markdown_extensions:
  - pymdownx.superfences:
      custom_fences:
        - name: mermaid
          class: mermaid
EOF

# Локальный предпросмотр:
mkdocs serve  # http://127.0.0.1:8000

# Деплой как статика (git hook или CI):
mkdocs build  # генерит site/ — отдаём через nginx

# Диаграмма прямо в markdown (Mermaid):
# ```mermaid
# graph LR
#   Internet --> Firewall --> LB --> Web1 & Web2 --> DB
# ```

Один принцип который делает Docs-as-Code живым: хорошая документация должна непрерывно эволюционировать вместе с кодом который она описывает. Правило простое — изменил инфраструктуру, обнови doc в том же PR. Не «потом», а в том же коммите. Review не пропускает PR без обновления документации.

Зачем это сисадмину а не только разработчику: твои runbook, топология сети, процедуры onboarding — это и есть код инфраструктуры. В git они версионируются, ревьюятся, и главное — видно кто и когда менял. Confluence этого не даёт.

Итог: MkDocs + Gitea + правило «doc в том же PR» = документация которая не устаревает. Это вечер настройки и смена привычки. Попробуй на одном runbook на этой неделе.

#skills #docsascode #документация #mkdocs #git #sysadmin #admin_future