Linux lab: e-ticaret senaryosunda log, dosya ve yetki yönetimi
Gerçekçi bir senaryoda grep ile log analizi, find ve xargs ile toplu işlem, chmod ile yetkilendirme. Komut ezberi değil, sahada nasıl kullanıldıkları.
Yazıyı okuMerhaba, ben Erdem
IT uzmanı olarak sunucuların, kullanıcıların ve ağın sorunsuz çalışmasını sağlıyorum. Bu tecrübeyi Linux, AWS ve otomasyonla DevOps'a taşıyor, yol boyunca öğrendiklerimi paylaşıyorum.
Bir alan seçin, günlük işlerimde kullandığım komutları görün.
Bir IT uzmanı olarak günlük operasyonda üstlendiğim görevler. Her gün yeni bir şey öğreniyor, kendimi geliştirmeye devam ediyorum.
Çalışanların bilgisayar, yazılım ve donanım sorunlarını hızlı ve kalıcı şekilde çözmek.
Yeni personelin hesaplarını açmak, yetkilerini düzenlemek ve e-posta işlemlerini yürütmek.
İnternet, Wi-Fi ve VPN bağlantı sorunlarını tespit edip çözmek.
Sunucu ve bilgisayarların düzenli kontrolü, yedekleme ve güncelleme süreçlerinde görev almak.
Sahada ve öğrenme sürecimde karşılaştığım konuları, çözüm adımlarıyla birlikte açık ve anlaşılır şekilde paylaşıyorum.
Gerçekçi bir senaryoda grep ile log analizi, find ve xargs ile toplu işlem, chmod ile yetkilendirme. Komut ezberi değil, sahada nasıl kullanıldıkları.
Yazıyı okuÇalışma planı, faydalandığım kaynaklar ve dikkat edilmesi gereken konular.
Yazıyı okuTarayıcıya bir adres yazıldığında arka planda neler olur? DNS'ten TCP bağlantısına adım adım.
Yazıyı okuSistem yönetiminden DevOps'a uzanan planlı bir rota. Her aşamada edindiklerimi burada paylaşıyorum.
Sunucu, kullanıcı ve ağ altyapısının günlük yönetimi. Yolculuğun başladığı yer.
Linux ve ağ bilgisini DevOps için gereken derinliğe taşımak.
AWS üzerinde güvenli ve ölçeklenebilir altyapının yapı taşları.
Kodu versiyonlamak, yayını ve altyapıyı otomatiğe bağlamak.
Uygulamaları her ortamda aynı şekilde çalışacak hale getirmek.
Sistemleri ölçmek, loglamak ve sorunları erken yakalamak.
Sık duyulan terimler, sade bir dille ve örnekleriyle.
Alan adını IP adresine çeviren sistem. İnternetin telefon rehberi gibi düşünebilirsiniz.
Örnek: erdemsoyumer.com → sunucunun IP adresi
IP, bir cihazın ağdaki adresi. Subnet ise bu adresleri mantıklı gruplara bölmek.
Örnek: 192.168.1.0/24 → 254 kullanılabilir adres
Hangi trafiğin içeri girip çıkabileceğine karar veren güvenlik katmanı.
Örnek: Sadece 80 ve 443 portlarına izin ver
Özel ağdaki cihazların tek bir genel IP üzerinden internete çıkmasını sağlar.
Örnek: Ofisteki 50 bilgisayar, tek dış IP
Gelen istekleri birden fazla sunucuya dağıtarak yükü dengeler ve kesintiyi önler.
Örnek: Trafik 3 sunucuya eşit dağıtılır
İstemcinin karşısında duran ve istekleri arkadaki doğru sunucuya ileten ara katman.
Örnek: Nginx, istekleri uygulamaya yönlendirir
Region, bulut sağlayıcının coğrafi bölgesi. AZ ise o bölgedeki birbirinden bağımsız veri merkezleri.
Örnek: eu-central-1 → Frankfurt
Bulutta size ait, izole sanal ağ. Kendi subnet, route ve güvenlik kurallarınızı belirlersiniz.
Örnek: Public ve private subnet ayrımı
Kimin, hangi kaynağa, ne yetkiyle erişebileceğini yöneten kimlik ve yetki servisi.
Örnek: Sadece okuma yetkisi olan kullanıcı
AWS'de kiralayabildiğiniz sanal sunucu. İhtiyaca göre boyutu seçilir, açılıp kapatılır.
Örnek: Bir web sunucusu için t3.micro
Dosyaları "nesne" olarak saklayan, neredeyse sınırsız ölçeklenen depolama servisi.
Örnek: Yedekler, görseller, statik siteler
Yük arttığında sunucu sayısını otomatik artırıp, azaldığında düşüren mekanizma.
Örnek: Kampanya gününde 2 sunucudan 6'ya
Kodun her değişikliğini kaydeden versiyon kontrol sistemi. Hata olursa geri dönebilirsiniz.
Örnek: git commit, git push
Kodun otomatik test edilip (CI) otomatik yayına alınması (CD). Elle deploy derdini bitirir.
Örnek: Push sonrası otomatik yayın
Build, test ve deploy gibi adımların sırayla ve otomatik çalıştığı iş akışı.
Örnek: build → test → deploy
Sunucu ve ağ gibi altyapıyı tıklayarak değil, kodla tanımlayıp kurmak.
Örnek: Terraform ile VPC oluşturmak
Uygulamayı tüm bağımlılıklarıyla birlikte paketleyip her ortamda aynı çalıştıran yapı.
Örnek: "Benim bilgisayarımda çalışıyordu" sorununa çözüm
Çok sayıda container'ı otomatik dağıtan, ölçekleyen ve ayakta tutan orkestrasyon sistemi.
Örnek: Çöken container'ı kendiliğinden yeniden başlatır
Sistemlerin CPU, bellek, disk gibi metriklerini sürekli ölçüp sorunları erken yakalamak.
Örnek: CPU %90'ı geçince alarm
Sistemlerin ve uygulamaların ne yaptığını zaman damgasıyla kaydettiği kayıtlar.
Örnek: Hata anında ilk bakılan yer
Bu aramayla eşleşen terim bulunamadı.
Sorunlara tahminle değil, ölçüm ve analizle yaklaşmayı seviyorum. Bir problemi çözmekle kalmayıp tekrar etmemesi için kalıcı hale getirmeye önem veriyorum. Bu yaklaşımı şimdi bulut ve otomasyon alanına taşıyorum.
Çok lokasyonlu bir yapıda sunucu, kullanıcı ve ağ altyapısının günlük yönetimi.
AWS Solutions Architect sertifikasına hazırlanıyor, Linux ve networking bilgimi derinleştiriyorum.
İş birliği, görüş ya da yazılarla ilgili sorularınız için bana ulaşabilirsiniz. Her mesaja en kısa sürede dönüş yapıyorum.
Linux'u komut ezberleyerek değil, gerçekçi bir senaryo üzerinde çalışarak öğreniyorum. Bu projede hayali bir e-ticaret şirketinin sunucusunu kurguladım ve bir sistem yöneticisinin günlük işlerini adım adım uyguladım.
Hayali bir e-ticaret şirketinin sunucusundayım. Şirketin bir web arayüzü, bir backend servisi, bir veritabanı ve bunların ürettiği loglar var. Bir sistem yöneticisinin her gün karşılaştığı işleri bu ortamda yapıyorum: yapıyı kurmak, loglarda hata aramak, dosyaları bulup toplu işlem yapmak ve kimin neye erişebileceğini belirlemek.
Ortam olarak Windows üzerinde WSL ile çalışan bir Linux kullandım.
Dört klasörü tek tek oluşturmak yerine tek komutla kurdum. Süslü parantezler (brace expansion) shell'in aynı komutu her isim için çoğaltmasını sağlıyor, -p ise üst klasör yoksa onu da oluşturuyor.
$ mkdir -p ~/ecommerce-project/{frontend,backend,database,logs}
$ ls ~/ecommerce-project
backend database frontend logs
Bir sistemde sorun çıktığında ilk bakılan yer loglardır. Binlerce satırlık bir dosyada aradığını bulmak için grep'i farklı seçenekleriyle kullandım:
# Büyük-küçük harf ayırmadan tüm hataları bul
$ grep -i "error" logs/app.log
# Kaç hata var? Satır numaralarıyla göster
$ grep -c "ERROR" logs/app.log
$ grep -n "ERROR" logs/app.log
# Sadece tam kelime eşleşmesi (500 ararken 5000'i getirmesin)
$ grep -w "500" logs/access.log
# INFO satırlarını gizle, gerisini göster
$ grep -v "INFO" logs/app.log
# Hatanın öncesindeki 1, sonrasındaki 2 satırla birlikte
$ grep -B 1 -A 2 "timeout" logs/app.log
# Tüm log klasöründe ara
$ grep -r "payment" logs/
Özellikle -A ve -B çok işe yarıyor. Hata satırı tek başına çoğu zaman yetmiyor; hatadan hemen önce ne olduğunu görmek, sorunun kaynağını bulmayı hızlandırıyor.
find dosyaları isme, türe ya da boyuta göre buluyor. Asıl gücü ise bulduklarını başka bir komuta aktarabilmesinde.
# Projedeki tüm log dosyaları
$ find ~/ecommerce-project -name "*.log"
# Büyük-küçük harf fark etmeksizin
$ find ~/ecommerce-project -iname "readme*"
# Boş dosyaları bul
$ find ~/ecommerce-project -type f -empty
# İçinde ERROR geçen log dosyalarını listele
$ find logs -name "*.log" | xargs grep -l "ERROR"
Silme gibi geri dönüşü olmayan işlemlerde önce sadece listeleyip kontrol ediyorum, sonra işlemi çalıştırıyorum. Yanlış bir find sorgusu, yanlış dosyaları silmek demek.
Bir not: dosya adlarında boşluk olabilecekse find ... -print0 | xargs -0 kullanmak daha güvenli. Aksi halde boşluklu isimler ikiye bölünüyor.
Bir şirkette herkesin her dosyaya erişmesi istenmez. Veritabanı ayarlarını sadece sahibi okuyabilmeli, backend kodunu ekip görebilmeli ama dışarıdan biri görememeli. Bunu chmod ile ayarladım.
Sayısal gösterimde her rakam bir grubu temsil ediyor: sahip, grup ve diğerleri. Okuma 4, yazma 2, çalıştırma 1 puan; toplamları yetkiyi veriyor.
# Veritabanı ayarları: sadece sahibi okuyup yazabilir
$ chmod 600 database/config.env # rw-------
# Backend: grup okuyup girebilir, diğerleri hiçbir şey
$ chmod 750 backend # rwxr-x---
# Frontend: herkes okuyabilir
$ chmod 755 frontend # rwxr-xr-x
# Aynı işin sembolik yazımı
$ chmod u=rwx,g=rx,o= backend
Sayısal yazım hızlı, sembolik yazım ise okunaklı. İkisini de bilmek, başkasının yazdığı scriptleri okurken işe yarıyor.
Terminal renkleri düzgün görünmüyordu. Prompt'u belirleyen PS1 değişkenini ~/.bashrc dosyasına ekleyerek düzelttim:
$ echo 'export PS1="\[\e[1;36m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ "' >> ~/.bashrc
$ source ~/.bashrc
Burada öğrendiğim en önemli şey >> ile > arasındaki fark oldu. >> dosyanın sonuna ekler; tek > ise dosyanın tüm içeriğini siler ve üzerine yazar. Yanlışlıkla tek ok kullanmak, bütün shell ayarlarını kaybetmek demek.
Şu an sed ile dosyalardaki belirli satırları gösterip silmeye başladım:
# Sadece 5. satırı göster
$ sed -n '5p' logs/app.log
# 3. satır olmadan göster (dosya değişmez)
$ sed '3d' logs/app.log
sed varsayılan olarak dosyayı değiştirmiyor, sonucu ekrana basıyor. Dosyanın kendisini düzenlemek için -i gerekiyor. Sıradaki adımlar metin değiştirme, awk ve bunları birleştiren Bash scriptleri.
AWS Certified Solutions Architect – Associate (SAA-C03) sınavına hazırlanırken izlediğim yolu, kullandığım kaynakları ve özellikle dikkat edilmesi gereken konuları bir araya getirdim.
SAA-C03, AWS üzerinde güvenli, dayanıklı, performanslı ve maliyet açısından verimli mimariler tasarlama becerisini ölçüyor. Sorular senaryo tabanlı; "şu servis nedir" yerine "bu şirketin ihtiyacına en uygun çözüm hangisi" diye soruluyor.
Ağırlıklara bakınca en büyük payın güvenlikte olduğu görülüyor. Çalışma süremi de buna göre dağıtıyorum.
AWS'nin yayınladığı sınav rehberi, hangi konuların kapsamda olduğunu açıkça listeliyor. Her konuyu bir kontrol listesine dönüştürüp ilerledikçe işaretliyorum. Böylece neyi bilmediğimi görebiliyorum.
Servisleri okumakla kurmak arasında büyük fark var. Free Tier hesabında kendi VPC'mi oluşturup public ve private subnet'ler, bir EC2 sunucusu ve güvenlik kuralları kurduğumda konular çok daha kalıcı oldu.
İlk iş olarak AWS Budgets ile düşük tutarlı bir bütçe alarmı kurun. Açık unutulan tek bir kaynak, beklenmedik bir fatura demek.
Deneme sınavlarında puandan çok yanlışlarım önemli. Her yanlış cevap için "neden yanlış seçtim, doğrusu neden doğru" sorularının cevabını kısa bir not olarak yazıyorum. Tekrar ederken en çok bu notlar işe yarıyor.
AWS'nin mimari en iyi uygulamalarını anlatan bu çerçeve, sınavdaki "en uygun çözüm" sorularının arkasındaki mantığı anlamamı sağladı.
Sınava girdikten sonra bu yazıyı sonuç ve sınav günü deneyimimle güncelleyeceğim.
Tarayıcıya bir adres yazıp Enter'a bastığınızda saniyeden kısa bir sürede onlarca şey olur. OSI katmanlarını ezberlemek yerine, tek bir isteğin yolculuğunu baştan sona takip edelim.
Örneğimiz basit: tarayıcıya erdemsoyumer.com yazdınız. Sayfanın ekrana gelmesine kadar geçen yolculuğu beş durakta inceleyeceğiz.
Bilgisayarlar isimlerle değil IP adresleriyle konuşur. İlk iş, alan adını IP adresine çevirmek. Tarayıcı önce kendi önbelleğine, sonra işletim sistemine bakar. Cevap yoksa soru DNS sunucusuna gider ve oradan alan adının yetkili sunucusuna kadar ilerler.
$ dig +short erdemsoyumer.com
Akılda kalsın: DNS = İsim → IP. İnternetin telefon rehberi.
IP adresi elimizde. Şimdi bilgisayar şunu sorar: Bu adres benim ağımda mı? Değilse paketi doğrudan gönderemez, ağdan çıkış kapısı olan default gateway'e (genellikle modem ya da router) teslim eder.
Gateway'e ulaşmak için onun MAC adresi gerekir. Bunu da ARP ile öğrenir: "Bu IP kimde?" diye ağa sorar, gateway cevap verir.
$ ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link
Akılda kalsın: Aynı subnet ise doğrudan, farklı subnet ise gateway üzerinden.
Paket internete çıktı ve router'lar arasında hedef sunucuya ulaştı. Ama veri göndermeden önce iki taraf bağlantıyı kurmak zorunda. Buna TCP üçlü el sıkışması denir:
Web siteleri https için 443, http için 80 numaralı portu kullanır. Port, sunucudaki doğru uygulamaya ulaşmayı sağlayan kapı numarasıdır.
$ nc -zv erdemsoyumer.com 443
Connection to erdemsoyumer.com 443 port [tcp/https] succeeded!
Bağlantı kuruldu ama henüz şifreli değil. https'teki "s" burada devreye girer. Sunucu kimliğini kanıtlamak için SSL/TLS sertifikasını gönderir, tarayıcı bu sertifikanın güvenilir bir otoriteden geldiğini doğrular. Ardından iki taraf, sonraki tüm trafiği şifreleyecek anahtarlar üzerinde anlaşır.
Tarayıcıdaki kilit simgesi, bu adımın başarıyla tamamlandığını gösterir.
Ancak şimdi asıl istek gönderilebilir: "Bana ana sayfayı ver." Sunucu bir durum koduyla cevap verir. 200 her şey yolunda, 301 yönlendirme, 404 bulunamadı, 500 sunucu hatası demektir.
$ curl -I https://erdemsoyumer.com
HTTP/2 200
content-type: text/html
Tarayıcı gelen HTML'i okur, sayfayı çizer. Bütün bu yolculuk çoğu zaman bir saniyenin altında tamamlanır.
"Site açılmıyor" şikâyetinde rastgele denemek yerine aynı yolu adım adım kontrol etmek, sorunu hızla daraltır:
dig ile alan adı doğru IP'ye çözülüyor mu?ip route ve ping ile ağdan çıkış var mı?nc -zv ile hedef port açık mı, araya firewall giriyor mu?curl -I ile sunucu hangi durum kodunu dönüyor?Sorun hangi durakta başlıyorsa, çözüm de oradadır.