Best practices for docker-compose

Using sensible defaults for Env Vars

Using docker-compose for local development is common practice. That's why we chose to implement Environment creation based on it.

Furthermore, your flow should not be disturbed. That's why we support using a separate .env.bunnyshell for you to be able to define sensible defaults for defining Environments in Bunnyshell.

For example, the development .env for the Bunnyshell Demo app looks like this:

; .env.sample
BACKEND_BUILD_TARGET=dev
FRONTEND_BUILD_TARGET=dev
BACKEND_URL=http://books-api.local.bunnyshell.com:3080
FRONTEND_URL=http://books.local.bunnyshell.com
FRONTEND_VIRTUAL_HOST=books.local.bunnyshell.com

On the other hand, the one for Bunnyshell has some parametrised URLs, in order to be compatible with generating any number of environments, on future-determined URLs.

; .env.bunnyshell
BACKEND_BUILD_TARGET=prod
FRONTEND_BUILD_TARGET=prod
BACKEND_URL="https://{{ components.backend.ingress.hosts[0] }}"
FRONTEND_URL="https://{{ components.frontend.ingress.hosts[0] }}"
FRONTEND_VIRTUAL_HOST="{{ components.frontend.ingress.hosts[0] }}"

Resilience to order of deployment

There is no depends_on concept in Kubernetes. Pods (and containers) start as soon as they can.

So it's up to the Application to be resilient to this type of behaviour.

We provide additional (advanced) mechanisms to handle this, using the pod property for components in env.yaml, which allows the use of Init- and Sidecar- containers.

You can also tinker with your images and create custom entrypoints to achieve waiting between Services.