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.

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.

Kubernetes
Helm
Docker
Sanal Sunucu

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

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>

Helm ile kurulan Apinizer modülleri helm upgrade ile yükseltilir. Bu akışta yalnızca imaj sürümü (image.tag) değişir; diğer tüm değerler --reuse-values ile mevcut release'ten korunur.

uyarı

Diğer bileşenlerden önce API Manager yükseltilmelidir. API Manager, veritabanı (Mongock) migration'larını çalıştırır; pod'ları Ready olduktan sonra diğer modüller yükseltilmelidir.

2.1) Çevrimiçi Güncelleme (Helm)

Her modülde chart ve sürüm (--version 1.0.0) aynı kalır, yalnızca yeni imaj tag'i verilir:

1.0.0 öncesinden yükseltiyorsanız — Secret silinmesin

1.0.0 öncesi chart'lar Secret'ı kendileri oluştururdu; 1.0.0 chart'ında Secret yoktur. Doğrudan helm upgrade yaparsanız Helm, kendi oluşturduğu Secret'ı release'ten silebilir ve pod'lar MongoDB bağlantısını kaybeder. Upgrade'den önce Secret'a "silme" politikası uygulayın:

kubectl -n <API-Manager-Namespace> annotate secret mongo-db-credentials \
  helm.sh/resource-policy=keep --overwrite

Aynı işlemi Secret'ı paylaşan diğer namespace'ler ve Portal Secret'ı (apinizer-portal) için de tekrarlayın.

API Manager'ı yükseltin

helm upgrade apimanager oci://registry-1.docker.io/apinizercloud/apinizer-apimanager \
  --version 1.0.0 --reuse-values \
  -n <API-Manager-Namespace> \
  --set image.tag="<NEW_VERSION>"

Pod'lar Ready olana kadar bekleyin:

kubectl -n <API-Manager-Namespace> rollout status deploy/apimanager

Worker ve Cache'i yükseltin

helm upgrade worker oci://registry-1.docker.io/apinizercloud/apinizer-worker \
  --version 1.0.0 --reuse-values -n <Worker-Namespace> --set image.tag="<NEW_VERSION>"

helm upgrade cache oci://registry-1.docker.io/apinizercloud/apinizer-cache \
  --version 1.0.0 --reuse-values -n <Cache-Namespace> --set image.tag="<NEW_VERSION>"

Integration ve API Portal'ı yükseltin

helm upgrade integration oci://registry-1.docker.io/apinizercloud/apinizer-integration \
  --version 1.0.0 --reuse-values -n <Integration-Namespace> --set image.tag="<NEW_VERSION>"

helm upgrade portal oci://registry-1.docker.io/apinizercloud/apinizer-apiportal \
  --version 1.0.0 --reuse-values -n <API-Portal-Namespace> --set image.tag="<NEW_VERSION>"

not

--reuse-values mevcut release'in tüm değerlerini korur; --set image.tag yalnızca imaj sürümünü değiştirir. Release adları ve namespace'ler kurulumdakiyle aynı olmalıdır (her modül kurulumda kullandığınız namespace'te).

2.1.1) values.yaml ile Güncelleme (GitOps)

values.yaml dosyasını sürüm kontrolünde (örn. GitLab) tutuyorsanız güncellemeyi --set yerine dosya üzerinden yapabilirsiniz: yeni imaj sürümünü values.yaml içindeki image.tag alanına yazıp commit'leyin, ardından aynı dosyayla helm upgrade -f çalıştırın.

helm upgrade apimanager oci://registry-1.docker.io/apinizercloud/apinizer-apimanager \
  --version 1.0.0 \
  -n <API-Manager-Namespace> \
  -f apinizer-apimanager/values.yaml

Diğer modüller için aynı şekilde ilgili chart ve values.yaml yolunu kullanın (apinizer-worker, apinizer-cache, apinizer-integration, apinizer-apiportal).

not

-f values.yaml ile güncellemede --reuse-values kullanmayın; değerlerin tek kaynağı values.yaml dosyasıdır. Secret yine bu kapsamda değildir; values.yaml'a kimlik bilgisi koymayın.

2.2) Doğrulama

helm list -n <NAMESPACE>     # her modülün kurulu olduğu namespace için tekrarlayın
kubectl -n <NAMESPACE>  get pods

2.3) Çevrimdışı / Yerel Registry

Cluster internete erişemiyorsa imajlar bir yerel registry'ye taşınır (imaj transferi için yukarıdaki Kubernetes sekmesindeki çevrimdışı adımlara bakın). Yerel registry kullanılıyorsa imaj tag'i ile birlikte repository de verilir:

helm upgrade apimanager oci://registry-1.docker.io/apinizercloud/apinizer-apimanager \
  --version 1.0.0 --reuse-values -n <API-Manager-Namespace> \
  --set image.repository=<YEREL_REGISTRY>/apinizercloud/apimanager \
  --set image.tag="<NEW_VERSION>"

2.4) Geri Alma (Helm Rollback)

Helm her upgrade'i bir revision olarak saklar; sorun durumunda önceki revision'a dönülebilir:

helm history apimanager -n <API-Manager-Namespace>
helm rollback apimanager <REVISION> -n <API-Manager-Namespace>
kubectl -n <API-Manager-Namespace> rollout status deploy/apimanager

uyarı

Mongock migration'ları forward-only'dir. Yeni sürüm veritabanı şemasını değiştirdiyse rollback eski Manager'ın açılmasını engelleyebilir; major sürüm yükseltmelerinden önce mutlaka MongoDB yedeği alın (bkz. bölüm 1) ve gerekirse bölüm 3'teki geri yükleme adımlarını uygulayın.

Hızlı Başvuru

NEW=2026.04.6
docker pull apinizercloud/<modul>:${NEW}

# docker-compose:
# 1) compose.yml içinde image tag'ini güncelle
# 2) docker compose up -d <service>

# vanilla docker:
docker stop <konteyner-adi> && docker rm <konteyner-adi>
docker run -d --name <konteyner-adi> ... apinizercloud/<modul>:${NEW}

Önerilen Yükseltme Sırası

MongoDB (gerekiyorsa — bkz. MongoDB Yükseltme)
API Manager — Mongock migration'ları çalışır, schema güncellenir
Cache (rolling — bir node bir node)
Worker (rolling — bir replika bir replika; LB arkasında)
Integration (rolling — Quartz cluster check-in cycle bekleyin)
API Portal — stateless, basit replace

Modül Bazlı Detaylar

API Manager

Manager Mongock migration'ları üretebileceği için tek instance'a indirgemek gerekmez — yeni Manager başlarken eski Manager hâlâ ayakta olabilir. Migration'lar idempotent.

docker pull apinizercloud/apimanager:${NEW}
docker compose up -d apimanager      # tag compose.yml'de değişti
docker compose logs -f apimanager    # "Mongock finished" ve "Started ApinizerManagerApp"

İlk başlatma 30–90 saniye sürebilir (Mongock migration'lar).

uyarı

Üretimde major version atlamadan önce MongoDB yedek alın. Major versiyon zinciri (örn. 2026.04.x → 2026.05.x → 2026.06.x) tek seferde değil, sırayla atlanmalı; her aşamada Mongock log'larını izleyin.

Cache (rolling upgrade)

Cache node'ları Hazelcast cluster'ı oluşturduğu için bir node bir node yükseltin:

docker pull apinizercloud/cache:${NEW}

# Node 1
docker stop -t 30 apinizer-cache-1 && docker rm apinizer-cache-1
docker run -d --name apinizer-cache-1 ... apinizercloud/cache:${NEW}

# 'Members {size:3, ver:N}' log'u tekrar görünene kadar bekle
docker logs apinizer-cache-1 | grep -E 'Members \{'

# Sonra node 2, node 3...

Cluster bir node eksikken çalışmaya devam eder (replication factor ≥ 1).

Worker

LB arkasında çalışan Worker'lar için canary / blue-green:

docker pull apinizercloud/worker:${NEW}

# LB'den bir replikayı çek
# Konteyneri replace et
docker stop -t 60 apinizer-worker-1 && docker rm apinizer-worker-1
docker run -d --name apinizer-worker-1 ... apinizercloud/worker:${NEW}

# Sağlık doğrulanınca LB'ye geri ekle
# Diğer replikaları sırayla yükselt

uyarı

docker stop -t 60 zorunlu — in-flight HTTP / gRPC / WebSocket istekleri 60 saniyeye kadar drain olur.

Integration (clustered Quartz)

Integration node'ları MongoDB üzerinden cluster oluşturduğu için bir node restart sırasında diğer node trigger'ları üstlenir:

docker pull apinizercloud/integration:${NEW}

# Node 1
docker stop -t 120 apinizer-integration-1 && docker rm apinizer-integration-1
docker run -d --name apinizer-integration-1 ... apinizercloud/integration:${NEW}

# 'Quartz Scheduler Prod Environment Setup started' log'unu bekle
# Sonra node 2, node 3...

stop -t 120 zorunlu — waitForJobsToCompleteOnShutdown=true ile mevcut job'lar drain olabilsin.

API Portal

Stateless — basit recreate yeterli:

docker pull apinizercloud/apiportal:${NEW}
docker compose up -d apiportal       # tag değişti

Multiple replica varsa LB önünde her replikayı sırayla replace edin.

Geri Alma (Rollback)

Önceki versiyona dönmek için aynı pattern, eski tag ile:

OLD=2026.04.5
docker compose down                              # veya: docker stop ... && docker rm ...
# compose.yml'i eski tag'e geri al, sonra:
docker compose up -d

uyarı

Mongock migration'ları forward-only. Yeni versiyon DB schema'sını değiştirmişse rollback eski Manager'ın boot etmemesine yol açabilir. Major upgrade'lerden önce MongoDB yedek alın.

Sorun Giderme

Yeni Manager boot edemiyor: `Mongock lock acquired by another instance`

Eski Manager Mongock lock'ı bırakmadan SIGKILL aldı. Manager DB'sinde:

use apinizer
db.mongockLock.deleteMany({})

Lock cleanup'tan sonra Manager yeniden başlatın.

Worker yeni versiyonda Environment'a bağlanamıyor

Major versiyon değişikliğinde Environment schema değişmiş olabilir. Manager log'larını kontrol edip Environment'ın doğru schema'da olduğunu doğrulayın.

Compose'da `image is being used by container` hatası

docker compose up -d tag değişmedikçe konteyneri recreate etmez. Manuel:

docker compose up -d --force-recreate <service>

Hızlı Başvuru

NEW=2026.04.6
sudo systemctl stop apinizer-<modul>
sudo tar -xzf apinizer-<modul>-${NEW}-linux-x64.tar.gz -C /opt
sudo cp /opt/apinizer-<modul>/conf/application.env /opt/apinizer-<modul>-${NEW}/conf/
sudo cp /opt/apinizer-<modul>/conf/master.key      /opt/apinizer-<modul>-${NEW}/conf/
sudo chown -R apinizer:apinizer /opt/apinizer-<modul>-${NEW}/conf
sudo chmod 600 /opt/apinizer-<modul>-${NEW}/conf/application.env
sudo chmod 400 /opt/apinizer-<modul>-${NEW}/conf/master.key
sudo mv /opt/apinizer-<modul> /opt/apinizer-<modul>.bak
sudo mv /opt/apinizer-<modul>-${NEW} /opt/apinizer-<modul>
sudo /opt/apinizer-<modul>/bin/<modul>-install.sh    # systemd unit'i yeniden register
sudo systemctl start apinizer-<modul>
sudo systemctl status apinizer-<modul>
# Healthy doğrulandıktan sonra:
sudo rm -rf /opt/apinizer-<modul>.bak

Önerilen Yükseltme Sırası

MongoDB (gerekiyorsa)
API Manager — Mongock migration'ları
Cache — rolling, bir node bir node
Worker — LB arkasında rolling
Integration — clustered Quartz, rolling
API Portal — stateless

Modül Bazlı

API Manager

NEW=2026.04.6
sudo systemctl stop apinizer-apimanager

# Yedek al
sudo cp /opt/apinizer-manager/conf/application.env ~/manager-env-pre-${NEW}.bak
sudo cp /opt/apinizer-manager/conf/master.key      ~/manager-key-pre-${NEW}.bak

# Yeni paketi aç
curl -fSLO "https://packages.apinizer.com/apinizer-packages/apimanager/${NEW}/apinizer-apimanager-${NEW}-linux-x64.tar.gz"
sudo tar -xzf apinizer-apimanager-${NEW}-linux-x64.tar.gz -C /opt

# Config taşı
sudo cp /opt/apinizer-manager/conf/application.env /opt/apinizer-apimanager-${NEW}/conf/
sudo cp /opt/apinizer-manager/conf/master.key      /opt/apinizer-apimanager-${NEW}/conf/
sudo chown -R apinizer:apinizer /opt/apinizer-apimanager-${NEW}/conf
sudo chmod 600 /opt/apinizer-apimanager-${NEW}/conf/application.env
sudo chmod 400 /opt/apinizer-apimanager-${NEW}/conf/master.key

# Swap + reinstall
sudo mv /opt/apinizer-manager /opt/apinizer-manager.bak
sudo mv /opt/apinizer-apimanager-${NEW} /opt/apinizer-manager
sudo /opt/apinizer-manager/bin/apimanager-install.sh
sudo systemctl start apinizer-apimanager
sudo journalctl -u apinizer-apimanager -f          # Mongock log'unu izle

İlk başlangıçta Mongock 30–90 saniye sürebilir. Started ApinizerManagerApp log'undan sonra:

curl -fsS http://127.0.0.1:8080/management/health
# Healthy ise:
sudo rm -rf /opt/apinizer-manager.bak

Cache (rolling upgrade)

Cache node'ları stateful Hazelcast member — bir node bir node yükseltin:

# Node 1'de:
sudo systemctl stop apinizer-apicache
# (yukarıdaki Manager akışıyla aynı: tarball aç, conf taşı, install, start)
# Sonra node 2'ye geç — log'da 'Members {size:3, ver:N}' görmek kritik

Cluster bir node eksikken çalışmaya devam eder.

Worker

LB arkasında her replikayı sırayla:

# LB'den replika 1'i çıkar
sudo systemctl stop apinizer-apiworker     # SIGTERM + 60 sn drain
# (tarball swap akışı)
sudo systemctl start apinizer-apiworker
curl -fsS http://127.0.0.1:8091/server-status
# Healthy → LB'ye geri al, replika 2'ye geç

Integration

Quartz cluster check-in 7.5 sn — bir node restart ederken diğer node trigger'ları üstlenir:

sudo systemctl stop apinizer-apiintegration    # SIGTERM + waitForJobsToCompleteOnShutdown drain
# (tarball swap akışı)
sudo systemctl start apinizer-apiintegration
sudo journalctl -u apinizer-apiintegration -f  # 'Quartz Scheduler Prod Environment Setup started'

API Portal

Stateless — basit swap:

sudo systemctl stop apinizer-apiportal
# tarball swap
sudo systemctl start apinizer-apiportal

Geri Alma (Rollback)

.bak dizinini henüz silmediyseniz hızlı:

sudo systemctl stop apinizer-<modul>
sudo mv /opt/apinizer-<modul> /opt/apinizer-<modul>.failed
sudo mv /opt/apinizer-<modul>.bak /opt/apinizer-<modul>
sudo /opt/apinizer-<modul>/bin/<modul>-install.sh
sudo systemctl start apinizer-<modul>

uyarı

Mongock migration'ları forward-only. Yeni Manager DB schema'sını değiştirdiyse rollback eski Manager'ın boot etmesini engelleyebilir. Major upgrade öncesi MongoDB yedek alın.

Sorun Giderme

Yeni paketten servis "is not set" ile çıkıyor

conf/application.env taşıma adımında atlandı veya izinler bozuk. Manuel kontrol:

ls -la /opt/apinizer-<modul>/conf/
# application.env mod 600, apinizer:apinizer sahipli olmalı
# master.key mod 400, apinizer:apinizer sahipli olmalı

"Master key file not found" + boot crash

master.key taşınmadı. Backup'tan geri yükle:

sudo cp ~/manager-key-pre-${NEW}.bak /opt/apinizer-manager/conf/master.key
sudo chown apinizer:apinizer /opt/apinizer-manager/conf/master.key
sudo chmod 400 /opt/apinizer-manager/conf/master.key
sudo systemctl restart apinizer-apimanager

`Mongock lock acquired by another instance`

Önceki Manager temizlik yapamadan kapandı. MongoDB'de:

use apinizer
db.mongockLock.deleteMany({})

Sonra Manager'ı yeniden başlat.

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

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.

Kubernetes
Helm
Docker
Sanal Sunucu

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>

Önceki revision'a dönün

Helm her upgrade'i bir revision olarak saklar; helm history ile hedef revision belirlenir ve o revision'a dönülür:

helm history apimanager -n <API-Manager-Namespace>
helm rollback apimanager <REVISION> -n <API-Manager-Namespace>

Pod durumunu takip edin

Pod'un Ready olması beklenir:

kubectl -n <API-Manager-Namespace> rollout status deploy/apimanager
kubectl -n <API-Manager-Namespace> get pods

Api Manager imajını eski sürüme döndürün

docker compose down                              # veya: docker stop apinizer-apimanager && docker rm apinizer-apimanager
# compose.yml'i eski tag'e geri al, sonra:
docker compose up -d apimanager
docker compose logs -f apimanager                # Mongock + boot log'unu izle

Api Manager sürümünü geri alın

sudo systemctl stop apinizer-apimanager
sudo mv /opt/apinizer-manager /opt/apinizer-manager.failed
sudo mv /opt/apinizer-manager.bak /opt/apinizer-manager
sudo /opt/apinizer-manager/bin/apimanager-install.sh
sudo systemctl start apinizer-apimanager
sudo journalctl -u apinizer-apimanager -f        # Mongock log'unu izle

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.

Kubernetes
Helm
Docker
Sanal Sunucu

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

Diğer modülleri önceki revision'a döndürün

Her modül için helm history <release> -n <namespace> ile hedef revision'ı belirleyip geri dönün:

helm rollback worker      <REVISION> -n <Worker-Namespace>
helm rollback cache       <REVISION> -n <Cache-Namespace>
helm rollback integration <REVISION> -n <Integration-Namespace>
helm rollback portal      <REVISION> -n <API-Portal-Namespace>

Pod durumlarını kontrol edin

kubectl get pods -A

Diğer modüllerin imajlarını eski sürüme döndürün

# compose.yml'i eski tag'lere geri al, sonra:
docker compose down
docker compose up -d

# veya vanilla docker ile modül başına:
OLD=2026.04.5
docker stop apinizer-worker && docker rm apinizer-worker
docker run -d --name apinizer-worker ... apinizercloud/worker:${OLD}
# Diğer modüller (cache, integration, portal) için de aynı pattern

Diğer modüllerin sürümlerini geri alın

# Worker
sudo systemctl stop apinizer-apiworker
sudo mv /opt/apinizer-worker /opt/apinizer-worker.failed
sudo mv /opt/apinizer-worker.bak /opt/apinizer-worker
sudo /opt/apinizer-worker/bin/apiworker-install.sh
sudo systemctl start apinizer-apiworker

# Cache, Integration, Portal için de benzer pattern kullan

Güncelleme Yöntemleri​

1) MongoDB Yedeğinin Alınması​

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

Güncelleme Stratejisi ve Kesinti Riski​

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

2.1.1) Apinizer Api Manager Güncellenmesi​

2.1.2) Apinizer Worker ve Cache Güncellenmesi​

2.1.3) Apinizer Portal ve Integration Güncellenmesi​

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

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

2.2.1.1) Docker Kullanımı​

2.2.1.2) Containerd Kullanımı​

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

2.2.2.1) Docker Kullanımı​

2.2.2.2) Containerd Kullanımı​

2.2.3) Apinizer Api Manager Güncellenmesi​

2.2.4) Apinizer Worker ve Cache Güncellenmesi​

2.2.5) Apinizer Portal ve Integration Güncellenmesi​

2.1) Çevrimiçi Güncelleme (Helm)​

2.1.1) values.yaml ile Güncelleme (GitOps)​

2.2) Doğrulama​

2.3) Çevrimdışı / Yerel Registry​

2.4) Geri Alma (Helm Rollback)​

Hızlı Başvuru​

Önerilen Yükseltme Sırası​

Modül Bazlı Detaylar​

API Manager​

Cache (rolling upgrade)​

Worker​

Integration (clustered Quartz)​

API Portal​

Geri Alma (Rollback)​

Sorun Giderme​

Yeni Manager boot edemiyor: Mongock lock acquired by another instance​

Worker yeni versiyonda Environment'a bağlanamıyor​

Compose'da image is being used by container hatası​

Hızlı Başvuru​

Önerilen Yükseltme Sırası​

Modül Bazlı​

API Manager​

Cache (rolling upgrade)​

Worker​

Integration​

API Portal​

Geri Alma (Rollback)​

Sorun Giderme​

Yeni paketten servis "is not set" ile çıkıyor​

"Master key file not found" + boot crash​

Mongock lock acquired by another instance​

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

3.1) MongoDB Veritabanı Geri Yükleme​

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

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

Güncelleme Yöntemleri

1) MongoDB Yedeğinin Alınması

2) Apinizer Uygulamalarının Güncellenmesi

Güncelleme Stratejisi ve Kesinti Riski

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

2.1.1) Apinizer Api Manager Güncellenmesi

2.1.2) Apinizer Worker ve Cache Güncellenmesi

2.1.3) Apinizer Portal ve Integration Güncellenmesi

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

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

2.2.1.1) Docker Kullanımı

2.2.1.2) Containerd Kullanımı

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

2.2.2.1) Docker Kullanımı

2.2.2.2) Containerd Kullanımı

2.2.3) Apinizer Api Manager Güncellenmesi

2.2.4) Apinizer Worker ve Cache Güncellenmesi

2.2.5) Apinizer Portal ve Integration Güncellenmesi

2.1) Çevrimiçi Güncelleme (Helm)

2.1.1) values.yaml ile Güncelleme (GitOps)

2.2) Doğrulama

2.3) Çevrimdışı / Yerel Registry

2.4) Geri Alma (Helm Rollback)

Hızlı Başvuru

Önerilen Yükseltme Sırası

Modül Bazlı Detaylar

API Manager

Cache (rolling upgrade)

Worker

Integration (clustered Quartz)

API Portal

Geri Alma (Rollback)

Sorun Giderme

Yeni Manager boot edemiyor: `Mongock lock acquired by another instance`

Worker yeni versiyonda Environment'a bağlanamıyor

Compose'da `image is being used by container` hatası

Hızlı Başvuru

Önerilen Yükseltme Sırası

Modül Bazlı

API Manager

Cache (rolling upgrade)

Worker

Integration

API Portal

Geri Alma (Rollback)

Sorun Giderme

Yeni paketten servis "is not set" ile çıkıyor

"Master key file not found" + boot crash

`Mongock lock acquired by another instance`

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

3.1) MongoDB Veritabanı Geri Yükleme

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

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