This is an automated email from the ASF dual-hosted git repository.
grag pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mesos.git
The following commit(s) were added to refs/heads/master by this push:
new b24ab0a Added documentation about standalone containers.
b24ab0a is described below
commit b24ab0a97e0043cb4a06624f7593dec9e15f5661
Author: Joseph Wu <[email protected]>
AuthorDate: Mon Sep 9 10:37:57 2019 -0700
Added documentation about standalone containers.
This outlines some of the differences to expect from this
new type of container and shows some example API calls.
Review: https://reviews.apache.org/r/65112/
---
docs/csi.md | 2 +-
docs/home.md | 1 +
docs/standalone-containers.md | 202 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 204 insertions(+), 1 deletion(-)
diff --git a/docs/csi.md b/docs/csi.md
index 4a83581..aa03175 100644
--- a/docs/csi.md
+++ b/docs/csi.md
@@ -80,7 +80,7 @@ More details about SLRP can be found in the following
[section](#storage-local-r
CSI plugins are long-running [gRPC](https://grpc.io/) services, like daemons.
Those CSI plugins are packaged as containers, and are launched by SLRPs using
-the [standalone containers](standalone-container.md) API from the agent.
+the [standalone containers](standalone-containers.md) API from the agent.
Standalone containers can be launched without any tasks or executors. They use
the same isolation mechanism provided by the agent for task and executor
containers.
diff --git a/docs/home.md b/docs/home.md
index ad19919..4e62b4a 100644
--- a/docs/home.md
+++ b/docs/home.md
@@ -59,6 +59,7 @@ layout: documentation
* [Container Sandboxes](sandbox.md)
* [Container Volumes](container-volume.md)
* [Nested Container and Task Group (Pod)](nested-container-and-task-group.md)
+* [Standalone Containers](standalone-containers.md)
## Networking
* [Networking Overview](networking.md)
diff --git a/docs/standalone-containers.md b/docs/standalone-containers.md
new file mode 100644
index 0000000..1e1e306
--- /dev/null
+++ b/docs/standalone-containers.md
@@ -0,0 +1,202 @@
+---
+title: Apache Mesos - Standalone Containers
+layout: documentation
+---
+
+# Standalone Containers
+
+Traditionally, launching a container in a Mesos cluster involves
+communication between multiple components:
+
+```
+ Container(s)
+ +-----------+ +--------+ +-------+ +----------+
+ | Framework | <-> | Master | <-> | Agent | <-> | Executor |
+ +-----------+ +--------+ +-------+ | `->Task |
+ ^ +----------+
+ | +-------+ +----------+
+ +------> | Agent | <-> | Executor |
+ | +-------+ | `->Task |
+ ... +----------+
+```
+
+Mesos 1.5 introduced "Standalone Containers", which provide an alternate
+path for launching containers with a reduced scope and feature set:
+
+```
+ +-------+ +----------------------+
+ Operator API <-> | Agent | -> | Standalone Container |
+ +-------+ +----------------------+
+```
+
+**NOTE:** Agents currently require a connection to a Mesos master in
+order to accept any Operator API calls. This limitation is not necessary
+and may be fixed in future.
+
+**NOTE:** Standalone containers only apply to the Mesos containerizer.
+For standalone docker containers, use docker directly.
+
+As hinted by the diagrams, standalone containers are launched on single
+Agents, rather than cluster-wide. This document describes the major
+differences between normal containers and standalone containers; and
+provides some examples of how to use the new Operator APIs.
+
+
+## Launching a Standalone Container
+
+Because standalone containers are launched directly on Mesos Agents,
+these containers do not participate in the Mesos Master's offer cycle.
+This means standalone containers can be launched regardless of resource
+allocation and can potentially overcommit the Mesos Agent, but cannot
+use reserved resources.
+
+An Operator API might look like this:
+
+```
+LAUNCH_CONTAINER HTTP Request (JSON):
+
+POST /api/v1 HTTP/1.1
+
+Host: agenthost:5051
+Content-Type: application/json
+
+{
+ "type": "LAUNCH_CONTAINER",
+ "launch_container": {
+ "container_id": {
+ "value": "my-standalone-container-id"
+ },
+ "command": {
+ "value": "sleep 100"
+ },
+ "resources": [
+ {
+ "name": "cpus",
+ "scalar": { "value": 2.0 },
+ "type": "SCALAR"
+ },
+ {
+ "name": "mem",
+ "scalar": { "value": 1024.0 },
+ "type": "SCALAR"
+ },
+ {
+ "name": "disk",
+ "scalar": { "value": 1024.0 },
+ "type": "SCALAR"
+ }
+ ],
+ "container": {
+ "type": "MESOS",
+ "mesos": {
+ "image": {
+ "type": "DOCKER",
+ "docker": {
+ "name": "alpine"
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+The Agent will return:
+
+ * 200 OK if the launch succeeds, including fetching any container images
+ or URIs specified in the launch command.
+ * 202 Accepted if the specified ContainerID is already in use by a running
+ container.
+ * 400 Bad Request if the launch fails for any reason.
+
+**NOTE:** Nested containers share the same Operator API. To launch a nested
+container, the ContainerID needs to have a parent; and no resources may be
+specified in the request.
+
+
+## Monitoring a Standalone Container
+
+Standalone containers are not managed by a framework, do not use executors,
+and therefore do not have status updates. They are not automatically
+relaunched upon completion/failure.
+
+After launching a standalone container, the operator should monitor the
+container via the `WAIT_CONTAINER` call:
+
+```
+WAIT_CONTAINER HTTP Request (JSON):
+
+POST /api/v1 HTTP/1.1
+
+Host: agenthost:5051
+Content-Type: application/json
+Accept: application/json
+
+{
+ "type": "WAIT_CONTAINER",
+ "wait_container": {
+ "container_id": {
+ "value": "my-standalone-container-id"
+ }
+ }
+}
+
+WAIT_CONTAINER HTTP Response (JSON):
+
+HTTP/1.1 200 OK
+
+Content-Type: application/json
+
+{
+ "type": "WAIT_CONTAINER",
+ "wait_container": {
+ "exit_status": 0
+ }
+}
+```
+
+This is a blocking HTTP call that only returns after the container has
+exited.
+
+If the specified ContainerID does not exist, the call returns a 404.
+
+
+## Killing a Standalone Container
+
+A standalone container can be signalled (usually to kill it) via this API:
+
+```
+KILL_CONTAINER HTTP Request (JSON):
+
+POST /api/v1 HTTP/1.1
+
+Host: agenthost:5051
+Content-Type: application/json
+
+{
+ "type": "KILL_CONTAINER",
+ "kill_container": {
+ "container_id": {
+ "value": "my-standalone-container-id"
+ }
+ }
+}
+
+KILL_CONTAINER HTTP Response (JSON):
+
+HTTP/1.1 200 OK
+```
+
+If the specified ContainerID does not exist, the call returns a 404.
+
+
+## Cleaning up a Standalone Container
+
+Unlike other containers, a standalone container's sandbox is not garbage
+collected by the Agent after some time (like other sandbox directories).
+The Agent is unable to garbage collect these containers because there is
+no status update mechanism to report the exit status of the container.
+
+Standalone container sandboxes must be manually cleaned up by the operator and
+are located in the agent's work directory under
+`/containers/<my-standalone-container-id>`.
