This article describes how to update Cloudmersive Private Cloud Windows container deployments in Azure App Service with no planned downtime.

The guidance applies to both:

• Cloudmersive Private Cloud Reverse Proxy
• Cloudmersive API on Private Cloud

Both workloads can be deployed as Windows containers on Azure App Service and updated using the same Azure App Service container update patterns.

Cloudmersive recommends using Azure App Service deployment slots for production environments. A direct, in-place container image update is also supported for simpler environments, but deployment slots provide the safest update and rollback workflow.

Applies to

This article applies to:

• Cloudmersive Private Cloud
• Cloudmersive Private Cloud Reverse Proxy
• Cloudmersive API on Private Cloud
• Azure App Service
• Windows container deployments
• Azure Container Registry
• Container image updates, for example moving from one Cloudmersive image tag to a newer image tag

Overview

There are two common update approaches.

Recommended production method: deployment slot update and swap

Use this method for production and high-availability environments.

With this approach, the new container image is deployed to a staging slot first. The staging slot can be started, warmed up, and validated before it is swapped into production.

Benefits:

• No planned downtime for normal HTTP traffic when the application is healthy and warmed up
• Safer validation before production traffic is moved
• Simple rollback by swapping back to the previous slot
• Recommended for production environments

Simpler method: direct production image tag update

Use this method for lower-risk or non-critical environments.

With this approach, the production App Service image tag is changed directly.

Benefits:

• Simpler workflow
• No deployment slot required
• Suitable for development, test, or lower-risk environments

Limitations:

• Less controlled than deployment slots
• Less opportunity to validate before production traffic uses the new container
• Rollback requires changing the production image tag back to the previous version

Zone redundancy is not required for zero-downtime application updates. Zone redundancy is an Azure App Service Plan resiliency feature that helps protect against an Azure availability zone failure. Deployment slots and health checks are the primary Azure App Service features used for zero-downtime application updates.

Deployment Models Covered

Cloudmersive Private Cloud deployments may include one or more Azure App Service Windows container applications.

Cloudmersive Private Cloud Reverse Proxy

The Cloudmersive Private Cloud Reverse Proxy routes traffic to Cloudmersive Private Cloud API services.

This workload is deployed as a Windows container.

Cloudmersive API on Private Cloud

Cloudmersive API on Private Cloud runs Cloudmersive API functionality in a private deployment.

This workload is also deployed as a Windows container.

The same update process can be used for each App Service container workload. If your environment includes multiple Cloudmersive App Services, update and validate them one at a time unless Cloudmersive Support has provided a coordinated upgrade sequence.

Recommended Update Order

For environments with both Cloudmersive API containers and the Cloudmersive Reverse Proxy, Cloudmersive generally recommends the following order:

1. Import or make available the new container image tags in Azure Container Registry.
2. Update the Cloudmersive API App Service container or containers.
3. Validate that the API containers are healthy.
4. Update the Cloudmersive Private Cloud Reverse Proxy App Service container.
5. Validate end-to-end traffic through the reverse proxy.

This approach helps ensure the backend API services are ready before the reverse proxy is updated.

If Cloudmersive Support provides a release-specific update order, follow that release-specific guidance.

Prerequisites

Before beginning, confirm the following:

1. The Cloudmersive Private Cloud workload is already deployed to Azure App Service as a Windows container.
2. The App Service Plan has sufficient memory for the workload.
3. For the Cloudmersive Private Cloud Reverse Proxy, Cloudmersive recommends Premium v3 P2mv3 or higher.
4. The new Cloudmersive container image tag has already been imported into your Azure Container Registry.
5. The App Service can pull images from the Azure Container Registry.
6. Required Cloudmersive environment variables are configured.
7. Application Insights is not enabled for the Cloudmersive Private Cloud deployment.
8. Health Check is enabled, or can be enabled, using the correct health path for the workload.

For production environments, Cloudmersive recommends running at least two App Service instances. This allows Azure Health Check and App Service load balancing to route traffic away from unhealthy instances during normal operation.

Image Names and Tags

The exact image name and tag depend on the Cloudmersive Private Cloud component being updated.

For the Cloudmersive Private Cloud Reverse Proxy, the image may use a tag similar to:

win2022_win_reverseproxy_4_11_11

For Cloudmersive API on Private Cloud, use the Cloudmersive API image name and tag provided in your Cloudmersive Private Cloud installation or update instructions.

When updating, always use the specific version tag provided by Cloudmersive. Avoid using floating tags such as latest in production environments.

Option 1: Recommended Update Using a Deployment Slot

This is the recommended production update method.

With this approach, you deploy the new Cloudmersive container image to a staging slot, validate that it starts successfully, and then swap the staging slot into production.

Use this process separately for each Cloudmersive App Service, including the Cloudmersive API App Service and the Cloudmersive Reverse Proxy App Service.

Step 1: Open the Azure App Service

1. Sign in to the Azure Portal.
2. Navigate to the Azure App Service running the Cloudmersive workload you want to update.
3. Confirm that you are viewing the production App Service resource.

For example, this may be one of the following:

• The Cloudmersive Private Cloud Reverse Proxy App Service
• A Cloudmersive API on Private Cloud App Service

Step 2: Create a Staging Deployment Slot

Skip this step if a staging slot already exists.

1. In the left navigation menu, select Deployment slots.

2. Click Add slot.

3. Enter a slot name such as:

   staging

4. For Clone settings from, select the production slot if available.

5. Click Add.

Azure will create a separate staging slot with its own URL.

Step 3: Configure Container Registry Access for the Staging Slot

1. Open the newly created staging slot.
2. In the left navigation menu, select Identity.
3. Confirm that the same managed identity approach used by production is also configured for the staging slot.
4. If your deployment uses a system-assigned managed identity, confirm that the staging slot identity has permission to pull images from the Azure Container Registry.
5. If your deployment uses a user-assigned managed identity, confirm that the identity is assigned to the staging slot.

The identity used by the staging slot must have pull access to the Azure Container Registry.

Step 4: Configure the New Container Image on the Staging Slot

1. While viewing the staging slot, select Deployment Center.

2. Open the container configuration settings.

3. Confirm the following settings:

   • Image Source: Azure Container Registry
   • Registry: Your Azure Container Registry, for example CloudmersiveContainerRegistry
   • Authentication: Managed Identity
   • Image: the Cloudmersive image name for the component being updated
   • Tag: the new Cloudmersive image tag

For the Cloudmersive Private Cloud Reverse Proxy, the image name may be:

cloudmersive-privatecloud

The tag may be similar to:

win2022_win_reverseproxy_4_11_11

For Cloudmersive API on Private Cloud, use the image name and tag provided in your Cloudmersive API Private Cloud update instructions.

4. Save the changes.

Azure App Service will pull and start the selected container image in the staging slot.

Step 5: Confirm Environment Variables on the Staging Slot

1. While viewing the staging slot, select Environment variables.
2. Confirm that all required Cloudmersive application settings are present.
3. Confirm that the Cloudmersive access key setting is present if required by your deployment.
4. Confirm that any API-specific or reverse-proxy-specific settings are present.

For the Cloudmersive Private Cloud Reverse Proxy, confirm that the following setting exists:

CMPCAccessKey

For Cloudmersive API on Private Cloud, confirm the required application settings from your Cloudmersive API deployment instructions.

For most deployments, the staging slot should use the same functional Cloudmersive settings as production. If your organization uses slot-specific settings, confirm that the deployment slot setting behavior matches your internal policy.

Step 6: Enable or Confirm Health Check

Cloudmersive recommends enabling Azure App Service Health Check.

1. Open the App Service or slot.
2. In the left navigation menu, select Health check.
3. Enable Health Check.
4. Set the health check path for the workload.

For the Cloudmersive Private Cloud Reverse Proxy, use:

/

For Cloudmersive API on Private Cloud, use the health or status path specified in your Cloudmersive API Private Cloud deployment instructions.

5. Click Save.

The health check path should return a successful response only when the Cloudmersive container is ready to receive traffic.

Step 7: Warm Up and Validate the Staging Slot

1. Open the staging slot Overview page.
2. Click Browse.
3. Confirm that the Cloudmersive workload loads successfully.
4. Refresh until the expected Cloudmersive response appears.
5. Optionally, send a test API request to the staging slot URL.

For the Reverse Proxy, confirm that traffic can be routed successfully through the reverse proxy.

For Cloudmersive API on Private Cloud, confirm that the API container responds successfully to an appropriate test request.

Do not proceed to the swap until the staging slot is healthy.

Step 8: Swap Staging into Production

1. Return to the production App Service.

2. Select Deployment slots.

3. Click Swap.

4. Set the source slot to:

   staging

5. Set the target slot to:

   production

6. Review the swap changes.

7. Start the swap.

Azure will warm the source slot and then switch production traffic to the updated container image.

Step 9: Verify Production

After the swap completes:

1. Open the production App Service Overview page.
2. Click Browse.
3. Confirm that the Cloudmersive workload is responding.
4. Confirm that API traffic is successful.
5. Review App Service logs and Health Check status.

The previous production version is now available in the staging slot.

Step 10: Repeat for Other Cloudmersive App Services

If your deployment includes multiple Cloudmersive App Services, repeat the slot update process for each application.

Recommended sequence:

1. Cloudmersive API on Private Cloud App Service or services
2. Cloudmersive Private Cloud Reverse Proxy App Service

Validate each component before moving to the next component.

Rollback Procedure for Slot-Based Updates

If you need to roll back an App Service:

1. Open the production App Service.

2. Select Deployment slots.

3. Click Swap.

4. Set the source slot to:

   staging

5. Set the target slot to:

   production

6. Complete the swap.

This swaps the previous production version back into production for that App Service.

If your deployment includes multiple App Services, roll back the affected component first. If necessary, roll back the other Cloudmersive components in the reverse order of the update.

Option 2: Direct Production Image Tag Update

This method updates the production App Service directly. It is simpler, but it provides less pre-production validation and a less controlled rollback experience than deployment slots.

Use this method only when deployment slots are not available or when the environment is lower risk.

Use this process separately for each Cloudmersive App Service, including Cloudmersive API on Private Cloud and the Cloudmersive Private Cloud Reverse Proxy.

Step 1: Confirm the New Image Tag Is Available

Before changing App Service, confirm that the new Cloudmersive image tag has already been imported into your Azure Container Registry.

1. In the Azure Portal, open your Azure Container Registry.
2. Select Repositories.
3. Select the Cloudmersive repository for the component being updated.
4. Confirm that the new tag is present.

For the Reverse Proxy, the repository and tag may look similar to:

• Repository: cloudmersive-privatecloud
• Tag: win2022_win_reverseproxy_4_11_11

For Cloudmersive API on Private Cloud, use the repository and tag provided in your Cloudmersive API Private Cloud update instructions.

Step 2: Open the Production App Service

1. Sign in to the Azure Portal.
2. Navigate to the production App Service running the Cloudmersive workload you want to update.
3. Select Deployment Center.

Step 3: Change the Container Image Tag

1. In Deployment Center, open the container configuration settings.
2. Confirm the image name for the Cloudmersive component being updated.
3. Change the image tag to the new Cloudmersive version.
4. Save the changes.

Azure App Service will pull and start the new container image.

Step 4: Monitor Startup

1. Open the App Service Overview page.
2. Wait for the application to restart with the new container image.
3. Click Browse.
4. Refresh until the expected Cloudmersive response appears.
5. Confirm API traffic is successful.

For larger Windows container images, startup can take several minutes.

Step 5: Repeat for Other Cloudmersive App Services

If your deployment includes multiple Cloudmersive App Services, repeat the direct image tag update for each App Service.

Recommended sequence:

1. Cloudmersive API on Private Cloud App Service or services
2. Cloudmersive Private Cloud Reverse Proxy App Service

Validate each component before moving to the next component.

Rollback Procedure for Direct Updates

If you need to roll back:

1. Open the production App Service.
2. Select Deployment Center.
3. Change the image tag back to the previous known-good Cloudmersive image tag.
4. Save the changes.
5. Wait for App Service to pull and start the previous container image.
6. Verify that the Cloudmersive workload is responding.

If your deployment includes multiple App Services, roll back the affected component first. If necessary, roll back related components in the reverse order of the update.

High Availability Recommendations

For production deployments, Cloudmersive recommends the following:

1. Use deployment slots for updates.
2. Run at least two App Service instances.
3. Enable Health Check.
4. Use immutable container image tags rather than latest.
5. Validate the staging slot before swapping into production.
6. Keep the previous production version in the staging slot until the new version has been validated in production.
7. Update one Cloudmersive App Service at a time unless Cloudmersive Support provides a release-specific coordinated update procedure.
8. Do not enable Application Insights for the Cloudmersive Private Cloud deployment.

Is Zone Redundancy Required?

No. Zone redundancy is not required for zero-downtime container image updates.

Deployment slots are used to perform zero-downtime application updates. Zone redundancy is an Azure infrastructure resiliency option that distributes App Service Plan instances across availability zones in supported regions.

You may choose to enable zone redundancy for additional resilience against an Azure availability zone outage. However, it is not required in order to use deployment slots or to perform a zero-downtime Cloudmersive container image update.