Stacks Manifest Reference

Stacks are designed for developers who don't want to deal with the complexities of Kubernetes manifests. Define your application using a docker-compose like format.

Example

name: voting-app
services:
  vote:
    public: true
    image: okteto/vote:stacks
    build: vote
    replicas: 2
    ports:
      - 8080
    resources:
      cpu: 100m
      memory: 128Mi

  redis:
    image: redis
    ports:
      - 6379
    resources:
      cpu: 100m
      memory: 128Mi
      storage: 1Gi
    volumes:
      - /data

The equivalent Kubernetes manifests would have more than 200 lines of yaml!

Schema reference

name (string, required)

The name of your Stack.

name: voting-app

namespace (string, optional)

The namespace where you want to deploy your Stacks. By default, it takes the current kube config namespace.

namespace: development

services ([object], optional)

Define the services that make up your application so they can be run together when the Stack is deployed.

Each service has the following properties:

annotations ([string], optional)

Specify annotations for the service.

annotations:
  dev.okteto.com/auto-ingress: "private"

args (string, optional)

Override the default image CMD.

args: --debug

The args can also be a list of string:

args: ["-p", "3000"]

build ([string|object], optional)

Indicate that the image of this service must be built when running okteto stack deploy --build. The value can be the path to the build context:

build: vote

or an object that supports these fields:

• context: the build context that is sent to BuildKit. When the value supplied is a relative path, it is interpreted as relative to the location of the stack manifest file (default: .)
• dockerfile: the path to the Dockerfile. It is a relative path to the build context (default: Dockerfile)
• target: build the specified stage as defined inside the Dockerfile. See the multi-stage build Docker official docs for details.
• args: add build arguments, which are environment variables accessible only during the build process. Build arguments with a value containing a $ sign are resolved to the environment variable value on the machine okteto is running on, which can be helpful for secret or machine-specific values.

build:
  context: .
  dockerfile: Dockerfile
  target: prod
  args:
    - ENV1=prod
    - ENV2=$VALUE

okteto stack deploy --build builds a new docker image, pushes it to the registry and redeploys your containers. By default, images are built using the Okteto Build Service. Set the variable BUILDKIT_HOST if you want to use your own BuildKit instance.

cap_add ([string], optional)

Add container capabilities. See man 7 capabilities for a full list.

cap_add:
  - ALL

cap_drop ([string], optional)

Drop container capabilities. See man 7 capabilities for a full list.

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

command (string, optional)

Override the default image ENTRYPOINT.

command: bundle exec thin -p 3000

The command can also be a list of string:

command: ["bundle", "exec", "thin", "-p", "3000"]

env_file ([string], optional)

Add environment variables from files. Environment variables declared in the environment section override these values. This also holds true if those values are empty or undefined.

env_file:
  - .env

environment ([string], optional)

Add environment variables. Specify them as an array of strings:

environment:
  - DEV_MODE=yes
  - DB_HOST=postgres://${DB_HOST:-db}:${DB_PASSWORD}@postgres:5432/postgres

image (string, required)

The container image of each service.

image: okteto/vote:stacks

labels ([string], optional)

Specify labels for the service.

labels:
  app: sample

ports ([int], optional)

Ports exposed by each service. By default, they are only accessible from the cluster private network.

ports:
  - 8080

public (bool, optional)

If the service should be exposed via a public endpoint or not (default: false).

public: true

replicas (bool, optional)

Specify the number of containers that should be running for each service (default: 1).

replicas: 2

resources (object, optional)

Configures resource constraints. For example, to configure a service with 300 mili cpus, 500Mi of memory and 5Gi of storage:

resources:
  cpu: 300m
  memory: 500Mi
  storage: 5Gi

storage also accepts an extended notation to specify the storage class of the persistent volume created for a service:

resources:
  cpu: 300m
  memory: 500Mi
  storage:
    size: 5Gi
    class: standard

stop_grace_period (int, optional)

Specify how long to wait (in seconds) when attempting to stop a container before sending SIGKILL

stop_grace_period: 10

volumes ([string], optional)

List of persistent volumes mounted on the containers of each service.

volumes:
  - /data