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.
The following annotations are leveraged to make the Rollouts flow possible.
The repository on which to bring changes.
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, for instance
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