Revisions in Azure Container Apps Preview
A revision is an immutable snapshot of a container app.
- The first revision is automatically created when you deploy your container app.
- New revisions are automatically created when a container app's
templateconfiguration changes. - While revisions are immutable, they're affected by changes to global configuration values, which apply to all revisions.
Revisions are most useful when you enable ingress to make your container app accessible via HTTP. Revisions are often used when you want to direct traffic from one snapshot of your container app to the next. Typical traffic direction strategies include A/B testing and BlueGreen deployment.
The following diagram shows a container app with two revisions.
The scenario shown above presumes the container app is in following state:
- Ingress is enabled, which makes the container app available via HTTP.
- The first revision is deployed as Revision 1.
- After the container was updated, a new revision was activated as Revision 2.
- Traffic splitting rules are configured so that Revision 1 receives 80% of the requests, while Revision 2 receives the remaining 20%.
Change types
Changes made to a container app fall under one of two categories: revision-scope and application-scope changes. Revision-scope changes are any change that triggers a new revision, while application-scope changes don't create revisions.
Revision-scope changes
The following types of changes create a new revision:
- Changes to containers
- Add or update scaling rules
- Changes to Dapr settings
- Any change that affects the
templatesection of the configuration
Application-scope changes
The following types of changes do not create a new revision:
- Changes to traffic splitting rules
- Turning ingress on or off
- Changes to secret values
- Any change outside the
templatesection of the configuration
While changes to secrets are an application-scope change, revisions must be restarted before a container recognizes new secret values.
Activation state
New revisions remain active until you deactivate them, or you set your container app to automatically deactivate old revisions.
- Inactive revisions remain as a snapshot record of your container app in a certain state.
- You are not charged for inactive revisions.
- Up to 100 revisions remain available before being purged.