Ana içeriğe geç

Apinizer Version Upgrade

Update Methods​

Apinizer version upgrade operations can be performed using two different methods depending on whether your deployment has internet access:

Online Update

Used when your infrastructure has internet access. Docker images are pulled directly from Docker Hub and automatically updated. Provides a faster and easier update process.

When to Use:

  • If Kubernetes worker servers can access the internet
  • If Docker / Virtual Server hosts have outbound internet access
  • If you want to perform a quick and easy update
  • If you don't want to take extra steps for image transfer
Offline Update

Used when your infrastructure cannot access the internet or direct access is restricted due to security policies. Images are first pulled on a server with internet access, saved as .tar files, or uploaded to a local registry.

When to Use:

  • If Kubernetes worker servers cannot access the internet
  • If direct internet access is restricted due to security policies
  • If a local Docker registry (Nexus, Harbor, etc.) is used

Methods:

  • Manual Image Transfer (Docker/Containerd)
  • Local Registry Usage
Warning

Reviewing release notes is recommended before upgrading.

Upgrading to 2026.09.2 — identity and limit migration

Take the MongoDB backup in step 1 before you start. The first Manager start on this version runs an automatic identity and limit migration before it accepts any requests — installation-wide, no operator action needed. A few thousand records typically take minutes, so the first boot after this upgrade can run longer than the usual 30–90 seconds; watch the Manager (Mongock migration) log rather than assuming it has hung. On an installation with a large apinizer_token collection, the same boot also backfills a digest for every stored token and builds the indexes that speed up future reads (see Token Service) — first boot can take noticeably longer still on a token history in the millions.

The migration writes two ledger collections, api_client_migration_run and api_client_migration_row, and installs a daily reconcile job (03:45) that keeps retrying any record that did not converge on the first pass. Every Request Rate counter it creates — quota and throttling — starts at zero; a migrated AI Token Limit assignment is the one exception, since it is counted under the same counter its legacy budget already used, so in-window AI consumption carries over rather than resetting. This migration cannot be rolled back: the MongoDB backup in step 1 below is your only way back if something looks wrong afterward.

The same upgrade moves every enabled AI token budget on an API Proxy ACL/API Proxy Group ACL row into a typed AI Token Limit assignment — see AI Budgets — and, together with this, typed AI Token Limit assignments at every subject level start enforcing for real: the shadow-comparison mechanism (apinizer.limit.shadow.enabled and its comparison metric) is removed entirely, not only turned off. Review your existing typed AI Token Limit assignments beforehand if you are not ready for them to start blocking traffic. Version 2026.10.0 later removed the Token Quotas screen and the remaining entity budgets without converting them; see Removed AI Budgets.

Upgrade every gateway to this version within 7 days of this migration. Legacy password copies are removed only after that window (the daily reconcile job does it, not the boot-time migration itself; configurable with -Dapinizer.migration.legacyPasswordUnsetGraceDays=N) — an older-version gateway pod restarting after its window has elapsed can no longer find the password it needs to verify a migrated Consumer. See Automatic Migration at Upgrade → Legacy password cleanup for detail.

The same upgrade also retires the Rate Limit Control List and the API Proxy ACL/API Proxy Group ACL throttling/quota fields — see Legacy Limits Migrated at Upgrade for what happens to them, and Automatic Migration at Upgrade for the full step-by-step.

This version also moves OAuth2 access and refresh tokens to digest-only storage — see Token Service for what changes. The same boot-time step above backfills any missing digest and then removes the old plain-text columns; no separate action is needed. For this specific change, upgrade Gateway (Worker) nodes before the Manager: if an older Worker is still writing the old plain-text columns against an already-upgraded Manager, those columns are simply unused until the next cleanup pass — not a security exposure, just temporary extra storage.

This version also introduces Legal Holds and Data Lifecycle Purge. The upgrade adds the new Data Lifecycle permission category and its three new collections (legal holds, purge runs, purge run issues); your existing data is otherwise untouched. The new permission is granted automatically only to the Project Owner role — no other predefined role gains the ability to place a legal hold or run a purge, so no existing user unexpectedly gains the ability to permanently erase data. A dedicated Lifecycle Purge Run History retention setting is added alongside the other Log Retention entries, disabled by default. Elasticsearch API traffic logs are not rewritten by this feature in either direction — see Legal Holds and Data Lifecycle Purge → Data Subject Erasure for how they age out instead.

A defect in how a Consumer's deployed IP restriction list was assembled from its global and environment-level entries meant the list a worker actually enforced could only ever grow, never shrink, across redeploys — this is fixed in this version, and the merged list is now recomputed fresh on every deploy. If any of your consumers use IP-based access restriction, review their configured IP lists after upgrading: an address no longer present in your configuration but still being accepted before this fix stops being accepted once the fix takes effect.

An LDAP account that does not yet record which directory it came from is no longer signed in while any configured LDAP connection is disabled. Before this version such an account was resolved against the enabled connections only, which could bind it permanently to the wrong directory and let a directory you had deliberately disabled keep signing its users in. If your configuration still holds a disabled LDAP connection, enable it or delete it — one action for the whole installation — or open and save each affected user once so the account records its own connection. Accounts that already record their LDAP connection are unaffected, and a refused sign-in is written to Login Records with its reason.

Upgrading to 2026.09.2 — case-insensitive duplicate usernames

This version installs an index that makes usernames (login) unique regardless of letter case. Before you upgrade, after taking the MongoDB backup from step 1 below, run this query on the MongoDB server to check your existing users for a pair that differs only by letter case:

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 } }
)

If it returns nothing, no action is needed. If it returns one or more groups, rename the accounts from the Users screen, or delete the redundant one, before you upgrade, so only one username remains per group.

If this step is skipped: the Manager still starts, and your existing users keep signing in normally — only the index is not installed, and a warning is written to the log. But until the index is installed, a new LDAP user is refused first-time automatic account creation (LDAP users whose account already exists are unaffected). So the Manager starting cleanly is not proof the index is installed: after upgrading, search the Manager log for the line tagged 202609-006722 — it ends with "installed/verified" if the index is in place, or "NOT installed" if it is not; in the latter case, remove the duplicates with the query above and restart the Manager, which retries this step automatically on every boot.

Upgrading to 2026.09.2 — Audit Event / Login Log table columns (SQL/JDBC connector only)

If your installation sends Audit Records or Login Records to a relational database via the SQL/JDBC connector, run the Audit and Login Table ALTER Scripts against that database before you upgrade — not "before or during", because the insert this version issues against those two tables is unconditional. Until the script runs, every Audit Event row fails to write (though it still reaches your configured failover connector), and every Login Log row fails to write with no failover — it is dropped. This step does not apply if you use the Elasticsearch or MongoDB connector for these two log types.

Upgrading to 2026.10.0 — API traffic log table columns (SQL/JDBC connector only)

If your installation writes API proxy traffic logs to a relational database via the SQL/JDBC connector, run the ALTER TABLE scripts for your starting version (see the column-count table on Table Creation Commands), before you upgrade the gateway. Do not run a script twice:

The gateway INSERT names every column of log_ApiProxyTraffic. If a column is missing, the insert of that traffic row fails and the record is lost. Which scripts apply to your starting version is listed on Table Creation Commands for Apinizer Logs. This step does not apply if you write traffic logs only to Elasticsearch or MongoDB.

Upgrading to 2026.10.0 — typed access model removed (upgrade order)

This version removes the typed access model: the access entitlements and the API client authorization restrictions. Access is defined only on the Access Control List (ACL). Nothing is carried over from the removed data, because it only mirrored the ACL. Take the MongoDB backup in step 1 before you start. The first Manager start on this version runs a one-time migration that deletes the related dispatch and change-candidate records and drops the access_entitlement and api_client_authorization_restriction collections. There is no switch and no rollback path.

Follow this order:

  1. Stop the Manager and start it on the new version. The migration runs at this start.
  2. Upgrade all Workers. A restart empties their memory, and the new Worker has no typed access code.
  3. Make ACL changes — on the Access Control screen, by cancelling a portal subscription, or through APIops — only after the last old Worker is gone. An old Worker still holds the typed grants in memory and could keep allowing a request whose ACL row you removed.

This order applies to the move onto 2026.10.0. Notices for earlier versions above keep their own order. See Authorization of an API Client for the gateway rule.

1) Take a MongoDB Backup​

MongoDB backup is taken before the update operation to prevent data loss. This command is run on the MongoDB server.

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 server IP address

--port(number)
Default25080

MongoDB port number

--username(string)required

MongoDB username

--password(string)required

MongoDB password

--authenticationDatabase(string)
Defaultadmin

Authentication database

--gzip(boolean)

Compresses the backup file

--archive(string)required

Path and filename where the backup file will be saved

Note

For detailed information about backup, you can check the Backup page.

2) Updating Apinizer Applications​

The system basically consists of apimanager (manager in versions 2025.11.0 and earlier), worker, and cache applications. Depending on the license scope, integration and apiportal (portal in versions 2025.04.5 and earlier) applications may also be present.

Current version information can be accessed from Docker Hub or from the release notes page.

Update Strategy and Downtime Risk​

The risk of traffic interruption during update may vary depending on factors such as pod count, update strategy, and adequacy of server resources.

Replica/Pod Count

If the application to be updated is running on only 1 pod, a short interruption may occur. It is recommended that the Api Manager component runs with 1 pod.

Update Strategy

Unless a special strategy is specified during installation, updates are performed using the RollingUpdate method with at least one pod remaining active. Recreate strategy can also be preferred for Api Manager and Cache components.

Server Resources

In environments where the number of Kubernetes worker servers is low and existing resources are used at the limit, manual intervention may be required during update and traffic flow interruption is likely.

Note

Pick the tab matching your installation type.

2.1) Online Update​

2.1.1) Apinizer Api Manager Update​

Warning

Apinizer Api Manager must be updated before updating other Apinizer components.

After Api Manager makes updates to the database, other Apinizer applications need to be fed from the database with current settings.

Therefore, after Api Manager is updated, make sure that Api Manager pods on Kubernetes are in "ready" status and then update other components.

Commands in this and subsequent steps are run on servers with Kubernetes Control Plane task.

Check deployment information
kubectl get deployments -Ao wide
Update Api Manager deployment image
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<NEW_VERSION>
Monitor pod status

Wait for the pod to be READY, monitor pod status and logs:

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

2.1.2) Apinizer Worker and Cache Update​

After ensuring that the Apinizer Api Manager image is updated, Apinizer Worker and Cache applications are updated.

Update Worker and Cache deployment images
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>
Monitor pod status

Wait for pods to be READY, monitor pod status:

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

2.1.3) Apinizer Portal and Integration Update​

Apinizer Portal and Integration can be updated similarly.

Update Portal and Integration deployment images
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>
Monitor pod statuses

Wait for pods to be READY, monitor pod statuses:

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) Offline Update​

For offline systems that require updates in Kubernetes environments, two main methods can be used:

Manual Image Transfer

Pulling image files to a server with internet and docker/containerd application and transferring these image files to the target Kubernetes cluster.

Local Registry Usage

Using a repository application that the Kubernetes cluster will use (Nexus, Harbor, etc.).

2.2.1) Pulling Images from Online Server and Transferring to Offline Servers​

If there is a machine with internet access and access to offline machines, the following steps can be performed.

2.2.1.1) Docker Usage​
# All images required for upgrade are pulled from online server
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>

# To transfer relevant images to offline servers, images are saved in `.tar` format on online server
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

# Each image is transferred to offline server
scp apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Images are loaded on each offline server
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 Usage​
# All images required for upgrade are pulled from online server
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>

# To transfer relevant images to offline servers, images are saved in `.tar` format on online server
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>

# Each image is transferred to offline kubernetes worker servers
scp docker.io-apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Images are loaded on each offline server
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) Using Local Image Registry or Repository​

Although different image registries and repositories work with different methods, in most of them, pulled images must be tagged and sent to the application.

Info

For node configuration and deployment image path updates with corporate registries such as Nexus or Harbor, see the Container Registry section. The steps below cover the scenario of pushing images to a registry.

Info

If the application is used as a reverse proxy, it is sufficient to provide the necessary definition for the apinizercloud repo at hub.docker.com.

2.2.2.1) Docker Usage​
# All required images are pulled
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>

# Pulled images are retagged with necessary tag information
docker tag apinizercloud/apimanager:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
docker tag apinizercloud/worker:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
docker tag apinizercloud/cache:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
docker tag apinizercloud/apiportal:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
docker tag apinizercloud/integration:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

# Images are transferred to organization's local image registry:
docker push <LOCAL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
docker push <LOCAL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
docker push <LOCAL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
docker push <LOCAL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
docker push <LOCAL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
2.2.2.2) Containerd Usage​
# All required images are pulled
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>

# Pulled images are retagged with necessary tag information
ctr image tag docker.io/apinizercloud/apimanager:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/worker:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/cache:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/apiportal:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
ctr image tag docker.io/apinizercloud/integration:<NEW_VERSION> <LOCAL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

# Images are transferred to organization's local image registry:
ctr images push <LOCAL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
ctr images push <LOCAL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
ctr images push <LOCAL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
ctr images push <LOCAL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
ctr images push <LOCAL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>

2.2.3) Apinizer Api Manager Update​

Warning

Apinizer Api Manager must be updated before updating other Apinizer components.

After Api Manager makes updates to the database, other Apinizer applications need to be fed from the database with current settings.

Therefore, after Api Manager is updated, make sure that Api Manager pods on Kubernetes are in "ready" status and then update other components.

Commands in this and subsequent steps are run on servers with Kubernetes Control Plane task.

Check deployment information
kubectl get deployments -Ao wide
Update Api Manager deployment image
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=<LOCAL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
Monitor pod status

Wait for the pod to be READY, monitor pod status:

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

2.2.4) Apinizer Worker and Cache Update​

After ensuring that the Apinizer Api Manager image is updated, Apinizer Worker and Cache applications are updated.

Update Worker and Cache deployment images
kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=<LOCAL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=<LOCAL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
Monitor pod status

Wait for pods to be READY, monitor pod status:

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

2.2.5) Apinizer Portal and Integration Update​

Apinizer Portal and Integration can be updated similarly.

Update Portal and Integration deployment images
kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=<LOCAL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=<LOCAL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
Monitor pod statuses

Wait for pods to be READY, monitor pod statuses:

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) Rolling Back Apinizer Application Updates​

Version downgrade is not supported in Apinizer applications. However, if there are database backups, an updated version can be rolled back.

2026.09.2 identity and limit migration cannot be rolled back

Once the automatic identity and limit migration described in section 1 above has run, downgrading the application alone does not undo it — an older Manager binary does not know how to read the typed records the migration wrote. The only way back is restoring the MongoDB backup taken in step 1 before the upgrade, following the steps below.

Warning

When updates need to be rolled back for any reason, the first thing to do is check that MongoDB backup was taken before the update. If there is no database backup taken before the update, there is no way to roll back the changes Api Manager application will make to the database, so if there is a system backup of the database servers, you can return to the most recent backup at that date and return to that version.

This operation will cause loss of changes made since that date, so it should be done carefully. Since structural differences may occur with the update, this operation can only be considered for reference purposes.

3.1) MongoDB Database Restore​

Before this operation, it should be confirmed that the Api Manager application is not in a restart loop. For the safest method, the Api Manager application should be stopped.

Stop Api Manager

Api Manager replica count is reduced to 0 and all pods are shut down:

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

MongoDB should be returned to the most recent backup. The --drop parameter can be used to prevent possible conflicts during return. This will only drop collections that have a counterpart in the backup file and then perform the load.

Note

For detailed information, the MongoDB Database Backup and Restore page can be reviewed.

3.2) Rolling Back Api Manager Application Version​

Note

If a local registry will be used during rollback, commands should be updated accordingly.

Roll back Api Manager deployment image to old version
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<OLD_VERSION>
Increase replica count to 1
kubectl scale deploy <MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> --replicas=1
Monitor pod status

Wait for the pod to be READY, monitor pod status and logs:

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

3.3) Rolling Back Other Applications' Versions​

When the Api Manager application is running, other applications can be rolled back to the old version together.

Note

If a local registry will be used during rollback, commands should be updated accordingly.

Roll back deployment images to old version
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>
Check pod statuses

Wait for pods to be READY, monitor pod statuses and logs if necessary:

kubectl get pods -A
Warning

Mongock migrations are forward-only. If the new version changed the DB schema, rolling back may prevent the old Manager from booting. Back up MongoDB before major upgrades.

En son tarihinde güncellendi