Armory Docs – Armory Feature Status

Continuous-Deployment: Armory Continuous Deployment Compatibility Matrix

Mon, 01 Jan 0001 00:00:00 +0000

Compatibility matrix overview

This compatibility matrix details what is supported in the Armory Continuous Deployment 2.36.x release. Compatibility is for all minor versions of a major release version. Note that although Spinnaker™ is part of Armory Continuous Deployment, what open source Spinnaker supports and what Armory Continuous Deployment supports is not a one-to-one relationship.

You can find the compatibility matrix for previous Armory Continuous Deployment releases in the docs version for the release you are using:

See System Requirements for Armory Continuous Deployment for information about the system requirements you need to install Armory Continuous Deployment.

Legend

Feature status describes what state the feature is in and where you should install it. For more information, see Release Definitions. You can also click on the feature status badge directly.

The feature as a whole is generally available. There may be newer extended functionality that is in a different state.

Beta The feature is in Early Access. For more information about using this feature, contact us.

The feature is in Early Access. For more information about using this feature, contact us.

The feature is an Experiment. For more information about using this feature, contact us.

Enterprise availability

The feature or parts of it are available in open source Spinnaker (OSS).

The feature or parts of it are available only as part of Armory Continuous Deployment for Spinnaker.¹

Versions

All supported versions for the Armory Continuous Deployment version refers to the current minor release and the two previous minor releases. For example, if the current version is 2.21.x, all supported versions include 2.19.x, 2.20.x, and 2.21.x. For third-party software, “all supported versions” refers to actively maintained versions by the provider.

Armory Operator

The Armory Operator and Spinnaker Operator provide you with the ability to install, update, and maintain your clusters via a Kubernetes operator.

Feature	Version	Armory Continuous Deployment Version	Notes
Install, update, and maintain Spinnaker clusters	All supported versions	All supported versions
Automatically determine Deck/Gate URL configuration if Ingress objects are defined	1.1.0 or later	1.1.1 or later	Ingress objects must be defined in the same namespace where Spinnaker lives.
Support definition of all Halyard configuration options	All supported versions	All supported versions
In cluster mode, validate configuration before apply	All supported versions	All supported versions	Does not work when installed in “basic” mode. Does not guarantee a valid configuration, but does check for most common misconfigurations.

Note that newer versions of the Armory Operator drop support for older Kubernetes versions. The following table outlines the supported combinations of Kubernetes, the Operator, and Armory Continuous Deployment:

Kubernetes Version	Armory Operator Version	Armory CD Version
< 1.21	<= 1.6.x	<= 2.28.0
>= 1.21	>= 1.7.x	All supported versions

Kubernetes Version	Spinnaker Operator Version	Spinnaker Version
< 1.21	<= 1.2.5	>= 1.27.3
>= 1.21	>= 1.3.x	>= 1.27.3

Consult the Manage Operator guide for how to upgrade your Operator version.

Application metrics for Canary Analysis

Application metrics can be ingested by Kayenta to perform Canary Analysis or Automated Canary Analysis (ACA). For information about how to enable Canary Analysis, see Configure Automated Canary Deployments in Spinnaker.

The following table lists supported app metric providers:

Provider	Version	ACA	Armory Continuous Deployment Version	Note
AWS Cloudwatch	All supported versions	Yes	2.23.1 or later
Datadog	All supported versions	Yes	2.26.0 or later	Beta
Dynatrace	All supported versions	Yes	2.23.0 or later
Graphite	All supported versions	Yes	All supported versions
New Relic	All supported versions	Yes	All supported versions
Prometheus	All supported versions	Yes	All supported versions	Authentication using a bearer token is supported. Armory supports offerings that are proprietary versions of Prometheus, such as Cortex, to the extent that the offering overlaps with open source Prometheus. That is, Armory guarantees functionality that is compatible with open source Prometheus. Compatibility between open source Prometheus and the proprietary version is the responsibility of that vendor, not Armory.
SignalFx	All supported versions	Yes	All supported versions
Stackdriver	All supported versions	Yes	All supported versions

Artifacts

Artifacts are deployable resources.

The following table lists the supported artifact stores:

Provider	Armory Continuous Deployment Version	Notes
Bitbucket	All supported versions
Container registries	All supported versions	Docker Hub, ECR, and GCR
GitHub	All supported versions
Git Repo	All supported versions	GitHub or Bitbucket. Supports using the entire repo as an artifact.
Google Cloud Storage	All supported versions
HTTP	All supported versions
Maven	All supported versions
S3	All supported versions

As code solutions

Pipelines-as-Code

Armory’s Pipelines-as-Code feature provides a way to specify pipeline definitions in source code repos such as GitHub and BitBucket.

The Pipelines-as-Code has two components: 1) a Spinnaker plugin; and 2) a service called Dinghy, which keeps the Spinnaker pipeline in sync with what you define in a dinghyfile in your repo. You can also make a pipeline by composing other pipelines, stages, or tasks and templating certain values.

GitHub is in the process of replacing master as the name of the default base branch. Newly created repos use main. As this transition happens, confirm what branch your repo is using as its base branch and explicitly refer to that branch when configuring Armory features such as Pipelines-as-Code. For more information, see GitHub’s Renaming information.

Version control systems

Feature	Version	Armory CD Version	Spinnaker Version	Notes
BitBucket Cloud		All supported versions	1.26+
BitBucket Server	4.x - 6.x	All supported versions	1.26+	BitBucket Server 7.x is not officially supported due to changes in webhook handling and may not behave as expected.
GitHub		All supported versions	1.26+	Hosted or cloud
GitLab		All supported versions	1.26+	Hosted or cloud

Features

Feature	Armory CD Version	Spinnaker Version	Notes
Fiat service account integration	All supported versions	1.26+
GitHub status notifications	All supported versions	1.26+
Local modules for development	All supported versions	1.26+
Modules	All supported versions 1.26+		Templatize and reuse pipeline snippets across applications and teams
Pull Request Validation	2.21 or later	1.26+
Slack notifications	All supported versions	1.26+
Webhook secret validation	All supported versions	1.26+
Permissions validation on commit	2.30 or later	1.30+

Templating languages

To create a dinghyfile, you can use one of the following templating languages:

HashiCorp Configuration Language (HCL)
JSON
YAML

ARM CLI

The ARM CLI is a tool to render dinghyfiles and modules. Use it to help develop and validate your pipelines locally.

You can find the latest version on Docker Hub.

Terraform Integration

Use Terraform within your pipelines to create your infrastructure as part of your software delivery pipeline. Terraform Integration is a feature in Armory CD and a plugin for Spinnaker. For more information see the Terrafrom Integration docs.

Supported Terraform versions

Not all patch versions are included for each release. Although other Terraform versions may be usable with Spinnaker/Armory CD and Terraform Integration, Armory only supports the versions listed here.

Terraform Versions	Armory CD Version	Spinnaker Version	Notes
0.12, 0.13, 0.14, 0.15, 1.0, 1.1, 1.2, 1.3	2.30	1.30
0.12, 0.13, 0.14, 0.15, 1.0, 1.1, 1.2	2.28	1.28	Version 0.12 was not available in 2.28 but is supported as of release 2.28.1.
0.11, 0.12, 0.13, 0.14, 0.15, 1.0, 1.1, 1.2	2.27	1.27
0.11, 0.12, 0.13, 0.14, 0.15, 1.0	2.26	1.26

Features

The following table lists the Terraform Integration features and their supported versions:

Feature	Armory Continuous Deployment Version	Notes
Base Terraform Integration	All supported versions
Named Profiles with authorization	All supported versions

Support is limited to configuring Terraform Integration and using the stage within Armory Continuous Deployment. Armory’s Customer Care team does not troubleshoot Terraform script issues or infrastructure creation using Terraform. If you have questions, contact your assigned Technical Account Manager and/or Account Executive. Alternatively, you can reach our Customer Care team by visiting the Armory Support Portal to submit a case.

Authentication

The following table lists the supported authentication protocols:

Identity provider	Armory Continuous Deployment Version	Note
None	All supported versions	Armory recommends having Armory Continuous Deployment only accessible through a VPN if this is turned on.
SAML	All supported versions
OAuth 2.0/OIDC	All supported versions	You can use any OAuth 2.0 provider such as Auth0, Azure, GitHub, Google, Okta, OneLogin, or Oracle Cloud.
LDAP/Active Directory	All supported versions
x509	All supported versions

Authorization

The following table lists the supported authorization methods:

Provider	Armory Continuous Deployment Version	Note
None	All supported versions	Armory recommends having Armory Continuous Deployment only accessible through a VPN if this is turned on.
GitHub Teams	All supported versions	Roles from GitHub are mapped to the Teams under a specific GitHub organization.
Google Groups	All supported versions
LDAP/Active Directory	All supported versions
OAuth 2.0/OIDC	All supported versions	Requires the provider to include groups in claims or be a supported third party integration.
SAML	All supported versions

Baking machine images

The following table lists the supported image bakeries:

Provider	Armory Continuous Deployment Version	Notes
AWS	All supported versions
GCE	All supported versions
Packer	All supported versions	The following lists the included Packer versions: Armory 2.23.x through 2.28.x include Packer 1.6.4 Armory 2.30.x and later include Packer 1.8.1

Baking Kubernetes manifests

The following table lists the supported manifest templating engines:

Provider	Armory Continuous Deployment Version	Notes
Helm 2	All supported versions
Helm 3	2.19.x or later
Kustomize	All supported versions	Kustomize version installed is 3.8.6
Kustomize4	2.30.x or later	Kustomize version installed is 4.5.5

Build systems

The following table lists the supported CI systems:

Provider	Version	Armory Continuous Deployment Version	Note
GitHub Actions	n/a	All supported versions	Webhook integration
Jenkins	All supported versions	All supported versions

Custom stages

Armory Continuous Deployment includes custom stages that you can use to extend the capabilities of Armory Continuous Deployment. Some of these stages are available out of the box while others are available as plugins to Armory Continuous Deployment.

Stage	Armory Continuous Deployment Version	Notes
Evaluate Artifacts	2.24.0 and later	Available as a plugin

Deployment targets

Armory Continuous Deployment supports various deployment targets.

Here’s a great chart by Google to help you understand how the different deployment targets are categorized.

Compute as a Service

Provider	Deployment strategies	Armory Continuous Deployment Version	Notes
Amazon AWS EC2	None (always adds a new one) Highlander Red/Back aka Blue/Green Custom (run a custom pipeline) Rolling Blue/Green	All supported versions	AWS Public Cloud only. Armory does not support GovCloud.

Container as a Service Platforms

These are manifest-based providers. Armory Continuous Deployment applies the manifest and leaves the rollout logic to the platform itself.

Provider	Version	Armory Continuous Deployment Version
Kubernetes	1.23 or later	All supported versions
Amazon AWS EKS	All versions	All supported versions
Google GKE	All versions	All supported versions

Provider	Deployment strategies	Armory Continuous Deployment Version	Notes
Amazon AWS ECS	Red/Black aka Blue/Green	All supported versions	AWS Public Cloud only. Armory does not support GovCloud.

Platform as a Service

Provider	Version	Deployment strategies	Armory Continuous Deployment Version	Notes
Google Cloud App Engine		Custom	All supported versions
Cloud Foundry	CC API Version: 2.103.0+ and 3.38.0+	None (always adds a new one) Highlander Red/Back aka Blue/Green Rolling Red/Black Custom (run a custom pipeline)	All supported versions	Support for the Cloud Foundry provider is based on your license agreement with Armory. If you have questions, contact your assigned Technical Account Manager and/or Account Executive. Alternatively, you can reach our Customer Care team at support@armory.io or visit the Help Center to submit a case.

Serverless

You write the function and use Armory Continuous Deployment to manage the rollout of iterative versions. These are usually hosted by Cloud Providers.

Provider	Deployment strategies	Armory Continuous Deployment Version	Notes
Amazon AWS Lambda	Red/Black aka Blue Green Highlander Custom (run a custom pipeline)	All supported versions	AWS Public Cloud only. Armory does not support GovCloud.

Dynamic accounts

Dynamic accounts (external account configurations) allow you to manage account configuration outside of Spinnaker, including secrets.

Note that Armory Continuous Deployment does not support using dynamic account configuration with Spring Cloud Config Server.

Backend provider

The following table lists the supported backends:

Provider	Version	Armory Continuous Deployment Version
Git	All supported versions	All supported versions
S3	n/a	All supported versions
Vault	All supported versions	All supported versions

Supported Spinnaker services

The following table lists the services that support dynamic accounts:

Service	Account types	Note
Clouddriver	Cloud provider, artifact	Automatic configuration refreshing is supported for Cloud Foundry and Kubernetes cloud provider accounts only.
Echo	Pub/Sub
Igor	CI systems, version control

Notifications

The following table lists the supported notification systems:

Provider	Armory Continuous Deployment Version	Notes
Email	All supported versions
GitHub	All supported versions
MS Teams	2.23.2 or later
Slack	All supported versions
PagerDuty	All supported versions

Observability

The following table lists the supported observability providers:

Provider	Version	Armory Continuous Deployment Version	Note
New Relic	All supported versions	All supported versions
Prometheus	All supported versions	All supported versions	Use Grafana for dashboards. Armory supports offerings that are proprietary versions of Prometheus, such as Cortex, to the extent that the offering overlaps with open source Prometheus. That is, Armory guarantees functionality that is compatible with open source Prometheus. Compatibility between open source Prometheus and the proprietary version is the responsibility of that vendor, not Armory.
Datadog	All supported versions	All supported versions

Pipeline triggers

The following table lists the supported pipeline triggers:

Provider	Armory Continuous Deployment Version	Notes
AWS Pub/Sub	All supported versions
Cron	All supported versions
Docker	All supported versions	Docker Registry API v2 required
Git	All supported versions
GitHub Webhook	All supported versions
Google Pub/Sub	All supported versions
Jenkins Job	All supported versions
Manual	All supported versions
Webhook	All supported versions

Secret stores

Note

This section applies to secrets in configuration files, not application secrets.

The following table lists the supported secret stores for referencing secrets in config files securely:

Provider	Armory Continuous Deployment Version	Notes
AWS Secrets Manager	All supported versions
Encrypted GCS Bucket	All supported versions
Encrypted S3 Bucket	All supported versions
Kubernetes secrets	All supported versions	Armory Operator based deployments
Vault	All supported versions	Proprietary feature

Some of Armory Continuous Deployment’s features are proprietary and require a license for use. For more information, see the Terms of Service and Terms & Conditions. ↩︎

Continuous-Deployment: Feature Deprecations & End of Support

Mon, 01 Jan 0001 00:00:00 +0000

Overview

To continually improve the Armory customer experience, we will occasionally deprecate and end support for certain Armory features. We understand these decisions can have very real implications for your business, so we will always be direct and honest with you about why a decision has been made and how it might affect you. Where possible, we will provide migration paths and suggestions for features that solve for the same use cases.

The following clarifies what we mean when a feature is deprecated or reaches end of support:

Deprecated: when a feature enters the end of support cycle and no new development is done except for critical (P0/1) bugs and security CVE fixes specific to the feature.
End of Support: when a feature is no longer available for customer or technical support, including critical (P0/1) bugs and security CVE fixes specific to the feature.

Feature	Deprecated	End of Support	Last compatible Armory CD release
Pipelines as CRD	2021 Aug 01	2021 Nov 01	Not applicable
Halyard	2021 Sept 01	2021 Dec 30	2.26.x

FAQ

How much notice will I receive on Feature Deprecations and End of Support?

Our goal is to deprecate all features for at least 6 months prior to reaching End of Support, and we’ll begin communicating this as soon as a feature is officially deprecated. For features that require significant support to gracefully migrate away from, our goal is to deprecate for at least 12 months to ensure plenty of lead time for adjustments.

A list of feature deprecations and related information is maintained in the deprecations section, and you will be notified by various methods in order to limit any surprises for your teams.

There are situations in which the deprecation timeline may be accelerated due to special circumstances. In all cases, we provide as much advance notification as possible. These situations include but are not limited to the following:

Essential changes, such as those needed to maintain the integrity and stability of the platform for all customers.
When third party software leveraged by Armory is changed or no longer available.
When changes are needed to protect data security and comply with any legal requirements.

How will Armory announce feature deprecations?

To ensure you have ample time to prepare for these planned changes, we’ll communicate in the following ways:

Deprecation section on the Armory Continuous Deployment docs site - Each deprecated feature will be outlined within this Deprecation Policy and Status document. There will also be a separate document that includes a detailed overview of the status, important dates leading up to the deprecation of the feature, what each phase of the deprecation includes, how it impacts you as the customer, and the transition process.
Email Communication - Armory will send a series of emails leading up to the deprecation to ensure that you have taken or have plans to take complete any required actions to ensure a smooth transition. Additionally, any deprecations will be noted in the Armory newsletter.
In-Person Communication - Armory customers who have an assigned Customer Success Manager and/or an Account Executive will receive a direct communication in addition to general email notifications.

Who do I contact with any questions or concerns?

For customers who have an assigned Technical Account Manager and/or Account Executive, these are your first and best resource. For others you can reach our Customer Care team at support@armory.io or visit the Help Center to submit a case.

Continuous-Deployment: Feature Status Definitions

Mon, 01 Jan 0001 00:00:00 +0000

Overview of feature status definitions

Features and plugins that Armory releases have a corresponding status indicating the overall maturity of the feature. This page summarizes those feature status definitions and provides recommendations on where and how you should use them.

Early Access

An Early Access feature is working and installable. However, some functionality is likely to be missing, and a number of known and unknown issues are likely to surface. Armory releases Early Access features to a limited set of technology partners.

Where to install Early Access

Do not install in a production environment! An Early Access release gives you to use a feature sooner and gives Armory a chance to collect feedback on what is working and not working. Early Access is meant for a closed development environment or a learning environment that can be destroyed at any time and rebuilt.

Beta

A Beta feature is working, and installation works. All major known issues have been fixed. Armory is working with customers to test the feature. The feature is close to what Armory expects to ship to users.

Where to install Beta

You could install in a production environment, but proceed with caution and have proper rollbacks ready. If you want to experiment with the feature, Armory recommends using your development, QA, staging, or pre-production environments. A Beta release is meant to give you a chance to set up new features, which makes the transition to a GA release easier. It is also an opportunity to give feedback on any major issues.

GA

All major technical issues have been identified and/or resolved. The feature is available for installation by all customers in the corresponding Armory CD release.

Where to install GA

All environments.