How Bunnyshell works

Suggest Edits

Introduction

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.

  

Deployment target

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

 

Environments lifecycle

Creating Primary Environments

Bunnyshell stores the definition of an environment in a YAML format, in a file called bunnyshell.yaml.

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:

📘

The environment definition bunnyshell.yaml file 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.


Deploying Environments

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.

 

Containers Image Building

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.

 

Helm charts, Kubernetes manifests, Terraform and Generic Components (scriptable components)

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.

  

Docker-compose components

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.

  

Stopping Environments

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.

 
 

Deleting Environments

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 destroy scripts are executed, all in parallel.

Updated 5 months ago