Etzel Art of Digital Manufacturing
Bize ulaşın
Lunex 1.6.0 kullanım kılavuzu

Kurulum yönetimi, roller ve ortak kaynaklar

Settings ve System ile ortak şablon, kaynak ve yapılandırmaları yönetin.

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örevAtanacak rollerBaşlıca işlevler
İzleyiciplatform-userProje/dosya okuma, çalışma durumlarını ve izin verilen izleme verilerini inceleme.
Geliştiriciplatform-user, platform-developerProje/dosya oluşturma ve değiştirme, Git, Run/Reload, Build ve dağıtım, API geliştirme/yayımlama.
Kurulum yöneticisiplatform-admin; geliştirme yapacaksa ayrıca diğer iki rolSystem 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:

SekmeKullanımı
ContainersPlatform ve proje konteynerlerinin durumunu inceleme; uygun satırdan log açma.
DeploymentsDeployment, imaj ve hazır replica durumlarını inceleme.
SecretsKubernetes Secret’ları ve anahtarlarını yönetme. Liste değerleri gizler; gerektiğinde ilgili değeri açarsınız.
ConfigMapsGizli olmayan çalışma ayarlarını anahtar/değer olarak yönetme.
Environment variablesLunex uygulama sürecinin ortam değişkenlerini inceleme.
Application propertiesUygulamanın etkin yapılandırmasını inceleme.
LogSeç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.

  1. System → Secrets açın ve yeni Secret oluşturma işlemini seçin.
  2. Name alanına orders-connection gibi küçük harf, rakam ve tirelerden oluşan bir ad yazın; Create seçin.
  3. Secret satırında Add key seçin.
  4. Key alanına password, Value alanına bağlantı parolasını girip Add key seçin.
  5. Projenin deployment.jkube.yaml dosyasında mevcut entegrasyon konteynerinin env alanına referans ekleyin:
spec:
  template:
    spec:
      containers:
        - name: integration
          env:
            - name: ORDER_SYSTEM_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: orders-connection
                  key: password
  1. application.properties içinde uygulama özelliğini bu environment variable’a bağlayın:
order.system.password={{env:ORDER_SYSTEM_PASSWORD}}
  1. 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ı?

BelirtiSorumluluk ve ilk kanıt
Giriş yapılamıyorKimlik yöneticisi; public URL, redirect, issuer, kullanıcı ve roller.
Git veya registry erişimi reddediliyorKurulum/Git/registry yöneticisi; erişim hesabı, DNS/TLS, uygulama ve builder ayarları.
Pod başlayamıyorKubernetes yöneticisi; pod olayları, Secret referansları, imaj erişimi, request/limit ve kota.
Akış hata veriyorEntegrasyon geliştiricisi; Message Monitor çalışması, route/adım ve dış servis yanıtı.
Kuyruk büyüyorEntegrasyon ve mesajlaşma sorumluları; tüketiciler, bekleyen mesajlar ve hata/yeniden deneme davranışı.
API erişilemiyorAPI 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.

Lunex’i kendi entegrasyonunuzla görün

Kılavuzda okuduklarınızı kendi sistemlerinizle deneyelim. Demo için bize yazın.