VMware Cloud Foundation ortamlarında offline depot hazırlamak, dışarıdan bakıldığında basit bir web sunucusu kurulumundan ibaret gibi görünebilir. Ancak işin içine gerçek üretim ortamları, güvenlik gereksinimleri, doğru dizin yapısı, erişim kontrolleri ve internet erişimi olmayan dark site senaryoları girdiğinde süreç tahmin edilenden çok daha karmaşık hale gelir.
Özellikle air-gapped yapılarda VCF Installer ya da SDDC Manager’ın ihtiyaç duyduğu dosyalara doğru formatta, doğru path altında ve kesintisiz şekilde erişebilmesi gerekir. Aksi halde küçük bir dizin hatası, eksik bir yetki, yanlış yapılandırılmış TLS sertifikası ya da hatalı bir URL tüm sürecin durmasına neden olabilir.
Offline VCF Depot Neden Gereklidir?
Kurumsal yapılarda her altyapı bileşeninin internete doğrudan erişmesi istenmez. Finans, kamu, savunma, üretim ve yüksek güvenlik gerektiren ortamlarda sistemler genellikle dış dünyadan izole edilir. Bu tür yapılarda VMware Cloud Foundation bileşenlerinin güncelleme paketlerine, bundle dosyalarına veya kurulum medyalarına erişebilmesi için iç ağda konumlandırılmış güvenilir bir depot sunucusu kullanılır.
Offline VCF depot, bu noktada merkezi bir kaynak görevi görür. SDDC Manager veya VCF Installer, internet üzerindeki public repository yerine bu dahili sunucuya bağlanarak gerekli paketleri indirir. Böylece hem güvenlik politikalarına uyum sağlanır hem de güncelleme ve kurulum süreçleri kontrollü bir şekilde yönetilebilir.

Sürecin Göründüğünden Daha Zor Olmasının Nedeni
Offline depot hazırlarken yalnızca Apache ya da Nginx kurmak yeterli değildir. Web sunucusunun doğru şekilde yapılandırılması, TLS desteğinin eklenmesi, erişim kontrolünün sağlanması ve dosya ağacının VMware’in beklediği formata uygun olması gerekir.
Örneğin VCF tarafında beklenen PROD/ dizin yapısında yapılacak küçük bir hata bile SDDC Manager’ın “Path not found” hatası vermesine yol açabilir. Bu hata çoğu zaman paket eksikliğinden değil, yanlış yerleştirilmiş bir dosyadan, hatalı klasör isminden veya eksik web erişiminden kaynaklanır.
Benzer şekilde authentication tarafında htpasswd kullanılıyorsa kullanıcı adı, parola ve web server location tanımlarının doğru çalışması gerekir. TLS tarafında ise self-signed sertifika mı kullanılacağı, yoksa Let’s Encrypt gibi bir yapı üzerinden geçerli sertifika mı alınacağı netleştirilmelidir. Üretim ortamlarında bu detaylar, yalnızca kurulum kolaylığı açısından değil, güvenlik standartları açısından da önemlidir.
Apache veya Nginx ile Depot Yayınlamak
Offline depot için genellikle Apache ya da Nginx tercih edilir. Her iki web server da bu iş için uygundur, ancak yapılandırma dikkatli yapılmalıdır.
Nginx kullanıldığında sade ve performanslı bir static file serving yapısı kurulabilir. Apache tarafında ise directory listing, authentication ve access control gibi özellikler kolayca yönetilebilir. Hangi web server seçilirse seçilsin temel hedef aynıdır: VCF bileşenlerinin beklediği URL path’lerini eksiksiz ve doğru şekilde yayınlamak.
Burada önemli nokta, depot sunucusunun yalnızca dosya barındıran basit bir sunucu olarak görülmemesidir. Bu sunucu, VCF lifecycle operasyonlarının bir parçası haline gelir. Dolayısıyla servis sürekliliği, güvenlik, log yönetimi ve erişilebilirlik mutlaka düşünülmelidir.
TLS, htpasswd ve Güvenli Erişim
Depot sunucusu iç ağda çalışıyor olsa bile güvenlik ihmal edilmemelidir. TLS kullanımı, özellikle production ortamlarda önerilen bir yaklaşımdır. Bu sayede SDDC Manager ile depot sunucusu arasındaki trafik şifrelenir.
Erişim kontrolü için htpasswd kullanılabilir. Böylece depot içeriğine yalnızca yetkili sistemlerin veya kullanıcıların erişmesi sağlanır. Ancak burada yapılan küçük bir hata bağlantı problemlerine neden olabilir. Örneğin web server authentication beklerken SDDC Manager tarafında kullanıcı bilgileri yanlış tanımlanmışsa bağlantı başarısız olur. Aynı şekilde yanlış realm, hatalı location bloğu veya eksik permission da sorun yaratabilir.
Bu nedenle kurulumdan sonra yalnızca web tarayıcısı ile test yapmak yeterli değildir. VCF Installer veya SDDC Manager’ın gerçekten hangi endpoint’leri kontrol ettiğini doğrulayan bir verify script kullanmak çok daha sağlıklı bir yaklaşımdır.
Dark Site Ortamlarında Ek Zorluklar
İnternet erişimi olmayan dark site ortamlarında süreç daha da hassas hale gelir. Çünkü depot host üzerinde paket indirme, sertifika alma veya dış repository’lere bağlanma imkânı bulunmaz. Gerekli tüm dosyaların, script’lerin, sertifika bilgilerinin ve konfigürasyonların önceden hazırlanması gerekir.
Bu tür yapılarda iki aşamalı bir workflow oldukça kullanışlıdır. İlk aşamada internet erişimi olan bir sistemde gerekli içerikler hazırlanır. İkinci aşamada ise bu içerikler air-gapped ortama taşınarak depot sunucusu üzerinde kurulum tamamlanır. Böylece internet bağımlılığı olmayan, kontrollü ve tekrar edilebilir bir kurulum modeli elde edilir.
systemd Hardening ve Firewall Kuralları
Depot sunucusu production ortamda çalışacağı için yalnızca web servisini ayağa kaldırmak yeterli değildir. systemd hardening ile servis daha güvenli hale getirilebilir. Örneğin gereksiz dosya sistemi erişimleri sınırlandırılabilir, servis kullanıcısının yetkileri daraltılabilir ve process izolasyonu artırılabilir.
Firewall tarafında da yalnızca gerekli portların açılması gerekir. Genellikle HTTP veya HTTPS erişimi yeterlidir. Yönetim erişimleri ise ayrı kurallarla sınırlandırılmalı, mümkünse yalnızca belirli yönetim IP’lerinden erişime izin verilmelidir.
Bu yaklaşım, depot sunucusunun hem işlevsel hem de güvenlik açısından daha kontrollü çalışmasını sağlar.
Otomasyon Neden Büyük Avantaj Sağlar?
Offline VCF depot kurulumu elle yapıldığında tekrar eden, hata yapmaya açık ve zaman alan bir süreçtir. Her ortamda aynı adımların yeniden uygulanması gerekir: web server kurulumu, vhost tanımı, TLS yapılandırması, authentication ayarları, dosya ağacının hazırlanması, firewall kuralları, servis sertleştirme ve doğrulama testleri.
Bu nedenle süreci otomatikleştiren bir araç ciddi zaman kazandırır. Tek seferlik installer ile canlı preview sunan, Let’s Encrypt entegrasyonu sağlayan, Cloudflare veya Route53 credential bilgilerini gömülü şekilde kullanabilen ve air-gapped ortamlar için iki script’li workflow üretebilen bir yapı, operasyonel yükü büyük ölçüde azaltır.
En büyük avantaj ise standartlaşmadır. Her kurulumda aynı dizin yapısı, aynı güvenlik yaklaşımı ve aynı doğrulama mantığı kullanılır. Böylece “bir yerde çalışıyor ama diğer ortamda hata veriyor” gibi klasik problemler minimuma iner.
Offline VCF depot kurulumu, ilk bakışta basit bir web server hazırlığı gibi görünse de production ve dark site ortamlarında dikkat isteyen bir süreçtir. Doğru PROD/ dizin yapısı, güvenli TLS yapılandırması, htpasswd erişim kontrolü, systemd hardening, firewall kuralları ve gerçekçi doğrulama testleri olmadan sağlıklı bir yapı kurmak zordur.
Bu nedenle sürecin otomasyonla yönetilmesi hem zaman kazandırır hem de hata riskini azaltır. Özellikle VCF ortamlarında lifecycle yönetiminin kesintisiz devam edebilmesi için offline depot yapısının güvenilir, tekrar edilebilir ve kolay doğrulanabilir şekilde hazırlanması büyük önem taşır.
Detaylar ve araç için:
https://tools.virtualbytes.io/vcf-offline-depot-generator
![[TR] Offline VCF Depot Hazırlanması = Air-Gapped Ortamlar İçin Daha Hızlı ve Güvenilir Bir Yaklaşım](https://kadirkozan.com/wp-content/uploads/2026/02/VMware-logo-featured-1.jpg)
![[TR] Her İnternet Kullanıcısının Bu Hafta Sonu Kontrol Etmesi Gereken Web Siteleri](https://kadirkozan.com/wp-content/uploads/2026/03/iStock-479801118-150x150.jpg)