How Safespring Delivers 100% Predictable, Consistent Ansible Deployments with Dagger
October 1, 2024
Oct 1, 2024
Case Study
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Rob Haverkamp (aka @rob005317_81211 on Discord). Rob is a storage engineer at Safespring, a Nordic supplier of public and private cloud infrastructure. Rob is an active Daggernaut and has implemented Dagger for multiple production use cases at Safespring, such as deploying OpenStack clusters using Dagger and Pulumi. This blog post discusses how he uses Dagger to eliminate environment variance in Ansible deployments and enables his team to consistently run Ansible playbooks on the Safespring cloud platform.
"Dagger is the only tool we've encountered that can properly spawn containers using code and also then do actually useful things with that code.." - Rob Haverkamp, Safespring
Fighting Environment Complexity and Inconsistency
Safespring provides cloud solutions hosted in multiple public and private data centers, utilizing console hosts to oversee the overall infrastructure management. Engineers have user accounts on each console host. When engineers need to work on a site, they log in to a console host, pull Ansible playbooks and inventory data, and use those playbooks to set up their work environment correctly.
Some of the challenges with this approach were:
The same playbook would sometimes work for one engineer but not for another. This usually occurred due to missing dependencies or incorrect software versions in the engineers' console host accounts.
As the number of engineers increased, so too did the variability in their execution environments (e.g. one engineer might prefer `bash`, another might prefer `fish`, and so on), leading to inconsistency in playbook results.
Similarly, as the number of sites increased, the complexity of the playbooks also increased, to account for different software versions and tooling on each site.
Managing the variance was a huge issue and so the team was already considering switching to a container-based approach. Rob knew about Dagger from its early days, but hadn't used it before. In April 2024, he read a blog post about Dagger Functions and grew excited about its potential. He decided to try using Dagger to deliver standardized Ansible environments to the team.
"We were planning a switch to containers, but then we still had open questions around how to spin up the Docker container, maintain the Dockerfile, adapt for different sites and so on. And so we never really got anywhere, because there was already a huge list of things to solve. Then we came across Dagger, which solved all these problems, and we had a minimum setup working in just a couple of days."
Delivering Predictability with Dagger
Safespring created a Dagger module to build an Ansible container and import secrets (SSH keys) into it. The module uses those secrets to clone the required Git repositories and enable access to the rest of the network infrastructure. It then retrieves and runs the Ansible playbooks and reports back.
Safespring also added some wrapper scripts around their Dagger Functions, to make it easier for engineers to interact with them. For example, an engineer can call:
deploy-ansible, which calls a Dagger Function to run a specific Ansible playbook on a specified site;deploy-ansible-interactive, which returns an interactive Dagger terminal for the caller to manually check out source code, switch to a different branch, and so on;check-ansible, which simulates an Ansible playbook run and shows proposed changes.
After switching to Dagger Functions, the workflow for Safespring's engineers has become far simpler and more predictable. Everything now runs in containers, eliminating environment variance and last-minute surprises.
"Everybody's just happy to have the consistency problem solved. You can log on to that site or this site, or a cluster from a different customer, and all the deployment steps are always the same. Everything just works, thanks to Dagger."
Improving Productivity, Reliability and Team Collaboration
Rob and his team have seen three critical benefits from their Dagger implementation:
Improved productivity: Dagger produces Ansible environments which work consistently and predictably, regardless of which console host they're running on. Every engineer operates in the same standardized environment. Platform inconsistencies and version mismatches are now a thing of the past, and engineers can now focus their time on productive work.
Greater adaptability: Dagger Functions are regular program code. As a result, conditional requirements, such as which version of a tool or library should be used on which site, can now be expressed in code rather than YAML or Dockerfile syntax. This has made the system easier to customize for different sites and scenarios.
Better team collaboration and engagement: Engineers across the company can easily inspect the code to see how it works, which increases their overall confidence and trust in the system. They can also collaborate with the platform engineering team to contribute improvements.
In future, Rob plans to automate more of what the team is doing and migrate additional tasks to Dagger Functions. He is also keen to integrate a scheduler, so that a Dagger Function can be triggered automatically to perform a certain task and report the results.
"The greatest thing about Dagger for me is that you can easily use containers with code and do error handling in code, and don't have to fall back to strange bash scripts and shell redirection and stuff like that. Everything just works locally, in a pipeline on your VMs, in your containers...wherever you want it to work. The fact that it's open-source and you can just download it and get started, is huge."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord.
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Rob Haverkamp (aka @rob005317_81211 on Discord). Rob is a storage engineer at Safespring, a Nordic supplier of public and private cloud infrastructure. Rob is an active Daggernaut and has implemented Dagger for multiple production use cases at Safespring, such as deploying OpenStack clusters using Dagger and Pulumi. This blog post discusses how he uses Dagger to eliminate environment variance in Ansible deployments and enables his team to consistently run Ansible playbooks on the Safespring cloud platform.
"Dagger is the only tool we've encountered that can properly spawn containers using code and also then do actually useful things with that code.." - Rob Haverkamp, Safespring
Fighting Environment Complexity and Inconsistency
Safespring provides cloud solutions hosted in multiple public and private data centers, utilizing console hosts to oversee the overall infrastructure management. Engineers have user accounts on each console host. When engineers need to work on a site, they log in to a console host, pull Ansible playbooks and inventory data, and use those playbooks to set up their work environment correctly.
Some of the challenges with this approach were:
The same playbook would sometimes work for one engineer but not for another. This usually occurred due to missing dependencies or incorrect software versions in the engineers' console host accounts.
As the number of engineers increased, so too did the variability in their execution environments (e.g. one engineer might prefer `bash`, another might prefer `fish`, and so on), leading to inconsistency in playbook results.
Similarly, as the number of sites increased, the complexity of the playbooks also increased, to account for different software versions and tooling on each site.
Managing the variance was a huge issue and so the team was already considering switching to a container-based approach. Rob knew about Dagger from its early days, but hadn't used it before. In April 2024, he read a blog post about Dagger Functions and grew excited about its potential. He decided to try using Dagger to deliver standardized Ansible environments to the team.
"We were planning a switch to containers, but then we still had open questions around how to spin up the Docker container, maintain the Dockerfile, adapt for different sites and so on. And so we never really got anywhere, because there was already a huge list of things to solve. Then we came across Dagger, which solved all these problems, and we had a minimum setup working in just a couple of days."
Delivering Predictability with Dagger
Safespring created a Dagger module to build an Ansible container and import secrets (SSH keys) into it. The module uses those secrets to clone the required Git repositories and enable access to the rest of the network infrastructure. It then retrieves and runs the Ansible playbooks and reports back.
Safespring also added some wrapper scripts around their Dagger Functions, to make it easier for engineers to interact with them. For example, an engineer can call:
deploy-ansible, which calls a Dagger Function to run a specific Ansible playbook on a specified site;deploy-ansible-interactive, which returns an interactive Dagger terminal for the caller to manually check out source code, switch to a different branch, and so on;check-ansible, which simulates an Ansible playbook run and shows proposed changes.
After switching to Dagger Functions, the workflow for Safespring's engineers has become far simpler and more predictable. Everything now runs in containers, eliminating environment variance and last-minute surprises.
"Everybody's just happy to have the consistency problem solved. You can log on to that site or this site, or a cluster from a different customer, and all the deployment steps are always the same. Everything just works, thanks to Dagger."
Improving Productivity, Reliability and Team Collaboration
Rob and his team have seen three critical benefits from their Dagger implementation:
Improved productivity: Dagger produces Ansible environments which work consistently and predictably, regardless of which console host they're running on. Every engineer operates in the same standardized environment. Platform inconsistencies and version mismatches are now a thing of the past, and engineers can now focus their time on productive work.
Greater adaptability: Dagger Functions are regular program code. As a result, conditional requirements, such as which version of a tool or library should be used on which site, can now be expressed in code rather than YAML or Dockerfile syntax. This has made the system easier to customize for different sites and scenarios.
Better team collaboration and engagement: Engineers across the company can easily inspect the code to see how it works, which increases their overall confidence and trust in the system. They can also collaborate with the platform engineering team to contribute improvements.
In future, Rob plans to automate more of what the team is doing and migrate additional tasks to Dagger Functions. He is also keen to integrate a scheduler, so that a Dagger Function can be triggered automatically to perform a certain task and report the results.
"The greatest thing about Dagger for me is that you can easily use containers with code and do error handling in code, and don't have to fall back to strange bash scripts and shell redirection and stuff like that. Everything just works locally, in a pipeline on your VMs, in your containers...wherever you want it to work. The fact that it's open-source and you can just download it and get started, is huge."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord.
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Rob Haverkamp (aka @rob005317_81211 on Discord). Rob is a storage engineer at Safespring, a Nordic supplier of public and private cloud infrastructure. Rob is an active Daggernaut and has implemented Dagger for multiple production use cases at Safespring, such as deploying OpenStack clusters using Dagger and Pulumi. This blog post discusses how he uses Dagger to eliminate environment variance in Ansible deployments and enables his team to consistently run Ansible playbooks on the Safespring cloud platform.
"Dagger is the only tool we've encountered that can properly spawn containers using code and also then do actually useful things with that code.." - Rob Haverkamp, Safespring
Fighting Environment Complexity and Inconsistency
Safespring provides cloud solutions hosted in multiple public and private data centers, utilizing console hosts to oversee the overall infrastructure management. Engineers have user accounts on each console host. When engineers need to work on a site, they log in to a console host, pull Ansible playbooks and inventory data, and use those playbooks to set up their work environment correctly.
Some of the challenges with this approach were:
The same playbook would sometimes work for one engineer but not for another. This usually occurred due to missing dependencies or incorrect software versions in the engineers' console host accounts.
As the number of engineers increased, so too did the variability in their execution environments (e.g. one engineer might prefer `bash`, another might prefer `fish`, and so on), leading to inconsistency in playbook results.
Similarly, as the number of sites increased, the complexity of the playbooks also increased, to account for different software versions and tooling on each site.
Managing the variance was a huge issue and so the team was already considering switching to a container-based approach. Rob knew about Dagger from its early days, but hadn't used it before. In April 2024, he read a blog post about Dagger Functions and grew excited about its potential. He decided to try using Dagger to deliver standardized Ansible environments to the team.
"We were planning a switch to containers, but then we still had open questions around how to spin up the Docker container, maintain the Dockerfile, adapt for different sites and so on. And so we never really got anywhere, because there was already a huge list of things to solve. Then we came across Dagger, which solved all these problems, and we had a minimum setup working in just a couple of days."
Delivering Predictability with Dagger
Safespring created a Dagger module to build an Ansible container and import secrets (SSH keys) into it. The module uses those secrets to clone the required Git repositories and enable access to the rest of the network infrastructure. It then retrieves and runs the Ansible playbooks and reports back.
Safespring also added some wrapper scripts around their Dagger Functions, to make it easier for engineers to interact with them. For example, an engineer can call:
deploy-ansible, which calls a Dagger Function to run a specific Ansible playbook on a specified site;deploy-ansible-interactive, which returns an interactive Dagger terminal for the caller to manually check out source code, switch to a different branch, and so on;check-ansible, which simulates an Ansible playbook run and shows proposed changes.
After switching to Dagger Functions, the workflow for Safespring's engineers has become far simpler and more predictable. Everything now runs in containers, eliminating environment variance and last-minute surprises.
"Everybody's just happy to have the consistency problem solved. You can log on to that site or this site, or a cluster from a different customer, and all the deployment steps are always the same. Everything just works, thanks to Dagger."
Improving Productivity, Reliability and Team Collaboration
Rob and his team have seen three critical benefits from their Dagger implementation:
Improved productivity: Dagger produces Ansible environments which work consistently and predictably, regardless of which console host they're running on. Every engineer operates in the same standardized environment. Platform inconsistencies and version mismatches are now a thing of the past, and engineers can now focus their time on productive work.
Greater adaptability: Dagger Functions are regular program code. As a result, conditional requirements, such as which version of a tool or library should be used on which site, can now be expressed in code rather than YAML or Dockerfile syntax. This has made the system easier to customize for different sites and scenarios.
Better team collaboration and engagement: Engineers across the company can easily inspect the code to see how it works, which increases their overall confidence and trust in the system. They can also collaborate with the platform engineering team to contribute improvements.
In future, Rob plans to automate more of what the team is doing and migrate additional tasks to Dagger Functions. He is also keen to integrate a scheduler, so that a Dagger Function can be triggered automatically to perform a certain task and report the results.
"The greatest thing about Dagger for me is that you can easily use containers with code and do error handling in code, and don't have to fall back to strange bash scripts and shell redirection and stuff like that. Everything just works locally, in a pipeline on your VMs, in your containers...wherever you want it to work. The fact that it's open-source and you can just download it and get started, is huge."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord.
