chore: Move static assets to /static (#1777)

Author: niallthomson

website/docs/aiml/chatbot/testing.md

@@ -68,13 +68,13 @@ http://k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com
 A "Chat" button will be visible in the bottom-right corner of the screen:
 
 <Browser url="http://k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com">
-<img src={require('./assets/home-chat.webp').default}/>
+<img src={require('@site/static/docs/aiml/chatbot/home-chat.webp').default}/>
 </Browser>
 
 Clicking this button will display a chat window which you can use to send messages to the retail store assistant:
 
 <Browser url="http://k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com">
-<img src={require('./assets/chat-bot.webp').default}/>
+<img src={require('@site/static/docs/aiml/chatbot/chat-bot.webp').default}/>
 </Browser>
 
 ## Conclusion

website/docs/aiml/inferentia/wrapup.md

@@ -7,8 +7,8 @@ In the previous sections we've seen how we can use Amazon EKS to train models fo
 
 For training the model we would want to use the DLC container as our base image and add our Python code to it. We would then store this container image in our container repository like Amazon ECR. We would use a Kubernetes Job to run this container image on EKS and store the generated model to S3.
 
-![Build Model](./assets/CreateModel.webp)
+![Build Model](/docs/aiml/inferentia/CreateModel.webp)
 
 For running inference against our model we would want to modify our code to allow other applications or users to retrieve the classification results from the model. This could be done by creating a REST API that we can call and responds with our classification results. We would run this application as a Kubernetes Deployment within our cluster using the AWS Inferentia resource requirement: `aws.amazon.com/neuron`.
 
-![Inference Model](./assets/Inference.webp)
+![Inference Model](/docs/aiml/inferentia/Inference.webp)

website/docs/aiml/q-cli/q-cli-setup.md

@@ -84,7 +84,7 @@ To see the tools offered by the EKS MCP server, run:
 
 You should see output similar to this:
 
-![list-mcp-tools](./assets/list-mcp-tools.jpg)
+![list-mcp-tools](/docs/aiml/q-cli/list-mcp-tools.jpg)
 
 The output shows:
 

website/docs/automation/continuousdelivery/codepipeline/deploy_application.md

@@ -27,7 +27,7 @@ $ while [[ "$(aws codepipeline list-pipeline-executions --pipeline-name ${EKS_CL
 
 Once complete the pipeline will show the stages have succeeded.
 
-![Pipeline complete](./assets/pipeline-complete.webp)
+![Pipeline complete](/docs/automation/continuousdelivery/codepipeline/pipeline-complete.webp)
 
 Now we can review the changes that have been made by the pipeline. First we can check the ECR repository:
 
@@ -39,7 +39,7 @@ Now we can review the changes that have been made by the pipeline. First we can
 
 Open the repository `retail-store-sample-ui` and inspect the image that has been pushed.
 
-![Image 1](assets/ecr_image.webp)
+![Image 1](/docs/automation/continuousdelivery/codepipeline/ecr_image.webp)
 
 We can also verify that a Helm release has been installed in the cluster:
 
@@ -76,6 +76,6 @@ $ kubectl get deployment -n ui ui -o json | jq -r '.spec.template.spec.container
 
 We can also click the `deploy_eks` action to view more details such as the logs:
 
-![Pipeline deploy detail](assets/pipeline-deploy-detail.webp)
+![Pipeline deploy detail](/docs/automation/continuousdelivery/codepipeline/pipeline-deploy-detail.webp)
 
 With that we have successfully create a pipeline that builds our application container image and deploys it to an EKS cluster using a Helm chart.

website/docs/automation/continuousdelivery/codepipeline/pipeline_setup.md

@@ -17,7 +17,7 @@ $ aws eks associate-access-policy --cluster-name ${EKS_CLUSTER_NAME} \
 
 Let's explore the CodePipeline that was set up for us, and refer to the CloudFormation that was used to create it.
 
-![Pipeline overview](./assets/pipeline.webp)
+![Pipeline overview](/docs/automation/continuousdelivery/codepipeline/pipeline.webp)
 
 You can use the button below to navigate to the pipeline in the console:
 

website/docs/automation/controlplanes/ack/index.md

@@ -32,4 +32,4 @@ In this lab, we'll use ACK to provision these services and create secrets and co
 
 For learning purposes, we're using helm to install the ACK controller. Another option is to use Terraform that allows for rapid deployment of AWS Service Controllers to your cluster. For more information, see the [ACK Terraform module documentation](https://registry.terraform.io/modules/aws-ia/eks-ack-addons/aws/latest#module_dynamodb).
 
-![EKS with DynamoDB](./assets/eks-workshop-ddb.webp)
+![EKS with DynamoDB](/docs/automation/controlplanes/ack/eks-workshop-ddb.webp)

website/docs/automation/controlplanes/ack/provision-resources.md

@@ -5,7 +5,7 @@ sidebar_position: 5
 
 By default, the **Carts** component in the sample application uses a DynamoDB local instance running as a pod in the EKS cluster called `carts-dynamodb`. In this section of the lab, we'll provision an Amazon DynamoDB cloud-based table for our application using Kubernetes custom resources and configure the **Carts** deployment to use this newly provisioned DynamoDB table instead of the local copy.
 
-![ACK reconciler concept](./assets/ack-desired-current-ddb.webp)
+![ACK reconciler concept](/docs/automation/controlplanes/ack/ack-desired-current-ddb.webp)
 
 Let's examine how we can create the DynamoDB Table using a Kubernetes manifest:
 

website/docs/automation/controlplanes/crossplane/compositions/claims.md

@@ -41,7 +41,7 @@ eks-workshop-carts-crossplane-bt28w-lnb4r   True   True      eks-workshop-carts-
 
 Now, let's understand how the DynamoDB table is deployed using this claim:
 
-![Crossplane reconciler concept](../assets/ddb-claim-architecture.webp)
+![Crossplane reconciler concept](/docs/automation/controlplanes/crossplane/ddb-claim-architecture.webp)
 
 When querying the claim `DynamoDBTable` deployed in the carts namespace, we can observe that it points to and creates a Composite Resource (XR) `XDynamoDBTable`:
 

website/docs/automation/controlplanes/crossplane/how-it-works.md

@@ -23,6 +23,6 @@ Here, `upbound-provider-family-aws` represents the Crossplane provider for Amazo
 
 Crossplane simplifies the process for developers to request infrastructure resources using Kubernetes manifests called claims. As illustrated in the diagram below, claims are the only namespace-scoped Crossplane resources, serving as the developer interface and abstracting implementation details. When a claim is deployed to the cluster, it creates a Composite Resource (XR), a Kubernetes custom resource representing one or more cloud resources defined through templates called Compositions. The Composite Resource then creates one or more Managed Resources, which interact with the AWS API to request the creation of the desired infrastructure resources.
 
-![Crossplane claim](./assets/claim-architecture-drawing.webp)
+![Crossplane claim](/docs/automation/controlplanes/crossplane/claim-architecture-drawing.webp)
 
 This architecture allows for a clear separation of concerns between developers, who work with high-level abstractions (claims), and platform teams, who define the underlying infrastructure implementations (Compositions and Managed Resources).

website/docs/automation/controlplanes/crossplane/index.md

@@ -26,7 +26,7 @@ You can view the Terraform that applies these changes [here](https://github.com/
 
 Crossplane extends your Kubernetes cluster to support orchestrating any infrastructure or managed service. It allows you to compose Crossplane's granular resources into higher-level abstractions that can be versioned, managed, deployed, and consumed using your favorite tools and existing processes.
 
-![EKS with Dynamodb](./assets/eks-workshop-crossplane.webp)
+![EKS with Dynamodb](/docs/automation/controlplanes/crossplane/eks-workshop-crossplane.webp)
 
 With Crossplane, you can: