GCE VM Nedir ve Google Cloud’da VPC Üzerine GCE VM Kurulumu

Öncelikle, neden kendi VPC ağımıza bir GCE VM instance’ı kurmanın nedenlerine gelmeden önce, kısaca GCE instance’ı nedir, gelin onu inceleyelim.

GCE instance (Google Compute Engine instance), Google Cloud Platform üzerinde çalışan sanal makinelerdir. Fiziksel bir sunucuya ihtiyaç duymadan, Google’ın veri merkezlerinden bizim için ayrılmış olan sanal bir bilgisayardır.

Bunu basitçe şu şekilde düşünebilirsiniz: Eskiden sunucu kiralamak için veri merkezine başvurur, donanım satın alır ya da hosting firmalarıyla anlaşırdık. Şimdi ise GCE (Google Compute Engine) ile, birkaç tıklama veya bir komut satırı üzerinden CPU, RAM, disk ve işletim sistemi seçip dakikalar içinde yeni bir makine ya da bilgisayar ayağa kaldırabiliyoruz.

GCE instance’ların temel özellikleri şu şekildedir:

1. Ölçeklenebilirlik: İhtiyacımıza göre küçük bir makineden (örneğin 1 vCPU, 0.5 GB RAM) çok güçlü bir makineye (örneğin 96 vCPU, terabaytlarca RAM) kadar seçim yapabiliriz.
2. İşletim Sistemi Seçimi: Linux dağıtımları (Ubuntu, Debian, CentOS) veya Windows Server kurma imkânı tanır.
3. Disk Seçimleri: SSD ya da HDD tabanlı disk tanımlama imkânı sunar.
4. Ağ Yapısı (VPC): Sanal makinemizi Google Cloud VPC’ye (Virtual Private Cloud) bağlarız. Böylece güvenlik, firewall kuralları ve IP yönetimi tamamen bizim kontrolümüzde olur.
5. Otomasyon: Her GCE instance’ını ayağa kaldırdığımızda her seferinde tek tek program kurmak, ayar yapmak veya ortam hazırlamak istemeyiz. Bunun yerine “başlangıç betiği (startup script)” çalıştırabiliriz. Böylece sadece “makineyi başlat” dediğimizde her şey hazır hale gelir.
6. Kullanım Modeli: Saatlik/dakikalık kullanım üzerinden ücretlendirilir. Yani “kullandığın kadar öde” mantığı işler.

GCE’nin temel özellikleri diğer platformlardakilere benzer olsa da, GCE’yi ayıran özellikler vardır. Onlara değinmek istersek şunlardır:

1. Global VPC ile ağ mimarisi: Diğer platformlarda (AWS/Azure) VPC bölgesel çalışırken, GCE’de tek bir VPC ile tüm bölgelerde (region’lar) subnet’ler oluşturabilirsiniz ve bu ek ücrete tabi de değildir. (VPC hakkında detaylı bilgi için şu yazımı okuyabilirsiniz.)
2. Live Migration (kesintisiz taşıma): Bakım, patch veya donanım arızalarında bile instance’lar kapatılmadan başka bir host’a taşınabilir. Diğer platformlarda (AWS/Azure) ise çoğu durumda instance’lar yeniden başlatılır; bu da downtime’a sebep olur.

Peki GCE’yi bu kadar anlattık ve avantajlarından da bahsettik; fakat gerçekten de GCE instance’ları nerelerde ve ne için kullanılır? Biraz da bundan bahsetmek istiyorum.

Çeşitli web uygulamaları barındırmak (.NET Core vb.), veritabanı sunucusu çalıştırmak (SQL Server, PostgreSQL vb.), makine öğrenmesi/AI eğitimleri için GPU destekli makineler, deneme ve test ortamları kurmak, arka plan iş yükleri veya batch işlemleri için kullanabiliriz.

GCE instance’ları Google Bulut’unda bize ait olan bir bilgisayar gibidir — aslında bir nevi de öyle. İstediğimiz zaman açıp kapatabileceğimiz, büyütüp küçültebileceğimiz bir “sanal sunucudur”.

Fiziksel cihazın karmaşasından kurtarıp bizi tamamen sisteme odaklı bir mimariye yaklaştırır.

Şimdi ise asıl konumuz olan “neden GCE instance’larımızı VPC üzerine kurmalıyız” ona bakalım.

VPC, bir şirketin ya da bir projenin buluttaki omurgasıdır. VM’lerimiz, veritabanlarımız, servislerimiz bu özel ağda, kontrollü giriş kapılarıyla (firewall, route) aracılığıyla konuşur. VM’yi VPC’nin üzerine koymak, güvenlik, yönetim ve gözlemlenebilirlikte (IAM, etiketler, loglar) tek nokta sağlar.

Bu mimariye (VPC) kuş bakışıyla bakmak istersek şu şekilde gözükür:

İnternet ──> A. [Firewall Rules: HTTP/HTTPS/SSH] ──> VPC ──> Subnet ──> GCE (web-sunucu)
            │
            └── B. (Alternatif) IAP tüneli ile yönetim

Seçenek A (genel IP ile): Dış dünyadan HTTP/HTTPS istekleri geldiğinde makineye atanan IP adresi üzerinden gelir. SSH için sadece belirli IP’ler tercih edilir (örn. ofis IP’si, VPN çıkış IP’si). Burada trafiğin yönünü firewall ile yönetiriz. Web trafiği için genelde 80/443 portuyla herkes erişir; yönetim trafiği ise (22) ile sınırlıdır.

Seçenek B (genel IP yok + IAP): Yönetim trafiği yalnızca Google’ın IAP aralığından içeri alınır. Yani makinemiz dış dünyaya kapalı; sadece Google’ın IAP servisinden kimlik doğrulaması yaparak erişebiliriz. Eğer içeriden dışarıya çıkış yapması gerekiyorsa trafiği VPC içinden “NAT Gateway” üzerinden gönderir. Burada NAT içeriden dışarıya çıkış sağlıyor ama dışarıdan içeri doğrudan erişim imkânı vermiyor.

Seçenek A: Genel IP ile Web VM (Nginx)

Kimler için? İlk kez VM açacak olanlar. Hedefimiz 15 dakikada statik IP’li bir Linux VM üzerinden Nginx ile “hoş geldin” sayfası göstermek.

Neden bu yolu tercih ettik? Daha anlaşılır ve daha yönetilebilir olduğundan dolayı.

A0) Cloud Shell ile başlayın Console’dan sağ üstte “Activate Cloud Shell” butonuna tıklayın. İlk defaysa yetkileri onaylayın; sağ altta bir terminal açılacak.

VM kurmadan önce şu ön koşulları sağlamanız gerekmektedir:

• gcloud yapılandırılmış olmalı: gcloud init
• Projede Compute API açık olmalı: gcloud services enable compute.googleapis.com
• Mevcut bir VPC ve alt ağ (subnet) olmalı: İsimlerini aşağıdaki komutlarla bulabilirsiniz.

gcloud compute networks list
gcloud compute networks subnets list --regions="europe-west1"

1.resim

A1) Statik (sabit) dış IP ayrımı Dış dünyadan erişilecek sabit bir IPv4 adresi tahsis ediyoruz. Bu adres (regional) bir adrestir ve VM bulunduğu bölgeyle (zone) aynı bölgede olmalıdır. VPC adı burada önemli değildir. IP adresi VPC’ye değil, VM’ye bağlanır.

Peki neden statik IP? Geçici (ephemeral) IP, VM yeniden başlatıldığında değişebilir; DNS/SSL kurulumunu bozar. Statik IP ise isimlendirebildiğiniz, kalıcı bir adrestir. Not: Boşta duran statik IP’lerin ücretlendirilmesi olur. İşiniz bitince serbest bırakmamız gerekir.

A1.1) Tahsis edilecek olan IP adresi ile alt ağ (subnet) bölgesi uyuşuyor mu? Elimizde var olan VPC: “first-vpc” olarak adlandırdık, subnet’imiz ise “web-subnet” olarak açılmış. IPv4 tahsis etmeden önce bu değeri öğrenmemiz kritik. Subnet’in bulunduğu bölge (region) ile tahsis edilecek olan IPv4 aynı region’a sahip olmalıdır.

Aşağıdaki komutlarla subnet’imizin region’ını öğrenebiliriz.

2.resim

export SUBNET_NAME="web-subnet"
gcloud compute networks subnets list --filter="name=$SUBNET_NAME" --format="table(name, region)"

A1.2) Statik IPv4 adresi tahsis edilmesi Bir isim veriyoruz, örneğin “web-ip”. Bu IP henüz hiçbir yere bağlı değil; sadece bizim projemize ayrılmış durumdadır.

3.resim

# Statik IPv4 rezervasyonu
gcloud compute addresses create web-ip \
  --region="$REGION" \
  --description="Static IPv4 for web-sunucu"

# IP değerini bir değişkene alalım
export STATIC_IP=$(gcloud compute addresses describe web-ip \
  --region="$REGION" --format='value(address)')

echo "Ayrılan IP: $STATIC_IP"

4.resim

A1.3) Doğrulama ve sık hata kontrolleri IP listemizde var mı kontrol edelim.

gcloud compute addresses list --regions="$REGION" --filter="name=web-ip" \
  --format="table(name,address,status,region)"

5.resim

Hata: Görüldüğü üzere IP listemizde tahsis ettiğimiz IP adresi duruyor. Eğer IP adresindeki region ile subnet aynı region’da değilse, IP’yi doğru bölgeye tahsis edin. VM ile IP adresi eşleşmeli!

A2) Güvenlik duvarı kuralları (HTTP/HTTPS/SSH) Burada en kritik konu “target-tags” etiketleridir. Eğer tanımladığımız kuralları yanlış etiketlere verirsek kaos ortamına sebebiyet vermiş oluruz.

SSH daraltma

MY_IP="$(curl -s ifconfig.me)" # Bulunduğunuz yerin dış IP’si

gcloud compute firewall-rules create ${VPC_NAME}-allow-ssh \
  --network="$VPC_NAME" --direction=INGRESS --priority=1000 --action=ALLOW \
  --rules=tcp:22 --source-ranges=${MY_IP}/32 --target-tags=ssh

Tehlike: --source-ranges=0.0.0.0/0 tüm dünyaya açar.

HTTP ve HTTPS:

gcloud compute firewall-rules create ${VPC_NAME}-allow-http \
  --network="$VPC_NAME" --direction=INGRESS --priority=1000 --action=ALLOW \
  --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=http

gcloud compute firewall-rules create ${VPC_NAME}-allow-https \
  --network="$VPC_NAME" --direction=INGRESS --priority=1000 --action=ALLOW \
  --rules=tcp:443 --source-ranges=0.0.0.0/0 --target-tags=https

A3) VM Oluşturma (Debian 12 + Nginx otomatik kurulum) --tags=http,https,ssh ile firewall kurallarını bu VM’ye bağlayacağız.

gcloud compute instances create web-sunucu \
  --zone="$ZONE" \
  --machine-type=e2-medium \
  --subnet="$SUBNET_NAME" \
  --address="$STATIC_IP" \
  --tags=http,https,ssh \
  --labels=env=demo,app=web,owner=cengiz \
  --image-family=debian-12 --image-project=debian-cloud \
  --boot-disk-size=20GB --boot-disk-type=pd-balanced \
  --metadata=startup-script='#!/bin/bash
set -eux
apt-get update
apt-get install -y nginx
systemctl enable nginx
systemctl restart nginx
'

6. resim

Artık makinemiz tamamen ayakta.

A5) Sayfa gelmiyor:

• Statik IP doğru mu? gcloud compute instances describe web-sunucu --zone="$ZONE" --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
• VM’nin etiketleri uygun mu? gcloud compute instances describe web-sunucu --zone="$ZONE" --format='get(tags.items)'
• Firewall kuralları var mı? gcloud compute firewall-rules list --filter="network:$VPC_NAME"
• Nginx çalışmıyor: journalctl -u nginx -n 50 --no-pager ile hataya bakın, systemctl restart nginx deneyin.
• SSH erişemiyorum: IP kısıtı fazla dar olabilir. Geçici olarak ofis dışından bağlanıyorsanız --source-ranges alanını genişletip sonra tekrar daraltın.

Sık yapılan hatalar:

• Firewall hedef etiketi unutuluyor: Kural var ama VM’ye aynı etiket verilmemiş; trafik düşer.
• Genel IP yok ama HTTP test ediliyor: IAP sadece yönetimi tüneller; HTTP için ya genel IP ya da Load Balancer gerekir.
• Kaynak aralığı geniş: 0.0.0.0/0 ile SSH açmak yerine ofis IP’lerine daraltın.

Yeni başlayan olarak şunu gördüm ki GCE VM açmak bir varış değil; asıl iş, onu VPC üzerinde etiket, IAM ve firewall politikalarıyla yönetmek. Sonrasında ise HTTPS Load Balancer ve MIG ile kurumsal standarda doğru yürümek. Çünkü bulutta kalıcı başarı, tek bir sunucudan değil; politikası yazılmış bir ağdan doğar. Bugün ilk taşı koydum.