Ana içeriğe geç

Apinizer Sürüm Yükseltme

Apinizer sürüm yükseltme işlemi, kurulum tipi (Kubernetes, Docker, Sanal Sunucu) ve ağ erişim durumuna göre farklı yöntemlerle gerçekleştirilebilir. Her adımda veri kaybını önlemek için MongoDB yedeği alınması ve güncellemeler arası uyumluluğun sağlanması önerilir.

Güncelleme Yöntemleri​

Apinizer sürüm yükseltme işlemi, Kubernetes worker sunucularının internete erişim durumuna göre iki farklı yöntemle gerçekleştirilebilir:

Çevrim İçi Güncelleme

Kubernetes cluster'ının internet erişimine sahip olduğu durumlarda kullanılır. Docker imajları doğrudan Docker Hub'dan çekilir ve otomatik olarak güncellenir. Daha hızlı ve kolay bir güncelleme süreci sağlar.

Ne Zaman Kullanılır:

  • Kubernetes worker sunucuları internete erişebiliyorsa
  • Hızlı ve kolay güncelleme yapmak istiyorsanız
  • İmaj transferi için ekstra adımlar atmak istemiyorsanız
Çevrim Dışı Güncelleme

Kubernetes cluster'ının internet erişimine sahip olmadığı veya güvenlik politikaları nedeniyle doğrudan internet erişiminin kısıtlandığı durumlarda kullanılır. İmajlar önce internete erişimi olan bir sunucuda çekilir, .tar dosyası olarak kaydedilir veya yerel bir registry'ye yüklenir.

Ne Zaman Kullanılır:

  • Kubernetes worker sunucuları internete erişemiyorsa
  • Güvenlik politikaları nedeniyle doğrudan internet erişimi kısıtlanmışsa
  • Yerel bir Docker registry (Nexus, Harbor vb.) kullanılıyorsa

Yöntemler:

  • Manuel İmaj Transferi
  • Yerel Registry Kullanımı
uyarı

Güncelleme işleminden önce, mevcut sistem yapılandırmasıyla uyumsuzluk oluşturabilecek değişiklikleri tespit etmek ve gerekli önlemleri almak adına Sürüm Notlarının incelenmesi tavsiye edilir.

2026.09.2'ye Yükseltme — Kimlik ve Limit Taşıması

Bu sürüme yükselten bir Manager, açılışta kimlik ve limit verilerinizi kendiliğinden taşır — operatör müdahalesi gerekmez (bkz. Eski Kayıtlar: Otomatik Taşıma → Yükseltmede Otomatik Taşıma). Taşıma, Manager'ın HTTP dinleyicisi açılmadan önce çalışır; yaklaşık 4.000 kayıtlık bir kurulumda birkaç dakika sürer ve bu süre boyunca Manager istek kabul etmez. Sonuçlar api_client_migration_run / api_client_migration_row kayıt defteri koleksiyonlarına yazılır ve taşıma tamamen yakınsayana kadar her gün 03:45'te çalışan bir arka plan görevi eksik kalan kayıtları yeniden dener.

Bu taşıma için bir geri alma (rollback) mekanizması yoktur — yükseltmeden önce aşağıdaki adımda anlatılan MongoDB yedeğini almanız tek geri dönüş yoludur. Aynı sürümle birlikte Rate Limit Kontrol Listesi emekliye ayrılmıştır ve API Proxy ACL / API Proxy Grup ACL satırlarındaki ortam bazlı Daraltma/Kota alanları artık gateway tarafından uygulanmaz. Ortam bazlı AI token bütçesi alanı da 2026.09.2 yükseltmesinde typed bir AI Token Limiti atamasına taşınmıştır. 2026.10.0 sürümü bu alanı ve diğer AI bütçelerini (kuruluş, uygulama, proje, genel varsayılan) kaldırır; bu değerler dönüştürülmeden silinir (bkz. Desteği Sonlandırılanlar ve Kaldırılanlar). 2026.09.2 yükseltmesinde taşınan atamalarda sayaç sıfırlanmaz, taşınmış tüketici/istemci aynı sayaç havuzunda kalmaya devam eder — bu, sıfırdan başlayan İstek Hızı sayaçlarının aksinedir. AI Token Limiti ailesi de artık gölge modunda değildir, typed atamalar gerçekten uygulanır; gölge karşılaştırmasını kapatan apinizer.limit.shadow.enabled JVM sistem özelliği bu sürümde kaldırılmıştır.

Taşınmış kimlik bilgilerinin eski (legacy) parola kopyaları hemen silinmez — kimlik adımı tamamlandıktan 7 gün sonra günlük bir arka plan görevi tarafından temizlenir (bkz. Eski Kayıtlar: Otomatik Taşıma → Yükseltmede Otomatik Taşıma). Bu 7 günlük pencere içinde kurulumunuzdaki tüm gateway'leri (Worker) bu sürüme yükseltin — eski sürüm bir gateway pod'u bu pencereden sonra yeniden başlarsa taşınmış kimlik bilgilerini doğrulayacak legacy parolayı artık bulamaz.

Bu sürüm ayrıca OAuth2 erişim ve yenileme token'larını yalnızca özet (digest) ile saklanan bir yapıya taşır — ne değiştiğini Token Servisi sayfasında bulabilirsiniz. Yukarıdaki açılış-anı adımı eksik kalan özetleri tamamlar ve ardından eski düz metin sütunlarını kaldırır; ayrıca bir işlem yapmanız gerekmez. Bu değişikliğe özgü olarak, gateway (Worker) düğümlerini Manager'dan önce yükseltin: henüz yükseltilmemiş bir Worker, zaten yükseltilmiş bir Manager'a karşı eski düz metin sütunlarını yazmaya devam ederse, bu sütunlar yalnızca bir sonraki temizlik geçişine kadar kullanılmadan kalır — bu bir güvenlik açığı değil, geçici bir fazlalıktır.

Bu sürüm ayrıca Yasal Saklama ve Veri Yaşam Döngüsü Temizleme özelliğini tanıtır. Yükseltme, yeni Veri Yaşam Döngüsü yetki kategorisini ve üç yeni koleksiyonu (yasal saklamalar, temizleme koşuları, temizleme koşusu bulguları) ekler; mevcut verileriniz bunun dışında değişmeden kalır. Yeni yetki otomatik olarak yalnızca Project Owner rolüne verilir — önceden tanımlı başka hiçbir role yasal saklama koyma veya temizleme çalıştırma yeteneği verilmez; böylece hiçbir mevcut kullanıcı beklenmedik biçimde veriyi kalıcı olarak silme yeteneği kazanmaz. Log Saklama altındaki diğer kalemlerin yanına, varsayılan olarak kapalı olan özel bir Lifecycle Purge Run History (Temizleme Koşusu Geçmişi) saklama ayarı eklenir. Elasticsearch API trafik logları bu özellik tarafından hiçbir yönde yeniden yazılmaz — bunların nasıl zamanla düştüğü için bkz. Yasal Saklama ve Veri Yaşam Döngüsü Temizleme → Veri Sahibi Silme.

Token özet (digest) taşıması, çok büyük bir token geçmişine sahip kurulumlarda yükseltme sonrası ilk açılış süresini biraz uzatabilir — bu, eksik özetleri tamamlayan açılış-anı adımının kendisinden kaynaklanır ve operatör müdahalesi gerektirmez; ilerlemeyi Manager (Mongock migration) logundan izleyebilirsiniz.

Bu sürümde ayrıca, deploy edilmiş bir kimlik bilgisinin IP listesinin her istekte büyüyüp global ve ortam listelerinin birleşiminin kalıcı hâle gelmesine yol açan bir davranış düzeltildi. IP kısıtlaması kullanan müşteriler yükseltme sonrasında listelerini gözden geçirsin — daha önce kabul edilen bir IP artık reddedilebilir.

Hangi dizinden geldiği hesabında kayıtlı olmayan bir LDAP kullanıcısı, yapılandırmada devre dışı bırakılmış bir LDAP bağlantısı bulunduğu sürece artık içeri alınmıyor. Bu sürümden önce böyle bir hesap yalnızca açık bağlantılarda aranıyordu; bu, hesabın kalıcı olarak yanlış dizine bağlanmasına ve bilerek kapattığınız bir dizinin kullanıcılarının girmeye devam etmesine yol açabiliyordu. Yapılandırmanızda kapalı bir LDAP bağlantısı duruyorsa onu açın ya da silin — kurulumun tamamı için tek işlem — veya etkilenen kullanıcıları bir kez açıp kaydedin; böylece hesap kendi bağlantısını kaydeder. Bağlantısı zaten kayıtlı olan hesaplar etkilenmez, reddedilen girişler ise gerekçesiyle birlikte Giriş Kayıtları'na yazılır.

2026.09.2'ye Yükseltme — Büyük/Küçük Harf Duyarsız Yinelenen Kullanıcı Adı

Bu sürüm, kullanıcı adlarının (login) büyük/küçük harf farkı gözetmeksizin tekil olmasını zorunlu kılan bir dizin kurar. Yükseltmeden önce, aşağıdaki §1'de anlatıldığı gibi MongoDB yedeğini aldıktan sonra, MongoDB sunucusunda şu sorguyu çalıştırarak mevcut kullanıcılarınız arasında yalnızca büyük/küçük harfle ayrışan bir çift olup olmadığını kontrol edin:

db.user.aggregate(
  [
    { $match: { login: { $type: "string" } } },
    { $group: { _id: "$login", count: { $sum: 1 }, logins: { $push: "$login" } } },
    { $match: { count: { $gt: 1 } } }
  ],
  { collation: { locale: "en", strength: 2 } }
)

Sonuç boşsa bir işlem gerekmez. Bir veya daha fazla grup dönerse, yükseltmeden önce her grupta yalnızca bir kullanıcı adı kalacak şekilde hesapları Kullanıcılar ekranından yeniden adlandırın ya da fazla olan hesabı silin.

Bu adım atlanırsa: Manager yine açılır ve mevcut kullanıcılarınız normal şekilde giriş yapmaya devam eder — dizin yalnızca kurulamaz ve günlüğe bir uyarı yazılır. Ancak dizin kurulana kadar yeni bir LDAP kullanıcısının ilk girişte hesabının otomatik oluşturulması reddedilir (daha önce hesabı oluşturulmuş LDAP kullanıcıları etkilenmez). Bu nedenle Manager'ın sorunsuz açılması, dizinin kurulduğunun kanıtı değildir: yükseltme sonrasında Manager günlüğünde 202609-006722 etiketli satırı arayın — "installed/verified" ile bitiyorsa dizin kuruludur, "NOT installed" ile bitiyorsa yukarıdaki sorguyla yinelenen kayıtları giderip Manager'ı yeniden başlatın; bu adım her açılışta otomatik olarak yeniden denenir.

2026.09.2'ye Yükseltme — Denetim Olayı / Login Log tablosu kolonları (yalnızca SQL/JDBC connector)

Kurulumunuz Denetim Kayıtları'nı veya Giriş Kayıtları'nı SQL/JDBC connector'ı üzerinden ilişkisel bir veritabanına gönderiyorsa, Denetim ve Login Log Tablosu ALTER Scriptleri'ni o veritabanına karşı yükseltmeden önce çalıştırın — "önce veya sırasında" değil, çünkü bu sürümün bu iki tabloya karşı yaptığı INSERT koşulsuzdur. Script çalışana kadar her Denetim Olayı satırı yazılamaz (yine de yapılandırılmış failover connector'ınıza ulaşır) ve her Login Log satırı failover olmadan yazılamaz — tamamen düşer. Bu iki log tipi için Elasticsearch veya MongoDB connector'ı kullanıyorsanız bu adım geçerli değildir.

2026.10.0'a Yükseltme — API trafik log tablosu kolonları (yalnızca SQL/JDBC connector)

Kurulumunuz API proxy trafik loglarını SQL/JDBC connector'ı üzerinden ilişkisel bir veritabanına yazıyorsa, başlangıç sürümünüzün ALTER TABLE scriptlerini (Tablo Oluşturma Komutları sayfasındaki kolon sayısı tablosuna bakın) gateway'i yükseltmeden önce çalıştırın. Hiçbir scripti iki kez çalıştırmayın:

Gateway INSERT komutu log_ApiProxyTraffic tablosunun tüm kolonlarını adıyla yazar. Bir kolon eksikse o trafik satırının INSERT işlemi başarısız olur ve kayıt kaybolur. Başlangıç sürümünüze göre hangi scriptlerin gerektiği Apinizer Logları için Tablo Oluşturma Komutları sayfasında listelenir. Trafik loglarını yalnızca Elasticsearch veya MongoDB'ye yazıyorsanız bu adım geçerli değildir.

2026.10.0'a Yükseltme — Tipli Erişim Modeli Kaldırıldı (Yükseltme Sırası)

Bu sürüm tipli erişim modelini, yani erişim yetkilerini ve API istemcisi yetkilendirme kısıtlarını kaldırır. Erişim yalnızca Erişim Kontrol Listesi'nde (ACL) tanımlanır. Kaldırılan veriler yalnızca ACL'nin bir kopyası olduğu için hiçbirinden veri taşınmaz. Başlamadan önce aşağıdaki 1. adımdaki MongoDB yedeğini alın. Bu sürümdeki ilk Manager başlatması, ilgili dispatch ve change-candidate kayıtlarını silen ve access_entitlement ile api_client_authorization_restriction koleksiyonlarını kaldıran tek seferlik bir migration çalıştırır. Anahtar ya da geri alma yolu yoktur.

Şu sırayı izleyin:

  1. Manager'ı durdurun ve yeni sürümle başlatın. Migration bu başlatmada çalışır.
  2. Tüm Worker'ları yükseltin. Yeniden başlatma bellekteki verileri boşaltır; yeni Worker'da tipli erişim kodu yoktur.
  3. ACL değişikliklerini — Erişim Kontrolü ekranında, portal aboneliği iptal ederek ya da APIops ile — yalnızca son eski Worker devreden çıktıktan sonra yapın. Eski Worker tipli yetkileri hâlâ bellekte tutar ve ACL satırını kaldırdığınız bir isteğe izin vermeyi sürdürebilir.

Bu sıra 2026.10.0'a geçiş için geçerlidir. Yukarıdaki önceki sürüm uyarıları kendi sıralarını korur. Gateway kuralı için bkz. API İstemcisinin Yetkilendirilmesi.

1) MongoDB Yedeğinin Alınması​

Güncelleme işleminden önce veri kaybını önlemek için MongoDB yedeği alınır. Bu komut MongoDB sunucusu üzerinde çalıştırılır ve tüm kurulum tipleri (Kubernetes, Docker, Sanal Sunucu) için aynı şekilde uygulanır.

sudo mongodump \
  --host <PRIMARY_MONGODB_IP_ADDRESS> \
  --port=25080 \
  --username=apinizer \
  --password=<PASSWORD> \
  --authenticationDatabase=admin \
  --gzip \
  --archive=<BACKUP_DIRECTORY>/apinizer-backup--<CURRENT_VERSION>--<BACKUP_DATE>--01.archive
--host(string)required

Primary MongoDB sunucusunun IP adresi

--port(number)
Default25080

MongoDB port numarası

--username(string)required

MongoDB kullanıcı adı

--password(string)required

MongoDB şifresi

--authenticationDatabase(string)
Defaultadmin

Kimlik doğrulama veritabanı

--gzip(boolean)

Yedek dosyasını sıkıştırır

--archive(string)required

Yedek dosyasının kaydedileceği yol ve dosya adı

not

Yedekleme ile ilgili detaylı bilgi için Yedekleme sayfasına bakabilirsiniz.

2) Apinizer Uygulamalarının Güncellenmesi​

Sistem, temel olarak apimanager (2025.11.0 ve öncesi sürümlerde manager), worker ve cache uygulamalarından oluşur. Lisans kapsamına bağlı olarak integration ve apiportal (2025.04.5 ve öncesi sürümlerde portal) uygulamaları da bulunabilir.

Güncel sürüm bilgilerine Docker Hub adresinden veya sürüm notları sayfasından erişilebilir.

Güncelleme Stratejisi ve Kesinti Riski​

Güncelleme sırasında trafik kesintisi riski; pod sayısı, güncelleme stratejisi ve sunucu kaynaklarının uygunluğu gibi faktörlere bağlı olarak değişkenlik gösterebilir. Bu değişkenlikler tüm kurulum tipleri için geçerlidir.

Replica/Pod Sayısı

Güncellenecek uygulama yalnızca 1 pod üzerinde çalışıyorsa kısa süreli kesinti yaşanabilir. Api Manager bileşeninin 1 pod ile çalışması önerilir.

Güncelleme Stratejisi

Kurulum sırasında özel bir strateji belirtilmediği sürece, güncellemeler RollingUpdate yöntemiyle ve en az bir pod aktif kalacak şekilde gerçekleştirilir. Api Manager ve Cache bileşenlerinde Recreate stratejisi de tercih edilebilir.

Sunucu Kaynakları

Kubernetes worker sunucu sayısının az olduğu ve mevcut kaynakların sınırda kullanıldığı ortamlarda, güncelleme sırasında manuel müdahale gerekebilir ve trafik akışında kesinti yaşanması muhtemeldir.

not

Aşağıdaki sekmelerden kurulum tipinize uygun olanı seçin.

2.1) Apinizer'ın Çevrimiçi Güncellenmesi​

2.1.1) Apinizer Api Manager Güncellenmesi​

uyarı

Apinizer'ın diğer bileşenlerini güncellemeden önce Apinizer Api Manager'ın güncellenmesi gerekmektedir.

Api Manager'ın veritabanına yapacağı güncellemelerden sonra diğer Apinizer uygulamalarının güncel ayarlarla veritabanından beslenmesi gerekmektedir.

Bu nedenle, Api Manager güncellendikten sonra Kubernetes üzerindeki Api Manager podlarının "ready" durumuna geldiğinden emin olunmalı ve ardından diğer bileşenler güncellenmelidir.

Bu ve sonraki adımlardaki komutlar, Kubernetes Control Plane görevine sahip sunucular üzerinde çalıştırılır.

Deployment bilgilerini kontrol edin
kubectl get deployments -Ao wide
Api Manager deployment imajını güncelleyin
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<NEW_VERSION>
Pod durumunu takip edin

Pod'un READY olması beklenir, pod durumu ve logları takip edilir:

kubectl get pods -n <MANAGER_NAMESPACE>
kubectl get logs -f -n <MANAGER_NAMESPACE> <POD_NAME>

2.1.2) Apinizer Worker ve Cache Güncellenmesi​

Apinizer Api Manager imajının güncellendiğinden emin olduktan sonra Apinizer Worker ve Cache uygulamaları güncellenir.

Worker ve Cache deployment imajlarını güncelleyin
kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=apinizercloud/worker:<NEW_VERSION>
kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=apinizercloud/cache:<NEW_VERSION>
Pod durumunu takip edin

Pod'ların READY olması beklenir, pod durumu takip edilir:

kubectl get pods -n <WORKER_CACHE_NAMESPACE>
kubectl get logs -f -n <WORKER_CACHE_NAMESPACE> <POD_NAME>

2.1.3) Apinizer Portal ve Integration Güncellenmesi​

Apinizer Portal ve Integration benzer şekilde güncellenebilir.

Portal ve Integration deployment imajlarını güncelleyin
kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=apinizercloud/apiportal:<NEW_VERSION>
kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=apinizercloud/integration:<NEW_VERSION>
Pod durumlarını takip edin

Pod'ların READY olması beklenir, pod durumları takip edilir:

kubectl get pods -n <PORTAL_NAMESPACE>
kubectl get logs -f -n <PORTAL_NAMESPACE> <POD_NAME>
kubectl get pods -n <INTEGRATION_NAMESPACE>
kubectl get logs -f -n <INTEGRATION_NAMESPACE> <POD_NAME>

2.2) Apinizer'ın Çevrimdışı Güncellenmesi​

Kubernetes ortamlarında güncelleme yapmayı gerektiren offline sistemler için iki ana yöntem kullanılabilir:

Manuel İmaj Transferi

İnterneti ve docker/containerd uygulaması olan bir sunucuya imaj dosyalarını çekmek ve bu imaj dosyalarını hedef Kubernetes cluster'ına aktarmak.

Yerel Registry Kullanımı

Kubernetes cluster'ın kullanacağı bir repository uygulaması kullanmak (Nexus, Harbor vb.).

2.2.1) Online Sunucudan İmajların Çekilmesi ve Offline Sunuculara Aktarılması​

İnternete ve offline makinelere erişimi olan bir makine varsa aşağıdaki adımlar gerçekleştirilebilir.

2.2.1.1) Docker Kullanımı​
# Online sunucudan yükseltme için gerekli olan tüm imajlar çekilir
docker pull apinizercloud/apimanager:<NEW_VERSION>
docker pull apinizercloud/worker:<NEW_VERSION>
docker pull apinizercloud/cache:<NEW_VERSION>
docker pull apinizercloud/apiportal:<NEW_VERSION>
docker pull apinizercloud/integration:<NEW_VERSION>

# İlgili imajları offline sunuculara aktarmak için, online sunucuda imajlar `.tar` formatında kaydedilir
docker save apinizercloud/apimanager:<NEW_VERSION> -o apinizercloud-apimanager.<NEW_VERSION>.tar
docker save apinizercloud/worker:<NEW_VERSION> -o apinizercloud-worker.<NEW_VERSION>.tar
docker save apinizercloud/cache:<NEW_VERSION> -o apinizercloud-cache.<NEW_VERSION>.tar
docker save apinizercloud/apiportal:<NEW_VERSION> -o apinizercloud-apiportal.<NEW_VERSION>.tar
docker save apinizercloud/integration:<NEW_VERSION> -o apinizercloud-integration.<NEW_VERSION>.tar

# İmajların her biri offline sunucuya aktarılır
scp apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Her bir offline sunucuda imajlar yüklenilir
docker load -i apinizercloud-apimanager.<NEW_VERSION>.tar
docker load -i apinizercloud-worker.<NEW_VERSION>.tar
docker load -i apinizercloud-cache.<NEW_VERSION>.tar
docker load -i apinizercloud-portal.<NEW_VERSION>.tar
docker load -i apinizercloud-integration.<NEW_VERSION>.tar
2.2.1.2) Containerd Kullanımı​
# Online sunucudan yükseltme için gerekli olan tüm imajlar çekilir
ctr image pull docker.io/apinizercloud/apimanager:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/worker:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/cache:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/apiportal:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/integration:<NEW_VERSION>

# İlgili imajları offline sunuculara aktarmak için, online sunucuda imajlar `.tar` formatında kaydedilir
ctr images export apinizercloud-apimanager.tar docker.io/apinizercloud/apimanager:<NEW_VERSION>
ctr images export apinizercloud-worker.tar docker.io/apinizercloud/worker:<NEW_VERSION>
ctr images export apinizercloud-cache.tar docker.io/apinizercloud/cache:<NEW_VERSION>
ctr images export apinizercloud-apiportal.tar docker.io/apinizercloud/apiportal:<NEW_VERSION>
ctr images export apinizercloud-integration.tar docker.io/apinizercloud/integration:<NEW_VERSION>

# İmajların her biri offline kubernetes worker sunuculara aktarılır
scp docker.io-apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Her bir offline sunucuda imajlar yüklenilir
ctr images import apinizercloud-apimanager.tar
ctr images import apinizercloud-worker.tar
ctr images import apinizercloud-cache.tar
ctr images import apinizercloud-apiportal.tar
ctr images import apinizercloud-integration.tar

2.2.2) Yerel İmaj Registry ya da Repository Kullanımı​

Farklı imaj registry ve repository'leri farklı yöntemlerle çalışsa da çoğunda çekilen imajlar tag'lenerek uygulamaya gönderilmelidir.

bilgi

Nexus veya Harbor gibi kurumsal registry'lerde node yapılandırması ve deployment imaj path güncellemesi için Container Registry bölümüne bakın. Aşağıdaki adımlar imajları registry'ye push etme senaryosu içindir.

bilgi

Eğer uygulama reverse proxy şeklinde kullanılıyorsa hub.docker.com adresindeki apinizercloud reposuna yönelik gerekli tanımın verilmesi yeterli olmaktadır.

2.2.2.1) Docker Kullanımı​
# Gerekli tüm imajlar çekilir
docker pull apinizercloud/apimanager:<NEW_VERSION>
docker pull apinizercloud/worker:<NEW_VERSION>
docker pull apinizercloud/cache:<NEW_VERSION>
docker pull apinizercloud/apiportal:<NEW_VERSION>
docker pull apinizercloud/integration:<NEW_VERSION>

# Çekilen imajlar, gerekli tag bilgileri ile yeniden etiketlenir
docker tag apinizercloud/apimanager:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
docker tag apinizercloud/worker:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
docker tag apinizercloud/cache:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
docker tag apinizercloud/apiportal:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
docker tag apinizercloud/integration:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

# Kurumun yerel imaj registry'sine imajlar aktarılır:
docker push <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
docker push <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
docker push <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
docker push <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
docker push <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
2.2.2.2) Containerd Kullanımı​
# Gerekli tüm imajlar çekilir
ctr image pull docker.io/apinizercloud/apimanager:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/worker:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/cache:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/apiportal:<NEW_VERSION>
ctr image pull docker.io/apinizercloud/integration:<NEW_VERSION>

# Çekilen imajlar, gerekli tag bilgileri ile yeniden etiketlenir
ctr image tag docker.io/apinizercloud/apimanager:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/worker:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/cache:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/apiportal:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/integration:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

# Kurumun yerel imaj registry'sine imajlar aktarılır:
ctr images push <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
ctr images push <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
ctr images push <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
ctr images push <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
ctr images push <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

2.2.3) Apinizer Api Manager Güncellenmesi​

uyarı

Apinizer'ın diğer bileşenlerini güncellemeden önce Apinizer Api Manager'ın güncellenmesi gerekmektedir.

Api Manager'ın veritabanına yapacağı güncellemelerden sonra diğer Apinizer uygulamalarının güncel ayarlarla veritabanından beslenmesi gerekmektedir.

Bu nedenle, Api Manager güncellendikten sonra Kubernetes üzerindeki Api Manager podlarının "ready" durumuna geldiğinden emin olunmalı ve ardından diğer bileşenler güncellenmelidir.

Bu ve sonraki adımlardaki komutlar, Kubernetes Control Plane görevine sahip sunucular üzerinde çalıştırılır.

Deployment bilgilerini kontrol edin
kubectl get deployments -Ao wide
Api Manager deployment imajını güncelleyin
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
Pod durumunu takip edin

Pod'un READY olması beklenir, pod durumu takip edilir:

kubectl get pods -n <MANAGER_NAMESPACE>
kubectl logs -f -n <MANAGER_NAMESPACE> <POD_NAME>

2.2.4) Apinizer Worker ve Cache Güncellenmesi​

Apinizer Api Manager imajının güncellendiğinden emin olduktan sonra Apinizer Worker ve Cache uygulamaları güncellenir.

Worker ve Cache deployment imajlarını güncelleyin
kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
Pod durumunu takip edin

Pod'ların READY olması beklenir, pod durumu takip edilir:

kubectl get pods -n <WORKER_CACHE_NAMESPACE>
kubectl logs -f -n <WORKER_CACHE_NAMESPACE> <POD_NAME>

2.2.5) Apinizer Portal ve Integration Güncellenmesi​

Apinizer Portal ve Integration benzer şekilde güncellenebilir.

Portal ve Integration deployment imajlarını güncelleyin
kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
Pod durumlarını takip edin

Pod'ların READY olması beklenir, pod durumları takip edilir:

kubectl get pods -n <PORTAL_NAMESPACE>
kubectl get logs -f -n <PORTAL_NAMESPACE> <POD_NAME>
kubectl get pods -n <INTEGRATION_NAMESPACE>
kubectl get logs -f -n <INTEGRATION_NAMESPACE> <POD_NAME>

3) Apinizer Uygulama Güncellemelerinin Geri Alınması​

2026.09.2'den Geri Dönüş

2026.09.2'de açılışta çalışan kimlik ve limit taşıması uygulama sürümü düşürülerek geri alınamaz. Bu sürümden geri dönmeniz gerekirse tek yol, aşağıdaki §1'de anlatıldığı gibi yükseltmeden önce alınmış MongoDB yedeğinin geri yüklenmesidir.

Apinizer uygulamalarında sürüm düşürülmesi desteklenmemektedir. Ancak güncellenen bir sürüm veritabanı yedekleri varsa geri alınabilir.

uyarı

Herhangi bir sebep ile güncellemelerin geri alınması gerektiğinde yapılması gereken ilk iş güncelleme öncesi MongoDB yedeğinin alınmış olduğunu kontrol etmektir. Güncelleme öncesi alınmış bir veritabanı yedeği yoksa Api Manager uygulamasının veritabanında yapacağı değişiklikleri geri almanın bir yolu olmadığı için veritabanı sunucularının sistemsel bir yedeği varsa mevcut son yedeğe dönülerek o tarihteki sürüme geri dönülebilir.

Bu işlem o tarihten itibaren yapılan değişikliklerin kaybına yol açacağı için dikkatle yapılmalıdır. Güncelleme ile yapısal farklılıklar oluşabileceğinden bu işlem sadece referans olarak kullanılmak için düşünülebilir.

3.1) MongoDB Veritabanı Geri Yükleme​

Bu işlemin öncesinde Api Manager uygulamasının kubernetes üzerinde CrashLoopBackOff hatası ile yeniden başlatılma döngüsünde olmadığı teyit edilmelidir. En güvenli yöntem için Api Manager uygulaması replica sayısı 0'a indirilerek durdurulmalıdır.

Api Manager'ı durdurun

Api Manager replica sayısı 0'a çekilir ve tüm pod'lar kapatılır (Kubernetes ortamlarında):

kubectl scale deploy <MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> --replicas=0

Docker ortamlarında: docker compose stop apimanager veya docker stop apinizer-apimanager

Sanal Sunucu ortamlarında: sudo systemctl stop apinizer-apimanager

MongoDB yedeğini geri yükleyin

MongoDB mevcut son yedeğe dönülmelidir. Dönüş sırasında olası çakışmaları engellemek için --drop parametresi kullanılabilir. Bu sadece yedek dosyasında karşılığı olan koleksiyonları drop edecek ve yüklemeyi sonrasında gerçekleştirmeyi sağlayacaktır.

not

Detaylı bilgi için MongoDB Veritabanı Yedekleme ve Geri Yükleme sayfası incelenebilir.

3.2) Manager Sürümünün Geri Alınması​

not

Dönüş sırasında eğer yerel kayıt defteri kullanılacaksa komutlar buna göre güncellenmelidir.

Api Manager deployment imajını eski sürüme döndürün
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<OLD_VERSION>
Replica sayısını 1'e çekin
kubectl scale deploy <MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> --replicas=1
Pod durumunu takip edin

Pod'un READY olması beklenir, pod durumu ve logları takip edilir:

kubectl get pods -n <MANAGER_NAMESPACE>
kubectl logs -f -n <MANAGER_NAMESPACE> <POD_NAME>

3.3) Diğer Uygulamaların Sürümünün Geri Alınması​

Api Manager uygulaması çalışır hale geldiğinde diğer uygulamalar birlikte eski sürüme döndürülebilir.

not

Dönüş sırasında eğer yerel kayıt defteri kullanılacaksa komutlar buna göre güncellenmelidir.

Deployment imajlarını eski sürüme döndürün
kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=apinizercloud/worker:<OLD_VERSION>
kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=apinizercloud/cache:<OLD_VERSION>
kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=apinizercloud/apiportal:<OLD_VERSION>
kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=apinizercloud/integration:<OLD_VERSION>
Pod durumlarını kontrol edin

Pod'ların READY olması beklenir, pod durumları ve gerekirse logları takip edilir:

kubectl get pods -A
En son tarihinde güncellendi