Creating and Running Containers

Container Creation Workflow

To launch a new container, open Console → Containers and click Create Container.

The provisioning process consists of 5 straightforward steps:

1. Container Name: Set a unique resource name for the container within your project.
2. Select OCI Image: Pick a pre-registered image in the Ready status.
3. Execution Parameters: Configure the entrypoint command, runtime arguments, environment variables, and restart policy.
4. Attach Persistent Storage (Optional): Select a volume for the Stateful OverlayFS root layer. Without a volume the container runs with a read-only root filesystem.
5. Bind VPC Network Interface (Required): Assign a dedicated private IP address in your project’s VPC.

Configuration Parameters

1. Container Name

Specify a unique resource name within your project (e.g., api-gateway-01).

2. OCI Image Selection

Choose an OCI image in the Ready state (see Container Images).

3. Command & Environment Variables

• Command: Binary entrypoint path (e.g., /usr/bin/python3 or nginx).
• Args: Command-line arguments (e.g., -m http.server 8080 or -g "daemon off;").
• Environment: Key-value pairs in KEY=value format, one per line.
• Restart Policy:
  • always (default) — automatically restarts on any exit code.
  • on_failure — restarts only if the exit code is non-zero.
  • never — disables automatic restarts.

4. Data Volumes (Persistent Storage)

[!NOTE] Attaching a volume is optional. With one or more unattached volumes, the first one becomes the persistent storage layer for Stateful OverlayFS: all filesystem writes made during execution are saved to this disk.

Without a volume the container has no writable disk: the root filesystem is mounted read-only (the image is immutable), only tmpfs (/tmp, /run) is writable, and data is lost on restart. This fits stateless workloads (stateless APIs, workers, proxies).

5. VPC Network Interfaces

[!IMPORTANT] Attaching at least one unattached network interface is required. The container is always created with a dedicated static private IP address in your VPC.

Select an available NetworkInterface from your VPC to assign a dedicated static private IP address to the container.

Provisioning via REST API

Automate container deployments using the Selene REST API:

curl -X POST "https://api.microsrv.ru/api/v1/projects/${PROJECT_ID}/containers" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "region_id": "ru-central1",
    "flavor_id": "flavor-std-2",
    "image_id": "img-nginx-alpine-ulid",
    "name": "web-proxy-01",
    "command": ["nginx"],
    "args": ["-g", "daemon off;"],
    "env": {
      "PORT": "8080",
      "NODE_ENV": "production"
    },
    "restart_policy": "always",
    "volume_ids": ["vol-01j9a4k..."],
    "network_interface_ids": ["ni-01j9a4m..."]
  }'

Networking & Ingress

1. Internal VPC Communication: Containers communicate with other containers and VMs via private IP addresses (10.x.x.x).
2. Outbound Internet Egress: Containers access external dependencies, Git repositories, and APIs through eBPF Outbound NAT without needing a public IP address.
3. Inbound web traffic: publish a container port through the HTTPS gateway with a <name>.msrv.space hostname and a TLS certificate.
4. In-cluster DNS: every container gets a <container-name>.msrv.internal name, resolved by the VPC gateway DNS (e.g. 10.0.0.1) to its private IP, so workloads in the same VPC can reach it by name.

Lifecycle Management

• Detail Inspection: Access /console/containers/<id> to review sandbox state, attached volumes, and IP allocations.
• Resizing: Update container configuration dynamically via API (PATCH /api/v1/containers/<id>).
• Deletion: Deleting a container releases compute vCPU/RAM and network interfaces; the attached NVMe volumes persist and can be attached to new workloads.

Next Steps

• Containers Overview
• Stateful OverlayFS & Storage
• Container Live Migration
• VPC Network Interfaces