What if you want to test a change before applying it into the production/live environment?
Are you testing your application in an environment which was replicated from the real one?
Usually you do not. There are some reasons:
- Complexity: Your real environment is too complex.
- Monetary cost: Having multiple environment are expensive.
- Technical cost: Keeping all environments up to date is an arduous task. And we’re not saying anything about security…
We are sure you can think of many other reasons.
Ephemeral Environment
We are not reinventing the concept. If you google it, you can find the following link (first result, i promise):
In an ephemeral environment configuration, each relevant stage would contain two extra actions: one at the beginning, and one at the end, that spin up an environment for the purpose of testing, and spin it down at the end of the stage.
Let’s do it
In this case the application is a static web page using hugo to render markdown files. The final web version will be deployed at https://docs.k8spin.cloud.
Our objective is to have a new ephemeral environment on every new branch. The requirements are:
- Public URL: We share it with the team to validate branch changes.
- SSL/TLS: As production environment contains SSL/TLS certificates, our ephemeral environment needs too.
- Dynamic: Has to be ready in few seconds and could be destroyed any time.
Let’s get to work
To achieve this, we opt to use gitlab.com as our CI/CD system and our platform as ephemeral kubernetes environment provider.
Why gitlab.com? It provides us git repositories along with a yaml + containers based CI/CD system.
When a new branch is created, the CI pipeline creates a container image with the changed site then creates a new ephemeral environment and deploys the container into it.
Pipeline looks like this:
Gitlab provides the “environment” concept. We use it to manage all ephemeral environment as it can have many branches.
It provides a simple way to go to the published URL and stop (destroy) the environment.
In addiction, if we open a pull/merge request we can use both buttons:
So, our reviewer can open the “app” before merge the changes.
Under the hood
Our platform provides an API to manage kubernetes namespaces in a dynamic (and secure) way. So we create a namespace where the container image created in a feature branch is deployed exposing its service via ingress.
Right now the pipeline invokes the API using curl but we will release a CLI in the following days so pipeline scripts will be cleaner.
You can find all kubernetes deployment objects inside the repository (live-review directory) and your quota usage at k8spin console:
Conclusions
During several years of experience we see an ecosystem where a static number of environments is maintained. The problem of having a static number of environments is that if a change is wrongly promoted, you can cause your colleague’s work to stop or simply break the application for a while.
That’s why it’s good to have your environment defined as code so that it can be deployed in a new environment to be tested before sending it to the production/live environment.
K8Spin provides you ephemeral environments where you can deploy your changes being this at least as safe as the environment where your solution will finally be deployed.
We also know that this is a very simple example, but a complex application must be tested even better. Think about making your application or component testable with ephemeral environments, you will notice the difference quickly.
