Okteto Manifest Reference

okteto.yml is a manifest format for describing development environments. It declares the deployment target, the dev container, the working directory and other information required to activate your development environment with okteto.

Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
name: vote
labels:
app.kubernetes.io/part-of: vote
app.kubernetes.io/component: api
image: python:3
command: ["python", "app.py"]
workdir: /usr/src/app
environment:
- name=$USER
- environment=development
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
forward:
- 8080:80
- 8080:90

Schema reference

name (string, required)

The name of your development environment. If labels is not defined, it is also the name of the kubernetes deployment you want to transform into a development environment.

labels (map[string]string, optional)

The labels of the kubernetes deployment you want to transform into a development environment. They must identify a single kubernetes deployment.

container (string, optional)

The name of the container in your deployment you want to transform into a development environment. By default, it takes the first one.

namespace (string, optional)

The namespace of the deployment you want to transform into a development environment. By default, it takes the current kube config namespace.

image (string, optional)

Sets the container image of your development environment. Defaults to the image specified in your deployment.

command ([string], optional)

Sets the command of your development environment. By default, it creates an sh terminal.

workdir (string, optional)

Sets the working directory of your development environment.
If mountpath is not specified, workdir also specifies the mount path of your local folder in your development environment.

mountpath (string, optional)

Sets the mount path of your local folder in your development environment (default: /okteto).

subpath (string, optional)

Sets a relative subpath of your local folder to mount in your development environment, instead of mounting the root of your local folder.

environment ([string], optional)

A list of environment variables that will be injected into your development environment. If a variable already exists on your deployment, it will be overridden with the value specified on the manifest.

Environment variables with only a key, or with a value that starts with a $ sign are resolved to their values on the machine okteto is running on, which can be helpful for secret or machine-specific values.

1
2
3
4
5
6
...
environment:
- environment=development
- name=$USER # will be replaced by the value of $USER
- DBPASSWORD # will be given the value of $DBPASSWORD if it exists
...

volumes ([string], optional)

A list of paths in your development environment that you want to associate to persistent volumes. This is useful to persist information between okteto up executions, like downloaded libreries or cache information. For example, to speed your golang builds up, you could define:

1
2
3
4
5
...
volumes:
- /go/pkg/
- /root/.cache/go-build/
...

resources (object, optional)

Allows you to override the resources configuration of your development environment. It supports the same syntax used in Kubernetes. By default, requests and limits are unset.

forward ([string], optional)

A list of ports to forward from your development environment. The list should follow the localPort:remotePort notation and each element should be unique.

1
2
3
4
5
...
forward:
- 8080:80
- 8090:8090
...

Once your development environment is up and running, you will be able to access the port directly by using localhost:localPort.

Common uses of port forwarding are:

  1. Access a service via localhost instead of via an ingress
  2. Get direct access to a service that’s not exposed via a service (e.g. a queue consumer)
  3. Connect to a hot reloader via a websocket
  4. Remote debugging

If Okteto can’t forward a port (typically because they are already taken), an error will be logged in the console.

services ([object], optional)

A list of other containers (other than the main one) that you want to put in developer mode. The difference with the main container and the ones defined in this section is that the main container is transformed into an interactive session, where you can, for example, execute a shell. The containers defined in this section run in detached mode, but they can also mount your local folder in a particular path.

For example, to put a Django application in developer mode you could use the following manifest:

1
2
3
4
5
6
7
name: web
workdir: /app
command: ["python", "manage.py", "runserver", "0.0.0.0:8080"]
services:
- name: worker
workdir: /app
command: ["celery", "worker", "-A", "myproject.celeryconf", "-Q", "default", "-n", "[email protected]%h"]

and both deployments, web and worker will mount your local folder into the path /app.

The supported keys for containers defined in this section are:

  1. name
  2. labels
  3. container
  4. namespace
  5. image
  6. environment
  7. command
  8. workdir
  9. mountpath
  10. subpath
  11. resources

They work the same as for the main container, except for the command and name keys. For services, command defaults to the command specified in your deployment, instead of sh. labels and name are mutually exclusive (for the main container, name is mandatory).