GCP Cloud Storage Bucket Oluşturma ve Yönetimi

Tarafındankomut
0 Comments

Google Cloud Platform’da nesne depolama ihtiyacınız olduğunda aklınıza gelen ilk şey Cloud Storage oluyor. S3’e alışkın olanlar için tanıdık gelecek ama GCP’nin kendi özellikleri ve terminolojisi var. Bu yazıda sıfırdan bir bucket oluşturmaktan production ortamına hazır güvenli bir yapı kurmaya kadar her şeyi ele alacağız. Hem gcloud CLI hem de Terraform ile örnekler göreceğiz çünkü gerçek hayatta her ikisine de ihtiyaç duyuyorsunuz.

Cloud Storage Temel Kavramları

Başlamadan önce terminolojiyi netleştirelim. GCP Cloud Storage’da her şey bucket (kova) etrafında dönüyor. Bucket’lar proje bazında oluşturuluyor ve içinde object (nesne) saklıyorsunuz. Object dediğimiz şey aslında dosya, yani fotoğraftan log dosyasına, veritabanı yedeğinden statik web sitesi içeriğine kadar her şey olabilir.

Bucket oluştururken dikkat etmeniz gereken birkaç kritik parametre var:

  • Storage Class: Veriye ne sıklıkla erişeceğinizi belirler, maliyeti doğrudan etkiler
  • Location Type: Regional, Dual-region veya Multi-region olarak seçebilirsiniz
  • Access Control: Uniform veya Fine-grained erişim kontrolü
  • Versioning: Silinen veya üzerine yazılan dosyaların önceki sürümlerini saklama

Storage class seçimi özellikle önemli. Günlük eriştiğiniz veriler için Standard, ayda birkaç kez erişeceğiniz için Nearline, yılda bir-iki kez erişeceğiniz için Coldline, arşiv amaçlı kullanım için Archive sınıfını tercih etmelisiniz. Yanlış seçim hem performans hem de maliyet açısından sizi yakabilir.

Ortam Hazırlığı ve gcloud CLI Kurulumu

Önce gcloud CLI’ın kurulu ve authenticate edilmiş olması gerekiyor. Eğer kurmadıysanız:

# Google Cloud SDK kurulumu (Debian/Ubuntu)
curl https://sdk.cloud.google.com | bash
exec -l $SHELL

# SDK'yı başlatma ve kimlik doğrulama
gcloud init
gcloud auth login
gcloud auth application-default login

# Çalışacağınız projeyi ayarlama
gcloud config set project YOUR_PROJECT_ID

# Mevcut yapılandırmayı doğrulama
gcloud config list

Kurulum tamamlandıktan sonra hangi projede çalıştığınızı bir kez daha kontrol edin. Yanlış projede bucket oluşturmak, sonradan temizlemesi zaman alan bir baş ağrısına dönüşebilir.

İlk Bucket’ı Oluşturma

En basit haliyle bucket oluşturmak tek satır. Ama bucket adının globally unique olması gerektiğini unutmayın. Yani tüm GCP kullanıcıları arasında benzersiz olmalı. Bu yüzden proje ID’nizi veya şirket adınızı prefix olarak kullanmak iyi bir pratik.

# Temel bucket oluşturma
gcloud storage buckets create gs://sirketadi-proje-bucket 
    --location=europe-west1 
    --storage-class=STANDARD

# Daha detaylı yapılandırmayla bucket oluşturma
gcloud storage buckets create gs://sirketadi-production-assets 
    --location=europe-west1 
    --storage-class=STANDARD 
    --uniform-bucket-level-access 
    --public-access-prevention

# Mevcut bucket'ları listeleme
gcloud storage buckets list

# Belirli bir bucket'ın detaylarını görme
gcloud storage buckets describe gs://sirketadi-production-assets

--uniform-bucket-level-access parametresi önemli. Bu seçeneği açtığınızda object bazında ACL (Access Control List) kullanımını devre dışı bırakıyorsunuz ve erişim kontrolünü tamamen IAM üzerinden yönetiyorsunuz. Google bu yöntemi öneriyor ve yeni projeler için kesinlikle bu şekilde gitmenizi tavsiye ederim.

--public-access-prevention ise bucket’ı ve içindeki nesneleri yanlışlıkla public yapmayı engelliyor. Production bucket’larına bunu eklemeyi alışkanlık haline getirin.

Dosya Yükleme, İndirme ve Yönetme

Bucket hazır, şimdi içine bir şeyler koyalım:

# Tek dosya yükleme
gcloud storage cp /yerel/dosya.txt gs://sirketadi-production-assets/

# Klasör yükleme (recursive)
gcloud storage cp -r /yerel/klasor/ gs://sirketadi-production-assets/klasor/

# Wildcard kullanımı
gcloud storage cp /log/dizini/*.log gs://sirketadi-production-assets/logs/

# rsync ile senkronizasyon (yalnızca değişen dosyalar)
gcloud storage rsync -r /yerel/web-sitesi/ gs://sirketadi-production-assets/web/

# Dosya indirme
gcloud storage cp gs://sirketadi-production-assets/dosya.txt /yerel/

# Bucket içindeki dosyaları listeleme
gcloud storage ls gs://sirketadi-production-assets/
gcloud storage ls -l gs://sirketadi-production-assets/logs/

# Dosya silme
gcloud storage rm gs://sirketadi-production-assets/eski-dosya.txt

# Klasör silme (recursive)
gcloud storage rm -r gs://sirketadi-production-assets/eski-klasor/

rsync komutunu özellikle vurgulamak istiyorum. Web sitesi deploy süreçlerinde veya düzenli yedekleme işlemlerinde rsync kullanmak, her seferinde tüm dosyaları tekrar yüklemenizi engelliyor. Sadece değişen dosyaları transfer ediyor, bu da hem süreyi hem de maliyeti düşürüyor.

Versioning ve Lifecycle Yönetimi

Gerçek production ortamlarında versioning ve lifecycle policy olmazsa olmaz. Bir dosya yanlışlıkla silindiğinde veya üzerine yazıldığında, versioning sayesinde önceki halini geri getirebiliyorsunuz.

# Versioning'i etkinleştirme
gcloud storage buckets update gs://sirketadi-production-assets 
    --versioning

# Versioning durumunu kontrol etme
gcloud storage buckets describe gs://sirketadi-production-assets 
    --format="value(versioning)"

# Belirli bir dosyanın tüm versiyonlarını listeleme
gcloud storage ls -a gs://sirketadi-production-assets/onemli-dosya.txt

# Eski bir versiyonu geri yükleme
gcloud storage cp 
    "gs://sirketadi-production-assets/onemli-dosya.txt#1699000000000000" 
    gs://sirketadi-production-assets/onemli-dosya.txt

Lifecycle policy ise gereksiz veri birikmesini ve maliyeti kontrol altında tutmanın en iyi yolu. JSON formatında kural tanımlıyorsunuz:

# lifecycle-policy.json dosyası oluşturun
cat > lifecycle-policy.json << 'EOF'
{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "NEARLINE"
        },
        "condition": {
          "age": 30,
          "matchesStorageClass": ["STANDARD"]
        }
      },
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "COLDLINE"
        },
        "condition": {
          "age": 90,
          "matchesStorageClass": ["NEARLINE"]
        }
      },
      {
        "action": {
          "type": "Delete"
        },
        "condition": {
          "age": 365,
          "isLive": false
        }
      }
    ]
  }
}
EOF

# Policy'yi bucket'a uygulama
gcloud storage buckets update gs://sirketadi-production-assets 
    --lifecycle-file=lifecycle-policy.json

# Mevcut lifecycle policy'yi görüntüleme
gcloud storage buckets describe gs://sirketadi-production-assets 
    --format="json(lifecycle)"

Bu örnekteki lifecycle politikası şöyle işliyor: 30 gün sonra Standard’dan Nearline’a geçiyor, 90 gün sonra Coldline’a düşüyor ve eski (non-live) versiyonlar 365 gün sonra siliniyor. Log dosyaları, veritabanı yedekleri gibi verileri yönetmek için ideal bir yaklaşım.

IAM ve Güvenlik Yapılandırması

Bucket güvenliği konusunda en çok gördüğüm hata, servis hesaplarına gereğinden fazla yetki vermek. Principle of least privilege burada hayat kurtarıyor.

# Bucket için mevcut IAM policy'yi görüntüleme
gcloud storage buckets get-iam-policy gs://sirketadi-production-assets

# Belirli bir kullanıcıya okuma yetkisi verme
gcloud storage buckets add-iam-policy-binding gs://sirketadi-production-assets 
    --member="user:[email protected]" 
    --role="roles/storage.objectViewer"

# Servis hesabına yazma yetkisi verme
gcloud storage buckets add-iam-policy-binding gs://sirketadi-production-assets 
    --member="serviceAccount:[email protected]" 
    --role="roles/storage.objectCreator"

# Tüm bucket yönetimi için admin rolü (dikkatli kullanın)
gcloud storage buckets add-iam-policy-binding gs://sirketadi-production-assets 
    --member="serviceAccount:[email protected]" 
    --role="roles/storage.admin"

# Bir üyenin yetkisini kaldırma
gcloud storage buckets remove-iam-policy-binding gs://sirketadi-production-assets 
    --member="user:[email protected]" 
    --role="roles/storage.objectViewer"

Rollerin ne anlama geldiğini hızlıca özetleyelim:

  • roles/storage.objectViewer: Nesneleri okuyabilir, listeleyebilir
  • roles/storage.objectCreator: Yeni nesne oluşturabilir, mevcut olanları okuyabilir
  • roles/storage.objectAdmin: Nesneler üzerinde tam kontrol
  • roles/storage.admin: Bucket dahil her şey üzerinde tam kontrol

Signed URL ile Geçici Erişim

Bazen bir dosyayı dışarıdan biriyle paylaşmanız gerekiyor ama bucket’ı public yapmak istemiyorsunuz. Signed URL tam bu durumlar için var. Belirli bir süre için geçerli olan, authentication gerektirmeyen bir link oluşturuyorsunuz.

# Servis hesabı anahtarı ile signed URL oluşturma
gcloud storage sign-url 
    gs://sirketadi-production-assets/rapor-2024.pdf 
    --duration=1h 
    --private-key-file=/path/to/service-account-key.json

# Impersonation ile (daha güvenli yöntem)
gcloud storage sign-url 
    gs://sirketadi-production-assets/rapor-2024.pdf 
    --duration=24h 
    --impersonate-service-account=signing-sa@proje-id.iam.gserviceaccount.com

Signed URL’lerin süresi dolduğunda link çalışmayı bırakıyor. Müşterilere geçici dosya paylaşımı, CI/CD pipeline’larında artifact dağıtımı gibi senaryolarda çok işe yarıyor.

Terraform ile Infrastructure as Code Yaklaşımı

Production ortamında bucket’ları manuel oluşturmak yerine Terraform kullanmak çok daha sağlıklı. Hem versiyon kontrolü altında tutuyorsunuz hem de ekip içinde tutarlılık sağlıyorsunuz.

# main.tf dosyası içeriği
cat > main.tf << 'EOF'
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

resource "google_storage_bucket" "production_assets" {
  name          = "${var.project_id}-production-assets"
  location      = var.region
  storage_class = "STANDARD"

  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"

  versioning {
    enabled = true
  }

  lifecycle_rule {
    action {
      type          = "SetStorageClass"
      storage_class = "NEARLINE"
    }
    condition {
      age = 30
    }
  }

  lifecycle_rule {
    action {
      type = "Delete"
    }
    condition {
      age            = 365
      with_state     = "ARCHIVED"
    }
  }

  labels = {
    environment = "production"
    team        = "platform"
    managed_by  = "terraform"
  }
}

resource "google_storage_bucket_iam_member" "app_service_account" {
  bucket = google_storage_bucket.production_assets.name
  role   = "roles/storage.objectCreator"
  member = "serviceAccount:${var.app_service_account}"
}

output "bucket_url" {
  value = google_storage_bucket.production_assets.url
}
EOF

# Terraform başlatma ve uygulama
terraform init
terraform plan
terraform apply

Terraform ile bucket yönetmenin en büyük avantajı, terraform destroy ile her şeyi temizleyebiliyor olmanız ve terraform plan ile değişiklikleri önceden görebilmeniz. Özellikle birden fazla ortam (dev, staging, prod) yönetirken bu yaklaşım hayat kurtarıyor.

Gerçek Dünya Senaryosu: Uygulama Logu Yedekleme

Bir web uygulamasının loglarını düzenli olarak Cloud Storage’a göndermek istediğinizi düşünelim. Hem maliyet optimize edilmiş hem de otomatik lifecycle yönetimli bir yapı kuralım:

#!/bin/bash
# log-backup.sh - Crontab ile çalışacak backup scripti

LOG_DIR="/var/log/uygulama"
BUCKET="gs://sirketadi-uygulama-logs"
TARIH=$(date +%Y/%m/%d)
HOSTNAME=$(hostname)

# Bugünün loglarını sıkıştır ve yükle
find "$LOG_DIR" -name "*.log" -mtime -1 | while read dosya; do
    dosya_adi=$(basename "$dosya")
    gzip -c "$dosya" | gcloud storage cp - 
        "${BUCKET}/logs/${TARIH}/${HOSTNAME}/${dosya_adi}.gz"
    
    if [ $? -eq 0 ]; then
        echo "$(date): $dosya_adi başarıyla yüklendi"
    else
        echo "$(date): HATA - $dosya_adi yüklenemedi" >&2
    fi
done

# 7 günden eski local logları temizle (Cloud'da lifecycle ile 90 gün saklıyoruz)
find "$LOG_DIR" -name "*.log" -mtime +7 -delete

echo "Yedekleme tamamlandı: $(date)"

Bu scripti crontab’a ekleyebilirsiniz:

# Her gece 02:00'de çalışacak şekilde crontab'a ekle
echo "0 2 * * * /usr/local/bin/log-backup.sh >> /var/log/backup.log 2>&1" | crontab -

Bu senaryoda bucket için 30 günden sonra Nearline, 90 günden sonra Coldline’a geçiş lifecycle kuralı tanımladığınızda maliyet dramatik şekilde düşüyor. Loglar zaten genellikle eski tarihli olduğunda nadiren erişilir.

Bucket Monitoring ve Alerting

Bucket’larınızı takip etmek de en az oluşturmak kadar önemli. Beklenmedik boyut artışları veya erişim anomalileri erken fark edilmeli:

# Bucket boyutunu kontrol etme
gcloud storage du gs://sirketadi-production-assets

# Detaylı istatistik (recursive)
gcloud storage du -s -r gs://sirketadi-production-assets

# Bucket hakkında genel bilgi
gcloud storage buckets describe gs://sirketadi-production-assets

# Cloud Monitoring ile custom metrik alarm oluşturma
gcloud alpha monitoring policies create 
    --notification-channels="projects/proje-id/notificationChannels/CHANNEL_ID" 
    --display-name="Bucket Boyut Uyarısı" 
    --condition-display-name="Storage Boyutu 100GB Üstü" 
    --condition-filter='resource.type="gcs_bucket" AND metric.type="storage.googleapis.com/storage/total_bytes"' 
    --condition-threshold-value=107374182400 
    --condition-threshold-comparison=COMPARISON_GT

Sık Karşılaşılan Sorunlar ve Çözümleri

Bucket adı çakışması: Bucket adları globally unique olduğu için “bucket already exists” hatası alabilirsiniz. Proje ID’nizi ve ortam adını birleştiren bir naming convention belirleyin. Örneğin ${PROJECT_ID}-${ORTAM}-${AMAÇ} formatı işe yarıyor.

Permission denied hataları: En sık karşılaşılan sorun bu. Servis hesabının doğru role sahip olup olmadığını kontrol edin. --uniform-bucket-level-access açıkken object bazında ACL işe yaramayacağını unutmayın.

Yüksek veri çıkış maliyetleri: Egress ücreti özellikle multi-region senaryolarda can yakıyor. Uygulamanızı bucket ile aynı bölgede çalıştırın. Aynı bölge içindeki veri transferi genellikle ücretsiz.

Silinen dosyaları geri getirme: Versioning açıksa mümkün, değilse imkansız. Bu yüzden production bucket’larında versioning’i her zaman açık tutun.

Sonuç

GCP Cloud Storage, doğru yapılandırıldığında son derece güvenilir ve maliyet etkin bir depolama çözümü sunuyor. Bu yazıda ele aldığımız konuları özetleyecek olursak: bucket oluştururken uniform access control ve public access prevention ile başlayın, production ortamlarında versioning’i mutlaka açık tutun, lifecycle policy ile maliyetleri otomatik yönetin ve servis hesaplarına minimum gerekli yetkileri verin. Altyapınızı Terraform gibi IaC araçlarıyla yönetmek ise uzun vadede hem ekip koordinasyonunu hem de güvenlik auditini kolaylaştırıyor.

Signed URL’leri geçici paylaşımlar için kullanmak, bucket’ları asla gereksiz yere public yapmamak ve monitoring ile olağandışı durumları erken yakalamak güvenli bir Cloud Storage kullanımının temelini oluşturuyor. Bu alışkanlıkları edindiğinizde hem production problemlerini hem de beklenmedik maliyet sürprizlerini büyük ölçüde azaltmış olacaksınız.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir