Bunnyshell seamlessly integrates with Kubernetes clusters and Image Registries from major cloud providers, while also leveraging a number of proven tools, such as Helm and Terraform, to create an efficient workspace for developers.
To be able to create environments on demand, Bunnyshell only requires:
- a Kubernetes cluster to be connected
- access to your Git repository.
Access to your Image Registry is optional, since you can use the registry provided by Bunnyshell to store container images.
Also, access to your Git repository is not needed if the build is performed outside Bunnyshell.
Bunnyshell connects to your Kubernetes cluster via its API. This is why the clusters need to either be publicly exposed, or have Bunnyshell IPs whitelisted.
Parameters needed for connecting to the Kubernetes cluster are dependent on the cloud provider. However, in most cases, the following parameters are required:
- The endpoint of the cluster
- The certificate
- An admin token / a user and password (or similar) pair of credentials
Bunnyshell stores the definition of an environment in a YAML format, in a file called
All subsequent changes for the respective Environment's definition can be made either through the UI, or by editing the
bunnyshell.yaml. You can build up the
bunnyshell.yaml by adding components, from:
- Helm charts
- Kubernetes manifests
- Terraform Modules
- various scripts within your repository or contained in docker images
The environment definition
bunnyshell.yamlfile is stored for now exclusively in Bunnyshell.
Ephemeral Environments can be created automatically, triggered by Git webhooks.
Bunnyshell installs webhooks for each repository into your Git Provider when the Git Account is connected.
When you perform an action in Git, Bunnyshell receives a webhook from your Git Provider, and decides if it needs to act upon it or not.
An Ephemeral Environment will be created when a Pull Request is created if:
- The environment contains one or more components belonging to the PR's repository
- The target branch of the PR is deployed for the respective component(s)
- The Create ephemeral environments on pull request setting is set to ON on the Primary Environment.
When created automatically, an Ephemeral Environment is always based on a Primary Environment, that it uses as a template. It is essentially, a clone of the respective environment, having the branch(es) changed for the component(s) which matched the Pull Request.
The sequence in which the deploy is executed is controlled by the
dependsOn attribute, specified at the component level.
All component deployments which do not depend on others will be started as soon as possible, and will be ran in parallel. This is a principle in the way workflows are handled in Bunnyshell.
Some other relevant mentions follow.
The build is performed in a Kubernetes cluster, using Kaniko. The cluster can be either managed by you or by Bunnyshell, depending on what you chose in the Build Settings of the Primary Environment.
Built images are pushed into the Image Registry chosen for the respective Environment. This registry can be either the one managed by Bunnyshell, or your own (previously connected) registry.
The DNS records are created for each component's Kubernetes Ingress endpoints, after each is deployed (manifests applied). Only Ingresses with a given class are considered for automatic URL creation.
For each Docker-compose components (Application, Database, Service), a Kubernetes manifest is generated which will be applied independently of other components.
Bunnyshell creates the needed Kubernetes resources: Pods, Deployments, Services, Ingress, Persistent Volume Claims and Network Policies.
The DNS records are created for all components' Kubernetes Ingress endpoints (defined under
hosts in the
bunnyshell.yaml Component), after the manifest is applied.
Notifications are sent to users, and after that the Environment enters the Running state.
Communication between namespaces is by default prevented when Docker-compose components are present, but it is up to you if you wish to disable this restriction.
All environments can be started and stopped manually. They can also be subject to a defined schedule, at a Project or Environment level.
Kubernetes Deployments for Docker-compose components (Application, Database, Service) resources are scaled to 0(zero) replicas, while for the rest of the components you can define what stopping a component will execute.
Ephemeral Environments can be destroyed automatically by Bunnyshell when a Pull Request is either merged or closed, depending on the Environment settings.
All resources associated with an Environment are destroyed once an Environment is deleted:
- Docker-compose components: the whole namespace is deleted
- Helm, Kubernetes manifests, Terraform,Generic components: the
destroyscripts are executed, all in parallel.
Updated about 2 months ago