How Bunnyshell works
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
Creating Primary Environments
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
- Terrafrom Modules
- various scripts within your repository or contained in docker images
The environment definition
bunnyshell.yamlfile is stored for now exclusively in Bunnyshell.
Creating Ephemeral Environments
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 deployment workflow is the most complex in the lifecycle of an Environment, so let's break it down after we take a look at the deployment flow diagram.
Containers Image Building & Terraform applying
When deploying an environment, the first (meaningful) step includes building the container images and applying the Terraform modules.
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.
Images are then 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.
Terraform modules will be applied in parallel with the images being built.
Helm charts, Kubernetes manifests, Generic Components (scriptable components)
Between these 3 component kinds, they are taken in the order in which they appear in
bunnyshell.yaml and are deployed in sequence. The scripts within the `deploy property of the component are also ran in sequence, and any failure in one of them (exit code > 0) will cause the entire flow to fail.
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 all Docker-compose components (Application, Database, Service), a single Kubernetes manifest is generated which will be applied in one go.
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.
Terraform-created resources are not affected by stopping the Environment they're part of.
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
- Terraform resources: destroyed
- Helm Charts, Kubernetes manifests, Generic components: the
destroyscripts are executed, all in parralel.
Updated 23 days ago