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:


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_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.



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.



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