Introduction
Continuous Integration/Continuous Deployment (CI/CD) has revolutionized software development by enabling automation of the build, test, and deployment process. One critical decision when setting up a CI/CD pipeline is whether to use Git provider-hosted runners or self-hosted runners. While Git provider-hosted runners have their merits, and are sufficient for a large number of use cases, self-hosted runners offer greater control and security when managing resources in and deploying applications to your environment. Among self-hosted runners, the choice between ephemeral and permanent architectures further impacts efficiency and costs.
Self-Hosted Runners:
Self-hosted runners offer control and security over the pipeline execution environment present in Git provider-hosted runners.
The biggest advantage of self-hosted runners is the ability to provision these runners directly into your environment, allowing them to connect to and manage private cloud resources that runners from Git providers normally would not be able to.
However, self-hosted runners come with the additional cost of needing to be managed by your organization. Organizational needs will dictate which of the below architectures, ephemeral runners vs permanent runners, meet your use cases.
Ephemeral Runners
Ephemeral runners are short-lived instances created specifically for executing individual CI/CD jobs. This architecture offers distinct benefits and challenges.
The general general architecture of ephemeral runners in AWS uses API Gateway,Lambda, and webhooks from your Git provider of choice. The Git providers CI/CD webhooks post to an API Gateway, which triggers the appropriate Lambda functions to orchestrate the creation of runners.
For instance termination either a Lambda function can regularly check EC2 instance utilization and terminate idle resources, or Cloudwatch Events can be used to monitor for idle resources and trigger a Lambda function to terminate them.
Pros of ephemeral runners:
- Enhanced Security: Ephemeral runners have a brief lifetime, reducing the window of opportunity for malicious actors to exploit the environment.
- Cost Efficiency: As runners are spun up and down as needed, costs are minimized, eliminating charges for idle resources.
Cons of ephemeral runners:
- Increased Spin-Up Time: The time taken to spin up instances and configure necessary software can extend the overall pipeline runtime if not using a customized Amazon Machine Image, which adds additional management complexity.
Permanent Runners:
Permanent runners are longer-lasting instances that remain available for multiple pipeline executions.
The general architecture of permanent runners should utilize an EC2 autoscaling group with a minimum capacity of one instance. This will ensure that runners can be provisioned and terminated to meet your pipeline execution needs, reducing cloud costs. Autoscaling groups can be combined with spot instances to further reduce costs.
AWS Systems Manager Documents along with State Manager can automatically run documents against EC2 instances provisioned by the autoscaling group to automatically register and deregister the EC2 instances as runners.
Pros of permanent runners:
- Faster Execution: At least one permanent runner is immediately available to pipelines, allowing them to start sooner.
- Simpler Execution Environment: Since instances are maintained over time, there's less time waiting for dependencies to be installed on the runner.
Cons of permanent runners:
- Costs of Idle Resources: Keeping instances alive results in ongoing costs, even during periods of inactivity at minimum capacity.
Conclusion
Choosing between ephemeral and permanent self-hosted CI/CD runners involves a trade-off between security, efficiency, and cost. Ephemeral runners offer enhanced security and lower costs but may introduce architectural complexity and increased spin-up time. Permanent runners provide faster execution and a more consistent environment but come with ongoing idle resource costs and maintenance overhead. Organizations must carefully evaluate their requirements and resources to determine the most suitable architecture for their CI/CD pipelines.
