Ephemeral Environments
Ephemeral Environments are a way to create and destroy environments on demand.
Determining if you need an ephemeral environment
Here are some key questions to help determine if ephemeral environments would benefit your workflow:
If you answered yes to any of these questions, implementing ephemeral environments could significantly improve your development workflow.
Scenario
A development team needs to test feature branches in isolated environments before merging to main. Each developer needs:
- A complete replica of the production environment
- Automatic cleanup when pull requests are merged
- Cost optimization for cloud resources
- Integration with their CI/CD pipeline
In this example we will be using the following technologies
- Github Actions for CI/CD
- Kubernetes (GKE) for containerization
We are going to deploy a simple nginx application to the cluster and then test it.
Here is a high level overview of the workflow:
1. Pull Request Resource Creation
When using Ctrlplane for any system, you must first determine what resources represent the the existance of your deployment.
In this case, we will use the GitHub pull request to determine if the ephemeral environment should be created and when it should be destroyed.
This means Ctrlplane will follow the lifecycle of the pull request - creating the environment when the PR is opened and destroying it when the PR is merged or closed.
todo this we will need to create a Github that tracks and updates resources in ctrlplane as pull requests state changes.
Here is what it does:
-
When a pull request is opened or reopened:
- Creates/updates a resource in Ctrlplane with metadata about the PR
- Includes details like repository, branch, PR number, and author
- Links back to the GitHub PR for reference
-
When a pull request is closed:
- Automatically deletes the corresponding resource from Ctrlplane
- Helps clean up any associated ephemeral environments
2. Infrastructure Creation
Once the pull request resource is created, we now determine what pipelines need to be take give the state of the Pull Request. In our scenario we will create a GKE cluster for each PR.
If you wanted to speed up the creation of the cluster, you could instead deploy to a namespace in an existing cluster.
3. Application Deployment
Lets create a new github action that will deploy our Nginx application to the cluster.