Reliable and Automatic Multi-Target Deployments

Multi-target deployments can feel tedious as you deploy the same code over and over to multiple clouds and environments — and none of them in the same way. With an automatic multi-target deployment tool, on the other hand, you do the work once and deliver your code everywhere it needs to be.

Armory provides an easy-to-use tool for DevOps and release engineers to gain safe, reliable, and automatic multi-target deployments. This article discusses how Armory (the next evolution of Spinnaker) helps streamline your pipeline with integrations and automation.

What Is a Multi-Target Deployment?

A target is a destination where developers apply configuration or run code after completing a delivery process. An example of a target is a staging or a production environment in a particular region.

A multi-target deployment may be a multi-cloud deployment, which deploys the same application across multiple cloud vendors, or deployment into different environments within a single cloud. Or, it may be a combination of multi-cloud and multi-environment.

Multi-target deployment may involve different ways to run the same application. In some cases, developers must deploy a single application to bare metal servers, VMs, and containers. They might also have multiple sub-targets. This dramatically increases the complexity of deployment and warrants the need for a platform to manage multi-target deployment more effectively.

Enter Armory and Spinnaker

Armory equips developers like you with the tools to automate multi-target deployments, allowing companies to innovate faster, ship better software faster, and exploit the benefits of multi-target deployment more effectively.

Armory Enterprise is a tested reliable deployment product that has open source Spinnaker at its core. Spinnaker is one of the fastest-growing continuous delivery tools for deploying safely and continuously to cloud platforms like AWS, EKS, GCP, Kubernetes, and Azure, to name a few.

How Does Armory Achieve This?

Armory and Spinnaker combine to support a wide range of cloud deployment environments from these cloud providers:

• Google App Engine
• Amazon Web Services
• Microsoft Azure
• Google Compute Engine
• Cloud Foundry
• Kubernetes
• Oracle Cloud

Registering and configuring a cloud provider is the first step and is central to everything done within Armory. Here, developers define a server group, which is a single deployable artifact within Armory and a collection of instances of the running software. This includes EC2 instances, VM instances, and Kubernetes pods. The server group contains basic configuration settings about the application, such as the number of instances and scaling policies.

Once registered and fully configured with the cloud provider, you can create pipelines based on strategies. Pipelines are the main deployment components and are crucial to defining the deployment strategies. These pipelines are a sequence of stages used to represent a deployment workflow.

You can start pipelines manually or trigger them throughout the software development process by automatically activating events such as pushing code to GitHub, a successful build by Jenkins, a new Docker image hitting the registry, or completing a stage in another pipeline. You can configure these pipelines to emit notifications by email, Slack, HipChat, or SMS at various points during pipeline execution, such as pipeline start, completion, or failure.

You can use Armory Enterprise as a single point to orchestrate deployments to multiple targets across multiple cloud providers. This way, you don’t have to manage environments separately. This exponentially reduces the complexity often experienced with multi-target deployment.

Configuring Artifacts

An artifact is a remote deployable resource or an object that references an external resource. The external resource could be any of the following:

• A code repository like GitHub: You can configure Armory to listen to code changes and activate a pipeline every time code is committed to the repository. Armory can pull the latest build and deploy it to a target environment.
• An artifact repository like Amazon S3: A stage can directly read data from this repository.
• A container registry, such as Docker Hub: Here, you must deploy software as a Docker image.

You can easily integrate these with Armory after registering the target cloud providers. You can configure Armory to listen to events to trigger pipelines and collect artifacts produced by builds in continuous external integration (CI) systems.

You can also fetch these artifacts using a URI. Artifact stores often store parameterized artifacts, and each environment needs to fill in different environment-specific parameters in the configuration. Armory provides an image bakery that can take the generic artifact, fill in needed parameters, and produce machine images.

Working With Pipelines

Pipelines are the critical workflow constructs used to manage deployments. They control how to deploy our application. A pipeline is a sequence of stages that you can combine in many ways to precisely define the functions for managing deployments. This makes pipelines flexible, consistent, and repeatable.

As mentioned before, when creating a new pipeline for a selected application, you must add stages to specify the actions that the pipeline performs. These stages break the pipeline into small, customizable blocks, each one of which serves a specific task. You link the blocks together to represent the whole continuous delivery process.

Types of Stages

You can add any number of stages to the pipeline and in any order needed to suit your business’s needs. These stages fall into four broad categories.

Infrastructure

The stages operate on the underlying cloud infrastructure, and you configure them for every cloud provider to which you deploy. They are responsible for creating, updating, or deleting resources. This provides an efficient and consistent way to deploy to multiple targets and provides a seamless experience. This applies to creating AMIs or Docker images that you can bake, tag, and associate with a specific server group.

External Systems Integrations

Armory can interact with CI systems and provides integrations to enable users to chain together logic performed on external systems other than Spinnaker. You can trigger pipelines with Jenkins or Travis CI. The Jenkins stage enables you to reuse existing functionality when migrating from Jenkins to Armory.

<testing< h4=””>
</testing<>

You can use testing stages to uncover issues related to fallback, latency, load limit, and performance degradation. You can also run functional tests using Jenkins.

Flow Control

With these stages, users can control the pipeline’s flow by making customizations that enable performing conditional logic. This allows human interaction for acknowledgment purposes, waiting for a specified amount of time, and the nesting of pipelines. This means you can run another pipeline from within the current pipeline.

Triggers

When working with pipelines, it’s essential to know how to start them. As mentioned earlier, you can start them manually or automatically using triggers. A pipeline can react to time-based triggers, which can be manual or a cron job. You can run manual triggers as needed or base cron triggers on the scheduling capabilities of cron jobs.

However, most of the time, you would want to start a pipeline based on events caused by other resources. These are known as event-based triggers. Some examples of event-based triggers are commits made to a Git repository, changes in a Google Cloud Storage bucket, or after a Jenkins job completes successfully.

You can also trigger pipelines programmatically by subscribing and listening to a pub/sub topic and pushing messages to the configured topic. To broadcast the status of these pipelines, Armory enables us to configure notifications for pipeline start, success, and failure.

Expressions

Expressions give you a more advanced way to customize the pipeline further and provide more control by exposing the raw pipeline JSON. You can make decisions based on parameters passed into the pipeline or data coming from a trigger. You can set and access the values during the execution of the pipeline.

This is useful when deploying to multiple targets based on certain conditions so that you don’t build custom stages or extend existing ones to cover different cases.

Rollout Strategies

The last step of a pipeline is a rollout strategy which Armory provides out-of-the-box. Armory supports the red/black, rolling red/black, and canary strategies. You can use these strategies with providers such as Amazon EC2, Google Compute Engine, and Kubernetes.

Using Automated Canary Analysis

This is a deployment process in which you partially roll out a change and use the current deployment as a baseline to evaluate the quality of the new deployment. You can assess the quality using key metrics chosen when configuring the canary. Using these metrics in Armory enables you to ensure the releases are safe and reliable.

Deploying to Multiple Kubernetes Environments

In addition to Armory Enterprise, Armory has a standalone SaaS offering for deploying to Kubernetes environments distributed across multiple clusters and clouds. This offering, called Project Borealis, offers a simple declarative way to specify the requirements for how code moves between environments, for example, you can simply state that staging must be deployed before production, and/or that an approval must happen before deploying to production. Borealis enables the most common deployment strategies, blue-green deployments, and canary deployments. All strategies can leverage automated canary analysis to ensure the health of the deployment.

Borealis is configured via a yaml file that lives in your source control alongside your application. It is invoked via a GitHub action, or a command line tool that can be used as a drop-in replacement for kubectl. This makes it easy to start leveraging advanced allocation strategies from your existing tools, whether it’s Jenkins, GitHub actions, or custom shell scripts.

Borealis is currently seeking design partners for its early access program. Spots are limited so if you are interested in helping shape our SaaS offering for continuous deployment, let us know today.

Summary

With Armory, companies can target multiple environments and cloud providers and seamlessly deploy them from a single user interface while following industry best practices. This is very important for rapid deployment since no time is spent customizing each environment.

You can adopt Armory to enable your business to move to the cloud quickly. Or, if you’re already working in the cloud, Armory can help you be more effective and take full advantage of the benefits of cloud computing.