Migration path for RaaS deployed as a container to RPM in Aria Automation Config

Products

• VCF Automation
• VMware Salt

Issue/Introduction

This article provides step-by-step instructions for migrating your Aria Config RaaS (Returner as a Service) daemon from a containerized microservice deployment to a standard RPM-based deployment on the same RHEL 8 host.

The core concept of this migration is transitioning the RaaS daemon from a container runtime to a native host-level service. Because you are performing an in-place migration on the same host, the FQDN and IP address will remain unchanged. As long as you retain the /etc/raas/pki/.raas.key file—which allows the RaaS daemon to decrypt the information in your database—you can safely stop the container and install the RaaS RPM directly on the host OS seamlessly.

Environment

VMware Aria Automation Config (formerly SaltStack Config) 8.18.0 to 8.18.3

Cause

The Aria Config RaaS daemon, previously provided as a containerized microservice relying on components such as NGINX, is now distributed as an RPM package for RHEL-based systems. Administrators must migrate their existing containerized workloads to the new RPM format to resolve identified security vulnerabilities and upgrade to the 8.18.3 release.

Resolution

This procedure details an in-place migration of the RaaS daemon on its current host. The expected outcome of this process is that the RaaS service will seamlessly transition from running as a containerized application to a native systemd service installed via RPM. Because this migration occurs in-place, the RaaS node will retain its exact existing FQDN and IP address, ensuring no network adjustments are needed. This is an isolated migration of the RaaS daemon only; all other components (PostgreSQL, Redis/Valkey, Salt Master) will remain completely unaffected and continue to run in their existing locations.

NOTE: Before beginning any migration tasks, we strongly recommend creating a fresh database backup using your organization's standard PostgreSQL backup procedures. Please refer to standard database backup instructions for Aria Config prior to proceeding: https://knowledge.broadcom.com/external/article/312990/backing-up-and-restoring-your-postgresql.html

Step 1: Connect to the Host and Escalate Privileges

The majority of the commands required for this migration process necessitate administrative privileges on the host operating system.

1. Connect to your existing RaaS VM via SSH.

2. Elevate your session to the root user:

   sudo -s
   

Step 2: Preparation and Configuration Backup

On the system hosting your current RaaS container, you must back up the configuration directory. This captures your vital .raas.key and configuration files in case they are modified during the RPM installation.

1. Ensure you are operating in a root terminal on the host OS.

2. Create a backup of the /etc/raas directory using the tar command:

   tar -czvf /root/raas-config-backup.tar.gz /etc/raas
   

3. Securely store the raas-config-backup.tar.gz file, as it will be required to restore connectivity to the database if the /etc/raas directory is accidentally overwritten.

Step 3: Halt the Container Service

To avoid port conflicts, gracefully stop the existing RaaS container before installing the native service.

1. Identify the RaaS container ID. In most standard deployments, the RaaS container is the only container running on the host, or its container/image name explicitly includes raas. You can try finding it with:

   docker ps | grep raas
   

   Alternative Identification Methods: If the container is not easily identifiable by name, you can verify the correct container using these methods:

   • Listening Ports: The Aria Config RaaS service typically binds to web/API ports such as 443 , 8080 , or 80 . Check the PORTS column in the docker ps output.

   • Expected Mounted Directories: The RaaS container must have the local configuration directory mounted. Look for a container that maps a volume to /etc/raas (you can verify mounts using docker inspect <container_id>).

2. Stop the container image using the identified ID:

   docker stop <RAAS_CONTAINER_ID>
   

Once stopped, the required network ports on the host will be freed up for the new RPM-based service to bind to.

Step 4: Verify Existing RPM Installation Status

Before proceeding with the deployment, confirm whether the RaaS RPM package is already installed on your host. You can check this using standard dnf or rpm commands.

1. Run the following command to check for an existing installation:

   rpm -qa | grep raas
   

   (Alternatively, you can use dnf list installed raas)

2. If the package is not installed: Proceed to Step 5 to perform the installation.

3. If the package is already installed: Then proceed to review the instructions for how to upgrade using the standard documentation: https://techdocs.broadcom.com/us/en/vmware-cis/other/vmware-salt/8-18/using-vmware-salt/installation-for-administrators-and-deployment/upgrade-to-vcf-salt/upgrading-to-vcf-salt/vcf-salt-application-upgrade-steps.html

Step 5: Deploy the RHEL 8 RPM In-Place

Proceed with the RPM installation directly on the host OS.

Note: Architectural enhancements in recent releases introduce new environmental and security isolation prerequisites. Failure to properly isolate the raas service account home directory or clear legacy directories can result in upgrade failures, schema upgrade deadlocks, or database credential authentication errors. The following steps incorporate the remediation for these prerequisites.

1. Installation of the RaaS RPM may require installation of additional dependencies. See the official installation documentation for additional info (https://techdocs.broadcom.com/us/en/vmware-cis/other/vmware-salt/8-18/using-vmware-salt/installation-for-administrators-and-deployment/vcf-salt-installation-overview.html). If you are on Red Hat Enterprise Linux, then you may need to have an active subscription via Red Hat’s built-in subscription-manager CLI tool. Install the newly distributed RaaS RPM package provided by Broadcom:

   dnf install <path_to_raas_rpm_file>.rpm
   

   Note: The information and remediation steps beginning in step 2 below are sourced from this KB article: https://knowledge.broadcom.com/external/article/443389/database-upgrade-fails-and-raas-service.html

2. Artifact Cleanup: Identify and clear out legacy state directories to prevent initialization conflicts.

   rm -fRv /var/lib/raas
   

3. Secure State Directory Allocation: Create an isolated home directory for the raas service account. This allows the application to store runtime state without granting write access to the binary execution path (/opt/saltstack/raas/).

   mkdir -p /app/raas
   chown -R raas:raas /app/raas
   

4. Service Account Profile and Certificate Configuration: Reconfigure the service account profile to utilize the newly created isolated home directory, and enforce explicit ownership over the PKI path.

   usermod -d /app/raas raas
   chown -Rv raas:raas /etc/pki/raas
   

5. Secure Database Credential Re-Initialization: To prevent credential logging in plain-text .bash_history files, securely reset the PostgreSQL user password via the interactive psql password prompt.

   psql -U postgres
   \password salt_eapi
   

6. Virtual Environment Activation and Schema Upgrade: Switch the session context to the raas user, set the environment variables, activate the daemon's Python virtual environment, generate the raas.secconf file, and perform the necessary database schema upgrade.

   sudo -u raas /bin/bash
   export HOME=/app/raas
   export PATH=/opt/saltstack/raas/bin:$PATH
   source /opt/saltstack/raas/bin/activate
   raas -l debug save_creds postgres='{"username": "salt_eapi","password":"<DB_PASS>"}' redis='{"username":"<REDIS_USER>","password":"<REDIS_PASS>"}'
   raas -l debug upgrade
   exit
   

7. Crucial Configuration Check: Since this is an in-place migration, your custom configuration files and .raas.key should already reside in /etc/raas. Verify that your custom settings are intact. If the RPM installation altered your configuration, restore the files from your backup:

   tar -xzvf /root/raas-config-backup.tar.gz -C /
   

8. Update Ownership: The RPM installation creates a new raas user on the host OS. Because the /etc/raas files were previously accessed via a container, you must ensure the new local raas user has proper ownership of the directory and the .raas.key file:

   chown -R raas:raas /etc/raas
   

9. Enable and start the new RaaS systemd service:

   systemctl enable --now raas
   systemctl status raas
   

Step 6: Archive the Old Container (Post-Verification)

Once you have verified that the new RPM-based RaaS daemon is running, successfully connecting to the database, and servicing your salt-masters, you should archive the old container state for emergency restoration before fully deleting it.

1. Commit the container state to an image to capture any runtime changes:

   docker commit <RAAS_CONTAINER_ID> raas-emergency-archive
   

2. Save the image as a tarball:

   docker save -o raas-container-archive.tar raas-emergency-archive
   

3. Move raas-container-archive.tar to your secure backup storage.

Additional Information

• Emergency Rollback: If you ever need to perform an emergency rollback to the containerized version, you can disable the new raas service (systemctl disable --now raas) and restore the archived container using the command docker load -i raas-container-archive.tar.

• Cleanup: Once the archive is safely stored, you may completely delete the old container and its base images from the Docker host to free up disk space.