Continuous Deployment-as-a-Service, Continuous Update | September 2022

Sep 12, 2022 by Stephen Atwell

Introduction:

This summer we launched Continuous Deployment-as-a-Service, and we’re starting this blog to keep you up to date on all of the updates and news around this solution. At Armory, we want to make sure you have all of the tools you need to be successful when deploying your code. Armory will handle your Continuous Deployment so you can focus on what you do best – providing innovation and the best possible customer experience to your customers.

Below, you’ll find the latest CD-as-a-Service news: our latest updates, upcoming events, and what we’re working on next. Haven’t tried out CD-as-a-Service yet? Click here to get started, it’s free!

New Releases & Enhancements:

Allocate Resources Efficiently with Support for Horizontal Pod Autoscalers (HPA): CD-as-a-Service adds support for a Horizontal Pod Autoscaler (HPA) during deployments. You configure the HPA(s) in your application’s manifest file. CD-as-a-Service deploys any HPA tied to a Kubernetes Deployment object and enables autoscaling after the deployment to your environment finishes.
Save time with Redeploying a Replicaset on any change: Many deployment solutions only apply the deployment logic for certain changes, such as a change in the application image version. Other changes, such as changes to configuration maps may not follow the same strategy and validation. CD-as-a-Service now follows the same deployment strategy for any change, to any Kubernetes object, ensuring all changes are validated and applied safely. This means, for example, that when deploying just a change to a configuration map, a new ReplicaSet will be created, and validated, just like any other change.
Speed up your deployments with Support for Traffic Management with Service Mesh Interface (SMI): It is now possible to have fine-grained traffic management during canary deployments using Service Mesh Interface (SMI). This should allow you to send as little as 1% of traffic to the canary version of your application to verify the impact of a change. Here is the link for the documentation for this new feature as well as a full blog post here!
Increase Reliability and save time withAutomated Webhook-based Approvals: We knew it was important to enable users to easily hook their existing automated process into the Armory Deployments pipeline. Specifically, we had three primary use cases in mind:
- For application developers, it enables automatically running their integration tests once the staging environment deploys, and only requires updates to the production environment if the integration tests pass.
- For an application test suite, there is a selenium test that checks basic functionality of your application that you can run during canary deployment as traffic increases, and rollback in the event of failure..
- InfoSec engineers can run security scanners against applications in a staging environment, and only promote application changes to production if the scanner detects no new issues.

Horizontal Pod Autoscaler: (Read the HPA blog here!)

Problem: Deployment Solutions need to take into account load and current HPA state when deploying in order to ensure maximum uptime and efficient use of resources. Prior to this feature that wasn’t possible. Historically, CD-as-a-service hasn’t supported applications that use a horizontal pod autoscaler. (HPAs are used to dynamically change the amount of resources dedicated to an application based on that application’s current load).

Solution: When deploying CD-as-a-Service now looks at the amount of resources HPA has scaled for your application and makes sure that both the old and new versions are running at that current scale. Now, you can do a Blue/Green Deployment, you have equal allocation to servers when deploying. If your current version needs ten servers, CD-as-a-Service knows the new one will too, and allocates resources accordingly.

Who it Benefits: Infrastructure Operations, Platform Engineers, Site Reliability Engineers, IT Operations

How it works:

Step 1: Before starting a deployment to an environment, CD-as-a-Service takes note of the scale that your application is currently running and maintains this scale until the deployment to the environment is finished.

The Details: Because CD-as-a-Service knows the scale right before the deployment starts, it can alter deployment strategies in a way that does not cause degraded service. For example, when you are using a Blue/Green strategy, the next version of the application is scaled up to meet the current traffic load before traffic is moved over to the new version. Once the traffic is cut over to the new version, your users would not experience interruptions or degraded service. Additionally, this approach ensures reliability and speed when rolling back – your rollbacks don’t have to scale up to support the required traffic.

Step 2: CD-as-a-Service then disables the HPA for your application and executes your deployment strategy.
- The Details: By disabling HPA during the deployment strategy, we can ensure that HPA does not interfere with the strategy. For instance, in case of automated analysis results, if the new version has a memory leak the HPA could scale up and thwart the threshold based queries. Or during pod-ratio canary deployments, HPA could scale down pods and could force more users into the canary version of the application.
Step 3: After successfully deploying the new version of the application, CD-as-a-Service then enables HPA for the new version of the application.
- The Details: CD-as-a-Service deploys every change you make, even changes to the HPA. That means as you refine your HPA configuration to the application’s needs, you can run automated performance tests in staging environments before ever deploying new HPA configurations to production.

Redeploying a Replicaset

Problem: When a Kubernetes resource like configMap or secret is updated, often those changes are not reflected immediately. For these changes to take effect, the relevant pods need to be restarted. This process is usually manual, or there is a homegrown automation that tries to achieve that. More than anything, it forces you to know the intricacies of Kubernetes and know exactly which resources need pod restarts and how can those pods restarted safely without causing interruptions.
Solution: CD-as-a-Service follows the prescribed deployment strategy and deploys a new ReplicaSet anytime there is a deployment. Deploying a new ReplicaSet makes sure that your changes are picked up by the new pods. CD-as-a-Services ensures reliability by executing on the deployment strategy to identify potential issues early on and not causing interruptions for end users.
Who it Benefits: Application Developers, Infrastructure Operations, Platform Engineers, Site Reliability Engineers, IT Operations, and anyone who is not a Kubernetes expert.
How it works: CD-as-a-Service will deploy a new ReplicaSet for any change that occurs in the application, even if the change is one of the Kubernetes resources that is deployed. The deployment will still follow the strategy defined for the environment. For instance, if your prod environment uses Blue/Green strategy to deploy, CD-as-a-Service will use the Blue/Green strategy to deploy a new ReplicaSet and deploy the resource changes. If any automated tests indicate an error, then the deployment can be immediately rolled back.
How to get it: There is no special configuration needed to access this behavior. Anytime you deploy a change, be it a new version of the image or just changing Kubernetes resources, a new ReplicaSet will be spawned so that all the changes are deployed reliably.

Support for Traffic Management with Service Mesh Interface (SMI)

Problem: Historically, doing blue/green or canary deployment has required manually updating routing rules to the newly deployed version. Creating a new stack and updating the routing rules is complicated, error-prone, and complex to automate.

Today, progressive deployments scales up the new version slowly, and routes a percentage of new traffic based on the percentage of pods running the old version and the new version. This requires us to scale down the old version as we scale up the new version, which prevents instantaneous rollback if an issue is discovered.

Solution: Allow traffic to be routed by updating traffic routing rules via any SMI-compliant service mesh, instead of by stopping and starting pods.

Who it Benefits: Platform engineers

How it works: CD-as-a-Service creates a new service for the old and new application version, and creates an SMI rule to route traffic from your specified service to the dynamically created versions with the appropriate traffic split.

Update your deployment configuration to specify the SMI service to route traffic for.

Armory CD-as-a-Service Deployment using SMI Traffic Management

Automated Webhook-based Approvals

Problem: Adopting a new CD tool often means changing your existing test and security automation, or manually triggering it and issuing manual approvals. Ideally, production deployment should only occur once all integration tests pass on the staging environment. Oftentimes, this process of running smoke tests and promoting a deployment to production is manual and time-consuming.
Solution: Webhook based Approvals gives you the agency to automatically trigger existing automation like smoke tests and security scanners, and use the results of those automated tests and processes to decide if a deployment is fit to be rolled back or proceed further in the pipeline.

Who Benefits: Application Developers, Platform Engineers, Performance Engineers, Quality Assurance Engineers, Infosec
How it works: Webhooks can be configured at any point in the deployment’s lifecycle. You can run a webhook before deploying to an environment to trigger a database upgrade. Alternatively, you could use a webhook during deployment to check against your logging service to measure rate of errors, or to run smoke tests.

Within CD-as-a-Service webhooks are simple REST API calls which can be customized. After making an API request, CD-as-a-Service waits for a callback with a success or failure status. If the callback status is successful, the deployment proceeds to the next step. However, if the callback returns failure, then the deployment automatically rolls back and stops deployment to any future environment.
How to get it: Webhooks can be configured in the CD-as-a-Service deployment YAML and can be used within a deployment strategy like canary or Blue/Green or be used as an environment specific constraint to trigger before or after deployment. To get started with webhooks based approvals, check out our docs.
If you are not sure how this benefits you, check out our blog post all about this feature.

Armory in the News

For all things newsworthy, check out the coverage of our new 2.28 product release here:

Hope to see you there – Upcoming Events

We look forward to seeing you at these upcoming webinars and virtual events.

KubeCon + CloudNativeCon North America – October 24-28, Detroit, Registration and Additional Info Here

This is a hybrid event taking place both in person and with a virtual component from October 24-28. Pre-event programming will take place on October 24-25 and the main conference will be on October 26-28. In person AND online content will be showcased over five days, including keynotes, conference sessions across 10+ tracks, tutorials, sponsor booths, and networking opportunities..

On the Horizon:

Enterprise Tier: RBAC – you will be able to control who does what with Armory CD-as-a-Service. Unlike some solutions in the market, it allows you to control not just who can do what, but also who can do what where. For example, who can deploy what applications to which clusters in which namespaces.
Notifications: As an Application Developer, I have no way of knowing when my deployment is ready for me to review it and issue any needed manual approvals to continue scaling. We are adding the ability to subscribe to notifications about your deployment pipeline. Notifications can be sent to slack, or your custom webhook.

Follow us on LinkedIn

Follow us on Twitter Write your code, package your artifacts, declare your application targets, and commit — Armory Continuous Deployment-as-a-Service will take care of the rest. Get started here!

Share this post: