Skip to main content

Provider Agent

When DevPod connects through a Provider to an environment, it will inject itself into the environment to handle the following tasks:

  • deploying the container
  • forward credentials
  • ssh server
  • auto-shutdown after a period of inactivity

This counterpart is called the DevPod agent, which is available in the same DevPod binary under devpod agent. Within the provider.yaml you can configure certain parts of how local DevPod should interact with its agent counterpart.

info

Agent's Driver specifies how the whole container workloads is deployed inside the provider's resources.

Head over to the drivers section to understand how this impacts the provider

Agent section​

The following options are available in the agent section

agent: # You can also use options within this section (see injectGitCredentials as an example)
  path: $\{DEVPOD\}
  driver: docker # Optional, default: docker
  inactivityTimeout: 10m
  containerInactivityTimeout: 10m
  injectGitCredentials: ${INJECT_GIT_CREDENTIALS}
  injectDockerCredentials: ${INJECT_DOCKER_CREDENTIALS}
  binaries:
    MY_BINARY:
      - os: linux
        arch: amd64
        path: https://url-to-binary.com
        checksum: shasum-of-binary
  exec:
    shutdown: |-
      ${MY_BINARY} stop

Breaking down the options:

  • path: where to place the agent on the remote machine. Use ${DEVPOD} here if you want to use the local machine instead.
  • driver: which driver to use to run container, check the Drivers section for more information
  • inactivityTimeout: after how much time to shut down the machine. Use for machine providers
  • containerInactivityTimeout: after how much time to shut down the container. Use for non-machine providers
  • injectGitCredentials: whether to inject git credentials into the machine.
  • injectDockerCredentials: whether to inject docker credentials into the machine.
  • exec.shutdown: command to execute when shutting down the machine after DevPod has determined the inactivityTimeout. Option values will be available here as well. For example, you can reuse an option that stores a cloud api key within this command to terminate the machine.
  • binaries: this section can be used to declare additional binaries to download on the machine to use in exec.shutdown
info

The binaries section is useful for injecting a helper binary in the machine, in order to use the specific cloud's APIs to shut down the machine, if a simple shutdown -h now does not work

info

The binaries section follows the same syntax and structure of the binaries section in the main provider manifest

Auto-Inactivity Stop​

One of the most important features of DevPod is to make sure that developer environments use as little resources as possible when they are not used.

Non-Machine Providers​

For non-machine providers, DevPod can automatically kill the container its running in by terminating the process with pid 1. This is useful for providers such as docker, kubernetes or ssh, where you don't want the container to be running if its not needed. The timeout can be configured through agent.containerInactivityTimeout. DevPod will then start a process within the container to keep track of activity and then kill itself when the user hasn't connected for the given duration. This will not erase any state within the container and instead only stop it. Then when the user wants to start working with the workspace again, DevPod will start the container again.

Machine Providers​

For machine providers, killing just the container within the remote machine is typically not enough as VMs still generate costs even if they are unused. Hence DevPod provides a way to configure automatically shutting down or deleting an unused machine on the cloud provider side if a developer is currently not working anymore. DevPod will then restart or recreate it again, when the development should continue.

DevPod tries to make this as easy as possible for you, as it will automatically keep track of when a user is connected to a workspace or not and only needs the command to run when the machine should be stopped from the provider. This command can be defined through agent.exec.shutdown. All configured options are available in this command and helper binaries needed can be defined through agent.exec.binaries

Official providers that use this method of automatically stopping an inactive machine are:

  • devpod-provider-azure: Just uses shutdown -t now as agent.exec.shutdown to shutdown an unused machine.
  • devpod-provider-aws: Uses the local aws cli tool to generate a temporary token, which is then saved in a DevPod option. This token is then used within agent.exec.shutdown to shutdown the machine on the agent side with an AWS api call.
  • devpod-provider-gcloud: Uses the local gcloud cli tool to generate a temporary token, which is then saved in a DevPod option. This token is then used within agent.exec.shutdown to shutdown the machine on the agent side with an Google Cloud api call.
  • devpod-provider-digitalocean: Deletes the whole machine on inactivity as stopped machines are still billed by DigitalOcean. The local digital ocean token is reused on the agent side to make an API call to delete the whole machine and preserve the state in an extra volume.