Deployments
Deployments provide the ability to run multiple independent copies of a group of containers within the same environment. This is often useful when deploying an application where the ability to rollback to a previously working copy, or roll forward without causing downtime is desired.
LINKED records can be pointed at a deployment tag and a container identifier to ensure a url always points to a specific container of for example, a production deployment.
How Deployments Work
There are two pieces to deployments: versions and tags.
Versions
A version string is set on a container, and tags are managed on the environment. When a container has a version set, it implicitly creates a deployment within that environment. All containers sharing the same version string are part of the same deployment.
Semantic Versioning
Any version starting with a v will strictly enforce semantic
versioning .
Tags
Deployment tags work similarly to how tags work in git. The environment keeps a mapping of tags -> versions, where the tag could be something like prod, development, ISSUE-123 etc. As the version underneath the tag changes, there is a consistent marker for, i.e., what is currently prod.
LINKED records can be pointed at these tags, so that, for example, dev.cycle.io would always point to the website container in the version under the dev tag.
Zero Downtime with Deployments
Using this system, it's possible to have two running copies of the same application, stack, etc. within an environment. When using LINKED records to point to the deployment tag, the load balancer will return the IP address of the instance pointed at by the tag.
Caution
There is no network isolation between deployments within the environment. The concept of deployments exist purely within a DNS / discovery scope. Containers within the same deployment can communicate via hostname. A container in one deployment is unable to communicate with a container in a different deployment unless a SDN+Deployment hostname or a direct IP is utilized.
Let's take an example of how this would look when releasing an update.
Example
Assume there are two deployments of an application in an environment: v1.0.0, and v2.0.0. Each deployment has a container
with the identifier website.
v1.0.0 is tagged with prod, and v2.0.0 is tagged with dev. We have a LINKED Record, pointing at the website identifier,
and at the deployment tag prod. When a user is visiting the URL, they see the v1.0.0 version of the website.
After testing, it is determined that v2.0.0 is stable, and is ready to go to production. By switching the prod tag from v1.0.0 to v2.0.0,
the load balancer will begin resolving the container. Within a few seconds, people visiting the URL will begin seeing v2.0.0.
If something were to go wrong, the prod tag could be moved back to v1.0.0, effectively rolling back. Since there can be an arbitrary
amount of these deployments within an environment, we call them rainbow deployments.
Addressing Deployment Tags in SDNs
If utilizing SDNs, a container within a specific deployment tag can be referenced using an SDN deployment hostname.
Set Up Deployments on Cycle
See our dedicated, interface-specific documentation for configuring deployments: