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 the 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:

BACKEND_BUILD_TARGET=dev
FRONTEND_BUILD_TARGET=dev
BACKEND_URL=http://books-api.local.bunnyshell.com:3080
FRONTEND_URL=http://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.

BACKEND_BUILD_TARGET=prod
FRONTEND_BUILD_TARGET=prod
BACKEND_URL="https://{{ components.backend.ingress.hosts[0] }}"
FRONTEND_URL="https://{{ 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.

📘

Note

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

👍

Note

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