Capabilities section done

Moving on to tooling

Author: remotesynth

public/images/aws/chaos-engineering-dashboard.png

@@ -1,5 +1,5 @@
 ---
-import data from '../data/coverage.json';
+import data from '../data/persistence/coverage.json';
 
 const coverage = Object.values(data);
 console.log(coverage);

public/images/aws/live-policy-stream-enable.png

@@ -12,14 +12,14 @@ This service allows you to conduct controlled experiments on your AWS infrastruc
 By using the Fault Injection Service, you can identify weaknesses, test recovery procedures, and ensure that your applications can withstand unexpected disruptions.
 This proactive approach to reliability engineering enables you to enhance system robustness, minimize downtime, and maintain a high level of service availability for your users.
 
-{{< alert title="Note">}}
+:::note
 Fault Injection Service emulation is available as part of the LocalStack Enterprise plan.
 If you'd like to try it out, please [contact us](https://www.localstack.cloud/demo) to request access.
-{{< /alert >}}
+:::
 
-{{< callout "tip" >}}
-For more information, please refer to the [FIS service docs]({{< ref "user-guide/aws/fis" >}}).
-{{< /callout >}}
+:::tip
+For more information, please refer to the [FIS service docs](/aws/services/fis).
+:::
 
 Some of the most important concepts associated with a FIS experiment are:
 

public/images/aws/policy-generate.png

@@ -18,15 +18,15 @@ You can use LocalStack Chaos API to cause API failures for any combination of th
 - Region
 - Operation
 
-You can customise the HTTP error code and message that LocalStack responds with.
+You can customize the HTTP error code and message that LocalStack responds with.
 If required, you can make the failures occur probabilistically.
 
 Furthermore, the Chaos API can also be configured to add a network latency for all calls.
 
-{{< alert title="Note">}}
+:::note
 Chaos API is available as part of the LocalStack Enterprise plan.
 If you'd like to try it out, please [contact us](https://www.localstack.cloud/demo) to request access.
-{{< /alert >}}
+:::
 
 ## Prerequisites
 
@@ -92,8 +92,8 @@ This endpoint allows the following operations:
 
 To cause faults, make a POST request as follows:
 
-{{< command >}}
-$ curl --location --request POST 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
+```bash
+curl --location --request POST 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
 --header 'Content-Type: application/json' \
 --data '
 [
@@ -109,48 +109,50 @@ $ curl --location --request POST 'http://localhost.localstack.cloud:4566/_locals
         "service": "lambda"
     }
 ]'
-{{< /command >}}
+```
 
 In this example, S3 is affected in `us-east-1` and `ap-south-1,` and Lambda is affected in all regions.
 All calls to these services in these regions will return a 503 Service Unavailable error.
 
 To see this in action, try to create an S3 bucket in `us-east-1`:
 
-{{< command >}}
-$ awslocal s3 mb s3://test-bucket --region us-east-1
-<disable-copy>
+```bash
+awslocal s3 mb s3://test-bucket --region us-east-1
+```
+
+```bash
 make_bucket failed: s3://test-bucket An error occurred (ServiceUnavailableException) when calling the CreateBucket operation (reached max retries: 4): Service 's3' not accessible due to an outage
-</disable-copy>
-{{< /command >}}
+```
 
 However, the same operation, when run in `eu-central-1` will work as expected.
 
-{{< command >}}
+```bash
 $ awslocal s3 mb s3://test-bucket --region eu-central-1
-<disable-copy>
+```
+
+```bash
 make_bucket: test-bucket
-</disable-copy>
-{{< /command >}}
+```
 
 Faults can be disabled by setting an empty rule list in the configuration.
 The following request will clear the current configuration:
 
-{{< command >}}
-$ curl --location --request POST 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
+```bash
+curl --location --request POST 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
 --header 'Content-Type: application/json' \
 --data '[]'
-{{< /command >}}
+```
 
 To retrieve the current configuration, make the following GET call:
 
-{{< command >}}
-$ curl --location --request GET 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults'
-{{</ command >}}
+```bash
+curl --location --request GET 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults'
+```
 
 To add a new rule to the current configuration, make a PATCH call as follows:
 
-{{< command >}}
-$ curl --location --request PATCH 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
+```bash
+curl --location --request PATCH 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
 --header 'Content-Type: application/json' \
 --data '
 [
@@ -164,18 +166,18 @@ $ curl --location --request PATCH 'http://localhost.localstack.cloud:4566/_local
         }
     }
 ]'
-{{</ command >}}
+```
 
 This new rule will cause probabilistic failures for Kinesis PutRecord operation.
 Here, the returned error is also customised to be HTTP 400 ProvisionedThroughputExceededException.
 
 To remove a rule from the configuration, make a DELETE call as follows:
 
-{{< command >}}
-$ curl --location --request DELETE 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
+```bash
+curl --location --request DELETE 'http://localhost.localstack.cloud:4566/_localstack/chaos/faults' \
 --header 'Content-Type: application/json' \
 --data '[{"service": "lambda"}]'
-{{</ command >}}
+```
 
 The rule to be removed must be exactly the same as in the existing configuration.
 

src/components/persistence-coverage.astro

@@ -12,7 +12,7 @@ The Chaos Engineering Dashboard in LocalStack offers streamlined testing for clo
 
 The dashboard uses [LocalStack Chaos API]({{< ref "chaos-api" >}}) under the hood to offer a set of customizable templates that can be seamlessly integrated into any automation workflows.
 
-{{< figure src="chaos-engineering-dashboard.png" width="900" >}}
+![chaos engineering dashboard](/images/aws/chaos-engineering-dashboard.png)
 
 You can find this feature in the LocalStack Web Application by navigating to [**app.localstack.cloud/chaos-engineering**](https://app.localstack.cloud/chaos-engineering).
 

src/content/docs/aws/capabilities/chaos-engineering/aws-fault-injection.md

@@ -6,6 +6,8 @@ sidebar:
     order: 5
 ---
 
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
 ## Background
 
 LocalStack sometimes performs on-demand fetching of resources from the public internet.
@@ -15,9 +17,9 @@ You may see errors in the logs relating to TLS such as "unable to get local issu
 
 There are three options when running LocalStack:
 
-1. [creating a custom Docker image]({{< ref "#creating-a-custom-docker-image" >}}),
-2. [using init hooks]({{< ref "#custom-ssl-certificates-with-init-hooks" >}}) or
-3. [when running in host mode]({{< ref "#custom-ssl-certificates-with-host-mode" >}}).
+1. [creating a custom Docker image](#creating-a-custom-docker-image),
+2. [using init hooks](#custom-ssl-certificates-with-init-hooks) or
+3. [when running in host mode](#custom-ssl-certificates-with-host-mode).
 
 They all can be summarised as:
 
@@ -28,11 +30,11 @@ They all can be summarised as:
 
 ## Creating a custom docker image
 
-If you run LocalStack in a docker container (which includes using [the CLI]({{< ref "/getting-started#localstack-cli" >}}), [docker]({{< ref "/getting-started/#docker" >}}), [docker-compose]({{< ref "/getting-started/#docker-compose" >}}), or [helm]({{< ref "/getting-started/#helm" >}})), to include a custom TLS root certificate a new docker image should be created.
+If you run LocalStack in a docker container (which includes using [the CLI](/aws/getting-started/installation/#installing-localstack-cli), [docker](/aws/getting-started/installation/#docker), [docker-compose](/aws/getting-started/installation/#docker-compose), or [helm](/aws/getting-started/installation/#helm)), to include a custom TLS root certificate a new docker image should be created.
 
 Create a `Dockerfile` containing the following commands:
 
-```docker
+```yaml
 FROM localstack/localstack:latest
 # or if using the pro image:
 FROM localstack/localstack-pro:latest
@@ -46,34 +48,40 @@ ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt
 
 and build the image:
 
-{{< command >}}
-$ docker build -t <image name> .
-{{< / command >}}
+```bash
+docker build -t <image name> .
+```
 
-{{< callout "tip" >}}
+:::tip
 Certificate files must end in `.crt` to be included in the system certificate store.
 If your certificate file ends with `.pem`, you can rename it to end in `.crt`.
-{{< /callout >}}
+:::
 
 ### Starting LocalStack with the custom image
 
 LocalStack now needs to be configured to use this custom image.
 The workflow is different depending on how you start localstack.
 
-{{< tabpane lang="bash">}}
-{{< tab header="CLI" lang="bash" >}}
+<Tabs>
+<TabItem label="CLI">
+```bash
 IMAGE_NAME=<image name> localstack start
-{{< /tab >}}
-{{< tab header="Docker" lang="bash" >}}
+```
+</TabItem>
+<TabItem label="Docker">
+```bash
 docker run <docker arguments> <image name>
-{{< /tab >}}
-{{< tab header="docker-compose.yml" lang="yml" >}}
+```
+</TabItem>
+<TabItem label="docker-compose.yml">
+```yaml
 services:
   localstack:
     image: <image name>
     # the rest of your configuration
-{{< /tab >}}
-{{< / tabpane >}}
+```
+</TabItem>
+</Tabs>
 
 ## Custom TLS certificates with init hooks
 
@@ -98,7 +106,7 @@ Then run LocalStack with the environment variables
 * `CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt`, and
 * `NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt`
 
-and follow the instructions fn the [init hooks documentation]({{< ref "init-hooks" >}}) for configuring LocalStack to use the hook directory as a `boot` hook.
+and follow the instructions fn the [init hooks documentation](/aws/capabilities/config/initialization-hooks) for configuring LocalStack to use the hook directory as a `boot` hook.
 
 ## Custom TLS certificates with host mode
 
@@ -107,21 +115,21 @@ and follow the instructions fn the [init hooks documentation]({{< ref "init-hook
 On linux the custom certificate should be added to your `ca-certificates` bundle.
 For example on Debian based systems (as root):
 
-{{< command >}}
+```bash
 # cp <your custom certificate.crt> /usr/local/share/ca-certificates
 
 # update-ca-certificates
 
-{{< / command >}}
+```
 
 Then run LocalStack with the environment variables `REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`, and `NODE_EXTRA_CA_CERTS``:
 
-{{< command >}}
-$ NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt \
+```bash
+NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt \
   CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt \
   REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt \
   localstack start --host
-{{< / command >}}
+```
 
 ### macOS
 
@@ -130,14 +138,14 @@ See [this Apple support article](https://support.apple.com/en-gb/guide/keychain-
 
 Then run LocalStack with the environment variables `REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`, and `NODE_EXTRA_CA_CERTS``:
 
-{{< command >}}
-$ NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt \
+```bash
+NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt \
   CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt \
   REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt \
   localstack start --host
-{{< / command >}}
+```
 
 ### Windows
 
 Currently host mode does not work with Windows.
-If you are using WSL2 you should follow the [Linux]({{< ref "#linux" >}}) steps above.
+If you are using WSL2 you should follow the [Linux](#linux) steps above.

src/content/docs/aws/capabilities/chaos-engineering/chaos-api.md

@@ -17,9 +17,9 @@ This guide is designed for users new to Explainable IAM and assumes basic knowle
 
 Start your LocalStack container with the `DEBUG=1` and `ENFORCE_IAM=1` environment variables set:
 
-{{< command >}}
-$ DEBUG=1 ENFORCE_IAM=1 localstack start
-{{< /command >}}
+```bash
+DEBUG=1 ENFORCE_IAM=1 localstack start
+```
 
 In this guide, we will create a policy for creating Lambda functions by only allowing the `lambda:CreateFunction` permission.
 However we have not included the `iam:PassRole` permission, and we will use the Policy Engine's log to point out adding the necessary permission.
@@ -44,9 +44,11 @@ Create a policy document named `policy_1.json` and add the following content:
 
 You can now create a new user named `test-user`, and put the policy in place by executing the following commands:
 
-{{< command >}}
-$ awslocal iam create-user --user-name test-user
-<disable-copy>
+```bash
+awslocal iam create-user --user-name test-user
+```
+
+```bash
 {
     "User": {
         "Path": "/",
@@ -56,38 +58,41 @@ $ awslocal iam create-user --user-name test-user
         "CreateDate": "2022-07-05T16:08:25.741000+00:00"
     }
 }
-</disable-copy>
-$ awslocal iam put-user-policy --user-name test-user --policy-name policy1 --policy-document file://policy_1.json
-{{< /command >}}
+```
+
+```bash
+awslocal iam put-user-policy --user-name test-user --policy-name policy1 --policy-document file://policy_1.json
+```
 
 You can further create an access key for the user by executing the following command:
 
-{{< command >}}
-$ awslocal iam create-access-key --user-name test-user
-{{< /command >}}
+```bash
+awslocal iam create-access-key --user-name test-user
+```
 
 Export the access key and secret key as environment variables:
 
-{{< command >}}
-$ export AWS_ACCESS_KEY_ID=...
-$ export AWS_SECRET_ACCESS_KEY=...
-{{< /command >}}
+```bash
+export AWS_ACCESS_KEY_ID=...
+export AWS_SECRET_ACCESS_KEY=...
+```
 
 ### Attempt to create a Lambda function
 
 You can now attempt to create a Lambda function using the newly created user's credentials:
 
-{{< command >}}
-$ awslocal lambda create-function \
+```bash
+awslocal lambda create-function \
     --function-name test-function \
     --role arn:aws:iam::000000000000:role/lambda-role \
     --runtime python3.8 \
     --handler handler.handler \
     --zip-file fileb://function.zip
-<disable-copy>
+```
+
+```bash
 An error occurred (AccessDeniedException) when calling the CreateFunction operation: Access to the specified resource is denied
-</disable-copy>
-{{< / command >}}
+```
 
 You can inspect the LocalStack logs, to observe the presence of five log entries directly related to the denied request: