Sunucu Yapılandırmaları Neden Aklınızda Değil Git'te Durmalı?
Reklam
Devraldığım neredeyse her sunucunun aynı sessiz problemi vardır: ayarlar çalışır, ancak kimse sana neden bu şekilde olduklarını söyleyemez.
Bir Nginx vhost'unda proxy_read_timeout değeri 300 saniyeye fırlamıştır. Bir fail2ban kuralında belirli bir IP aralığı beyaz listeye (whitelist) alınmıştır. Bir sysctl ayarı bağlantı limitini iki katına çıkarmıştır. Her bir değişiklik muhtemelen yapıldığı o an için doğru hamleydi. Canlı ortamda, stres altında yapıldılar ve sadece o dosyanın içi dışında hiçbir yere not edilmediler. Altı ay sonra kimse hangi satırların sistemi ayakta tuttuğunu, hangilerinin eski bir testten kaldığını hatırlamaz ve kimse o yanlış satırı silen kişi olmak istemez.
En hafif çözüm: etckeeper
Tek bir sunucu için atılabilecek en kullanışlı küçük adım etckeeper aracıdır. /etc dizinini git versiyon kontrolüne alır ve paket yöneticisi bir ayar dosyasına her dokunduğunda otomatik olarak commit'ler:
apt install etckeeper
cd /etc
git log --oneline -10
Bu noktadan sonra, yaptığınız her manuel değişiklik bir sonraki paket yüklemesinde yakalanır veya düzenledikten hemen sonra git add -A && git commit diyerek kendiniz kaydedebilirsiniz. Bunun asıl faydasını, bir ayar değişikliğinden sonra sistem ilk kez patladığında ve şu komutu çalıştırdığınızda görürsünüz:
git log -p -- nginx/sites-enabled/example.com
Neyin, ne zaman değiştiğini ve—eğer bir commit mesajı yazdıysanız—neden değiştiğini tam olarak görürsünüz. Bu son kısım çok önemlidir. git commit -m "yavaş çalışan rapor çıktısı uç noktası için proxy_read_timeout artırıldı" şeklindeki bir not, gelecekteki "siz"in o dosyayı anlayıp güvenle düzenleyebilmesi ile dosyaya dokunmaktan ölesiye korkması arasındaki farktır.
Birden fazla sunucu için: müşteriye özel bir ayar reposu
etckeeper sadece bulunduğu makinede çalışır. Tek bir VPS için sorun değil ancak bir müşterinin birbiriyle bağlantılı üç veya dört sunucusu olduğunda işe yaramaz. Bunlar için, host bazında yapılandırılmış ayrı bir Git reposu tutarım:
client-configs/
├── web-01/
│ ├── nginx/sites-available/example.com
│ └── fail2ban/jail.local
├── db-01/
│ ├── postgresql/postgresql.conf
│ └── pgbackrest/pgbackrest.conf
└── deploy.sh
Değişiklikler önce yerel ortamda (local) yapılır. Hiçbir yere gitmeden önce bir diff üzerinden gözden geçirilir. Ardından, küçük bir deploy.sh betiği yalnızca ilgili dosyaları doğru sunucuya atar:
#!/bin/bash
HOST=$1
rsync -av "$HOST/" "deploy@$HOST.internal:/" --dry-run
# diff mantıklı görünüyorsa --dry-run bayrağını kaldırın
Buradaki --dry-run varsayılanı kasıtlıdır. Ayar dağıtımı (deploy) tam olarak rsync içinde yanlış yere konan tek bir eğik çizginin (/) istenenden çok daha fazlasını üzerine yazabileceği bir işlemdir. Varsayılan --dry-run davranışı, gerçekten değişmeden önce size neyin değişeceğini göstermeye zorlar.
Bunun dokümantasyonun ötesinde sağladığı fayda
Genellikle bunun alternatifi, "önemli ayar değişikliklerini" anlatan bir wiki sayfası veya bir README dosyasıdır. Bunlar neredeyse anında çürür. Çünkü wiki'yi güncellemek ile değişikliği yapmak iki ayrı adımdır ve zaman baskısı altındayken o ikinci adımlar hep atlanır. Git geçmişinin böyle bir sorunu yoktur: kayıt tutmak, zaten o işi yapmanın doğal bir yan ürünüdür.
Ayrıca çalışma alışkanlığınızı da değiştirir. Bir ayar git'te durduğunda, SSH ile sunucuya girip doğrudan canlı dosyayı hacklemek yerine, mantıklı gelen şey dosyayı lokalde düzenlemek, nedenini anlatan bir commit mesajı yazmak ve ardından deploy etmektir. Asıl değer de yedeğe sahip olmaktan çok bu küçük alışkanlık değişiminden gelir: ne yaptığınızı yapmadan hemen önce neden yaptığınızı not alma alışkanlığı.
Üç ay sonra, "acaba şu satırı silsem bir şey bozulur mu" diye ekrana boş boş bakarken, o commit mesajındaki tek bir cümle, sizi bir saat sürecek stresli bir kod arkeolojisinden kurtarır.
Reklam