Lunex yöneticisi kullanıcıların girişini, ortak çalışma ayarlarını, platform servislerini ve kurulumun kapasitesini yönetir. Entegrasyon geliştiricisi ise projelerin kaynaklarını, bağlantılarını ve çalışma sürümlerini hazırlar. Aynı kişi iki görevi üstlenebilir; roller ayrı ayrı atanır.
Başlangıç için kurulum ve dış servisler, Keycloak ve kurumsal OIDC, kendi Git deponuz ve CPU/RAM bütçesi rehberlerini kullanın.
Kullanıcı rollerini belirleme
| Görev | Atanacak roller | Başlıca işlevler |
|---|---|---|
| İzleyici | platform-user | Proje/dosya okuma, çalışma durumlarını ve izin verilen izleme verilerini inceleme. |
| Geliştirici | platform-user, platform-developer | Proje/dosya oluşturma ve değiştirme, Git, Run/Reload, Build ve dağıtım, API geliştirme/yayımlama. |
| Kurulum yöneticisi | platform-admin; geliştirme yapacaksa ayrıca diğer iki rol | System menüsü, yönetici tanılamaları, ortak yapılandırmanın paylaşılması ve yönetim görevleri. |
platform-admin tek başına geliştirici yetkisi vermez. Roller birikimlidir; yalnızca yönetici rolü olan hesabın bir build isteğinde 403 alması beklenebilir. Kullanıcı ve rol yönetimi Lunex içinde değil, kimlik yönetiminde yapılır. İzleme verisine erişim ayrıca kayıt ve erişim politikasına bağlıdır.
Roller kurulum geneline uygulanır. Proje sahipliği, projeye özel kullanıcı grubu veya kiracı yetkisi oluşturmaz. Ayrı kuruluşların kaynaklarını, Secret’larını ve verisini ayırmanız gerekiyorsa mimari sınırları kurulum seviyesinde planlayın.
Settings ile ortak dosyaları yönetme
Settings → Templates, Kamelets ve Configuration bütün projelerin yararlandığı ortak kaynakları içerir. Dosyalar, proje kaynaklarındaki gibi oluşturulur, düzenlenir, karşılaştırılır ve Git’e gönderilir.
Templates, yeni dosyalara başlangıç verir. Mevcut proje dosyalarının otomatik güncellenmesini beklemeyin. Kamelets, tekrar kullanılabilir entegrasyon parçalarıdır. Configuration, build betiği gibi birden fazla projeyi etkileyen dosyaları içerir.
Kubernetes’te bir Configuration dosyasını çalışma altyapısına aktarmak için dosyayı açıp Share kullanın. Bu yönetici işlemi dosyayı ConfigMap olarak paylaşır. Git commit’i ile çalışma altyapısına paylaşma farklı işlemlerdir: sürüm geçmişi için dosyayı Git’e de gönderin. Özellikle build betiğini değiştirdikten sonra yeni bir deneme build’iyle beklenen davranışı doğrulayın.
System ekranını kullanma
System menüsü platform-admin rolü olan hesaplarda gösterilir. Sekmelerin kapsamı şöyledir:
| Sekme | Kullanımı |
|---|---|
| Containers | Platform ve proje konteynerlerinin durumunu inceleme; uygun satırdan log açma. |
| Deployments | Deployment, imaj ve hazır replica durumlarını inceleme. |
| Secrets | Kubernetes Secret’ları ve anahtarlarını yönetme. Liste değerleri gizler; gerektiğinde ilgili değeri açarsınız. |
| ConfigMaps | Gizli olmayan çalışma ayarlarını anahtar/değer olarak yönetme. |
| Environment variables | Lunex uygulama sürecinin ortam değişkenlerini inceleme. |
| Application properties | Uygulamanın etkin yapılandırmasını inceleme. |
| Log | Seçilen konteynerin logunu okuma. |
Environment variables ve Application properties tanılama tablolarıdır. Bir entegrasyonun environment variable’ını ya da gateway politikasını buradan düzenlemezsiniz. Kalıcı değişikliği ilgili Helm ayarı, Secret, ConfigMap veya proje dağıtım dosyasında yapın.
Secret oluşturma ve projeye bağlama
Secret, parola veya erişim belirteci gibi bir değeri proje kaynak dosyasına yazmadan runtime’a vermenizi sağlar. Secret’ı oluşturmak tek başına bir bağlantı açmaz; projedeki runtime tanımı ilgili değeri referans etmelidir.
- System → Secrets açın ve yeni Secret oluşturma işlemini seçin.
- Name alanına
orders-connectiongibi küçük harf, rakam ve tirelerden oluşan bir ad yazın; Create seçin. - Secret satırında Add key seçin.
- Key alanına
password, Value alanına bağlantı parolasını girip Add key seçin. - Projenin
deployment.jkube.yamldosyasında mevcut entegrasyon konteynerininenvalanına referans ekleyin:
spec:
template:
spec:
containers:
- name: integration
env:
- name: ORDER_SYSTEM_PASSWORD
valueFrom:
secretKeyRef:
name: orders-connection
key: password
application.propertiesiçinde uygulama özelliğini bu environment variable’a bağlayın:
order.system.password={{env:ORDER_SYSTEM_PASSWORD}}
- Bileşenin ilgili parola alanında
{{order.system.password}}yer tutucusunu kullanın. Kaydedin; geliştirme podunu yeniden oluşturun veya paketlenmiş sürümü commit/build ile dağıtın.
Örnek YAML mevcut dosyaya birleştirilecek parçadır; integration yerine mevcut entegrasyon konteynerinizin adını kullanın, proje metadata ve diğer container ayarlarını koruyun. Secret aynı namespace’te bulunmalıdır. Eksik Secret veya yanlış anahtar adı podun başlamasını engelleyebilir. Bağlantının gerçek servisle çalıştığını küçük bir denemeyle doğrulayın.
Secret değerleri Git’e commit edilmez; dağıtım dosyasında yalnızca Secret adı ve anahtarı bulunur. Bir Secret’ı birden fazla proje referans edebilir. Proje oluşturmak Secret’ın kullanımını yalnızca o projeyle sınırlandırmaz.
ConfigMap ile gizli olmayan ayarları paylaşma
System → ConfigMaps altında aynı oluşturma ve Add key akışını kullanın. Örneğin orders-settings içinde base-url anahtarı oluşturabilirsiniz. Runtime’a bağlamak için environment variable’ın valueFrom alanında configMapKeyRef kullanın:
- name: ORDER_SYSTEM_URL
valueFrom:
configMapKeyRef:
name: orders-settings
key: base-url
Ardından application.properties içinde order.system.url={{env:ORDER_SYSTEM_URL}} tanımlayıp akışta {{order.system.url}} kullanın. Parola ve belirteçleri ConfigMap’e koymayın. Environment variable üzerinden alınan değerlerin değişmesi için podu yeniden oluşturun; yalnızca akış Reload işlemi yeterli değildir.
Chart’ın yönettiği kaynakları değiştirecekseniz asıl ayarı values/kurulum tanımında da güncelleyin. Aksi halde sonraki yükseltme elle yapılan değişikliği geri yazabilir. Platformun kullandığı korumalı Secret/ConfigMap’leri uygulama bağlantılarınız için genel depo gibi kullanmayın.
Bir arızayı hangi ekip araştırmalı?
| Belirti | Sorumluluk ve ilk kanıt |
|---|---|
| Giriş yapılamıyor | Kimlik yöneticisi; public URL, redirect, issuer, kullanıcı ve roller. |
| Git veya registry erişimi reddediliyor | Kurulum/Git/registry yöneticisi; erişim hesabı, DNS/TLS, uygulama ve builder ayarları. |
| Pod başlayamıyor | Kubernetes yöneticisi; pod olayları, Secret referansları, imaj erişimi, request/limit ve kota. |
| Akış hata veriyor | Entegrasyon geliştiricisi; Message Monitor çalışması, route/adım ve dış servis yanıtı. |
| Kuyruk büyüyor | Entegrasyon ve mesajlaşma sorumluları; tüketiciler, bekleyen mesajlar ve hata/yeniden deneme davranışı. |
| API erişilemiyor | API ve kurulum sorumluları; operasyon tanımı, runtime, yayın durumu ve istemci kimlik doğrulaması. |
Sorun raporuna ortamı, Project ID’yi, zaman aralığını, ilgili çalışma/istek kimliğini ve gizli verileri çıkarılmış hata mesajını ekleyin. Genel sorun giderme, izleme ve kuyruk yönetimi rehberleri kanıtları nasıl okuyacağınızı açıklar.