OpsAny SaaS Application Architecture

OpsAny SaaS applications are independent platforms built on the PaaS platform. They can be deployed with PaaSAgent, or in standalone containers.

• Deploying SaaS platforms with PaaSAgent (now deprecated; only for development and test environments.)
• Deploying SaaS platforms in standalone containers (the default since v2.0.0, suitable for production.)

Standalone container deployment of SaaS (production)

Since v2.0.0, standalone container deployment has been the default. Each SaaS platform starts on its own, listens on a web port, and Nginx forwards requests to that port.

Example: accessing the Workbench

Listening port: 7002
Request path: /o/workbench
Forwarded to: 192.168.56.11:7002

To make later configuration optimization and performance tuning easier, the configuration each SaaS needs is placed under ${INSTALL_PATH}/conf/opsany-saas/${APPID} at deployment time and mounted into the corresponding SaaS containers.

SaaS configuration

SaaS configuration lives in the opsany-paas repository and is mounted when the SaaS starts. Every SaaS has five configuration files.

# Configuration directory
[root@opsany-prod ~]# tree /opt/opsany/conf/opsany-saas/workbench/
/opt/opsany/conf/opsany-saas/workbench/
├── workbench-init.py         # Workbench project configuration (used when changing the access domain; records the SaaS APPID and Secret Key)
├── workbench-nginx.conf      # Nginx configuration that forwards requests to uwsgi (normally not modified)
├── workbench-prod.py         # Workbench project configuration (used when changing e.g. database settings)
├── workbench-supervisor.ini # Workbench service startup configuration; defines the main process, Celery, and other processes (normally not modified)
└── workbench-uwsgi.ini       # Workbench uwsgi configuration (used for performance tuning)

# Log directory
ls /opt/opsany/logs/workbench

OpsAny also provides a script to update SaaS deployed in standalone containers. It works by removing the old container, starting a new one, and running the database migration. So if a SaaS platform misbehaves, running an update is also a valid remedy.

Day-to-day SaaS management

• 1. SaaS health checks

Every SaaS exposes a health check endpoint. - URL: https://DOMAIN_NAME/o/APPID/healthz/ - For example, unified permissions has the APPID rbac, so its health check is: https://demo.opsany.com/o/rbac/healthz/

This endpoint is public by default. If your platform is deployed on the public internet, operations staff should restrict access by editing the Nginx configuration.

• 1. Day-to-day SaaS operations

Each SaaS platform is an independent Docker container. In principle any problem is resolved by restarting the container. Apart from the performance tuning described above, users have essentially nothing to operate.

• 1. SaaS upgrades

OpsAny releases new versions periodically. Upgrade SaaS with the opsany-ce-update.sh script. The script essentially removes the old container and starts a new one, so if a SaaS runs into odd problems, running the update script to rebuild it is a valid remedy.

• 1. SaaS data backup

SaaS containers store no data: logs are mounted from INSTALL_PATH (/opt/opsany/ by default)/logs, uploaded data is mounted from INSTALL_PATH/uploads, and other data lives in MySQL and MongoDB. So there is no per-SaaS backup — back up the whole platform, namely MySQL, MongoDB, and the uploads directory.

SaaS port list

Every SaaS listens on port 80 inside its container. Docker maps each SaaS to its own port, which the Nginx in the access entry point (the opsany-base-openresty container) uses for load balancing.

• Unified permissions (APPID: rbac) — 7001
• Workbench (APPID: workbench) — 7002
• Resource platform (APPID: cmdb) — 7003
• Control platform (APPID: control) — 7004
• Job platform (APPID: job) — 7005
• Basic monitoring (APPID: monitor) — 7006
• Cloud management platform (APPID: cmp) — 7007
• Bastion host (APPID: bastion) — 7008
• Application platform (APPID: devops) — 7009
• Code repository (APPID: code) — 7010
• Pipeline (APPID: pipeline) — 7017
• Artifact repository (APPID: repo) — 7020
• Continuous deployment (APPID: deploy) — 7018

In practice you can deploy SaaS platforms on different hosts — you only need to change the Nginx configuration, and you must keep the uploads directory in sync, for example by mounting it over NFS. Our recommendation is to deploy OpsAny on Kubernetes.

Deploying SaaS with PaaSAgent (test)

Before v2.0.0, deploying and updating SaaS relied mainly on the PaaSAgent service. PaaSAgent is, as the name suggests, the PaaS's agent — the agent the PaaS platform uses to maintain SaaS. A PaaS platform can have PaaSAgents for both a test and a production environment.

PaaSAgent overview

The paasagent directory contains the source of the agent module that corresponds to the application engine (appengine) in the PaaS platform.

Main responsibilities:

• The agent must be deployed on the application server
• It receives requests from the upper-layer application engine (appengine) and performs tasks such as deploying and unpublishing SaaS applications (building the application runtime and hosting processes)

Technology stack:

• framework: labstack/echo
• python run time: virtualenv, uwsgi

Dependencies:

• paas: when using built-in applications, downloads the SaaS deployment package the user uploaded from the paas service.
• appengine: calls the appengine API to write back the SaaS application's deployment logs.

How the PaaSAgent deployment script works

That script has been archived. What did ./saas-base-install.sh install actually do?

1. Created the MySQL databases the SaaS needs (which is why installing PaaS requires the MySQL client — to run the initialization).
2. Created the MongoDB databases the SaaS needs (which is why installing PaaS requires the MongoDB client — also for initialization).
3. Imported the built-in models of the resource platform (CMDB). (That is why after installation the resource platform's resource models contain plenty of built-in data.)
4. Added the SaaS application's environment variables to the PaaS platform. (SaaS configuration such as its database is stored on the PaaS platform; at install time it is read from the platform and passed to the program as environment variables.)
5. Ran deploy.py to deploy the SaaS. That script essentially uploads the package and clicks the deploy button for you.

SaaS package deployment flow

Whether you deploy by calling deploy.py from saas-base-install.sh or manually in the Developer Center under Built-in Applications, the flow is the same. PaaSAgent creates a Python virtual environment for each SaaS, starts it with Supervisor + uwsgi, and forwards through PaaSAgent's Nginx. So after the PaaSAgent container restarts, you must start all SaaS platforms manually with the script.

1. When you click upload, the SaaS package is uploaded and saved to /opt/opsany/paas/paas/media/saas_files/ inside the PaaS container.
2. When you click deploy, PaaSAgent downloads that file from the paas service and saves it into the paasagent container. The paas address comes from the PAAS_SERVER_URL parameter configured in paas_agent_config.yaml.
3. paasagent creates the corresponding Python virtual environment for the SaaS in that directory.
4. paasagent extracts the downloaded SaaS package and installs every dependency package under pkgs.
5. paasagent creates a supervisor service for the SaaS and generates the supervisor ini configuration automatically.
6. paasagent starts the SaaS service through supervisor.
7. It runs the Django migration.