Kurulum, dış servisler ve işletim

Bu rehber Lunex kurulumundan sorumlu teknik ekip içindir. Çalışan bir kurulumu kullanmak için geliştiricilerin Helm veya Kubernetes erişimine ihtiyacı yoktur. Proje geliştirmeye Projects üzerinden başlayabilirler.

Lunex kurulum paketi uygulamayı, kimlik servisini, veri tabanını, mesaj aracısını, entegrasyon Git deposunu, imaj registry’sini ve API giriş katmanını birlikte kurabilir. Kendi yönettiğiniz servisleri kullanmak istediğinizde aşağıdaki bağlantı ve sahiplik sınırlarını belirleyin.

Kuruluma hazırlık

Sunucu kurulumu için Linux, en az 4 CPU, 8 GiB RAM ve 40 GiB boş disk planlayın. Bu başlangıç kapasitesi iş yükü kapasitesi garantisi değildir; eşzamanlı entegrasyonlar, build’ler, tutulan mesajlar ve izleme verileri ayrıca boyutlandırılır.

Kurulumun ihtiyaçları şunlardır:

• Root erişimli bir Linux sunucu veya erişilebilir Kubernetes cluster’ı ve uygun KUBECONFIG.
• Mevcut cluster’da kalıcı diskler için kullanılabilir bir StorageClass.
• kubectl, OpenSSL, gzip ve jq; çevrimiçi kurulum için curl ve Helm. Kurucu eksik Helm’i kurabilir.
• Teslim edilen Lunex sürümüne ait imajlara erişim veya aynı sürümün çevrimdışı imaj paketi.
• Lunex, Keycloak ve broker konsolu için tek HTTPS adresi; DNS, sertifika ve seçilen HTTP API portuna gerekli ağ erişimi.
• Git, registry ve dış sistemlere uygulama/build podlarından gerekli DNS ve ağ erişimi.

Sunucu kurucusu Kubernetes yoksa k3s kurabilir. Geliştirici bilgisayarında yerel ortam için aşağıdaki k3d akışını kullanın. Mevcut cluster’da Gateway API kaynakları ve ortak gateway controller’ının yönetimi cluster sahibiyle koordine edilmelidir; kurucu uyumsuz ortak şemaları zorla devralmaz.

İlk sunucu kurulumu

Teslim edilen paketin install.sh dosyasını içeren dizininde:

cp values.example.yaml values.yaml

values.yaml içinde sunucunun tarayıcıdan erişilen adresini belirleyin:

exposure:
  publicUrl: https://lunex.example.com
  apiHttp:
    enabled: true
    port: 30082  # Entegrasyonların çağırdığı HTTP portu; güncellemelerde değiştirmeyin.
  tls:
    secretName: lunex-company-tls
keycloak:
  adminAllowedCidrs: [192.0.2.0/24]  # Gerçek yönetici/VPN ağıyla değiştirin.

lunex-company-tls, kurulum namespace’inde önceden oluşturulmuş kubernetes.io/tls Secret’ıdır. Sertifika tarayıcıda kullanılan hostname’i kapsamalıdır. Kubernetes henüz yoksa ilk kurucu çağrısı K3s ve Gateway’i hazırlar, uygulamayı kurmadan sertifika kontrolünde durur; Secret’ı oluşturup aynı komutu tekrarlayın. Örneğin namespace lunex ise:

kubectl create namespace lunex --dry-run=client -o yaml | kubectl apply -f -
kubectl -n lunex create secret tls lunex-company-tls \
  --cert=fullchain.pem --key=privkey.pem

Chart, kurumunuzun güvendiği bir sertifika ister. Özel CA kullanılıyorsa ca.crt anahtarını içeren ayrı bir Secret oluşturup exposure.tls.caSecretName ile belirtin; istemci bilgisayarlarına CA güvenini kurumunuz dağıtır. Aynı CA altında sertifika yenilendiğinde Envoy yeni sertifikayı otomatik yükler. CA değişirse güven dağıtımından sonra kurucuyu tekrar çalıştırın; broker güven deposu da yenilenir.

Çevrimiçi kurulum:

sudo ./install.sh --values values.yaml \
  --ghcr-token-file /root/ghcr-token.txt

Belirteç dosyası teslim edilen imajları okuyabilen hesabın değerini içerir. Kurucu lunex namespace’ini ve servisleri hazırlar; ilk kurulumda URL’leri ve ilk admin parolasını gösterir. İlk girişte istenen parola değişikliğini tamamlayın.

Çevrimdışı imaj paketiyle kurulum:

sudo ./install.sh --values values.yaml --images /media/lunex-images

Çevrimdışı ortamda k3s ve Helm’i önceden sağlayın; paketin gerekli imaj ve gateway chart arşivlerinin tamamını taşıyın. Çevrimdışı imaj kurulumu, her projenin build bağımlılıklarının önceden indirildiği anlamına gelmez. Entegrasyonların kullanacağı bağımlılık depoları ve build erişimini ayrıca hazırlayın.

Tek HTTPS adresi ve HTTP API portu

Envoy Gateway 443 portunda HTTPS’i karşılar: Lunex /, Keycloak /auth, Artemis konsolu /console/ yolundadır. DNS kaydını bu Gateway girişine yönlendirin. Keycloak yönetim ekranı /auth/admin/, yalnızca keycloak.adminAllowedCidrs içinde belirtilen ağlardan erişilebilir. Boş liste dışarıdan yönetim erişimini kapatır; normal kullanıcı girişi ve hesap yönetimi kullanılabilir.

Yeni ve bağımsız k3s kurulumu Traefik’i kapalı kurar. Mevcut cluster’da 443 ve seçilen HTTP API portunun Envoy’a ayrılması gerekir; kurucu başka bir controller’ı kendiliğinden kaldırmaz. Kullanıcıların kullandığı ağdan gerekli portlara erişimi doğrulayın.

UI ve HTTPS proje API’leri aynı origin’i paylaşır: https://lunex.example.com/<projectId><server-base-path><operation-path>. HTTP seçilen API’ler exposure.apiHttp.port üzerinden çalışır; kurulum varsayılanı 30082’dir ve mevcut müşteri değeri yükseltmede korunmalıdır. HTTP isteği otomatik HTTPS’e çevrilmez. HTTP API gerekmiyorsa exposure.apiHttp.enabled: false ile kapatılabilir. API yayımlama erişim yollarını açıklar.

Harici servis kullanma

Git

git:
  enabled: false
  external:
    repository: https://git.example.com/integration-team/integrations.git
    username: lunex-automation
    password: "<git-access-token>"
    branch: main

Depo/dal, uygulama ve builder tarafından ortak kullanılır. Gerçek kimlik bilgilerini Git’e koymayın. HTTPS/SSH farkları, Secret aktarımı ve doğrulama adımları kendi Git deponuzu bağlama rehberindedir.

İmaj registry’si

registry:
  enabled: false
  group: integrations
  external:
    url: registry.example.com
    username: lunex-push
    password: "<registry-access-token>"
    pull:
      username: lunex-pull
      password: "<read-only-registry-token>"

Bu ayar paketlenmiş proje imajlarının yazılacağı ve çekileceği registry’yi belirler. Builder username/password hesabıyla imaj gönderir; bu bilgiyi yalnızca Lunex okur ve her build’e kendisi aktarır. Paketlenmiş proje Deployment’ları lunex-integration servis hesabına bağlanan çekme Secret’ı ile aynı registry’den çeker. Entegrasyonlar bu çekme Secret’ını okuyabildiği için pull altına salt okunur bir hesap verin; boş bırakılırsa gönderme hesabı kullanılır. Prod kurulumunda salt okunur bir hesap yeterlidir. Dev ve prod aynı registry’yi kullandığında dev’de bir kez üretilen imaj prod’da değiştirilmeden çalıştırılır.

Registry özel bir CA ile imzalanmış sertifika kullanıyorsa CA’yı ca.crt anahtarlı bir Secret olarak oluşturup trust.caSecretName ile belirtin. Aynı ayar harici Git için de geçerlidir; Lunex, builder ve k3s üzerinde kurucu node’un container runtime’ı bu CA’ya güvenir. TLS doğrulaması kapatılmaz.

global.imageRegistry ise Lunex ürün imajlarının konumudur; iki registry ayarı farklı amaçlara sahiptir. Özel ürün imajları için namespace’teki çekme Secret’larını global.imagePullSecrets ile belirtin.

Kurucu yalnızca k3s node’unu yapılandırır. Yönetilen/çok node’lu bir cluster’da node container runtime’larının registry güven ayarlarını cluster sahibi sağlamalıdır.

PostgreSQL

postgres:
  enabled: false
  external:
    host: postgres.internal.example.com
    port: 5432
    database: lunex
    username: lunex
  monitorRole:
    create: false
keycloak:
  database:
    name: keycloak
    create: false

Veri tabanı parolasını kurucunun yönettiği /etc/lunex/credentials.env içindeki LUNEX_DATABASE_PASSWORD değeriyle veya aşağıdaki mevcut Secret modeliyle sağlayın. Önceden kullanılan bir veri tabanını bağlarken credential değerini gerçek veri tabanı hesabıyla eşleştirin; yalnızca dosya değerini değiştirmek veri tabanındaki parolayı döndürmez.

Keycloak da paket içinde çalışıyorsa aynı PostgreSQL sunucusunda ayrı keycloak veri tabanı kullanır. Örnekte create: false olduğundan bu veri tabanını yönetici önceden oluşturmalıdır. Harici Keycloak kullanıyorsanız onun veri tabanı işletimi de kimlik ekibine aittir.

Message Monitor entegrasyon pod’larında uygulamanın veri tabanı hesabıyla değil, yalnızca izleme kayıtlarını yazabilen lunex_monitor rolüyle bağlanır. Lunex bu rolü her başlangıçta oluşturur ve parolasını LUNEX_MONITOR_DATABASE_PASSWORD (Secret anahtarı monitor-database-password) değerine eşitler; bunun için veri tabanı hesabının rol oluşturma (CREATEROLE) yetkisi gerekir. Örnekteki gibi monitorRole.create: false olduğunda rolü yönetici önceden oluşturur ve parolasını bu değerle aynı tutar: CREATE ROLE lunex_monitor LOGIN PASSWORD '<parola>';. Yetkileri Lunex’in şema geçişleri verir. Rol sunucu geneli bir hesaptır; aynı PostgreSQL sunucusunu paylaşan kurulumlarda aynı parolayı kullanın.

Kimlik servisi

keycloak:
  enabled: false
  realm: lunex
  frontendClientId: frontend
  backendClientId: backend
  external:
    url: https://login.example.com
    internalUrl: https://keycloak.internal.example.com

Realm rolleri, frontend/backend istemcileri, audience mapper’ı ve gerekiyorsa broker istemcisini kimlik rehberine göre hazırlayın. internalUrl farklı bir iç adres yoksa boş bırakılır. Harici servisin kullanıcıları, yedekleri ve yükseltmeleri o servisin yöneticisine aittir.

Kurulum Secret’ları ve parola sahipliği

Kurucu genel servis kimlik bilgilerini /etc/lunex/credentials.env dosyasında erişimi sınırlı olarak tutar ve Kubernetes’e aktarır. Aynı dosyayı sonraki yükseltmeler için koruyun. Dosya yoksa mevcut kuruluma rastgele yeni parolalar üretmeyin; mevcut yedeğinden geri getirin.

Kubernetes Secret’ını kurumunuz yönetecekse chart’a adını verin:

credentials:
  existingSecret: customer-lunex-credentials

Bu Secret aynı namespace’te gerekli anahtarları taşımalıdır:

existingSecret seçildiğinde chart genel credential Secret’ını ve artemis-credentials mesajlaşma Secret’ını üretmez. Projeleriniz artemis-credentials içindeki username/password anahtarlarını kullanıyorsa onu ayrıca kurumunuzun Secret yönetimiyle proje namespace’inde (<namespace>-integrations) sağlayın. Git ve registry için kullanılan lunex builder Secret’ı farklıdır; credentials.existingSecret onu devralmaz.

Paket içi Keycloak için insan yönetici parolaları ile keycloak-reconcile-secret ayrı sorumluluklardır. İnsan parolası değişebilir; makine secret’ı, Keycloak’taki istemci secret’ı ve kurulum kaydı birlikte korunmalıdır. Harici Keycloak’ta bu otomasyon Lunex tarafından kurulmaz.

Kalıcı veri ve yedekleme

PVC boyutları lunex.persistence.size, postgres.persistence.size, artemis.persistence.size, git.persistence.size ve registry.persistence.size üzerinden belirlenir. StorageClass global.storageClass ile seçilir. Kurulumdan sonra büyütme desteği storage altyapısına bağlıdır; values değerini değiştirmek tek başına her disk türünü büyütmez.

Git, bütün kurulumun yedeği değildir: kuyruktaki mesajları, kimlik kullanıcılarını ve dış sistemdeki iş verisini içermez. Bir geri yükleme planında bu bileşenlerin birbiriyle uyumlu sürümlerini dikkate alın.

Broker’da yeniden teslim ve dead letter’lar

Chart, paket içindeki broker’ın her kuyruğu için transacted bir route’un geri aldığı (rollback) teslimin nasıl yeniden deneneceğini ve sonra nereye gideceğini tanımlar. Konsolda ayar gerekmez; yeni ve mevcut broker diskleri aynı ayarları alır.

Varsayılanlarla bir mesaj yaklaşık 12,5 saat yeniden denenir. İlk dört değer tam sayı olmalıdır; tam sayı olmayan bir değerde, 1’den küçük çarpanda, ilk beklemeden kısa en uzun beklemede, birden az teslimde veya 0–1 dışındaki sapmada kurucu açıklayıcı bir mesajla durur. Bir değeri değiştirmek broker’ı yeniden başlatır.

Dead letter’lar DLA adresine gider: dead.letters kuyruğu her dead letter’ı saklar, dead.letter.events bir uyarı projesi için son 1000 olayı tutar. Dead letter’lar hiçbir zaman otomatik silinmez.

Broker diski (artemis.persistence.size, varsayılan 5Gi). Yeniden teslim bekleyen mesajlar ve bütün dead letter’lar bu diskte durur. Diski kabul ettiğiniz en uzun kesinti için boyutlandırın: o sürede gelen mesajlar çarpı boyutları, artı yeniden denenene veya silinene kadar tuttuğunuz dead letter’lar. Kurulumdan sonra büyütme StorageClass’a bağlıdır.

• Yeniden teslim süresi. Varsayılan ayarlarla bir mesaj dead letter olmadan önce yaklaşık 12,5 saat kuyruğunda bekleyebilir; sonra yeniden denenene veya silinene kadar kalır. Hedef sistemin bu süreden uzun bir kesintisi, o süre içinde gelen her mesajı dead letter yapar; disk hepsini taşır.
• Örnek hesap. 12,5 saatlik bir SAP kesintisinde saniyede 5 adet 20 KiB mesaj: 5 × 45.000 sn × 20 KiB ≈ 4,3 GiB. Diskin yalnız %90’ı kullanılabilir (aşağıda); kuyrukların olağan birikimi ve eski dead letter’lar eklendiğinde bu kesinti varsayılan 5Gi değerinden fazlasını ister.
• Yaşa göre silme. Her olayı, kimsenin işlemeyeceği dead letter’ları kaynak kuyruğa ve yaşa göre silerek kapatın. Araçlar dead letter rehberindedir.
• Disk sınırında. Kullanım %90’a ulaştığında (oluşturulan max-disk-usage ayarı) broker yer açılana kadar mesaj kabul etmez ve loguna AMQ222210 ile AMQ222212 yazar. Gönderimler bekler; mesajı kuyruğa yazan kabul akışı çağırana hata veya zaman aşımıyla döner. Hiçbir mesaj kaybolmaz: teslimler sürer, tüketilen veya silinen mesajlar yer açar.

Yükseltme ve geri dönüş

Yeni sürüm paketini açın, mevcut values ve credential dosyalarını koruyun; ilk kurulumdaki komutu aynı yapılandırmayla yeniden çalıştırın. Ayrı dev ve prod kurulumlarında önce dev’i yükseltin; sıra aşağıdaki Yükseltme sırası bölümündedir. Kurucu yükseltmeden önce paket içindeki PostgreSQL’in yedeğini varsayılan olarak /var/lib/lunex/backups/<timestamp>.sql.gz altında oluşturur. Harici veri tabanı otomatik yedeklenmez; yükseltmeden önce kendi veri tabanı yedeğinizi alın.

Paket içindeki Keycloak mevcut realm’i yeniden içe aktarmaz; istemci URL’lerini kurulum otomasyonu uzlaştırır. Mevcut kullanıcı parolalarını values değiştirerek güncellemeye çalışmayın. PostgreSQL major sürüm yükseltmesi aynı veri dizinini doğrudan yeniden kullanma işlemi değildir; desteklenen veri taşıma/yedek geri yükleme yolunu planlayın.

Proje namespace’i

Projeler kendi namespace’lerinde derlenir ve çalışır: <namespace>-integrations (örneğin lunex-integrations). Chart bu namespace’i oluşturur; kaldırma ve geri dönüşte silmez. Proje hesapları Lunex’in namespace’ine ve lunex-credentials Secret’ına erişemez. Lunex çalışan projeleri bu namespace’e taşımaz. 1.2.0 veya önceki bir sürümden yükseltmeden önce:

1. Lunex’te dağıtılmış her projeyi Undeploy edin ve her Run’ı durdurun.
2. Projelerin {{secret:…}} ve {{configmap:…}} ile kullandığı Secret ve ConfigMap’leri proje namespace’inde yeniden oluşturun.
3. Kurucuyu çalıştırın.
4. Her projeyi dev’de yeniden derleyin, prod’da sürümünü yeniden dağıtın.

Lunex’in namespace’inde paketlenmiş entegrasyon ya da Run podu kaldıkça kurucu yükseltmeyi reddeder ve projeleri listeler. Geri dönüşte de hedef revizyonun kullanmadığı namespace’te çalışan proje varsa reddeder; önce Undeploy edin. trust.caSecretName CA’sı ve global.imagePullSecrets her kurucu çalıştırmasında proje namespace’ine kopyalanır; bunlardan birini değiştirdikten sonra kurucuyu yeniden çalıştırın.

Build podları Kubernetes belirteci olmadan çalışır; Git ve registry bilgilerini Lunex her build’e kendisi aktarır ve build’in ürettiği paketi Lunex dağıtır. Yükseltmeden önce configuration projesine kaydedilmiş build.sh ve builder.pod.jkube.yaml dosyaları varsa silip commit edin; eski kopyalar build’i başlatamaz.

1.4.0’dan yükseltme: broker dead letter’ları

Broker bir kez yeniden başlar ve yukarıdaki Broker’da yeniden teslim ve dead letter’lar bölümünde tanımlı ayarlarla çalışır. Eski ortak DLQ kuyruğundaki mesajlar orada kalır; hiçbir şey onları taşımaz. Neden giderildiğinde Artemis konsolunu platform-admin olarak açın, Artemis JMX altında DLQ kuyruğunu seçin ve Operations içinde retryMessages() çalıştırın; mesajlar kaynak kuyruklarına döner. Kimsenin işlemeyeceği mesajları silin. Yeni dead letter’lar DLA adresine gider. Konsol işlemleri Lunex’te kayıt bırakmaz.

1.4.0’a geri dönüşte broker tanımlı ayarlar olmadan başlar: anında yeniden teslim, 10 teslim ve ortak DLQ yeniden geçerli olur; DLA mesajlarıyla broker diskinde kalır.

Önceki Helm revizyonuna dönüş:

sudo ./install.sh --rollback

Bu işlem release manifestlerini geri alır; veri tabanı içeriğini, TLS Secret’larının içeriğini (lunex-tls dahil), dış servis verisini ve ortak gateway controller/CRD sürümlerini otomatik geri almaz. Uygulama ve veri şeması uyumunu ayrıca değerlendirin. Projelerin çalışan sürümüne geri dönme işlemi runtime rehberinde açıklanır.

Dev ve prod kurulumları

Test edilen bir entegrasyonu üretime taşımak için iki ayrı Lunex kurulumu kullanılır: dev build yapar ve sürümleri Git’e yazar, prod bu sürümleri kendi değerleriyle dağıtır. Akışın kendisi sürüm rehberinde anlatılır; bu bölüm yöneticinin planlaması gereken sınırları özetler.

• Ortam adı: lunex.environment kurulumun ortamını belirler; varsayılan dev’dir. Prod kurulumunda lunex.environment: prod yazın. Prod’da Build, commit, Create release ve proje silme sunucu tarafından reddedilir; Pull çalışır.
• Ortak Git ve registry: iki kurulum aynı Git deposunu ve imaj registry’sini kullanır; dev’deki Gitea kurulumu bu ikisini birlikte sağlar. Prod’un git.external ve registry.external hesapları yalnız okuma yetkili olmalıdır; sürümleri listelemek ve dağıtmak için okuma yeterlidir. Dev’in sertifikası kurumunuzun güvendiği bir CA ile imzalanmamışsa prod’da CA’yı trust.caSecretName ile belirtin.
• Geliştirici erişimi: Gitea’da platform-developer rolündeki kullanıcılar ilk Keycloak girişlerinde developers takımına alınır ve entegrasyon deposuna yazabilir; rol kaldırılınca üyelik bir sonraki girişte kalkar; yazma erişiminin hemen kesilmesi gerekiyorsa üyeliği Gitea’da takımdan elle kaldırın. Geliştirici Gitea’da Ayarlar → Uygulamalar altında kişisel erişim belirteci oluşturur ve kullanıcı adı ile bu belirteci kullanarak HTTPS üzerinden push eder. releases dalı ve sürüm etiketleri yalnızca Lunex’in dev hesabına açıktır. Geliştiricilerin ağları gitea.allowedCidrs içinde olmalıdır.
• Ortam değerleri: namespace, servis hesabı ve Message Monitor bağlantısını dağıtan kurulum ekler; prod mesajları prod’un veri tabanına yazılır. Projelerin {{secret:ad/anahtar}} ve {{configmap:ad/anahtar}} ile başvurduğu Secret ve ConfigMap’leri her ortamda kendi değerleriyle oluşturun. Başvurduğu değer prod’da yoksa sürüm prod’da başlamaz; Lunex önceki sürümü geri yükler.

Geliştirme kurulumundaki her kimlik bilgisi, orada çalışan geliştiriciler ve ajanlar, ayrıca ajanların model sağlayıcıları tarafından okunabilir. Bu yüzden geliştirme kurulumlarını yalnız test sistemlerine, en az yetkili kullanıcılarla bağlayın; üretim kimlik bilgilerini hiçbir zaman geliştirme kurulumunda tutmayın.

Prod’un dev’e bağlılığı

Prod, sürümleri dev’in Git deposundan okur ve imajları dev’in registry’sinden çeker. Dev’in Gitea’sı durduğunda:

• prod’da çalışan entegrasyonlar hizmet vermeye devam eder;
• imajı node’da bulunan bir pod aynı node’da yeniden başlayabilir, örneğin Restart ile; imaj yeniden çekilmez;
• başarısız bir dağıtımın otomatik geri yüklemesi de çekme gerektirmez, çünkü eski pod çalışmaya devam eder;
• sürüm listesi Git’in nedenini gösteren bir hata verir; sürüm dağıtmak ve imajı henüz bulunmayan bir node’da pod başlatmak dev geri gelene kadar bekler;
• bu sırada yeniden başlayan prod Lunex podu hazır olmaz. Dev geri geldiğinde prod’da kubectl -n lunex rollout restart deployment/lunex çalıştırın.

Dev’in bakım ve yedekleme penceresini bu nedenle prod dağıtımlarıyla birlikte planlayın.

Bir pod daha için yer

Daha yeni bir sürümün dağıtımı ve Restart, yeni podu eski pod durmadan önce başlatır. Namespace kotası (resourceBudget.quota, varsayılan olarak kapalı) ve node’lar aynı anda güncellenen her entegrasyon için bir pod daha kaldıracak yer bırakmalıdır. Kendi RAM ayarı olmayan bir entegrasyon 512 MiB istek ve 1 GiB sınır alır. Kota açıkken build podları ayrı bir kotada sayılır, bu yüzden build dağıttığı podun kotadaki yerini almaz; node’larda build podu için de yer kalmalıdır. Hesap için kaynak rehberini kullanın.

Yer yoksa yeni pod oluşturulamaz; eski sürüm hizmet vermeye devam eder, Lunex dağıtımın ilerleme süresi (180 sn) dolunca Kubernetes’in kota veya zamanlama mesajını gösterir ve son başarılı paketi geri yükler. Bu durum yeni sürümdeki bir hata değildir: kotayı veya node kapasitesini artırın ve dağıtımı tekrarlayın.

Yükseltme sırası

Her sürüm, onu build eden Lunex’in platform sürümünü taşır. Yükseltmeyi şu sırayla yapın:

1. Önce dev kurulumunu yükseltin.
2. Dev’de entegrasyonları yeniden build edin, test edin ve Create release ile yeni sürüm yapın.
3. Sonra prod kurulumunu yükseltin ve bu sürümleri dağıtın.

Prod, kendi sürümünden daha yeni bir Lunex ile build edilmiş sürümü reddeder ve gereken sürümü gösterir. Daha eski bir Lunex ile build edilmiş sürüm Rebuild required · built by <sürüm> gösterir ama dağıtılabilir; böylece yükseltmeden sonra da önceki sürüme dönmek ve otomatik geri yükleme çalışır.

Geliştirici bilgisayarında k3d kurulumu

Lunex kaynak dizininde Java 25, Docker, k3d, kubectl, Helm, OpenSSL ve jq bulunmalıdır. Yerel başlatma:

./scripts/local-up.sh

Bu akış ayrı etzel-lunex k3d cluster’ını, namespace ve bağımlılıkları hazırlar. Güncel kaynaklardan imajları oluşturur. Uygulamayı yerel Lunex adresinden açın. Giriş kullanıcısı admin, ilk parola .local/admin-password dosyasındadır; kimlik servisi yerel Keycloak adresini kullanır.

Başlangıcı incelemek için:

KUBECONFIG="$PWD/.local/kubeconfig" kubectl -n lunex get deployments,pods
KUBECONFIG="$PWD/.local/kubeconfig" kubectl -n lunex logs deployment/lunex --tail=80

.local altındaki credential ve kubeconfig dosyalarını Git’e eklemeyin. Cluster’ı durdurmak ile silmek farklıdır; cluster’ı silmek yerel kalıcı verileri de kaybettirebilir. Yerel Git ve registry, geliştirme ortamına ait servislerdir; dış kullanıcıların eriştiği sunucu düzenini yukarıdaki kurulum ayarlarıyla hazırlayın.

SAP bağlantısı gerekiyorsa platform SDK/worker hazırlığı da gerekir. Gereken dosyalar ve etkinleştirme adımları SAP bağlantısı rehberindedir.

Kurulumun başarılı olduğunu doğrulama

Yalnızca bir podun Running olmasıyla tamamlandı kabul etmeyin. Gerçek kullanıcı adresinden giriş/çıkışı, bir deneme projesi oluşturmayı, Git push/pull’u, geliştirme çalışmasını, build’i ve gerekiyorsa yayımlanan API’ye erişimi doğrulayın. Broker kullanılacaksa mesaj gönderme ve tüketme akışını da deneyin.

Başlangıçta takılma için uygulama pod olaylarını, init container’ın Git/veri tabanı bekleme durumunu, kimlik discovery erişimini ve imaj çekme hatalarını sırayla kontrol edin. Daha ayrıntılı yönlendirme sorun giderme rehberindedir.