Armory

Certain functionality, such as trigger nodes and the ability to redeploy an old version, are only available on the pipeline graph. With this change these features are available when deploying to a single target.

Use already connected clusters to set up deployments for your new applications using the wizard. Earlier, using the wizard to set up new applications forced you to install a new Remote Network Agent (RNA), which was not ideal if you already had your cluster connected, leaving you with the option of creating a new deployment file using our docs. CD-as-a-Service enables you to select an already connected cluster when setting up a new application via the wizard and easily onboard new applications. Additionally, we have streamlined RNA installation experience, making it easier to choose between various installation options. The updated RNA install experience is currently live within CD-as-a-Service setup.

The Armory CLI now returns exit code 3 when there is an ongoing deployment. CD-as-a-Service allows only 1 deployment to be in progress for an application. Previously, the Armory CLI would print an error message for ongoing deployments, but would return with an exit code 0. This made it harder to determine if the deployment was successfully started or rejected because one was already in progress. We have improved the behavior, as well as improved the error message formatting.

Historically Armory CD-as-a-Service has managed replica sets when deploying a Deployment object, and once deployment was complete there was no Deployment object in cluster. With this change we can now deploy the deployment object as well so that existing runbooks (e.g. restarting a deployment object) can be run on it if desired.

To enable this functionality

Add the following configuration block to your application's deploy.yml:

deploymentConfig:
  keepDeploymentObject: true

Known issues (All are Fixed):

(fixed Jul 14) When starting a deployment, you will receive the following warning, that you can safely ignore. A fix for this warning is expected soon:

YAML is NOT valid. See the following errors:

#PipelineRequest.deploymentConfig: field not allowed: keepDeploymentObject

Easily view the Kubernetes manifests deployed using CD-as-a-Service from within the UI. Previously, understanding which manifests were deployed in a deployment required tracking down the manifest files in your source control repository. However, now you can conveniently access and review the manifests directly within the CD-as-a-Service UI. This feature simplifies the process of identifying potential issues with Kubernetes manifests that may not meet your expectations.

To view the Kubernetes resource manifests, simply click on the "View Deployment Config" link on the deployment graph page. Then, select the "Kubernetes Manifests" tab to access and review the manifests.

You can now sign up and log in for CD-as-a-Service using your Google or GitHub credentials. With our latest update, it's easier than ever to create an account or log in. Simply click on the "Login with Google" or "Login with GitHub" buttons, and you're all set! No more manual data entry required.

For users who have previously created an account using a username and password, you can now use the social sign-on option to access your existing account.

Note: If you are using an external Identity Provider (e.g., Okta, Google Workspace), please ensure that you use your accounts configured with the external Identity Providers.

Several new armory-provided context variables are now available for use in your web-hooks and automated canary analysis configuration.

{{ armory.namespace }} - this variable will inject the namespace to which a target is deploying.

{{ armory.accountName }} - this variable will inject the name of the account to which a target is deploying.

{{ armory.environmentName }} - this variable will inject the name of the target to which you are deploying.

{{ armory.applicationName }} - this variable will inject the name of the application that you are deploying.

These configuration variables can be useful when passing this information into a web-hook to simplify web-hook configuration for certain use-cases by reducing the need for custom context variables.

When defining a webhook, it can now pass the URL of any services exposed using the expose service step to the webhook. This can be used to run automated tests against the exposed service. ([more info](${{ github.event.client_payload.callbackUri }}))

Here is an example that passes the exposed url for the service 'potato-facts-internal' into a github actions workflow:

  - bodyTemplate:
      inline: |-
        { "event_type": "checkLogs", "client_payload": {
            "callbackUri": "{{armory.callbackUri}}/callback", "service":"{{	armory.preview.potato-facts-internal}}"
            }
        }
    headers:
      - key: Authorization
        value: token {{secrets.github_token}}
      - key: Content-Type
        value: application/json
    method: POST
    name: Integration_Tests
    retryCount: 3
    uriTemplate: https://api.github.com/repos/mycompany/myrepo/dispatches

Getting started with CD-as-a-Service is now easier than ever. The new user's onboarding experience sent them into the configuration page, which was slightly confusing. Users are now taken to a dedicated wizard like setup experience. This allows them to easily deploy the sample application and get started with deploying their own application without having to learn a new YAML structure.

You can now use webhooks asynchronously during deployment. Until now, using webhooks required a callback for the deployment to continue or rollback, which was not ideal for use cases like event streaming. webhooks now has an optional boolean field disableCallback. When you set this field to true, CD-as-a-Service does not wait for the callback to continue deployment.

The following is a sample configuration for defining an asynchronous webhook:

webhooks:
  - name: Sample_Integration_tests
    method: POST
    disableCallback: true
    uriTemplate: https://api.cloud.armory.io/sandbox/webhoo
    headers:
      - key: Content-Type
        value: application/json
    bodyTemplate:
      inline: >-
        {
          "callbackUri": "{{armory.callbackUri}}/callback",
          "success": true
        }
    retryCount: 3

strategies:
  canary-20:
    canary:
      steps:
        - setWeight:
            weight: 20
        - runWebhook:
            name: Sample_Integration_tests

You can now fetch the Deployment ID and the Deployment URL as outputs from the deployment step of your GitHub Action. You can use these outputs to further simplify your deployment process. Add the Deployment URL as a comment to the relevant PR or the commit. Additionally, if you'd like for the GitHub Action to wait until the deployment is finished, you can pass the waitForDeployment:true flag as an argument to the GitHub Action.

The following snippet uses the outputs from the deployment step and feeds them into the next step:

      - name: Deployment
        id: armory
        uses: armory/cli-deploy-action@main
        with:
          clientId: ${{ secrets.CDAAS_CLIENT_ID }}  
          clientSecret:  ${{ secrets.CDAAS_CLIENT_SECRET }} 
          path-to-file: "/deploy.yml"
          waitForDeployment: false
      - name: echo-ID
        uses: peter-evans/commit-comment@v2
        with:
          sha: ${{github.sha}}
          body: |
            Deployment URL - ${{steps.armory.outputs.LINK}}
            Deployment ID - ${{steps.armory.outputs.DEPLOYMENT_ID}}

You can now restrict which roles can issue manual approvals during the course of deployment. This helps you ensure that only authorized people are promoting changes to Production, and application owners are interacting with their own applications. To restrict approvals, you need to add a requiresRoles field in the manual approval step and list the roles that can issue approvals. Organization Admins and respective tenant's Admins can issue approvals, even if those roles are not included in the requiresRoles field.
Users without the required role will have the approval functionality disabled and will see a message on which roles can issue approvals. More detailed documentation is in progress and will soon be up on our docs site.

targets:
  prod:
    account: demo-prod-cluster
    namespace: application-1
    strategy: canary-20
    constraints:
      beforeDeployment:
        - pause:
            untilApproved: true
            requiresRoles: ["Production Owner"]
strategies:
  canary-20:
    canary:
      steps:
        - setWeight:
            weight: 20
        - pause:
            untilApproved: true
            requiresRoles: ["sample-application-owners"]

Issue manual approvals from the Environment graph page without having to dive into the environment. Additionally, accessing the detailed environment view is now easier and needs a single click. That means, you can easily reach environment details to dive into details, and issue approvals easily if everything is progressing smoothly.

The Remote Network Agent (RNA) has been updated to run on ARM containers in addition to x86 containers. Additionally the RNA has been updated such that it should use fewer resources, especially when idle. Note, these changes shipped in version 3.x of the RNA, please see the recent Breaking change notice for upgrade caveats if you are using a proxy with your RNA.

To simplify trying out CD-as-a-Service, we have added the ability to create Armory provided sandbox Kubernetes clusters so that you can deploy the sample application and experience canary deployment without having to install CD-as-a-Service on your own local cluster. Armory provided clusters live for upto 2 hours.

Additionally, we have also added an alternative method to install RNA which does not require you to have helm. Should you choose to use Helm to install the RNA, the option is still available in our docs.

We added the capability to create and update roles in CLI version 0.37.1. As we continue to improve the experience around creating roles, an upcoming change will require you to have a CLI version greater than 0.37.1 to be able to create and update roles. The change is expected to release on 10/04/2022.

It is now possible to create roles and assign users to those roles. You can now restrict access to configuration tab - secrets, privilege to invite new users, integrations within the CD-as-a-Service portal. Creating roles can be done by creating an armory config file as shown below. Documentation for the feature is still in progress, but you can use the syntax shown here to create new roles.

roles:
    - name: Potato Facts Role
      tenant: main
      grants:
        - type: api
          resource: deployment
          permission: full
  - name: Potato Lies Role
    tenant: main
    grants:
      - type: api
        resource: organization
        permission: full

The file can live in your source control and be applied to armory by using the armory CLI command armory config apply -f config.yaml

Users can be assigned roles when they are being invited, or can be assigned new roles from the Users tab. Only admin users can view the Configuration tab in the CD-as-a-Service UI.

Users signing in with SSO will get the permissions of any roles that have the same name as one of their groups.

On the configuration home page it is now possible to chat with us if you are running into challenges during your free trial. WE'd love to help make you successful!

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 supports autoscaling after the deployment to your environment finishes.

CD-as-a-Service now allows you to configure a timeout for your deployment. By default, if pods for your application fail to be in ready state in 30 minutes, the deployment times out and rolls back. You can now configure this timeout if your pods take longer to start, or if you want deployments to timeout and rollback faster.

To configure the timeout, you can add the following as a top level block in your CD-as-a-Service deployment yaml.

deploymentConfig:
  timeout:
    unit: minutes
    duration: 1

When a webhook fails its execution, you can see the HTTP response body returned by the webhook as well as the error message in the environment deployment screen.

Historically CD-as-a-Service, like many other deployment systems, has only been able to route traffic for a single object of Kind deployment when deploying using a canary or blue/green strategy. With this change, you can now have 1 or more Deployment objects, and they will be deployed together. This allows you to deploy multiple tightly coupled services together, and roll them all back if an issue is uncovered.

Historically unless the deployment object being deployed contained changes, CD-as-a-Service completed an environments deployment instantly, and did not create a new ReplicaSet. Now all changes will follow the deployment strategy. 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.

There is now a script that can more easily install the CLI. Simply click 'Install CLI' on the user dropdown to get started.

There is now a wizard that can more easily install the RNA. Simply click 'Add Agent' on the Agents screen to get started.

The cli now supports an additional command line argument that adds context variables to web-hook and canary analysis steps in a deployment field.

example usage:

armory deploy start -f deploy-webhook.yml --add-context=pr=myprnumber

this will add a new context variable named 'pr' with the value 'myprnumber' to all canary and webhook triggers.

This can also be passed from the github action using the following syntax:

addContext: "pr=myprnumber", or to ad multiple: addContext: "pr=myprnumber,changeby=myname"

Here is a full exampleGHA config using the new option:

name: Deploy my latest version

on: 
  push: # What triggers a deployment. For example, `push`.
    branches:
      - main # What branch triggers a deployment. For example, `main`.   

jobs:
  build:
    name: deploy from main
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Deployment
        uses: armory/cli-deploy-action@main
        with:
          clientId: "${{ secrets.BOREALIS_CREDENTIAL_ID }}"  # "61ihoLa6dkk5SRwAy232H0TJk1xTBbK6"
          clientSecret:  "${{ secrets.BOREALIS_CREDENTIAL_SECRET }}" #Client secret that you created in the Armory Cloud Console that has been encrypted with GitHub's encrypted secrets.
          path-to-file: "/deploy-webhook.yml" # Path to the deployment file. For more information, see the Create a deployment file section.
          addContext: "environment2=prod,pr=test"
          applicationName: "potato-facts4sa" # yes?

Known Issues:

Context will not currently be added to triggers in the following situations:

1. An 'analysis' step when used in an after deployment constraint

2. A step in a blue/green deployment strategy.

When triggering a webhook from your deployment, you can now reference a secret from within it. To do this type {{secret.secretName}} where secretName is the name given to the secret when creating it through the ui. You should use secrets to store credentials used by webhooks to ensure they are neither visible to users nor logged. Here is an example of how to trigger a GitHub action that uses a secret for authentication:

  - name: Run_Security_Scanners
    method: POST
    uriTemplate: https://api.github.com/repos/myorgname/myreponame/dispatches
    networkMode: direct
    headers:
      - key: Authorization
        value: token {{secrets.github_token}}
      - key: Content-Type
        value: application/json
    bodyTemplate:
      inline:  >-
        {
        "event_type": "Run_Security_Scanners",
        "client_payload": {
            "callbackUri": "{{armory.callbackUri}}/callback"
            }
        }
    retryCount: 3

You can now run integration tests and security scanners after an environment finishes deployment using an AfterDeployment constraint. If the tests fails, any environments that depend on the one being tested will not be deployed. Documentation is still in progress, but here is the syntax:

targets:
  staging:
    account: demo-staging-cluster
    namespace: borealis-staging
    strategy: rolling
    constraints:
      #after deployment constraints are useful for running automated tests in a deployed staging environment before deploying to production.
      afterDeployment:
        - runWebhook:
            name: Run_Integration_Tests
            context:
              environment: staging

Note: leveraging an automated canary analysis step within an afterDeployment constraint is not yet supported.

It is now possible to leverage a Web-hook within a before deployment constraint and a blue/green strategy (in addition to a canary strategy). We are still working to document this functionality, but in the meantime, more information is in the prior feature notes on using web-hooks in a canary strategy.

Example syntax for using web-hook from within a before deployment constraints:

    constraints:
      dependsOn: ["infosec","staging"]
      beforeDeployment:
      - pause:
          untilApproved: true
      - runWebhook:
          name: myWebhookwcontext
          context:
            environment: production

Example syntax for using web-hooks from within a blue/green deployment strategy:

strategies:
  myBlueGreen:
    blueGreen:
      activeService: potato-facts-external
      previewService: potato-facts-preview
      redirectTrafficAfter:
        - analysis:
            interval: 7
            units: seconds
            numberOfJudgmentRuns: 1
            rollBackMode: manual
            rollForwardMode: automatic
            queries:
              - avgCPUUsage-pass
        - runWebhook:
            name: myWebhook

Known issues:

web-hook name does not show up properly in a before deployment constraint yet

Fixed an issue where the Spinnaker plugin would intermittently fail to retrieve an authentication token when starting a deployment using the new aurora stages.

Added a new 'Borealis Progressive Deployments YAML' stage that can deploy using the same YAML as the Project Borealis CLI . This enables the Project Aurora stage to leverage all Borealis features even if they have not been added to the Spinnaker stage configuration UI.

Known Issues

You can only deploy to a single environment using the new 'Borealis Progressive Deployments YAML' stage

Fixes and improvements

• Fixed the known issue where when using a deployment constraint of type beforeDeployment, you also had to provide a 'dependsOn' constraint.

Add flag that allows for setting application name outside of deployment yaml. If you specify the --application argument when starting a deployment, you can now override the name of the application that is specified in the deploy.yml. This can be useful if you have a single deploy.yml that is otherwise applicable to multiple applications.

Add Status UI URL - The Kubernetes Progressive stage in Armory Enterprise (Spinnaker™) now displays a link to an alternate UI for deployments it initiates. This UI exists outside of Armory Enterprise and is part of Armory Cloud. The UI shows any deployments triggered from the stage as well as ones that are triggered outside of Spinnaker using Project Borealis. To use the Status UI, you must have been invited to the Armory Cloud Console and have an account.

Argo Rollouts is no longer required for the plugin. (CLOUD-862)

You can now deploy manifests that contain multiple Kubernetes resources. Note that this does not include support for deploying manifests that contain multiple Deployment resources. (CLOUD-884)

The Borealis CLI now supports the following commands:

• login - Log in using your cloud console user credentials.

• logout - Log out of Armory Cloud.

• armory template kubernetes canary - Generate a YAML template for a manual canary deployment to Kubernetes.

• deploy start - Start a deployment from a deployment definition YAML file.

• deploy status - Retrieve the status of a deployment.

CLI now supports authenticating with machine credentials.