diff --git a/config.toml b/config.toml index da82c005d0..ead50cea06 100644 --- a/config.toml +++ b/config.toml @@ -120,7 +120,7 @@ weight = 1 [[menu.main]] name = "CD-as-a-Service" weight = 2 - url = "/cd-as-a-service/" + url = "https://developer.armory.io/" [[menu.main]] name = "Armory CD" @@ -176,8 +176,7 @@ privacy_policy = "https://www.armory.io/privacy-policy/" terms_of_service = "https://www.armory.io/terms-of-service/" terms_and_conditions = "https://www.armory.io/terms-and-conditions/" -# Display the Armory CDaaS NDA banner -cdaas_banner = false + # First one is picked as the Twitter card image if not set on page. # images = ["images/project-illustration.png"] diff --git a/content/en/_index.html b/content/en/_index.html index 3788c57536..5722335a7d 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -29,7 +29,7 @@

Declarative deployments with the GitOps experience you love

- }}"> + View Documentation diff --git a/content/en/cd-as-a-service/_index.md b/content/en/cd-as-a-service/_index.md deleted file mode 100755 index 4613332e5a..0000000000 --- a/content/en/cd-as-a-service/_index.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Armory Continuous Deployment-as-a-Service -linkTitle: Armory CD-as-a-Service -no_list: true -description: > - Armory CD-as-a-Service is a single control plane that enables deployment to multiple Kubernetes clusters using CD-as-a-Service's secure, one-way Kubernetes agents. These agents facilitate multi-cluster orchestration and advanced deployment strategies, such as canary and blue/green, for your apps. ---- - -## Overview of Armory CD-as-a-Service - -Armory CD-as-a-Service delivers intelligent deployment-as-a-service that supports advanced deployment strategies so developers can focus on building great code rather than deploying it. By automating code deployment across all of your Kubernetes environments, Armory CD-as-a-Service removes demands on developers and reduces the risk of service disruptions due to change failures. It does this by seamlessly integrating pre-production verification tasks with advanced production deployment strategies. This mitigates risks by providing deployment flexibility while limiting blast radius, which leads to a better customer experience. Best of all, Armory CD-as-a-Service doesn’t require migrating to a new deployment platform. It easily plugs into any existing SDLC. - -{{< figure src="/images/cdaas/cdaas-arch.png" alt="CD-as-a-Service High-Level Architecture" height="75%" width="75%" >}} - -See the [Key Components]({{< ref "cd-as-a-service/concepts/architecture/key-components" >}}) section for details. The [Armory CD-as-a-Service (CDaaS) product page](https://www.armory.io/products/continuous-deployment-as-a-service/) contains a full list of features and pricing. - - -{{< cardpane >}} - -{{% card header="Get Started" %}} -[Quickstart]({{< ref "cd-as-a-service/setup/quickstart" >}})
-[Deploy Your Own App]({{< ref "cd-as-a-service/setup/deploy-your-app" >}})
-[Deploy Using GitHub Action]({{< ref "cd-as-a-service/setup/gh-action" >}})
-[Install a Remote Network Agent]({{< ref "cd-as-a-service/tasks/networking/install-agent.md" >}})
-{{% /card %}} - -{{% card header="Learn About CD-as-a-Service" %}} -[Key Components]({{< ref "cd-as-a-service/concepts/architecture/key-components.md" >}})
-[Orgs, Tenants, and Users]({{< ref "cd-as-a-service/concepts/architecture/orgs-tenants.md" >}})
-[RBAC]({{< ref "cd-as-a-service/concepts/iam/rbac.md" >}})
- -{{% /card %}} - -{{% card header="Set Up Your Organization" %}} -[Add Tenants]({{< ref "cd-as-a-service/tasks/tenants/add-tenants.md" >}})
-[Create Roles]({{< ref "cd-as-a-service/tasks/iam/create-role.md" >}})
-[Invite Users]({{< ref "cd-as-a-service/tasks/iam/invite-users.md" >}})
-{{% /card %}} - -{{< /cardpane >}} - -{{< cardpane >}} -{{% card header="Strategies" %}} -[Blue/Green Deployment]({{< ref "cd-as-a-service/setup/blue-green" >}})
-[Canary Analysis]({{< ref "cd-as-a-service/setup/canary" >}})
-[Query Reference Guide]({{< ref "cd-as-a-service/reference/ref-queries.md" >}})
-[Integrate a Metrics Provider]({{< ref "cd-as-a-service/tasks/canary/add-integrations" >}})
-[Construct Retrospective Analysis Queries]({{< ref "cd-as-a-service/tasks/canary/retro-analysis" >}})
-{{% /card %}} - - - -{{% card header="Deployment" %}} -[Create a Deployment Config File]({{< ref "cd-as-a-service/tasks/deploy/create-deploy-config" >}})
-[Deployment Config File Reference]({{< ref "cd-as-a-service/reference/ref-deployment-file.md" >}})
-[Deploy Using Credentials]({{< ref "cd-as-a-service/tasks/deploy/deploy-with-creds.md" >}})
-[Add Context Variables]({{< ref "cd-as-a-service/tasks/deploy/add-context-variable" >}})
-[Create and Use Secrets]({{< ref "cd-as-a-service/tasks/secrets/secrets-create" >}})
-{{% /card %}} - -{{% card header="Traffic Management" %}} -[Traffic Management With Istio]({{< ref "cd-as-a-service/concepts/deployment/traffic-management/istio.md" >}})
-[Traffic Management With Linkerd]({{< ref "cd-as-a-service/concepts/deployment/traffic-management/smi-linkerd.md" >}})
-[Configure Istio]({{< ref "cd-as-a-service/tasks/deploy/traffic-management/istio" >}})
-[Configure Linkerd]({{< ref "cd-as-a-service/tasks/deploy/traffic-management/linkerd" >}})
-{{% /card %}} - -{{< /cardpane >}} - -{{< cardpane >}} - - -{{% card header="Webhooks" %}} -[Webhook-Based Approvals]({{< ref "cd-as-a-service/concepts/external-automation" >}})
-[Configure a Webhook]({{< ref "cd-as-a-service/tasks/webhook-approval" >}})
-[GitHub Webhook-Based Approval Tutorial]({{< ref "cd-as-a-service/tutorials/external-automation/webhook-github" >}})
-{{% /card %}} - -{{% card header="Tools" %}} -[CLI]({{< ref "cd-as-a-service/tasks/cli" >}})
-{{% /card %}} - -{{% card header="Tutorials" %}} - -[Create and Manage RBAC Roles]({{< ref "cd-as-a-service/tutorials/access-management/rbac-users" >}})
-[Deploy a Sample App]({{< ref "cd-as-a-service/tutorials/deploy-sample-app" >}})
- - -{{% /card %}} -{{< /cardpane >}} - diff --git a/content/en/cd-as-a-service/concepts/_index.md b/content/en/cd-as-a-service/concepts/_index.md deleted file mode 100644 index 9f7348ff9c..0000000000 --- a/content/en/cd-as-a-service/concepts/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Armory Continuous Deployment-as-a-Service Concepts -linkTitle: Concepts -description: > - This section contains information on the concepts and pieces that comprise the Armory Continuous Deployment-as-a-Service platform. -weight: 20 ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/architecture/_index.md b/content/en/cd-as-a-service/concepts/architecture/_index.md deleted file mode 100644 index 5317c76657..0000000000 --- a/content/en/cd-as-a-service/concepts/architecture/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Armory Continuous Deployment-as-a-Service Architecture -linkTitle: Architecture -description: > - Learn about Armory CD-as-a-Service key components and how to organize your CD-as-a-Service workspace to orchestrate deployments by multiple project teams. -weight: 10 -aliases: - - /armory-deployments/architecture/ - - /cd-as-as-service/concepts/architecture/ -categories: ["Concepts"] -tags: ["Architecture"] ---- - diff --git a/content/en/cd-as-a-service/concepts/architecture/key-components.md b/content/en/cd-as-a-service/concepts/architecture/key-components.md deleted file mode 100755 index 4ebdeee34b..0000000000 --- a/content/en/cd-as-a-service/concepts/architecture/key-components.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Armory CD-as-as-Service Key Components -linkTitle: Key Components -description: > - Learn about the key components that comprise Armory Continuous Deployment-as-a-Service and how they work together to orchestrate deployments. Remote Network Agent (RNA), Kubernetes permissions, networking requirements, CLI, GitHub Action. -weight: 10 -categories: ["Concepts"] -tags: ["Architecture", "Key Components", "Remote Network Agent", "Secrets"] -aliases: - - /armory-deployments/architecture/ - - /cd-as-as-service/architecture/ - - /cd-as-as-service/concepts/architecture/ - - /cd-as-a-service/concepts/architecture/system-requirements/ - - /cd-as-a-service/release-notes/requirements/ ---- - - - -## How Armory CD-as-a-Service works - -Armory CD-as-a-Service is a platform of cloud-based services that orchestrate app deployments and monitor their progress. These services have API endpoints with which users and non-cloud services interact via HTTPS or gRPC/HTTP2. The [Networking](#networking) section contains details of the endpoints that need to be whitelisted. - -Armory CD-as-a-Service uses secure agents that run in target Kubernetes 1.16+ clusters to communicate with Armory CD-as-a-Service. Make sure your environment meets the [networking](#networking) requirements so that the agents can communicate with Armory CD-as-a-Service. - -There are no additional requirements for installing the agents that Armory CD-as-a-Service uses. For information about how to install these agents, see {{< linkWithTitle "cd-as-a-service/tasks/networking/install-agent" >}}. - -Armory CD-as-a-Service contains components that you manage: the CLI, the Remote Network Agent (RNA), and the GitHub Action (GHA). These components communicate with Armory CD-as-a-Service to deploy your apps to your existing infrastructure. - -{{< figure src="/images/cdaas/cdaas-arch.png" alt="CD-as-a-Service High-Level Architecture" height="75%" width="75%" >}} - -When you start a deployment from the CLI or the GHA, Armory CD-as-a-Service forwards your deployment request to the designated RNA in your Kubernetes cluster. - -You can track the status of a deployment in the Armory CD-as-a-Service UI. - -## Key components - -### Remote Network Agent (RNA) - -The RNA is a Kubernetes Agent that enables Armory CD-as-a-Service to interact with your Kubernetes clusters and orchestrate deployments without direct network access to your clusters. The RNA that you install in your cluster engages in secure communication with Armory CD-as-a-Service over encrypted, long-lived gRPC/HTTP2 connections. The RNA issues calls to your Kubernetes cluster based on requests from Armory CD-as-a-Service. - -Once you install the RNA in your cluster, you don't need to update it beyond security updates. Deployment logic is encapsulated in server-side services. - -#### Kubernetes permissions for the Remote Network Agent - -By default, the RNA is installed with full access to your cluster. At a minimum, the RNA needs permissions to create, edit, and delete all `kind` objects that you plan to deploy with CD-as-a-Service, in all namespaces to which you plan to deploy. The RNA also requires network access to any monitoring solutions or webhook APIs that you plan to forward through it. You can modify permissions, proxy configurations, custom annotations, labels, or environment variables by modifying the Helm chart's configurable values. - -### Command Line Interface (CLI) - -Users install the CLI locally. The CLI interacts with Armory CD-as-a-Service via REST API. To deploy an app, the user must either log in using the CLI or pass valid authorization credentials to the `deploy` command. - -### GitHub Action (GHA) - -You can use the `armory/cli-deploy-action` to trigger a deployment from your GitHub workflow. The GitHub Action interacts with Armory CD-as-a-Service via REST API. The GHA requires a valid Client ID and Client Secret be passed to the deploy command. - -### Spinnaker plugin - -{{< include "cdaas/desc-plugin.md" >}} - -## Networking - -{{< include "cdaas/req-networking.md" >}} - -## Secrets - -Secrets allow Armory CD-as-a-Service to authenticate with external systems and tools during a deployment. - -### Metrics providers - -You can store credentials for metrics providers like New Relic, DataDog, or Prometheus as secrets. Armory CD-as-a-Service uses these credentials to authenticate with your metric provider when querying for application metrics during a canary analysis. - -### Kubernetes clusters - -You can store long-lived Kubernetes authentication tokens as secrets. -Armory CD-as-a-Service uses these credentials to deploy, scale, and cache Kubernetes resources. - -### GitHub actions - -You can store GitHub Personal Access Tokens (PATs) as secrets. -You can configure a webhook to authenticate with a GitHub PAT to kick off GitHub Actions-based integration tests during a deployment. - -### Security - -Secrets are encrypted in transit and at rest. They are additionally encrypted at rest with a per-tenant key using AES-256 encryption. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/setup/quickstart.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/architecture/orgs-tenants.md b/content/en/cd-as-a-service/concepts/architecture/orgs-tenants.md deleted file mode 100644 index 881a2a6d8a..0000000000 --- a/content/en/cd-as-a-service/concepts/architecture/orgs-tenants.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Organizations, Tenants, and Users -linkTitle: Orgs, Tenants, Users -description: > - Learn how to organize your Armory Continuous Deployment-as-a-Service workspace. -weight: 10 -categories: ["Concepts"] -tags: ["Architecture", "Tenants", "Access", "RBAC"] ---- - - -## Overview - -{{< cardpane >}} -{{< card header="Organization: a company, such as Apple or Google" >}} -```mermaid -graph TB -A(Organization) -- "1...*" --> B(Tenant) -A -- 1...* --> C(User) -``` -* Has a collection of Users -* Has a collection of Tenants -{{< /card >}} -{{< card header="Tenant: an organizational space" >}} -```mermaid -graph TB - A(Tenant) -- "1...1" --> B(Organization) - A -- 1...* --> C(User) -``` -* Belongs to a single Organization -* Has at least one User -* Has its own configuration, Remote Network Agents, and deployments -{{< /card >}} -{{< card header="User: an Organization member" >}} -```mermaid -graph TB - A(User) -- "1...1" --> B(Organization) - A -- 1...* --> C(Tenant) -``` - -* Belongs to a single Organization -* Can be granted access to multiple Tenants within the Organization -{{< /card >}} -{{< /cardpane >}} - -When a user creates an account, CD-as-a-Service does the following: - -* Creates an Organization for the company -* Creates a Tenant for the Organization -* Creates a User with an _Organization Admin_ role - -For example, Shannon Singh works for a company called Foothold. When Shannon creates a new account, CD-as-a-Service creates these: - -* **Organization**: Foothold -* **Tenant**: main -* **Organization Admin**: Shannon Singh - -As the Organization Admin, Shannon can do the following: -* [Create Tenants]({{< ref "cd-as-a-service/tasks/tenants/add-tenants.md" >}}) -* [Create User Roles]({{< ref "cd-as-a-service/tasks/iam/create-role.md" >}}) -* [Invite Users]({{< ref "cd-as-a-service/tasks/iam/invite-users.md" >}}) -* [Assign Roles to Users]({{< ref "cd-as-a-service/tasks/iam/manage-role-user.md" >}}) -* [Create Machine-to-Machine Client Credentials]({{< ref "cd-as-a-service/tasks/iam/client-creds.md" >}}) - -## How to organize your company workspace - -How you organize your workspace depends on various factors. If you have a small team, a single tenant may serve your needs quite well. If you multiple apps and project teams, you may want to create several tenants. - -### Scenario: one tenant for each app - -Foothold has 3 project teams and wants app-level deployment separation. - -| App | Tenant | User Role | Project Team Members | -|-------|-----------|--------------|---------------------------------------------| -| Alpha | app-alpha | tenant-alpha | Priya, Aiden, Cassidy | -| Beta | app-beta | tenant-beta | Gabriela, Franz, Blake | -| Gamma | app-gamma | tenant-gamma | Quinn, Sai, Cassidy | - -For this scenario, Organization Admin Shannon has to create the tenants and roles for users to access specific tenants. Then Shannon assigns roles to project team members, with Cassidy assigned two roles since she works on two different apps. - -This approach might become cumbersome if your company has or could have a lot of apps. - -### Scenario: one tenant for each project team - -Foothold has 3 project teams and wants team-level deployment separation. - -| Project Team | Tenant | User Role | Project Team Members | -|--------------|----------------|-----------------|---------------------------------------------| -| Wormhole | team-wormhole | tenant-wormhole | Priya, Aiden, Cassidy | -| Starship | team-starship | team-starship | Gabriela, Franz, Blake | -| Nebula | team-nebula | team-nebula | Quinn, Sai, Cassidy | - -Like the previous scenario, Organization Admin Shannon has to create the tenants and roles. Then he assigns roles to project team members, with Cassidy assigned two roles since she works on two different teams. - -The advantage to this approach is that it supports project teams responsible for a varying number of apps at any given point in time. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}} -* {{< linkWithTitle "cd-as-a-service/tasks/iam/_index.md" >}} diff --git a/content/en/cd-as-a-service/concepts/canary-analysis/_index.md b/content/en/cd-as-a-service/concepts/canary-analysis/_index.md deleted file mode 100644 index 8f2b01a9eb..0000000000 --- a/content/en/cd-as-a-service/concepts/canary-analysis/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Canary Concepts -linkTitle: Canary -description: > - Learn how Armory Continuous Deployment-as-a-Service supports canary strategies. - -draft: true ---- - -Armory CD-as-a-Service supports performing canary deployments. The canary deployment strategy deploys an app progressively to your cluster based on a set of steps that you configure. You set weights (percentage thresholds) for how the deployment should progress and a pause after each weight is met. Armory CD-as-a-Service works through these steps until your app is fully deployed. For example, you can deploy the new version of your app to 25% of your target cluster and then wait for a manual judgement or a configurable amount of time. This pause gives you time to assess the impact of your changes. From there, either continue the deployment to the next weight you set or roll back the deployment if you notice an issue. \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/deployment/_index.md b/content/en/cd-as-a-service/concepts/deployment/_index.md deleted file mode 100644 index ff929bda73..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Deployment Concepts -linkTitle: Deployment -description: > - In this section, learn how Armory CD-as-a-Service manages your deployments. ---- - diff --git a/content/en/cd-as-a-service/concepts/deployment/how-hpa-works.md b/content/en/cd-as-a-service/concepts/deployment/how-hpa-works.md deleted file mode 100644 index 8014d18512..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/how-hpa-works.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Kubernetes Horizontal Pod Autoscaling in Armory CD-as-a-Service" -linktitle: "Kubernetes HPA" -description: > - Learn how Armory Continuous Deployment-as-a-Service implements Kubernetes Horizontal Pod Autoscaling. -categories: ["Concepts"] -tags: ["Deployment", "Kubernetes", "Horizontal Pod Autoscaling"] ---- - -## {{% heading "prereq" %}} - -Before you begin using a Kubernetes HorizontalPodAutoscaler in your CD-as-a-Service deployment, you should have a working knowledge of Horizontal Pod Autoscaling in Kubernetes. Consult the following Kubernetes docs: - -- [Horizontal Pod Autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) -- [HorizontalPodAutoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) - -## Where to create your HorizontalPodAutoscaler - -You must create your app's HorizontalPodAutoscaler in a manifest. See [Creating the autoscaler declaratively](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#creating-the-autoscaler-declaratively) for a manifest example. Each Deployment resource can have its own HorizontalPodAutoscaler. - - -## How Horizontal Pod Autoscaling works in CD-as-a-Service - -When you deploy a Deployment resource, CD-as-a-Service converts the Deployment to a ReplicaSet. Correspondingly, when you declare a HorizontalPodAutoscaler to scale a Deployment resource, CD-as-a-Service automatically reconfigures that HorizontalPodAutoscaler to reference the generated ReplicaSet resource. - -### What happens during a deployment - -CD-as-a-Service freezes scaling behavior at the start of a deployment. - -Consider a deployment to upgrade your app from v1 to v2. In this scenario, the v1 app is running with 10 Pods. Your HorizontalPodAutoscaler scales your app down to 5 Pods minimum or up to 15 Pods maximum. - -1. When the deployment begins, CD-as-a-Service deletes the v1 HorizontalPodAutoscaler. Your v1 app has 10 Pods but no longer scales up or down. -1. CD-as-a-Service deploys the v2 instance of your app with 10 Pods. Now you have 20 total Pods between v1 and v2. -1. At the end of your v2 app deployment, CD-as-a-Service creates a new HorizontalPodAutoscaler resource to target your v2 app. - -### What happens during a rollback - -Since you can't roll back once a deployment has finished, scaling behavior is still frozen when a rollback begins. - -CD-as-a-Service deletes the v2 app and v2 HorizontalPodAutoscaler and recreates the v1 HorizontalPodAutoscaler config file using the `kubectl.kubernetes.io/last-applied-configuration` annotation. CD-as-a-Service then deploys your v1 app and HorizontalPodAutoscaler. - ->Do not delete the `kubectl.kubernetes.io/last-applied-configuration` annotation between deployments or your rollback will fail. Additionally, CD-as-a-service may not capture any manual or programmatic changes you make to the HorizontalPodAutoscaler configuration file between deployments. - -## Supported HorizontalPodAutoscaler API versions - -- [v1](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v1/) -- [v2 beta 1 and 2](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2beta2/) -- [v2](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) diff --git a/content/en/cd-as-a-service/concepts/deployment/role-based-manual-approval.md b/content/en/cd-as-a-service/concepts/deployment/role-based-manual-approval.md deleted file mode 100644 index aff7793b2a..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/role-based-manual-approval.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Role-Based Manual Approval -description: > - Learn how role-based manual approvals in Armory Continuous Deployment-as-a-Service can enforce your SDLC's approval processes. -categories: ["Concepts"] -tags: ["Deployment", "RBAC", "Approvals"] ---- - -## Overview of role-based manual approval in Armory CD-as-a-Service - -You can use role-based manual approvals to enforce approval processes within your SDLC. For example, if a release manager must provide a signoff before production deployment, you can create a "Release Managers" role and configure a manual approval to require approval by that role. - -## {{% heading "prereq" %}} - -* You have read {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}}. - -## How role-based manual approval works - -Any manual approval can be role-based. In your deployment manifest, you add a `requiresRoles` field to specify which roles can issue the approval. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -... -pause: - untilApproved: true - requiresRoles: [] -... -{{< /prism >}} - -- `requiresRoles`: list of RBAC roles - - - The list must have at least one entry. - - Omitting this field means that any user with access to the deployment can issue the approval. - -### Rules - -* Users assigned any of the roles in the list can issue the approval. The **Approve** button is disabled if the user doesn't have the correct role. -* Users assigned the Organization Admin role can issue an approval in any deployment regardless of tenant. -* Users assigned a [Tenant Admin role]({{< ref "cd-as-a-service/concepts/iam/rbac#tenant-admin-role" >}}) can issue an approval in any deployment in their specific tenant. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/tasks/deploy/role-based-manual-approval.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/deployment/traffic-management/_index.md b/content/en/cd-as-a-service/concepts/deployment/traffic-management/_index.md deleted file mode 100644 index 1c44d2aa7d..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/traffic-management/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Traffic Management -linkTitle: Traffic Management -description: > - Learn about service mesh traffic management for your Armory Continuous Deployment-as-a-Service canary deployments. CD-as-a-Service supports Istio and Linkerd. -aliases: - - /cd-as-a-service/concepts/deployment/traffic-mgmt/ ---- - diff --git a/content/en/cd-as-a-service/concepts/deployment/traffic-management/istio.md b/content/en/cd-as-a-service/concepts/deployment/traffic-management/istio.md deleted file mode 100644 index 51e8f152d8..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/traffic-management/istio.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Traffic Management With Istio -linkTitle: Istio -description: > - Learn how CD-as-a-Service implements traffic management with Istio. -categories: ["Concepts"] -tags: ["Deployment", "Traffic Management", "Istio"] ---- - -## {{% heading "prereq" %}} - -* You are familiar with the following [Istio](https://istio.io/latest/) concepts: - - * [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/) - * [Virtual Service configuration](https://istio.io/latest/docs/reference/config/networking/virtual-service/) - -## How CD-as-a-Service shapes traffic - -In the following example, you define a CD-as-a-Service deployment that uses a VirtualService and DestinationRoute: - -{{< include "cdaas/deploy/istio-example.md" >}} - -When you deploy your app, CD-as-a-Service modifies your VirtualService and DestinationRule, setting weights for `stable` and `canary` subsets based on the weights specified in your deployment strategy. CD-as-a-Service also adds the `armory-pod-template-hash` label to the DestinationRule subsets for routing traffic to the pods of each ReplicaSet. - -{{< prism lang="yaml" line="13-17, 30-34" line-numbers="true" >}} -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: reviews -spec: - hosts: - - reviews - http: - - route: - - destination: - host: reviews.istiodemo.svc.cluster.local - subset: stable - weight: 10 - - destination: - host: reviews.istiodemo.svc.cluster.local - subset: canary - weight: 90 - name: http-route-reviews ---- -apiVersion: networking.istio.io/v1alpha3 -kind: DestinationRule -metadata: - name: reviews -spec: - host: reviews.istiodemo.svc.cluster.local - subsets: - - name: stable - labels: - app: reviews - armory-pod-template-hash: gc6647 - - name: canary - labels: - app: reviews - armory-pod-template-hash: cd6648 -{{< /prism >}} - -At the end of the deployment, CD-as-a-Service removes the lines it added so the resources look the same as before the deployment began. - -## Additional capabilities - -* You have two options for deploying your VirtualService and DestinationRule Istio resources: - - 1. Separately, before your CD-as-a-Service deployment - 1. As part of your CD-as-a-Service deployment, included in the same directory as your app manifest - -* You can use a VirtualService that has more than one route as long as the route is named within the resource and specified in your deployment file. -* CD-as-a-Service supports both FQDN and short names in the `host` fields. - - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/tasks/deploy/traffic-management/istio.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/deployment/traffic-management/smi-linkerd.md b/content/en/cd-as-a-service/concepts/deployment/traffic-management/smi-linkerd.md deleted file mode 100644 index ac468b30b8..0000000000 --- a/content/en/cd-as-a-service/concepts/deployment/traffic-management/smi-linkerd.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Traffic Management With Linkerd -linkTitle: Linkerd -description: > - Learn how CD-as-a-Service implements progressive canary traffic management using Linkerd. -aliases: - - /cd-as-a-service/concepts/deployment/progressive-canary/ -categories: ["Concepts"] -tags: ["Deployment", "Traffic Management", "Linkerd"] ---- - -## Service meshes and the Service Mesh Interface (SMI) - -There are many guides and introductions to service meshes, such as the [Service Mesh Manifesto](https://buoyant.io/service-mesh-manifesto/). - -Most guides to the service mesh concept start by describing a control plane and a data plane. Ignore both of these terms. Instead, focus on the proxy, which is typically auto-injected as a sidecar in your application pods. - ->CD-as-a-Service does not configure proxy sidecar injection. - -This proxy intercepts all inbound and outbound network traffic and understands application-level protocols (think HTTP and gRPC). Because it understands application protocols, the proxy can implement application features: HTTP metrics, path-and-header-based routing, access control, or retries. The service mesh, as a whole — the previously ignored data and control plane — is a system to implement, configure, and observe these features. The magic of a mesh is that it's possible to get consistent HTTP metrics (or retries, access control, etc.) across a set of heterogenous microservices without the wrangling or even buy-in of the service owners. - -The Service Mesh Interface (SMI) is an abstraction of the features common among service mesh implementations; the abstraction takes the form of Kubernetes Custom Resource Definitions (CRDs). - -SMI solves a common integration problem: _n_ consumers want to integrate with _m_ producers, each having its own interface, creating a miserable _m ⋅ n_ integration matrix. Because of SMI, tools that want to integrate with service mesh providers don't need to integrate with each mesh individually. Instead, they can just integrate with SMI. Popular service meshes understand SMI natively or via adapters. - -A progressive canary deployment — not to be confused with canary analysis — incrementally shifts traffic between two versions of your software. You can, for example, define a deployment that looks like this: - -- Send 25% of incoming traffic to the new version of my software -- Run a metric analysis (e.g., verify that no more than 1% of HTTP requests return a 5xx status code during the analysis period) -- Run integration tests -- If the preceding two steps succeed, bump the traffic weight to 100% and tear down the old version of my software - -A progressive canary deployment is a kind of interface. Armory CD-as-a-Service offers two progressive canary implementations: pod-ratio canary and SMI canary. - -In a pod-ratio canary, we shape traffic by controlling the relative number of pods of each version of your software. Pod-ratio canaries are great, and most of the internal services that comprise Armory CD-as-a-Service use it to deploy themselves. There are, however, some limitations: - -- **Traffic granularity**: in a pod-ratio canary, it's not always possible to achieve highly granular traffic shifts. If your application typically runs as a cluster of four pods, it's not possible to send a tiny percentage of traffic — e.g., 1% — to the new version of your software. If you're trying to maintain an ambitious SLA, coarse-grained traffic weighting may not be acceptable to you. -- **Traffic shift and rollback time**: since the pod-ratio strategy scales pods up and down to shift traffic, traffic shifts and rollbacks can be slow if your application boots slowly. This can be scary if you need to roll back quickly. -For those that like to get straight to the point (and would like to skip to the end of the article): our implementation of progressive canary with SMI solves both of these problems. - -## Progressive canary with SMI TrafficSplit - -Armory CD-as-a-Service uses SMI's TrafficSplit resource to implement progressive canary deployments. - -A TrafficSplit defines, declaratively, how traffic should be weighted across two or more groups of pods under a single cluster-local domain name. Clients can call a single address and talk, with a defined likelihood, to one of several different versions of your software. - -A split is a powerful tool but, on its own, it can't deploy your software. It needs to be used in concert with other tools: as the SMI spec says, "the resource itself [i.e., SMI TrafficSplit] is not a complete solution as there must be some kind of controller managing the traffic shifting over time." - -Armory CD-as-a-Service is this controller — it's the coordinator that scales up the new version of your software, waits for it to become healthy, safely shifts traffic by updating a TrafficSplit, and shuts down the old version of your software once you're certain that your deployment is healthy. Apart from installation, you don't need any knowledge of SMI or your service mesh to use CD-as-a-Service - we're responsible for creating all of the auxiliary resources and cleaning them up when we're done. - -A canary deployment with SMI has the following advantages over a pod-ratio canary: - -- You can choose any integer traffic weight for the new version of your software, regardless of the size of your deployment. In the future we may support fractional traffic weights (e.g., 0.1%) -- Traffic shifts and rollbacks are nearly instantaneous and not dependent on scale up or scale down time. - -## Supported service mesh products - -* [Linkerd](https://linkerd.io/) - - -## {{% heading "nextSteps" %}} - -- {{< linkWithTitle "cd-as-a-service/tasks/deploy/traffic-management/linkerd.md" >}} diff --git a/content/en/cd-as-a-service/concepts/external-automation.md b/content/en/cd-as-a-service/concepts/external-automation.md deleted file mode 100644 index 77245ac654..0000000000 --- a/content/en/cd-as-a-service/concepts/external-automation.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: External Automation Using Webhook-Based Approvals -linktitle: External Automation -description: > - Integrate webhook-based approvals into your Armory CD-as-a-Service app deployment process. -categories: ["Concepts"] -tags: ["Webhooks", "GitHub", "Automation"] ---- - -## When you should use webhook-based approvals - -You can think of webhook-based approvals as a generic extensibility layer that enables you to call any API in any internet-accessible system. You can use a webhook to obtain a decision from a process that is external to Armory CD-as-a-Service. - -### Webhook use cases - -**Before deployment** - -- Upgrade a database schema -- Custom approval process - -**Within your deployment strategy** - -- Check logs and system health -- Run custom tests - -**After deployment** - -- Run integration tests in a staging environment -- Perform metric tests -- Run security scanners - -## How webhook-based approval works - -In order to accommodate a long-running process, Armory CD-as-a-Service supports the asynchronous webhook with callback pattern. You define the webhook in your deployment file and add a webhook call in the `constraints` section of your deployment definition or in a canary step. - -**Basic flow** - -The deployment process: -1. Encounters a webhook call -1. Calls the external API -1. Pauses deployment while waiting for the callback -1. Receives and processes callback - - Success: deployment proceeds - - Failure: deployment rolls back - -```mermaid -flowchart TB - A --> B - B --> C - C --> D - D --> E - E --> F - F -- "Success: true" --> G - F -- "Success: false" --> H - - A["Deployment Starts"] - B["Webhook Call Triggered
Deployment Pauses"] - F{"Did the external process
succeed or fail?"} - G["Deployment Continues"] - H["Deployment Rolls Back"] - - subgraph exp [External Process] - C["External API
Receives Request"] - D["Process Runs"] - E[Callback to Deployment] - end -``` - -{{% alert title="Important" color="Primary" %}} -- If you have a manual approval in your deployment constraint and the webhook callback returns failure, the deployment rolls back without waiting for the manual approval. -- If Armory CD-as-a-Service hasn't received the webhook callback within 24 hours, the process times out and deployment fails. -- If an `afterDeployment` webhook callback returns failure, deployment is canceled to all environments that depend on the current environment, _but the current environment is not rolled back_. -{{% /alert %}} - -## Requirements for your webhook and callback - -- The webhook must retrieve the callback URI from the payload or query parameters. -- The callback must use Bearer authorization and include a success value and optional message in the body. - -### Retrieve an OAUTH token to use in your callback - -Request format: - -{{< prism lang="bash" line-numbers="true" >}} -curl --request POST \ - --url https://auth.cloud.armory.io/oauth/token \ - --header 'Content-Type: application/x-www-form-urlencoded' \ - --data "data=audience=https://api.cloud.armory.io&grant_type=client_credentials&client_id=$CDAAS_CLIENT_ID&client_secret=$CDAAS_CLIENT_SECRET" -{{< /prism >}} - -Example response: - -{{< prism lang="json" line-numbers="true" >}} -{ - "access_token": "", - "scope": "manage:deploy read:infra:data exec:infra:op read:artifacts:data", - "expires_in": 86400, - "token_type": "Bearer" -} -{{< /prism >}} - -### Callback format - -{{< prism lang="bash" line-numbers="true" >}} -curl --request POST \ - --url 'https://$CALLBACK_URI' \ - --header 'Authorization: Bearer $OAUTH_TOKEN' \ - --header 'Content-Type: application/json' \ - --data '{"success": true, "mdMessage": "Webhook successful"}' -{{< /prism >}} - -Armory CD-as-a-Service looks for `success` value of `true` or `false` to determine the webhook's success or failure. `mdMessage` should contain a user-friendly message for Armory CD-as-a-Service to display in the UI and write to logs. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "/cd-as-a-service/tasks/webhook-approval.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/concepts/iam/_index.md b/content/en/cd-as-a-service/concepts/iam/_index.md deleted file mode 100644 index 346f25023a..0000000000 --- a/content/en/cd-as-a-service/concepts/iam/_index.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Access Management Concepts -linkTitle: Access Management -description: > - In this section, learn about Access Management in Armory CD-as-a-Service. -categories: ["Concepts"] -tags: ["OIDC", "Access"] ---- - -## Armory CD-as-a-Service Access Management - -Armory CD-as-a-Service uses OIDC to authenticate both user and machine principals and issue short-lived access tokens, which are signed JSON web tokens (JWTs). - -The Armory CD-as-a-Service API consumes these access tokens in order to validate that a request has authorization for a given tenant’s resources and operations. - -Use the the [CD-as-a-Service Console](https://console.cloud.armory.io/) to manage the following: - -- Credentials for machines and scope them for specific permissions and use cases -- Users -- OIDC based external identity providers (IdP), such as Okta, Auth0, or OneLogin - diff --git a/content/en/cd-as-a-service/concepts/iam/rbac.md b/content/en/cd-as-a-service/concepts/iam/rbac.md deleted file mode 100644 index 01b01e9b6a..0000000000 --- a/content/en/cd-as-a-service/concepts/iam/rbac.md +++ /dev/null @@ -1,366 +0,0 @@ ---- -title: Role-Based Access Control -linktitle: RBAC -description: > - Learn how Armory Continuous Deployment-as-a-Service implements Role-Based Access Control (RBAC). -categories: ["Concepts"] -tags: ["RBAC", "Access"] ---- - - -## {{% heading "prereq" %}} - -You are familiar with the concepts discussed in {{< linkWithTitle "cd-as-a-service/concepts/architecture/orgs-tenants.md" >}}. - -## Overview of RBAC in CD-as-a-Service - -CD-as-a-Service's RBAC implementation provides you with the following features: - -* [System-defined roles](#system-roles) for admins and machine-to-machine credentials -* [Custom roles](#custom-role-examples) that you create to fit your company's needs -* [SSO groups to custom RBAC roles mapping](#sso-groups-and-rbac-roles) -* [Role-based deployment approval]({{< ref "cd-as-a-service/concepts/deployment/role-based-manual-approval.md" >}}) - -## RBAC implementation - -```mermaid -classDiagram - class Role { - +String name - +Tenant tenant - +List~Grant~ grants - } - class Grant { - +GrantType type - +String resource - +List~Permission~ permissions - } - class GrantType { - api - } - class Permission { - full - } - class User { - +List~Role~ roles - } - class M2MCredential { - +List~Role~ roles - } - class Tenant { - +String name - } - - Role "1" --> "*" Grant - Grant "1" --> "*" Permission - Grant "1" --> "1" GrantType - Role "1" --> "1" Tenant - Role "1" --> "1" Tenant - User "1" --> "*" Role - M2MCredential "1" --> "*" Role -``` - - -Central to CD-as-a-Service's [RBAC](https://en.wikipedia.org/wiki/Role-based_access_control) implementation is a _Role_, which defines what a user can do within the platform. Each Role has a _Grants_ collection that defines permissions. - -You define your custom RBAC roles in a YAML file that has this structure: - -{{< prism lang="yaml" line-numbers="true" >}} -roles: - - name: - tenant: - grants: - - type: - resource: - permission: -{{< /prism >}} - -You can create an organization-wide role by omitting the `tenant` definition. - -### Grants - -A _Grant_ has type, resource, and permission attributes. - -`type` has a single choice: `api`. - -`resource` defines what area the Grant can access. It has the following values: - -* `tenant`: When you use `tenant` as the `resource`, the Grant allows access to the tenant that you specify in the `roles.tenant` field. You use `tenant` when you define a [Tenant Admin role](#tenant-admin-role). -* `deployment`: This resource allows the role to deploy using the CLI and manage deployments in the **Deployments** UI. If you omit `roles.tenant`, the role has this Grant across your organization. -* `organization`: You use this resource when you need to create an Organization Admin role that maps to an SSO group. See [SSO groups and RBAC roles](#sso-groups-and-rbac-roles) for more on mapping SSO groups to RBAC roles. - -`permission` has one option: `full`. - -### System roles - -CD-as-a-Service provides the following system roles: - -* Organization Admin - * Grants: - - * UI - full access to all screens and functionality - * CLI - full authority to execute all CLI commands - - * Assignment: - - * CD-as-a-Service assigns this role to the person who creates a new CD-as-a-Service account (Organization). - * You are able to manually assign the Organization Admin role to all users you invite to your Organization, thus bypassing the need to create custom RBAC roles. - -* Deployments Full Access - - * Grants: - * This role grants full authority to trigger deployments. - * Assignment: - * Assign this role to Client Credentials that you plan to use with CI tools like GitHub Actions. - -* Remote Network Agent - - * Grants: - * This role grants a Remote Network Agent access to CD--as-a-Service. - * Assignment: - * Assign this role to all Client Credentials you create to use with Remote Network Agents. - - -## Custom role examples - -### Tenant Admin role - -This example defines three Tenant Admin roles, one for each tenant. Each role has full authority within the specified tenant. - -{{< prism lang="yaml" line-numbers="true" >}} -roles: - - name: Tenant Admin Main - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Tenant Admin Finance - tenant: finance - grants: - - type: api - resource: tenant - permission: full - - name: Tenant Admin Commerce - tenant: commerce - grants: - - type: api - resource: tenant - permission: full -{{< /prism >}} - -If you want to grant a user permission to manage all of your tenants, assign that user the **Organization Admin** role using the UI. - -### Deployment roles - -This example defines a role that grants permission to use the **Deployments** UI and start deployments using the CLI. The role is bound to the `finance` tenant. - -{{< prism lang="yaml" line-numbers="true" >}} -roles: - - name: Deployer Finance - tenant: finance - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -This next example defines a role that grants permission to use the **Deployments** UI and start deployments using the CLI across your entire organization. Note that `tenant` is not defined, which makes this an organization-wide role. - -{{< prism lang="yaml" line-numbers="true" >}} -roles: - - name: Deployer All Tenants - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - - -## Assign roles - -After you define your roles, you use the CLI to [add your roles]({{< ref "cd-as-a-service/tasks/iam/create-role" >}}) to your CD-as-a-Service Organization. You do all subsequent role management with the CLI, but you [assign roles to users]({{< ref "cd-as-a-service/tasks/iam/manage-role-user" >}}) using the UI. - -All users must have at least one role in order to use CD-as-a-Service. You can assign the Organization Admin role or a custom role. If a user has login credentials but no role assigned, the user sees a blank **Deployments** screen after logging in. - -A Client Credential must also have an RBAC role to access CD-as-a-Service functionality. See {{< linkWithTitle "cd-as-a-service/tasks/iam/client-creds.md" >}} for how to assign a role to a Client Credential. - -## SSO groups and RBAC roles - ->There is no self-service function for integrating your SSO provider. Contact your Armory rep if you want to use SSO with CD-as-a-Service. - -You must create your RBAC roles using the same names as your SSO groups. For example, your company has the following groups defined in its SSO provider: - -1. Engineering-Lead -1. Engineering-Deployment -1. Engineering-Infra - -You want to use those groups in CD-as-a-Service, so you need to create roles for those SSO groups. In the following example, `Engineering-Lead` has a tenant-specific Tenant Admin role, `Engineering-Deployment` has a tenant-specific deployment role, and `Engineering-Infra` has the equivalent of an Organization Admin role. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Engineering-Lead - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Engineering-Deployment - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: Engineering-Infra - grants: - - type: api - resource: organization - permission: full -{{< /prism >}} - -During authentication, CD-as-a-Service maps a user's SSO groups to your defined RBAC roles. - -{{% alert title="Caution" color="warning" %}} -1. The SSO role does not appear in the UI. You cannot use CD-as-a-Service to assign an SSO role to a user. -1. You cannot use CD-as-a-Service to inspect the SSO groups that a user belongs to. -{{% /alert %}} - - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/concepts/deployment/role-based-manual-approval.md" >}} -* Tasks: {{< linkWithTitle "cd-as-a-service/tasks/iam/create-role.md" >}}, {{< linkWithTitle "cd-as-a-service/tasks/iam/update-role.md" >}}, {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}}, {{< linkWithTitle "cd-as-a-service/tasks/iam/invite-users.md" >}}, {{< linkWithTitle "cd-as-a-service/tasks/iam/client-creds.md" >}} -* Tutorial: {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} - - - -
-
- - - \ No newline at end of file diff --git a/content/en/cd-as-a-service/plugin-spinnaker.md b/content/en/cd-as-a-service/plugin-spinnaker.md deleted file mode 100644 index 5395fac961..0000000000 --- a/content/en/cd-as-a-service/plugin-spinnaker.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Armory CD-as-a-Service Plugin for Spinnaker and Armory Continuous Deployment -linkTitle: Spinnaker Plugin -manualLinkRelRef: "plugins/cdaas-spinnaker.md" -exclude_search: true -description: > - Armory Continuous Deployment-as-a-Service plugin enables performing canary and blue/green deployments in a single stage. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/reference/_index.md b/content/en/cd-as-a-service/reference/_index.md deleted file mode 100644 index 790a82cbfc..0000000000 --- a/content/en/cd-as-a-service/reference/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Reference Docs for Armory CD-as-a-Service -linkTitle: Reference -weight: 50 -no_list: true -description: > - Deployment config file reference, CLI cheat sheets ---- - -## Terminology - -To help you understand how Armory CD-as-a-Service works, familiarize yourself with the following terms: - -- **Environment**: environments are used in two ways for Armory CD-as-a-Service, depending on the context. - - **CD-as-a-Service Console**: the Armory CD-as-a-Service backend and UI use environments to isolate users and secrets. Users and secrets for one environment do not have access to other environments. That means a user in environment A cannot access secrets or deployments in environment B. - - **Deployments**: for deployments, an environment is the collection of configs that you configure to tailor the deployment. It consists of characteristics that define how you deploy your app, including the target Kubernetes cluster, namespace, deployment strategy, and constraints (dependencies). For example, if you create a `prod` environment for your deployment, you can make it dependent on a `dev` environment and add a deployment strategy that protects `prod` untested changes. -- **Deployment/deploy file**: the deployment file is a YAML file that you use to define where you want to deploy to (the environments), what you want to deploy (the manifests), and how you want to deploy (the strategy). You can generate a template for the file using the Armory CD-as-a-Service CLI. For more information, see the [Deployment File Reference]({{< ref "ref-deployment-file" >}}). \ No newline at end of file diff --git a/content/en/cd-as-a-service/reference/glossary/cloud-provider.md b/content/en/cd-as-a-service/reference/glossary/cloud-provider.md deleted file mode 100644 index ab8399b0cd..0000000000 --- a/content/en/cd-as-a-service/reference/glossary/cloud-provider.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Cloud Provider -id: cloud-provider -short_description: > - An organization that offers a cloud computing platform. - -aka: -- Cloud Service Provider -tags: -- community - -draft: true ---- - A business or other organization that offers a cloud computing platform. - - - -Cloud providers, sometimes called Cloud Service Providers (CSPs), offer -cloud computing platforms or services. - -Many cloud providers offer managed infrastructure (also called -Infrastructure as a Service or IaaS). -With managed infrastructure the cloud provider is responsible for -servers, storage, and networking while you manage layers on top of that -such as running a Kubernetes cluster. - -You can also find Kubernetes as a managed service; sometimes called -Platform as a Service, or PaaS. With managed Kubernetes, your -cloud provider is responsible for the Kubernetes control plane as well -as the {{< cdaas/glossary_tooltip term_id="node" text="nodes" >}} and the -infrastructure they rely on: networking, storage, and possibly other -elements such as load balancers. diff --git a/content/en/cd-as-a-service/reference/glossary/index.md b/content/en/cd-as-a-service/reference/glossary/index.md deleted file mode 100644 index f8973aa105..0000000000 --- a/content/en/cd-as-a-service/reference/glossary/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Glossary -layout: glossary -noedit: true -default_active_tag: fundamental -weight: 5 -card: - name: reference - weight: 10 - title: Glossary -draft: true ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/reference/glossary/node.md b/content/en/cd-as-a-service/reference/glossary/node.md deleted file mode 100644 index cf9972e954..0000000000 --- a/content/en/cd-as-a-service/reference/glossary/node.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Node -id: node -date: 2018-04-12 -full_link: /docs/concepts/architecture/nodes/ -short_description: > - A node is a worker machine in Kubernetes. - -aka: -tags: -- fundamental - -draft: true ---- - A node is a worker machine in Kubernetes. - - - -A worker node may be a VM or physical machine, depending on the cluster. It has local daemons or services necessary to run Pods and is managed by the control plane. The daemons on a node include kubelet, kube-proxy, and a container runtime implementing the CRI such as Docker. - -In early Kubernetes versions, Nodes were called "Minions". diff --git a/content/en/cd-as-a-service/reference/ref-deployment-file.md b/content/en/cd-as-a-service/reference/ref-deployment-file.md deleted file mode 100644 index f1028ae85a..0000000000 --- a/content/en/cd-as-a-service/reference/ref-deployment-file.md +++ /dev/null @@ -1,857 +0,0 @@ ---- -title: Deployment Config File Reference for CD-as-a-Service -linkTitle: Deployment Config File -description: > - The deployment (deploy) file is where you configure your app for deployment by Armory CD-as-a-Service. This config file includes deployment artifact, target, strategy, and traffic management definitions. -aliases: - - /cd-as-a-service/reference/deployfile/ - - /cd-as-a-service/reference/deployfile/ref-deployment-file/ -categories: ["Reference"] -tags: ["Deployment", "Deploy Config"] ---- - -## Deployment config file reference overview - -The deployment config file is what you use to define how and where Armory CD-as-a-Service deploys your app. - -## Templates - -You can generate a template file by running the following command with the CLI: - -Basic template: - -```bash -armory template kubernetes [command] -``` -where `command` is the type of template. -
- -Automated canary analysis template: - -```bash -armory template kubernetes canary -f automated -``` - -Blue/green deployment template: - -```bash -armory template kubernetes bluegreen -``` - -To use a template, output it to a file and modify it to suit your needs: - -```bash -armory template kubernetes [template-type] > deployment-template.yaml -``` - -
Show me an example deployment file -This file is in the armory/docs-cdaas-sample repo. - -{{< github repo="armory/docs-cdaas-sample" file="/deploy.yml" lang="yaml" options="" >}} -

- -## Sections - -### `application` - -Provide a descriptive name for your application so that you can identify it when viewing the status of your deployment in the Deployments UI and other locations. - -### `deploymentConfig.` - -This config block is optional. If included, this configuration applies to all targets. - -A deployment times out if the pods for your application fail to be in ready state in 30 minutes. If you want to change the default, include this section. - - -{{< prism lang="yaml" line-numbers="true" >}} -deploymentConfig: - timeout: - unit: - duration: -{{< /prism >}} - -- `timeout`: (Required is section is included) The section specifies the amount of time to wait for pods to be ready before cancelling the deployment. - - `unit`: (Required) Set to `seconds`, `minutes` or `hours` to indicate what `duration` refers to. - - `duration`: (Required) Integer amount of time to wait - ->The minimum timeout you can specify is 60 seconds (1 minute). - -### `targets.` - -This config block is where you define where and how you want to deploy an app. You can specify multiple targets. Provide unique descriptive names for each environment to which you are deploying. - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - : - account: - namespace: - strategy: - constraints: -{{< /prism >}} - - - -#### `targets.` - -A descriptive name for this deployment, such as the name of the environment you want to deploy to. - -For example, this snippet configures a deployment target with the name `prod`: - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: -... -{{< /prism >}} - -#### `targets..account` - -The account name that a target Kubernetes cluster got assigned when you installed the Remote Network Agent (RNA) on it. Specifically, it is the value for the `agentIdentifier` parameter. Note that older versions of the RNA used the `agent-k8s.accountName` parameter. - -This name must match an existing cluster because Armory CD-as-a-Service uses the identifier to determine which cluster to deploy to. - -For example, this snippet configures a deployment to an environment named `prod` that is hosted on a cluster named `prod-cluster-west`: - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west -... -{{< /prism >}} - -#### `targets..namespace` - -(Recommended) The namespace on the target Kubernetes cluster that you want to deploy to. This field overrides any namespaces defined in your manifests. - -For example, this snippet overrides the namespace in your manifest and deploys the app to a namespace called `overflow`: - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west - namespace: overflow -{{< /prism >}} - -#### `targets..strategy` - -This is the name of the strategy that you want to use to deploy your app. You define the strategy and its behavior in the `strategies` block. - -For example, this snippet configures a deployment to use the `canary-wait-til-approved` strategy: - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west - namespace: overflow - strategy: canary-wait-til-approved -{{< /prism >}} - -Read more about how this config is defined and used in the [strategies.](#strategies.) section. - -#### `targets..constraints` - -`constraints` is a map of conditions that must be met before a deployment starts. The constraints can be dependencies on previous deployments, such as requiring deployments to a test environment before staging, or a pause. If you omit the constraints section, the deployment starts immediately when it gets triggered. - -> Constraints are evaluated in parallel. - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west - namespace: overflow - strategy: canary-wait-til-approved - constraints: - dependsOn: [""] - beforeDeployment: - - pause: - untilApproved: true - - pause: - duration: - unit: -{{< /prism >}} - -##### `targets..constraints.dependsOn` - -A comma-separated list of deployments that must finish before this deployment can start. You can use this option to sequence deployments. Deployments with the same `dependsOn` criteria execute in parallel. For example, you can make it so that a deployment to prod cannot happen until a staging deployment finishes successfully. - -The following example shows a deployment to `prod-west` that cannot start until the `dev-west` target finishes: - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-west - namespace: overflow - strategy: canary-wait-til-approved - constraints: - dependsOn: ["dev-west"] -{{< /prism >}} - -##### `targets..constraints.beforeDeployment` - -Conditions that must be met before the deployment can start. These are in addition to the deployments you define in `dependsOn` that must finish. - -You can specify a pause that waits for a manual approval or a certain amount of time before starting. - -**Pause until manual approval** - -Use the following configs to configure this deployment to wait until a manual approval before starting: - -- `targets..constraints.beforeDeployment.pause.untilApproved` set to true -- `targets..constraints.beforeDeployment.pause.requiresRole` (Optional) list of RBAC roles that can issue a manual approval -- `targets..constraints.beforeDeployment.pause.approvalExpiration` (Optional) Optional timeout configuration; when expired the ongoing deployment is cancelled - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west - namespace: overflow - strategy: canary-wait-til-approved - constraints: - dependsOn: ["dev-west"] - beforeDeployment: - - pause: - untilApproved: true - requiresRole: [] - approvalExpiration: - duration: 60 - unit: seconds -{{< /prism >}} - -**Pause for a certain amount of time** - -- `targets..constraints.beforeDeployment.pause.duration` set to an integer value for the amount of time to wait before starting after the `dependsOn` condition is met. -- `targets..constraints.beforeDeployment.pause.unit` set to `seconds`, `minutes` or `hours` to indicate the unit of time to wait. - -{{< prism lang="yaml" line-numbers="true" >}} -targets: - prod: - account: prod-cluster-west - namespace: overflow - strategy: canary-wait-til-approved - constraints: - dependsOn: ["dev-west"] - beforeDeployment: - - pause: - duration: 60 - unit: seconds -{{< /prism >}} - -### `manifests.` - -{{< prism lang="yaml" line-numbers="true" >}} -manifests: - # Directory containing manifests - - path: /path/to/manifest/directory - targets: ["", ""] - # Specific manifest file - - path: /path/to/specific/manifest.yaml - targets: ["", ""] -{{< /prism >}} - -#### `manifests.path` - -The path to a manifest file that you want to deploy or the directory where your manifests are stored. If you specify a directory, such as `/deployments/manifests/configmaps`, Armory CD-as-a-Service reads all the YAML files in the directory and deploys the manifests to the target you specified in `targets`. - -#### `manifests.path.targets` - -(Optional). If you omit this option, the manifests are deployed to all targets listed in the deployment file. A comma-separated list of deployment targets that you want to deploy the manifests to. Make sure to enclose each target in quotes. Use the name you defined in `targets.` to refer to a deployment target. - -### `strategies.` - -This config block is where you define behavior and the actual steps to a deployment strategy. - -{{< prism lang="yaml" line-numbers="true" >}} -strategies: - - canary: - steps: - - setWeight: - weight: - - pause: - duration: - unit: - - setWeight: - weight: - - exposeServices: - services: - - - - - - - ttl: - duration: - unit: - - pause: - untilApproved: true - - analysis: - context: - keyName: - keyName: - interval: - units: - numberOfJudgmentRuns: - rollBackMode: - rollForwardMode: - queries: - - - - - - setWeight: - weight: - - blueGreen: - activeService: - previewService: - redirectTrafficAfter: - - pause: - duration: - unit: - shutDownOldVersionAfter: - - pause: - untilApproved: true -{{< /prism >}} - -#### `strategies.` - -The name you assign to the strategy. Use this name for `targets..strategy`. You can define multiple strategies, so make sure to use a unique descriptive name for each. - -For example, this snippet names the strategy `canary-wait-til-approved`: - -{{< prism lang="yaml" line-numbers="true" >}} -strategies: - canary-wait-til-approved: -{{< /prism >}} - -You would use `canary-wait-til-approved` as the value for `targets..strategy` that is at the start of the file: - -{{< prism lang="yaml" line-numbers="true" >}} -... -targets: - someName: - ... - strategy: canary-wait-till-approved -... -{{< /prism >}} - -#### `strategies..` - -The kind of deployment strategy this strategy uses. Armory CD-as-a-Service supports `canary` and `blueGreen`. - -{{< prism lang="yaml" line-numbers="true" >}} -strategies: - - canary: -{{< /prism >}} - -#### Canary fields - -##### `strategies..canary.steps` - -Armory CD-as-a-Service progresses through all the steps you define as part of the deployment process. The process is sequential and steps can be of the types, `analysis`, `setWeight` or `pause`. - -Generally, you want to configure a `setWeight` step and have a `analysis` or `pause` step follow it although this is not necessarily required. This gives you the opportunity to see how the deployment is doing either manually or automatically before the deployment progresses. - -Some scenarios where this pairing sequence might not be used would be the following: - -- You can start the sequence of steps with a `pause` that has no corresponding weight. Armory CD-as-a-Service recognizes this as a weight of `0` since it is as the start of the deployment. This causes the deployment to pause at the start before any of the app is deployed. -- You want to have two `pause` steps in a row, such as a `pause` for a set amount of time followed by a `pause` for a manual judgment. - -You can add as many steps as you need but do not need to add a final step that deploys the app to 100% of the cluster. Armory CD-as-a-Service automatically does that after completing the final step you define. - -##### `strategies..canary.steps.setWeight.weight` - -This is an integer value and determines how much of the cluster the app gets deployed to. The value must be between 0 and 100 and the the `weight` for each `setWeight` step should increase as the deployment progresses. After hitting this threshold, Armory CD-as-a-Service pauses the deployment based on the behavior you set for the `strategies...steps.pause` that follows. - - -For example, this snippet instructs Armory CD-as-a-Service to deploy the app to 33% of the cluster: - -{{< prism lang="yaml" line-numbers="true" >}} -... -steps: - - setWeight: - weight: 33 -{{< /prism >}} - -##### `strategies..canary.steps.pause` - -There are two base behaviors you can set for `pause`, either a set amount of time or until a manual judgment is made. - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - pause: - duration: - unit: -... - - pause: - untilApproved: true - approvalExpiration: - duration: 60 - unit: seconds -{{< /prism >}} - -**Pause for a set amount of time** - -If you want the deployment to pause for a certain amount of time after a weight is met, you must provide both the amount of time (duration) and the unit of time (unit). - -- `strategies..canary.steps.pause.duration` - - Use an integer value for the amount of time. -- `strategies..canary.steps.pause.unit` - - Use `seconds`, `minutes` or `hours` for unit of time. - -For example, this snippet instructs Armory CD-as-a-Service to wait for 30 seconds: - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - pause: - duration: 30 - unit: seconds -{{< /prism >}} - -**Pause until a manual judgment** - -When you configure a manual judgment, the deployment waits when it hits the corresponding weight threshold. At that point, you can either approve the deployment so far and let it continue or roll the deployment back if something doesn't look right. - -- `strategies..canary.steps.pause.untilApproved: true` -- `strategies..canary.steps.pause.requiresRole` (Optional) list of RBAC roles that can issue a manual approval -- `strategies..canary.steps.pause.approvalExpiration` (Optional) time to wait for the approval - if expired, current deployment is cancelled - -For example: - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - pause: - untilApproved: true - requiresRoles: [] - approvalExpiration: - duration: 60 - unit: minutes -{{< /prism >}} - -##### `strategies..canary.steps.analysis` - -The `analysis` step is used to run a set of queries against your deployment. Based on the results of the queries, the deployment can automatically or manually roll forward or roll back. - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - metricProviderName: - context: - keyName: - keyName: - interval: - units: - numberOfJudgmentRuns: - rollBackMode: - rollForwardMode: - queries: - - - - -{{< /prism >}} - -###### `strategies..canary.steps.analysis.metricProviderName` - -Optional. The name of a configured metric provider. If you do not provide a metric provider name, Armory CD-as-a-Service uses the default metric provider defined in the `analysis.defaultMetricProviderName`. Use the **Configuration UI** to add a metric provider. - -###### `strategies..canary.steps.analysis.context` - -Custom key/value pairs that are passed as substitutions for variables to the queries. - -Armory supports the following variables out of the box: - -- `armory.startTimeIso8601` -- `armory.startTimeEpochSeconds` -- `armory.startTimeEpochMillis` -- `armory.endTimeIso8601` -- `armory.endTimeEpochSeconds` -- `armory.endTimeEpochMillis` -- `armory.intervalMillis` -- `armory.intervalSeconds` -- `armory.promQlStepInterval` -- `armory.deploymentId` -- `armory.applicationName` -- `armory.environmentName` -- `armory.replicaSetName` - -If your deployment strategy contains `exposeServices` step, all exposed service preview links are available as part of the `armory.preview` sub-context. -For example, if you create service preview for service `my-http-service` you could access it using `armory.preview.my-http-service`. - -You can supply your own variables by adding them to this section. When you use them in your query, include the `context` prefix. For example, if you create a variable named `owner`, you would use `context.owner` in your query. - -For information about writing queries, see the [Query Reference Guide]({{< ref "ref-queries.md" >}}). - -###### `strategies..canary.steps.analysis.interval` - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - interval: - units: -{{< /prism >}} - -How long each sample of the query gets summarized over. - -For example, the following snippet sets the interval to 30 seconds: - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - interval: 30 - units: seconds - -{{< /prism >}} - -###### `strategies..canary.steps.analysis.units` - -The unit of time for the interval. Use `seconds`, `minutes` or `hours`. See `strategies...steps.analysis.interval` for more information. - -###### `strategies..canary.steps.analysis.numberOfJudgmentRuns` - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - ... - numberOfJudgmentRuns: - ... -{{< /prism >}} - -The number of times that each query runs as part of the analysis. Armory CD-as-a-Service takes the average of all the results of the judgment runs to determine whether the deployment falls within the acceptable range. - -###### `strategies..canary.steps.analysis.rollBackMode` - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - ... - rollBackMode: - ... -{{< /prism >}} - -Optional. Can either be `manual` or `automatic`. Defaults to `automatic` if omitted. - -How a rollback is approved if the analysis step determines that the deployment should be rolled back. The thresholds for a rollback are set in `lowerLimit` and `upperLimit` in the `analysis` block of the deployment file. This block is separate from the `analysis` step that this parameter is part of. - -###### `strategies..canary.steps.analysis.rollForwardMode` - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - ... - rollForwardMode: - ... -{{< /prism >}} - -Optional. Can either be `manual` or `automatic`. Defaults to `automatic` if omitted. - -How a rollback is approved if the analysis step determines that the deployment should proceed (or roll forward). The thresholds for a roll forward are any values that fall within the range you create when you set the `lowerLimit` and `upperLimit`values in the `analysis` block of the deployment file. This block is separate from the `analysis` step that this parameter is part of. - -###### `strategies..canary.steps.analysis.queries` - -{{< prism lang="yaml" line-numbers="true" >}} -steps: -... - - analysis: - ... - queries: - - - - -{{< /prism >}} - -A list of queries that you want to use as part of this `analysis` step. Provide the name of the query, which is set in the `analysis.queries.name` parameter. Note that thee `analysis` block is separate from the `analysis` step. - -All the queries must pass for the step as a whole to be considered a success. - -##### `strategies..canary.steps.exposeServices` - -{{< include "cdaas/deploy/preview-link-details.md" >}} - -#### Blue/green fields - -##### `strategies..blueGreen.activeService` - -The name of a [Kubernetes Service object](https://kubernetes.io/docs/concepts/services-networking/service/) that you created to route traffic to your application. - -{{< prism lang="yaml" line-numbers="true" >}} -strategies: - : - blueGreen: - activeService: -{{< /prism >}} - -##### `strategies..blueGreen.previewService` - -(Optional) The name of a [Kubernetes Service object](https://kubernetes.io/docs/concepts/services-networking/service/) you created to route traffic to the new version of your application so you can preview your updates. - -{{< prism lang="yaml" line-numbers="true" >}} -strategies: - : - blueGreen: - previewService: -{{< /prism >}} - -##### `strategies..blueGreen.redirectTrafficAfter` - -The `redirectTrafficAfter` steps are conditions for exposing the new version to the `activeService`. The steps are executed in parallel. After each step completes, Armory CD-as-a-Service exposes the new version to the `activeService`. - -###### `strategies..blueGreen.redirectTrafficAfter.pause` - -There are two base behaviors you can set for `pause`, either a set amount of time or until a manual judgment is made. - -{{< prism lang="yaml" line-numbers="true" >}} -redirectTrafficAfter: - - pause: - duration: - unit: -{{< /prism >}} - -{{< prism lang="yaml" line-numbers="true" >}} -redirectTrafficAfter: - - pause: - untilApproved: true - approvalExpiration: - duration: 60 - unit: seconds -{{< /prism >}} - -**Pause for a set amount of time** - -If you want the deployment to pause for a certain amount of time, you must provide both the amount of time (duration) and the unit of time (unit). - -- `strategies..blueGreen.redirectTrafficAfter.pause.duration` - - Use an integer value for the amount of time. -- `strategies..blueGreen.redirectTrafficAfter.pause.unit` - - Use `seconds`, `minutes` or `hours` for unit of time. - -For example, this snippet instructs Armory CD-as-a-Service to wait for 30 minutes: - -{{< prism lang="yaml" line-numbers="true" >}} -redirectTrafficAfter: - - pause: - duration: 30 - unit: minutes -{{< /prism >}} - -**Pause until a manual judgment** - -When you configure a manual judgment, the deployment waits for manual approval through the UI. You can either approve the deployment or roll the deployment back if something doesn't look right. Do not provide a `duration` or `unit` value when defining a judgment-based pause. - -- `strategies..blueGreen.redirectTrafficAfter.pause.untilApproved: true` -- `strategies..blueGreen.redirectTrafficAfter.pause.requiresRole` (Optional) list of RBAC roles that can issue a manual approval -- `strategies..blueGreen.redirectTrafficAfter.pause.approvalExpiration` (Optional) time to wait for the approval - if expired, current deployment is cancelled -- -For example: - -{{< prism lang="yaml" line-numbers="true" >}} -redirectTrafficAfter: - - pause: - untilApproved: true - requiresRoles: [] - approvalExpiration: - duration: 60 - unit: minutes -{{< /prism >}} - -###### `strategies..blueGreen.redirectTrafficAfter.analysis` - -The `analysis` step is used to run a set of queries against your deployment. Based on the results of the queries, the deployment can (automatically or manually) roll forward or roll back. - -{{< prism lang="yaml" line-numbers="true" >}} -redirectTrafficAfter: - - analysis: - metricProviderName: - context: - keyName: - keyName: - interval: - unit: - numberOfJudgmentRuns: - rollBackMode: - rollForwardMode: - queries: - - - - -{{< /prism >}} - -##### `strategies..blueGreen.shutdownOldVersionAfter` - -This step is a condition for deleting the old version of your software. Armory CD-as-a-Service executes the `shutDownOldVersion` steps in parallel. After each step completes, Armory CD-as-a-Service deletes the old version. - -{{< prism lang="yaml" line-numbers="true" >}} -shutdownOldVersionAfter: - - pause: - untilApproved: true -{{< /prism >}} - -###### `strategies..blueGreen.shutdownOldVersionAfter.analysis` - -The `analysis` step is used to run a set of queries against your deployment. Based on the results of the queries, the deployment can (automatically or manually) roll forward or roll back. - -{{< prism lang="yaml" line-numbers="true" >}} -shutdownOldVersionAfter: - - analysis: - metricProviderName: - context: - keyName: - keyName: - interval: - units: - numberOfJudgmentRuns: - rollBackMode: - rollForwardMode: - queries: - - - - ` -{{< /prism >}} - -##### `strategies..blueGreen.redirectTrafficAfter.exposeServices` - -{{< include "cdaas/deploy/preview-link-details.md" >}} - -### `analysis.` - -This block defines the queries used to analyze a deployment for any `analysis` steps. In addition, you set upper and lower limits for the queries that define what is considered a failed deployment step or a successful deployment step. - -You can provide multiple queries in this block. The following snippet includes a sample Prometheus query. Note that the example requires the following: - -- `kube-state-metrics.metricAnnotationsAllowList[0]=pods=[*]` must be set -- Your applications pods need to have the annotation `"prometheus.io/scrape": "true"` - -{{< prism lang="yaml" line-numbers="true" >}} -analysis: # Define queries and thresholds used for automated analysis - defaultMetricProviderName: # The name that you assigned a metrics provider in the Configuration UI. - queries: - - name: - upperLimit: # If the metric exceeds this value, the automated analysis fails. - lowerLimit: # If the metric goes below this value, the automated analysis fails. - queryTemplate: >- - - - name: avgCPUUsage - upperLimit: 100 - lowerLimit: 1 - queryTemplate: >- - avg (avg_over_time(container_cpu_system_seconds_total{job="kubelet"}[{{armory.promQlStepInterval}}]) * on (pod) group_left (annotation_app) - sum(kube_pod_annotations{job="kube-state-metrics",annotation_deploy_armory_io_replica_set_name="{{armory.replicaSetName}}"}) - by (annotation_app, pod)) by (annotation_app) - #,annotation_deploy_armory_io_replica_set_name="${canaryReplicaSetName}"}) - #${ARMORY_REPLICA_SET_NAME} - #,annotation_deploy_armory_io_replica_set_name="${ARMORY_REPLICA_SET_NAME}" - #${replicaSetName} - #${applicationName} - # note the time should actually be set to ${promQlStepInterval} -{{< /prism >}} - -You can insert variables into your queries. Variables are inserted using the format `{{key}}`. The example query includes the variable `armory.replicaSetName`. Variables that Armory supports can be referenced by `{{armory.VariableName}}`. Custom defined variables can be referenced by `{{context.VariableName}}`. - -For more information, see the [`analysis.context` section](#strategiesstrategynamestrategystepsanalysiscontext). - -#### `analysis.defaultMetricProviderName` - -The name that you assigned to a metrics provider in the **Configuration UI**. If the analysis step does not specify a metrics provider, the default metrics provider is used. - -#### `analysis.queries` - -This block is how you define the queries that you want to run. - -##### `analysis.queries.name` - -Used in `analysis` steps to specify the query that you want to use for the step. Specifically it's used for the list in `steps.analysis.queries`. - -Provide a unique and descriptive name for the query, such as `containerCPUSeconds` or `avgMemoryUsage`. - -##### `analysis.queries.upperLimit` - -The upper limit for the query. If the analysis returns a value that is above this range, the deployment is considered a failure, and a rollback is triggered. The rollback can happen either manually or automatically depending on how you configured `strategies...steps.analysis.rollBackMode`. - -If the query returns a value that falls within the range between the `upperLimit` and `lowerLimit` after all the runs of the query complete, the query is considered a success. - -##### `analysis.queries.lowerLimit` - -The lower limit for the query. If the analysis returns a value that is below this range, the deployment is considered a failure, and a rollback is triggered. The rollback can happen either manually or automatically depending on how you configured `strategies...steps.analysis.rollBackMode`. - -If the query returns a value that falls within the range between the `upperLimit` and `lowerLimit` after all the runs of the query, the query is considered a success. - -##### `analysis.queries.queryTemplate` - -{{< prism lang="yaml" line-numbers="true" >}} -analysis: # Define queries and thresholds used for automated analysis - queries: - - name: - upperLimit: # If the metric exceeds this value, the automated analysis fails. - lowerLimit: # If the metric goes below this value, the automated analysis fails. - queryTemplate: >- - - - name: avgCPUUsage # example query - upperLimit: 100 - lowerLimit: 1 - queryTemplate: >- - avg (avg_over_time(container_cpu_system_seconds_total{job="kubelet"}[{{armory.promQlStepInterval}}]) * on (pod) group_left (annotation_app) - sum(kube_pod_annotations{job="kube-state-metrics",annotation_deploy_armory_io_replica_set_name="{{armory.replicaSetName}}"}) - by (annotation_app, pod)) by (annotation_app) - #,annotation_deploy_armory_io_replica_set_name="${canaryReplicaSetName}"}) - #${ARMORY_REPLICA_SET_NAME} - #,annotation_deploy_armory_io_replica_set_name="${ARMORY_REPLICA_SET_NAME}" - #${replicaSetName} - #${applicationName} - # note the time should actually be set to ${promQlStepInterval} -{{< /prism >}} - -The query you want to run. See the {{< linkWithTitle "cd-as-a-service/tasks/canary/retro-analysis.md" >}} guide for details on how to build and test queries using the UI. - -For information about writing queries, see {{< linkWithTitle "ref-queries.md" >}}. - -When writing queries, you can use key/value pairs that are passed as substitutions for variables to the queries. - -Armory supports the following variables out of the box: - -- `armory.startTimeIso8601` -- `armory.startTimeEpochSeconds` -- `armory.startTimeEpochMillis` -- `armory.endTimeIso8601` -- `armory.endTimeEpochSeconds` -- `armory.endTimeEpochMillis` -- `armory.intervalMillis` -- `armory.intervalSeconds` -- `armory.promQlStepInterval` -- `armory.deploymentId` -- `armory.applicationName` -- `armory.environmentName` -- `armory.replicaSetName` - -If your deployment strategy contains `exposeServices` step, all exposed service preview links are available as part of the `armory.preview` sub-context. -For example, if you create service preview for service `my-http-service` you could access it using `armory.preview.my-http-service`. - -You can supply your own variables by adding them to the `strategies...steps.analysis.context`. When you use them in your query, include the `context` prefix. For example, if you create a variable named `owner`, you would use `{{context.owner}}` in your query. - - -### `webhooks.` - -See {{< linkWithTitle "cd-as-a-service/tasks/webhook-approval.md" >}} for a detailed example. - -{{< include "cdaas/dep-file/webhooks-config.md" >}} - -### `trafficManagement.` - -You configure your service mesh per target in this section. If you omit the `target` entry, CD-as-a-Service applies the config to all targets. - -{{< prism lang="yaml" line-numbers="true" >}} -trafficManagement: - - targets: [""] -{{< /prism >}} - -#### `trafficManagement.targets.smi` - -{{< include "cdaas/dep-file/tm-smi-config.md" >}} - - -#### `trafficManagment.targets.istio` - -See {{< linkWithTitle "cd-as-a-service/tasks/deploy/traffic-management/istio.md" >}} for a detailed example. - -{{< include "cdaas/dep-file/tm-istio-config.md" >}} - - diff --git a/content/en/cd-as-a-service/reference/ref-queries.md b/content/en/cd-as-a-service/reference/ref-queries.md deleted file mode 100644 index 2a10b6404f..0000000000 --- a/content/en/cd-as-a-service/reference/ref-queries.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: Query Reference Guide -linkTitle: Queries -description: > - Armory CD-as-a-Service has different requirements for how queries are formatted and what kind of data can get returned based on the metrics provider you use for automated canary analysis. This guide provides basic information about what Armory CD-as-a-Service needs for each provider. -categories: ["Reference"] -tags: ["Deployment", "Deploy Strategy", "Canary"] ---- - -## Automated canary analysis - -When Armory CD-as-a-Service performs automated canary analysis, Armory CD-as-a-Service runs queries against a metrics provider to either progress a deployment or roll it back based on thresholds you set. Armory CD-as-a-Service supports the following metrics providers: - -- Datadog -- New Relic -- Prometheus - -For information about using queries in your deploy file, see the following resources: - -- [Add queries to your deploy file]({{< ref "ref-deployment-file#analysisqueries" >}}) -- [Use a query in a deployment step]({{< ref "ref-deployment-file#strategiesstrategynamestrategystepsanalysis" >}}) - -## Query variables - -You can use variables in the query templates you define in the `analysis.queries.queryTemplate` block of your deployment file. Armory provides a basic set of variables that can be used for all the metrics providers, but you can configure additional ones. - -### Armory-provided variables - -Armory provides some metrics by default on all canary analysis requests. These variables are all prefixed with `armory` and are surrounded by `{{}}`. For example, to use `applicationName` variable that Armory supplies, you use the following snippet in the query template: `{{armory.applicationName}}`. - -Armory provides the following variables: - -| Variable | Annotation | Environment variable | Notes | -|--------------------------|-------------------------------------|---------------------------|-----------------------------------------------------------------------------| -| applicationName | `deploy.armory.io/application` | `ARMORY_APPLICATION_NAME` | Added as annotation resources and as environment variables on pods* | -| deploymentId | `deploy.armory.io/deployment-id` | `ARMORY_DEPLOYMENT_ID` | Added as annotation resources and as environment variables on pods* | -| environmentName | `deploy.armory.io/environment` | `ARMORY_ENVIRONMENT_NAME` | Added as annotation resources and as environment variables on pods* | -| replicaSetName | `deploy.armory.io/replica-set-name` | `ARMORY_REPLICA_SET_NAME` | Added as annotation resources and as environment variables on pods* | -| accountName | - | - | The name of the account (or agentIdentifier) used to execute the deployment | -| namespace | - | - | The namespace resources are being deployed to | -| promQlStepInterval | - | - | Used to aggregate PromQL functions to a single value | -| intervalSeconds | - | - | Length of the current query interval in seconds | -| intervalMillis | - | - | Length of the current query interval in milliseconds | -| endTimeEpochMillis | - | - | Exact end time of the current query interval in epoch milliseconds format | -| endTimeEpochSeconds | - | - | Exact end time of the current query interval in epoch seconds format | -| endTimeIso8601 | - | - | Exact end time of the current query interval in ISO 8601 format | -| startTimeEpochMillis | - | - | Exact start time of the current query interval in epoch milliseconds format | -| startTimeEpochSeconds | - | - | Exact start time of the current query interval in epoch seconds format | -| startTimeIso8601 | - | - | Exact start time of the current query interval in ISO 8601 format | -| preview.`` | - | - | URL to the `Service` resource exposed via `exposeServices` step** | - -`*`If you are using a metrics implementation like [Micrometer](https://micrometer.io/), make sure to configure it to report these metrics to your metrics provider. - -`**`Service preview links are scoped to the strategy and `afterDeployment` constraints section. Do consider adjusting preview link's TTL property, otherwise you may end up -serving links which have already expired. - - -### Custom variables - -In addition to the Armory provided variables, you can define additional custom ones. These are added to the `strategies..canary.steps.analysis.context` section of your deployment file: - -``` -strategies: - ... - canary: - steps: - ... - - analysis: - ... - context: - - : -``` - -They need to be defined for each analysis step that uses a query referencing them. - -In query templates, you reference them with the following format: `{{context.}}`. For example, if you created a variable called `owner`, you reference it in the query template with `{{context.owner}}`. - -## Query template requirements - -Regardless of metrics provider, all queries require the following: - -- **Must return a single result**. Automated canary analysis does not support queries that return multiple values -- Must be defined in `analysis.queries.queryTemplate` - -### Datadog queries - -Datadog queries cannot be a time-series query. This means that you need to include the `.rollup(method, {{armory.intervalSeconds}})` method in your query. - -For more information on Datadog queries, see [the Datadog documentation](https://docs.datadoghq.com/tracing/trace_explorer/query_syntax/). - -#### Sample Datadog query - -```sql -avg:jvm.memory.used{name:{{armory.applicationName}} - AND {{armory.replicaSetName}}}.rollup(avg, {{armory.intervalSeconds}}) / avg:jvm.memory.max{name:{{armory.applicationName}} - AND {{armory.replicaSetName}}}.rollup(avg, {{armory.intervalSeconds}}) * 100 -``` - -### New Relic queries - -New Relic queries must meet the following requirements: - -* Must include an `UNTIL` clause in your query that specifies the start and end of the canary interval - * For example, include a clause similar to the following clause: `SINCE '{{armory.startTimeIso8601}}' UNTIL '{{armory.endTimeIso8601}}` -* Cannot contain the ‘TIMESERIES’ clause - -For information on New Relic’s Query Language, see the [New Relic documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/). - -#### Sample New Relic query - -```sql -SELECT average(jvm.memory.used) / average(jvm.memory.max) * 100 FROM Metric - WHERE name = '{{armory.applicationName}}' AND replicaSetName = '{{armory.replicaSetName}}' - SINCE '{{armory.startTimeIso8601}}' UNTIL '{{armory.endTimeIso8601}}' -``` - -### Prometheus queries - -Prometheus queries must return results as a time stamp value pair. - -For information on Prometheus queries, see [the Prometheus documentation](https://prometheus.io/docs/prometheus/latest/querying/basics/). - -##### Sample Prometheus query - -```sql -avg(avg_over_time(jvm_memory_used_bytes{app="{{armory.applicationName}}",replicaSet="{{armory.replicaSetName}}"}[{{armory.promQlStepInterval}}])) / - avg(avg_over_time(jvm_memory_max_bytes{app="{{armory.applicationName}}",replicaSet="{{armory.replicaSetName}}"}[{{armory.promQlStepInterval}}])) * 100 -``` \ No newline at end of file diff --git a/content/en/cd-as-a-service/release-notes/_index.md b/content/en/cd-as-a-service/release-notes/_index.md deleted file mode 100644 index f1c5ebeb2a..0000000000 --- a/content/en/cd-as-a-service/release-notes/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Release Notes -weight: 999 -description: > - System requirements, release notes, and known issues for Armory Continuous Deployment-as-a-Service. ---- diff --git a/content/en/cd-as-a-service/release-notes/known-issues.md b/content/en/cd-as-a-service/release-notes/known-issues.md deleted file mode 100644 index 98364b34f4..0000000000 --- a/content/en/cd-as-a-service/release-notes/known-issues.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Known Issues and Limitations - ---- - -## Deployment fails with a blank namespace error - -There is a known issue where deployments fail if you do not specify a namespace in `targets..namespace` in your deployment file even if your manifest specifies a namespace. - -**Workaround**: - -Define the namespace in your deployment file even if your manifest specifies a namespace. - -## Manifest requirements - -{{< include "cdaas/ki-manifest-limitation.md" >}} - -## `armory.cloud` config block location - -In Armory Continuous Deployment 2.26.3, the location of where you put the `armory.cloud` block as well as an additional `plugins` block when configuring the Armory CD-as-a-Service Spinnaker Plugin is different from other versions. This issue affects both Operator and Halyard based installations of Armory Continuous Deployment. - -For more information, see the [known issues for the Spinnaker plugin]({{< ref "plugin-spinnaker#armorycloud-block-location" >}}). \ No newline at end of file diff --git a/content/en/cd-as-a-service/release-notes/release-notes.md b/content/en/cd-as-a-service/release-notes/release-notes.md deleted file mode 100644 index b85c3cf8c8..0000000000 --- a/content/en/cd-as-a-service/release-notes/release-notes.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Armory Continuous Deployment-as-a-Service Release Notes -linkTitle: Release Notes -description: > - Information about new features and changes, fixes, and improvements in Armory Continuous Deployment-as-a-Service. -manualLink: "https://armory.releases.live/?filter=eyJ0aXRsZU9yRGVzY3JpcHRpb24iOiIiLCJzY29wZSI6WyJDRC1hcy1hLVNlcnZpY2UiXSwidHlwZSI6W10sImZpZWxkcyI6W119" -manualLinkTarget: "_blank" ---- - - \ No newline at end of file diff --git a/content/en/cd-as-a-service/setup/_index.md b/content/en/cd-as-a-service/setup/_index.md deleted file mode 100644 index 5e8a6616cf..0000000000 --- a/content/en/cd-as-a-service/setup/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Get Started with Armory CD-as-a-Service -linkTitle: Get Started -description: > - Armory CD-as-a-Service is a software deployment tool that you can use to deploy Kubernetes applications. -weight: 10 ---- diff --git a/content/en/cd-as-a-service/setup/argo-rollouts.md b/content/en/cd-as-a-service/setup/argo-rollouts.md deleted file mode 100644 index fff519e5ae..0000000000 --- a/content/en/cd-as-a-service/setup/argo-rollouts.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: Get Started with Argo Rollouts Deployment -linkTitle: Argo Rollouts Deployment -description: > - Use Armory CD-as-a-Service to deploy Argo Rollout Objects across multiple environments. -weight: 40 -categories: ["Get Started"] -tags: ["Argo Rollouts", "Deployment"] ---- - -## Objectives - -In this guide, you learn how to use Argo Rollouts with Armory CD-as-a-Service. - -1. [Create a CD-as-a-Service deployment config file](#create-a-cd-as-a-service-deployment-config-file) -1. [Add your Rollout manifest](#add-your-rollout-manifest) -1. [Deploy your app](#deploy-your-app) -1. [Extend deployment functionality](#extend-functionality-for-rollout-deployments) to use webhooks and to deploy multiple rollouts - -## {{% heading "prereq" %}} - -Make sure that you have performed the following steps: - -- Connected to your Kubernetes cluster and deployed an app using the CLI. See {{< linkWithTitle "cd-as-a-service/setup/quickstart.md" >}}. - -To complete this guide, you need the following: - -- Access to a Kubernetes cluster where you have installed the Remote Network Agent (RNA). This cluster acts as the deployment target for the sample app. (Optional) You can connect multiple Kubernetes clusters to deploy to multiple environments -- One or more [Argo Rollout manifests](https://argoproj.github.io/argo-rollouts/features/specification/). For example: - - {{< prism lang="yaml" >}} - # rollout.yaml - apiVersion: argoproj.io/v1alpha1 - kind: Rollout - metadata: - name: example - spec: - replicas: 5 - ... - {{< /prism >}} - -## Create a CD-as-a-Service deployment config file - -Create a file called `armoryDeployment.yaml` with the following contents: - -{{< prism lang="yaml" >}} -# armoryDeployment.yaml -version: v1 -kind: kubernetes -application: -targets: - staging: - account: # Name of the cluster you entered when installing the RNA. - namespace: - production: - account: - namespace: - constraints: - dependsOn: [staging] - beforeDeployment: - - pause: - untilApproved: true -manifests: - - path: -{{< /prism >}} - -This example includes multiple targets. You can remove or add targets to match your environment. - -Be sure to replace ``, ``, and `` placeholders with your own values. - -See {{< linkWithTitle "cd-as-a-service/tasks/deploy/create-deploy-config.md" >}} if you want to create a more robust deployment config file. -The {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} page contains explanations of the fields. - -## Add your Rollout manifest - -1. Go to the `manifests` section in your deployment config file. -1. Add your Argo Rollout manifests in the `manifests[].path` section: - - {{< prism lang="yaml" line="5-6" >}} - # armoryDeployment.yaml - version: v1 - kind: kubernetes - ... - manifests: - - path: rollout.yaml - {{< /prism >}} - - -## Deploy your app - -1. Ensure you have logged into CD-as-a-Service: - - {{< prism lang="bash" >}} - armory login - {{< /prism >}} - - -1. Start your deployment using the Armory CLI: - - {{< prism lang="bash" >}} - armory deploy start -f armoryDeployment.yaml --watch - {{< /prism >}} - - Remove the `--watch` flag if you don't want to output deployment status in your terminal. - - ->If you are only deploying Argo Rollouts, CD-as-a-Service ignores any strategy you configure in your deployment config file. The Rollout follows the strategy defined in the Rollout manifest. - -## Extend functionality for Rollout deployments - -### Run integration tests using webhooks - -You can use webhooks in `afterDeployment` constraints to add specific logic for Argo Rollouts to finish deploying before starting integration tests. For example: - -{{< prism lang="yaml" line="9-12, 15-28" >}} - # armoryDeployment.yaml -version: v1 -kind: kubernetes -application: my-application -targets: - staging: - account: staging - namespace: default - constraints: - afterDeployment: - - runWebhook: - name: Refer to Argo Rollouts for status -manifests: - - path: rollout.yaml -webhooks: - - name: Refer to Argo Rollouts for status - method: POST - uriTemplate: http://cmd-hook.default:8081/cmd - networkMode: remoteNetworkAgent - agentIdentifier: - retryCount: 3 - bodyTemplate: - inline: >- - { - "cmd": "kubectl", - "arg": "wait -n=default rollout/example --for=condition=Completed --timeout=30m", - "callbackURL": "{{armory.callbackUri}}/callback" - } -{{< /prism >}} - -### Deploy multiple Argo Rollouts - -To deploy multiple Argo Rollouts together, you can add more paths to the `manifests` section of the deployment config file: - -{{< prism lang="yaml" >}} -manifests: - - path: rollout-1.yaml - - path: rollout-2.yaml - - path: rollout-3.yaml -{{< /prism >}} - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/tools.md" >}} -* {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} -* {{< linkWithTitle "cd-as-a-service/concepts/external-automation.md" >}} -* {{< linkWithTitle "cd-as-a-service/tasks/webhook-approval.md" >}} diff --git a/content/en/cd-as-a-service/setup/blue-green.md b/content/en/cd-as-a-service/setup/blue-green.md deleted file mode 100644 index 3b12de5ab2..0000000000 --- a/content/en/cd-as-a-service/setup/blue-green.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Get Started with Blue/Green Deployment -linkTitle: Blue/Green Deployment -description: > - This guide walks you through how to deploy using a blue/green strategy. -weight: 40 -categories: ["Get Started"] -tags: ["Deployment", "Deploy Strategy", "Blue/Green"] ---- - -## Blue/Green deployment overview - -A blue/green strategy shifts traffic from the running version of your software to a new version of your software. The Armory CD-as-a-Service blue/green strategy follows these steps: - -1. Armory CD-as-a-Service deploys a new version of your software without exposing it to external traffic. -1. Armory CD-as-a-Service executes one or more user-defined steps in parallel. These steps are pre-conditions for exposing the new version of your software to traffic. For example, you may want to run automated metric analysis or wait for manual approval. -1. After all pre-conditions complete successfully, Armory CD-as-a-Service redirects all traffic to the new software version. At this stage of the deployment, the old version of your software is still running but is not receiving external traffic. -1. Next, Armory CD-as-a-Service executes one or more user-defined steps in parallel. These steps are pre-conditions for tearing down the old version of your software. For example, you may want to pause for an hour or wait for an additional automated metric analysis. -1. After all pre-conditions complete successfully, Armory CD-as-a-Service tears down the old version of your software. - -## {{% heading "prereq" %}} - -This quick start assumes that you completed the prior two quick starts that taught you how to register a cluster with Armory CD-as-a-Service and how to deploy an app with the CLI. - -To complete this quick start, you need the following: - -- Access to a Kubernetes cluster where you can install the Remote Network Agent (RNA). This cluster acts as the deployment target for the sample app. You can reuse the cluster from the previous quick starts or create a new one. -- You need to deploy a [Kubernetes Service object](https://kubernetes.io/docs/concepts/services-networking/service/) that sends traffic to the current version of your application. This is the `trafficManagement.kubernetes.activeService` field in the YAML configuration. -- (Optional) You can also create a `previewService` Kubernetes Service object so you can programmatically or manually observe the new version of your software before exposing it to traffic via the `activeService`. This is the `trafficManagement.kubernetes.previewService` field in the YAML configuration. - -## Add blue/green to your deployment - -1. In your deploy file, go to the `strategies` section. -1. Create a new strategy named `blue-green-deploy-strat` like the following: - - ```yaml - strategies: - blue-green-deploy-strat - blueGreen: - redirectTrafficAfter: - - pause: - untilApproved: true - shutDownOldVersionAfter: - - pause: - untilApproved: true - ``` - - See the [Deployment File Reference]({{< ref "ref-deployment-file#bluegreen-fields" >}}) for an explanation of these fields. - - This strategy is configured to pause for manual judgment before redirecting traffic to your new app version as well as before shutting down your old version. You could instead choose to pause for a duration of time. - -1. Change the value of `targets..strategy` for one or more of your deployment targets to `blue-green-deploy-strat`. - - ```yaml - ... - targets: - : - account: - namespace: - strategy: blue-green-deploy-strat - ... - ``` -1. At the bottom of your file, create a top-level traffic management configuration for your `activeService` and `previewService`: - - ```yaml - ... - trafficManagement: - - targets: [''] - kubernetes: - - activeService: myAppActiveService - previewService: myAppPreviewService - ... - ``` - - The values for `activeService` and `previewService` must match the names of the Kubernetes Service objects you created to route traffic to the current and preview versions of your application. See the [Deployment File Reference]({{< ref "ref-deployment-file#traffic-managment" >}}) for an explanation of these fields. - -1. Save the file - -## Redeploy your app - -Make a change to your app, such as the number of replicas, and redeploy it with the CLI: - -```bash -armory deploy start -f .yaml -``` - -Monitor the progress and **Approve & Continue** or **Roll back** the blue/green deployment in the UI. - - - diff --git a/content/en/cd-as-a-service/setup/canary.md b/content/en/cd-as-a-service/setup/canary.md deleted file mode 100644 index b854f0adaf..0000000000 --- a/content/en/cd-as-a-service/setup/canary.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -title: Get Started with Canary Analysis -linktitle: Canary Analysis -description: > - This guide walks you through using canary analysis on the app you deployed in the Get Started with the CLI to Deploy Apps guide. You perform a retrospective analysis on the app. Then, you use those queries to create canary analysis steps for subsequent deployments. -weight: 40 -categories: ["Get Started"] -tags: ["Deployment", "Deploy Strategy", "Canary"] ---- - -Performing retrospective analysis on a deployment is a great way to understand how your app is performing over a predefined time period. It is the first step to enabling automatic canary analysis where you create queries that control how canary deployments react based on metrics you consider important. - -The examples in this guide use Prometheus as the metrics provider. - -## {{% heading "prereq" %}} - -You have completed the following guides: - -1. {{< linkWithTitle "cd-as-a-service/setup/quickstart.md" >}} -1. {{< linkWithTitle "cd-as-a-service/setup/deploy-your-app.md" >}} - -You need the following to work through this guide: - -- Access to a Kubernetes cluster where you can install the Remote Network Agent (RNA). This cluster acts as the deployment target for the sample app. You can reuse the clusters from the previous quick starts if you want. Or stand up new ones. -- A Prometheus instance set up to monitor your Kubernetes clusters. Keep the following in mind: - - - Armory recommends your Prometheus instance uses the following settings: `"prometheus.io/scrape": "true"` (on by default) and `kube-state-metrics.metricAnnotationsAllowList[0]=pods=[*]` (collect annotations). These flags instruct Prometheus to collect all Kubernetes annotations, which allow you to reference the annotations that Armory CD-as-a-Service injects as part of your query. - - If you install Prometheus with Helm, this example command includes the required flag: - - ```yaml - helm upgrade --install prometheus prometheus-community/kube-prometheus-stack --set 'kube-state-metrics.metricAnnotationsAllowList[0]=pods=[*]' - ``` - - - It is either accessible by the public internet or you have installed the Remote Network Agent (RNA) in the same cluster. - - For information about how to install Prometheus, see the the [Prometheus documentation](https://prometheus.io/docs/prometheus/latest/installation/). - - -## Add your metrics provider - -Armory CD-as-a-Service can run queries against metrics providers that you add. The results are examined as part of canary analysis steps in the deploy file. - -1. In the **Configuration UI**, go to [**Canary Analysis > Integrations**](https://console.cloud.armory.io/configuration/metric-source-integrations/). -2. Select **New Integration**. - - The examples in this guide use Prometheus as the metrics provider. - -3. Complete the wizard: - - The parameters you need to provide depend on the metrics provider you choose. For more information, see the {{< linkWithTitle "cd-as-a-service/tasks/canary/add-integrations.md" >}} guide. - - The following fields are for a Prometheus integration: - - - **Type**: (Required) Your metrics provider. This example uses Prometheus. The form options change based on your provider. - - **Name**: (Required) A descriptive name for your metrics provider, such as the environment it monitors. You use this name in places such as your deploy file when you want to configure canary analysis as part of your deployment strategy. - - **Base URL**: (Required) The base URL for your Prometheus instance. If Prometheus runs in the same cluster as the RNA and is exposed using HTTP on port 9090 through a service named `prometheus` in the namespace `prometheus`, then use `http://prometheus.prometheus:9090`. (This can be a private DNS only if the RNA is installed in the same cluster as the Prometheus instance.) - - **Remote Network Agent**: (Optional) The RNA that is installed in the Prometheus cluster if the cluster is not publicly accessible. Select the identifier for the RNA from the dropdown. - - **Authentication Type**: (Required) Select **None**, **Username/Password**, or **Bearer Token**. - - - If you selected **Username/Password**: Fill in the username for accessing Prometheus and select the password secret. - - If you selected **Bearer Token**: Select the token secret from the drop-down list. - -## Perform a retrospective analysis - -Retrospective analysis is the starting point to creating queries so that you can perform canary analysis on your deployments. The UI gives you a structured way to create a query and test it against previous deployments. When ready, you can export it so that you can add the query to your deploy file easily. - -1. In the **Configuration UI**, go to [**Canary Analysis > Retrospective Analysis**](https://console.cloud.armory.io/configuration/metric-source-integrations/). -2. Select the metric provider you just configured. -3. Select a time range that includes when you deployed your app. -4. Add a **Query Template**. Use the following example: - - - **Name**: avgCPUUsage - - **Upper Limit**: The upper limit for the query. If the results exceed this value, the deployment is considered to be a failure. Set this to `10000`. - - **Lower Limit**: The lower limit for the query. If the results fall below this value, the deployment is considered to be a failure. Set this to `0`. - - **Query Template**: - - ``` - avg(avg_over_time(container_cpu_system_seconds_total{job="kubelet"}[{{armory.promQlStepInterval}}]) * on (pod) group_left (annotation_app) - sum(kube_pod_annotations{job="kube-state-metrics",annotation_deploy_armory_io_replica_set_name="{{armory.replicaSetName}}"}) by (annotation_app, pod)) by (annotation_app) - ``` - - - **The query must return a single result**. Automated canary analysis does not support queries that return multiple values. See [Query template requirements]({{< ref "ref-queries#query-template-requirements" >}}) for restrictions and provider examples. - - The query contains variables that are automatically injected during canary analysis, but you must manually provide some of them during retrospective analysis. - - Time related variables like `armory.promqlStepInterval` are automatically substituted by Armory CD-as-a-Service. For a full list, see the {{< linkWithTitle "cd-as-a-service/tasks/canary/retro-analysis.md" >}} guide. - - `armory.replicaSetName` needs to be set to the name of the ReplicaSet that Armory CD-as-a-Service created for this app version. It's used to differentiate between the current and next version of the app. Do this in the next step where you add key/value pairs. - -5. Add **Key Value (KV) Pair** for the **Context**. The key value pairs for your For the sample query, you need to add the following key value Pair: - - - **Key**: `replicaSetName` - - **Value**: The name of the ReplicaSet that was created when you deployed the app in *Get Started with the CLI to Deploy Apps* guide. - -6. Run the analysis. If the results fall within the upper and lower limits you set, the deployment is considered a success. - -### Export and add a query to your deploy file - -The Retrospective Analysis can take the query you provide and generate the YAML equivalent that you can use it in your deploy file. - -1. From the analysis screen, select **Go back to Analysis Configuration**. -2. Click **Export Queries for Armory Deployments**. This creates the YAML block for the `analysis` portion of a deploy file. -3. Insert the YAML block into your deploy file at the bottom. For example: - - ```yaml - analysis: - queries: - - name: avgCPUUsage - upperLimit: 10000 - lowerLimit: 0 - queryTemplate: >- - avg (avg_over_time(container_cpu_system_seconds_total{job="kubelet"}[{{armory.promQlStepInterval}}]) * on (pod) group_left (annotation_app) - sum(kube_pod_annotations{job="kube-state-metrics",annotation_deploy_armory_io_replica_set_name="{{armory.replicaSetName}}"}) - by (annotation_app, pod)) by (annotation_app) - ``` - -For a detailed explanation of these fields, see the [Deployment File Reference]({{< ref "ref-deployment-file#analysis" >}}) - -The `avgCPUUsage` query is now available for you to use in the `steps` block of your deploy file to perform canary analysis. - -## Add canary analysis to your deployment - -Armory CD-as-a-Service supports manual and automated canary analysis. Manual canary analysis allows you to review the canary results until you have confidence that your queries are making good decisions around service health. - -Adding canary analysis to your deployment involves updating your deploy file to include the following: - -- An `analysis` block that describes what queries to use and how they are run. The YAML for the queries is what you can export from the UI. You did this in [Export and add a query to your deploy file](#export-and-add-a-query-to-your-deploy-file). -- Steps in your `strategy` block that perform canary analysis and define how it behaves. - -1. In your deploy file, go to the `strategies` section. -2. Create a new strategy named `canary-deploy-strat` like the following: - - ```yaml - strategies: - canary-deploy-strat - canary: - steps: - - setWeight: - weight: 50 - - analysis: - interval: 10 - units: seconds - numberOfJudgmentRuns: 3 - rollBackMode: manual - rollForwardMode: manual - queries: # The queries to run - - avgCPUUsage - - setWeight: - weight: 75 - - analysis: - interval: 10 - units: seconds - numberOfJudgmentRuns: 3 - rollBackMode: manual - rollForwardMode: manual - queries: - - avgCPUUsage - ``` - - For a detailed explanation of these fields, see the [Deployment File Reference]({{< ref "ref-deployment-file#strategies" >}}) - - This strategy deploys the app to 50% of the cluster and then performs a canary analysis with the following characteristics: - - - The interval for each run of the query is 10 seconds. - - The number of runs of the query is 3. - - Rolling a deployment back or forward is done manually using the Deployments UI. - - It uses the query `containerCPUSeconds`. - - The strategy then deploys the app to 75% of the cluster and then performs a canary analysis. After the roll forward is approved, Armory CD-as-a-Service deploys the app to 100% of the cluster. - -3. Change the value of `targets..strategy` for one or more of your deployment targets to `canary-deploy-strat`. - - ```yaml - ... - targets: - : - account: - namespace: - strategy: canary-deploy-strat - ... - ``` -4. Save the file - -## Redeploy your app - -Make a change to your app, such as the number of replicas, and redeploy it with the CLI: - -```bash -armory deploy start -f .yaml -``` - -Monitor the progress and approve the canary steps in the UI. - -### Go from manual to automated - -Once you have confidence in your queries, switching from manual approvals of canary steps to automatic approvals involves updating the `analysis` steps in your strategy. You can either comment out the `rollBackMode` and `rollForwardMode` fields or set them to `automatic`. Subsequent deployments using the updated deploy file will progress the deployment automatically if the canary analysis steps pass. diff --git a/content/en/cd-as-a-service/setup/deploy-your-app.md b/content/en/cd-as-a-service/setup/deploy-your-app.md deleted file mode 100644 index 3dd52e9c39..0000000000 --- a/content/en/cd-as-a-service/setup/deploy-your-app.md +++ /dev/null @@ -1,227 +0,0 @@ ---- -title: Deploy Your Own App -linkTitle: Deploy Your Own App -description: > - Create a deployment config file for your app. Deploy two versions of your app to your Kubernetes cluster using Armory CD-as-a-Service. -weight: 20 -categories: ["Get Started"] -tags: ["Deployment", "Quickstart"] ---- - -## Learning objectives - -In this guide, you build on what you learned in the CD-as-a-Service [Quickstart]({{< ref "cd-as-a-service/setup/quickstart" >}}) by deploying your own app using the deployment configuration from the Quickstart. - -1. [Create your deployment config file](#create-a-deployment-config-file) -1. [Deploy your app](#deploy-your-app) - - ->If you prefer a web-based, interactive tutorial, see the CD-as-a-Service Console's [**Deploy Your Own App** tutorial](https://next.console.cloud.armory.io/getting-started). - -## {{% heading "prereq" %}} - -* You have completed the CD-as-a-Service [Quickstart]({{< ref "cd-as-a-service/setup/quickstart" >}}). -* You have created the Kubernetes manifests for your web app. -* You have two versions of your app to deploy. - -For this guide, you can use the Remote Network Agent that you created as part of the Quickstart. Instead of deploying Armory's sample app, you deploy your own web app using the CD-as-a-service deployment configuration from the Quickstart. - -### Directory structure - -This guide assumes the following directory structure: - -``` - -├── deployment.yaml -└── manifests -    ├── -service.yaml -    ├── .yaml -    ├── namespace-staging.yaml -    └── namespace-prod.yaml -``` - -The Kubernetes manifests for deploying your app are in the `manifests` directory. Replace `` with the name of your app. - -Create your staging namespace in `namespace-staging.yaml` and your prod namespace in `namespace-prod.yaml`. The deployment config file supports deploying manifests to specific targets, and the deployment config file uses separate namespace manifests to illustrate this feature. - -## Create your deployment config file - -This deployment config defines the following strategies: - -* `rolling`: deploy 100% of the app (staging) -* `trafficSplit`: 75% to the current version and 25% to the new version (prod) - -In addition, prod deployment requires a manual approval to begin deployment and another to continue deployment after the traffic split. - -Create a `deployment.yaml` file with the following contents: - -```yaml -version: v1 -kind: kubernetes -application: -targets: - staging: - account: # the name you gave the RNA when you installed it in your staging cluster - namespace: # defined in namespace-staging.yaml - strategy: rolling - prod: - account: # the name you gave the RNA when you installed it in your prod cluster - namespace: # defined in namespace-prod.yaml - strategy: trafficSplit - constraints: - dependsOn: ["staging"] - beforeDeployment: - - pause: - untilApproved: true -manifests: - - path: manifests/my-app.yaml - - path: manifests/my-app-service.yaml - - path: manifests/namespace-staging.yaml - targets: ["staging"] - - path: manifests/namespace-prod.yaml - targets: ["prod"] -strategies: - rolling: - canary: - steps: - - setWeight: - weight: 100 - trafficSplit: - canary: - steps: - - setWeight: - weight: 25 - - exposeServices: - services: - - - ttl: - duration: 30 - unit: minutes - - pause: - untilApproved: true - - setWeight: - weight: 100 -``` - -* Replace `account` and `namespace` values with those specific to your environment. -* Replace `` with your app name (or the names of your manifest file) - -{{% alert title="Important" color="warning" %}} -For the first deployment of your app, Armory CD-as-a-Service automatically deploys the app to 100% of the cluster since there is no previous version. Subsequent deployments of your app follow the strategy steps defined in your deployment file. -{{% /alert %}} - -## Deploy your app - -{{% alert title="Important" color="warning" %}} -Armory CD-as-a-Service manages your Kubernetes deployments using ReplicaSet resources. During the initial deployment of your app, CD-as-a-Service deletes the underlying Kubernetes deployment object in a way that leaves behind the ReplicaSet and pods so that there is no actual downtime for your app. These are later deleted when the deployment succeeds. - -If your initial deployment fails, you should [manually delete]({{< ref "cd-as-a-service/troubleshooting/tools#initial-deployment-failure-orphaned-replicaset" >}}) the orphaned ReplicaSet. -{{% /alert %}} - -### Deploy first version - -1. Log in using the CLI. - - ```bash - armory login - ``` - - The CLI returns a `Device Code` and opens your default browser. Confirm the code in your browser to complete the login process,. - -1. Start the deployment from the root of your directory. - - ```bash - armory deploy start -f deployment.yaml - ``` - - The `deploy start` command starts your deployment. The command returns a **Deployment ID** and a link to your deployment details. - -1. Monitor your deployment execution. - - Use the link provided by the CLI to navigate to your deployment details page in the [CD-as-a-Service Console](https://console.cloud.armory.io/deployments). - -1. Issue manual approval. - - Since you defined a manual approval to deploy to prod in your strategy, you need to issue your manual approval using the UI. Once the `staging` deployment has completed, click **Approve** to allow the `prod` deployment to begin. Because this is the first time deploying your app, CD-as-a-Service deploys 100% to your prod environment, skipping the defined `trafficSplit` strategy. CD-as-a-Service uses the `trafficSplit` when deploying subsequent versions of your app. - -### Deploy second version - -1. Update your Kubernetes manifest to deploy a new version of your app. -1. Start the deployment from the root of your directory. - - ```bash - armory deploy start -f deployment.yaml - ``` - -1. Monitor your deployment. - - Use the link provided by the CLI to observe your deployment's progression in the [CD-as-a-Service Console](https://console.cloud.armory.io/deployments). - -1. Issue manual approvals. - - CD-as-a-Service deploys your resources to `staging`. After those resources have deployed successfully, CD-as-a-Service waits for your manual approval before deploying to `prod`. - - Once the `staging` deployment has completed, click **Approve** to allow the `prod` deployment to begin. Observe the traffic split and preview your web app deployment. Then issue your manual approval to finish deployment. - -## How to watch from your terminal - -If you want to monitor your deployment in your terminal, use the `--watch` flag to output deployment status. - -```bash -armory deploy start -f deployment.yaml --watch -``` - -Output is similar to: - -```bash -[2023-05-24T13:43:35-05:00] Waiting for deployment to complete. Status UI: https://console.cloud.armory.io/deployments/pipeline/03fe43c6-ddc1-49d8-8116-b01db0ca0c5a?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b -. -[2023-05-24T13:43:46-05:00] Deployment status changed: RUNNING -.. -[2023-05-24T13:44:06-05:00] Deployment status changed: AWAITING_APPROVAL -... -[2023-05-24T13:44:36-05:00] Deployment status changed: RUNNING -.. -[2023-05-24T13:44:56-05:00] Deployment status changed: AWAITING_APPROVAL -. -[2023-05-24T13:45:06-05:00] Deployment status changed: RUNNING -.. -[2023-05-24T13:45:26-05:00] Deployment status changed: SUCCEEDED -[2023-05-24T13:45:26-05:00] Deployment 03fe43c6-ddc1-49d8-8116-b01db0ca0c5a completed with status: SUCCEEDED -[2023-05-24T13:45:26-05:00] Deployment ID: 03fe43c6-ddc1-49d8-8116-b01db0ca0c5a -[2023-05-24T13:45:26-05:00] See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/03fe43c6-ddc1-49d8-8116-b01db0ca0c5a?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b - -``` - -If you forget to add the `--watch` flag, you can run the `armory deploy status --deploymentID ` command. Use the Deployment ID returned by the `armory deploy start` command. For example: - -```bash -armory deploy start -f deployment.yaml -Deployment ID: 9bfb67e9-41c1-41e8-b01f-e7ad6ab9d90e -See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/9bfb67e9-41c1-41e8-b01f-e7ad6ab9d90e?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b -``` - -then run: - -```bash -armory deploy status --deploymentId 9bfb67e9-41c1-41e8-b01f-e7ad6ab9d90e -``` - -Output is similar to: - - ```bash -application: sample-application, started: 2023-01-06T20:07:36Z -status: RUNNING -See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/9bfb67e9-41c1-41e8-b01f-e7ad6ab9d90e? environmentId=82431eae-1244-4855-81bd-9a4bc165f90b -``` - -This `armory deploy status` command returns a point-in-time status and exits. It does not watch the deployment. - ->You must issue manual approvals using the UI. You cannot issue manual approvals using the CLI. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "gh-action.md" >}} -* {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} -* {{< linkWithTitle "cd-as-a-service/troubleshooting/tools.md" >}} -* {{< linkWithTitle "add-context-variable.md" >}} diff --git a/content/en/cd-as-a-service/setup/gh-action.md b/content/en/cd-as-a-service/setup/gh-action.md deleted file mode 100644 index 1e8215286e..0000000000 --- a/content/en/cd-as-a-service/setup/gh-action.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: Get Started with the GitHub Action to Deploy Apps -linkTitle: Deploy Using GitHub Action -weight: 30 -description: > - Use the Armory CD-as-a-Service Deployment Action to integrate your GitHub repo with Armory CD-as-a-Service. -categories: ["Get Started"] -tags: ["Deployment", "Quickstart", "GitHub", "Tools", "Automation"] ---- - -## Overview of the Armory Continuous Deployment-as-a-Service GitHub Action - -This Action enables deploying your app based on a specific GitHub trigger, such as a push to the main branch of your repo. You can configure the action to return immediately or wait for a final deployment state before exiting. - -You can find the Action in the [GitHub Action Marketplace](https://github.com/marketplace/actions/armory-continuous-deployment-as-a-service). - -## {{% heading "prereq" %}} - -If you have previously configured Armory CD-as-a-Service for your deployment target, you can skip to step 3. - -1. You are familiar with CD-as-a-Service's [key components]({{< ref "cd-as-a-service/concepts/architecture/key-components.md" >}}). -1. If you have already prepared a deployment target for Armory CD-as-a-Service, skip this step. If you have not, complete the the following: - - - [Register for Armory CD-as-a-Service](https://go.armory.io/signup/). - - [Create machine-to-machine client credentials]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) for the Remote Network Agent (RNA), which you install on your deployment target cluster. - - Connect your Kubernetes cluster by [installing the RNA]({{< ref "cd-as-a-service/tasks/networking/install-agent" >}}). - -1. (Optional) [Install the CD-as-a-Service CLI]({{< ref "cd-as-a-service/setup/quickstart#install-the-cd-as-as-service-cli" >}}) on your workstation. You can use the CLI to generate a deployment file template. You can also create a deployment file manually. See {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}}. -1. If you are new to using GitHub Actions, see GitHub's [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart) guide for information about setting up GitHub Actions. -1. [Create a CD-as-a-Service Client Credential]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) for your GitHub Action to use to connect to CD-as-a-Service. Assign the `Deployments Full Access` role to your credential. -1. Create GitHub [secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets) for the Client ID and a Client Secret so you don't expose them in plain text in your GitHub workflow file. Use descriptive name for these two values. You reference these secrets when you configure the CD-as-a-Service GitHub Action. - -## Use the GitHub Action - -Configuring the GitHub Action is a multi-part process: - -1. [Determine your manifest path](#determine-your-manifest-path) -1. [Create a deployment file](#create-a-deployment-file) -1. [Configure the action](#configure-the-action) - -### Determine your manifest path - -Decide where you are going to store the app manifest(s) you want to deploy to CD-as-a-Service. You need to know this path when you create your deployment file. - -Note that the path is relative to where the GitHub Action YAML is stored (`.github/workflows`). For example, if your repo looks like this: - -``` -.github ---workflows ----cdaas-deploy-workflow.yaml -deployments ---deployment.yaml ---manifests ----sample-app.yaml -``` - -Then the value you use for `manifests.path` in your `deployment.yaml` would be `/deployments/manifests/sample-app.yaml`. - -### Create a deployment file - -{{< include "cdaas/create-config.md" >}} - -Save your deployment file to a directory in your repo. You use this path later when you configure the GitHub Action's `path-to-file` parameter. - -### Configure the action - -Create a file in the `.github/workflows` directory. The content format is: - -```yaml -name: # This name appears in the Actions screen in the GitHub UI. - -on: - push: # What triggers a deployment. For example, `push`. - branches: - - # What branch triggers a deployment. For example, `main`. - -jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Checkout code - uses: actions/checkout@v2 - - - name: Armory CD-as-a-Service Deployment - id: deploy - uses: armory/cli-deploy-action@main - with: - clientId: "" - clientSecret: "" - path-to-file: "" - waitForDeployment: -``` - -**Armory CD-as-a-Service Deployment job** - -* `clientId`: GitHub secret that you created for your CD-as-a-Service Client ID. For example, if you named your secret **CDAAS_CLIENT_ID**, the value for `clientId` would be `"${{ secrets.CDAAS_CLIENT_ID }}"`. -* `clientSecret`: GitHub secret that you created for your CD-as-a-Service Client ID. For example, if you named your secret **CDAAS_CLIENT_SECRET**, the value for `clientSecret` would be `"${{ secrets.CDAAS_CLIENT_SECRET }}"`. -* `path-to-file`: Relative path to your deployment file. The path you provide for the `path-to-file` parameter is relative to where your GitHub Action YAML is stored (`.github/workflows`). - - For example, if your repo looks like this: - - ``` - .github - --workflows - ---cdaas-deploy.yaml - deployments - --deployment.yaml - --manifests - ---sample-app.yaml - ``` - - Then `path-to-file` would be `/deployments/deployment.yaml`. - -* `waitForDeployment`: (Optional); Default: false; this blocks the GitHub Action from completing until the deployment has transitioned to its final state (FAILED, SUCCEEDED, CANCELLED). - -When the Action is done running, it prints out the Deployment ID, a link to the Deployments UI, and optionally the deployment's final state. It also returns that information in output parameters that you can use elsewhere in your workflow: - -* `DEPLOYMENT_ID`: This is the unique deployment identifier, which you can use to query the status of the deployment in UI. -* `LINK`: This is the link to the UI, where you can check the state of the workflow and advance it to the next stages if you have manual judgments. -* `RUN_RESULT`: If you configured 'waitForDeployment=true', this variable contains the final state of the deployment (FAILED, SUCCEEDED, CANCELLED). - -You could, as a simplistic example, add a job step that prints out the values of the output parameters: - -```yaml -steps: -... - - name: Print Armory CD-as-a-Service Deployment Output - id: output - run: echo -e 'DeploymentID ${{steps.deploy.outputs.DEPLOYMENT_ID}}\nLink ${{steps.deploy.outputs.LINK}}\n${{steps.deploy.outputs.RUN_RESULT}}' -``` - -See GitHub's [Using workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) content for more information. - -### Example configuration - -For this scenario: - -1. You created secrets called `CDAAS_CLIENT_ID` AND `CDAAS_CLIENT_SECRET`. -1. Your `deployment.yaml` file is in the `deployments` directory of your repo. -1. You want to deploy when a pull request is merged to the `main` branch. -1. You want the Armory GitHub Action to run until it receives a final deployment status from CD-as-a-Service. -1. You want to print the output from the Armory GitHub Action in a separate job step. - -Your workflow file contents looks like this: - -```yaml -name: Deploy to CD-as-a-Service - -on: - push: - branches: - - main - -jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Checkout code - uses: actions/checkout@v2 - - - name: Deploy app - id: deploy - uses: armory/cli-deploy-action@main - with: - clientId: ${{ secrets.CDAAS_CLIENT_ID }} - clientSecret: ${{ secrets.CDAAS_CLIENT_SECRET }} - path-to-file: "/deployments/deployment.yaml" - waitForDeployment: true - - - name: Print deploy output - id: output - run: echo -e 'DeploymentID ${{steps.deploy.outputs.DEPLOYMENT_ID}}\nLink ${{steps.deploy.outputs.LINK}}\n${{steps.deploy.outputs.RUN_RESULT}}' -``` - - -## Trigger a deployment - -After you have created your deployment file and configured your workflow, you can trigger a CD-as-a-Service deployment based on the trigger you defined in your workflow. - -You can monitor your deployment's progress in the GitHub UI or in the CD-as-a-Service UI. Be sure to you know how to access a GitHub Action [workflow run log](https://docs.github.com/en/act##ions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting) before you begin. - -1. **GitHub workflow run log**: Use `waitForDeployment: true` in your job and watch the Action output in the workflow run log. - - Output is similar to: - - ```bash - Waiting for deployment to complete. Status UI: https://console.cloud.armory.io/deployments/pipeline/f4e1fbfe-641f-4613-aff3-0699698d5aed?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b - . - Deployment status changed: RUNNING - ..... - Deployment status changed: PAUSED - .. - Deployment status changed: RUNNING - ... - Deployment status changed: PAUSED - .. - Deployment status changed: RUNNING - Deployment ID: f4e1fbfe-641f-4613-aff3-0699698d5aed - ..... - Deployment status changed: SUCCEEDED - Deployment f4e1fbfe-641f-4613-aff3-0699698d5aed completed with status: SUCCEEDED - See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/f4e1fbfe-641f-4613-aff3-0699698d5aed?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b - ``` - -1. **CD-as-a-Service Deployments UI**: Obtain the **Deployments** UI direct link from the Action output. - - When you configure `waitForDeployment: false`, the Action immediately prints out the Deployment ID and a link to the **Deployments** UI and then exits. Output is similar to: - - ```bash - Deployment ID: 065e9c2c-5e3e-4e6a-a591-bdd756a497c2 - See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/065e9c2c-5e3e-4e6a-a591-bdd756a497c2?environmentId=82431eae-1244-4855-81bd-9a4bc165f90b - ``` - ->Note: if you configured a manual approval in your strategy, you must use the CD-as-a-Service Deployments UI to issue that approval. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/tools.md" >}} -* {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} -* {{< linkWithTitle "add-context-variable.md" >}} diff --git a/content/en/cd-as-a-service/setup/quickstart.md b/content/en/cd-as-a-service/setup/quickstart.md deleted file mode 100644 index 6c9e595729..0000000000 --- a/content/en/cd-as-a-service/setup/quickstart.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: Armory CD-as-a-Service Quickstart -linktitle: Quickstart -description: > - Install the Armory Continuous Deployment-as-a-Service CLI, connect your Kubernetes cluster with a single CLI command, and deploy an sample app using a traffic split. Learn deployment file syntax. -weight: 1 -categories: ["Get Started"] -tags: ["Deployment", "Quickstart"] -aliases: - - /cd-as-a-service/setup/get-started/ - - /cd-as-a-service/setup/cli/ ---- - -## Learning objectives - -1. [Sign up for CD-as-a-Service](#sign-up-for-cd-as-a-service). -1. [Install the CD-as-as-Service CLI](#install-the-cd-as-as-service-cli) on your Mac or Linux workstation. -1. [Connect your Kubernetes cluster](#connect-your-cluster) to CD-as-a-Service. -1. [Deploy Armory's sample app](#deploy-the-sample-app) `potato-facts` to two environments: `staging` and `prod`. - * Use the CD-as-a-Service Console to approve an environment promotion. - * Observe a traffic split between two app versions. -1. [Learn CD-as-a-Service deployment file syntax](#learn-deployment-file-syntax). -1. [Remove](#clean-up) the resources you created. - -## {{% heading "prereq" %}} - -* You are familiar with CD-as-a-Service's [key components]({{< ref "cd-as-a-service/concepts/architecture/key-components.md" >}}). -* You have access to a Kubernetes cluster. If you need a cluster, consider installing a local [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) or [Minikube](https://minikube.sigs.k8s.io/docs/start/) cluster. Your cluster's API endpoint does not need to be publicly accessible to use CD-as-a-Service. - ->If you do not have a Kubernetes cluster and still wish to tour CD-as-a-Service, you can [sign up ](https://go.armory.io/signup/) and select **Self-Guided Browser Tour**. CD-as-a-Service creates a short-lived Kubernetes cluster for you and then guides you through deploying the sample app. - -## Sign up for CD-as-a-Service - -{{< include "cdaas/register.md" >}} - - -## Install the CD-as-as-Service CLI - -{{< include "cdaas/install-cli.md" >}} - -### Log in with the CLI - -```shell -armory login -``` - -Confirm the device code in your browser when prompted. Then return to this guide. - -## Connect your cluster - -CD-as-a-Service uses an agent to execute deployments in your Kubernetes cluster. The installation process uses credentials from your `~/.kube/config` file to install the CD-as-a-Service agent into a new `armory-rna` namespace. - -Run the following command to install an agent in your Kubernetes cluster: - -```shell -armory agent create -``` - -You name your agent during the installation process. This guide references that name as ``. - -
Having connection issues? Expand to see alternate instructions. - -Use the **CD-as-a-Service Console** to generate kubectl commands that you can run locally. - - - -{{< include "cdaas/rna-ui-add-agent.md" >}} - -You can also [open a ticket](https://github.com/armory/docs//issues/new?title=Armory%20CD-as-a-Service%20Quickstart) so Armory knows what issues you had. - -
- -## Deploy the sample app - -Armory's [`potato-facts` sample app](https://github.com/armory-io/potato-facts-go) is a simple web app. The UI polls the API backend for facts about potatoes and renders them for users. - -### First deployment - -Your first deployment deploys the following resources into your Kubernetes cluster: - -- Two namespaces: `potato-facts-staging` and `potato-facts-prod` -- In each namespace: the `potato-facts` app and a Kubernetes `Service` - -**Deploy** - -Run the following command: - -```shell -armory deploy start -f https://go.armory.io/hello-armory-first-deployment --account -``` - -Congratulations, you've just started your first deployment with CD-as-a-Service! - -You can use the link provided by the CLI to observe your deployment's progression in the [CD-as-a-Service Deployments Console](https://console.cloud.armory.io/deployments). CD-as-a-Service deploys your resources to `staging`. Once those resources have deployed successfully, CD-as-a-Service deploys to `prod`. - -### Second deployment - -CD-as-a-Service is designed to help you build safety into your app deployment process. It does so by giving you declarative levers to control the scope of your deployment. - -CD-as-a-Service has four kinds of constraints that you can use to control your deployment: - -- Manual Approvals -- Timed Pauses -- [Webhooks]({{< ref "cd-as-a-service/tasks/webhook-approval" >}}) -- [Automated Canary Analysis]({{< ref "cd-as-a-service/setup/canary" >}}) - -You can use these constraints _between_ environments and _within_ environments: - -- During your next deployment, you need to issue a manual approval between `staging` and `prod`. -- Within the `prod` deployment, CD-as-a-Service creates a traffic split between your app versions: 75% goes to the old version and 25% goes to the new version. CD-as-a-Service waits for your approval before continuing the deployment. - -**Deploy** - -Start your second deployment: - -```shell -armory deploy start -f https://go.armory.io/hello-armory-second-deployment --account -``` - -Use the link provided by the CLI to navigate to your deployment in the [CD-as-a-Service Console](https://console.cloud.armory.io/deployments). Once the `staging` deployment has completed, click **Approve** to allow the `prod` deployment to begin. - -{{< figure src="/images/cdaas/setup/quickstart/clickApprove.jpg" width=80%" height="80%" >}} - -Once deployment begins, you can see the traffic split. CD-as-a-Service has deployed a new `ReplicaSet` with only one pod to achieve a 75/25% traffic split between app versions. Click the **prod** deployment to open the details window. - -{{< figure src="/images/cdaas/setup/quickstart/openTrafficSplitDetails.jpg" width=80%" height="80%" >}} - -Click on `potato-facts` in the **Resources** section to open a preview of `potato-facts`. - -{{< figure src="/images/cdaas/setup/quickstart/trafficSplitDetailsWindow.jpg" width=80%" height="80%" >}} - -The app's graph plots the ratio of facts served by a given Kubernetes `ReplicaSet`. The ratio of facts served by `ReplicaSet` backends in the graph should roughly match the 75/25% split. - -{{< figure src="/images/cdaas/setup/quickstart/potatoFactsTrafficSplit.jpg" width=80%" height="80%" >}} - -Return to the deployment details window. Click **Approve & Continue** to finish deployment. CD-as-a-Service fully shifts traffic to the new app version and tears down the previous app version. - -{{< figure src="/images/cdaas/setup/quickstart/deployFinishedDetails.jpg" width=80%" height="80%" >}} - -## Learn deployment file syntax - -Now that you've used CD-as-a-Service to deploy to two environments, it's time to break down the sample app's deployment file. You can find full specification details in the [Deployment Config File Reference](https://docs.armory.io/cd-as-a-service/reference/ref-deployment-file/#sections). - -**`targets`** - -In CD-as-a-Service, a `target` is an `(account, namespace)` pair where `account` is the agent identifier you created when you connected your cluster. - -When deploying to multiple targets, you can specify dependencies between targets using the `constraints.dependsOn` field. In this guide, the `prod` deployment starts only after the `staging` deployment has completed successfully, and you have manually approved deployment to prod. - -```yaml -targets: - staging: - # Account is optional when passed as a CLI flag (--account). - # It's also required if you'd like to deploy to multiple Kubernetes clusters. - # account: - namespace: potato-facts-staging - strategy: rolling - prod: - namespace: potato-facts-prod - strategy: trafficSplit - constraints: - dependsOn: ["staging"] - beforeDeployment: - - pause: - untilApproved: true -``` - -**`manifests`** - -CD-as-a-Service can deploy any Kubernetes manifest. You do not need to alter your manifests or apply any special annotations. - -By default, CD-as-a-Service deploys all the manifests defined in `path` to all of your `targets`. If you want to restrict the targets where a manifest should be deployed, use the `manifests.targets` field. - -A `path` can be a path to a directory or to an individual file. Each file may contain one or more Kubernetes manifests. - -```yaml -manifests: - - path: ./manifests/potato-facts-v1.yaml - - path: ./manifests/potato-facts-service.yaml - - path: ./manifests/staging-namespace.yaml - targets: ["staging"] - - path: ./manifests/prod-namespace.yaml - targets: ["prod"] -``` - -**`strategies`** - -A `strategy` defines how CD-as-a-Service deploys manifests to a target. - -A `canary`-type strategy is a linear sequence of steps. The `setWeight` step defines the ratio of traffic between app versions. - -```yaml -strategies: - rolling: - canary: - steps: - # This strategy immediately flips all traffic to the new app version. - - setWeight: - weight: 100 - trafficSplit: - canary: - steps: - - setWeight: - weight: 25 - - exposeServices: - services: - - potato-facts - ttl: - duration: 30 - unit: minutes - - pause: - untilApproved: true - - setWeight: - weight: 100 -``` - - -CD-as-a-Service integrates with service meshes like [Istio]({{< ref "cd-as-a-service/tasks/deploy/traffic-management/istio" >}}) and [Linkerd]({{< ref "cd-as-a-service/tasks/deploy/traffic-management/linkerd" >}}), but you do not need to use a service mesh to use a CD-as-a-Service `canary` strategy. - -CD-as-a-Service also supports a [blue/green]({{< ref "cd-as-a-service/setup/blue-green" >}}) deployment strategy. - -## Clean up - -You can clean kubectl to clean up the app resources you created: - -```shell -kubectl delete ns potato-facts-staging potato-facts-prod -``` - -To remove the Remote Network Agent, run: - -```shell -kubectl delete ns armory-rna -``` - ->Don't delete your Remote Network Agent if you plan to use the same cluster to deploy your own app. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/setup/deploy-your-app.md" >}} -* {{< linkWithTitle "cd-as-a-service/setup/gh-action.md" >}} -* {{< linkWithTitle "cd-as-a-service/setup/blue-green.md" >}} -* {{< linkWithTitle "cd-as-a-service/setup/canary.md" >}} -* {{< linkWithTitle "cd-as-a-service/setup/argo-rollouts.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/_index.md b/content/en/cd-as-a-service/tasks/_index.md deleted file mode 100644 index ee78ca4309..0000000000 --- a/content/en/cd-as-a-service/tasks/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Guides -linktitle: Guides -description: > - The Armory Continuous Deployment-as-a-Service Guides section contains content that shows you how to do discreet tasks in the Armory CD-as-a-Service platform. -weight: 30 ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/canary/_index.md b/content/en/cd-as-a-service/tasks/canary/_index.md deleted file mode 100644 index 70a59ef35c..0000000000 --- a/content/en/cd-as-a-service/tasks/canary/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Canary Analysis Tasks -linktitle: Canary Analysis -description: > - This section contains guides for adding metrics providers and constructing queries in Armory CD-as-a-Service. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/canary/add-integrations.md b/content/en/cd-as-a-service/tasks/canary/add-integrations.md deleted file mode 100644 index acb90d88ba..0000000000 --- a/content/en/cd-as-a-service/tasks/canary/add-integrations.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Integrate a Metrics Provider -linkTitle: Integrate Metrics Provider -description: > - Add metrics sources such as Prometheus, Data Dog, and New Relic for canary analysis in Armory Continuous Deployment-as-a-Service. -categories: ["Guides"] -tags: ["Deploy Strategy", "Canary", "Metrics", "CD-as-as-Service Setup"] ---- - -## Overview - -Integrate your metrics provider with Armory CD-as-a-Service so that you can perform retrospective analysis of your deployment performance or use canary analysis as part of your deployment strategy. - -Armory supports the following metrics providers: - -- [Datadog](#datadog) -- [New Relic](#new-relic) -- [Prometheus](#prometheus) - -## {{% heading "prereq" %}} - -- You have installed one of the supported metrics providers. -- You have created a [secret]({{< ref "cd-as-a-service/tasks/secrets/secrets-create" >}}) for your provider's encrypted connection token: - - - Datadog: **API Key** and **Application Key** - - New Relic: **API Key** - - Prometheus: If you use username/password authentication, create a secret for the password. If you use a Bearer token, create a secret for the token. - - -## How to add a metrics provider - -1. In the [CD-as-a-Service Console](https://console.cloud.armory.io/), navigate to **Canary Analysis** > **Integrations**. -1. Click on **New Integration**. - -The **Type** drop-down on the **Metrics Source Integration Configuration** screen contains a list of supported metrics providers. Select your provider and fill in the required fields, which change based on selected provider. - -### Datadog - -- **Name**: A descriptive name for your metrics provider, such as the environment it monitors. You use this name in places such as your deploy file when you want to configure canary analysis as part of your deployment strategy. -- **Base URL**: Your Datadog instance URL; for example, `https://api.datadoghq.com/`. -- **API Key**: The key that your Datadog Agent uses to submit metrics and events to Datadog. -- **Application Key**: The key that grants permission for programmatic access to the Datadog API. - -For information about how to get the API Key and Application Key, see [DataDog documentation](https://docs.datadoghq.com/account_management/api-app-keys/). - -### New Relic - -- **Name**: A descriptive name for your metrics provider, such as the environment it monitors. You use this name in places such as your deploy file when you want to configure canary analysis as part of your deployment strategy. -- **Base URL**: Your New Relic instance URL; for example, `https://api.newrelic.com/graphql/`. -- **API Key**: The metrics integration requires access to Graph QL, so provide the User Key API key. For more information, see [User Key in the New Relic documentation](https://docs.newrelic.com/docs/apis/accounts-api/new-relic-user-key-api-key/). -- **Account ID**: Your New Relic account ID. For information about how to get this ID, see [Account ID in the New Relic documentation](https://docs.newrelic.com/docs/apis/accounts-api/new-relic-account-id/). - -### Prometheus - -- **Name**: A descriptive name for your metrics provider, such as the environment it monitors. You use this name in places such as your deploy file when you want to configure canary analysis as part of your deployment strategy. -- **Base URL**: Your Prometheus instance URL; for example, if Prometheus runs in the same cluster as the RNA and is exposed using HTTP on port 9090 through a service named `prometheus` in the namespace `prometheus-ns`, then the URL would be `http://prometheus.prometheus-ns:9090`. -- **Remote Network Agent**: The RNA that is installed in the Prometheus cluster if the cluster is not publicly accessible. -- **Authentication Type**: Select **None**, **Username/Password**, or **Bearer Token**. - - - If you selected **Username/Password**: Fill in the username for accessing Prometheus and select the password secret. - - If you selected **Bearer Token**: Select the token secret from the drop-down list. - - diff --git a/content/en/cd-as-a-service/tasks/canary/retro-analysis.md b/content/en/cd-as-a-service/tasks/canary/retro-analysis.md deleted file mode 100644 index 4e5e2e32f7..0000000000 --- a/content/en/cd-as-a-service/tasks/canary/retro-analysis.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Construct Retrospective Analysis Queries for Canary Analysis -linktitle: Construct Queries -description: > - Learn how to construct retrospective analysis queries that you can then use for your canary strategy. -categories: ["Guides"] -tags: ["Deploy Strategy", "Canary", "Retrospective Analysis"] ---- - -## Overview - -Retrospective analysis is the starting point to creating queries so that you can perform canary analysis on your deployments. The UI gives you a structured way to create a query and test it against previous deployments. When ready, you can export it so that you can add the query to your deploy file easily. -Use the **Retrospective Analysis** UI to help you to construct queries. You can then test those queries by running them against previous deployments. Once you've created a query that meets your needs, export it to generate YAML that you can use in your deploy file. - -## {{% heading "prereq" %}} - -You need to integrate your Metrics provider. See the {{< linkWithTitle "cd-as-a-service/tasks/canary/add-integrations.md" >}} guide for details. - -## How to Perform a retrospective analysis - -To perform retrospective analysis, you need to provide the following: - -- **Metrics Provider**: The metrics provider that you want to use. -- **Analysis Range**: The time range that you want to analyze. -- **Queries**: One or more query templates to use for the analysis. For the query template, you need the following: - - Name: Provide a descriptive name - - Upper Limit: - - Lower Limit: - - Query Template -- **Context**: Key/Value pair for the substitutable template variables in your query templates. - -Armory supports the following time related variables out of the box: - -- `armory.startTimeIso8601` -- `armory.startTimeEpochSeconds` -- `armory.startTimeEpochMillis` -- `armory.endTimeIso8601` -- `armory.endTimeEpochSeconds` -- `armory.endTimeEpochMillis` -- `armory.intervalMillis` -- `armory.intervalSeconds` -- `armory.promQlStepInterval` - -You do not need to provide these variables in the context. - -In addition to the time related variables, Armory CD-as-a-Service provides an additional set of variables that you must add these manually as part of the context when performing retrospective analysis. They are automatically substituted in queries that are part of your deploy file. - -- `armory.deploymentId` -- `armory.applicationName` -- `armory.environmentName` -- `armory.replicaSetName` - -You can also add your own custom variables as key/value pairs. If you want to use these custom variables, you need to add them to [`strategies...steps.analysis.context` section in your deployment file]({{< ref "ref-deployment-file#strategiesstrategynamestrategystepsanalysiscontext" >}}). - -### Export and add a query to your deploy file - -You can generate the YAML equivalent of your query to use in your deploy file. - -1. From the analysis screen, select **Go back to Analysis Configuration**. -1. Click **Export Queries for Armory Deployments**. This creates the YAML block for the `analysis` portion of your deploy file. -1. Insert the YAML block into your deploy file at the bottom. \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/cli.md b/content/en/cd-as-a-service/tasks/cli.md deleted file mode 100644 index c97971ca35..0000000000 --- a/content/en/cd-as-a-service/tasks/cli.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Install and Upgrade the CD-as-a-Service CLI -linkTitle: Install/Upgrade CLI -description: > - Install the Armory Continuous Deployment-as-a-Service CLI natively on Linux or Mac or use a Docker image. -categories: ["Guides"] -tags: [ "Tools", "CLI", "CD-as-as-Service Setup"] ---- - -## CLI overview - -You can install the CLI (`armory`) on your Mac, Linux, or Windows workstation. Additionally, you can run the CLI in Docker. - -On Mac, you can also download, install, and update the CLI using the Armory Version Manager (AVM). The AVM includes additional features such as the ability to list installed CLI versions and to declare which version of the CLI to use. - - - -{{< tabpane text=true right=true >}} -{{% tab header="**Method**:" disabled=true /%}} - -{{% tab header="Homebrew" %}} -```bash -brew tap armory-io/armory -brew install armory-cli -``` -{{% /tab %}} -{{% tab header="Script Mac/Linux" %}} - -You can install the CLI with a one-line script that does the following: - -1. Fetches the correct Armory Version Manager binary (`avm`) for your operating system -1. Installs the AVM binary -1. Uses the AVM to install the CLI binary (`armory`) -1. Adds the AVM and the CLI to the path in your bash or zsh profile - -Execute the following script on the machine that has access to your Kubernetes cluster: - -```bash -curl -sL go.armory.io/get-cli | bash -``` - -After installation completes, you should start a new terminal session or source your profile. - -{{% /tab %}} - - -{{% tab header="Manual Mac/Linux" %}} -1. Download the AVM for your operating system and CPU architecture. You can manually download it from the [repo](https://github.com/armory/avm/releases/) or use the following command: - - ```bash - curl -LO https://github.com/armory/avm/releases/latest/download/avm-- - ``` - - For example, the following command downloads the latest version for macOS (Darwin): - - ```bash - curl -LO https://github.com/armory/avm/releases/latest/download/avm-darwin-amd64 - ``` - - You can see the full list of available releases in the [repo](https://github.com/armory/avm/releases/). -2. Give AVM execute permissions. For example (on macOS): - - ```bash - chmod +x avm-darwin-amd64 - ``` - -4. Confirm that `/usr/local/bin` is on your `PATH`: - - ```bash - echo $PATH - ``` - The command returns your `PATH`, which should now include `/usr/local/bin/`. - -5. Rename the AVM binary to `avm` and move it to `/usr/local/bin`, which is on your `PATH`. For example (on macOS): - - ```bash - mv avm-darwin-amd64 /usr/local/bin/avm - ``` - -6. Run the following command to install the CLI: - - ```bash - avm install - ``` - - The command installs the CLI and returns a directory that you need to add to your path, such as `/Users/milton/.avm/bin`. - - If you get an `developer cannot be identified error` when trying to run AVM, you must allow AVM to run. - -
Show me how to allow AVM to run. - - On macOS, go to **System Preferences > Security & Privacy > General** and click **Allow Anyway**. - - For more information, see the macOS documentation about [how to open a Mac app from an unidentified developer](https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac). - -

- -7. Add the directory that AVM returned when you ran `avm install` to your path. - -
Show me how to add the directory. - - You can either add the path directly to `/etc/paths` or add it to your shell profile. The following steps describe how to add it to your shell profile: - 1. Edit the resource file for your shell, such as `.bashrc`, `.bash_profile`, or .`zshrc`. For example: - - ```bash - vi ~/.bashrc - ``` - - 1. In the file, find the line for the `PATH` that your resource file exports. They follow the format `export PATH=$HOME/bin:/usr/local/bin:$PATH`. - 2. Insert the path provided by AVM (such as `/Users/brianle/.avm/bin`) before the ending `$PATH`. The line should look similar to this: - - ```bash - export PATH=$HOME/bin:/usr/local/bin::/Users/milton/.avm/bin:$PATH - ``` - - 3. Save the file. - 4. Reload your terminal, open a new session, or `source` your terminal profile file (for example, `source .bash_profile`). - -

- -8. Run the following command to verify that the CLI is installed: - - ```bash - armory - ``` - - The command returns basic information about the CLI, including available commands. - -For the AVM or the CLI, you can use the `-h` flag for more information about specific commands. - -{{% /tab %}} - -{{% tab header="Docker" %}} -Armory provides the CD-as-a-Service CLI as a [Docker image](https://hub.docker.com/r/armory/armory-cli). - -```bash -docker pull armory/armory-cli -``` -{{% /tab %}} - -{{% tab header="Windows" %}} -Download the latest `armory-cli` Windows executable from the [repo Releases page](https://github.com/armory-io/armory-cli/releases). Install on the machine that has access to your Kubernetes cluster. -{{% /tab %}} - -{{< /tabpane >}} - - -## Upgrade the CLI - -{{< tabpane text=true right=true >}} -{{% tab header="**Method**:" disabled=true /%}} -{{% tab header="Homebrew" %}} -```bash -brew upgrade armory-cli -``` -{{% /tab %}} -{{% tab header="AVM" %}} -```bash -avm install -``` -{{% /tab %}} - -{{< /tabpane >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/_index.md b/content/en/cd-as-a-service/tasks/deploy/_index.md deleted file mode 100644 index 20aeeb4abe..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Deployment Tasks -linkTitle: Deployment -description: > - This section contains tasks related to deploying your apps using Armory CD-as-a-Service, including how to create the deployment config file, configure traffic management, and configure role-based manual approval. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/add-context-variable.md b/content/en/cd-as-a-service/tasks/deploy/add-context-variable.md deleted file mode 100644 index bb308881fb..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/add-context-variable.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Add New Context Variables at Deploy Time -linktitle: Add Context Variables at Deploy Time -description: > - Add new context variables from the command line or in your GitHub Action. These variables are injected into your canary analysis and webhook triggers. -categories: ["Guides"] -tags: ["Deployment", "Deploy Config", "Variables"] ---- - -## How to add new context variables - -You can add new context variables at deployment time by using the `--add-context` argument on the command line or from within your [Armory CD-as-a-Service GitHub Action]({{< ref "gh-action" >}}). Armory CD-as-a-Service adds the new context variables to webhook triggers and canary analysis steps in any deployment constraint. - -The value of the `--add-context` argument is a comma-delimited list of key=value pairs. - -For this example, you want to add the following new context variables: - -| Name | Value | -| ----------- | ---------- | -| smokeTest | true | -| environment | prod | -| changeBy | jane-smith | - -
-Your command line looks like this: - -{{< prism lang="bash" line-numbers="true" >}} -armory deploy start -f deploy.yml --add-context=smokeTest=true,environment=prod,changeBy=jane-doe -{{< /prism >}} -
-In your GitHub Action, you add an `addContext` key in your `Deployment` step. - -{{< prism lang="yaml" line-numbers="true" line="22" >}} -name: Deploy my latest version - -on: - push: - branches: - - 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.CDAAS_CLIENT_ID }}" - clientSecret: "${{ secrets.CDAAS_CLIENT_SECRET }}" - path-to-file: "/deploy.yml" - addContext: "smokeTest=true,environment=prod,changeBy=jane-doe" - applicationName: "potato-facts" -{{< /prism >}} - -## Known issues - -Context variables are not added in the following situations: - -* An `analysis` step when used in an after deployment constraint -* A step in a blue/green deployment strategy - diff --git a/content/en/cd-as-a-service/tasks/deploy/create-deploy-config.md b/content/en/cd-as-a-service/tasks/deploy/create-deploy-config.md deleted file mode 100644 index 025ee2921d..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/create-deploy-config.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Create a Deployment Config File for Armory CD-as-a-Service -linkTitle: Create Deploy Config -description: > - Create a config file to deploy your app using Armory Continuous Deployment-as-a-Service. -categories: ["Guides"] -tags: ["Deployment", "Deploy Config"] ---- - -## {{% heading "prereq" %}} - -Make sure you have [installed the CD-as-a-Service CLI]({{< ref "cd-as-a-service/tasks/cli" >}}), which you use to generate a deployment template. - -## How to create a deployment config file - -{{< include "cdaas/create-config.md" >}} - -## {{% heading "nextSteps" %}} - -* [Deploy your app using the CLI]({{< ref "cd-as-a-service/setup/deploy-your-app" >}}). -* [Deploy your app using a GitHub Action]({{< ref "cd-as-a-service/setup/gh-action" >}}). diff --git a/content/en/cd-as-a-service/tasks/deploy/deploy-with-creds.md b/content/en/cd-as-a-service/tasks/deploy/deploy-with-creds.md deleted file mode 100644 index 1a4c8b1a74..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/deploy-with-creds.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Deploy an App Using Credentials -linkTitle: Deploy with Credentials -description: > - Use the CLI to deploy an app using CD-as-a-Service machine to machine credentials. -categories: ["Guides"] -tags: ["Deployment", "Deploy Config", "Credentials", "Automation", "CLI"] ---- - -## Deploy your app using a Client ID and Client Secret - -When you want to script a CLI deployment, you can pass your Client ID and Client Secret to the `deploy` command instead of separately logging into CD-as-a-Service using the CLI. - -## {{% heading "prereq" %}} - -You have [created machine to machine client credentials]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) and have access to your Client ID and Client Secret values. - -## Deploy your app - -{{< prism lang="bash" >}} -armory deploy start -c -s -f -{{< /prism >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/monitor-deployment.md b/content/en/cd-as-a-service/tasks/deploy/monitor-deployment.md deleted file mode 100644 index f1cfbf8f7f..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/monitor-deployment.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: How to Monitor Deployments -linkTitle: Monitor Deployments -description: > - Monitor the status of your deployments and approve or rollback deployments. -categories: ["Guides"] -tags: ["Deployment", "Monitor"] ---- - - -## Monitor deployments using the Deployments UI - -When you navigate to the **Armory Deployments** tab of the UI, you land on the **All Deployments** page, which shows all the apps for a specific Armory CD-as-a-Service environment. If you don't see a deployment that you're expecting to see, refresh the list or verify the Armory CD-as-a-Service environment the app belongs to. You can switch environments in the top right menu by clicking on your username. - -On the **All Deployments** page, you can select a specific app to get more details on that app's deployments. This brings up a status pane with basic information that includes the following: - -- Who started the most recent deployment for an app -- When the deployment started -- Deployment health -- Progress and status for the deployment, such as if it is waiting for approval - -Select **See Full Details** from the status pane on the **All Deployments**, you arrive on the **All Environments** page, which shows all the environments that are part of that deploy file. If a deploy file only contains one environment, you'll only see one on this page. - -You can watch a [demo](https://s.armory.io/BludOJBo) of how the All Deployments page and the details page for a single environment work together to walk you through progressing your deployment. - -### All environments - -The **All Deployments** page shows you all environments that are being deployed to in a single deploy file. If you click the link that the CLI returns when you trigger the deployment, this is the page you are linked to. It can give you a general idea of the state of the deployment and what environment is currently being deployed to. - -{{< figure src="/images/cdaas/multitarget-deploy.jpg" alt="The deployment starts in a dev environment. It then progresses to infosec and staging environments simultaneously. It finishes by deploying to a prod-west environment." >}} - -More specifically, this view shows you how deployments are supposed to progress through different environments based on the constraints that are defined in the deploy file. An environment that is waiting for one or more constraints to be satisfied is connected to the preceding deployment by a dotted line and is greyed out. - -{{< figure src="/images/cdaas/ui-constraints.jpg" alt="The staging-west environment has constraints that prevent it from starting until they are satisfied." >}} - -Clicking on a specific environment brings up a status pane with basic information about that environment. From here, you can see the **Full Details** for that single environment where you can take additional action. - -### Single environment - -The **Full Details** page for a single environment is where you monitor the progress of the deployment to that environment. If the strategy you specified involves user input, such as a manual approval, this is the page where you can approve or rollback the deployment. - -{{< figure src="/images/cdaas/ui-fulldetails.jpg" >}} diff --git a/content/en/cd-as-a-service/tasks/deploy/preview-link.md b/content/en/cd-as-a-service/tasks/deploy/preview-link.md deleted file mode 100644 index 9da82feb3e..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/preview-link.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Create a Temporary Preview Link to a Deployed Service -linkTitle: Create Preview Links -description: > - Create a temporary public preview link to a deployed service for testing. -categories: ["Guides"] -tags: ["Deployment", "Deploy Config", "Deploy Preview"] ---- - -## Overview - - Create a temporary public preview link to a deployed service to verify HTTP services after their deployment. The created link is generated with a cryptographically secure domain prefix and automatically expires after a configured time period. - -You can use this step in both canary and blue-green deployment strategies. - - ## Expose your service - -**Canary strategy**: add an `exposeServices` step to `strategies..canary.steps` in your [deployment file]({{< ref "cd-as-a-service/reference/ref-deployment-file#strategiesstrategynamecanarystepsexposeservices" >}}). - -**Blue/Green strategy**: add an `exposeServices` entry to `strategies..redirectTrafficAfter` in your [deployment file]({{< ref "cd-as-a-service/reference/ref-deployment-file#strategiesstrategynamebluegreenredirecttrafficafterexposeservices" >}}). - -{{< include "cdaas/deploy/preview-link-details.md" >}} - -## Find your exposed service URL - -### Customer Portal - -The **Resources** section of your Deployment details page displays a clickable link to preview your service. CD-as-a-Service automatically creates the preview link right after the `exposeServices` step completes - no need to refresh the page. On the link itself there is a tooltip with the approximate remaining lifetime of the preview link. - -CD-as-a-Service deactivates the link after the service preview expires. - -### REST API - -You can find your exposed URL by doing a `GET` to `https://api.cloud.armory.io/deploy-engine/deployments/{{deploymentID}}`. - -You can find the `exposeServices` step in the strategy's `steps` collection. The `exposeServices` steps contains a `preview` object with the following keys: - -* `previews`: map of `service-name:URL` objects -* `expiresAtIso8601`: the absolute timestamp of the preview link's expiration - -### Webhook context - -After the preview link is created, you can use it in context of the webhook action for current strategy. The link naming convention is `armory.preview.`. - -If you have a long-running deployment, be suure to choose a long enough `ttl` for the service, so that the link passed to the webhook has not already expired. - -## Example - -If you configure the following in a canary strategy: - -{{< prism lang="yaml" line-numbers="true" >}} -... -steps: -... -- exposeServices: - services: - - sample-app-svc - ttl: - duration: 20 - unit: minutes -{{< /prism >}} - -... and then deploy your app, you would see this in your deployment details: - -{{< figure src="/images/cdaas/tasks/deploy/exposeServices-UI.png" alt="The preview link in the Resources section" >}} - -If you query the REST API endpoint, you see results similar to: - -{{< figure src="/images/cdaas/tasks/deploy/exposeServices-API.png" alt="The preview link in the REST API results" >}} - -To reference an exposed service in your webhook, add a `runWebhook` step in your strategy and then add a `preview-link` in your webhook definition. For example: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -... -steps: -... -- runWebhook: - name: call-service -... -webhooks: -- name: call-service - ... other webhook configuration properties - bodyTemplate: - inline: >- - { - "preview-link": "{{armory.preview.sample-app-svc}}" - } - {{< /prism >}} diff --git a/content/en/cd-as-a-service/tasks/deploy/role-based-manual-approval.md b/content/en/cd-as-a-service/tasks/deploy/role-based-manual-approval.md deleted file mode 100644 index 4287ceaba5..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/role-based-manual-approval.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Configure Role-Based Manual Approval -description: > - Implement role-based manual deployment approval in Armory Continuous Deployment-as-a-Service. -categories: ["Guides"] -tags: ["Deployment", "Deploy Config", "Approvals"] ---- - -## {{% heading "prereq" %}} - -* You have read {{< linkWithTitle "cd-as-a-service/concepts/deployment/role-based-manual-approval.md" >}} to learn how role-based manual approvals can enforce your SDLC's approval processes in Armory CD-as-a-Service. - - -## Configure role-based manual approval - -In your deployment manifest, add a `requiresRole` field to your manual approval. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -... -pause: - untilApproved: true - requiresRoles: [] -... -{{< /prism >}} - -- `requiresRoles`: list of RBAC roles - -For example, if you want only users with an "Approver", "InfoSec", or "Release Manager" role to be able to issue a manual approval, you would add those roles to the `requiresRole` list: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -... -pause: - untilApproved: true - requiresRoles: ["Approver", "InfoSec", "Release Manager"] -... -{{< /prism >}} - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/traffic-management/_index.md b/content/en/cd-as-a-service/tasks/deploy/traffic-management/_index.md deleted file mode 100644 index 8422370432..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/traffic-management/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Configure Traffic Management in Armory Continuous Deployment-as-a-Service -linkTitle: Configure Traffic Management -description: > - Configure traffic management using Istio or Linkerd in your Armory CD-as-a-Service deployment. -aliases: - - /cd-as-a-service/tasks/deploy/traffic-management/ ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/traffic-management/istio.md b/content/en/cd-as-a-service/tasks/deploy/traffic-management/istio.md deleted file mode 100644 index 7d0c96b320..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/traffic-management/istio.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Configure Traffic Management Using Istio -linkTitle: Istio -description: > - Configure your Armory CD-as-a-Service deployment to use Istio for traffic management. -categories: ["Guides"] -tags: ["Deployment", "Traffic Management", "Istio", "Deploy Config"] ---- - -## {{% heading "prereq" %}} - -* You have read {{< linkWithTitle "cd-as-a-service/concepts/deployment/traffic-management/istio.md" >}} -* You have [installed Istio](https://istio.io/latest/docs/setup/getting-started/) in your target cluster. -* You know how to configure Istio's [VirtualService](https://istio.io/latest/docs/reference/config/networking/virtual-service/) and associated [DestinationRule](https://istio.io/latest/docs/reference/config/networking/virtual-service/#Destination). -* You know [how to create a CD-as-a-Service deployment config file]({{< ref "cd-as-a-service/tasks/deploy/create-deploy-config" >}}). - ->CD-as-a-Service does not configure proxy sidecar injection. - -## Create your Istio resources manifest - -Create a manifest that defines your VirtualService and DestinationRule resources. Armory recommends one VirtualService with one DestinationRule for your deployment. CD-as-a-Service modifies these resources based on the [canary strategy]({{< ref "cd-as-a-service/reference/ref-deployment-file#canary-fields" >}}) that you define in your deployment file. You can deploy these resources separately or as part of your CD-as-a-Service deployment. - -## Configure your CD-as-a-Service deployment - -Configure your Istio resources in the `trafficManagement.targets` section of your deployment file. - -{{< include "cdaas/dep-file/tm-istio-config.md" >}} - -## Example resources and deployment files - -In this example, you deploy an app called "reviews". You define your Istio resources in `istio-resources.yaml` and deploy that manifest as part of your app deployment. - -{{< include "cdaas/deploy/istio-example.md" >}} - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/deploy/traffic-management/linkerd.md b/content/en/cd-as-a-service/tasks/deploy/traffic-management/linkerd.md deleted file mode 100644 index 67f3f7f5e0..0000000000 --- a/content/en/cd-as-a-service/tasks/deploy/traffic-management/linkerd.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Configure Traffic Management Using Linkerd -linkTitle: Linkerd -description: > - Configure your Armory CD-as-a-Service deployment to use Linkerd for traffic management. -aliases: - - /cd-as-a-service/tasks/deploy/traffic-management/ -categories: ["Guides"] -tags: ["Deployment", "Traffic Management", "Linkerd", "Deploy Config"] ---- - -## {{% heading "prereq" %}} - -* You have read {{< linkWithTitle "cd-as-a-service/concepts/deployment/traffic-management/smi-linkerd.md" >}}. -* In your target Kubernetes cluster, you have deployed Linkerd, a service mesh that complies with the [Service Mesh Interface (SMI) spec](https://github.com/servicemeshinterface/smi-spec). -* You know [how to create a CD-as-a-Service deployment config file]({{< ref "cd-as-a-service/tasks/deploy/create-deploy-config" >}}). - ->CD-as-a-Service does not configure proxy sidecar injection. - -## Configure traffic management - -Add a top-level `trafficManagement.targets` section to your deployment file. - -{{< include "cdaas/dep-file/tm-smi-config.md" >}} - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/_index.md b/content/en/cd-as-a-service/tasks/iam/_index.md deleted file mode 100644 index 104f599f3a..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Access Management Tasks -linktitle: Access Management -description: > - This section contains Access Management tasks within Armory CD-as-a-Service. - ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/iam/client-creds.md b/content/en/cd-as-a-service/tasks/iam/client-creds.md deleted file mode 100644 index fa5affc37e..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/client-creds.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Create Client Credentials -description: > - Create machine-to-machine credentials and assign RBAC roles to them in Armory CD-as-a-Service. -categories: ["Guides"] -tags: [ "Access", "Credentials"] ---- - -## Overview - -A _Client Credential_ is a machine-to-machine credential that the CLI uses to authenticate with CD-as-a-Service when you trigger deployments as part of an external automated workflow. You pass the credential through the `clientID` and `clientSecret` parameters. - -Additionally, a Remote Network Agent uses a Client Credential for authentication when communicating with CD-as-a-Service. - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You are familiar with {{< linkWithTitle "cd-as-a-service/concepts/architecture/orgs-tenants.md" >}} and [RBAC in CD-as-a-Service]({{< ref "cd-as-a-service/concepts/iam/rbac.md" >}}) - - -## Create a Client Credential - -{{< include "cdaas/client-creds.md" >}} - -Armory recommends that you store credentials in a secret engine that is supported by the tool you want to integrate with CD-as-a-Service. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/tasks/iam/manage-role-client-cred.md" >}} -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/create-role.md b/content/en/cd-as-a-service/tasks/iam/create-role.md deleted file mode 100644 index 0b2b31d12e..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/create-role.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: Create an RBAC Role -description: > - Create an RBAC role using Armory CD-as-a-Service's CLI. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - - -## Create a new RBAC role - -By default, a new user has no permission to access functionality within CD-as-a-Service. You can assign a new user the Organization Admin role or create a custom role that defines what the user can see and do in the UI as well as from the CLI. - ->All users can start a deployment. - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You are familiar with {{< linkWithTitle "cd-as-a-service/concepts/architecture/orgs-tenants.md" >}} and {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}}. - -## How to create a custom role - -You define your roles in a YAML file using the following structure: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: - tenant: - grants: - - type: - resource: - permission: -{{< /prism >}} - -* `name`: (Required); String; name of the role -* `tenant`: (Optional); String; name of the tenant; if omitted, the role is an organization-wide role, not bound to a specific tenant -* `grants`: (Required)(Dictionary) - - * `type`: (Required); String; `api` - * `resource`: (Required); String; one of `organization`, `tenant`, or `deployment` - * `permission`: (Required); String; `full` - -After you have defined your roles, use the CLI to add those roles to CD-as-a-Service. - -{{< prism lang="bash" line-numbers="true" line="" >}} -armory login -armory config apply -f .yml -{{< /prism >}} - -You can check that you created your roles correctly by running `armory config get`. - ->**Organization Admin** is a system-defined role that does not appear in your RBAC config. - -### User role examples - -**Tenant Admin** - -A user with this role can access every screen in the `main` tenant and deploy apps using the CLI. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full -{{< /prism >}} - -**Deployer** - -A user with this role can only access the **Deployments** screen in the UI and deploy apps using the CLI. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -## SSO roles - -If your organization uses SSO with CD-as-a-Service, you must create your roles using the same names as your SSO groups. For example, your company has the following groups defined in its SSO provider: - -1. Engineering-Infra -1. Engineering-Release -1. Engineering-InfoSec - -You want to use those groups in CD-as-a-Service, so you need to create roles for those SSO groups. In the following example, `Engineering-Infra` has a Tenant Admin role. `Engineering-Release` and `Engineering-InfoSec` have tenant-scoped deployment roles. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Engineering-Infra - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Engineering-InfoSec - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: Engineering-Release - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -## {{% heading "nextSteps" %}} - -* RBAC - * {{< linkWithTitle "cd-as-a-service/tasks/iam/update-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/concepts/deployment/role-based-manual-approval.md" >}} - -* User Role Management - * {{< linkWithTitle "cd-as-a-service/tasks/iam/manage-role-user.md" >}} - * {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} - - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/delete-role.md b/content/en/cd-as-a-service/tasks/iam/delete-role.md deleted file mode 100644 index a504885810..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/delete-role.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Delete an RBAC Role -description: > - Delete an RBAC role using Armory CD-as-a-Service's CLI. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You have read {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}}. - -## How to delete a role - -Perform the following to delete a role or roles: - -1. Add `allowAutoDelete: true` to the top of your RBAC config file. -1. Remove the role(s) from your RBAC config file. -1. Log into the CLI and apply the changes: - - {{< prism lang="bash" line-numbers="true" >}} - armory login - armory config apply -f .yml{{< /prism >}} - - -For example, you have a config file with the following roles: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: Tester - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -You want to delete the Tester role. Update your config file by adding `autodelete: true` to the top and removing the Tester role entry: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -allowAutoDelete: true -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -Execute `armory config apply -f .yml` to apply your changes. - -You can check that you deleted your role by running `armory config get`. - -When you delete a role, that role is removed from existing users. You can accidentally remove the ability for your users to perform actions within CD-as-a-Service. A user with no role can still log into the UI but only sees a blank **Deployments** screen: -{{< figure src="/images/cdaas/user-no-role.png" >}} - -## {{% heading "nextSteps" %}} - -* User Role Management - * {{< linkWithTitle "cd-as-a-service/tasks/iam/manage-role-user.md" >}} - * {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} - -* {{< linkWithTitle "cd-as-a-service/troubleshoOting/rbac.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/iam/invite-users.md b/content/en/cd-as-a-service/tasks/iam/invite-users.md deleted file mode 100644 index 866f43120d..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/invite-users.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Invite a User -linktitle: Invite a User -description: > - Use the Armory CD-as-a-Service Console to invite a user to your CD-as-a-Service organization. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - -## Overview - -For your users to get access to Armory CD-as-a-Service, you must invite them to your organization. This grants them access to the Armory CD-as-a-Service UI. Depending on their permissions, they may have access to different parts of the UI. - -## {{% heading "prereq" %}} - -1. You are familiar with the concepts discussed in {{< linkWithTitle "cd-as-a-service/concepts/architecture/orgs-tenants.md" >}}. -1. You need to create at least one role or your user won't be able to access CD-as-a-Service. See {{< linkWithTitle "cd-as-a-service/tasks/iam/create-role.md" >}}. -1. You need the user's name and email address. Note that the email domain must match your organization's format. For example, users that work for Acme (which uses `username@acme.com`) must have `@acme.com` email addresses. Users are automatically added to your organization once they accept the invite and complete the sign up. - -{{% alert title="Important" color="warning" %}} -* **A user can belong to only one CD-as-as-Service Organization (company account)**. If you try to invite a person that already belongs to another org, you get a `409 Conflict: The user already exists` error. -* A user can have access to multiple tenants within a single org. -{{% /alert %}} - -## How to invite a user - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Users**. -1. Click **Invite Users** -1. Enter the new user's full name in the **Name** field and the user's email address in the **Email** field. -1. Select at least one role from the **Roles** drop down list. -1. Click **Send Invitation**. -1. A modal window opens. Review the information and click **OK** to send the information or **Cancel** to return to the previous screen. - -The new user receives an email with instructions for accessing the CD-as-a-Service Console. - - -## {{% heading "nextSteps" %}} - -* RBAC - * {{< linkWithTitle "cd-as-a-service/tasks/iam/update-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}} - -* User Role Management - * {{< linkWithTitle "cd-as-a-service/tasks/iam/manage-role-user.md" >}} - * {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/manage-role-client-cred.md b/content/en/cd-as-a-service/tasks/iam/manage-role-client-cred.md deleted file mode 100644 index 7128bd09b5..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/manage-role-client-cred.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Manage a Client Credential's RBAC Role -linkTitle: Manage Credential's Role -description: > - Assign and revoke a Client Credential's RBAC role in Armory CD-as-a-Service. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You are familiar with [RBAC in CD-as-a-Service]({{< ref "cd-as-a-service/concepts/iam/rbac.md" >}}) -* You have [created a Client Credential]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}). - -## How to assign a role - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Client Credentials**. -1. Find the credential you want to update. Click the **pencil icon** to open the **Update** screen. -1. In the **Update** screen, place your cursor in the **Select Roles** field and click. -1. Select a role from the drop-down list. Repeat if you want to assign the credential more than one role. Selected roles appear below the **Select Roles** drop-down list. -1. Click the **Update Credential** button. - -## How to revoke a role - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Client Credentials**. -1. Find the Client Credential you want to update. Click the **pencil icon** to open the **Update** screen. -1. In the **Update** screen, you can see a credential's roles listed below the **Select Roles** field. -1. Each assigned role has an **x** next to it. Click the **x** to revoke the role. - ->Make sure your Client Credential has at least one role! - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/manage-role-user.md b/content/en/cd-as-a-service/tasks/iam/manage-role-user.md deleted file mode 100644 index 9faa9c1fa6..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/manage-role-user.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Manage a User's RBAC Role -linkTitle: Manage User's Role -description: > - Assign and revoke a user's RBAC role in Armory CD-as-a-Service. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You have [created RBAC roles]({{< ref "cd-as-a-service/tasks/iam/create-role.md" >}}) for your users. - -## How to assign a role - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Users**. -1. Find the user you want to update. Click the **pencil icon** to open the **Edit User** screen. -1. In the **Edit User** screen, place your cursor in the **Roles** field and click. -1. Select a role from the drop-down list. Repeat if you want to assign the user more than one role. Selected roles appear below the **Roles** drop-down list. -1. Click the **Save Roles** button. - -## How to revoke a role - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Users**. -1. Find the user you want to update. Click the **pencil icon** to open the **Edit User** screen. -1. In the **Edit User** screen, you can see a user's roles listed below the **Roles** field. -1. Each assigned role has an **x** next to it. Click the **x** to remoke the role. - -{{< figure src="/images/cdaas/user-role-delete.jpg" alt="User role with arrow pointing at 'x' to delete" >}} - - ->Make sure your user has at least one role! - -## {{% heading "nextSteps" %}} - -* RBAC - * {{< linkWithTitle "cd-as-a-service/tasks/iam/update-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}} - -* User Role Management - * {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} tutorial - -* {{< linkWithTitle "cd-as-a-service/troubleshooting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/iam/update-role.md b/content/en/cd-as-a-service/tasks/iam/update-role.md deleted file mode 100644 index b78c3ece95..0000000000 --- a/content/en/cd-as-a-service/tasks/iam/update-role.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Update an RBAC Role -description: > - Update an RBAC role using Armory CD-as-a-Service's CLI. -categories: ["Guides"] -tags: [ "Access", "RBAC"] ---- - -## {{% heading "prereq" %}} - -* You are an Organization or Tenant Admin within CD-as-a-Service. -* You have read {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}}. - -## How to update a role - -Perform the following to update a role or roles: - -1. Update the existing role(s) in your RBAC config file. -1. Log into the CLI and apply the changes: - - {{< prism lang="bash" line-numbers="true" >}} - armory login - armory config apply -f .yml{{< /prism >}} - - -For example, you created the following roles: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: Tester - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -You notice that the Tester role has no `tenant` defined, which means the role is organization-wide. Update your config file to add the tenant: - -{{< prism lang="yaml" line-numbers="true" line="14" >}} -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: Tester - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -Execute `armory config apply -f .yml` to apply your changes. - -You can check that you updated your role correctly by running `armory config get`. - ->The role name is case insensitive. "DeployM2m" is the same as "DeployM2M", so if you want to change capitalization in a role name, you must delete the role and add a new role with the name's corrected capitalization. - -## {{% heading "nextSteps" %}} - -* RBAC - * {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}} - -* User Role Management - * {{< linkWithTitle "cd-as-a-service/tasks/iam/manage-role-user.md" >}} - * {{< linkWithTitle "cd-as-a-service/tutorials/access-management/rbac-users.md" >}} - -* {{< linkWithTitle "cd-as-a-service/troubleshoOting/rbac.md" >}} diff --git a/content/en/cd-as-a-service/tasks/networking/_index.md b/content/en/cd-as-a-service/tasks/networking/_index.md deleted file mode 100644 index 1d0df4bb49..0000000000 --- a/content/en/cd-as-a-service/tasks/networking/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Remote Network Agent Tasks -linktitle: Remote Network Agents -description: > - This section contains Armory CD-as-a-Service Remote Network Agent (RNA) tasks such as manually installing an RNA and monitoring an RNA from the UI. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/networking/install-agent.md b/content/en/cd-as-a-service/tasks/networking/install-agent.md deleted file mode 100644 index 7870d0ec96..0000000000 --- a/content/en/cd-as-a-service/tasks/networking/install-agent.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Install a Remote Network Agent in Your Cluster -linktitle: Install RNA -description: > - Install a CD-as-a-Service Remote Network Agent in your Kubernetes cluster. -categories: ["Guides"] -tags: [ "Networking", "Remote Network Agent", "CD-as-as-Service Setup"] ---- - - - -## Remote Network Agent installation methods - -By default, you install a Remote Network Agent (RNA) with full access to your cluster. At a minimum, the RNA needs permissions to create, edit, and delete all `kind` objects that you plan to deploy with CD-as-a-Service, in all namespaces you plan to deploy to. The RNA also requires network access to any monitoring solutions or webhook APIs that you plan to forward through it. - -You can install the Remote Network Agent (RNA) in your Kubernetes cluster using one of the following: - -* [**UI wizard**](#generate-install-script-using-a-ui-wizard) - * Use a UI wizard to generate an install script that includes **Client Credentials** - * Install using default configuration - * Not recommended for production environments -* [**CLI**](#install-manually-using-the-cli) - * Install using default configuration - * Not recommended for production environments -* [**kubectl**](#install-manually-using-kubectl) - * Install using default configuration - * Not recommended for production environments -* [**Helm**](#install-manually-using-helm) - * Install using default or advanced configuration - * Recommended for production environments - -{{% alert title="Important" color="warning" %}} -If you are coming to this guide from the UI **Install a Remote Network Agent** screen because you want to manually install the RNA, follow the [Helm instructions](#install-using-helm). Use the cluster name you created to identify your RNA. Copy the **Client ID** and **Client Secret** from the UI. - -_Do not close the pop-up window in the UI until you have completed RNA installation. The credentials in the pop-up window are deleted if you close the window before the RNA has connected._ -{{% /alert %}} - -## {{% heading "prereq" %}} - -* You have a role that allows you to create **Client Credentials** and connect a Remote Network Agent. -* You have access to your own Kubernetes cluster. - -## Generate install script using a UI wizard - ->You do not need to create **Client Credentials** for these options. The UI does that for you. - -### Option 1 - -1. In the CD-as-a-Service Console, navigate to the **Welcome to Continuous Deployment-as-a-Service** [Configuration page](https://console.cloud.armory.io/configuration). -1. Click **Connect your Kubernetes Cluster**. -1. In the **Select Installation Method** window, select either **Connect Cluster Using Helm** or **Connect Cluster Using Kubectl**. -1. In the **Identify Your Cluster** window, enter an agent identifier for your Remote Network Agent (RNA) in the **Cluster Name** field. You install this RNA in the cluster where you want to deploy your app, so create a meaningful identifier. -1. Click **Continue**. -1. Copy the script from the **Connect New Remote Network Agent** window and run it locally. - -### Option 2 - -{{< include "cdaas/rna-ui-add-agent.md" >}} - -## Install manually using the CLI - ->You do not need to create **Client Credentials** for this option. The CLI does that for you. - -1. Install the CLI if you haven't already. - - {{< include "cdaas/install-cli.md" >}} - -1. Log in using the CLI. - - ```shell - armory login - ``` - -1. Install the RNA in your cluster. - - ```shell - armory agent create - ``` - - You choose your cluster and provide an **agent identifier** (cluster name) for the RNA during the installation process. - -## Install manually using kubectl - -### {{% heading "prereq" %}} - -You have **Client Credentials** with Remote Network Agent permissions. - -
Show me how -{{< include "cdaas/client-creds.md" >}} - -
- -### Steps - -{{< include "cdaas/rna-install-kubectl.md" >}} - -## Install manually using Helm - -### {{% heading "prereq" %}} - -You have **Client Credentials** with Remote Network Agent permissions. - -
Show me how -{{< include "cdaas/client-creds.md" >}} -
- -### Steps - -{{< include "cdaas/rna-install-helm.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/networking/monitor-agents.md b/content/en/cd-as-a-service/tasks/networking/monitor-agents.md deleted file mode 100644 index 2d044e38c7..0000000000 --- a/content/en/cd-as-a-service/tasks/networking/monitor-agents.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Monitor Installed Remote Network Agents -linktitle: Monitor Agents -description: > - Monitor Remote Network Agents using the Armory CD-as-a-Service console. -categories: ["Guides"] -tags: [ "Networking", "Remote Network Agent"] ---- - -## Monitor connected agents - -[**Networking > Agents**](https://console.cloud.armory.io/configuration/agents) - -The **Agents** page shows you the list of agents that are connected if the credentials they use have the `connect:agentHub` scope. - -> Note that you may see a "No Data" message when first loading the **Agents** page even if there are successfully connected RNAs. - -The Agent Hub (Armory's hosted cloud service) and the RNA on your clusters perform periodic healthchecks to ensure that the connection between the Agent Hub and your target deployment cluster is working. If the healthcheck fails, the RNA is removed from the list. When a subsequent check passes, the RNA and its cluster are added back to the list with the **Connected At** column showing when the connection was re-established. - -{{< figure src="/images/cdaas/ui-rna-status.jpg" alt="The Connected Remote Network Agents page shows connected agents and the following information: Agent Identifier, Agent Version, Connection Time when the connection was established, Last Heartbeat time, Client ID, and IP Address." >}} - diff --git a/content/en/cd-as-a-service/tasks/secrets/_index.md b/content/en/cd-as-a-service/tasks/secrets/_index.md deleted file mode 100644 index 15ae4cbde9..0000000000 --- a/content/en/cd-as-a-service/tasks/secrets/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Secrets Tasks -linktitle: Secrets -description: > - This section contains Secrets tasks within Armory CD-as-a-Service. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/secrets/secrets-create.md b/content/en/cd-as-a-service/tasks/secrets/secrets-create.md deleted file mode 100644 index 48af59bf0a..0000000000 --- a/content/en/cd-as-a-service/tasks/secrets/secrets-create.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Create and Reference Secrets -linktitle: Create Secrets -description: > - Use secrets to integrate Armory CD-as-a-Service with external systems and tools. -aliases: - - /cd-as-a-service/tasks/iam/secrets-create/ -categories: ["Guides"] -tags: [ "Access", "Secrets"] ---- - - -## Create a secret - -Follow these steps to create a secret: - -1. Log into the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Click the **Secrets** tab. -1. Click **New Secret**. -1. Fill in the **Name** and **Value** fields. Use a descriptive name. - -You use the name to reference the secret in the CD-as-a-Service Console or in your app's deployment file. - -Once created, a secret's raw value cannot be retrieved through Armory's API, UI, or CLI. - - -## Reference a secret - -Armory CD-as-a-Service uses [mustache template syntax](https://mustache.github.io/mustache.5.html) to reference secrets. - -Only variable tag types are supported. - -You can reference a secret in any input field in the CD-as-a-Service Console or in the [deployment YAML]({{< ref "ref-deployment-file" >}}). - -Reference a secret with a `secrets.` prefix followed by the secret's name. For example, if your secret is named `prod-cluster-token`, you can reference it in a form field or the deployment YAML DSL as `{{ secrets.prod-cluster-token }}`. - - diff --git a/content/en/cd-as-a-service/tasks/tenants/_index.md b/content/en/cd-as-a-service/tasks/tenants/_index.md deleted file mode 100644 index 95a5d8e7b0..0000000000 --- a/content/en/cd-as-a-service/tasks/tenants/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Tenant Tasks -linktitle: Tenants -description: > - This section contains Armory CD-as-a-Service Tenant tasks such as creating tenants using the CLI and switching tenants in the UI. ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tasks/tenants/add-tenants.md b/content/en/cd-as-a-service/tasks/tenants/add-tenants.md deleted file mode 100644 index fac29462e4..0000000000 --- a/content/en/cd-as-a-service/tasks/tenants/add-tenants.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Add Tenants -description: > - Add tenants to your Armory CD-as-a-Service organization. -categories: ["Guides"] -tags: [ "Tenants"] ---- - -## {{% heading "prereq" %}} - -* You have the Organization Admin role. -* You have installed the CLI and are logged into CD-as-a-Service. - -## Create tenants - -Every organization has a `main` tenant. You can create one or more additional tenants using a YAML file and the CLI. Your YAML file should have the following structure: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -tenants: - - - - -{{< /prism >}} - -Run the following command to add those tenants: - -{{< prism lang="yaml" line-numbers="true" line="" >}} -armory config apply -f -{{< /prism >}} - -## Example - -In the following example, you create tenants for two applications and a sandbox. - -1. Create a file called `config.yaml`. -1. Add the following content: - - {{< prism lang="yaml" line-numbers="true" line="" >}} - tenants: - - potato-facts-app - - sample-app - - sandbox{{< /prism >}} - - Save your file. - -1. Run the following command from the directory where you saved your `config.yaml` file: - - {{< prism lang="yaml" line-numbers="true" line="" >}} - armory config apply -f config.yaml{{< /prism >}} - - Output should be: - - {{< prism lang="bash" line-numbers="true" >}} - Created tenant: potato-facts-app - Created tenant: sample-app - Created tenant: sandbox{{< /prism >}} - -1. Confirm your tenants have been added: - - {{< prism lang="bash" line-numbers="true" >}} - armory config get{{< /prism >}} - - Output should be: - - {{< prism lang="bash" line-numbers="true" >}} - tenants: - - main - - potato-facts-app - - sample-app - - sandbox{{< /prism >}} - -## {{% heading "nextSteps" %}} - -{{< linkWithTitle "cd-as-a-service/tasks/tenants/switch-tenants.md" >}} diff --git a/content/en/cd-as-a-service/tasks/tenants/switch-tenants.md b/content/en/cd-as-a-service/tasks/tenants/switch-tenants.md deleted file mode 100644 index 2989b2655e..0000000000 --- a/content/en/cd-as-a-service/tasks/tenants/switch-tenants.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: View and Switch Tenants -description: > - View and switch tenants in your Armory CD-as-a-Service organization. -categories: ["Guides"] -tags: [ "Tenants"] ---- - -## {{% heading "prereq" %}} - -* You have installed the CLI and are logged into CD-as-a-Service. - -## View tenants - ->Non-Admin users only see tenants that they belong to. If users don't have a role belonging to a particular tenant, they don't see those tenants. - -You can use the CLI to view your tenants: - -{{< prism lang="bash" line-numbers="true" >}} -armory config get -{{< /prism >}} - -Output shows the list of tenants. When you only have access to the default tenant, the output is: - -{{< prism lang="bash" line-numbers="true" >}} -tenants: - - main -{{< /prism >}} - -You can also use the UI to view the list of tenants you can access. See the [Switch tenants](#switch-tenants) section. - -## Switch tenants - -You use the UI to switch to the tenant whose resources you want to see. CD-as-a-Service only displays the **Switch Tenants* user content menu item when you have access to more than one tenant. - -{{< figure src="/images/cdaas/ui-switch-tenant.jpg" alt="Switch Tenant." >}} - -1. Access your user context menu. -1. Hover over **Switch Tenant** to display a list of accessible tenants. -1. Click the tenant you want to switch to. - diff --git a/content/en/cd-as-a-service/tasks/webhook-approval.md b/content/en/cd-as-a-service/tasks/webhook-approval.md deleted file mode 100644 index 75f8fc0d3b..0000000000 --- a/content/en/cd-as-a-service/tasks/webhook-approval.md +++ /dev/null @@ -1,189 +0,0 @@ ---- -title: Configure a Webhook in the Deployment File -linkTitle: Configure a Webhook -description: > - Configure a webhook-based approval into your Armory CD-as-a-Service app deployment process. -categories: ["Guides"] -tags: [ "Webhooks", "Deploy Config"] ---- - -## {{% heading "prereq" %}} - -You have read the {{< linkWithTitle "cd-as-a-service/concepts/external-automation.md" >}} guide. - -## How to configure a webhook in your deployment file - -In your deployment file, you configure your webhook by adding a top-level `webhooks` section with the following information: - -{{< include "cdaas/dep-file/webhooks-config.md" >}} - -### Configuration examples - -The first example configures a GitHub webhook that uses token authorization, with the token value configured as a Armory CD-as-a-Service secret. This webhook requires the callback URI be passed in the request body. The payload also contains context variables that you pass in when invoking the webhook in your deployment file. - -{{< prism lang="yaml" line-numbers="true" line="8, 16-17" >}} -webhooks: - - name: myWebhook - method: POST - uriTemplate: https://api.github.com/repos/armory/docs-cdaas-sample/dispatches - networkMode: direct - headers: - - key: Authorization - value: token {{secrets.github_token}} - - key: Content-Type - value: application/json - bodyTemplate: - inline: >- - { - "event_type": "webhookCallback", - "client_payload": { - "callbackUri": "{{armory.callbackUri}}/callback" - "environment": "{{armory.environmentName}}" - "applicationName": "{{armory.applicationName}}" - "replicaSetName": "{{armory.replicaSetName}}" - } - } - retryCount: 3 -{{< /prism >}} -
- -The second example configures a webhook that is not accessible from the internet. The `networkMode` is set to `remoteNetworkAgent` and the `agentIdentifier` specifies which Remote Network Agent to use. The `agentIdentifier` value must match the **Agent Identifier** value listed on the **Agents** UI screen. The Authorization Bearer value is configured as a Armory CD-as-a-Service secret. Note that in this example, the callback URI is passed in the header. - -{{< prism lang="yaml" line-numbers="true" line="5-6, 9, 11" >}} -webhooks: - - name: integration-tests - method: POST - uriTemplate: https://integrations.armory.io/tests/ - networkMode: remoteNetworkAgent - agentIdentifier: test-rna - headers: - - key: Authorization - value: Bearer {{secrets.test_token}} - - key: Location - value: {{armory.callbackUri}}/callback - - key: Content-Type - value: application/json - - key: environment - value: {{context.environment}} - - key: applicationName - value: {{armory.applicationName}} - - key: replicaSetName - value: {{armory.replicaSetName}} - retryCount: 5 -{{< /prism >}} - - -## How to trigger a webhook - -You can trigger a webhook from the following areas: - -- Deployment constraints: `beforeDeployment` and `afterDeployment` -- A canary step within a canary strategy -- The `redirectTrafficAfter` section of a blue/green strategy - -You add a `runWebhooks` section where you want to trigger the webhook. - -{{< prism lang="yaml" line-numbers="true" >}} -- runWebhook: - name: - context: - myCustomKey: myCustomValue -{{< /prism >}} - -- `name`: (Required) webhook name; must match the name you gave your webhook in the `webhooks` configuration section. -- `context`: (Optional) dictionary; declare values to use in templates or headers. - -### Deployment constraints - -**Before deployment** - -In this example, you have a webhook named `Update-Database-Schema`. You want to trigger this webhook before your app gets deployed. So you trigger the webhook in the `beforeDeployment` constraint of your environment deployment. - -{{< prism lang="yaml" line-numbers="true" line="8-9" >}} -targets: - dev: - account: dev-cluster - namespace: myApp-dev - strategy: rolling-canary - constraints: - beforeDeployment: - - runWebhook: - name: Update-Database-Schema -{{< /prism >}} - -App deployment proceeds only if the `Update-Database-Schema` callback sends a "success: true" message. - -**After deployment** - -In this example, you have a webhook named `Run-Integration-Tests`. You want to trigger this webhook after your app has been deployed to staging but before it gets deployed to production. So you trigger the webhook in the `afterDeployment` constraint of your staging environment deployment. - -{{< prism lang="yaml" line-numbers="true" line="8-11" >}} -targets: - staging: - account: staging-cluster - namespace: myApp-staging - strategy: rolling-canary - constraints: - afterDeployment: - - runWebhook: - name: Run-Integration-Tests - context: - environment: staging - prod: - account: prod-cluster - namespace: myApp-prod - strategy: rolling-canary - constraints: - dependsOn: ["staging"] -{{< /prism >}} - -Deployment to production proceeds only if the `Run-Integration-Tests` callback sends a "success: true" message. - -### Blue/green strategy - -In this example, there is a `security-scan` webhook that scans your deployed app. You have a blue/green deployment strategy in which you want to run that security scan on the preview version of your app before switching traffic to it. You add the `runWebhook` section to the `redirectTrafficAfter` section in your blue/green strategy configuration. - -{{< prism lang="yaml" line-numbers="true" line="15-16" >}} -strategies: - myBlueGreen: - blueGreen: - activeService: myApp-external - previewService: myApp-preview - redirectTrafficAfter: - - analysis: - interval: 7 - units: seconds - numberOfJudgmentRuns: 1 - rollBackMode: manual - rollForwardMode: automatic - queries: - - avgCPUUsage-pass - - runWebhook: - name: security-scan -{{< /prism >}} - -Since tasks in the `redirectTrafficAfter` section run in parallel, both tasks in this example must be successful for deployment to continue. If the `analysis` task fails, rollback is manual. If the `runWebhook` task fails, rollback is automatic. - -### Canary strategy - -In this example, there is a `system-health` webhook that you want to trigger as part of your canary strategy. Add the `runWebhook` section to your `steps` configuration. - -{{< prism lang="yaml" line-numbers="true" line="7-10" >}} -strategies: - canary-rolling: - canary: - steps: - - setWeight: - weight: 25 - - runWebhook: - name: system-health - context: - environment: staging -{{< /prism >}} - - -## {{% heading "nextSteps" %}} - -* [Webhooks section in the deployment file reference]({{< ref "cd-as-a-service/reference/ref-deployment-file#webhooks." >}}) -* {{< linkWithTitle "cd-as-a-service/tutorials/external-automation/webhook-github.md" >}} -* {{< linkWithTitle "cd-as-a-service/troubleshooting/webhook.md" >}} diff --git a/content/en/cd-as-a-service/troubleshooting/_index.md b/content/en/cd-as-a-service/troubleshooting/_index.md deleted file mode 100644 index 65d3a0d7f9..0000000000 --- a/content/en/cd-as-a-service/troubleshooting/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Troubleshooting CD-as-a-Service -linktitle: Troubleshooting -description: > - Troubleshoot Armory Continuous Deployment-as-a-Service. -weight: 60 ---- - diff --git a/content/en/cd-as-a-service/troubleshooting/rbac.md b/content/en/cd-as-a-service/troubleshooting/rbac.md deleted file mode 100644 index d1b75ad54f..0000000000 --- a/content/en/cd-as-a-service/troubleshooting/rbac.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Troubleshoot Role-Based Access Control -linktitle: RBAC -description: > - Solutions for issues you might encounter while using RBAC in Armory Continuous Deployment-as-a-Service. -categories: ["Troubleshooting"] -tags: ["Access", "RBAC"] ---- - -## User sees blank **Deployments** screen - -{{< figure src="/images/cdaas/user-no-role.png" alt="User sees the Deployments screen with no deployments." >}} - -**Why this happens** -
-{{< tabs name="no-role" >}} -{{% tabbody name="No SSO" %}} -The user doesn't have an RBAC role. This happens when: - -* The Organization Admin didn't create any RBAC roles. -* The Organization or Tenant Admin didn't assign an existing role when inviting the user. -* The Organization or Tenant Admin deleted a role and didn't assign a new role to affected users. - -Organization Admin is a system role. CD-as-a-Service automatically assigns that role to the user who creates a new CD-as-a-Service organization. That role is not auto-assigned to anyone else in the organization. You can, however, assign the Organization Admin role to anyone you invite. - -**Fixes** -
-* Assign the existing Organization Admin role to the affected user. -* [Create at least one custom RBAC role]({{< ref "cd-as-a-service/tasks/iam/create-role.md" >}}) and then [assign that RBAC role]({{< ref "cd-as-a-service/tasks/iam/manage-role-user.md" >}}) to the affected user. - -{{% /tabbody %}} -{{% tabbody name="SSO" %}} - -* The user doesn't have the correct SSO groups assigned in your company's SSO provider. -* The Organization or Tenant Admin didn't create an RBAC role that corresponds to the SSO group. The CD-as-a-Service RBAC role name must be identical to the SSO group name. - -**Fix** -
-* [Create RBAC roles]({{< ref "cd-as-a-service/tasks/iam/create-role#sso-roles" >}}) to match the SSO groups that you want to use with CD-as-a-Service. - - -{{% /tabbody %}} -{{< /tabs >}} - - diff --git a/content/en/cd-as-a-service/troubleshooting/tools.md b/content/en/cd-as-a-service/troubleshooting/tools.md deleted file mode 100644 index e9f5f11cb6..0000000000 --- a/content/en/cd-as-a-service/troubleshooting/tools.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Troubleshoot CD-as-a-Service Tools -linkTitle: Tools -description: > - Solutions for issues you might encounter while using the Armory Continuous Deployment-as-a-Service AVM, CLI, or GitHub Action. -categories: ["Troubleshooting"] -tags: ["Tools"] ---- - -## Troubleshooting overview - -The CLI and GitHub Action (GHA) both call the same API, so you should see similar error reporting in both tools. - -## Initial deployment failure: orphaned ReplicaSet - -If the initial deployment of your app fails or is manually rolled back, the ReplicaSet is orphaned rather than deleted. In this situation, you should manually delete the orphaned ReplicaSet _only after the initial deployment runs successfully_. - -Follow these steps to delete the orphaned ReplicaSet: - -1. Get a list of ReplicaSet objects - - ```bash - kubectl get rs -n - ``` - -1. Identify the ReplicaSet with the old version of your application. This is typically the ReplicaSet with the greater age. -1. Delete the orphaned ReplicaSet: - - ```bash - kubectl delete rs -n - ``` - -## Common CLI and GHA error messages - -## Status code 422 - -When you don't have a publicly accessible Remote Network Agent (RNA) running in your target deployment cluster, you see a message similar to this: - -```bash -Error: request returned an error: status code(422), thrown error: {"error_id":"c0b7c916-e28f-4f65-b29f-7343c899c168","errors":[{"message":"account 'aimeeu-local' does not exist","code":"42"}]} -``` - -`account` is the name of the RNA that you configured in your CD-as-a-Service deployment file. You can check your RNA status in the **Configuration** > **Networking** > **Agents** screen of the Armory Cloud Console. - - -## CLI - -### Error writing credentials file - -`error: Error: there was an error writing the credentials file. ` - -This issue occurs because the directory the CLI stores your credentials in after you run `armory login` does not exist. You can create the directory by running the following command: - -```bash -mkdir ~/.armory/credentials -``` - -Make sure you are running the latest version of the CLI. - - -## GitHub Action - -GitHub Actions [docs](https://docs.github.com/en/actions) - - - [Using workflows](https://docs.github.com/en/actions/using-workflows/about-workflows) - - [Troubleshooting and monitoring GitHub Actions](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting) - -### Failed to fetch access token - -Check the syntax and spelling of your GitHub secrets in your workflow file. For example, if you named your GitHub secrets **CDAAS_CLIENT_ID** and **CDAAS_CLIENT_SECRET**, your config should look like: - -```yaml -clientId: ${{ secrets.CDAAS_CLIENT_ID }} -clientSecret: ${{ secrets.CDAAS_CLIENT_SECRET }} -``` - -## Armory Version Manager (AVM) - -### Developer cannot be verified error when trying to run AVM - -Depending on your operating system settings, you may need to allow apps from an unidentified developer in order to use AVM. For macOS, go to **System Preferences > Security & Privacy > General** and click **Allow Anyway**. For more information, see the macOS documentation about [how to open a Mac app from an unidentified developer](https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac). - -### Bad CPU type - -`bad CPU type in executable` - -This issue occurs if the AVM version you downloaded does not match your CPU architecture. For example, if you try to run an `arm64` build on a system that is not ARM based. Verify that you downloaded the correct AVM version for your system. \ No newline at end of file diff --git a/content/en/cd-as-a-service/troubleshooting/webhook.md b/content/en/cd-as-a-service/troubleshooting/webhook.md deleted file mode 100644 index c33ef0a742..0000000000 --- a/content/en/cd-as-a-service/troubleshooting/webhook.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Troubleshoot Webhooks -linktitle: Webhooks -description: > - Solutions for issues you might encounter while using webhooks with Armory Continuous Deployment-as-a-Service. -categories: ["Troubleshooting"] -tags: ["Webhooks"] ---- - -## GitHub - -### 401 status code - -In the UI, you see a `Received non-200 status code: 401` error. - -**Why this happens** - -You pass invalid credentials. - -**Fix** - -Check that your GitHub access token is valid. - -### 404 status code - -``` -404 Not Found: [{"message":"Not Found","documentation_url":"https://docs.github.com/rest"}] -``` - -**Why this happens** - -This is a confusing error that occurs when you do not send authorization credentials in the header. - -**Fix** - -Make sure you include your GitHub token in the request header. - -{{< prism lang="yaml" >}} -headers: -- key: Authorization - value: token {{secrets.github_personal_access_token}} -{{< /prism >}} - -### Failed to fetch access token - -{{< prism lang="bash" >}} -level=fatal msg="failed to fetch access token, err: no credentials set or expired. Either run armory login command to interactively login, or add clientId and clientSecret flags to specify service account credentials" -{{< /prism >}} - -You may see this error when you are using Secrets in a reusable workflow. - -**Why this happens** - -The reusable workflow does not automatically inherit Secrets from the caller worklow. - -**Fix** - -You need to explicitly configure your reusable workflow to inherit Secrets. See the [GitHub docs](https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow) for details. - -### Webhook process runs for a long time - -**Why this happens** - -The call to your action wasn't successful or your workflow didn't trigger the callback. - -**Fixes** - -Check your repo to see if your action is also still running. - -* If the action hasn't started, the call to your action wasn't successful. The UI should display an error message with a non-200 HTTP return code when the webhook process times out. In the meantime, check your deployment file to make sure the following fields have the correct values: - - - `uriTemplate` - - `networkMode` and optionally `agentIdentifier` - - `event_type` in the inline body template - - If you find an error, cancel your deployment before fixing and redeploying. - -* If your GitHub action workflow has completed, your workflow failed to trigger the callback to Armory CD-as-a-Service. Check GitHub's [Monitoring and troubleshooting workflows](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows) for troubleshooting suggestions. - - - - - - - - diff --git a/content/en/cd-as-a-service/tutorials/_index.md b/content/en/cd-as-a-service/tutorials/_index.md deleted file mode 100644 index 9739281cb6..0000000000 --- a/content/en/cd-as-a-service/tutorials/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Tutorials -linktitle: Tutorials -description: > - Armory Continuous Deployment-as-a-Service tutorials show you a series of steps, or tasks, to achieve a goal. - -weight: 40 ---- - -End-to-end tutorials for Armory CD-as-a-Service functionality. Begin with {{< linkWithTitle "deploy-sample-app.md" >}}. \ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/access-management/_index.md b/content/en/cd-as-a-service/tutorials/access-management/_index.md deleted file mode 100644 index c1efdace47..0000000000 --- a/content/en/cd-as-a-service/tutorials/access-management/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Access Management Tutorials -linktitle: Access Management -description: > - Learn how to leverage access management such as Role-Based Access Control (RBAC). ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/access-management/rbac-users.md b/content/en/cd-as-a-service/tutorials/access-management/rbac-users.md deleted file mode 100644 index 779834d724..0000000000 --- a/content/en/cd-as-a-service/tutorials/access-management/rbac-users.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Create and Manage RBAC Roles -linktitle: RBAC Roles -description: > - Learn how to configure and use Role-Based Access Control (RBAC) for Armory Continuous Deployment-as-a-Service users. -categories: ["Tutorials"] -tags: ["RBAC"] ---- - -## Objectives - -You are the CD-as-a-Service Organization Admin and lead a small development team that you want to invite to use CD-as-a-Service. Before you add your team, you need to create roles that define what a user can see in the UI. - - -In this tutorial, you learn how to: - -* [Define and add RBAC roles](#define-and-add-rbac-roles) in a YAML file. -* [Invite users and assign roles](#invite-users-and-assign-roles). -* [Modify your RBAC roles](#modify-your-rbac-roles). - - -## {{% heading "prereq" %}} - -* You have completed the Armory CD-as-a-Service [quickstart]({{< ref "cd-as-a-service/setup/quickstart" >}}), in which you create your login credentials, install the CLI, and deploy an example app. -* You are familiar with the following content: - - * {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/create-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/update-role.md" >}} - * {{< linkWithTitle "cd-as-a-service/tasks/iam/delete-role.md" >}} - -## Define and add RBAC roles - - -You want to create the following roles for your team: - -| Name | Description | Tenant | Grant Type | Grant Resource | Grant Permission | -|--------------|------------------------------------------------------------------|--------|------------|----------------|------------------| -| Tenant Admin | Same grants as the Org Admin but scoped to the tenant | main | api | tenant | full | -| Deployer | Engineer who can deploy apps using the CLI and monitor in the UI | main | api | deployment | full | -| Tester | Tester who can deploy apps using the CLI and monitor in the UI | main | api | deployment | full | - - -Create a file called `config.yml`. Add the following content, which deliberately contains a few mistakes: - -{{< prism lang="yaml" line-numbers="true" >}} ---- -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Tester - tenant: main - grants: - - type: api - resource: tenant - permission: full -{{< /prism >}} - -In the directory where you saved your `config.yml` file, log into CD-as-a-Service using the CLI and then execute: - -{{< prism lang="bash" line-numbers="true" >}} -armory config apply -f config.yml -{{< /prism >}} - -Then check that the roles are correct by executing: - -{{< prism lang="bash" line-numbers="true" >}} -armory config get -{{< /prism >}} - -The output should match the contents of your `config.yml` file. - -## Invite users and assign roles - -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Navigate to **Access Management** > **Users**. -1. Click **Invite Users** -1. Enter the new user's full name in the **Name** field and the user's email address in the **Email** field. -1. Select the **Tenant Admin** role from the **Roles** drop down list. -1. Click **Send Invitation**. -1. A modal window opens. Review the information and click **OK** to send the information or **Cancel** to return to the previous screen. - -Repeat the process for the Deployer and Tester roles. - - - - - -## Modify your RBAC roles - -Due to a hasty copy/paste, you inadvertently granted the Deployer and Tester roles full access to the main tenant. You need to change that. Also, since Deployer and Tester have the same grants, you want to eliminate the Tester role. You can do both in a single update to your `config.yml` file: - -1. Add the `allowAutoDelete: true` line and remove the Tester role entry. -1. Change `tenant` to `deployment` in the Deployer role config. - -Your config should look like this: - -{{< prism lang="yaml" line-numbers="true" line="2, 14" >}} ---- -allowAutoDelete: true -roles: - - name: Tenant Admin - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -Execute: - -{{< prism lang="bash" line-numbers="true" >}} -armory config apply -f config.yml -{{< /prism >}} - -Then check that the roles are correct by running: - -{{< prism lang="bash" line-numbers="true" >}} -armory config get -{{< /prism >}} - -Lastly, since you eliminiated the Tester role, you need to update the user you originally assigned the Tester role. Access that user in the **Access Management** > **Users** screen and edit the user to assign the Deployer role. - -## {{% heading "nextSteps" %}} - -* {{< linkWithTitle "cd-as-a-service/troubleshoOting/rbac.md" >}} \ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/access-management/rbac.md b/content/en/cd-as-a-service/tutorials/access-management/rbac.md deleted file mode 100644 index 4fa44fade0..0000000000 --- a/content/en/cd-as-a-service/tutorials/access-management/rbac.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Role-Based Access Control -linktitle: RBAC -description: > - Learn how to configure and use Role-Based Access Control (RBAC) in Armory Continuous Deployment-as-a-Service. -draft: true ---- - - - -## Objectives - -You are the CD-as-a-Service Organization Admin and lead a small development team that has one software engineer and one intern. - -Your Kubernetes cluster has four environments: `test`, `staging`, `prod-eu`, and `prod-us`. - -Your team has two apps to deploy: - -* Prod App - deploy to all environments -* Intern App - the intern's app; deploy to test and staging environments - -You want your intern to use CD-as-a-Service to deploy Intern App and monitor the progress on the **Deployments** screen. However, you don't want your intern to deploy Prod App. With CD-as-a-Service's Role-Based Access Control, you can create a role for your team to start deployments and view them in the UI. You can also restrict who deploys the Prod App by creating a app-specific role. - -In this tutorial, you learn how to: - -* [Fork and clone the repo](#fork-and-clone-the-repo) -* [Connect your cluster](#connect-your-cluster) -* [Create RBAC roles](#create-rbac-roles) - - -## {{% heading "prereq" %}} - -* You have installed `kubectl` and have access to a Kubernetes cluster -* You have [set up your Armory CD-as-a-Service account]({{< ref "get-started" >}}). -* You have [installed the `armory` CLI]({{< ref "cd-as-a-service/setup/cli" >}}). -* You have installed [Helm](https://helm.sh/docs/intro/install/). -* You have a GitHub account so you can fork the sample project. -* You have read the {{< linkWithTitle "cd-as-a-service/concepts/iam/rbac.md" >}} content. -* You have completed the {{< linkWithTitle "cd-as-a-service/tutorials/deploy-sample-app.md" >}}. - -## Fork and clone the repo - -[Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the [sample repo](https://github.com/armory/docs-cdaas-sample) to your own GitHub account. Then clone the repo to the machine where you installed `kubectl` and the `armory` CLI. - ->This tutorial uses the `tutorial-rbac` branch. Be sure to `git checkout tutorial-rbac` before you continue. - -This tutorial is designed to use a single Kubernetes cluster with multiple namespaces to simulate multiple clusters. The `configuration` directory contains a script to connect your Kubernetes cluster to Armory CD-as-a-Service and install the namespaces this tutorial uses. - -The repo has deployment files for Prod App (`deploy-prod-app.yml`) and Intern App (`deploy-intern-app.yml`). You can find the Kubernetes manifests for each app in the `manifests` directory. - -## Connect your cluster - -If you completed the {{< linkWithTitle "deploy-sample-app.md" >}} and have **not** cleaned up your Kubernetes environment by running `/configuration/teardown-helm.sh`, you can skip the remainder of this section. - -### Create Client Credentials - -Create a new set of Client Credentials for the Remote Network Agents. Name the credentials "docs-sample-rna". - -{{< include "cdaas/client-creds.md" >}} - -### Install the Remote Network Agents - -Configure the sample environments and install the Remote Network Agents in your Kubernetes cluster. - -1. Make sure you are connected to the Kubernetes cluster you want to install the sample app on. -1. Log into your Armory CD-as-a-Service environment using the CLI: - - ```bash - armory login --envName "" - ``` - - `--envName ` with the name of your Armory CD-as-a-Service environment if you have access to multiple environments. - -1. Navigate to the `docs-cdaas-sample/configuration` directory and run the `setup-helm.sh` script using the "docs-sample-rna" Client Credentials you created for this tutorial. - - The script does the following: - - - Creates four namespaces, one for each Remote Network Agent - - Creates secrets for each RNA namespace using the Client Credentials - - Uses Helm to install the Remote Network Agents, one in each RNA namespace - - Creates four namespaces to mimic different deployment target clusters - - ```bash - bash setup-helm.sh - ``` - - After the script completes successfully, you can view the connected Remote Network Agents on the CD-as-a-Service Console's **Networking** > **Agents** screen. - -## Create RBAC roles - -You can find the RBAC config file in the `docs-cdaas-sample/rbac` directory. - -### User role - -Since the default user role is one with no permissions, you should create your roles before you invite your team to CD-as-a-Service. - -Your team consists of an engineer and an intern. You want both to start and monitor deployments, so you create a role called "Deployer". - -{{< prism lang="yaml" line-numbers="true" line="" >}} -roles: - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full -{{< /prism >}} - -### App deployment role - -Since You want to restrict who deploys Prod App, you need to create a deployment role. A deployment role requires a target deployment group, so begin by defining that target group. You can find the targets in `deploy-prod-app.yml`. - -{{< prism lang="yaml" line-numbers="true" line="" >}} -targetGroups: - - name: ProdAppDeploymentTargetGroup - tenant: main - targets: - - name: test - account: sample-rna-test-cluster - kubernetes: - namespace: sample-test - - name: staging - account: sample-rna-staging-cluster - kubernetes: - namespace: sample-staging - - name: prod-eu - account: sample-rna-prod-eu-cluster - kubernetes: - namespace: sample-prod-eu - - name: prod-us - account: sample-rna-prod-us-cluster - kubernetes: - namespace: sample-prod-us -{{< /prism >}} - -Next, add the deployment role for Prod App to the `roles` section. -{{< prism lang="yaml" line-numbers="true" line="8-13" >}} -roles: - - name: Deployer - tenant: main - grants: - - type: api - resource: deployment - permission: full - - name: ProdAppDeployment - tenant: main - grants: - - type: targetGroup - resource: ProdAppDeploymentTargetGroup - permission: full - -targetGroups: - - name: ProdAppDeploymentTargetGroup - tenant: main - targets: - - name: test - account: sample-rna-test-cluster - kubernetes: - namespace: sample-test - - name: staging - account: sample-rna-staging-cluster - kubernetes: - namespace: sample-staging - - name: prod-eu - account: sample-rna-prod-eu-cluster - kubernetes: - namespace: sample-prod-eu - - name: prod-us - account: sample-rna-prod-us-cluster - kubernetes: - namespace: sample-prod-us -{{< /prism >}} - -### Add roles using the CLI - -After you have defined your roles, you need to add them to using the Armory CLI. Log into the Armory CLI, navigate to `docs-sample-repo/rbac` and execute: - -{{< prism lang="bash" >}} -armory config apply -f ./config.yaml -{{< /prism >}} - -## Assign RBAC roles diff --git a/content/en/cd-as-a-service/tutorials/deploy-sample-app.md b/content/en/cd-as-a-service/tutorials/deploy-sample-app.md deleted file mode 100644 index a32dd600d1..0000000000 --- a/content/en/cd-as-a-service/tutorials/deploy-sample-app.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Deploy a Sample App Tutorial -linktitle: Deploy a Sample App -description: > - Learn how to deploy a sample app to your Kubernetes cluster using Armory Continuous Deployment-as-a-Service. Use Helm to install the Remote Network Agent. Deploy the sample app to multiple targets. -aliases: - - /cd-as-a-service/tutorials/deploy-demo-app/ -categories: ["Tutorials"] -tags: ["Webhooks", "GitHub"] ---- - -## Objectives - -This tutorial is designed to use a single Kubernetes cluster with multiple namespaces to simulate multiple clusters. The sample code is in a GitHub repo that you can fork to your own GitHub account. - -- [Create Client Credentials](#create-client-credentials) to use when installing Remote Network Agents. -- [Connect your cluster](#connect-your-cluster). -- [Deploy the sample app](#deploy-the-sample-app). -- [Tear down](#tear-down) the environment. - -## {{% heading "prereq" %}} - -* You have completed the Armory CD-as-a-Service [quickstart]({{< ref "cd-as-a-service/setup/quickstart" >}}), in which you create your login credentials, install the CLI, and deploy a sample app. -* You have installed [Helm](https://helm.sh/docs/intro/install/). -* You have a GitHub account so you can fork the sample project. - -## Fork and clone the repo - -[Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the [sample repo](https://github.com/armory/docs-cdaas-sample) to your own GitHub account and then clone it to the machine where you installed `kubectl` and the `armory` CLI. - -The `configuration` directory contains a script to set up Kubernetes cluster and connect it to Armory CD-as-a-Service. - -## Create Client Credentials - -Create a new set of Client Credentials for the Remote Network Agents. Name the credentials "docs-sample-rna". - -{{< include "cdaas/client-creds.md" >}} - -## Connect your cluster - -Configure the sample environments and install the Remote Network Agents in your Kubernetes cluster. - -1. Make sure you are connected to the Kubernetes cluster you want to install the sample app on. -1. Log into your Armory CD-as-a-Service environment using the CLI: - - ```bash - armory login --envName "" - ``` - - `--envName` is optional. Replace `<>` with the name of your Armory CD-as-a-Service tenant if you have access to multiple ones. - -1. Navigate to the `docs-cdaas-sample/configuration` directory and run the `setup-helm.sh` script using the "docs-sample-rna" Client Credentials you created for this tutorial. - - The script does the following: - - - Creates four namespaces, one for each Remote Network Agent - - Creates secrets for each RNA namespace using the Client Credentials - - Uses Helm to install the Remote Network Agents, one in each RNA namespace - - Creates four namespaces to mimic different deployment target clusters - - ```bash - bash setup-helm.sh - ``` - - After the script completes successfully, you can view the connected Remote Network Agents on the CD-as-a-Service Console's **Networking** > **Agents** screen. - -## Deploy the sample app - -The sample [app](https://hub.docker.com/r/demoimages/bluegreen) is a simple webserver and a corresponding `Service`. You can find the Kubernetes manifest is the `manifests` directory. The CD-as-a-Service deployment file is called `deploy.yml` and is at the root level. - -You are going to deploy the sample app to four targets: test, staging, prod-us, and prod-eu. Each target defines the following: - -* The RNA to connect to -* The namespace to deploy the app to -* The deployment strategy -* Optionally any deployment constraints - -CD-as-a-Service deploys the sample app first to the the `test` target. If that succeeds, CD-as-a-Service deploys to `staging`. CD-as-a-Service deploys to the production targets only if deployment to staging is successful and a user manually approves deployment. - -To deploy the sample, navigate to your `docs-cdaas-sample` directory and run: - -```bash -armory deploy start -f deploy.yml -``` - -Output is similar to: - -```bash -[2022-04-27T16:24:04-05:00] Deployment ID: 4be2228f-5c46-4574-ad9a-e70e601d94c4 -[2022-04-27T16:24:04-05:00] See the deployment status UI: -https://console.cloud.armory.io/deployments/pipeline/4be2228f-5c46-4574-ad9a-e70e601d94c4?environmentId=a8906e61-2388-4daa-b38e-4339390b9447 -``` - -You can check deployment status by accessing the URL included in the output. - -Deployment to `prod-us` and `prod-eu` requires manual approval, so be sure to approve in the UI. Additionally, `prod-eu` requires manual approval to move all of the traffic to the new pods, so be sure to look two manual approvals - -## Tear down - -You can run the `configuration/teardown-helm.sh` script to uninstall the Remote Network Agents and delete both the RNA and app namespaces. - -## Troubleshooting - -### Deployment times out - -Because Armory CD-as-a-Service deploys to 100% of nodes on initial deployment, you may run out of space. Increasing the number of nodes should solve the issue. - -## {{% heading "nextSteps" %}} - -* [Introduction to leveraging external automation]({{< ref "webhook-approval" >}}) and [detailed tutorial]({{< ref "external-automation" >}}). - - -
\ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/external-automation/_index.md b/content/en/cd-as-a-service/tutorials/external-automation/_index.md deleted file mode 100644 index 35fd7e177e..0000000000 --- a/content/en/cd-as-a-service/tutorials/external-automation/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: External Automation Tutorials -linktitle: External Automation -description: > - Learn how to leverage external automation such as GitHub webhook approvals. - ---- \ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/external-automation/webhook-github.md b/content/en/cd-as-a-service/tutorials/external-automation/webhook-github.md deleted file mode 100644 index 521afc7666..0000000000 --- a/content/en/cd-as-a-service/tutorials/external-automation/webhook-github.md +++ /dev/null @@ -1,249 +0,0 @@ ---- -title: Deploy a Sample App That Uses GitHub Webhook-Based Approval -linktitle: GitHub Webhook Approval -description: > - Learn how to configure GitHub webhook-based approvals in your Armory CD-as-a-Service app deployment process. -categories: ["Tutorials"] -tags: ["Webhooks", "GitHub"] ---- - -## Objectives - -This tutorial shows you how to configure webhook-based approvals using GitHub. - -You should have completed the {{< linkWithTitle "deploy-sample-app.md" >}} guide. You use the same `docs-cdaas-sample` repo that you forked and cloned as part of that tutorial. - -## {{% heading "prereq" %}} - -- You have read the webhook-based approvals [introductory page]({{< ref "webhook-approval" >}}). -- You are familiar with workflows and webhooks in GitHub. - - [Workflows](https://docs.github.com/en/actions/using-workflows/) - - [Webhooks and events](https://docs.github.com/en/developers/webhooks-and-events/webhooks/) - -## Create credentials - -You need to create credentials that enable GitHub and Armory CD-as-a-Service to connect to each other. - -1. Create a personal access token in GitHub with **workflow** and **admin:repo_hook** permissions. See the GitHub [Creating a personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) guide for instructions. Copy the token value for use in the next step. -1. Create a new secret in the CD-as-a-Service Console for the GitHub token you just created. Go to the **Secrets** > **Secrets** screen. Click the **New Secret** button. - - - **Name**: `github_personal_access_token` - - **Replacement Value**: `` - - Replace `` with your token value. You use this secret when configuring your webhook in your deployment file. - -1. [Create a new CD-as-a-Service credential]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) for your webhook callback to use for CD-as-a-Service authentication. In the CD-as-a-Service Console, go to the **Access Management** > **Client Credentials** screen. Click the **New Credential** button. On the **Create New Client Credential** screen: - - - **Name**: `github_webhooks` - - **Select Roles**: select `Deployments Full Access` - - Click **Create Credential**. Copy the **Client ID** and **Client Secret** values for use in the next step. - -1. Create two GitHub repo secrets in your fork of the `docs-cdaas-sample` repo. See GitHub's [Creating encrypted secrets for a repository](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) for instructions. Your webhook callback uses the value of these secrets to authenticate to Armory CD-as-a-Service. Create your repo secrets with the following names and values: - - 1. **Name**: CDAAS_CLIENT_ID **Value**: `` - - Replace `` with the value of the Client ID you created in the previous step. - - 1. **Name**: CDAAS_CLIENT_SECRET **Value**: `` - - Replace `` with the value of the Client Secret you created in the previous step. - -## Create the webhook event and workflow - ->Be sure to enable workflows in your fork of the `docs-cdaass-sample` repo. - -You can create a `repository_dispatch` webhook event when you want to trigger a workflow from outside of GitHub. Review the following GitHub `repository_dispatch` docs if you're unfamiliar with this type of webhook event: - -- [Webhook events and payloads](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) -- [Events that trigger workflows](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch) -- [Create a repository dispatch event](https://docs.github.com/en/rest/repos/repos#create-a-repository-dispatch-event) - -The `docs-cdaas-sample` repo contains a `basicPing.yml` webhook workflow file in the `.github/workflows` directory. The webhook workflow obtains an OAUTH token, extracts the callback URI, and sends a POST request to that callback URI. - -You must include specific keys and values as detailed in the following sample: - -{{< prism lang="yaml" line-numbers="true" line="5, 16-19, 24-28" >}} -name: basicPing Webhook Callback - -on: - repository_dispatch: - types: basicPing - -jobs: - respond: - name: Calls the callback being passed in - runs-on: ubuntu-18.04 - steps: - - name: getToken - id: getToken - uses: fjogeleit/http-request-action@master - with: - url: "https://auth.cloud.armory.io/oauth/token" - method: "POST" - customHeaders: '{ "Content-Type": "application/x-www-form-urlencoded" }' - data: 'audience=https://api.cloud.armory.io&grant_type=client_credentials&client_id=${{ secrets.CDAAS_CLIENT_ID }}&client_secret=${{ secrets.CDAAS_CLIENT_SECRET }}' - - name: callCallback - id: callCallback - uses: fjogeleit/http-request-action@master - with: - url: ${{ github.event.client_payload.callbackUri }} - method: 'POST' - bearerToken: ${{ fromJSON(steps.getToken.outputs.response).access_token }} - customHeaders: '{ "Content-Type": "application/json" }' - data: '{ "success": true, "mdMessage": "basickPing webhook success: ${{ github.event.client_payload.callbackUri }}" }' - - name: show http response - run: echo ${{ steps.callCallback.outputs.response }} -{{< /prism >}} -
-Note: - -* `on.repository_dispatch.types`: User-supplied event type name. You use this name in the payload when you call this webhook event from Armory CD-as-a-Service. -* The `getToken` step fetches an OAUTH token from Armory CD-as-a-Service. The format for this API call is defined in [Retrieve an OAUTH token to use in your callback]({{< ref "webhook-approval#retrieve-an-oauth-token-to-use-in-your-callback">}}). The callback needs this OAUTH token to authenticate with Armory CD-as-a-Service. - - - In the `data` payload, you use the `CDAAS_CLIENT_ID` and `CDAAS_CLIENT_SECRET` GitHub repo secrets you created in the [Create credentials](#create-credentials) section. - -* The `callCallback` step sends request with workflow results to Armory CD-as-a-Service. The format for this API call is defined in [Callback format]({{< ref "webhook-approval#callback-format">}}). - - - `url`: GitHub extracts the `callbackUri` from the HTTP Request that Armory CD-as-a-Service sent. - - `method`: Rest API method is always `POST` - - `bearerToken`: GitHub extracts the `access_token` value from the `getToken` step's HTTP Response and inserts it here. - - `customHeaders`: this is always `{ "Content-Type": "application/json" }` - - `data`: this JSON payload must contain a `"true"` or `"false"` value for `"success"`. The `"mdMessage"` value should be user-friendly and meaningful. - -## Configure the webhook in your deployment file - -The `docs-cdaas-sample` repo contains a second deployment file called `deploy-webhook.yml` in the root directory. The `webhooks` section is at the bottom of the file. - -The `uriTemplate` uses secrets instead of hardcoding the URI. If you don't want to create secrets, be sure to change to `uriTemplete` to use your GitHub org and repo. To create secrets using the CD-as-a-Service Console, go to **Secrets** > **Secrets** and create two new secrets: - -1. **Name**: `github_org`; **Value**: the name of the GitHub org into which you forked the `docs-cdaas-sample` repo. This is either your business org, like 'armory', or your GitHub username. -1. **Name**: `github_repo`; **Value**: the name of the GitHub repo into which you forked the `docs-cdaas-sample` repo. This is most likely `docs-cdaas-sample`. - -The following is an example of how to configure a GitHub webhook workflow: - -{{< prism lang="yaml" line-numbers="true" line="2, 5-6, 8-10, 15-20" >}} -webhooks: - - name: basicPing - method: POST - # replace this with the URI for your repo if you don't create secrets - uriTemplate: https://api.github.com/repos/{{secrets.github_org}}/{{secrets.github_repo}}/dispatches - networkMode: direct - headers: - - key: Authorization - # The secret name must match the Armory CDaaS secret name for your GitHub access token - value: token {{secrets.github_personal_access_token}} - - key: Content-Type - value: application/json - bodyTemplate: - inline: >- - { - "event_type": "basicPing", - "client_payload": { - "callbackUri": "{{armory.callbackUri}}/callback" - } - } - retryCount: 1 -{{< /prism >}} -
-Note: - -* `name`: User-supplied name, in this tutorial `basicPing`; you use this name when you insert configuration to call this webhook. -* `uriTemplate`: the format for this URI is in GitHub's [Create a repository dispatch event]. Since this is a template, you can insert secrets in place of hardcoding parts of the URI. -* `networkMode`: `direct` because the webhook endpoint is accessible via the internet -* `headers`: For the `Authorization` value, use `token #{{secrets.github_webhook_token}}`. The secret name matches the name you used in the [Create credentials](#create-credentials) section. -* `bodyTemplate.inline`: The format for this is defined in GitHub's [Create a repository dispatch event]. - - - The `event_type` must match the `on.repository_dispatch.types` value in the `basicPing.yml` file. - - The items in the `client_payload` dictionary depend on the functionality within the `basicPing.yml` file. The `basicPing` workflow looks for `callbackUri`. The `callbackUri` value is always `{{armory.callbackUri}}/callback`. Armory CD-as-a-Service dynamically generates and fills in `armory.callbackUri` at runtime. - -## Call the webhooks in your deployment process - -The `deploy-webhook.yml` calls the webhook workflows in the `constraints` section of the deployment target definition. Look for `runWebhook` entries such as the following: - -{{< prism lang="yaml" line-numbers="true" line="8-9" >}} -staging: - account: sample-rna-staging-cluster - namespace: sample-staging - strategy: rolling - constraints: - dependsOn: ["test"] - afterDeployment: - - runWebhook: - name: basicPing -{{< /prism >}} - -`runWebhook.name` must match the name you gave the webhook in the `webhooks` section. - -## Deploy your updated process - -The deployment process calls the `basicPing` webhook workflow when deploying to the `staging` target. The webhook must be successful for deployment to continue to the prod targets. - -Navigate to your `docs-cdaas-sample` directory. Make sure you have logged in using the CLI (`armory login`). - -Deploy the using the `deploy-webhook.yml` file. - -```bash -armory deploy start -f deploy-webhook.yml -``` - -Output is similar to: - -```bash -[2022-04-28T18:09:31-05:00] Deployment ID: 8c9e77fa-2543-4cdc-b12f-86c095974c7a -[2022-04-28T18:09:31-05:00] See the deployment status UI: https://console.cloud.armory.io/deployments/pipeline/8c9e77fa-2543-4cdc-b12f-86c095974c7a?environmentId=a8906e61-2388-4daa-b38e-4339390b9447 -``` - -You can check deployment status by accessing the URL included in the output. - -{{< figure width="100%" height="100%" src="/images/cdaas/tutorials/webhooks/webhook-success.jpg" alt="BeforeDeployment webhook success" caption="
The basicPing webhook succeeded so deployment continued.
">}} - -To see what webhook failure looks like, go into your GitHub repo and change the `basicPing.yml` file line 28 like this: - -{{< prism lang="yaml" line-numbers="true" line="28" >}} -name: Basic Ping Webhook Callback - -on: - repository_dispatch: - types: basicPing - -jobs: - respond: - name: Calls the callback being passed in - runs-on: ubuntu-18.04 - steps: - - name: getToken - id: getToken - uses: fjogeleit/http-request-action@master - with: - url: "https://auth.cloud.armory.io/oauth/token" - method: "POST" - customHeaders: '{ "Content-Type": "application/x-www-form-urlencoded" }' - data: 'audience=https://api.cloud.armory.io&grant_type=client_credentials&client_id=${{ secrets.CDAAS_CLIENT_ID }}&client_secret=${{ secrets.CDAAS_CLIENT_SECRET }}' - - name: callCallback - id: callCallback - uses: fjogeleit/http-request-action@master - with: - url: ${{ github.event.client_payload.callbackUri }} - method: 'POST' - bearerToken: ${{ fromJSON(steps.getToken.outputs.response).access_token }} - customHeaders: '{ "Content-Type": "application/json" }' - data: '{ "success": false, "mdMessage": "Webhook FAILURE: ${{ github.event.client_payload.callbackUri }}" }' - - name: show http response - run: echo ${{ steps.callCallback.outputs.response }} -{{< /prism >}} - -Commit the change. - -Deploy by running `armory start deploy -f deploy-webhook.yml`. Then check deployment status by accessing the URL included in the output. CD-as-a-Service cancels the deployment when it receives a failure message from the webhook. - -{{< figure width="100%" height="100%" src="/images/cdaas/tutorials/webhooks/webhook-failure.jpg" alt="BeforeDeployment webhook failure" caption="
The basicPing webhook failed.
">}} - -## {{% heading "nextSteps" %}} - -{{< linkWithTitle "cd-as-a-service/troubleshooting/webhook.md" >}} - - - - -[Create a repository dispatch event]: https://docs.github.com/en/rest/repos/repos#create-a-repository-dispatch-event \ No newline at end of file diff --git a/content/en/cd-as-a-service/tutorials/external-automation/webhook-jenkins.md b/content/en/cd-as-a-service/tutorials/external-automation/webhook-jenkins.md deleted file mode 100644 index 2472a320f2..0000000000 --- a/content/en/cd-as-a-service/tutorials/external-automation/webhook-jenkins.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Jenkins Webhook-Based Approvals Tutorial -linktitle: Jenkins - -draft: true -description: > - Tutorial ---- - -## Objectives - - - -## {{% heading "prereq" %}} - -- You have read the webhook approval [introductory page]({{< ref "webhook-approval" >}}). - - - - - -{{< prism lang="yaml" line-numbers="true" line="3" >}} -webhooks: - - name: jenkins-integration - method: POST - uriTemplate: https://myprivate.jenkins:9000/buildByToken/buildWithParameters?token=${secrets.potato-facts-jenkins-secret}&job=PotatoIntegrationTestJob&replicaSetName=${replicaSetName}&callbackUri=${callbackUri} - networkMode: remoteNetworkAgent // direct or rna - `nil` by default will fall back to the configured account - agentIdentifier: jenkins-rna //can override the test-env.account with an agent name or account name that has an rna configured - headers: - - key: Authorization - value: Basic ${potato-facts-jenkins-auth} -{{< /prism >}} - -not that the URI template has a token, webhook parms as placeholders, and the callback - - -Jenkins uses query parameters via a buildWithParameters API endpoint. You can pass additional, custom, parameters. - -``` -https://jenkins.example.com/buildByToken/buildWithParameters?token=Secure-Token&job=TestJob&replicaSetName=spring-potato -``` -The token param above is specific to the job, but servers may also require authenticated requests. Jenkins uses Basic Auth and allows you to create username:api-token for machine use, much like GitHub's personal access tokens. -https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/ - -Jenkins users may also want to use crumbs however, this requires a process where we would take user/pass and request a token to use in executing the job build request. We will not support crumbs at this time because it would require custom Jenkins logic. - -Callback - -Callback will need to be handled by a custom script or http-request job. \ No newline at end of file diff --git a/content/en/includes/cdaas/agent-argo-install.md b/content/en/includes/cdaas/agent-argo-install.md deleted file mode 100644 index 1aad46a9d7..0000000000 --- a/content/en/includes/cdaas/agent-argo-install.md +++ /dev/null @@ -1,42 +0,0 @@ -Each Kubernetes cluster that you install the RNA on should have a unique account name that you set using the `agent-k8s.accountName` parameter. This account name is used in the Status UI and in other places to identify the cluster. - -1. Verify that you are in the correct Kubernetes context. The RNA is installed in the target deployment cluster. - -2. Add the Armory Helm repo: - - ```bash - helm repo add armory https://armory.jfrog.io/artifactory/charts - ``` - - You only need to do this once. - -3. Refresh the repo cache: - - ```bash - helm repo update - ``` - -4. Install the Helm chart. You can create the `armory-rna` namespace before running the `helm install` command or include the `--create-namespace` option. -> The value for the `agent-k8s.account` option is the name that is used to refer to the deployment target cluster in the Status UI and other places, so use a descriptive name. - - The following example includes the `--create-namespace` option: - - - ```bash - helm install armory-rna armory/aurora \ - --set agent-k8s.account= \ - --set agent-k8s.clientId=${CLIENT_ID_FOR_AGENT_FROM_ABOVE} \ - --set agent-k8s.clientSecret=${CLIENT_SECRET_FOR_AGENT_FROM_ABOVE} \ - --namespace armory-rna \ - --create-namespace - ``` - - If you already have Argo Rollouts configured in your environment you may disable - that part of the Helm chart by setting the `enabled` key to false as in the following example: - - ```bash - helm install aurora \ - # ... other config options - --set argo-rollouts.enabled=false - # ... other config options - ``` \ No newline at end of file diff --git a/content/en/includes/cdaas/client-creds.md b/content/en/includes/cdaas/client-creds.md deleted file mode 100644 index 13229f23cf..0000000000 --- a/content/en/includes/cdaas/client-creds.md +++ /dev/null @@ -1,10 +0,0 @@ -1. Access the [CD-as-a-Service Console](https://console.cloud.armory.io). -1. Go to the **Configuration** tab. -1. If you have more than one tenant, make sure you select the desired tenant in the User context menu. -1. In the left navigation menu, select **Access Management > Client Credentials**. -1. In the upper right corner, select **New Credential**. -1. Create a credential for your RNA. Use a descriptive name for the credential that matches what it is being used for. For example, name the credentials the same as the account name you assigned the target deployment cluster if creating a credential for an Remote Network Agent (RNA). -1. Select an RBAC role from the **Select Roles** list. You must assign an [RBAC role]({{< ref "cd-as-a-service/concepts/iam/rbac" >}}) in order for the credential to access CD-as-a-Service. - * If the credential for is a Remote Network Agent, select **Remote Network Agent**. - * If you plan to use the credential to deploy from a GitHub Action or similar tool, select **Deployments Full Access**. -1. Note the values for both **Client ID** and **Client Secret**. You need these values when configuring the RNA or any other service that you want to grant access to. Make sure to store the secret somewhere safe. You are not shown the value again. diff --git a/content/en/includes/cdaas/create-config.md b/content/en/includes/cdaas/create-config.md deleted file mode 100644 index 22e9f49d8b..0000000000 --- a/content/en/includes/cdaas/create-config.md +++ /dev/null @@ -1,56 +0,0 @@ -1. Generate your deployment config template and output it to a file. - - For example, this command generates a deployment template for canary deployments and saves it to a file named `canary.yaml`: - - ```bash - armory template kubernetes canary > canary.yaml - ``` - -1. Customize your deployment file by setting the following minimum set of parameters: - - - `application`: The name of your app. - - `targets.`: A descriptive name for your deployment. Armory recommends using the environment name. - - `targets..account`: This is the name of your RNA. If you installed the RNA manually, it is the value that you assigned to the `agentIdentifier` parameter. - - `targets..strategy`: the name of the deployment strategy you want to use. You define the strategy in `strategies.`. - - `manifests`: a map of manifest locations. This can be a directory of `yaml (yml)` files or a specific manifest. Each entry must use the following convention: `- path: /path/to/directory-or-file` - - `strategies.`: the list of your deployment strategies. Use one of these for `targets..strategy`. - - If you are using a canary strategy, the strategy section consists of a map of steps for your canary strategy in the following format: - - ```yaml - strategies: - my-demo-strategy: # Name that you use for `targets..strategy - - canary # The type of deployment strategy to use. - steps: - - setWeight: - weight: # What percentage of the cluster to roll out the manifest to before pausing. - - pause: - duration: # How long to pause before deploying the manifest to the next threshold. - unit: # The unit of time for the duration. - - setWeight: - weight: # The next percentage threshold the manifest should get deployed to before pausing. - - pause: - untilApproved: true # Wait until a user provides a manual approval before deploying the manifest - ``` - - Each step can have the same or different pause behaviors. Additionally, you can configure as many steps as you want for the deployment strategy, but you do not need to create a step with a weight set to 100. Once CD-as-a-Service completes the last step you configure, the manifest is deployed to the whole cluster automatically. - See the [Canary fields]({{< ref "cd-as-a-service/reference/ref-deployment-file#canary-fields" >}}) section of the deployment file reference for more information. - -1. (Optional) Configure a deployment timeout. - - A deployment times out if the pods for your application fail to be in ready state in 30 minutes. You can optionally configure a deployment timeout by adding a `deploymentConfig` top-level section: - - ```yaml - deploymentConfig: - timeout: - unit: - duration: - ``` - - Note that the minimum timeout you can specify is 60 seconds (1 minute). See the [Deployment config]({{< ref "cd-as-a-service/reference/ref-deployment-file#deploymentconfig" >}}) section of the deployment file reference for more information. - -1. (Optional) Ensure there are no YAML issues with your deployment file. - - Since a hidden tab in your YAML can cause your deployment to fail, it's a good idea to validate the structure and syntax in your deployment file. There are several online linters, IDE-based linters, and command line linters such as `yamllint` that you can use to validate your deployment file. - -> You can view detailed configuration options on the {{< linkWithTitle "cd-as-a-service/reference/ref-deployment-file.md" >}} page. diff --git a/content/en/includes/cdaas/dep-file/tm-istio-config.md b/content/en/includes/cdaas/dep-file/tm-istio-config.md deleted file mode 100644 index 8632f26e1f..0000000000 --- a/content/en/includes/cdaas/dep-file/tm-istio-config.md +++ /dev/null @@ -1,30 +0,0 @@ ---- ---- - -{{< prism lang="yaml" line-numbers="true" >}} -trafficManagement: - - targets: [""] - istio: - - virtualService: - name: - httpRouteName: - destinationRule: - name: - activeSubsetName: - canarySubsetName: -{{< /prism >}} - -* `targets`: (Optional) comma-delimited list of deployment targets; if omitted, CD-as-a-Service applies the traffic management configuration to all targets. -* `istio.virtualService`: (Required) - - * `istio.virtualService.name`: The name of your VirtualService - * `istio.virtualService.httpRouteName`: The name of the HTTPRoute defined in your VirtualService. This field is optional if you define only one HTTPRoute. - -* `istio.destinationRule`: Optional if you only define only one DestinationRule. - - * `istio.destinationRule.name`: The name of your DestinationRule - * `istio.destinationRule.activeSubsetName`: The name of the subset configured in your VirtualService HTTPRoute destination. This subset is running the current version of your app. `activeSubsetName` is optional if you define only one active subset. - * `istio.destinationRule.canarySubsetName`: (Optional) The name of the canary subset defined in your DestinationRule. - - - \ No newline at end of file diff --git a/content/en/includes/cdaas/dep-file/tm-smi-config.md b/content/en/includes/cdaas/dep-file/tm-smi-config.md deleted file mode 100644 index 0395513e5e..0000000000 --- a/content/en/includes/cdaas/dep-file/tm-smi-config.md +++ /dev/null @@ -1,32 +0,0 @@ ---- ---- - -{{< prism lang="yaml" line-numbers="true" >}} -trafficManagement: - - targets: [""] - smi: - - rootServiceName: "" - canaryServiceName: "-canary" - trafficSplitName: "" - kubernetes: - - activeService: "" - previewService: "" -{{< /prism >}} - -* `targets`: (Optional) comma-delimited list of deployment targets; if omitted, CD-as-a-Service applies the traffic management configuration to all targets. - -* `smi.rootServiceName`: (Required if configuring an `smi` block) the name of a Kubernetes `Service`. Its service selector should target a Kubernetes `Deployment` resource in your deployment's manifests. The SMI `TrafficSplit` spec defines a root service as the fully qualified domain name (FQDN) used by clients to communicate with your application. The `Service` should exist at the time of deployment. - -* `smi.canaryServiceName`: (Optional)(Canary) the name of a Kubernetes `Service`. Its service selector should target a Kubernetes `Deployment` resource in your deployment's manifests. - - - If you provide a `canaryServiceName`, CD-as-a-Service assumes the `Service` already exists and uses it for deployment. - - If you don't provide a `canaryServiceName`, CD-as-a-Service creates a `Service` object and gives it the name of the root service with "-canary" appended to it. For example, if your root service is "myRootService", then the canary service name would be "myRootService-canary". - -* `smi.trafficSplitName`: (Optional) CD-as-a-Service uses the provided name when creating an SMI `TrafficSplit`. - -* `kubernetes.activeService`: (Required if configuring a `kubernetes` block)(Blue/Green) the name of a Kubernetes `Service`. Its service selector should target a Kubernetes `Deployment` resource in your deployment's manifests. The `Service` should exist at the time of deployment. - -* `kubernetes.previewService`: (Optional)(Blue/Green) the name of a Kubernetes `Service`. Its service selector should target a Kubernetes `Deployment` resource in your deployment's manifests. The `Service` should exist at the time of deployment. - - - \ No newline at end of file diff --git a/content/en/includes/cdaas/dep-file/webhooks-config.md b/content/en/includes/cdaas/dep-file/webhooks-config.md deleted file mode 100644 index 129050ad7a..0000000000 --- a/content/en/includes/cdaas/dep-file/webhooks-config.md +++ /dev/null @@ -1,85 +0,0 @@ ---- ---- - -{{< prism lang="yaml" line-numbers="true" >}} -webhooks: - - name: - method: - uriTemplate: - networkMode: - agentIdentifier: - headers: - - key: Authorization - value: - bodyTemplate: - inline: >- - { - } - retryCount: -{{< /prism >}} - -* `name`: the unique name of your webhook - -* `method`: (Required) REST API method type of the webhook - -* `uriTemplate`: (Required) webhook URL; supports placeholders that are replaced at runtime - -* `networkMode`: (Required) `direct` or `remoteNetworkAgent`; `direct` means a direct connection to the internet; if your webhook is not internet-accessible, use the `remoteNetworkAgent` as a proxy. - -* `agentIdentifier`: (Optional) Use when `networkMode` is `remoteNetworkAgent`; the Remote Network Agent identifier to use as a proxy; the identifier must match the **Agent Identifier** value listed on the **Agents** UI screen; if not specified, Armory CD-as-a-Service uses the Remote Network Agent associated with the environment account. - -* `headers`: (Optional) Request headers; the `Authorization` header is required if your webhook requires authorization. Also supports use of `context` and `armory` provided variables. - -* `bodyTemplate`: (Optional) the body of the REST API request; the inline content depends on the endpoint you are calling. - -* `retryCount`: (Optional; Default: 0) if the first connection attempt fails, the number of retries before failing and declaring that the webhook cannot be reached. - -* `disableCallback`: (Optional; Default: false) if set to `true`, Armory CD-as-a-Service does not wait for a callback before moving on to the next deployment step. - -**Callback URI** - -You must pass the callback URI as `{{armory.callbackUri}}/callback`. Armory CD-as-a-Service generates the value for `armory.callbackUri` and fills it in at runtime. - - - - - -#### Webhook context variables - -You can use variables in the webhook templates you define in the `webhooks` block of your deployment for the follow fields: `webhooks.[].uriTemplate`, `webhooks.[].headers`, and `webhooks.[].bodyTemplate`. - -**Armory-provided context variables** - -Armory provides the following variables for every webhook execution: - -| Variable | Annotation | Environment variable | Notes | -|--------------------------|-------------------------------------|---------------------------|-----------------------------------------------------------------------------| -| applicationName | `deploy.armory.io/application` | `ARMORY_APPLICATION_NAME` | Added as annotation resources and as environment variables on pods* | -| deploymentId | `deploy.armory.io/deployment-id` | `ARMORY_DEPLOYMENT_ID` | Added as annotation resources and as environment variables on pods* | -| environmentName | `deploy.armory.io/environment` | `ARMORY_ENVIRONMENT_NAME` | Added as annotation resources and as environment variables on pods* | -| replicaSetName | `deploy.armory.io/replica-set-name` | `ARMORY_REPLICA_SET_NAME` | Added as annotation resources and as environment variables on pods* | -| accountName | - | - | The name of the account (or agentIdentifier) used to execute the deployment | -| namespace | - | - | The namespace resources are being deployed to | - -Prefix the variable with `armory` and surround with `{{}}`. For example, to use `applicationName`, add `{{armory.applicationName}}` to the webhook query template. - -**Custom context variables** - -Add your custom variables to the `strategies..canary.steps.runWebhook.context` section of your deployment file: - -``` -strategies: - ... - canary: - steps: - ... - - runWebhook: - name: - ... - context: - : -``` - -You need to configure your custom variables for each webhook step that references them. - -In supported webhook fields, you reference them with the following format: `{{context.}}`. For example, if you create a variable called `uri` for `webhooks.[].uriTemplate`, you reference it in `webhooks.[].bodyTemplate` with `{{context.uri}}`, so that `uriTemplate: {{context.uri}}` is the address the webhook calls. \ No newline at end of file diff --git a/content/en/includes/cdaas/deploy/istio-example.md b/content/en/includes/cdaas/deploy/istio-example.md deleted file mode 100644 index 46d860764d..0000000000 --- a/content/en/includes/cdaas/deploy/istio-example.md +++ /dev/null @@ -1,103 +0,0 @@ ---- ---- - - -
- - - - - - - - - - - - - -
CD-as-a-Service Deployment (deploy.yaml)Istio Resources (istio-resources.yaml)
- {{< prism lang="yaml" line=" " line-numbers="true">}} -version: v1 -kind: kubernetes -application: reviews -targets: - dev: - account: dev - namespace: istiodemo - strategy: strategy1 -manifests: - - path: manifests/reviews.yaml - - path: manifests/istio-resources.yaml -strategies: - strategy1: - canary: - steps: - - setWeight: - weight: 10 - - pause: - untilApproved: true - - setWeight: - weight: 90 - - pause: - untilApproved: true -trafficManagement: - - targets: ["dev"] - istio: - - virtualService: - name: reviews - httpRouteName: http-route-reviews - destinationRule: - name: reviews - activeSubsetName: stable - canarySubsetName: canary # does not exist yet -{{< /prism >}} - - {{< prism lang="yaml" line-numbers="true" >}} -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: reviews -spec: - hosts: - - reviews - http: - - route: - - destination: - host: reviews.istiodemo.svc.cluster.local - subset: stable - name: http-route-reviews ---- -apiVersion: networking.istio.io/v1alpha3 -kind: DestinationRule -metadata: - name: reviews -spec: - host: reviews.istiodemo.svc.cluster.local - subsets: - - name: stable - labels: - app: reviews -{{< /prism >}} -

- -**Mapping** -
- -| Deployment Field (deploy.yaml) | Deploy Line | Istio Resources Field (istio-resources.yaml) | Istio Line | -|----------------------------------|-------------|----------------------------------------------|------------| -| virtualService.name | 28 | VirtualService.metadata.name | 4 | -| virtualService.httpRouteName | 29 | VirtualService.http.route.name | 13 | -| destinationRule.name | 31 | DestinationRule.metadata.name | 18 | -| destinationRule.activeSubsetName | 32 | VirtualService.http.route.destination.subset | 12 | - - - - - diff --git a/content/en/includes/cdaas/deploy/preview-link-details.md b/content/en/includes/cdaas/deploy/preview-link-details.md deleted file mode 100644 index 5b5aaff327..0000000000 --- a/content/en/includes/cdaas/deploy/preview-link-details.md +++ /dev/null @@ -1,43 +0,0 @@ -The section enables exposing deployed `service` resources via a temporary, internet-facing, randomly generated link for testing purposes. - -{{< prism lang="yaml" line-numbers="true" >}} -... -- exposeServices: - services: - - - - - - - ttl: - duration: - unit: -{{< /prism >}} - -* `services`: List of one-to-many services to expose - * Each service name must match an existing service deployed in the target cluster. - * Each service must be in the same namespace as the app you are deploying. - * Each service must define a single HTTP port. -* `ttl`: (Optional) The lifetime of the exposed service preview - * Minimum: 1 minute (60 seconds) - * Maximum: 24 hours - * Default: 5 minutes - -Each link automatically expires after the configured amount of time. The exposed link is not secure. - -You can configure multiple `exposeServices` entries, each having a different expiration time. - -You can use exposed service links elsewhere in your deploy config, such as in your webhook definitions. The naming convention is `armory.preview.`. - -**Example** - -In this example, the snippet instructs Armory CD-as-a-Service to create a public URL to the deployed services service-name-1 and service-name-2. Both automatically expire after 2 hours. - -{{< prism lang="yaml" line-numbers="true" >}} -... -- exposeServices: - services: - - service-name-1 - - service-name-2 - ttl: - duration: 2 - unit: hours -{{< /prism >}} diff --git a/content/en/includes/cdaas/desc-plugin.md b/content/en/includes/cdaas/desc-plugin.md deleted file mode 100644 index df46ce9ed4..0000000000 --- a/content/en/includes/cdaas/desc-plugin.md +++ /dev/null @@ -1 +0,0 @@ -The Armory Continuous Deployment-as-a-Service Plugin for Spinnaker™ adds new stages to your Armory CD or Spinnaker instance. When you use one of these stages to deploy an app, you can configure how to deploy the stage incrementally by setting percentage thresholds for the deployment. For example, you can deploy the new version of your app to 25% of your target cluster and then wait for a manual judgement or a configurable amount of time. This wait gives you time to assess the impact of your changes. From there, either continue the deployment to the next threshold you set or roll back the deployment. \ No newline at end of file diff --git a/content/en/includes/cdaas/ea-banner.md b/content/en/includes/cdaas/ea-banner.md deleted file mode 100644 index 13ae7c73e6..0000000000 --- a/content/en/includes/cdaas/ea-banner.md +++ /dev/null @@ -1,2 +0,0 @@ - -As part of participating in an early access program you will receive information from Armory that is not yet publicly available and is subject to your NDA or confidentiality obligations with Armory. \ No newline at end of file diff --git a/content/en/includes/cdaas/install-cli.md b/content/en/includes/cdaas/install-cli.md deleted file mode 100644 index d2918a748d..0000000000 --- a/content/en/includes/cdaas/install-cli.md +++ /dev/null @@ -1,14 +0,0 @@ -Install `armory` on Mac OS using [Homebrew](https://brew.sh/): - -```shell -brew tap armory-io/armory -brew install armory-cli -``` - -To install `armory` on Linux, run the following command: - -```shell -curl -sL go.armory.io/get-cli | bash -``` - -The script installs `armory` and `avm`. You can use `avm` (**A**rmory **V**ersion **M**anager) to manage your `armory` version. \ No newline at end of file diff --git a/content/en/includes/cdaas/ki-manifest-limitation.md b/content/en/includes/cdaas/ki-manifest-limitation.md deleted file mode 100644 index e7c6811096..0000000000 --- a/content/en/includes/cdaas/ki-manifest-limitation.md +++ /dev/null @@ -1,4 +0,0 @@ -Armory CD-as-a-Service has the following constraints when deploying a manifest: - -- Deploying ReplicaSets is not supported. -- Deploying Pods is not supported. \ No newline at end of file diff --git a/content/en/includes/cdaas/login-creds.md b/content/en/includes/cdaas/login-creds.md deleted file mode 100644 index 5887686be3..0000000000 --- a/content/en/includes/cdaas/login-creds.md +++ /dev/null @@ -1,7 +0,0 @@ -You use the login credentials when you run the CLI locally and need to authenticate yourself to Armory's hosted services, such as when you run the `login` command with the CLI. - -This is also your login for Armory's hosted cloud services UI (where you can perform tasks such as managing credentials) and the Status UI (where you can monitor the progress of your deployments). - -1. Register for Armory's hosted cloud services with the link that Armory provides. -2. Click **Sign Up** and complete the form. -3. Complete the two-factor authentication configuration. Note that you need a device that can support OTP two-factor authentication, such as a smartphone with the Google Authenticator app. \ No newline at end of file diff --git a/content/en/includes/cdaas/mermaid/how-it-works.md b/content/en/includes/cdaas/mermaid/how-it-works.md deleted file mode 100644 index cc87cf8c2a..0000000000 --- a/content/en/includes/cdaas/mermaid/how-it-works.md +++ /dev/null @@ -1,24 +0,0 @@ -```mermaid -flowchart LR - id0<--"REST API"-->id2 - id1<--"REST API"-->id2 - id2<--"gRPC/HTTP2"-->id3 - - subgraph outside [External Environments] - id0[Armory CD-as-a-Service CLI] - id1[Automation Tools
GitHub, Jenkins, GitLab, Spinnaker] - end - - id2{Armory
CD-as-a-Service} - - subgraph kubernetes [Kubernetes Cluster] - id3[Remote Network Agent] - end - - classDef k8s fill:#326de6,stroke:#000000,stroke-width:1px - classDef armory fill:#38b5d9,stroke:#000000,stroke-width:1px - classDef ext fill:#ffffff,stroke:#000000,stroke-width:1px - class kubernetes k8s - class id2,id3,id0 armory - class outside ext -``` \ No newline at end of file diff --git a/content/en/includes/cdaas/rbac/snippet-deploy.md b/content/en/includes/cdaas/rbac/snippet-deploy.md deleted file mode 100644 index 1c0c5b8b01..0000000000 --- a/content/en/includes/cdaas/rbac/snippet-deploy.md +++ /dev/null @@ -1,45 +0,0 @@ -Example deployment.yaml - -{{< prism lang="yaml" line-numbers="true" >}} -version: v1 -kind: kubernetes -application: potato-facts -# Map of Deployment Targets, this is set up in a way where -# we can do multi-target deployments (multi-region or multi-cluster) -targets: - # This in the name of a deployment. Underneath it is its configuration. - staging: - # the name of an agent configured account - account: acme-eks-staging-cluster - # Optionally override the namespaces that are in the manifests - namespace: potato-facts - # This is the key to a strategy under the strategies map - strategy: rolling - constraints: - dependsOn: ["dev"] - beforeDeployment: [] - prod-east: - # the name of an agent configured account - account: acme-eks-prod-east-cluster - # Optionally override the namespaces that are in the manifests - namespace: potato-facts - # This is the key to a strategy under the strategies map - strategy: mycanary - constraints: - dependsOn: ["staging"] - beforeDeployment: - - pause: - untilApproved: true - prod-west: - # the name of an agent configured account - account: acme-eks-prod-west-cluster - # Optionally override the namespaces that are in the manifests - namespace: potato-facts - # This is the key to a strategy under the strategies map - strategy: myBlueGreen - constraints: - dependsOn: ["staging"] - beforeDeployment: - - pause: - untilApproved: true -{{< /prism >}} \ No newline at end of file diff --git a/content/en/includes/cdaas/rbac/snippet-rbac.md b/content/en/includes/cdaas/rbac/snippet-rbac.md deleted file mode 100644 index 1b4d360ad4..0000000000 --- a/content/en/includes/cdaas/rbac/snippet-rbac.md +++ /dev/null @@ -1,53 +0,0 @@ -Example rbac.yaml - -{{< prism lang="yaml" line-numbers="true" >}} -targetGroups: - - name: potato-facts - # optional field, defaults to main - tenant: main - targets: - - name: staging - account: acme-eks-staging-cluster - kubernetes: - namespace: potato-facts - - name: prod-east - account: acme-eks-prod-east-cluster - kubernetes: - namespace: potato-facts - - name: prod-west - account: acme-eks-prod-west-cluster - kubernetes: - namespace: potato-facts - -roles: - - name: Potato Facts Role - # optional field, defaults to main - tenant: main - grants: - - type: account - resource: acme-eks-dev-cluster - permission: full - - type: targetGroup - resource: potato-facts - permission: full - - type: api - resource: deployment - permission: full - - name: Tenant Admin - # optional field, defaults to main - tenant: main - grants: - - type: api - resource: tenant - permission: full - - name: Organization Admin - grants: - - type: api - resource: organization - permission: full - - name: Remote Network Agent - grants: - - type: api - resource: agent-hub - permission: connect -{{< /prism >}} \ No newline at end of file diff --git a/content/en/includes/cdaas/register.md b/content/en/includes/cdaas/register.md deleted file mode 100644 index bd9e5ffbae..0000000000 --- a/content/en/includes/cdaas/register.md +++ /dev/null @@ -1,13 +0,0 @@ -Access the [registration screen](https://go.armory.io/signup/) to create an account. Fill in the required fields. When you're done, click **Create Account**. - -When you create your account, CD-as-a-Service does the following: - -* Creates an Organization for your company -* Creates a Tenant for the Organization -* Creates a User account with an _Organization Admin_ role for you. - -See {{< linkWithTitle "/cd-as-a-service/concepts/architecture/orgs-tenants.md" >}} for details. - -> You may have to log in after creating your account. - -The **Welcome to Continuous Deployment-as-a-Service** [Configuration page](https://console.cloud.armory.io/configuration) lists the steps you need to complete to begin using Armory CD-as-a-Service. \ No newline at end of file diff --git a/content/en/includes/cdaas/req-networking.md b/content/en/includes/cdaas/req-networking.md deleted file mode 100644 index f62054df3f..0000000000 --- a/content/en/includes/cdaas/req-networking.md +++ /dev/null @@ -1,13 +0,0 @@ -The following network endpoints are used for communication into Armory CD-as-a-Service: - -| DNS | Port | Protocol | Description | -| ------------------------- | ---- | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| agent-hub.cloud.armory.io | 443 | TLS enabled gRPC over HTTP/2
TLS version 1.2 | Remote Network Agent Hub connection; Agent Hub routes deployment commands to RNAs and caches data received from them. Agent Hub does not require direct network access to the RNAs since they connect to Agent Hub through an encrypted, long-lived gRPC HTTP2 connection. Agent Hub uses this connection to send deployment commands to the RNA for execution. | -| api.cloud.armory.io | 443 | HTTP over TLS (HTTPS)
TLS version 1.2 | Armory REST API; Clients connect to these APIs to interact with Armory CD-as-a-Service. | -| auth.cloud.armory.io | 443 | HTTP over TLS (HTTPS)
TLS version 1.2 | OIDC Service; The Open ID Connect (OIDC) service is used to authorize and authenticate machines and users. The RNAs, Armory Continuous Deployment (Spinnaker) plugin, and other services all authenticate against this endpoint. The service provides an identity token that can be passed to the Armory API and Agent Hub. | - -All network traffic is encrypted while in transit. - -Encryption in transit is over HTTPS using TLS encryption. When using Armory-provided software for both the client and server, these connections are secured by TLS 1.2. Certain APIs support older TLS versions for clients that do not support 1.2. - -Encryption at rest uses AES256 encryption. \ No newline at end of file diff --git a/content/en/includes/cdaas/rna-install-helm.md b/content/en/includes/cdaas/rna-install-helm.md deleted file mode 100644 index 06455a33b7..0000000000 --- a/content/en/includes/cdaas/rna-install-helm.md +++ /dev/null @@ -1,45 +0,0 @@ -Installation requires Helm v3+. - -For advanced use cases such as restricting permissions, proxy configurations, custom annotations, labels, or environment variables, download and modify the [`values.yaml` for the RNA](https://github.com/armory-io/remote-network-agent-helm-chart/blob/main/values.yaml) or override existing values on the command line using `--set`. For information about using a `values file`, see the [Helm Values Files guide](https://helm.sh/docs/chart_template_guide/values_files/) and the [Customizing the Chart Before Installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing) section of the _Using Helm_ guide. - -1. Set your `kubectl` [context](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) to connect to the cluster where you want to deploy the RNA: - - ```bash - kubectl config use-context - ``` - -1. Create the namespace for the RNA: - - ```bash - kubectl create ns armory-rna - ``` - -1. Create secrets from your Client ID and Client Secret: - - ```bash - kubectl --namespace armory-rna create secret generic rna-client-credentials --type=string --from-literal=client-secret= --from-literal=client-id= - ``` - - The examples use Kubernetes secrets to encrypt the value. You supply the encrypted values in the Helm command to install the RNA. - -1. You can install the RNA with default permissions and values or you can customize using a `values.yaml` file. - - For most scenarios, you install one RNA per cluster. Use the `agentIdentifier` parameter to give each RNA a unique name. When you deploy your app, you specify which RNA to use, so Armory recommends creating a meaningful name that identifies the cluster. - - **Default values** - - The encrypted values for `clientId` and `clientSecret` reference the Kubernetes secrets you generated in an earlier step. - - ```bash - helm upgrade --install armory-rna armory/remote-network-agent \ - --set agentIdentifier= \ - --set 'clientId=encrypted:k8s!n:rna-client-credentials!k:client-id' \ - --set 'clientSecret=encrypted:k8s!n:rna-client-credentials!k:client-secret' \ - --namespace armory-rna - ``` - - **Customized values** - - You can specify the path to your customized values file using `-f values.yaml` or you can override values using the command line `--set `. Refer to the [Customizing the Chart Before Installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing) section in the Helm docs. - -1. You can go to the [Agents page](https://console.cloud.armory.io/configuration/agents) in the CD-as-a-Service Console to verify that your RNA has been installed and is communicating with CD-as-a-Service. If you do not see the RNA, check your cluster logs to see if the RNA is running. diff --git a/content/en/includes/cdaas/rna-install-kubectl.md b/content/en/includes/cdaas/rna-install-kubectl.md deleted file mode 100644 index 7bd49506f7..0000000000 --- a/content/en/includes/cdaas/rna-install-kubectl.md +++ /dev/null @@ -1,20 +0,0 @@ -You need [Client Credentials]{{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) (**Client Secret** and **Client ID**) so your RNA can communicate with CD-as-a-Service. - -1. Set your `kubectl` [context](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) to connect to the cluster where you want to deploy the RNA. - - ```bash - kubectl config use-context - ``` - -1. Install the RNA. - - Replace `` and `` with your Client Credentials. - - ```bash - kubectl create ns armory-rna; - kubectl --namespace armory-rna create secret generic rna-client-credentials \ - --type=string \ - --from-literal=client-secret="" \ - --from-literal=client-id=""; - kubectl apply -f "https://api.cloud.armory.io/kubernetes/agent/manifest?agentIdentifier=sample-cluster&namespace=armory-rna" - ``` diff --git a/content/en/includes/cdaas/rna-ui-add-agent.md b/content/en/includes/cdaas/rna-ui-add-agent.md deleted file mode 100644 index ed9532a0ef..0000000000 --- a/content/en/includes/cdaas/rna-ui-add-agent.md +++ /dev/null @@ -1,6 +0,0 @@ -1. Access the [Agents page](https://console.cloud.armory.io/configuration/agents). -1. Click **Add an Agent**. -1. In the **Name New Remote Network Agent** window, enter a name for your Remote Network Agent (RNA) in **Agent Identifier**. You install this RNA in the cluster where you want to deploy your app, so create a meaningful name. -1. Choose **I want to use my own cluster** in the **Choose Cluster Type** window. -1. Copy the **Option 1** content in the **Install a Remote Network Agent** window. -1. In your local terminal, ensure you are connected to your cluster and then execute the commands. \ No newline at end of file diff --git a/content/en/plugins/cdaas-spinnaker.md b/content/en/plugins/cdaas-spinnaker.md index 9a5b2ae707..41a14d9108 100644 --- a/content/en/plugins/cdaas-spinnaker.md +++ b/content/en/plugins/cdaas-spinnaker.md @@ -1,557 +1,8 @@ --- title: CD-as-a-Service Plugin for Spinnaker and Armory Continuous Deployment -linkTitle: Armory CD-as-a-Service +linkTitle: Armory CD-as-a-Service Plugin +manualLink: "https://developer.armory.io/integrations/plugin-spinnaker/" description: > The Armory Continuous Deployment-as-a-Service plugin enables performing canary and blue/green deployments in a single stage from Spinnaker to your Kubernetes deployment target using CD-as-a-Service. --- - -## Overview of the CD-as-a-Service Spinnaker plugin - -{{< include "cdaas/desc-plugin.md" >}} - -See the [CD-as-a-Service Architecture page]({{< ref "cd-as-a-service/concepts/architecture" >}}) for an overview of this plugin and how it fits in with Armory CD. - -## Objectives - -* Meet the prerequisites specified in the _{{% heading "prereq" %}}_ section. -* [Register your Spinnaker or Armory CD environment](#register-your-environment). -* [Install the CD-as-a-Service Remote Network Agent](#install-the-cd-as-a-service-remote-network-agent). -* [Install the plugin](#install-the-plugin). -* [Use the plugin](#use-the-plugin) to deploy a "Hello World" manifest. - -## Plugin compatibility matrix - -| Armory CD (Spinnaker) Version | Plugin Version | -|:-------|:-------------------| -| 2.24.x (1.24.x) | 0.29.x | - - - -## {{% heading "prereq" %}} - -[Register](https://go.armory.io/signup/) to use Armory CD-as-a-Service. - -### Networking - -Your Spinnaker instance and the cluster(s) where you install the CD-as-a-Service Remote Network Agent(s) need specific ports open. - -{{< include "cdaas/req-networking.md" >}} - -Additionally, your Armory CD instance needs access to GitHub to download the plugin during installation. - -### Target Kubernetes cluster - -The Spinnaker plugin does not use Clouddriver to source its accounts. Instead, it uses Remote Network Agents (RNAs) that are deployed in your target Kubernetes clusters. An RNA is a lightweight, scalable service that enables the Spinnaker plugin to interact with your infrastructure. You must install RNAs in every target cluster. - -The Helm chart described in [Enable the Armory CD-as-a-Service Remote Network Agent in target Kubernetes clusters](#enable-the-armory-cd-as-a-service-remote-network-agent-in-target-kubernetes-clusters) manages the installation of both of these requirements for you. - -## Register your environment - -{{< tabs name="RegisterEnv" >}} -{{% tabbody name="Armory CD" %}} - -Register your Armory CD environment so that it can communicate with Armory services. Each environment needs to get registered if you, for example, have production and development environments. - -Register your Armory CD [environment]({{< ref "ae-instance-reg" >}}). - -{{% /tabbody %}} -{{% tabbody name="Spinnaker" %}} - -[Create a new CD-as-a-Service credential]({{< ref "cd-as-a-service/tasks/iam/client-creds" >}}) for your Spinnaker instance so it can authenticate with CD-as-a-Service. - -In the CD-as-a-Service Console, go to the **Access Management** > **Client Credentials** screen. Click the **New Credential** button. On the **Create New Client Credential** screen: - - - **Name**: enter a meaningful name for your Spinnaker instance - - **Select Roles**: select `Deployments Full Access` - -Click **Create Credential**. Copy the **Client ID** and **Client Secret** values for use in the _[Install the plugin](#install-the-plugin)_ section. - -{{% /tabbody %}} -{{< /tabs >}} - -## Install the CD-as-a-Service Remote Network Agent - -### Create a credential for your RNA - -{{< include "cdaas/client-creds.md" >}} - -### Deploy the RNA in your target Kubernetes cluster - -{{< include "cdaas/rna-install-helm.md" >}} - -### Verify the Agent deployment - -Go to the [Agents page in the Configuration UI](https://console.cloud.armory.io/configuration/agents) and verify the connection. If you do not see your cluster, verify that you are in the correct CD-as-a-Service tenant. - -> Note that you may see a "No Data message" when first loading the Agent page. - -{{< figure src="/images/cdaas/ui-rna-status.jpg" alt="The Connected Remote Network Agents page shows connected Agents and the following information: Agent Identifier, Agent Version, Connection Time when the connection was established, Last Heartbeat time, Client ID, and IP Address." >}} - -If you do not see the RNA for your target deployment cluster, check the logs for the target deployment cluster to see if the RNA is up and running. - -You should see messages similar to the following that show your client ID and your account getting registered in Armory CD-as-a-Service: - -``` -time="2021-07-16T17:41:45Z" level=info msg="registering with uuid: f69daec0-0a32-4ded-b3ed-dc84bc0e93d0" -time="2021-07-16T17:41:45Z" level=info msg="registering with 1 servers" -time="2021-07-16T17:48:30Z" level=info msg="handling registration 01FAR6Y7EDJW1B5G8JQ109D53G" -time="2021-07-16T17:48:30Z" level=info msg="starting agentCreator provider:\"kubernetes\" name:\"account-test\"" -``` - -## Install the plugin - -> You can configure secrets as outlined in the [Secrets Guide]({{< ref "continuous-deployment/armory-admin/secrets" >}}). This means you can set the clientSecret value to be a secret token instead of the plain text value. - -{{< tabs name="DeploymentPlugin" >}} -{{% tabbody name="Operator" %}} - -If you are running Armory CD 2.26.3, `armory.cloud` block goes in a different location. Instead of `spec.spinnakerConfig.spinnaker`, the block needs to go under both `spec.spinnakerConfig.gate` and `spec.spinnakerConfig.orca`. For more information see [Known issues](#known-issues). Additionally there is a `plugins` block that needs to be added. - -The installation instructions using the Operator are the same except for where the `armory.cloud` and this `plugins` block go. - -In your Kustomize patches directory, create a file named **patch-plugin-deployment.yml** and add the following manifest to it. - -```yaml -#patch-plugin-deployment.yml -apiVersion: spinnaker.armory.io/v1alpha2 -kind: SpinnakerService -metadata: - name: spinnaker - namespace: -spec: - spinnakerConfig: - profiles: - gate: - spinnaker: - extensibility: - # This snippet is necessary so that Gate can serve your plugin code to Deck - deck-proxy: - enabled: true - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - enabled: true - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json - # Global Settings - spinnaker: - armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io - spinnaker: - extensibility: - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -``` - -Then, include the file under the `patchesStrategicMerge` section of your `kustomization` file: - -```yaml -bases: - - spinnaker.yml -patchesStrategicMerge: - - patches/patch-plugin-deployment.yml -``` - -Apply the changes to your Armory CD instance. - -```bash -kubectl apply -k .yml -``` - -{{% /tabbody %}} -{{% tabbody name="Halyard" %}} - -If you are running Armory CD 2.26.3, `armory.cloud` block needs to go in `gate-local.yml` and `orca-local.yml` instead of `spinnaker-local.yml`. For more information see [Known issues](#known-issues). Other than the change in location, the installation instructions remain the same. - -In the `/.hal/default/profiles` directory, add the following configuration to `spinnaker-local.yml`. If the file does not exist, create it and add the configuration. - -```yaml -#spinnaker-local.yml -armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io -spinnaker: - extensibility: - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -``` - -In the `/.hal/default/profiles` directory, add the following configuration to `gate-local.yml`. If the file does not exist, create it and add the configuration. - -```yaml -#gate-local.yml -spinnaker: - extensibility: - # This snippet is necessary so that Gate can serve your plugin code to Deck - deck-proxy: - enabled: true - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - enabled: true - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -``` - -Apply the changes to your Armory CD instance. - -```bash -hal deploy apply -``` - -{{% /tabbody %}} -{{< /tabs >}} - -### Verify that the plugin is configured - -1. Check that all the services are up and running: - - ```bash - kubectl -n get pods - ``` - -2. Navigate to the Armory CD UI. -3. In a new or existing application, create a new pipeline. -4. In this pipeline, select **Add stage** and search for **Kubernetes Progressive**. The stage should appear if the plugin is properly configured. - - {{< figure src="/images/deploy-engine/deploy-engine-stage-UI.jpg" alt="The Kubernetes Progressive stage appears in the Type dropdown when you search for it." >}} - -5. In the **Basic Settings** section, verify that you can see the target deployment account in the **Account** dropdown. - - {{< figure src="/images/deploy-engine/deploy-engine-accounts.png" alt="If the plugin is configured properly, you should see the target deployment account in the Account dropdown." >}}. - -## Use the plugin - -The plugin provides the following pipeline stages that you can use to deploy your app: - -* [Borealis Progressive Deployment YAML](#armory-cd-as-a-service-progressive-deployment-yaml-stage): You create the Armory CD-as-a-Service deployment YAML configuration, so you have access to the full set of options for deploying your app to a single environment. -* [Kubernetes Progressive](#kubernetes-progressive-stage): This is a basic deployment stage with a limited set of options. Blue/green deployment is not supported in Early Access. - -### Armory CD-as-a-Service Progressive Deployment YAML stage - -{{< alert title="Limitations" color="primary" >}} -* This stage only supports deploying to a single environment. -{{< /alert >}} - -This stage uses YAML deployment configuration to deploy your app. The YAML that you create must be in the same format as the [Deployment File]({{< ref "ref-deployment-file" >}}) that you would use with the Armory CD-as-a-Service CLI. - -You have the following options for adding your Armory CD-as-a-Service deployment YAML configuration: - -1. **Text**: You create and store your deployment YAML within Armory CD. -1. **Artifact**: You store your deployment YAML file in source control. - -#### {{% heading "prereq" %}} - -1. Add the Kubernetes manifest for your app as a pipeline artifact in the Configuration section of your pipeline. Or you can generate it using the 'Bake (Manifest)' stage, as you would for a standard Kubernetes deployment in Armory CD. - -1. Prepare your Armory CD-as-a-Service deployment YAML. You can use the [Armory CD-as-a-Service CLI]({{< ref "cd-as-a-service/setup/deploy-your-app" >}}) to generate a deployment file template. In your deployment YAML `manifests.path` section, you have to specify the file name of the app's Kubernetes manifest artifact, which may vary from the **Display Name** on the **Expected Artifact** screen. - -#### Configure the stage - -The **Deployment Configuration** section is where you define your Armory CD-as-a-Service progressive deployment and consists of the following parts: - -**Manifest Source** - -{{< tabs name="DeploymentYAMLManifestSource" >}} -{{% tabbody name="Text" %}} - -1. Choose **Text** for the **Manifest Source**. -1. Paste your deployment file YAML into the **Deployment YAML** text box. For example: - -{{< figure src="/images/cdaas/plugin/prog-deploy-yaml.png" alt="Example of a deployment YAML file pasted into the Deployment YAML text box." >}} - -{{% /tabbody %}} -{{% tabbody name="Artifact" %}} - -Before you select **Artifact**, make sure you have added your Armory CD-as-a-Service deployment file as a pipeline artifact. - -1. Select **Artifact** as the **Manifest Source**. -1. Select your Armory CD-as-a-Service deployment file from the **Manifest Artifact** drop down list. - -{{< figure src="/images/cdaas/plugin/prog-deploy-artifact.png" alt="Example of a deployment YAML file attached as an artifact." >}} - -{{% /tabbody %}} -{{< /tabs >}} -
-
-**Required Artifacts to Bind** - -For each manifest you list in the `manifests.path` section of your Armory CD-as-a-Service deployment file, you must bind the artifact to the stage. - -For example, if your deployment file specifies: - -```yaml -... -manifests: - - path: manifests/potato-facts.yml -... -``` - -Then you must bind `potato-facts.yml` as a required artifact: - -{{< figure src="/images/cdaas/plugin/req-artifact-to-bind.png" alt="Example of an artifact added to Required Artifacts to Bind" >}} - -### Kubernetes Progressive stage - -If you have deployed Kubernetes apps before using Armory CD, this page may look familiar. The key difference between a Kubernetes deployment using Armory CD and Armory CD with the Armory CD-as-a-Service Spinnaker Plugin is in the **How to Deploy** section. - -The **How to Deploy** section is where you define your progressive deployment and consists of two parts: - -**Strategy** - -This is the deployment strategy you want to use to deploy your Kubernetes app. As part of the early access program, the **Canary** strategy is available. Canary deployments allow you to roll out changes to a predefined percentage of your cluster and increment from there as you monitor the effects of your changes. If something doesn't look quite right, you can initiate a rollback to a previous known good state. - -**Steps** - -These settings control how the your Kubernetes deployment behaves as Armory CD-as-a-Service deploys it. You can tune two separate but related characteristics of the deployment: - -- **Rollout Ratio**: set the percentage threshold (integer) for how widely an app should get rolled out before pausing. -- **Then wait**: define what triggers the rollout to continue. The trigger can either be a manual approval (**until approved**) or for a set amount of time, either seconds, minutes or hours (integer). - -Create a step for each **Rollout Ratio** you want to define. For example, if you want a deployment to pause at 25%, 50%, and 75% of the app rollout, you need to define 3 steps, one for each of those thresholds. The steps have independent **Then wait** behaviors and can be set to all follow the same behavior or different ones. - -#### Try out the stage - -You can try out the **Kubernetes Progressive** stage using either the `hello-world` sample manifest described below or an artifact that you have. The `hello-world` example deploys NGINX that intentionally takes longer than usual for demonstration purposes. - -Perform the following steps: - -1. In the Armory CD UI, select an existing app or create a new one. -2. Create a new pipeline. -3. Add a stage to your pipeline with the following attributes: - - **Type**: select **Kubernetes Progressive** - - **Stage Name**: provide a descriptive name or use the autogenerated name. -4. In the **Account** field, select the target Kubernetes cluster you want to deploy to. This is a cluster where the Remote Network Agent is installed -5. For **Manifest Source**, ensure that you select your manifest source. If you are using the `hello-world` sample manifest described later, select **Text**. -6. **Using text as the manifest source:** - - In the **Manifest** field, provide your manifest. If you are using the `hello-world` manifest, enter that manifest. - -
Show me the hello-world manifest - - ```yaml - # A simple nginx deployment with an init container that causes deployment to take longer than usual - apiVersion: apps/v1 - kind: Deployment - metadata: - name: demo-app - spec: - replicas: 10 - selector: - matchLabels: - app: demo-app - template: - metadata: - labels: - app: demo-app - spec: - containers: - - env: - - name: TEST_ID - value: __TEST_ID_VALUE__ - image: 'nginx:1.14.1' - name: demo-app - ports: - - containerPort: 80 - name: http - protocol: TCP - initContainers: - - command: - - sh - - '-c' - - sleep 10 - image: 'busybox:stable' - name: sleep - ``` - -
- - **Using an existing artifact** - - Select an existing artifact or define a new one as you would for a standard Kubernetes deployment in Armory CD. - -7. In the **How to Deploy** section, configure the **Rollout Ratio** and **Then wait** attributes for the deployment. - - Optionally, add more steps to the deployment to configure the rollout behavior. You do not need to create a step for 100% Rollout Ratio. Armory CD-as-a-Service automatically scales the deployment to 100% after the final step you configure. - -8. Save the pipeline. -9. Trigger a manual execution of the pipeline. - -On the **Pipelines** page of the Armory CD UI, select the pipeline and watch the deployment progress. If you set the **Then wait** behavior of any step to **until approved**, this is where you approve the rollout and allow it to continue. After completing the final step you configured, Armory CD-as-a-Service scales the deployment to 100% of the cluster if needed. - -## Known issues and limitations - -### Manifest limitations - -{{< include "cdaas/ki-manifest-limitation.md" >}} - -### `armory.cloud` block location - -In Armory CD 2.26.3, the location of where you put the `armory.cloud` config block is different from other versions. Additionally, there is an additional config block for `spec.spinnakerConfig.profiles.gate.spinnaker.extensibility` that contains information for the plugin named `plugins`. - -{{< tabs name="KnownIssue" >}} -{{% tabbody name="Operator" %}} - -Your Kustomize patch file should resemble the following where `armory.cloud` is a child of the `gate` and `orca` blocks instead of a `spinnaker` block: - -```yaml -#patch-plugin-deployment.yml -apiVersion: spinnaker.armory.io/v1alpha2 -kind: SpinnakerService -metadata: - name: spinnaker - namespace: -spec: - spinnakerConfig: - profiles: - gate: - spinnaker: - extensibility: - # This snippet is necessary so that Gate can serve your plugin code to Deck - deck-proxy: - enabled: true - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version - repositories: - armory-deployment-plugin-releases: - enabled: true - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json - # Note how armory.cloud is a child of gate instead of spinnaker - armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io - # Note how armory.cloud is a child of orca instead of spinnaker - orca: - armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io - spinnaker: - extensibility: - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -``` - - - -{{% /tabbody %}} -{{% tabbody name="Halyard" %}} - -Your `spinnaker-local.yml` file should not have the `armory.cloud` block anymore and only contain the block to install the plugin: - -```yaml -#spinnaker-local.yml -spinnaker: - extensibility: - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -``` - -Your `gate-local.yml` file should include the `extensibility` and the `armory.cloud` configurations like the following example: - -```yaml -#gate-local.yml -spinnaker: - extensibility: - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version - # This snippet is necessary so that Gate can serve your plugin code to Deck - deck-proxy: - enabled: true - plugins: - Armory.Deployments: - enabled: true - version: # Replace this with the latest version from: https://github.com/armory-plugins/armory-deployment-plugin-releases/releases/ - repositories: - armory-deployment-plugin-releases: - enabled: true - url: https://raw.githubusercontent.com/armory-plugins/armory-deployment-plugin-releases/master/repositories.json -armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io -``` - -Your `orca-local.yml` file should include the `armory.cloud` configration like the following: - -```yaml -#orca-local.yml -armory.cloud: - enabled: true - iam: - clientId: - clientSecret: - tokenIssuerUrl: https://auth.cloud.armory.io/oauth/token - api: - baseUrl: https://api.cloud.armory.io -``` - -{{% /tabbody %}} -{{< /tabs >}} - -> This product documentation page is Armory confidential information. - -## Release notes - -You can find the plugin release notes in the [Armory CD-as-a-Service release notes](https://armory.releases.live/ledger/embed/). \ No newline at end of file + \ No newline at end of file diff --git a/layouts/404.html b/layouts/404.html index 4853a66549..6c22d3510a 100644 --- a/layouts/404.html +++ b/layouts/404.html @@ -2,32 +2,29 @@

Page Not Found

-

Oops! We're sorry we missed coding a redirect. - Please use the site navigation or the search on the - home page to find content.

-

- Enjoy this artwork from the public domain Works Progress Administration (WPA) Art Collection, which is part of The New York Public Library Digital Collections. The pieces below were created between 1935 and 1943 at the Harlem Arts Community Center. The WPA enabled many artists to work full time on their craft. -

- - - - - - - - -
-
- Rhythm Band -
WPA Rhythm Band
-
-
+ + + +
- Harlem Dance -
Harlem WPA Street Dance
+ Page Not Found +
-
-
+ + +

+ + + Find CD-as-a-Service docs at developer.armory.io
+ Find Armory CD docs at docs.armory.io/continuous-deployment/
+ Find Spinnaker Plugins docs at docs.armory.io/plugins/
+ + +

+
{{ end }} + + + diff --git a/layouts/cd-as-a-service/baseof.html b/layouts/cd-as-a-service/baseof.html deleted file mode 100644 index d891fb7287..0000000000 --- a/layouts/cd-as-a-service/baseof.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - {{ partial "head.html" . }} - {{ partial "cdaas/pendo.html" . }} - - -
- {{ partial "navbar.html" . }} -
-
-
-
- - -
- {{ partial "version-banner.html" . }} - {{ partial "cdaas/cdaas-banner.html" . }} - {{ if not .Site.Params.ui.breadcrumb_disable }}{{ partial "breadcrumb.html" . }}{{ end }} - {{ block "main" . }}{{ end }} -
-
-
- {{ partial "cdaas/cdaas-footer.html" . }} -
- {{ partial "scripts.html" . }} - - \ No newline at end of file diff --git a/layouts/cd-as-a-service/baseof.print.html b/layouts/cd-as-a-service/baseof.print.html deleted file mode 100644 index d37e99012b..0000000000 --- a/layouts/cd-as-a-service/baseof.print.html +++ /dev/null @@ -1,26 +0,0 @@ - - - - {{ partial "head.html" . }} - - -
- {{ partial "navbar.html" . }} -
-
-
-
-
-
-
-
-
- {{ block "main" . }}{{ end }} -
-
-
- {{ partial "footer.html" . }} -
- {{ partial "scripts.html" . }} - - diff --git a/layouts/cd-as-a-service/glossary.html b/layouts/cd-as-a-service/glossary.html deleted file mode 100644 index bd710b0c90..0000000000 --- a/layouts/cd-as-a-service/glossary.html +++ /dev/null @@ -1,55 +0,0 @@ -{{ define "main" }} -

{{ .Title }}

- - -

{{ T "layouts_docs_glossary_description" }}

-
-

{{ T "layouts_docs_glossary_filter" }}

- - {{ range (index site.Data "canonical-tags") }} -
- {{ .description }} -
- {{ end }} - {{ $sorted_tags := sort (index site.Data "canonical-tags") "name" }} - {{ range $sorted_tags }} - {{ $full_tag_name := printf "tag-%s" .id }} - - {{ .name }} - - {{ end }} - {{ T "layouts_docs_glossary_select_all" }} - {{ T "layouts_docs_glossary_deselect_all" }} -
-

{{ T "layouts_docs_glossary_click_details_before" }} [+] {{ T "layouts_docs_glossary_click_details_after" }}

-{{ partial "cdaas/glossary-terms.html" . }} -{{ $glossary_items := $.Scratch.Get "glossary_items" }} -{{ with $glossary_items }} -{{ $glossary_terms := sort . "Title" "asc" }} - -{{ end }} -{{ end }} - diff --git a/layouts/cd-as-a-service/list.html b/layouts/cd-as-a-service/list.html deleted file mode 100644 index b59b8d0047..0000000000 --- a/layouts/cd-as-a-service/list.html +++ /dev/null @@ -1,32 +0,0 @@ -{{ define "main" }} -
-

{{ .Title }}

- {{ with .Params.description }}
{{ . | markdownify }}
{{ end }} -
- {{ $context := . }} - {{ if .Site.Params.Taxonomy.taxonomyPageHeader }} - {{ range $index, $taxo := .Site.Params.Taxonomy.taxonomyPageHeader }} - {{ partial "taxonomy_terms_article.html" (dict "context" $context "taxo" $taxo ) }} - {{ end }} - {{ else }} - {{ range $taxo, $taxo_map := .Site.Taxonomies }} - {{ partial "taxonomy_terms_article.html" (dict "context" $context "taxo" $taxo ) }} - {{ end }} - {{ end }} - {{ if (and (not .Params.hide_readingtime) (.Site.Params.ui.readingtime.enable)) }} - {{ partial "reading-time.html" . }} - {{ end }} -
- {{ .Content }} - {{ partial "section-index.html" . }} - {{ if (and (not .Params.hide_feedback) (.Site.Params.ui.feedback.enable) (.Site.GoogleAnalytics)) }} - {{ partial "feedback.html" .Site.Params.ui.feedback }} -
- {{ end }} - {{ if (.Site.DisqusShortname) }} -
- {{ partial "disqus-comment.html" . }} - {{ end }} - {{ partial "page-meta-lastmod.html" . }} -
-{{ end }} diff --git a/layouts/cd-as-a-service/list.print.html b/layouts/cd-as-a-service/list.print.html deleted file mode 100644 index 1b04015886..0000000000 --- a/layouts/cd-as-a-service/list.print.html +++ /dev/null @@ -1,3 +0,0 @@ -{{ define "main" }} -{{ partial "print/render" . }} -{{ end }} diff --git a/layouts/cd-as-a-service/single.html b/layouts/cd-as-a-service/single.html deleted file mode 100644 index 00cb3ab911..0000000000 --- a/layouts/cd-as-a-service/single.html +++ /dev/null @@ -1,3 +0,0 @@ -{{ define "main" }} -{{ .Render "content" }} -{{ end }} \ No newline at end of file diff --git a/netlify.toml b/netlify.toml index 9ec16a9f99..a70b4a38c8 100644 --- a/netlify.toml +++ b/netlify.toml @@ -44,11 +44,6 @@ from = "/scale-agent/*" to = "/plugins/scale-agent/:splat" -[[redirects]] - from = "/cd-as-a-service/plugin-spinnaker/" - to = "/plugins/cdaas-spinnaker/" - force = true # ensure this always redirects because the "from" page does exist and does a TOC redirect but not for users clicking web search result link - [[redirects]] from = "/continuous-deployment/armory-admin/pipelines-as-code-enable/" to = "/plugins/pipelines-as-code/install/armory-cd/" @@ -70,9 +65,146 @@ from = "/armory-enterprise/*" to = "/continuous-deployment/:splat" +# cdaas redirects +# The Netlify redirects engine will process the first matching rule it finds, reading from top to bottom. The redirect engine processes the first matching rule it finds, so more specific rules should be listed before more general ones +# https://docs.netlify.com/routing/redirects/ +# https://docs.netlify.com/routing/redirects/redirect-options/ +# status = 301 (default); permanent redirect code. Tells the client that the address for this resource has permanently changed, and any indexes using the old address should start using the new one. The URL in the browser address bar will display the new address. + +[[redirects]] + from = "/cd-as-a-service/reference/ref-deployment-file/" + to = "https://developer.armory.io/docs/reference/deployment/config-file/" + +[[redirects]] + from = "/cd-as-a-service/reference/ref-queries/" + to = "https://developer.armory.io/docs/reference/canary-analysis-query/" + +[[redirects]] + from = "/cd-as-a-service/reference/ref-queries/" + to = "https://developer.armory.io/docs/reference/canary-analysis-query/" + +[[redirects]] + from = "/cd-as-a-service/setup/quickstart/" + to = "https://developer.armory.io/docs/get-started/quickstart/" + +[[redirects]] + from = "/cd-as-a-service/setup/deploy-your-app/" + to = "https://developer.armory.io/docs/get-started/deploy-your-app/" + +[[redirects]] + from = "/cd-as-a-service/setup/gh-action/" + to = "https://developer.armory.io/docs/integrations/ci-systems/gh-action/" + +[[redirects]] + from = "/cd-as-a-service/setup/blue-green/" + to = "https://developer.armory.io/docs/deployment/strategies/blue-green/" + [[redirects]] - from = "/armory-cdaas/*" - to = "/cd-as-a-service/" + from = "/cd-as-a-service/setup/canary/" + to = "https://developer.armory.io/docs/deployment/strategies/canary/" + +[[redirects]] + from = "/cd-as-a-service/setup/argo-rollouts/" + to = "https://developer.armory.io/docs/deployment/kubernetes/argo-rollouts/" + +[[redirects]] + from = "/cd-as-a-service/concepts/external-automation/" + to = "https://developer.armory.io/docs/webhooks/overview/" + +[[redirects]] + from = "/cd-as-a-service/tasks/webhook-approval/" + to = "https://developer.armory.io/docs/webhooks/webhook-approval/" + +[[redirects]] + from = "/cd-as-a-service/tasks/cli/" + to = "https://developer.armory.io/docs/cli/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/monitor-deployment/" + to = "https://developer.armory.io/docs/deployment/monitor-deployment/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/create-deploy-config/" + to = "https://developer.armory.io/docs/deployment/create-deploy-config/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/add-context-variable/" + to = "https://developer.armory.io/docs/deployment/add-context-variable/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/deploy-with-creds/" + to = "https://developer.armory.io/docs/deployment/deploy-with-creds/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/preview-link/" + to = "https://developer.armory.io/docs/reference/deployment/config-preview-link/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/role-based-manual-approval/" + to = "https://developer.armory.io/docs/reference/deployment/config-role-based-manual-approval/" + +[[redirects]] + from = "/cd-as-a-service/tasks/secrets/secrets-create/" + to = "https://developer.armory.io/docs/iam/manage-secrets/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/traffic-management/linkerd/" + to = "https://developer.armory.io/docs/traffic-management/linkerd/" + +[[redirects]] + from = "/cd-as-a-service/tasks/deploy/traffic-management/istio/" + to = "https://developer.armory.io/docs/traffic-management/istio/" + +[[redirects]] + from = "/cd-as-a-service/tutorials/deploy-sample-app/" + to = "https://developer.armory.io/docs/tutorials/deploy-sample-app/" + +[[redirects]] + from = "/cd-as-a-service/tutorials/external-automation/webhook-github/" + to = "https://developer.armory.io/docs/tutorials/tutorial-webhook-github/" + +# redirect anything in concepts/deployment +[[redirects]] + from = "/cd-as-a-service/concepts/deployment/*" + to = "https://developer.armory.io/docs/deployment/overview/" + +# redirect anything in concepts/architecture/ +[[redirects]] + from = "/cd-as-a-service/concepts/architecture/*" + to = "https://developer.armory.io/docs/architecture/" + +# redirect anything in concepts/iam/ +[[redirects]] + from = "/cd-as-a-service/concepts/iam/*" + to = "https://developer.armory.io/docs/iam/" + + + +# redirect anything in tasks/networking +[[redirects]] + from = "/cd-as-a-service/tasks/networking/*" + to = "https://developer.armory.io/docs/remote-network-agent/overview/" + +# redirect anything in tutorials/access-management/ +[[redirects]] + from = "/cd-as-a-service/tutorials/access-management/*" + to = "https://developer.armory.io/docs/tutorials/tutorial-rbac-users/" + +# redirect anything in /release-notes/ +[[redirects]] + from = "cd-as-a-service/release-notes/*" + to = "https://developer.armory.io/docs/release-notes/" + +# redirect anything in /troubleshooting/ +[[redirects]] + from = "cd-as-a-service/troubleshooting/*" + to = "https://developer.armory.io/docs/troubleshooting/" + +# this has to be last since it functions as a catchall for paths not previously defined +[[redirects]] + from = "/cd-as-a-service/*" + to = "http://developer.armory.io" + # https://github.com/netlify-labs/netlify-plugin-sitemap [[plugins]] @@ -85,7 +217,6 @@ package = "@netlify/plugin-sitemap" './public/plugins/plugin-appname/', './public/plugins/plugin-external-account/', './public/plugins/plugin-iam-authentication/', - './public/cd-as-a-service/plugin-spinnaker/', './public/continuous-deployment/feature-status/deprecations/pacrd-deprecation/', './public/continuous-deployment/installation/deployment-reg/', './public/managed-spin', diff --git a/static/images/404/404-graphic.png b/static/images/404/404-graphic.png new file mode 100644 index 0000000000..1ede9073c7 Binary files /dev/null and b/static/images/404/404-graphic.png differ diff --git a/static/images/cdaas/UI-environment-list.jpg b/static/images/cdaas/UI-environment-list.jpg deleted file mode 100644 index 8fef9c3fd0..0000000000 Binary files a/static/images/cdaas/UI-environment-list.jpg and /dev/null differ diff --git a/static/images/cdaas/cdaas-arch.png b/static/images/cdaas/cdaas-arch.png deleted file mode 100644 index 46eda54200..0000000000 Binary files a/static/images/cdaas/cdaas-arch.png and /dev/null differ diff --git a/static/images/cdaas/gha-statusUI.jpg b/static/images/cdaas/gha-statusUI.jpg deleted file mode 100644 index 2ea60ef4aa..0000000000 Binary files a/static/images/cdaas/gha-statusUI.jpg and /dev/null differ diff --git a/static/images/cdaas/multitarget-deploy.jpg b/static/images/cdaas/multitarget-deploy.jpg deleted file mode 100644 index 7ef854a616..0000000000 Binary files a/static/images/cdaas/multitarget-deploy.jpg and /dev/null differ diff --git a/static/images/cdaas/plugin/prog-deploy-artifact.png b/static/images/cdaas/plugin/prog-deploy-artifact.png deleted file mode 100644 index 163a984b9d..0000000000 Binary files a/static/images/cdaas/plugin/prog-deploy-artifact.png and /dev/null differ diff --git a/static/images/cdaas/plugin/prog-deploy-yaml.png b/static/images/cdaas/plugin/prog-deploy-yaml.png deleted file mode 100644 index ba02e4ea2d..0000000000 Binary files a/static/images/cdaas/plugin/prog-deploy-yaml.png and /dev/null differ diff --git a/static/images/cdaas/plugin/req-artifact-to-bind.png b/static/images/cdaas/plugin/req-artifact-to-bind.png deleted file mode 100644 index a45305955d..0000000000 Binary files a/static/images/cdaas/plugin/req-artifact-to-bind.png and /dev/null differ diff --git a/static/images/cdaas/setup/quickstart/clickApprove.jpg b/static/images/cdaas/setup/quickstart/clickApprove.jpg deleted file mode 100644 index 942053567e..0000000000 Binary files a/static/images/cdaas/setup/quickstart/clickApprove.jpg and /dev/null differ diff --git a/static/images/cdaas/setup/quickstart/deployFinishedDetails.jpg b/static/images/cdaas/setup/quickstart/deployFinishedDetails.jpg deleted file mode 100644 index 17e875b4d5..0000000000 Binary files a/static/images/cdaas/setup/quickstart/deployFinishedDetails.jpg and /dev/null differ diff --git a/static/images/cdaas/setup/quickstart/openTrafficSplitDetails.jpg b/static/images/cdaas/setup/quickstart/openTrafficSplitDetails.jpg deleted file mode 100644 index 4213a467fb..0000000000 Binary files a/static/images/cdaas/setup/quickstart/openTrafficSplitDetails.jpg and /dev/null differ diff --git a/static/images/cdaas/setup/quickstart/potatoFactsTrafficSplit.jpg b/static/images/cdaas/setup/quickstart/potatoFactsTrafficSplit.jpg deleted file mode 100644 index 921a88fe52..0000000000 Binary files a/static/images/cdaas/setup/quickstart/potatoFactsTrafficSplit.jpg and /dev/null differ diff --git a/static/images/cdaas/setup/quickstart/trafficSplitDetailsWindow.jpg b/static/images/cdaas/setup/quickstart/trafficSplitDetailsWindow.jpg deleted file mode 100644 index e4c48208ba..0000000000 Binary files a/static/images/cdaas/setup/quickstart/trafficSplitDetailsWindow.jpg and /dev/null differ diff --git a/static/images/cdaas/tasks/deploy/exposeServices-API.png b/static/images/cdaas/tasks/deploy/exposeServices-API.png deleted file mode 100644 index 3bb69b3cea..0000000000 Binary files a/static/images/cdaas/tasks/deploy/exposeServices-API.png and /dev/null differ diff --git a/static/images/cdaas/tasks/deploy/exposeServices-UI.png b/static/images/cdaas/tasks/deploy/exposeServices-UI.png deleted file mode 100644 index bab3ad7189..0000000000 Binary files a/static/images/cdaas/tasks/deploy/exposeServices-UI.png and /dev/null differ diff --git a/static/images/cdaas/tutorials/webhooks/webhook-failure.jpg b/static/images/cdaas/tutorials/webhooks/webhook-failure.jpg deleted file mode 100644 index dbfdb9bf55..0000000000 Binary files a/static/images/cdaas/tutorials/webhooks/webhook-failure.jpg and /dev/null differ diff --git a/static/images/cdaas/tutorials/webhooks/webhook-success.jpg b/static/images/cdaas/tutorials/webhooks/webhook-success.jpg deleted file mode 100644 index 24fa563fb0..0000000000 Binary files a/static/images/cdaas/tutorials/webhooks/webhook-success.jpg and /dev/null differ diff --git a/static/images/cdaas/ui-constraints.jpg b/static/images/cdaas/ui-constraints.jpg deleted file mode 100644 index e32bf6ff08..0000000000 Binary files a/static/images/cdaas/ui-constraints.jpg and /dev/null differ diff --git a/static/images/cdaas/ui-fulldetails.jpg b/static/images/cdaas/ui-fulldetails.jpg deleted file mode 100644 index 71e9b5cfbf..0000000000 Binary files a/static/images/cdaas/ui-fulldetails.jpg and /dev/null differ diff --git a/static/images/cdaas/ui-rna-status.jpg b/static/images/cdaas/ui-rna-status.jpg deleted file mode 100644 index b02b743ff0..0000000000 Binary files a/static/images/cdaas/ui-rna-status.jpg and /dev/null differ diff --git a/static/images/cdaas/ui-switch-tenant.jpg b/static/images/cdaas/ui-switch-tenant.jpg deleted file mode 100644 index 0e7ec868ae..0000000000 Binary files a/static/images/cdaas/ui-switch-tenant.jpg and /dev/null differ diff --git a/static/images/cdaas/user-no-role.png b/static/images/cdaas/user-no-role.png deleted file mode 100644 index 751284030f..0000000000 Binary files a/static/images/cdaas/user-no-role.png and /dev/null differ diff --git a/static/images/cdaas/user-role-delete.jpg b/static/images/cdaas/user-role-delete.jpg deleted file mode 100644 index b86b2e96a2..0000000000 Binary files a/static/images/cdaas/user-role-delete.jpg and /dev/null differ