Ana içeriğe geç

Uninstall

The method to uninstall Apinizer modules depends on your installation type. This page contains step-by-step uninstall instructions for both Container (Kubernetes / Docker) and Virtual Server (Linux / VM) deployments.

uyarı

Before uninstalling, back up the conf/master.key and conf/application.env files from each module installation directory. The master key cannot be regenerated and ENC(...) encrypted values cannot be decrypted without it. The MongoDB database is not deleted by these uninstall steps — if a clean state is desired, manual database drop is required.

Uninstall Order​

Remove modules in reverse order to minimize disruption and allow deletion of associated records from the Manager UI:

  1. API Portal (first — ends user access)
  2. Integration
  3. Cache
  4. Worker (Gateway)
  5. API Manager (last — all management metadata and audit logs live here)

Remove other modules before API Manager so you can delete their records from the Manager UI.

Kubernetes Namespace Deletion​

You can remove all Apinizer modules at once by deleting the Apinizer namespaces:

# Deletes all deployments, services, configmaps, secrets, and RBAC resources
kubectl delete namespace apinizer
kubectl delete namespace <gateway-namespace>
kubectl delete namespace <integration-namespace>
kubectl delete namespace <portal-namespace>

# Also clean cluster-level RBAC
kubectl delete clusterrole apinizer-role apinizer-gateway-role
kubectl delete clusterrolebinding apinizer-role-binding apinizer-gateway-role-binding

For module-by-module controlled deletion, delete the relevant deployment, service, configmap, and secret resources for each module namespace separately.

Docker / docker-compose​

To remove a module completely:

# With docker compose:
docker compose down                      # stop all services (keeps volumes)
docker compose down -v                   # also DELETE volumes (full reset)

# Vanilla docker (per module):
docker stop -t 60 apinizer-<module> && docker rm apinizer-<module>
docker volume rm apinizer-<module>-logs   # optional — drop the log volume
docker rmi apinizercloud/<module>:${VERSION}

Per-module stop timeouts​

Use a generous stop timeout to allow in-flight requests to drain gracefully:

ModuleCommand
API Managerdocker stop -t 30 apinizer-apimanager
API Portaldocker stop apinizer-apiportal
Workerdocker stop -t 60 apinizer-worker
Cachedocker stop -t 30 apinizer-cache
Integrationdocker stop -t 120 apinizer-integration

Manager UI Record Cleanup​

After pods and containers are deleted, clean up the remaining records in the Manager UI:

  • Server Management → Environments — Delete the relevant Environment
  • Server Management → Cache Servers — Delete registered Cache servers
  • Server Management → Integration Servers — Delete registered Integration servers
  • Portal → Portals — Delete registered Portals

MongoDB Data (Optional — for Clean State)​

If you want to completely delete the Apinizer Manager database:

mongosh --host <MONGODB_HOST> --port 25080 -u apinizer -p <PASSWORD>
use apinizer
db.dropDatabase()
uyarı

This action deletes all proxy definitions, environment records, and audit logs. This action cannot be undone.

Side Effects​

  • MongoDB: Not touched by docker compose down or docker rm commands. Drop the database manually for a clean slate.
  • API Portal registration: Deleting the Portal record in the Manager UI is a separate step — Portal → Portals → Delete.
  • Worker Environment record: Stays in the Manager UI; delete it from the Manager UI if you are decommissioning the gateway entirely.
  • Cache MapStore data: Hazelcast MapStore documents in MongoDB remain. To reset counter history, drop the relevant collections from MongoDB manually.
  • Integration Quartz state: schedule_integration_* collections remain in MongoDB. To start a clean install, drop them manually after every Integration node has stopped.

Verification​

After uninstall, verify that all resources have been removed:

# Container environment:
kubectl get all -n apinizer        # No resources found
docker ps -a | grep apinizer       # Should be empty

# Virtual server:
systemctl status apinizer-apimanager   # Unit not found
ls /opt/apinizer-manager               # No such file or directory
id apinizer                            # no such user (if the apinizer user was also removed)

Troubleshooting​

"Cannot connect to MongoDB" after partial uninstall​

If only some modules are removed but the Manager remains, MongoDB continues to operate normally. If you accidentally drop the database, restore from backup — Apinizer does not have a built-in recovery mechanism.

Master Key Lost After Uninstall​

If you did not back up the master key and need to recover encrypted values:

  • Recovery is not possible — the master key cannot be regenerated
  • On reinstall, set all ENC(...) values back to plaintext
  • Run apimanager-encrypt.sh to re-encrypt with the new master key

systemd Unit Still Active After Delete​

After removing the unit file, ensure the daemon reloads:

sudo systemctl daemon-reload
sudo systemctl reset-failed

Then verify:

sudo systemctl list-unit-files | grep apinizer   # Should be empty
En son tarihinde güncellendi