Skip to content

Commit

Permalink
Update containers page in developer guides (#630)
Browse files Browse the repository at this point in the history 
* Refine containers page

* Empty commit

* Address feedback

* Address feedback

* Apply suggestions from code review

Co-authored-by: Aaron Crawfis <[email protected]>

* Update docs/content/author-apps/container/index.md

* Update image description

* Update docs/content/author-apps/container/index.md

Co-authored-by: Aaron Crawfis <[email protected]>

* Update docs/content/author-apps/container/index.md

Co-authored-by: Aaron Crawfis <[email protected]>

* Address comments

---------

Co-authored-by: Aaron Crawfis <[email protected]>
  • Loading branch information
@Reshrahim @AaronCrawfis
Reshrahim and AaronCrawfis authored Jun 30, 2023
1 parent 591714c commit 2c2c260
Show file tree
Hide file tree
Showing 4 changed files with 82 additions and 63 deletions.
4 changes: 3 additions & 1 deletion .github/config/en-custom.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -419,4 +419,6 @@ ePMKNy
gg
kubernetesMetadata
daprSidecar
manualScaling
manualScaling
httpGet
tcp
91 changes: 78 additions & 13 deletions docs/content/author-apps/container/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,32 +4,97 @@ title: "Containerized workloads"
linkTitle: "Containers"
description: "Model and run container workloads in your Radius application"
weight: 300
categories: "Concept"
categories: "Overview"
tags: ["containers"]
---

A Radius container represents a container workload within your application.
## Overview

## Example
A Radius container provides an abstraction to model and run your container workloads as part of your Radius application.

{{< tabs Bicep >}}

{{% codetab %}}
See the [Bicep authoring guide]({{< ref bicep >}}) for more information.
{{< rad file="snippets/container.bicep" embed=true marker="//CONTAINER" >}}
{{% /codetab %}}

{{< /tabs >}}
## Supported runtimes

Containers are run on the same Kubernetes cluster as your [Radius installation]({{< ref platforms >}}). We plan to support additional container runtimes and configurations in the future

## Capabilities

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).

### Image

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.

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 "/operations/platforms/kubernetes/supported-clusters#configure-container-registry-access" >}}).

### Ports

Ports allow you to expose your container to incoming network traffic. Refer to the [networking guide]({{< ref networking >}}) for more information on container networking.

### Volumes

The volumes mounted to the container, either ephemeral or persistent, are defined in the volumes section.

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

#### 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.

For an **httpGet** probe, an HTTP GET request at the specified endpoint will be used to probe the application. If a success code is returned, the probe passes. If no code or an error code is returned, the probe fails, and the container won’t receive any requests after a specified number of failures. Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

For a **tcp** probe, the specified container port is probed to be listening. If not, the probe fails.

For an **exec probe**, a command is run within the container. A return code of 0 indicates a success and the probe succeeds. Any other return indicates a failure, and the container doesn’t receive any requests after a specified number of failures

Refer to the readiness probes section of the [container resource schema]({{< ref "container-schema#readiness-probes" >}}) for more details.

#### 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.

For an **httpGet probe**, an HTTP GET request at the specified endpoint will be used to probe the application. If a success code is returned, the probe passes. If no code or an error code is returned, the probe fails, and the container won’t receive any requests after a specified number of failures. Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

For a **tcp probe**, the specified container port is probed to be listening. If not, the probe fails.

For an **exec probe**, a command is run within the container. A return code of 0 indicates a success and the probe succeeds. Any other return indicates a failure, and the container doesn’t receive any requests after a specified number of failures.

Refer to the probes section of the [container resource schema]({{< ref "container-schema#liveness-probes" >}}) for more details.

### Connections

Connections enable communication between your container and other resources, such as databases, message queues, and other services. A connection injects information about the resource you connect to as environment variables. This could be connection strings, access keys, password or other information needed for communication between the container and the resource it connects to. It also enables you to configure the RBAC permissions for the container to access the resource.

Refer to the [connections schema] for containers({{< ref "container-schema#connections" >}}) for more details.

### Extensions

Extensions define additional capabilities and configuration for a container.

#### 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

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.

## Platform resources
#### Dapr sidecar extension

Depending on the target environment and configuration, a container can be run on a variety of platforms leveraging Kubernetes as the container runtime.
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

## More information
## Resource schema

- [Container schema]({{< ref container-schema >}})

## Other guides
## Further reading

{{< categorizeby category="Quickstart" tag="containers" >}}
{{< categorizeby category="How-To" tag="containers" >}}
18 changes: 0 additions & 18 deletions docs/content/author-apps/container/snippets/container.bicep
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,24 +21,6 @@ resource container 'Applications.Core/containers@2022-03-15-privatepreview' = {
containerPort: 80
}
}
volumes: {
tmp: {
kind: 'ephemeral'
managedStore: 'memory'
mountPath: '/tmp'
}
}
}
extensions: [
{
kind: 'daprSidecar'
appId: 'mycontainer'
}
]
connections: {
statestore: {
source: statestore.id
}
}
}
}
Expand Down
32 changes: 1 addition & 31 deletions docs/content/reference/resource-schema/core-schema/container-schema/_index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,10 +8,6 @@ weight: 300

`Container` provides an abstraction for a container workload that can be run on any platform Radius supports.

## Platform resources

Containers are hosted by Kubernetes as the container runtime today, regardless of which platform the application is deployed into. We plan to support additional container runtimes in the future.

## Resource format

{{< rad file="snippets/container.bicep" embed=true marker="//CONTAINER" >}}
Expand All @@ -35,11 +31,9 @@ Containers are hosted by Kubernetes as the container runtime today, regardless o

### Container

Details on what to run and how to run it are defined in the `container` property:

| Key | Required | Description | Example |
|------|:--------:|-------------|---------|
| image | y | The registry and image to download and run in your container. | `'myregistry/myimage:tag'`
| image | y | The registry and image to download and run in your container. Follows the format `<registry-hostname>:<port>/<image-name>:<tag>` where registry hostname is optional and defaults to the Docker public registry, port is optional and defaults to 443, tag is optional and defaults to `latest`.| `myregistry.azurecr.io/myimage:latest`
| env | n | A list of environment variables to be set for the container. | `'ENV_VAR': 'value'`
| command | n | Entrypoint array. Overrides the container image's ENTRYPOINT. | `['/bin/sh']`
| args | n | Arguments to the entrypoint. Overrides the container image's CMD. | `['-c', 'while true; do echo hello; sleep 10;done']`
Expand All @@ -62,12 +56,6 @@ The ports offered by the container are defined in the `ports` section.

#### Volumes

The volumes mounted to the container, either ephemeral or persistent, are defined in the `volumes` section.

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 lifecycles 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.

| Key | Required | Description | Example |
|------|:--------:|-------------|---------|
| name | y | A name key for the volume. | `tempstore`
Expand All @@ -79,14 +67,6 @@ Persistent volumes have lifecycles that are separate from the container. Contain

#### 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`. For an `httpGet` probe, an HTTP GET request at the specified endpoint will be used to probe the application. If a success code is returned, the probe passes. If no code or an error code is returned, the probe fails, and the container won't receive any requests after a specified number of failures.
Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

For a `tcp` probe, the specified container port is probed to be listening. If not, the probe fails.

For an `exec` probe, a command is run within the container. A return code of 0 indicates a success and the probe succeeds. Any other return indicates a failure, and the container doesn't receive any requests after a specified number of failures.

| Key | Required | Description | Example |
|------|:--------:|-------------|---------|
| kind | y | Type of readiness check, `httpGet` or `tcp` or `exec`. | `httpGet`
Expand All @@ -99,14 +79,6 @@ For an `exec` probe, a command is run within the container. A return code of 0 i

#### 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`. For an `httpGet` probe, an HTTP GET request at the specified endpoint will be used to probe the application. If a success code is returned, the probe passes. If no code or an error code is returned, the probe fails, and the container won't receive any requests after a specified number of failures.
Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.

For a `tcp` probe, the specified container port is probed to be listening. If not, the probe fails.

For an `exec` probe, a command is run within the container. A return code of 0 indicates a success and the probe succeeds. Any other return indicates a failure, and the container doesn't receive any requests after a specified number of failures.

| Key | Required | Description | Example |
|------|:--------:|-------------|---------|
| kind | y | Type of liveness check, `httpGet` or `tcp` or `exec`. | `httpGet`
Expand All @@ -119,8 +91,6 @@ For an `exec` probe, a command is run within the container. A return code of 0 i

### Connections

Connections define how a container connects to [other resources]({{< ref resource-schema >}}).

| Key | Required | Description | Example |
|------|:--------:|-------------|---------|
| name | y | A name key for the port. | `inventory`
Expand Down

0 comments on commit 2c2c260

Please sign in to comment.