HPE Morpheus Enterperise farklı sanallaştırma, bulut ve otomasyon altyapılarını tek bir merkezi panel üzerinden yönetmeye imkân sağlayan güçlü bir bulut yönetim platformudur.

Bu platform üzerinde sanal makine oluşturma, uygulama dağıtımı, self-servis katalog kullanımı, Terraform tabanlı altyapı yönetimi, PXE boot ile fiziksel sunucu kurulumu ve çok katmanlı uygulama provizyonu gibi birçok işlem merkezi olarak yönetilebilir.

Bu işlemlerin nasıl davranacağını belirleyen en önemli alanlardan biri ise Administration → Settings → Provisioning sekmesidir.

İlk bakışta bu ekran yalnızca birkaç onay kutusundan ve varsayılan değer alanından oluşuyor gibi görünebilir. Ancak aslında Morpheus platformunun provizyon davranışını doğrudan etkileyen oldukça kritik bir yapılandırma ekranıdır. Burada yapılan ayarlar yalnızca tek bir kullanıcıyı veya tek bir projeyi değil, çoğu zaman tüm tenant’ları, kullanıcıları, grupları ve self-servis deneyimini etkiler.

Bu nedenle Provisioning sekmesi görünürde sade ama etkisi büyük bir yönetim alanıdır. Küçük bir kutucuğun işaretlenmesi bile kullanıcıların kaynak oluşturma sırasında ne göreceğini hangi seçimleri yapabileceğini, hangi alanların zorunlu olacağını ve platformun kaynakları nasıl yöneteceğini değiştirebilir.

Doğru yapılandırılmış bir Provisioning ekranı kullanıcıların hata yapma ihtimalini azaltır, kaynakların standartlara uygun şekilde oluşturulmasını sağlar, isimlendirme ve etiketleme disiplinini korur, maliyet farkındalığını artırır ve operasyon ekiplerinin iş yükünü azaltır.

Yanlış veya plansız yapılandırılmış bir Provisioning ekranı ise kullanıcıları gereksiz seçeneklerle baş başa bırakabilir, hatalı cloud veya datastore seçimlerine neden olabilir, tenant’lar arasında isim çakışmaları oluşturabilir ve ileride yönetilmesi zor bir altyapı karmaşasına yol açabilir.

Bu nedenle bu alanı yalnızca “ayar ekranı” olarak değil platformun kaynak oluşturma davranışını şekillendiren merkezi bir politika alanı olarak değerlendirmek gerekir.

Provisioning Yapılandırmasının Temel Amacı

Provisioning, en basit haliyle bir kaynağın otomatik olarak oluşturulması anlamına gelir. Bu kaynak bir sanal makine, uygulama, katalog servisi, Linux veya Windows sunucusu, Terraform altyapısı ya da PXE boot ile kurulacak fiziksel bir sistem olabilir.

Morpheus üzerinde bir kullanıcı yeni bir kaynak oluşturmak istediğinde arka planda birçok karar alınır;

• Kaynak hangi cloud üzerinde oluşturulacak?
• Hangi host veya cluster kullanılacak?
• Hangi datastore’a yazılacak?
• Hangi network’e bağlanacak?
• Linux sistemlerde hangi kullanıcı adı ve SSH anahtarı kullanılacak?
• Windows sunucularda Administrator parolası ne olacak?
• Kaynak Dev, Test veya Production gibi hangi ortama ait olacak?
• Kullanıcı fiyat bilgisini görecek mi?
• Self-servis katalogda hangi seçenekler listelenecek?

İşte Administration → Settings → Provisioning ekranı bu kararların bir kısmını merkezi olarak belirler.

Bu ekranın temel amacı kullanıcıya verilecek özgürlük ile platformun sağlayacağı standartlaşma arasında doğru dengeyi kurmaktır. Bazı kurumlarda kullanıcıların cloud, ortam ve kaynak tipini özgürce seçmesi istenir. Bazı kurumlarda ise kullanıcı yalnızca onaylanmış katalog öğelerini görmeli, geri kalan teknik kararları platform otomatik vermelidir.

Bu nedenle Provisioning ayarlarında tek bir doğru yoktur. Doğru yapılandırma kurumun operasyon yapısına, tenant modeline, güvenlik politikasına, maliyet yönetimi yaklaşımına ve kullanıcı profiline göre belirlenmelidir.

a) Provisioning Settings

Provisioning Settings bölümü kullanıcıların yeni bir kaynak oluştururken karşılaşacağı ekranları ve seçimleri belirler. Bu alanı, Morpheus provizyon sihirbazının kullanıcıya görünen yüzünü tasarladığınız yer olarak düşünebilirsiniz.

Burada verilecek kararların çoğu şu soruya dayanır;

Kullanıcının bu kararı kendisinin vermesini istiyor muyuz, yoksa bu kararı platformun otomatik ve kontrollü şekilde vermesi daha mı doğru?

Bu soruya verilen cevap her ayarın açık veya kapalı olmasını doğrudan etkiler.

1) Allow Cloud Selection

Allow Cloud Selection kullanıcının provizyon sırasında hedef cloud ortamını kendisinin seçip seçemeyeceğini belirler.

Bu ayar açık olduğunda kullanıcı yetkisi dahilindeki cloud ortamları arasından seçim yapabilir. Örneğin VMware, Hyper-V, Nutanix, AWS, Azure veya başka bir entegre altyapı varsa kullanıcı hangi ortamda kaynak oluşturacağını belirleyebilir.

Bu özellik özellikle birden fazla cloud ortamıyla çalışan teknik ekipler için kullanışlıdır. Kullanıcı hangi altyapıya dağıtım yapacağını biliyorsa, cloud seçimini kendisinin yapması esneklik sağlar.

Ancak her kullanıcıya cloud seçimi yaptırmak her zaman doğru bir yaklaşım değildir. Özellikle self-servis yapıların son kullanıcıya açıldığı ortamlarda yanlış cloud seçimi ciddi sorunlara yol açabilir. Kullanıcı test ortamı için üretim cloud’unu seçebilir, düşük öncelikli bir workload’u yüksek maliyetli bir altyapıya taşıyabilir veya kendi tenant’ı için uygun olmayan bir hedefe kaynak oluşturmaya çalışabilir.

Bu ayar kapalı olduğunda hedef cloud seçimi kullanıcının rolüne, grubuna, tenant atamasına veya blueprint/katalog yapılandırmasına göre otomatik belirlenir. Böylece kullanıcı yanlış bir ortama kaynak açamaz.

Kısacası teknik ekiplerin bilinçli seçim yapacağı ortamlarda açık bırakılabilir. Daha standart, kontrollü ve hata toleransı düşük self-servis yapılarda ise kapalı tutulması daha doğru olur.

2) Allow Host Selection

Allow Host Selection sanal makinenin hangi fiziksel host üzerinde çalışacağını kullanıcının seçebilmesini sağlar.

Bu ayar çoğu kurumda kapalı tutulur. Çünkü fiziksel host seçimi genellikle son kullanıcının karar vermesi gereken bir konu değildir. Host seçimi kaynak doluluğu, CPU/RAM kullanımı, cluster dengesi, bakım durumu, lisanslama, affinity/anti-affinity kuralları ve performans gereksinimleri gibi birçok teknik faktöre bağlıdır.

Örneğin VMware ortamlarında DRS benzeri yük dengeleme mekanizmaları sanal makineleri uygun host üzerine otomatik yerleştirebilir. Bu kararın kullanıcıya bırakılması zamanla bazı host’ların gereğinden fazla dolmasına, bazı host’ların ise boş kalmasına neden olabilir.

Bu ayarın açık olması yalnızca özel durumlarda anlamlıdır. Örneğin belirli lisanslara sahip bir uygulamanın sadece belirli host üzerinde çalışması gerekiyorsa özel donanım bağımlılığı varsa veya test amaçlı belirli bir host hedefleniyorsa kullanılabilir.

Genel kural olarak Allow Host Selection kapalı tutulmalı ve yerleşim kararını platform veya sanallaştırma altyapısı vermelidir.

3) Require Environment Selection

Require Environment Selection kullanıcıların provizyon sırasında bir ortam seçmesini zorunlu hale getirir.

Bu ortamlar genellikle şu şekilde kullanılır:

• Dev
• Test
• Pre-Production
• Production
• Disaster Recovery
• Sandbox

Bu ayar açık olduğunda kullanıcı ortam seçmeden provizyon sürecine devam edemez. İlk bakışta küçük bir zorunluluk gibi görünse de aslında kurumsal yapılarda oldukça önemlidir.

Çünkü bir kaynağın hangi ortama ait olduğu güvenlik politikalarını, yedekleme kurallarını, maliyetlendirme modelini, erişim yetkilerini, izleme seviyesini ve yaşam döngüsü yönetimini doğrudan etkileyebilir.

Örneğin Production ortamındaki bir sunucunun günlük yedeklenmesi, daha sık izlenmesi ve daha katı erişim kurallarına sahip olması beklenirken; Dev ortamındaki bir sunucu daha esnek politikalarla yönetilebilir.

Bu nedenle ortam seçiminin zorunlu hale getirilmesi, kaynakların baştan doğru şekilde sınıflandırılmasını sağlar. Raporlama, chargeback, showback, güvenlik denetimi ve otomasyon süreçlerinde büyük kolaylık sağlar.

Ortam disiplinine önem veren kurumlarda bu ayarın açık olması önerilir.

4) Show Pricing

Show Pricing provizyon ekranında kullanıcıya tahmini maliyet veya fiyat bilgisinin gösterilip gösterilmeyeceğini belirler.

Bu ayar özellikle maliyet farkındalığı oluşturmak isteyen kurumlar için değerlidir. Kullanıcı bir sunucu oluştururken seçtiği CPU, RAM, disk ve ek servislerin yaklaşık maliyetini görebilir. Böylece gereğinden fazla kaynak talep etmeden önce kararını tekrar değerlendirebilir.

Örneğin kullanıcı test amaçlı bir sunucu oluştururken 16 vCPU ve 128 GB RAM seçtiğinde bunun yüksek maliyetli bir kaynak olduğunu ekranda görebilirse daha makul bir seçim yapabilir.

Bu özellik özellikle iki senaryoda önemlidir;

• Chargeback: Kullanılan kaynakların maliyeti ilgili departmana veya müşteriye yansıtılır.
• Showback: Maliyet kullanıcıya veya departmana gösterilir ancak doğrudan fatura edilmez.

Maliyetlerin merkezi olarak yönetildiği ve kullanıcıya gösterilmesinin istenmediği ortamlarda bu ayar kapalı bırakılabilir. Ancak self-servis kullanımın yaygın olduğu yapılarda maliyet bilgisinin gösterilmesi kaynak tüketiminde daha bilinçli davranılmasını sağlar.

5) Hide Datastore Stats On Selection

Hide Datastore Stats On Selection datastore seçim ekranında kapasite ve kullanım istatistiklerinin kullanıcıdan gizlenmesini sağlar.

Bu ayar kapalı olduğunda kullanıcı datastore seçerken ilgili datastore’un toplam kapasitesini, kullanılan alanını ve boş alanını görebilir. Teknik kullanıcılar için bu bilgi faydalı olabilir. Örneğin büyük diskli bir sanal makine oluşturacaksa, yeterli boş alanı olan datastore’u seçebilir.

Ancak bazı yapılarda altyapı kapasite bilgilerinin son kullanıcılara gösterilmesi istenmez. Özellikle çok tenant’lı yapılarda, bir tenant kullanıcısının genel datastore doluluk oranlarını görmesi güvenlik veya operasyon politikaları açısından uygun olmayabilir.

Bu ayarın aktif edilmesi kullanıcı arayüzünü sadeleştirir ve altyapı detaylarını gizler. Self-servis deneyimi daha kontrollü hale gelir.

Kurum içi teknik ekiplerin kullandığı yapılarda kapalı bırakılabilir. Müşteri veya tenant bazlı yapılarda ise aktif edilmesi değerlendirilebilir.

6) Cross-Tenant Naming Policies

Cross-Tenant Naming Policies adlandırma politikalarının tenant’lar arasında ortak çalışmasını sağlar.

Morpheus üzerinde kaynaklar için otomatik isimlendirme kuralları tanımlanabilir. Örneğin:

srv-prod-001
srv-prod-002
web-test-001
db-prd-001

Bu ayar kapalı olduğunda her tenant kendi isimlendirme sırasını bağımsız şekilde kullanabilir. Bu durumda farklı tenant’larda aynı isimli kaynakların oluşması mümkündür.

Örneğin Tenant A içinde srv-001, Tenant B içinde de srv-001 isimli bir sanal makine oluşabilir. Morpheus içinde tenant ayrımı olduğu için bu teknik olarak sorun yaratmayabilir. Ancak DNS, monitoring, backup, CMDB veya log yönetimi gibi merkezi sistemlerde isim çakışması ciddi karışıklığa neden olabilir.

Bu ayar açık olduğunda isimlendirme politikası tenant’lar arasında ortak çalışır. Böylece aynı isim veya sıra numarası farklı tenant’larda tekrar kullanılmaz.

Çok tenant’lı yapılarda merkezi isimlendirme standardı isteniyorsa bu ayarın açılması faydalı olabilir. Ancak her tenant’ın tamamen bağımsız isim alanına sahip olduğu yapılarda kapalı tutulabilir.

7) Reuse Naming Sequence Numbers

Reuse Naming Sequence Numbers otomatik isimlendirme sırasında kullanılan sıra numaralarının tekrar kullanılıp kullanılmayacağını belirler.

Örneğin srv-001 isimli bir sanal makine silindiğinde bu ayar açık ise sistem daha sonra oluşturulan yeni bir sanal makineye tekrar srv-001 adını verebilir. Ayar kapalı olduğunda ise sıra numarası ilerlemeye devam eder ve eski numara yeniden kullanılmaz.

Bu ayar teoride numara boşluklarını kapatmak için kullanışlı görünebilir. Ancak pratikte çoğu kurum için kapalı tutulması daha sağlıklıdır. Çünkü silinen bir sunucunun adı; log kayıtlarında, yedekleme raporlarında, monitoring sistemlerinde, DNS geçmişinde veya CMDB kayıtlarında hâlâ bulunabilir. Aynı ismin yeni bir sunucuya verilmesi, geçmiş kayıtların yorumlanmasını zorlaştırır.

Özellikle güvenlik olay incelemelerinde veya geçmişe dönük raporlamalarda “eski srv-001 mi, yeni srv-001 mi?” sorusu ciddi karışıklık yaratabilir.

Bu nedenle operasyonel izlenebilirlik açısından bu ayarın kapalı bırakılması önerilir.

8) Show Console Keyboard Layout Settings

Show Console Keyboard Layout Settings sanal makine konsoluna bağlanırken klavye düzeni seçeneklerinin gösterilmesini sağlar.

Bu ayar özellikle farklı klavye düzenlerinin kullanıldığı ülkelerde veya ekiplerde faydalıdır. Türkiye’de TR-Q klavye kullanılırken birçok sistem varsayılan olarak EN-US düzeniyle açılabilir. Bu durumda özellikle özel karakter içeren parolalarda kullanıcılar sorun yaşayabilir. Örneğin @, >, <, \, | gibi karakterler farklı klavye düzenlerinde farklı tuş kombinasyonlarıyla yazılır. Konsol üzerinden parola girerken bu durum ciddi zaman kaybına neden olabilir.

Bu ayar açık olduğunda kullanıcı konsola bağlanırken uygun klavye düzenini seçebilir. Özellikle Türkçe klavye kullanan ekiplerde aktif edilmesi kullanıcı deneyimini iyileştirir.

9) Deployment Archive Store

Deployment Archive Store deployment arşivlerinin saklanacağı depolama alanını belirler.

Morpheus üzerinde bazı dağıtım süreçlerinde script dosyaları, uygulama paketleri, blueprint bileşenleri veya otomasyon arşivleri kullanılabilir. Bu dosyaların saklanacağı storage bucket bu alanda seçilir.

Bu listede herhangi bir seçenek görünmüyorsa bu genellikle bir hata değildir. Büyük ihtimalle henüz Infrastructure → Storage bölümünde uygun bir depolama hedefi tanımlanmamıştır.

Bu durumda önce Infrastructure → Storage bölümüne giderek bir storage hedefi oluşturulmalı, ardından Provisioning ayarlarına dönülerek ilgili bucket seçilmelidir.

Bu ayar özellikle uygulama dağıtımlarının tekrar edilebilir, düzenli ve merkezi şekilde yönetilmesi açısından önemlidir.

b) Cloud-Init Settings: Linux Sunucular İçin Varsayılan Kimlik ve Erişim Ayarları

Cloud-init, Linux tabanlı sistemlerin ilk açılış sırasında otomatik olarak yapılandırılmasını sağlayan yaygın bir mekanizmadır.

HPE Morpheus Enterprise Linux sanal makineleri oluştururken cloud-init üzerinden kullanıcı adı, parola, SSH anahtarı, hostname ve başlangıç komutları gibi birçok ayarı uygulayabilir.

Cloud-Init Settings bölümü yeni oluşturulacak Linux sunucular için varsayılan kimlik bilgilerini belirler.

Bu bölümün amacı her yeni Linux sunucusu için aynı bilgileri tekrar tekrar girmek zorunda kalmadan standart bir başlangıç yapılandırması sağlamaktır.

1) Username ve Password

Username ve Password alanları yeni Linux sunucularında otomatik oluşturulacak varsayılan kullanıcı adı ve parolayı belirler.

Kullanıcı provizyon sırasında özel bir kullanıcı bilgisi girmezse bu değerler uygulanır. Bu sayede Linux sunucular standart bir kullanıcı hesabıyla hazır hale gelir.

Bu özellik operasyonel olarak kolaylık sağlar. Ancak güvenlik açısından dikkatli kullanılmalıdır. Tüm Linux sunucularda aynı kullanıcı adı ve parolanın kullanılması risk oluşturabilir. Bu nedenle production ortamlarında varsayılan parola kullanımından mümkün olduğunca kaçınılmalı, bunun yerine SSH key tabanlı erişim veya parola kasası entegrasyonu tercih edilmelidir.

2) Key Pair

Key Pair Linux sunuculara otomatik olarak enjekte edilecek SSH anahtar çiftini belirler.

SSH key kullanımı parola tabanlı erişime göre daha güvenli ve yönetilebilir bir yöntemdir. Özellikle otomasyon araçları, sistem yöneticileri ve DevOps ekipleri için anahtar tabanlı erişim büyük kolaylık sağlar. Bir SSH key pair tanımlandığında yeni oluşturulan Linux sunuculara bu anahtar otomatik eklenebilir. Böylece kullanıcılar veya otomasyon sistemleri sunucuya güvenli şekilde bağlanabilir. Güvenlik açısından bakıldığında, cloud-init tarafında mümkünse parola yerine key pair kullanımına ağırlık verilmelidir.

c) Windows Settings

Windows Settings bölümü Windows tabanlı sanal makinelerde kullanılacak varsayılan yönetici bilgisini belirler. Bu bölüm Linux tarafına göre daha sade görünür ancak güvenlik açısından oldukça kritik bir ayar içerir.

1) Administrator Password

Administrator Password yeni Windows sunucularında yerel Administrator hesabına atanacak varsayılan parolayı belirler.

Kullanıcı provizyon sırasında özel bir parola girmezse burada tanımlanan değer kullanılır. Bu durum hızlı kurulumlarda kolaylık sağlar. Ancak aynı Administrator parolasının çok sayıda sunucuda kullanılması güvenlik açısından risklidir.

Özellikle production ortamlarında varsayılan Administrator parolasının güçlü olması, düzenli olarak değiştirilmesi ve mümkünse merkezi parola yönetimiyle kontrol edilmesi gerekir.

Daha gelişmiş yapılarda her sunucu için dinamik parola üretilmesi, parolanın parola kasasına yazılması veya kurulum sonrası otomasyon ile değiştirilmesi daha güvenli bir yaklaşımdır.

d) Library Settings: Self-Servis Katalog Deneyimini Yönetmek

Library Settings bölümü kullanıcıların self-servis katalog ekranında hangi provizyon türlerini görebileceğini ve bu seçeneklerin hangi sırayla listeleneceğini belirler.

Bu bölüm kullanıcı deneyimini doğrudan etkiler. Çünkü kullanıcı Morpheus üzerinde kaynak oluşturmak istediğinde karşısına çıkan ilk seçenekler burada belirlenir.

Doğru yapılandırılmış bir Library Settings ekran kullanıcıların ihtiyaç duydukları hizmete daha hızlı ulaşmasını sağlar. Gereksiz seçenekleri azaltır, standartlaştırılmış servislerin kullanımını teşvik eder ve teknik karmaşıklığı kullanıcıdan uzaklaştırır.

1) Enable Catalog

Enable Catalog self-servis katalog öğelerinin kullanıcılara sunulmasını sağlar.

Katalog öğeleri önceden hazırlanmış ve belirli standartlara göre oluşturulmuş servislerdir. Örneğin:

• Ubuntu Web Server
• Windows Server
• SQL Server
• WordPress Uygulaması
• Test Ortamı
• Backup Enabled VM
• Production Linux Template

Katalog kullanımı self-servis yapının en önemli parçalarından biridir. Çünkü kullanıcı teknik detaylarla uğraşmadan, IT ekibi tarafından hazırlanmış ve onaylanmış servisleri seçebilir.

Bu yaklaşım hem kullanıcı deneyimini kolaylaştırır hem de IT tarafında standartlaşmayı sağlar. Kullanıcıya sınırsız seçenek vermek yerine doğru hazırlanmış katalog öğeleri sunmak daha güvenli ve yönetilebilir bir modeldir.

2) Enable Apps

Enable Apps çok katmanlı uygulama provizyonunu etkinleştirir.

Modern uygulamalar çoğu zaman tek bir sunucudan oluşmaz. Bir uygulama mimarisinde web sunucusu, uygulama sunucusu, veritabanı, load balancer, cache servisi ve güvenlik bileşenleri bulunabilir.

Morpheus Apps yapısı sayesinde bu bileşenler tek bir uygulama çatısı altında birlikte dağıtılabilir. Böylece kullanıcı her bileşeni ayrı ayrı kurmak yerine, tüm uygulama mimarisini tek işlemle ayağa kaldırabilir.

Örneğin üç katmanlı bir web uygulaması için:

• Web katmanı
• Application katmanı
• Database katmanı tek bir App blueprint içinde tanımlanabilir ve birlikte dağıtılabilir.

Bu özellik özellikle DevOps, uygulama ekipleri ve standart uygulama dağıtımı yapan kurumlar için oldukça değerlidir.

3) Enable Instances

Enable Instances tekil sanal makine veya instance oluşturma seçeneğini aktif hale getirir.

Bu HPE Morpheus’un en temel provizyon türüdür. Kullanıcı tek bir sanal makin oluşturur, işletim sistemi seçer, CPU/RAM/disk gibi kaynakları belirler ve ilgili cloud ortamına dağıtım yapar.

Teknik kullanıcılar, sistem yöneticileri, test ekipleri ve altyapı ekipleri tarafından sık kullanılır.

Çoğu ortamda bu seçeneğin açık kalması beklenir. Ancak yalnızca katalog tabanlı self-servis sunmak isteyen yapılarda kullanıcıların doğrudan instance oluşturması sınırlandırılabilir.

4) Provisioning Order

Provisioning Order Catalog, Apps ve Instances seçeneklerinin kullanıcı arayüzünde hangi sırayla gösterileceğini belirler.

Bu ayar küçük bir detay gibi görünebilir, ancak kullanıcı deneyiminde önemli etkisi vardır.

Örneğin kurumunuzda kullanıcıların öncelikle katalog üzerinden hizmet talep etmesini istiyorsanız Catalog seçeneğini ilk sıraya almak mantıklıdır. Teknik ekiplerin daha çok tekil VM oluşturduğu yapılarda Instances ilk sırada olabilir. Uygulama ekipleri için Apps seçeneği öne alınabilir.

Doğru sıralama kullanıcının aradığı seçeneğe daha hızlı ulaşmasını sağlar ve self-servis deneyimini daha akıcı hale getirir.

e) PXE Boot Settings

PXE Boot fiziksel makinelerin ağ üzerinden başlatılarak işletim sistemi kurulmasını sağlayan bir yöntemdir. Özellikle bare-metal sunucu kurulumlarında kullanılır.

Morpheus üzerinde PXE boot yapılandırması kullanıldığında fiziksel sistemlerin otomatik olarak işletim sistemiyle hazırlanması mümkün hale gelir.

1) Default Root Password

Default Root Password PXE boot ile hazırlanan sistemlerde root hesabına atanacak varsayılan parolayı belirler.

Bu ayar özellikle Linux tabanlı bare-metal kurulumlarda önemlidir. Çok sayıda fiziksel sunucu kurulacaksa her kurulumda manuel parola belirlemek yerine standart bir varsayılan parola kullanılabilir.

Ancak root hesabı sistem üzerindeki en yetkili hesaptır. Bu nedenle burada tanımlanan parolanın güçlü olması, yalnızca yetkili kişiler tarafından bilinmesi ve kurulum sonrasında değiştirilmesi gerekir.

Production sistemlerde root ile doğrudan erişim sınırlandırılmalı, mümkünse yetkili kullanıcılar ve merkezi erişim politikaları üzerinden yönetim yapılmalıdır.

f) App Blueprint Settings

Blueprint, HPE Morpheus üzerinde uygulama veya altyapı dağıtımlarını şablon haline getirmek için kullanılan yapılardır.

Bir blueprint içerisinde sanal makineler, network ayarları, değişkenler, scriptler, servis bağımlılıkları, otomasyon adımları ve uygulama bileşenleri tanımlanabilir.

Bu sayede aynı uygulama veya altyapı yapısı tekrar tekrar standart şekilde kurulabilir.

1) Default Blueprint Type

Default Blueprint Type yeni bir uygulama blueprint’i oluşturulurken varsayılan olarak hangi blueprint türünün seçileceğini belirler.

Morpheus kendi blueprint formatını desteklediği gibi farklı altyapı otomasyon araçlarıyla da çalışabilir. Bunlar arasında Terraform, Helm, ARM ve CloudFormation gibi seçenekler bulunabilir.

Burada doğru seçim, kurumun kullandığı teknolojiye bağlıdır.

Eğer ekipler Morpheus’un kendi uygulama şablonlarını kullanıyorsa varsayılan değer Morpheus olarak kalabilir. Kubernetes ağırlıklı yapılarda Helm tercih edilebilir. Infrastructure as Code yaklaşımını benimseyen ekiplerde Terraform varsayılan hale getirilebilir. Azure odaklı yapılarda ARM, AWS odaklı yapılarda ise CloudFormation tercih edilebilir.

Bu ayar, her yeni blueprint oluşturulduğunda tekrar seçim yapma ihtiyacını ortadan kaldırır ve iş akışını hızlandırır.

g) Terraform Settings

Terraform altyapının kod olarak yönetilmesini sağlayan en yaygın araçlardan biridir. HPE Morpheus’un Terraform entegrasyonu sayesinde altyapı kaynakları kod tabanlı olarak oluşturulabilir, yönetilebilir ve standart hale getirilebilir.

Terraform Settings bölümü Morpheus içinde Terraform’un nasıl çalışacağını ve hangi sürümün kullanılacağını belirler. Bu bölüm özellikle Terraform kullanan ekipler için kritik öneme sahiptir. Çünkü Terraform sürümleri arasında davranış farklılıkları olabilir. Bir sürümde çalışan modül, başka bir sürümde hata verebilir veya farklı sonuç üretebilir.

1) Terraform Runtime

Terraform Runtime Terraform çalışma zamanının (runtime) nasıl yönetileceğini belirler.

Manual seçeneği kullanıldığında Terraform sürümü manuel olarak belirlenir. Yani hangi Terraform sürümünün kullanılacağına platform yöneticisi karar verir. Bu yaklaşım sürüm kontrolünün önemli olduğu kurumsal ortamlarda daha güvenlidir. Çünkü beklenmeyen sürüm değişikliklerinin önüne geçilir.

Alternatif olarak platformun Terraform sürümünü otomatik yönetmesi de tercih edilebilir. Ancak production ortamlarında genellikle sürümün kontrollü şekilde belirlenmesi daha doğru olur.

2) Default Terraform Version

Default Terraform Version manual modda kullanılacak varsayılan Terraform sürümünü belirtir.

Örneğin kurumda tüm Terraform blueprint’leri 1.5.7 sürümüyle test edildiyse bu sürüm burada sabitlenebilir. Böylece tüm kullanıcılar ve blueprint’ler aynı Terraform sürümüyle çalışır. Bu alan boş bırakılırsa platformun varsayılan Terraform davranışı geçerli olur. Ancak sürüm uyumluluğunun kritik olduğu projelerde bu alanın bilinçli şekilde doldurulması önerilir. Terraform tarafında sürüm standardizasyonu ileride yaşanabilecek uyumluluk sorunlarını azaltır ve IaC süreçlerini daha öngörülebilir hale getirir.

Provisioning sekmesindeki ayarların tamamına bakıldığında aslında tek bir ana fikir öne çıkar:

Kullanıcıya ne kadar seçim hakkı vereceğiz, ne kadarını platform otomatik yönetecek?

Bu denge her kurumda farklıdır. Küçük ve teknik ekiplerden oluşan yapılarda kullanıcıların cloud, kaynak tipi, network veya datastore seçmesine izin verilebilir. Çünkü kullanıcılar altyapıyı tanır ve seçimlerinin sonucunu bilir. Ancak çok tenant’lı self-servis veya müşteri odaklı yapılarda kullanıcıya çok fazla teknik seçenek sunmak hataya neden olabilir. Bu durumda katalog, blueprint, policy ve otomasyon temelli bir model daha sağlıklıdır. Kullanıcıya sunulan seçenekler sadeleştirildikçe hata riski azalır. Platformun karar verdiği alanlar arttıkça standartlaşma güçlenir. Ancak fazla kısıtlama da kullanıcı deneyimini zorlaştırabilir. Bu nedenle ideal yapı kullanıcıya yalnızca gerçekten karar vermesi gereken seçenekleri sunmak geri kalan teknik ayrıntıları platform politikalarıyla yönetmektir.

Güvenlik Açısından Dikkat Edilmesi Gerekenler

Provisioning ayarlarında güvenlik konusu özellikle varsayılan kullanıcı bilgileri ve erişim yöntemleri tarafında önem kazanır.

Linux sunucular için varsayılan parola tanımlanıyorsa bu parolanın güçlü olması ve mümkünse production ortamlarında kullanılmaması gerekir. Parola yerine SSH key tabanlı erişim tercih edilmelidir.

Windows sunucularda Administrator parolasının tüm makinelerde aynı olması ciddi güvenlik riski doğurabilir. Bu parola düzenli olarak değiştirilmeli, mümkünse merkezi parola kasası veya otomasyon sistemiyle yönetilmelidir.

PXE boot ile kurulan sistemlerde root parolası dikkatle korunmalıdır. Kurulum sonrasında root erişimi sınırlandırılmalı ve erişim kayıt altına alınmalıdır.

Ayrıca kullanıcıların cloud, host veya datastore gibi kritik altyapı bileşenlerini seçebilmesi de güvenlik ve operasyon riski doğurabilir. Bu nedenle yetkilendirme rol bazlı erişim ve tenant sınırları dikkatli yapılandırılmalıdır.

Operasyonel Verimlilik Açısından Öneriler

Provisioning ayarları yalnızca güvenlik için değil operasyonel verimlilik için de önemlidir.

Öncelikle isimlendirme politikaları dikkatli planlanmalıdır. Sanal makinelerin, uygulamaların ve servislerin tutarlı isimlendirilmesi; DNS, monitoring, yedekleme, log yönetimi ve CMDB süreçlerini kolaylaştırır.

İkinci olarak ortam seçimi mümkünse zorunlu hale getirilmelidir. Dev, Test ve Production ayrımının net yapılması, ileride raporlama ve politika yönetiminde büyük kolaylık sağlar.

Üçüncü olarak katalog kullanımı teşvik edilmelidir. Kullanıcıların her seferinde manuel VM oluşturması yerine, önceden hazırlanmış ve test edilmiş katalog öğelerini kullanması daha güvenli ve standart bir yöntemdir.

Dördüncü olarak Terraform gibi IaC araçlarında sürüm standardizasyonu sağlanmalıdır. Farklı sürümlerle çalışan blueprint’ler zamanla yönetilmesi zor sorunlara neden olabilir.

Son olarak kullanıcı arayüzünde gereksiz seçenekler azaltılmalıdır. Kullanıcı ne kadar az ama doğru seçenek görürse, self-servis deneyimi o kadar başarılı olur.

Örnek Yaklaşım: Kurumsal Bir Ortamda Nasıl Yapılandırılabilir?

Kurumsal ve çok tenant’lı bir Morpheus ortamında aşağıdaki yaklaşım tercih edilebilir:

1. Allow Cloud Selection yalnızca teknik ekipler için açık bırakılabilir. Son kullanıcılar için cloud seçimi otomatik yapılabilir.
2. Allow Host Selection genel olarak kapalı tutulmalıdır. Host yerleşimini sanallaştırma platformu veya Morpheus politikaları yönetmelidir.
3. Require Environment Selection açık olmalıdır. Böylece her kaynak Dev, Test veya Production gibi bir ortamla ilişkilendirilir.
4. Show Pricing chargeback veya showback modeli varsa açık kullanılmalıdır.
5. Hide Datastore Stats On Selection müşteri veya tenant kullanıcıları için aktif değerlendirilebilir.
6. Cross-Tenant Naming Policies merkezi isimlendirme isteniyorsa açık kullanılabilir.
7. Reuse Naming Sequence Numbers genellikle kapalı kalmalıdır. Böylece eski kaynak adları yeniden kullanılmaz.
8. Cloud-init tarafında parola yerine SSH key kullanımına öncelik verilmelidir.
9. Windows Administrator parolası güçlü olmalı ve mümkünse dinamik yönetilmelidir.
10. Catalog ve Apps aktif kullanılmalı, kullanıcılar mümkün olduğunca standart katalog öğelerine yönlendirilmelidir.
11. Terraform sürümü manual olarak sabitlenmeli ve test edilmiş bir versiyon kullanılmalıdır.

Bu yaklaşımlar hem kullanıcı deneyimini sadeleştirir hem de altyapı yönetimini daha kontrollü hale getirir.