docs(chore): move images to same location as page (#88)

* docs(chore): move images to same location as page

Create media directory for shared

DOC-747

* fix broken image by moving shared image to media folder

content/en/deployment/monitor-deployment.md → content/en/deployment/monitor-deployment/index.md

@@ -19,9 +19,9 @@ On the **All Deployments** page, you can select a specific deployment to go a pa
 
 The deployment graph page gives you a general idea of the state of the deployment and what target CD-as-a-Service is currently deploying to. This graph uses nodes to represent key aspects of your deployment, gives a dynamic view of the execution of a deployment as it promotes through targets, and offers a historical view of a selected past deployment, including those that were canceled or rolled back. The connections between the nodes illustrate the promotion relationships and if applicable, current progress of an inflight deployment.
 
-{{< figure src="/images/cdaas/deploy/multitarget-ghaTrigger.jpg" >}}
+{{< figure src="multitarget-ghaTrigger.jpg" >}}
 
-{{< figure src="/images/cdaas/deploy/multitarget-cliTrigger.jpg" >}}
+{{< figure src="multitarget-cliTrigger.jpg" >}}
 
 ## Deployment graph node types
 
@@ -63,7 +63,7 @@ Context variables are visible if you have configured them at the time the deploy
 
 A target node corresponds to a target you defined in your deployment config file. Clicking on a specific target takes you to the an overview page for that single target, where you can view details and take additional action if needed.
 
-{{< figure src="/images/cdaas/deploy/ui-fulldetails.jpg" >}}
+{{< figure src="ui-fulldetails.jpg" >}}
 
 ## {{% heading "nextSteps" %}}
 

content/en/deployment/overview.md → content/en/deployment/overview/index.md

@@ -16,7 +16,7 @@ You define your CD-as-a-Service deployment configuration in a YAML file, which y
 
 ## How deployment works
 
-{{< figure src="/images/cdaas/deploy/deploy-overview.jpg" width=80%" height="80%" >}}
+{{< figure src="deploy-overview.jpg" width=80%" height="80%" >}}
 
 * CD-as-a-Service starts a deployment with an environment, such as development, that does not depend on another environment. Then deployment progresses through the steps, conditions, and environments defined in your deployment process. 
 * CD-as-a-Service deploys a new ReplicaSet every time a deployment is started. This ensures changes to resources like ConfigMap are immediately reflected and validated with your deployment strategy. 

content/en/deployment/preview-deployed-service.md

@@ -1,6 +1,6 @@
 ---
 title: Preview a Deployed Service
-manualLinkRelRef: "reference/deployment/config-preview-link.md"
+manualLinkRelRef: "reference/deployment/config-preview-link/index.md"
 exclude_search: true
 weight: 10
 description: >

content/en/get-started/quickstart.md → content/en/get-started/quickstart/index.md

@@ -103,27 +103,27 @@ armory deploy start -f https://go.armory.io/hello-armory-second-deployment --acc
 
 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/get-started/quickstart/clickApprove.jpg" width=80%" height="80%" >}}
+{{< figure src="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/get-started/quickstart/openTrafficSplitDetails.jpg"  width=80%" height="80%"  >}}
+{{< figure src="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/get-started/quickstart/trafficSplitDetailsWindow.jpg" width=80%" height="80%"  >}}
+{{< figure src="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/get-started/quickstart/potatoFactsTrafficSplit.jpg"  width=80%" height="80%"  >}}
+{{< figure src="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/get-started/quickstart/deployFinishedDetails.jpg"  width=80%" height="80%"  >}}
+{{< figure src="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).
+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]({{< ref "reference/deployment/config-file" >}}).
 
 **`targets`**
 

content/en/iam/manage-rbac-roles.md → content/en/iam/manage-rbac-roles/index.md

@@ -243,4 +243,4 @@ Execute `armory config apply -f <path-to-rbac-config>.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" >}}
+{{< figure src="user-no-role.png" >}}

content/en/iam/manage-tenants.md → content/en/iam/manage-tenants/index.md

@@ -101,7 +101,7 @@ Contact a <a href="mailto:[email protected]?subject=Delete a CD-as-a-Servic
 
 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." >}}
+{{< figure src="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.

content/en/iam/manage-users.md → content/en/iam/manage-users/index.md

@@ -55,4 +55,4 @@ CD-as-a-Service requires two-factor authentication (2FA) when logging in. When s
 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" >}}
+{{< figure src="user-role-delete.jpg" alt="User role with arrow pointing at 'x' to delete" >}}

content/en/includes/cdaas-explained-how.md

@@ -6,7 +6,7 @@ CD-as-a-Service uses secure, logicless Remote Network Agents to access privately
 
 Remote Network Agents connect to CD-as-a-Service to establish gRPC via HTTP/2 connections secured with TLS and OIDC client credentials. You don't need to open any ports to grant CD-as-a-Service access to your Kubernetes clusters or privately networked resources.
 
-{{< figure src="/images/cdaas/how-cdaas-works.png" alt="How CD-as-a-Service Works" height="75%" width="75%" >}}
+{{< figure src="/media/how-cdaas-works.png" alt="How CD-as-a-Service Works" height="75%" width="75%" >}}
 
 1. You render your Kubernets manifests using the tools you want. You build and publish your containers where and how you want, from DockerHub to a private registry on your network.
 2. You create a CD-as-a-Service deployment config file in which you define your deployment: canary and/or blue/green strategy; traffic shaping; deployment constraints such as manual judgments; external automation using webhooks; and retrospective analysis. You include the path to your Kubernetes manifests in the deployment config file. CD-as-a-Service can deploy any Kubernetes object that you define in your Kubernetes manifest.

content/en/integrations/plugin-spinnaker.md → content/en/integrations/plugin-spinnaker/index.md

@@ -87,7 +87,7 @@ Go to the [Agents page in the Configuration UI](https://console.cloud.armory.io/
 
 > 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." >}}
+{{< figure src="/media/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.
 
@@ -241,11 +241,11 @@ hal deploy apply
 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/cdaas/plugin/deploy-engine-stage-UI.jpg" alt="The Kubernetes Progressive stage appears in the Type dropdown when you search for it." >}}
+   {{< figure src="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/cdaas/plugin/deploy-engine-accounts.png" alt="If the plugin is configured properly, you should see the target deployment account in the Account dropdown." >}}.
+   {{< figure src="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
 
@@ -285,7 +285,7 @@ The **Deployment Configuration** section is where you define your Armory CD-as-a
 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." >}}
+{{< figure src="prog-deploy-yaml.png" alt="Example of a deployment YAML file pasted into the Deployment YAML text box." >}}
 
 {{% /tabbody %}}
 {{% tabbody name="Artifact" %}}
@@ -295,7 +295,7 @@ Before you select **Artifact**, make sure you have added your Armory CD-as-a-Ser
 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." >}}
+{{< figure src="prog-deploy-artifact.png" alt="Example of a deployment YAML file attached as an artifact." >}}
 
 {{% /tabbody %}}
 {{< /tabs >}}
@@ -316,7 +316,7 @@ manifests:
 
 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" >}}
+{{< figure src="req-artifact-to-bind.png" alt="Example of an artifact added to Required Artifacts to Bind" >}}
 
 ### Kubernetes Progressive stage
 

content/en/reference/deployment/config-file/webhooks.md

@@ -18,4 +18,4 @@ description: >
 
 * {{< linkWithTitle "webhooks/overview.md" >}}
 * {{< linkWithTitle "webhooks/webhook-approval.md" >}}
-* {{< linkWithTitle "tutorials/tutorial-webhook-github">}}
+* {{< linkWithTitle "tutorials/tutorial-webhook-github/index.md">}}

content/en/reference/deployment/config-preview-link.md → content/en/reference/deployment/config-preview-link/index.md

@@ -63,11 +63,11 @@ steps:
 
 ... and then deploy your app, you would see this in your deployment details:
 
-{{< figure src="/images/cdaas/deploy/exposeServices-UI.png" alt="The preview link in the Resources section" >}}
+{{< figure src="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/deploy/exposeServices-API.png" alt="The preview link in the REST API results" >}}
+{{< figure src="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:
 

content/en/remote-network-agent/install.md

@@ -136,5 +136,5 @@ You can go to the [Agents page](https://console.cloud.armory.io/configuration/ag
 
 ## {{% heading "nextSteps" %}}
 
-* [View your connected Remote Network Agents]({{< ref "remote-network-agent/monitor-agents" >}}) to see data such as the last time CD-as-a-Service detected a heartbeat.
+* [View your connected Remote Network Agents]({{< ref "remote-network-agent/monitor-agents/index.md" >}}) to see data such as the last time CD-as-a-Service detected a heartbeat.
 * [Install with advanced configuration options]({{< ref "remote-network-agent/install-helm" >}}).

content/en/remote-network-agent/monitor-agents.md

@@ -16,9 +16,7 @@ The Agent Hub and the RNAs perform periodic healthchecks to ensure that the conn
 
 [**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.
 
-{{< 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." >}}
+{{< figure src="/media/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." >}}
 

content/en/remote-network-agent/overview.md → content/en/remote-network-agent/overview/index.md

@@ -38,11 +38,11 @@ When you install the RNA configured with Armory credentials into your private ne
 
 Agent Hub routes network traffic from internal, authenticated Armory services to your privately networked resources via a multi-target network relay that pipes data through encrypted gRPC tunnels to the RNA, which forwards the data to its destination.
 
-{{< centeredImage src="/images/cdaas/rna-arch.png" alt="CD-as-a-Service Remote Network Agent Architecture Diagram" caption="Remote Network Agent securely integrates your on-prem tools with CD-as-a-Service." >}}
+{{< centeredImage src="rna-arch.png" alt="CD-as-a-Service Remote Network Agent Architecture Diagram" caption="Remote Network Agent securely integrates your on-prem tools with CD-as-a-Service." >}}
 
 In Armory's secure private network, Agent Hub is an [(RFC 1929)](https://datatracker.ietf.org/doc/html/rfc1929) SOCKS5 compliant proxy [(RFC 1928)](https://www.rfc-editor.org/rfc/rfc1928.html). Agent Hub knows how to execute socks proxy requests through a bidirectional gRPC tunnel that is established by an RNA.
 
 ## {{% heading "nextSteps" %}}
 
 * You can use the CLI, kubectl commands, or Helm to install a Remote Network Agent in your cluster. See the [Installation guide]({{< ref "remote-network-agent/install" >}}) for details.
-* You can [view all of your connected RNAs]({{< ref "remote-network-agent/monitor-agents" >}}) on a single UI screen that displays data such as the last time CD-as-Service detected a heartbeat.
+* You can [view all of your connected RNAs]({{< ref "remote-network-agent/monitor-agents/index.md" >}}) on a single UI screen that displays data such as the last time CD-as-Service detected a heartbeat.

content/en/scratchpad.md

@@ -1,55 +1,5 @@
 ---
 title: Scratchpad
-weight: 999
 draft: true
 ---
 
-## codeblock in tabpane
-
-{{< include "cli/install-cli-tabpane.md" >}}
-
-## bash
-
-```bash
-kubectl create ns armory-rna; 
-kubectl --namespace armory-rna create secret generic rna-client-credentials \
---type=string \
---from-literal=client-secret="<client-secret>" \
---from-literal=client-id="<client-id>";
-kubectl apply -f "https://api.cloud.armory.io/kubernetes/agent/manifest?agentIdentifier=sample-cluster&namespace=armory-rna"
-```
-
-## yaml
-
-yaml with lines highlighted
-
-
-{{< highlight yaml "linenos=table, hl_lines=5 10 22-27" >}}
-version: v1
-kind: kubernetes
-application: potato-facts
-targets:
-  staging:
-    account: my-cdaas-cluster
-    namespace: potato-facts-staging
-    strategy: rolling
-  prod:
-    account: my-cdaas-cluster
-    namespace: potato-facts-prod
-    strategy: rolling
-    constraints:
-      dependsOn: ["staging"]
-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:
-  rolling:
-    canary:
-      steps:
-        - setWeight:
-            weight: 100
-{{< /highlight >}}

content/en/troubleshooting/rbac.md → content/en/troubleshooting/rbac/index.md

@@ -10,7 +10,7 @@ tags: ["RBAC"]
 
 ## User sees blank **Deployments** screen
 
-{{< figure src="/images/cdaas/user-no-role.png" alt="User sees the Deployments screen with no deployments." >}}
+{{< figure src="user-no-role.png" alt="User sees the Deployments screen with no deployments." >}}
 
 **Why this happens**
 <br>

content/en/tutorials/tutorial-blue-green.md → content/en/tutorials/tutorial-blue-green/index.md

@@ -275,24 +275,24 @@ armory deploy start  -f deploy-v2.yaml
 
 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/tutorials/bluegreen/approve-prod-start.jpg" width=80%" height="80%" >}}
+{{< figure src="approve-prod-start.jpg" width=80%" height="80%" >}}
 
 
 Once deployment begins, click the **prod** deployment node to open the details window.
 
-{{< figure src="/images/cdaas/tutorials/bluegreen/openDetailsWindow.jpg" width=80%" height="80%" >}}
+{{< figure src="openDetailsWindow.jpg" width=80%" height="80%" >}}
 
 You can see that both the previous version (blue) and new version (green) are running.
 
 In the **Next Version** section, click **View Environment** to open the preview link to the green version of the app. You can also find the link in the **Resources** section.
 
-{{< figure src="/images/cdaas/tutorials/bluegreen/detailsWithPreviewLink.jpg" width=80%" height="80%" >}}
+{{< figure src="detailsWithPreviewLink.jpg" width=80%" height="80%" >}}
 
 After you have verified the new app version, you can click **Approve & Continue** to redirect all traffic to the new version. 
 
 The last step is shutting down the old version. Note that you can roll back until the old version has been shut down.
 
-{{< figure src="/images/cdaas/tutorials/bluegreen/deployFinish.jpg" width=80%" height="80%" >}}
+{{< figure src="deployFinish.jpg" width=80%" height="80%" >}}
 
 ## Clean up
 

content/en/tutorials/tutorial-webhook-github.md → content/en/tutorials/tutorial-webhook-github/index.md

@@ -202,7 +202,7 @@ Output is similar to:
 
 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="<center><i>The basicPing webhook succeeded so deployment continued.</i></center>">}}
+{{< figure  src="webhook-success.jpg"  alt="BeforeDeployment webhook success"  caption="<center><i>The basicPing webhook succeeded so deployment continued.</i></center>">}}
 
 To see what webhook failure looks like, go into your GitHub repo and change the `basicPing.yml` file line 28 like this:
 
@@ -243,7 +243,7 @@ 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="<center><i>The basicPing webhook failed.</i></center>">}}
+{{< figure src="webhook-failure.jpg"  alt="BeforeDeployment webhook failure"  caption="<center><i>The basicPing webhook failed.</i></center>">}}
 
 ## {{% heading "nextSteps" %}}