Using Get Webhook For Rainbow Deployment
- Difficulty - intermediate
- Time To Complete - 20-30 minutes
- Free Tier Compatible - no
Resources
To complete this tutorial you'll need the following resources available at the time of getting started:
- Server
- Environment
- Hosted DNS Zone
- Image - included below
This repo was originally for the blog post on Github Actions, but will do perfectly for this tutorial.
You'll need to create an Image Source from either this repo using the Dockerfile image source type, or, create an image source of your own that you'd like to use to follow along with this tutorial.
If you're providing your own image source, please make sure the image is meant to be some type of publicly accessible service that serves on bind-all IPv6 and you know which port the server is bound to (internally).
Creating the Deployment
At this point you should have the following resources created:
- Server
- Environment
- DNS Zone (verified)
- Image Source
- And Image
The first thing to do is create a new deployment and then assign that deployment the appropriate tags so we can associate the tags to a linked record.
For this tutorial, we'll use the deploy container form to create our container and deployment in one step. Head the the environment you'd like to use (or new one you've created) and click the Deploy Container button to open the wizard.
After giving the container a name, you can leave everything else as the default settings until you get to Image. In the image section choose Recent Images and then your newly created image from the dropdown.
In the Network section change Public Network to enable and add the port mappings. We want to take advantage of TLS termination at the load balancer, so if your service listens on 80 you'd add the following port mappings 80:80 & 443:80.
At the bottom of the page, enable the deployment using the toggle and enter a version for this deployment.
Only versions starting with the character v will be held to semantic versioning standards.
Once you've filled out the form fields, click Deploy Container.
Tags & Linked Records
For this tutorial, we'll want to create at least 2 tags. I'll be creating a test tag and a current tag.
Adding a tag is simple, use the + button to open the form and then add the tag(s) you'd like to use. The image below shows the process of adding a tag called demotag.
| Create Tag | New Tag Showing on Dashboard |
|---|---|
 |  |
Once you have the tag's in place you can associate a linked record with the tag so that the linked record will always point to the container this tag is present on.
In the image below, I'm creating a record pointing to my website container that follows the tag current.
Before visiting the linked record URL's, start the environment using the Start All button.
Make sure you point another linked record to the secondary tag you've created as well. After thats all configured, visit the URL's to verify that they resolve and all is working as expected.
Adding the Pipeline
Head over to pipelines in the portal and click the Create button at the top of the page. Feel free to name the pipeline whatever you'd like. We'll use the Dynamic type, so that we can use variables.
We will create enough steps to accomplish our task of creating a new deployment and switching traffic to it. If you'd like to add additional steps you can but you'll want to add at least the steps defined in the tutorial.
Create Steps
Click the Editor tab from the horizontal nav and add the stage. I'm calling mine deployment. After naming the stage, select the first step from the dropdown Create And Import Image.
The second step to add in this stage is Create Container. Make sure when filling out the create container step you use the same container name that you did during your original container create. This name is used by the platform to create an identifier and the identifier is what's used by the linked record association. Also fill in the step identifier as we will use a reference to this container later in the pipeline.
For Environment use the Resource type and the variable {{environment}}.
For the Image use the From type to target the image we created and imported in the first step.
Fill in the bottom of the form the same as the first container we created EXCEPT for the deployment version which should use the {{version}} variable (it doesn't have to be named this but will be in the example below).
Deploy Steps
The next step in this pipeline is Start Environment Deployment. This step takes our {{environment}} variable and the {{version}}
The Start Environment Deployment step takes care of starting the deployment containers so we can now move on to updating the first deployment tag to point to the new deployment/container. To do this we'll add a Update Deployment Tag Version step.
There are only 3 fields in this step and we want to use variables for each one of them. For Environment use the Resource type with {{environment}}. Using the same variable here as before allows us to make sure that the same environment is used across all places this variable is set. The Tag field should be set to a variable, I used {{test-tag}} and the New Version field to {{version}} again aligning version around the variable {{version}}.
After the deployment tag version is updated, we'll add a Sleep step. This step will give the container a few moments to get up and running as well as eliminate the chance that the next step (Get Webhook) will hit the wrong resource. Set this step to 30s.
With the new deployment started and the first tag set to be moved, we want to be sure the container comes online and is able to respond to a request before moving our current tag to it. The next step we'll use will let us verify this. Create a Get Webhook step. For the URL field, set the URL to the URL of the linked record you associated with the test tag in the earlier step. Open the Advanced Options section and check the boxes next to Retry On and Not in the second row. Then enter the HTTP code 200 in the codes array.
This setting will tell Cycle, please retry this get webhook on any code that is not 200 from the URL.
Set the Interval to 20s (twenty seconds) and Max Attempts to 5. This will give Cycle additional parameters to use when retrying the call.
Updating The Final Tags
At this point we've verified that the new deployment is responding to the HTTP calls the way we expect and we're ready to move over the current tag. However, we also want to keep the previous deployment around in case we need to roll back. Let's take a look at how we can finish this up.
Add a new step Update Deployment Tag Version. Here the environment is the same one we've been using throughout this tutorial. In the deployment section we'll set up two tags, the Existing Tag and the New Tag. We know from earlier in the guide that there is one existing tag named current. We can use this existing tag to target the deployment that already exists. Enter the value current in the Existing Tag field. For the New Tag field enter the tag previous. What we're able to accomplish here is tagging the existing deployment so that we always have the previous deployment around in case we need to role back. This will also allow us to later use the prune functionality on this environment cleaning up any untagged deployments.
Next we'll add another Update Deployment Tag Version step. The environment here is again the same. The Deployment Type needs to be set to Version which will change the field next to it to Existing Version. Because we've already deployed the new version we can target the {{version}} pipeline variable here. The next field New Tag will be current.
Now we have 2 existing deployments, one deployment marked previous which represents the previously deployed code and one deployment marked current which represents the newest code. This is a great pattern because its now possible to roll back to the previous deployment by simply updating the tag.
Cleanup Steps
Cleanup is just one step Prune Environment Deployments. This step will prune all deployments (and their containers) for any deployment that does not have any tag assigned to it.
For the single field on this form use the Resource type and again use the {{environment}} variable.
Remember to use the Save Pipeline button at the bottom of the screen to save all your step and stage changes.
Changing the Website
Before we fire off this pipeline we want to make a change to the website itself. If you're using the resource provided by this tutorial, all you'll need to do is change one of the text lines in the /src/App.js file to something else and commit that change.
Triggering the Pipeline
Head back to the pipeline you just created. In the top right corner of the screen there is a button Trigger Pipeline, next to the button is a V, click there and fill in the variables with the correct values.
If you've never used the resource identifiers before, the {{environment}} variable needs the format env:identifier or environment:identifier. If you don't have the environment identifier, just go to the environment's settings page and copy it.
Example Values:
Deployment Complete
After firing the pipeline, your changes will be live within the next few minutes.
If you want to see some of the jobs in action, head over to the environment > deployments page and you'll see the container being created, as well as the first and second tag updating. As soon as that second tag is updated your site will be rendering the new changes you've made.