Volumes for docker-compose
Helmcomponents will not be interfered with. They will work exactly as defined.
This article refers to Docker-compose components only:
Bunnyshell enables you to define persistent volumes and attach them to nodes/pods using the
PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a
It is a resource in the cluster just as how a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. Read more about Volumes on the official Kubernetes documentation platform.
Types of Bunnyshell volumes
There are two types of volumes users can define in Bunnyshell:
- Disk volumes: persistent volumes with
Such volumes can be attached to a single Kubernetes node.
- Network volumes: persistent volumes with
Such volumes can be attached to multiple Kubernetes nodes.
- An existing Bunnyshell environment
- An existing Kubernetes cluster connected to Bunnyshell
- Make sure you have created the necessary storage classes
Disk and Network volumes
- Are persistent
- Can have configurable sizes and names
- Support subpaths on mount
Volumes that are not claimed by an environment / component will be removed.
For all persistent volumes, the file mode will be 0777. File modes are set by init containers. Each pod has an init container that modifies permissions for all volumes.
Before the pod container starts, the init container executes a
chown 0777on all those volumes.
volumes key may be added at both the environment level and the component level. Below we will list the volumes for each of the cases.
At an Environment level, Volumes are declared, while at the Component level, they are used (mounted).
Declaring volumes in Environments
At the Environment level,
volumes are created for the Docker-compose Components (
Service) to use.
- name: the name of the volume. This field is mandatory;
- size: the size of the volume. This field is mandatory;
- type: the volume type mapped to Kubernetes cloud volume types. The following options are available:
- disk: can be attached to a single Node;
- network: can be attached to multiple Nodes.
Volumes are isolated at the environment level.
This means that if two
bunnyshell.yamlconfigs declare volumes with the same name, Bunnyshell will add the unique ID of their respective environments to their name, making them unique.
Using volumes in Components
At the Component level, the
volumes property will contain claims to volumes defined at the environment level. It contains the following properties:
- name: the name of the volume claimed. This field is mandatory;
- mount: the path where to mount the volume in the component. This field is mandatory;
- subPath: Path of what to mount into the component.
Volumes will be mounted inside Components based on this spec.
Validations and constraints
- Volume names must be unique. Two volumes can not have the same name;
- The name must consist of lower case alphanumeric characters. It can also contain hyphens
-, but it must start and end with an alphanumeric character (e.g. 123-abc).
- The volume type must be either
- The volume size must be greater than zero (any float number is accepted);
- The volume size syntax must be composed of two (case sensitive) parts :
unit. Unit is a memory unit like Gi.
'KB', 'MB', 'GB', 'TB', 'b', 'Gi';
An environment volume must be used by a container, otherwise Bunnyshell will show errors.
- The name must belong to one of the volumes declared at the environment level, otherwise Bunnyshell will show errors;
- The mount field must include a directory path where to mount the volume, in linux format (e.g.
- The name must consist of lower case alphanumeric characters. It can also contain hyphens -, but it must start and end with an alphanumeric character (e.g. 123-abc).
- Two volumes declared at the component level can not be mounted in the same path. The mount path must be unique in list.
All volumes declared in docker-compose will be interpreted as persistent volumes and will have a default size of 1Gi after parsing. These volumes can be found at environment level (declared) or requested by Docker-compose components, pods, init containers or sidecar containers.
docker-compose.yamlhas a different definition compared to the
Here's an example of a volume declared in docker-compose.
services: nginx: image: nginx volumes: - database_volume
And this is how it will be transformed in
kind: ... ... components: - name: nginx volumes: - name: database_volume mount: /var/db volumes: - name: database_volume type: disk size: 1Gi
Conversion from Docker-compose - Considerations
- Bunnyshell ignores volumes that are not used by any services (root directive identation 0 in
- Bunnyshell ignores bind and tmpfs Volumes, as well as any local bind that does not use a volume defined under the global key
- Volume names will be random values when only the target is defined, as a string.
- If the
StorageClasswas already added in a cluster that was previously connected to Bunnyshell, the user must wait until the cluster is verified to determine whether or not a needed storage class exists.
- If a volume is attached to several separate services in
docker-compose.yaml, or if it is mounted several times inside the same service, it will be migrated as a network volume.
- The default size is 1Gi.
- When adding an application that has a volume name already existing inside the environment, a random string will be added to the Volume name to make it unique.
# all volumes are persistent # if you don't need persistance, don't use a mount path # - the only thing that might not make sense here, is breaking out of the container resource pool # - I.E. backend php with 1GB disk space having an external mount of 5G volumes: - type: network # means ReadWriteMany name: logs-all size: 10Gi - type: disk # means ReadWriteOnce # passes validation if used by only 1 ServiceComponent # passes validation if used by any Init/Sidecar name: data-mysql size: 3Gi components: - name: mysql volumes: # now we have a persistent database # what we lack is a way to "kickoff" the database - name: data-mysql mountPath: /var/lib/mysql pod: init_container: # this init_container needs to: # 1. be able to init mysql data # 2. detect if init has already took place # 3. not force the volume to become a network volume - name: init-mysql-data mounts: - name: data-mysql mountPath: /var/lib/mysql - name: nginx volumes: - name: logs-all mount: /var/log/nginx subPath: /nginx - name: monitor volumes: - name: logs-all mount: /opt/logs pod: sidecar_container: - name: log-rotate volumes: - name: logs-all mountPath: /opt/logs
Kubernetes Cluster Requirements
In order to be able and create volumes (
PersistentVolumeClaims) for Docker-compose components, Bunnyshell needs to have its own, dedicated
StorageClasses created in the Kubernetes cluster.
StorageClassprovides a way for administrators to describe the "classes" of storage they offer.
Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators.
More information on the StorageClass concept is available on the official Kubernetes documentation.
Updated 23 days ago