diff --git a/.github/config/en-custom.txt b/.github/config/en-custom.txt index 06e0eea34..5285ad7b5 100644 --- a/.github/config/en-custom.txt +++ b/.github/config/en-custom.txt @@ -419,4 +419,6 @@ ePMKNy gg kubernetesMetadata daprSidecar -manualScaling \ No newline at end of file +manualScaling +httpGet +tcp \ No newline at end of file diff --git a/docs/content/author-apps/container/index.md b/docs/content/author-apps/container/index.md index 4547ad008..8a91d8671 100644 --- a/docs/content/author-apps/container/index.md +++ b/docs/content/author-apps/container/index.md @@ -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" >}} diff --git a/docs/content/author-apps/container/snippets/container.bicep b/docs/content/author-apps/container/snippets/container.bicep index ba9c82d07..206065347 100644 --- a/docs/content/author-apps/container/snippets/container.bicep +++ b/docs/content/author-apps/container/snippets/container.bicep @@ -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 - } } } } diff --git a/docs/content/reference/resource-schema/core-schema/container-schema/_index.md b/docs/content/reference/resource-schema/core-schema/container-schema/_index.md index 887b79218..79cde0541 100644 --- a/docs/content/reference/resource-schema/core-schema/container-schema/_index.md +++ b/docs/content/reference/resource-schema/core-schema/container-schema/_index.md @@ -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" >}} @@ -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 `:/:` 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']` @@ -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` @@ -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` @@ -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` @@ -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`