Armory logo

Sep

15

New on the deployment graph: Deployment triggers with source context!

CD-as-a-ServiceFeature

Aug

04

Aug 4, 2023
Cover image

Developer Hub is live - central locations for all the CD-as-a-Service resources

CD-as-a-Service
undefined
undefined

You can now access the new developer hub provides a central location for all the resources you need to get started with Armory CD-as-a-Service. The hub includes links to documentation, tutorials and release notes.

Additionally, The documentation for CD-as-a-Service has been revamped with new and updated content to help you get started with Armory CD-as-a-Service. Navigation is now structured to make it easier for you to find the relevant content.

You can access our developer hub at: https://developer.armory.io

You can access our new documentation at: https://developer.armory.io/docs

Apr

07

added ability to redeploy old version, and to view deployment configuration. Also updated login look and feel

CD-as-a-ServiceFeature
undefined
undefined

Redeploy old version (See demo)

It is now possible to easily redeploy any old version, by clicking the 'redeploy this version' button, and choosing which environments you want to redeploy to. This can be used for rolling back days or weeks after a version has been fully deployed to production. This option will not be available for older deployments, but is for all future deployments.

View Configuration (See demo)

It is also now possible to view the configuration of a deployment in the pipeline for easier reference. This is useful for helping new users see how existing deployments are configured. This option will not be available for older deployments, but is for all future deployments.

Sign In

Lastly, the sign-in experience now has an updated look and feel.

Mar

14

Added Ability to Expose an External Preview URL for any Deployed Kubernetes Service

CD-as-a-ServiceFeature
undefined
undefined

We've added support for creating service previews.

Armory can now leverage its remote network agent to expose a preview URL for any Kubernetes service it deploys. CD-as-a-Service can generate a cryptographically secure URL for applications developers. This url can be shared with teammates and stakeholders who need to review the deployed functionality. This enables developers access to deployed services on-demand without a dependency on other teams to set up networking.

See a demo

To enable a preview service for your deployment, add an expose service step to your canary or blue/green strategy:

        - exposeServices: # step name
            services:     # list of services to expose. Service must be included in the manifests being deployed.
            - potato-facts-internal
            - potato-lies-internal
            ttl: # Optional. Sets lifetime of the exposed service preview. After that period service preview automatically expires. Max lifetime cannot exceed 24 hours, Min is 1 minute, default is 5 minutes.
              duration: 30
              unit: MINUTES # SECONDS, MINUTES or HOURS

Jan

14

Can now deploy any Kubernetes Manifest, including CRDs for Operators without needing a deployment object

CD-as-a-ServiceFeature

CD-as-a-Service has historically only supported deploying manifests alongside an object of Kind Deployment. Now, Armory can deploy any set of Kubernetes manifests, not just those with Deployment objects. This enables some new use cases, such as:

  • Armory can deploy CRDs for operators such as Argo Rollouts or CrossPlane. This allows Armory to orchestrate cross-cluster deployments of software that is using an Operator within the cluster.

  • This also allows deploying standalone workloads that are not deployment based, such as CronJobs or StatefulSets using CD-as-a-Service.

You do not need any extra configuration to start with deploying operators and other Kubernetes manifests. Simply specify the paths to your Kubernetes resource in the manifests section of your deploy yaml and deploy using the CLI or GitHub Action.

When deploying manifests that do not contain and Deployment object, the 'Strategy' will be ignored. You can still use beforeDeployment constraint for manual approvals and other actions. When deploying to an operator use web-hooks in an AfterDeployment constraint to add operator-specific logic that waits for the operator to finish processing the updated CRD.

Known Issues:

Objects of Kind 'Custom Resource Definition' must be deployed before objects of the kinds they create.

May '22

06

can now add additional context variables at deploy time.

CD-as-a-ServiceFeature

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.

Apr '22

30

Support for Traffic Management with Service Mesh Interface (SMI)

CD-as-a-ServiceFeature
undefined
undefined

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. In addition to our documentation, here is an example of how to use trafficManagement as part of your canary strategy.

trafficManagement definition

Add trafficManagement as a top level element in the yaml file to define which environments should use traffic management and which Kubernetes service objects to use.

trafficManagement:
  - smi:
      - rootServiceName: potato-facts-cluster-svc # Required. name of the Kubernetes service pointing to the deployment object. 
    targets: ["staging"] # optional. Target environments which should use traffic management. If not provided, then all environments will use traffic management.

Apr '22

25

Webhooks can now reference secrets

CD-as-a-ServiceFeature
undefined
undefined

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

New Constraint Type: AfterDeployment

CD-as-a-ServiceFeature
undefined
undefined

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.

Apr '22

07

Now have support for Webhooks within a Canary Deployment Strategy

CD-as-a-ServiceFeature
undefined
undefined

It is now possible to leverage a Webhook within a canary deployment strategy. It is not yet possible to leverage them anywhere else. We are still working to document this functionality, but in the meantime, below is an example of how to use a webhook to invoke a github action. An example github action it triggers, than then continues the deployment can be found here: https://github.com/armory-io/borealis-demo/blob/main/.github/workflows/webhookCallback.yml.

webhook definition:

add this as a top-level element in the yaml to define named webhooks you can invoke from elsewhere in your deploy.yml


webhooks:

  - name: myWebhook

    method: POST

    uriTemplate: https://api.github.com/repos/armory-io/peacemaker-webhooks-demo/dispatches

    networkMode: direct

    headers:

      - key: Authorization

        value: token ghp_notarealtoken

      - key: Content-Type

        value: application/json

    bodyTemplate:

      inline:  >-

        {

        "event_type": "webhookCallback",

        "client_payload": {

            "callbackUri": "{{armory.callbackUri}}/callback"

            }

        }

Reference a webhook from within a canary strategy:

below is an example of how to reference your webhook from within a canary strategy.

strategies:

  strategy1:

    canary:

      steps:

        - setWeight:

            weight: 25

        - runWebhook:

            name: myWebhook

Note: there is a 24 hour timeout after which the web-hook will automatically fail.

Mar '22

11

Added support for Blue/Green Deployment Strategies

CD-as-a-ServiceFeature
undefined
undefined

Watch the demo to learn more

  • Specify blueGreen as a strategy for environments.

  • Specify redirectTrafficAfter as a set of constraints. This allows you to define constraints that must be fulfilled before the next version of the application starts receiving traffic. For Example, you can require that the next version will not receive traffic before a manual approval has been issued.

  • Specify shutDownOldVersionAfter as a set of constraints. This allows you to define constraints that must be fulfilled before the old version of the application is scaled down.

  • Added a new template for the Blue/Green deployment strategy.

  • Here is a docs guide to get started on how to use Blue/Green deployment strategy

Known Issues

  • View Environment link sometimes does not redirect to a new page. To work around the issue, you can edit the URL in the address bar by deleting console.cloud.armory.io/deployments/

  • Multiple manual approvals in a single constraint currently returns an error. This limits the redirectTrafficAfter and shutDownOldVersionAfter constraints to a single manual approval each.

Jan '22

11

Armory CLI Version 0.13.1

Bug FixCD-as-a-Service

Armory CLI Version 0.13.1

Important note: You must be on AVM v1.0.2 to install this and all later CLI versions.

What's New?

  • Adds support for deploying to multiple environments. Watch the demo to learn more! 

    • Specify dependsOn constraints for environments. This constraint allows you to require that certain environments deploy before other environments when deploying to multiple environments.

    • Specify beforeDeployment constraints for an environment. This constraint allows you to require a manual approval before a particular environment. For example, you can require that a deployment to production cannot start until prior environments, such as testing and staging, have completed.

    • Read more about the new constraints in the deployment file reference.

  • 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.

Known Issues

  • (Fixed in 0-.13.2) When using a deployment constraint of type beforeDeployment, you must also provide a 'dependsOn' constraint. If you do not, the CLI crashes with a segmentation fault when starting the deployment. As a workaround, add a dependsOn constraint that is an empty array. constraints:     dependsOn: []

  • When using a beforeDeployment constraint that is a manual approval, the deployment details on the right panel of the screen doesn't automatically update to show the details of that deployment to that environment when you approve the deployment. To workaround the issue, close and reopen the panel.

Support for deploying to multiple environments.

CD-as-a-ServiceFeature
undefined
undefined
  • Adds support for deploying to multiple environments. Watch the demo to learn more! 

    • Specify dependsOn constraints for environments. This constraint allows you to require that certain environments deploy before other environments when deploying to multiple environments.

    • Specify beforeDeployment constraints for an environment. This constraint allows you to require a manual approval before a particular environment. For example, you can require that a deployment to production cannot start until prior environments, such as testing and staging, have completed.

    • Read more about the new constraints in the deployment file reference.

Known Issues

  • (Fixed in 0.13.2) When using a deployment constraint of type beforeDeployment, you must also provide a 'dependsOn' constraint. If you do not, the CLI crashes with a segmentation fault when starting the deployment. As a workaround, add a dependsOn constraint that is an empty array.

    constraints:

        dependsOn: []

  • When using a beforeDeployment constraint that is a manual approval, the deployment details on the right panel of the screen doesn't automatically update to show the details of that deployment to that environment when you approve the deployment. To workaround the issue, close and reopen the panel.

allow for Overriding application name outside of deployment yaml

CD-as-a-ServiceFeature

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.

Nov '21

13

When upgrading to Spinnaker plugin version 0.25.0 from an earlier version, your existing deployments may be affected

Breaking Change NoticeCD-as-a-Service

Update: v0.29.2 Fixed an issue where the 'Accounts' dropdown was not working when using the latest version of the Remote Network Agent. Please skip from version 0.25.0 to v0.29.2 or later. Upgrade to v0.29.2, or later, before performing the procedure covered here: https://docs.armory.io/armory-enterprise/installation/aurora-install/#migrate-to-the-new-rna.

Because of changes to the plugin, deployments from an earlier version of the plugin are not compatible with version 0.25.0 or later. Existing deployments are affected in the following ways after you upgrade to 0.25.0:

  • Deployments that are currently in progress from an older version of the plugin cannot be continued or rolled back.

  • Application versions deployed by an older version of the plugin will not be removed when a new application version is deployed using version 0.25.0.

  • Previous versions of applications deployed by Project Aurora will not have their old versions terminated when a new version gets deployed.

These changes do not affect how you defined your Spinnaker stage. Once you complete the following steps, you can continue using your existing pipeline.

After upgrading the plugin, do the following for each application that was deployed using an older version of the plugin:

  1. Identify the namespace(s) that contains the old version of your application(s).

  2. Get the rollout for your application.

kubectl -n get rollout

  1. Delete all the rollouts with the —cascade=orphan flag.

kubectl -n delete rollout --cascade=orphan

Note: Deleting the rollout will not delete the underlying Replica Sets.

(Optional) Delete the Replica Sets for your application(s):

kubectl -n   delete rs

(Optional) Delete the Kubernetes deployment for your application(s):

kubectl -n delete deploy

You are now ready for new deployments using Project Aurora and Borealis.

Removed Dependency on Argo Rollouts

CD-as-a-ServiceFeature

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)