Revamp container overview page

docs/content/guides/author-apps/containers/overview/index.md

@@ -8,41 +8,37 @@ categories: "Overview"
 tags: ["containers"]
 ---
 
-A Radius container provides an abstraction to model and run your container workloads as part of your Radius application. 
+A Radius container allows you to run a container workload as part of your application. This can be a frontend UI, a backend API, a database, or any other container you need to run.
 
-{{< rad file="snippets/container.bicep" embed=true marker="//CONTAINER" >}}
+<img src="containers-splash.png" alt="Container graphic" width=300px >
 
-## Supported runtimes
-
-Containers are run on the same Kubernetes cluster as your [Radius installation]({{< ref "guides/operations/kubernetes" >}}). We plan to support additional container runtimes and configurations in the future
-
-## Capabilities
+> Adding a container and want to jump to the reference docs? Check out the [container resource schema]({{< ref "container-schema" >}}).
 
-Radius containers enables you to specify the image for the container, the ports the container provides and consumes, the environment variables to set, the volumes to mount, and the probes to run.
-
-Additionally you can customize the behavior of the containers with the help of [extensions](#extensions).
+## Supported runtimes
 
-### Image
+Radius containers are portable across container runtimes, allowing you to define your container workload once and run it on any of the supported runtimes.
 
-An image can be specified for your container workload to pull and run. Refer to the [container reference docs]({{< ref container-schema >}}) for more information on image requirements.
+### Kubernetes
 
-If you want to pull the container image from a private container register, you need to allow access from your Kubernetes cluster. Follow the documentation to [configure private container registries access]({{< ref "guides/operations/kubernetes/supported-clusters#configure-container-registry-access" >}}).
+Containers are deployed to the same Kubernetes cluster as your Radius installation, into the namespace that is defined in your application. For more information on how Radius resources map to Kubernetes objects, refer to the [Kubernetes mapping guide]({{< ref "kubernetes-mapping" >}}).
 
-### Ports
+## Container definition
 
-Ports allow you to expose your container to incoming network traffic. Refer to the [networking guide]({{< ref networking >}}) for more information on container networking.
+Radius containers allow you to specify your image, ports, environment variables, volumes, and more. Refer to the [container resource schema]({{< ref "container-schema" >}}) for more information.
 
-### Volumes
+## Volumes
 
-The volumes mounted to the container, either ephemeral or persistent, are defined in the volumes section.
+Volumes can be mounted to the container to provide access to data. There are two types of volumes, ephemeral and persistent.
 
 Ephemeral volumes have the same lifecycle as the container, being deployed and deleted with the container. They create an empty directory on the host and mount it to the container.
 
 Persistent volumes have life cycles that are separate from the container. Containers can mount these persistent volumes and restart without losing data. Persistent volumes can also be useful for storing data that needs to be accessed by multiple containers.
 
-### Probes
+## Health Probes
 
-#### Readiness Probe
+Health probes are used to determine the health of a container. There are two types of probes, readiness and liveness. For more information on how to setup health probes, refer to the [container resource schema]({{< ref "container-schema" >}}).
+
+### Readiness Probe
 
 Readiness probes detect when a container begins reporting it is ready to receive traffic, such as after loading a large configuration file that may take a couple seconds to process. There are three types of probes available, httpGet, tcp and exec. 
 
@@ -54,7 +50,7 @@ For an **exec probe**, a command is run within the container. A return code of 0
 
 Refer to the readiness probes section of the [container resource schema]({{< ref "container-schema#readiness-probes" >}}) for more details.
 
-#### Liveness Probe
+### Liveness Probe
 
 Liveness probes detect when a container is in a broken state, restarting the container to return it to a healthy state. There are three types of probes available, httpGet, tcp and exec.
 
@@ -66,45 +62,39 @@ For an **exec probe**, a command is run within the container. A return code of 0
 
 Refer to the probes section of the [container resource schema]({{< ref "container-schema#liveness-probes" >}}) for more details.
 
-### Connections
+## Connections
 
 When a connection between two resources is declared, Radius injects resource related information into environment variables that are then used to access the respective resource without having to hard code URIs, connection strings, access keys, or anything that application code needs to successfully communicate.
 
 These environment variables follow a naming convention that makes their use predictable. The naming pattern is derived from the connection name and resource type, which determines what values are required. This way the code that needs to read the values gets to define how they are named. Refer to the [reference documentation]({{< ref resource-schema >}}) of each resource for more information. 
 
-For example, adding a connection called `myconnection` that connects to a MongoDB resource would result in the following environment variables being injected:
+For example, adding a connection called `database` that connects to a MongoDB resource would result in the following environment variables being injected:
 
-```sh
-# the connection string to the resource
-CONNECTION_MYCONNECTION_CONNECTIONSTRING="mongodb://mongo:27017/mongo?authSource=admin"
-# Database name of the target resource
-CONNECTION_MYCONNECTION_DATABASE="my-database"
-# Username of the target resource
-CONNECTION_MYCONNECTION_USERNAME="admin"
-```
+| Key | Value |
+|-----|-------|
+| `CONNECTION_DATABASE_CONNECTIONSTRING` | The connection string to the database |
+| `CONNECTION_DATABASE_DATABASE` | Database name of the target database |
+| `CONNECTION_DATABASE_USERNAME` | Username of the target database |
+| `CONNECTION_DATABASE_PASSWORD` | Password of the target database |
 
 Alternatively, if you already have another convention you would like to follow or if you just prefer to be explicit, you may ignore the values generated by a connection and instead override it by setting your own environment variable values. Refer to the [environment variables quickstart]({{< ref howto-environment-variables >}}) for more details.
 
-### Extensions
+## Extensions
 
 Extensions define additional capabilities and configuration for a container.
 
-#### Kubernetes metadata extension
+### Kubernetes metadata extension
 
 The [Kubernetes metadata extension]({{< ref kubernetes-metadata>}}) enables you to configure the Kubernetes metadata for the container. This includes the labels and annotations for the container. Refer to to the extension overview page to get more details about the extension and how it works with other Radius resources.
 
-#### Manual scaling extension
+### Manual scaling extension
 
 The manualScaling extension configures the number of replicas of a compute instance (such as a container) to run. Refer to the [container resource schema]({{< ref "container-schema#extensions" >}}) for more details.
 
-#### Dapr sidecar extension
+### Dapr sidecar extension
 
 The `daprSidecar` extensions adds and configures a [Dapr](https://dapr.io) sidecar to your application. Refer to the [container resource schema]({{< ref "container-schema#extensions" >}}) for more details
 
-## Resource schema 
-
-- [Container schema]({{< ref container-schema >}})
-
 ## Further reading
 
-{{< categorizeby category="How-To" tag="containers" >}}
+- [Container schema]({{< ref container-schema >}})