Entegrasyonu çalıştırma, paketleme ve dağıtma

Lunex’te bir entegrasyonun kaynakları ile çalışan sürümü ayrı durumlardır. Dosyayı kaydetmek kaynakları günceller. Çalışan geliştirme sürümünü Run / Reload, Git’teki sürümü paketleyip Kubernetes’e dağıtmayı Build yönetir. İşlemden önce hangi kaynak sürümünün ve hangi dış sistemlerin kullanılacağını belirleyin.

İki sürümü adım adım paketlemek, sürüm yapmak ve başka bir ortama dağıtmak için geliştirmeden üretime, ekrandaki pod ve log alanlarını okumak için çalışan projeyi inceleme rehberini kullanın.

Hangi çalıştırma biçimini seçmeliyim?

Build, yalnızca bir imaj hazırlayan pasif işlem değildir. Varsayılan iş akışı dağıtımı da değiştirir. Üretim ve geliştirme ortamlarını aynı kurulum gibi değerlendirmeyin: prod kurulumu Build isteğini reddeder.

Geliştirme çalışmasını başlatma

Ön koşullar: platform-developer rolü, kaydedilmiş kaynaklar, erişilebilir dış servisler ve bu servislerin ihtiyaç duyduğu yapılandırma/Secret’lar. İlk çalıştırmada bağımlılık indirme ve runtime hazırlama süresi olabilir.

1. Source altında application.properties, akış dosyaları ve bağlantı adreslerini gözden geçirin.
2. Zamanlayıcı veya kuyruk tüketicisinin gerçek işlem yapmasını istemiyorsanız önce simülasyon kullanın. Run dış alıcılara gerçek istek gönderebilir.
3. Run seçin.
4. Açılan Log bölümünde başlangıcı izleyin. Starting container… tamamlandıktan sonra projenin çalışma durumunu kontrol edin.
5. Deployment sekmesinin Runtime tablosunda Version sütunu Development olan podu inceleyin; pod olayları için satırı genişletin.
6. Entegrasyonun girişinden bir deneme isteği veya mesajı gönderin; beklenen iş sonucunu ve Message Monitor kaydını doğrulayın.

Konteynerin çalışması, dış sisteme bağlantının veya her route’un başarılı olduğu anlamına gelmez. Örneğin pod ayakta kalırken bir kuyruk bağlantısı tekrar deneniyor olabilir. Başlangıç logunu, route durumunu ve gerçek deneme sonucunu birlikte değerlendirin.

Development run options menüsündeki Run verbose daha ayrıntılı başlangıç çıktısı sağlar. Run compile derleme modunu seçer; normal kaynak yeniden yükleme akışı bu seçenekle aynı değildir. Çalıştırma hatasını araştırırken ilk hata satırından sonraki özet satırları yerine bağımlılık/derleyici hatasının asıl nedenini okuyun.

Kaynak değişikliğini çalışan geliştirme sürümüne aktarma

1. Dosyanızı değiştirin, Saved durumunu veya ilgili Save işlemini bekleyin.
2. Görünüyorsa Reload seçin.
3. Reloading code… sonrasında runtime logunu ve aynı test isteğinin sonucunu kontrol edin.

Reload, Git commit’i oluşturmaz ve paketlenmiş imajı değiştirmez. Secret referansı, environment variable, volume, imaj veya pod kaynak ayarı değişikliklerinde podun yeniden oluşturulması gerekir; yalnızca kaynak yeniden yüklemeye güvenmeyin. Camel application.properties dosyasındaki bileşen (camel.component.*), camel.main.* ve bağımlılık ayarlarını yalnızca başlarken okur; bu dosya Run’dan sonra değiştiyse Reload ve ajanın pull_and_run_project çağrısı podu silip yeniden çalıştırır. Reload sunulmuyorsa geliştirme konteynerini kaldırıp Run ile yeniden başlatın.

Stopped waiting for native Reload veya işlem sonucunun doğrulanamadığını belirten bir hata alırsanız önce çalışma durumunu ve logu yenileyin. İstek zaman aşımına uğrasa da runtime tarafında işlem tamamlanmış olabilir.

Geliştirme çalışmasını sonlandırma

Kubernetes kurulumunda Delete container, geliştirme podunu ve ona ait çalışma kaynağını kaldırır; projenin kaydedilmiş dosyaları ve Git geçmişi kalır. Yeni bir deneme için tekrar Run kullanabilirsiniz. Aktif isteklere ve kuyruk tüketimine etkisini değerlendirerek sonlandırın.

Paketlenmiş runtime varsa Run düğmesi sunulmayabilir. Deployment sekmesinde Version sütunu Development olan geliştirme podunu paketlenmiş podlardan ayırın. Paketlenmiş servisi yeniden başlatmak için geliştirme işlemlerini kullanmayın.

Git sürümünden Build çalıştırma

Ön koşullar: dev kurulumu, Git’e gönderilmiş proje, build podunun Git ve registry erişimi, bağımlılıkların indirilebildiği veya kurulumda sağlandığı ortam ve yeterli CPU/RAM bütçesi.

1. Commit and push yapın. Dağıtılmasını istediğiniz bütün kaynak, sözleşme, yayın ve dağıtım dosyalarının commit’e girdiğini kontrol edin.
2. Çalışan bir geliştirme podu varsa onu Delete container ile sonlandırın; aynı kaynakları tüketen deneme ve paketlenmiş sürümleri eşzamanlı çalıştırmayın.
3. Build sekmesini açın.
4. Build seçin ve aynı bölümdeki build logunu izleyin.
5. Tamamlandığında Deployment → Runtime tablosunda podun durumunu ve Version sütununu (sürüm yapılmamış bir build için Unreleased build) kontrol edin. Satırı genişletip pod olaylarını, ardından Log çıktısını inceleyin.
6. Yayınlanan giriş üzerinden bir isteği çalıştırıp beklenen yanıtı ve iş etkisini doğrulayın.

Build başlangıcında seçilen commit sabitlenir. Dal daha sonra ilerlese bile sıradaki build’in kaynakları bu commit’ten alınır. Henüz commit edilmemiş değişiklikler build’e dahil olmaz. Commit the project to Git before building hatası alırsanız önce commit ve push işlemini tamamlayın.

Build imajı derlediği son commit’in kısa (7 karakterlik) kimliğiyle, commit yoksa latest ile etiketler; etiket girilmez. Deploy etiketi değil, imajın digest’ini kullanır. Paketlenmiş runtime Git’i izleyerek yeni kodu kendiliğinden yüklemez. Yeni kod, yeni imajın Deployment’a uygulanmasıyla çalışır. Sürüm örneği kaydetme, commit, imaj ve çalışan pod eşleşmesini gösterir.

Varsayılan Kubernetes build’i sırayla kaynakları Git’ten alır, runtime ve API kaynaklarını hazırlar, uygulamayı paketler, imajı registry’ye gönderir, Kubernetes kaynaklarını uygular, Kubernetes’in rollout sonucunu bekler ve yapılandırılmış API erişimini etkinleştirir. Paketten çıkarılan kaynakları da bir sonraki Build’de siler. Build isteğinin kabul edilmesi bu adımların tamamlandığını göstermez; sonucu Build bölümünde izleyin. Yayın ayarları ve erişim kontrolü için API yayımlama rehberini kullanın.

Starting build… isteğin yeni build kaynağına aktarılmasını, Building… çalışmanın sürdüğünü, Build completed yalnızca Kubernetes tüm replica’ların yeni sürümü çalıştırdığını ve eski replica kalmadığını bildirdiğinde görünür. Yeni sürüm Deployment’ın süresi (180 sn) içinde hazır olmazsa Build failed Kubernetes’in nedenini gösterir: yeni pod oluşturulamadıysa kota gibi ReplicaFailure mesajını, oluşturulduysa yeni podun zamanlama, imaj çekme veya hazır olma (readiness) mesajını. Bu sırada önceki sürüm hizmet vermeye devam eder ve Lunex bu ortamda son başarılı olan paketi yeniden dağıtır; açıklama Deploy failed and restored the last successful package: ile başlar. Yalnızca başarısız pakette bulunan kaynaklar silinir. Geri yükleme de başarısız olursa açıklama iki nedeni birlikte gösterir. Projenin ilk dağıtımında geri yüklenecek paket yoktur; başarısız sürüm incelemek için yerinde kalır. Çalışma sırasında tekrar Build gönderilmez; aynı projede sürmekte olan bir işlem varken başlatılan ikinci işlem reddedilir. Namespace kotası açık bir kurulumda varsayılan olarak aynı anda bir build çalışır: başka bir projenin build’i sürerken Build request failed exceeded quota: lunex-builds mesajını gösterir; o build bitince yeniden deneyin. Bir build en fazla 30 dakika sürer; süre dolarsa Kubernetes build podunu durdurur, Build failed DeadlineExceeded nedenini gösterir ve önceki sürüm çalışmaya devam eder. Süreyi ve builder’ın RAM’ini kurulum yöneticisi kaynak rehberindeki ayarlarla değiştirir. Build blocked veya kota hatası görünürse açıklamayı ve logu kontrol edin; tekrar tekrar basmak kaynak sınırını çözmez.

Tamamlanmış veya başarısız build podunu kaldırmak için Delete build kullanabilirsiniz. Bu işlem registry’deki imajı, kaynak projeyi veya paketlenmiş Deployment’ı geri almaz.

Bir sürümü dağıtma

Kubernetes kurulumlarında Deployment sekmesinin altındaki Releases tablosu projenin sürümlerini en yenisi üstte listeler: sürüm numarası (Release), kaynak commit’inin mesajının ilk satırı (Commit message; mesajı okunamayan commit için —), yerel saatle oluşturulma zamanı (Created), sürümü oluşturan kullanıcı (Created by, Git etiketini oluşturan) ve Status. Status, bu ortamda çalışan sürümde yeşil Deployed etiketini, dağıtılmakta olan sürümde Deploying göstergesini gösterir. Liste her açılışta ve Refresh releases ile Git deposundan okunur. Ondan fazla sürüm varsa tablo sayfalanır; daha eski sürümler için Older releases kullanın. Sürüm Create release ile dev kurulumunda oluşur.

1. Tabloda dağıtmak istediğiniz sürümün satırında Deploy seçin. Çalışan sürümün satırında Deploy yoktur; aynı sürümü yeniden başlatmak için Restart kullanın.
2. Deploy release <numara> onayında değiştirilecek sürümü, ortamı ve yeni sürümün commit mesajını (Replaces release <numara> in <ortam> with “<mesaj>”.) kontrol edip Deploy seçin.
3. Sonuç gelene kadar Runtime araç çubuğunda Deploying release <numara>…, sürümün satırında Deploying görünür ve aynı projede ikinci bir işlem gönderilemez. Rollout sırasında Version sütunu eski ve yeni podun hangi sürümü çalıştırdığını gösterir. Durduruluyor olan eski pod Stopping · Terminating görünür; hazır bir pod hizmet verdiği sürece projenin durumu Running kalır. Yeni pod çökerse Kubernetes onu yeniden başlatır: pod Restarting ve çökme nedeniyle, yeniden deneme beklemesinde Blocked · CrashLoopBackOff görünür; ikisi de son çalışmanın sonlanma mesajını gösterir. Satır açıksa podun olayları durum değiştikçe yenilenir. İşlemin süresini Deployment’ın ilerleme süresi (180 sn) ve olası geri yükleme belirler; arayüz bir zaman aşımı eklemez.
4. Deploy of release <numara> completed, tüm replica’lar yeni sürümü çalıştırdığında ve eski replica kalmadığında görünür. Deployed etiketi bu sürüme geçer.

Deploy çalışan dağıtımı silmeden günceller: Kubernetes eski podu ancak yenisi hazır olunca durdurur, bu yüzden namespace kotasında ve node’larda bir pod daha için yer olmalıdır. Paket, sürümün Git etiketindeki dosyadan okunur ve bu kurulumun namespace, servis hesabı ve Message Monitor bağlantısıyla uygulanır. Yeni pakette artık bulunmayan nesneler silinir; API yayını varsa rotalar rollout tamamlandıktan sonra bu kurulumun adresiyle yeniden oluşturulur.

Yeni sürüm hazır olmazsa önceki sürüm hizmet vermeye devam eder ve Lunex bu ortamda son başarılı olan paketi yeniden dağıtır. Sekmenin üstündeki Deploy of release <numara> failed, the previous version runs again bildirimi Kubernetes’in nedenini gösterir: başarısız readiness kontrolü, imaj çekme, zamanlama veya kota mesajı. Geri yükleme de başarısız olursa Deploy of release <numara> failed iki nedeni birlikte gösterir. Ortamda daha önce başarılı bir dağıtım yoksa başarısız sürüm incelemek için yerinde kalır.

Deploy, projenin Pull işlemlerine bağlı değildir ve commit edilmiş kubernetes.yaml gibi manifestleri kullanmaz. Bir proje bir ortamda ilk kez Projects listesindeki Pull ile görünür. Bu yüzden ortamın hiç çekmediği bir projenin ilk sürümü için orada bir kez liste Pull’u gerekir; sonraki sürümler Pull olmadan listelenir ve dağıtılır. Liste ve Deploy yalnız Git okuması yapar, salt okunur Git kimlik bilgisiyle çalışır. platform-developer rolü olmayan kullanıcılar sekmeyi salt okunur görür; Restart, Undeploy, Create release ve Deploy görünmez.

Restart, kaldırma ve sürüm geri dönüşü

Mevcut dağıtım için Deployment → Restart (Restart <proje> onayı) paketi değiştirmeden podları yeniden başlatır. Yeni kaynak commit’ini derlemez ve başka bir imaja geçmez. Pod ortam değişkeni veya Secret güncellemesinden sonra bu işlem gerekebilir. Kubernetes önce yeni podları başlatır, eski podları ancak yeniler hazır olunca durdurur; bu yüzden namespace kotasında ve node’larda bir pod daha için yer olmalıdır. Restart, yeniden başlatılan podların tamamı hazır olduğunda ve eski pod kalmadığında tamamlanır. Yeni podlar Deployment’ın ilerleme süresi içinde hazır olmazsa Restart başarısız olur ve Kubernetes’in nedeni gösterilir: başarısız readiness kontrolü, imaj çekme, zamanlama veya kota mesajı. Eski podlar hizmet vermeyi sürdürür. Paket değişmediği için geri yüklenecek bir şey yoktur; nedeni giderip yeniden deneyin.

Undeploy (Undeploy <proje> onayı) projenin yayınlanmış API rotalarını, paketin tüm nesnelerini ve ortamın sürüm kaydını kaldırır. Paketin nesnelerine, parça dosyalarıyla eklenen ConfigMap veya CronJob gibi nesneler de dahildir. Undeploy, Deployment’ın podları sonlanana kadar bekler. Run ve build podlarına, yöneticilerin oluşturduğu Secret ve ConfigMap’lere, proje kaynaklarına, sürümlere ve Git geçmişine dokunmaz. Açık bir kaldırma olduğu için Message Monitor’daki geçici kayıt penceresini iptal eder. Dış sistemlerdeki iş verisinin temizlenmesini ayrı yönetin.

Deploy, Restart, Undeploy ve Create release arka planda çalışır. Deploy, Restart ve Undeploy bitene kadar Runtime araç çubuğunda düğmelerin yerinde ilerleme görünür (Deploying release <numara>…, Restarting…, Undeploying…); Create release süresince Releases araç çubuğunda Create release yerine Creating release… görünür. İşlem ikinci kez gönderilemez; sekmeden ayrılıp dönseniz de ilerleme görünmeye devam eder. Aynı projede başka bir işlem sürüyorsa, örneğin bir Build’in dağıtımı, Deploy, Restart, Undeploy veya Create release, yeni işlem reddedilir ve nedeni gösterilir. Önceki işlem bitince yeniden deneyin. Tamamlanma (Restart completed gibi; Create release için oluşan sürümü adlandıran Release <numara> created) ve ret (Restart refused gibi) bildirim olarak görünür; ret bildirimi Lunex’in bildirdiği nedeni içerir ve siz kapatana kadar kalır. Başarısız işlem sekmenin üstünde <İşlem> failed bildirimiyle Kubernetes’in veya Git’in nedenini gösterir; bu bildirim projenin bir sonraki işlemi başlayana kadar herkes için kalır.

Deployment incomplete görünüyorsa son dağıtım veya kaldırma tamamlanmamıştır. Last successful son başarılı sürümü gösterir; çalışan sürümün doğrulandığı anlamına gelmez. Bu durum Lunex yeniden başlatıldığında da kalır. Aynı sürüm dahil uygun bir sürümü Deploy ederek, dev ortamında yeniden Build yaparak veya Undeploy ile kaldırmayı tamamlayarak toparlayın. Bu sırada Restart ve Create release kullanılamaz. Pod kalmamış olsa da Undeploy sunulur. Bir işlem sürerken, örneğin Build dağıtım aşamasındayken, bu uyarı görünmez, Runtime A deployment in <ortam> is in progress. der, önceki sürüm Deployed yerine Last successful etiketini taşır ve Deployment sekmesindeki düğmeler işlem bitene kadar devre dışı kalır; uyarı yalnızca işlem tamamlanmadan durduysa çıkar. Erişim veya yetki hatası varsa önce nedeni giderin.

Nesne uygulama, rollout, API yayını, budama veya sonuç kaydı başarısız olduğunda Lunex son başarılı paketi geri yüklemeyi dener. Geri yükleme de başarısızsa iki neden gösterilir ve durum tamamlanmamış kalır. İlk dağıtımda önceki başarılı paket bulunmadığından başarısız kaynaklar inceleme için kalır. Lunex kapanırken veya işlem kilidini kaybettiğinde otomatik geri yükleme başlatılmaz.

Önceki sürüme dönmek, Releases tablosunda önceki sürümü Deploy etmektir; ayrı bir geri alma mekanizması yoktur. Commits ekranı dağıtım geri alma aracı değildir. Veri tabanına ya da dış sisteme yapılmış iş değişiklikleri, sürüm değiştirilince otomatik geri alınmaz.

Ortam adı ve dağıtım hedefi

Kurulum yöneticisi aktif ortamı values dosyasındaki lunex.environment (LUNEX_ENVIRONMENT), arayüzde bilinen ortam adlarını LUNEX_ENVIRONMENTS ile belirleyebilir. Varsayılan ortam dev’dir. Dosya için Copy for environment, uygun altyapı dosyasını seçilen ortam ön ekiyle kopyalar; yeni cluster, namespace veya kimlik sağlayıcısı oluşturmaz.

İşlemler mevcut Lunex kurulumunun bağlı olduğu Kubernetes namespace’inde gerçekleşir. Bir ortam adı girerek başka cluster’a dağıtım veya otomatik geliştirme/test/üretim terfisi kurulmaz. Bu ayrım kurulum yönetiminin sorumluluğundadır.

Başarısız çalıştırmayı araştırma