Ambassador Cloud allows you to progressively rollout new versions of your services listed in the Service Catalog.
This feature leverages Argo CD to automatically monitor changes to a Git repository and apply them to your Kubernetes cluster, following a GitOps approach. At this point, Argo Rollouts comes in to control how traffic coming from Edge Stack gets sent to the new version of your service.
Upon creation of a rollout, Ambassador Cloud will prompt for a few questions:
- Image tag: new docker image version to rollout.
- Rollout duration: amount of time on which to spread the rollout steps between 0% and 100% traffic sent to the canary version.
- Weight increment: increment to the percentage of traffic routed to the canary version, distributed over the rollout duration.
- Number of pods: number of replicas (pods) your application should be running at the end of the rollout duration.
Rollout object is found matching the deployment manifest name (which should only
happen the first time a rollout is created), then Ambassador Cloud will look for a
Deployment object matching that same name.
If found, a new
Rollout manifest will be created referring to that deployment object and configured with the
mappings. A new canary service based on the current service specs
will also be created to allow Argo Rollouts to control the flow between the two versions.
The rollout steps will then be resolved based on the provided rollout duration and weight increment along with the
new number of pods. Ambassador Cloud will also search for a container (either in the
Deployment manifest) that
image property matching the configured image name and update it with the
provided new image tag.
Ambassador Cloud will then update those manifests on a new branch, open a pull request targeting the base branch and show you that new rollout in the service rollouts page. You'll see a "Merge pull request" button that will take you to the pull request where you can approve and merge it.
Once the pull request is merged, Argo CD will detect that a new version of the
Application has been pushed on the
repository and will sync the new manifests in the Kubernetes cluster. Once applied, Argo Rollouts will proceed to the
progressive delivery of the
Rollout object and its progress will be reported in Ambassador Cloud.
A new Helm values file named following the convention a8r-values-<ENVIRONMENT_name>.yaml (for example, a8r-values-staging.yaml) is generated with the values for the rollout configuration. These values will later be used to configure the
If you already have a
Rolloutobject matching the deployment manifest name in the templates folder, you should configure it to use the values from the Ambassador values file. You can follow this example:
If there is no
Rolloutobject that matches the deployment manifest name in the templates folder, use the example above to create one. More information about the
Rollout. This should only occur the first time a rollout is created. For more information about
Rolloutspec see the official Argo Rollouts documentation.
Serviceobject for the canary pods by duplicating the existing service and appending
-canaryto its name.
Mappingobject pointing to the "stable"
Ambassador Cloud updates the manifests on a new branch. Then opens a pull request to target the base branch. The new rollout appears in the service's rollouts page, with a "Merge pull request" button. Click on this button to open the pull request page, where you can approve and merge it.
Before you merge the pull request, disable the Argo Application's auto-sync feature in case you have it enabled. You will re-enable it back in step 9. Once the pull request is merged, Argo CD will detect that a new version of the
Applicationhas been pushed on the repository.
Now you will have to configure your Argo Application to use the Ambassador Helm values file after your own. This configuration is found in the
Parameterssection of your Application.
Finally, it's time to re-enable the Application's auto-sync or refresh your application. Argo CD will detect that the
Applicationis out of sync and will update the manifests in the cluster to match the ones in the repository. Argo Rollouts will proceed to the progressive delivery of the
Rolloutobject and its progress is reported in Ambassador Cloud.
The following annotations are leveraged to make the Rollouts flow possible.
The repository on which to bring changes.
The URL of the repository in which the manifests or the Helm Chart is. If this annotation is not present, it will default to the
The path in which the Kubernetes manifests should be found.
The branch to target when pull requests are opened by Ambassador Cloud to rollout a new version.
The image repository type. Accepted values are
The name of the image repository. This is used by Ambassador Cloud to identify which container to update in the Kubernetes manifests to update with the new image version. Per example, if the container to update's specs contain:
image: datawire/demo-image:1.2.3, the value for the annotation should be
Name of the Kubernetes
Rollout object to update for rollouts.
Coma separated list of Mapping objects that should control rollout traffic.