GitOps або Смерть. СКВ для сучасного системного адміністратора
В наш час межа між розробником (Dev) та адміністратором (Ops) остаточно розмилась. Якщо ваші скрипти живуть лише на робочому столі або в ~/scripts/, ви працюєте неефективно.
Будь-що: від “однорядкових” Bash-скриптів та автоматизації на Python до масивних плейбуків Ansible чи Terraform-маніфестів це все має бути під контролем систем контролю версій (СКВ).
Переваги використання СКВ#
У кожного адміна є право на помилку, ми люди і можемо помилятись. Щоб зменшити або навіть запобігти проблемним ситуаціям має бути можливість відкотитись до робочого стану (git revert).
Логування змін, ви завжди будете знати, хто, коли і, головне, навіщо змінив параметр у конфігу Nginx/Apache/Bind9. В команді кілька адмінів? Кілька адмінів можуть працювати над одним проектом, не затираючи правки один одного.
Також, СКВ це перший крок до автоматизації (CI/CD), комміт у репозиторій може автоматично оновити конфігурацію на сотнях серверів.
Огляд інструментів: Від класики до екзотики#
1. Git - стандарт де-факто.#
Сьогодні Git це база. Якщо ви не знаєте git push, ви поза ринком.
- Плюси: Децентралізація, швидкість, величезна спільнота, підтримка будь-яким IDE.
- Мінуси: Поріг входження. Робота з гілками (branching) спочатку може здатися складною.
- Для кого: Для всього і всіх. Від особистих нотаток до Infrastructure as Code (IaC).
2. Subversion (SVN) - Старий гвардієць#
Централізована система. Колись була королем, зараз зустрічається в legacy-проектах або дуже специфічних корпоративних середовищах.
- Плюси: Проста модель (одне центральне сховище).
- Мінуси: Потребує постійного зв’язку з сервером, повільна робота з гілками.
3. Mercurial (Hg) - Дружнє обличчя#
Схожа на Git, але з людським обличчям. Була популярною, але програла маркетингову війну.
- Плюси: Більш інтуїтивні команди, ніж у Git.
- Мінуси: Менша екосистема, важче знайти готові інтеграції.
4. Darcs - Альтернативний погляд#
Якщо Git та SVN оперують поняттями “знімків” (snapshots), то Darcs базується на унікальній теорії патчів.
- Плюси: Неймовірна гнучкість. Ви можете вибирати, які саме зміни (патчі) додати в репозиторій, не турбуючись про їхній суворий порядок. Вона інтуїтивна для тих, хто мислить категоріями “що я змінив”, а не “яку версію зберіг”.
- Мінуси: Написана на Haskell, що робить її нішевою. Швидкість роботи на дуже великих проектах поступається Git.
- Для кого: Для адмінів-естетів та специфічних локальних проектів.
Далі ми будемо розглядати роботу з Git, найпоширенішою системою СКВ.
Де тримати свій код? Git це не тільки хмари#
Багато новачків вважають, що Git обов’язково потребує веб-інтерфейсу типу GitHub чи GitLab. Це міф. Ви можете розгорнути Git-хостинг за 5 хвилин без жодного веб-сервера.
-
Git через SSH (Self-hosted): Достатньо мати доступ до будь-якого сервера. Ви просто ініціалізуєте порожній репозиторій на сервері (
git init --bare /srv/git/project.git), і вся ваша команда колег може до нього пушити. Це максимально безпечно, безкоштовно і повністю під вашим контролем. -
Файлова шара (NFS/SMB): Репозиторій може жити навіть просто на мережевому диску. Хоча це менш надійно через можливі конфлікти блокування файлів, для одного адміна це робочий варіант “швидкого бекапу” скриптів.
-
Готові платформи:
- GitHub - для open-source та особистих проектів.
- GitLab - стандарт для Enterprise з потужним вбудованим CI/CD.
- Gitea / Forgejo - “легковажний” self-hosted інструмент на Go, що літає навіть на мікрокомп’ютерах.
Шпаргалка: “Бойовий набір” команд Git#
Цього списку вистачить для 90% повсякденних задач системного адміністратора.
Початок роботи#
git init- створити новий репозиторій у поточній папці.git clone [url]- скопіювати існуючий проект (наприклад,git clone ssh://user@server:/srv/git/repo.git).
Робота зі змінами#
git status- головна команда. Показує, які файли змінені, а які ще не відстежуються.git add script.sh- додати файл до “індексу” (підготувати до збереження).git commit -m "feat: add log rotation to backup script"- зафіксувати зміни в історії з коментарем.
Робота з віддаленим сервером#
git remote add origin [url]- прив’язати локальний репозиторій до сервера.git push origin main- відправити ваші локальні комміти на сервер.git pull- забрати останні зміни від колег із сервера.
Якщо щось пішло не так#
git diff- подивитися, що саме ви змінили в коді порівняно з останньою версією.git checkout -- config.conf- скасувати всі незбережені зміни у файлі (повернути до стану останнього комміту).git log- подивитися історію всіх попередніх правок.
Гігієна репозиторію: Налаштовуємо виключення файлів#
Справжній адмін ніколи не тягне в Git сміття. Тимчасові файли, логи, кеш та (особливо!) паролі мають залишатися за бортом. Для цього в корені проекту створюється файл .gitignore.
Ось приклад .gitignore для системного адміністратора, який автоматизує процеси на Bash, Python та Ansible:
# --- Логи та тимчасові файли систем ---
*.log
*.tmp
*.swp
.DS_Store
thumbs.db
# --- Python компіляція та оточення ---
__pycache__/
*.pyc
*.pyo
*.pyd
.venv/
venv/
ENV/
# --- Ansible сміття ---
*.retry
.ansible_cache/
# --- Terraform тимчасові файли ---
.terraform/
*.tfstate
*.tfstate.backup
.terraform.tfstate.lock.info
# --- СЕКРЕТИ (Ніколи не пушити!) ---
*.pem
*.key
*.pub
id_rsa
secrets.txt
.env
Поради. Як “не вистрілити” собі в ногу#
- Atomic Commits: Один комміт - одна задача. Не треба пхати оновлення ядра проекту і зміну коментаря в скрипті бекапу в один запис.
- Змістовні повідомлення: Забудьте про повідомлення типу “fix”, “update” або “111”. Через місяць ви самі не зрозумієте, що там було. Пишіть за стандартом Conventional Commits:
# examples
# feat: (Feature) додавання нового функціоналу
feat: add firewall rules for web-server
# fix: (Bug Fix) - виправлення помилки
fix: correct mysql backup path.
# docs: (Documentation) - зміни в документації або файлі README
docs: update installation steps
# refactor: (Refactoring) - переписування коду без зміни його логіки
refactor: optimize loops in cleanup script
# chore: (Рутина/Обов'язки) - технічні завдання, які не міняють сам код скриптів
chore: add tmp files to .gitignore
- Не зберігайте секрети! Якщо потрібно зашифрувати паролі в Ansible, то використовуйте
ansible-vault. Якщо в скриптах - виносьте їх у змінні.env(який додано в.gitignore).
Заключення нашого огляду#
Не намагайтеся вивчити все одразу. Почніть з тріади add -> commit -> push. Коли ви вперше випадково видалите важливий скрипт, а потім за 2 секунди дістанете його з Git ви зрозумієте, чому цей інструмент став стандартом.
Git - це такий самий базовий інструмент, як SSH або текстовий редактор. Починайте з малого: створіть локальний репозиторій для своїх bash-скриптів вже сьогодні. Ваше “майбутнє я” скаже вам “дякую” під час наступного інциденту о третій ночі.