Components

Component Types

Currently, there are 6 major types of components in Bunnyshell:

• Docker-compose components, which are based on services from docker-compose definitions
• Build components, which produce artefacts for other components to use
• Static Applications, based on an Nginx serving static HTML, CSS & JS pages
• Kubernetes-compatible components, designed to deploy in Kubernetes in a native way
• Terraform components, designed to apply terraform modules and handle state
• Customizable components, which allow the user complete control of what is executed in the workflows

Docker-compose components

There are 3 types of components based on services from docker-compose

• Application - used for git-stored code that needs to be built
• Database - used for databases, which need persistence and seeding
• Service- used for services (such as caches, queues etc)

Build components

Currently, there are two artefact-producing components:

• DockerImage - handle Docker image builds, to be used in other components
• CustomDockerImage - also the goal is to build a Docker image, but the user has full control on the build steps

Static Applications

Currently, there is only one such component:

• StaticApplication - an Nginx serving static HTML, CSS & JS pages, prebuilt by Bunnyshell

Kubernetes-compatible components

These components are used for creating resources within Kubernetes.

• KubernetesManifest - used with plain Kubernetes manifests
• Helm - used with Helm Charts

Terraform components

• Terraform - used with Terraform modules

Customizable components

• GenericComponent - completely customizable, by writing scripts for each of the workflows

 

Component Actions

Settings

From Settings, you can rename a Component.

🚧

Components in Bunnyshell are identified by their name, so please note that renaming a component will also cause the component to appear as Marked for deletion, with a new component inserted (un-deployed).

You can reverse this by renaming the component back to its original name, before deploying.

Edit variables

You will enter a screen from where you can manage (add / edit / delete) the Environment Variables for the Component. You will be able to also see Environment-level Variables and Project-level Variables, along with their values, and you can override them at a Component level, by adding a variable with the same name.
For more details on how the inheritance works, please consult the Variables Inheritances & override section.

Change branch

A pop-up will appear, containing an input for the new branch to be set on the Component. Please note that this only changes the Environment's config, and you need to deploy the Environment in order to have changes applied in Kubernetes.

Remote Development

This action will open up a pop-up containing the CLI command needed to run in order to start Remote Development on the Component.

Port Forwarding

This action will open up a pop-up containing the CLI command needed to run in order to start port forwarding for the Component.

Remove Component

When a Component is removed, it is actually marked for deletion, and its resources will be removed from Kubernetes when the next deploy is performed on the environments. However, if the component was never deployed, it is deleted immediately.

For further details, please consult the Deploy workflow details section.

 

📘

Please note that changing a component's type (kind) can also mark a Component for deletion.

However, there are some inter-changable groups of Component types, within which Bunnyshell can perform the deployment using another type, without causing any loss of data, and these are as follows:

• Non-deployable group: SidecarContainer, InitContainer, DockerImage, CustomDockerImage
• Docker-compose group: Application, Service, Database, StaticApplication
• Generic group: KubernetesManifest, Helm, GenericComponent, Terraform
  Changing the type within the same group will not cause the Component to be marked for deletion.