compose.yaml

Beaker Studio searches for a compose.yaml file in the root of your Git repository, and then interprets it to build containers and run deployments. This is a reference of how Beaker Studio interprets that file.

If Beaker Studio cannot find a compose.yaml file, then it will look for compose.yml, docker-compose.yaml, and docker-compose.yml in that order.

Build

Beaker Studio mostly uses compose.yaml files as-is when building Docker images. It also uses the standard docker-compose build command to maximize compatibility. Beaker Studio may only modify the compose.yaml file in a few ways:

• Formatting changes from parsing.
• Prunes services that are not being deployed.
• The depends_on option is removed if present on services.
• Image names may be added for tagging purposes.

After images are built, Beaker Studio tags and pushes them to a private docker image repository for your environment.

Runtime

In order to deploy the built containers as production-ready servers, Beaker Studio has to interpret relevant settings from the compose.yaml file. Here are the various settings used at runtime:

• Top-level services:

  • command: Works like standard.
  • entry_point: Works like standard.
  • init: Works like standard.
  • ports: Works like standard. Beaker Studio gives additional options.
  • privileged: Works like standard.
  • user: Works like standard.
  • volumes: Only deploys when mount type is "volume". Beaker Studio gives additional options.
  • working_dir: Works like standard.

• The top-level volumes map is only checked to see if a named volume exists for a service mount.