Docker Compose

Docker Compose is one of the methods to create components within [bunnyshell.yaml](environment-definition).

Adding components from a docker-compose.yaml file is straightforward, and it will create one of the 3 environment component types, depending on what's being added.

📘

Important note

The conversion from docker-compose.yaml to bunnyshell.yaml is one-time and one-way.

When the docker-compose.yaml file is being added to the environment, it is parsed and the corresponding bunnyshell.yaml contents is generated, and from that point on, the management of the components will be performed solely from bunnyshell.yaml.

Updating docker-compose.yaml will NOT automatically update bunnyshell.yaml.

Essentially, all 3 kinds operate the same way, with the exception that some room for specific developments was left for Databases (with regards to seeding, for example).

Applications and Services differ only semantically, but operate identically.

Application

Applications are used for (you guessed it...) applications. They are designed to be used for pieces of software in your stack which are written by you and need to be built.
They are translated from Docker Compose services with an image to be built, and must not fall into the Database conditions.

Database

A component will be categorised as a Database if:

• the name of the image or the name of the Docker Compose service contains one of mysql, percona, mariadb, sql, postgre, mongo, clickhouse, database
• it exposes one of the ports 3306, 27017, 5432, 5433, 8123

Service

Services are designed to be used for pieces of software in your stack which are not written by you. A Service is a component translated from Docker Compose which is nor Database nor Application.

Kubernetes Resources

Docker Compose Kubernetes resources are fully managed by Bunnyshell.

For each component, Bunnyshell creates the needed Kubernetes resources, for example:

• dockerCompose.environment will create a Kubernetes ConfigMap
• dockerCompose.ports will create a KubernetesService
• hosts will create a Kubernetes Ingress

Resource cleanup

When updating/changing the Component, some resources may need to disappear, eg. removing all exposed ports will result in the associated Kubernetes Service to disappear.

The platform adds a label (app.bunnyshell.com/deploy-version) on each resource with every deployment. After a deployment is completed, resources which have a different value for app.bunnyshell.com/deploy-version will be deleted.

Resources not managed by Bunnyshell (not having the app.kubernetes.io/instance-${componentName}=bns label) will be left untouched.

Memory and CPU

For Docker Compose components, resources for the Application component (the container running in a Pod) can be set through the dockerCompose.deploy property of each Component. You can set a minimum and a maximum (reservations and limits).

-
    kind: Application
    name: api
    ...
    dockerCompose:
        deploy:
            resources:
                limits:
                    cpus: '2'
                    memory: '10000M'
                reservations:
                    cpus: '0.50'
                    memory: '5000M'

Health checks using Kubernetes probes

To ensure your application is up and running at all times, you can configure health checks for both startup and running phases. These can be implemented in the form of Kubernetes probes.

Please see the dedicated Health checks for Docker Compose section.

CronJobs

Please see the dedicated CronJobs for Docker Compose section.

Volumes

Please see the dedicated Volumes for Docker Compose section.

Horizontal Pod Autoscaling

Please see the dedicated HPA for Docker Compose section.

Example

Bunnyshell allows the docker compose service syntax in the componentdockerCompose field, with some exceptions, and below is an example with a rich component configuration

-
        kind: Application
        name: my-app
        gitRepo: 'https://gitlab.com/example/my-app.git'
        gitBranch: master
        gitApplicationPath: /
        dockerCompose:
            build:
                context: .
                dockerfile: ./Dockerfile
                target: prod
                args:
                    NOM_TOKEN: '{{env.varGroups.app.NPM_TOKEN}}'
            environmentVariablesGroups:
                - var-group-1
                - var-group-2
            environment:
                MY_VAR: value
                OTHER_VAR: 2
            entrypoint: /bin/sh
            command:
                - -c
                - 'echo "starting..." && ./myscript.sh"
            ports:
                - '80:8080'
            deploy:
                replicas: 3
                resources:
                    limits:
                        cpus: '2'
                        memory: '10000M'
                    reservations:
                        cpus: '0.50'
                        memory: '5000M'
        volumes:
            -
              name: database_volume
              mount: /var/db
            -
              name: misc_volume
              mount: /tmp/stuff
              subPath: /stuffA
        hosts:
            -
                hostname: 'app-{{env.base_domain}}'
                path: /
                servicePort: 80