A variety of tweaks to containers docs

Author: mikenomitch

src/content/docs/containers/architecture.mdx

@@ -5,7 +5,9 @@ sidebar:
   order: 9
 ---
 
-### How and where containers run
+This page describes the architecture of Cloudflare Containers.
+
+## How and where containers run
 
 After you deploy a Worker that uses a Container, your image is uploaded to
 [Cloudflare's Registry](/containers/image-management) and distributed globally to Cloudflare's Network.
@@ -32,7 +34,7 @@ should be built for the `linux/amd64` architecture, and should stay within
 [size limits](/containers/platform-details/#limits). Logging, metrics collection, and
 networking are automatically set up on each container.
 
-### Life of a Container Request
+## Life of a Container Request
 
 When a request is made to any Worker, including one with an associated Container, it is generally handled
 by a datacenter in a location with the best latency between itself and the requesting user.
@@ -60,6 +62,6 @@ which will allow container instances to always run in the same location as their
 :::
 
 Because all Container requests are passed through a Worker, end-users cannot make TCP or
-UDP requests to a Container instance. Workers themselves cal make TCO and UDP requests to
+UDP requests to a Container instance. Workers themselves can make TCO and UDP requests to
 the Container using the [`connect()` API](/workers/runtime-apis/tcp-sockets/#connect). If you have a use
 case that requires inbound TCP or UDP from an end-user, please [let us know](https://forms.gle/AGSq54VvUje6kmKu8).

src/content/docs/containers/beta-info.mdx

@@ -71,6 +71,6 @@ There are several areas where we wish to gather feedback from users:
 - Do you want to integrate Containers with any other Cloudflare services? If so, which ones and how?
 - Do you want more ways to interact with a Container via Workers? If so, how?
 - Do you need different mechanisms for routing requests to containers?
-- Do you need different mechanisms for scaling containers? (see scaling documentation for information on autoscaling plans)
+- Do you need different mechanisms for scaling containers? (see [scaling documentation](/containers/scaling-and-routing) for information on autoscaling plans)
 
 At any point during the Beta, feel free to [give feedback using this form](https://forms.gle/CscdaEGuw5Hb6H2s7).

src/content/docs/containers/examples/container-backend.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: A simple frontend app with a containerized backend
-tags:
-  - Containers
 pcx_content_type: example
 title: Static Frontend, Container Backend
 sidebar:
@@ -20,44 +18,44 @@ but you can select from one of many frontend frameworks. See our [Workers framew
 
 For a full example, see the [Static Frontend + Container Backend Template](https://github.com/mikenomitch/static-frontend-container-backend).
 
-### Configure Static Assets and a Container
+## Configure Static Assets and a Container
 
 <WranglerConfig>
-```jsonc
+```json
 {
-	"name": "cron-container",
-	"main": "src/index.ts",
-	"assets": {
+  "name": "cron-container",
+  "main": "src/index.ts",
+  "assets": {
     "directory": "./dist",
     "binding": "ASSETS"
   },
-	"containers": [
-		{
-			"class_name": "Backend",
-			"image": "./Dockerfile",
-		}
-	],
-	"durable_objects": {
-		"bindings": [
-			{
-				"class_name": "Backend",
-				"name": "BACKEND"
-			}
-		]
-	},
-	"migrations": [
-		{
-			"new_sqlite_classes": [
-				"Backend"
-			],
-			"tag": "v1"
-		}
-	]
+  "containers": [
+    {
+      "class_name": "Backend",
+      "image": "./Dockerfile",
+    }
+  ],
+  "durable_objects": {
+    "bindings": [
+      {
+        "class_name": "Backend",
+        "name": "BACKEND"
+      }
+    ]
+  },
+  "migrations": [
+    {
+      "new_sqlite_classes": [
+        "Backend"
+      ],
+      "tag": "v1"
+    }
+  ]
 }
 ```
 </WranglerConfig>
 
-### Add a simple index.html file to serve
+## Add a simple index.html file to serve
 
 Create a simple `index.html` file in the `./dist` directory.
 
@@ -125,26 +123,21 @@ Create a simple `index.html` file in the `./dist` directory.
 ```
 </Details>
 
-In this example, we are using Alpine.js to fetch a list of widgets from "/api/widgets".
+In this example, we are using [Alpine.js](https://alpinejs.dev/) to fetch a list of widgets from "/api/widgets".
 
 This is meant to be a very simple example, but you can get significantly more complex.
 See [examples of Workers integrating with frontend frameworks](/workers/framework-guides/web-apps/) for more information.
 
-### Define a Worker
+## Define a Worker
 
 Your Worker needs to be able to both serve static assets and route requests to the containerized backend.
 
 In this case, we will pass requests to one of three container instances if the route starts with `/api`,
 and all other requests will be served as static assets.
 
-```ts
+```javascript
 import { Container, getRandom } from "@cloudflare/containers";
 
-export interface Env {
-	BACKEND: DurableObjectNamespace<Backend>;
-	ASSETS: Fetcher;
-}
-
 const INSTANCE_COUNT = 3;
 
 class Backend extends Container {
@@ -153,7 +146,7 @@ class Backend extends Container {
 }
 
 export default {
-	async fetch(request: Request, env: Env): Promise<Response> {
+	async fetch(request, env) {
 		const url = new URL(request.url);
 		if (url.pathname.startsWith("/api")) {
 			// note: "getRandom" to be replaced with latency-aware routing in the near future
@@ -176,7 +169,7 @@ This will make scaling stateless instances simple and routing more efficient. Se
 [autoscaling documentation](/containers/scaling-and-routing) for more details.
 :::
 
-### Define a backend container
+## Define a backend container
 
 Your container should be able to handle requests to `/api/widgets`.
 
@@ -212,4 +205,3 @@ log.Fatal(http.ListenAndServe(":8080", nil))
 
 ```
 </Details>
-```

src/content/docs/containers/examples/cron.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: Running a container on a schedule using Cron Triggers
-tags:
-  - Containers
 pcx_content_type: example
 title: Cron Container
 sidebar:
@@ -20,35 +18,37 @@ Use a cron expression in your Wrangler config to specify the schedule:
 
 <WranglerConfig>
 
-```jsonc
+```json
 {
 	"name": "cron-container",
 	"main": "src/index.ts",
 	"triggers": {
 		"crons": [
-			"*/2 * * * *", // Run every 2 minutes
-		],
+			"*/2 * * * *" // Run every 2 minutes
+		]
 	},
 	"containers": [
 		{
 			"class_name": "CronContainer",
-			"image": "./Dockerfile",
-		},
+			"image": "./Dockerfile"
+		}
 	],
 	"durable_objects": {
 		"bindings": [
 			{
 				"class_name": "CronContainer",
-				"name": "CRON_CONTAINER",
-			},
-		],
+				"name": "CRON_CONTAINER"
+			}
+		]
 	},
 	"migrations": [
 		{
-			"new_sqlite_classes": ["CronContainer"],
-			"tag": "v1",
-		},
-	],
+			"new_sqlite_classes": [
+				"CronContainer"
+			],
+			"tag": "v1"
+		}
+	]
 }
 ```
 

src/content/docs/containers/examples/durable-object-interface.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: Various examples calling Containers directly from Durable Objects
-tags:
-  - Containers
 pcx_content_type: example
 title: Using Durable Objects Directly
 external_link: https://github.com/cloudflare/containers-demos

src/content/docs/containers/examples/env-vars-and-secrets.mdx

@@ -1,16 +1,14 @@
 ---
 type: example
 summary: Pass in environment variables and secrets to your container
-tags:
-  - Containers
 pcx_content_type: example
 title: Env Vars and Secrets
 sidebar:
   order: 6
 description: Pass in environment variables and secrets to your container
 ---
 
-import { WranglerConfig } from "~/components";
+import { WranglerConfig, PackageManagers } from "~/components";
 
 Environment variables can be passed into a Container using the `envVars` field
 in the `Container` class, or by setting manually when the Container starts.
@@ -29,45 +27,54 @@ be passing in:
 In practice, you may just use one of the methods for storing secrets, but
 we will show both for completeness.
 
-### Creating secrets
+## Creating secrets
 
 First, let's create the `"CONTAINER_SECRET_KEY"` secret in Worker Secrets:
 
-```bash
-npx wrangler secret put CONTAINER_SECRET_KEY
-```
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="secret put CONTAINER_SECRET_KEY"
+/>
 
 Then, let's create a store called "demo" in the Secret Store, and add
-he `"ACCOUNT_API"` secret to it:
+the `"ACCOUNT_API_KEY"` secret to it:
 
-```bash
-wrangler secrets-store store create demo --remote
-wrangler secrets-store secret create demo --name ACCOUNT_API_KEY --scopes workers --remote
-```
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="secrets-store store create demo --remote"
+/>
+
+<PackageManagers
+	type="exec"
+	pkg="wrangler"
+	args="secrets-store secret create demo --name ACCOUNT_API_KEY --scopes workers --remote"
+/>
 
 For full details on how to create secrets, see the [Workers Secrets documentation](/workers/configuration/secrets/)
 and the [Secret Store documentation](/secrets-store/integrations/workers/).
 
-### Adding a secrets binding
+## Adding a secrets binding
 
 Next, we need to add bindings to access our secrets and environment variables
 in Wrangler configuration.
 
 <WranglerConfig>
 
-```jsonc
+```json
 {
 	"name": "my-container-worker",
 	"vars": {
-		"ACCOUNT_NAME": "my-account",
+		"ACCOUNT_NAME": "my-account"
 	},
 	"secrets_store_secrets": [
 		{
 			"binding": "SECRET_STORE",
 			"store_id": "demo",
-			"secret_name": "ACCOUNT_API_KEY",
-		},
-	],
+			"secret_name": "ACCOUNT_API_KEY"
+		}
+	]
 	// rest of the configuration...
 }
 ```
@@ -80,7 +87,7 @@ added to `env`.
 Also note that we did not configure anything specific for environment variables
 or secrets in the container-related portion of wrangler configuration.
 
-### Using `envVars` on the Container class
+## Using `envVars` on the Container class
 
 Now, let's define a Container using the `envVars` field in the `Container` class:
 
@@ -93,15 +100,13 @@ export class MyContainer extends Container {
 		ACCOUNT_API_KEY: env.SECRET_STORE.ACCOUNT_API_KEY,
 		CONTAINER_SECRET_KEY: env.CONTAINER_SECRET_KEY,
 	};
-		MESSAGE: 'I was passed in via the container class!',
-  };
 }
 ```
 
 Every instance of this `Container` will now have these variables and secrets
 set as environment variables when it launches.
 
-### Setting environment variables per-instance
+## Setting environment variables per-instance
 
 But what if you want to set environment variables on a per-instance basis?
 

src/content/docs/containers/examples/index.mdx

@@ -11,4 +11,4 @@ import { GlossaryTooltip, ListExamples } from "~/components";
 
 Explore the following examples of Container functionality:
 
-<ListExamples directory="containers/examples/" />
+<ListExamples directory="containers/examples" />

src/content/docs/containers/examples/stateless.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: Run multiple instances across Cloudflare's network
-tags:
-  - Containers
 pcx_content_type: example
 title: Stateless Instances
 sidebar:

src/content/docs/containers/examples/status-hooks.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: Execute Workers code in reaction to Container status changes
-tags:
-  - Containers
 pcx_content_type: example
 title: Status Hooks
 sidebar:

src/content/docs/containers/examples/websocket.mdx

@@ -1,8 +1,6 @@
 ---
 type: example
 summary: Forwarding a Websocket request to a Container
-tags:
-  - Containers
 pcx_content_type: example
 title: Websocket to Container
 sidebar: