The DevOps and Platform Engineering space certainly is one that evolves fast. As new development paradigms get consumed, supporting the development pipeline is crucial. Pushing a public release of v0.2.x on March 30th, 2022, Dagger, from the creators of Docker, is another approach in portability and consistency in CI/CD pipelines. What the Docker Container has done applications, Dagger is hoping to achieve that with CI/CD pipelines. As adoption of Dagger starts to ramp, folks will be looking to adopt or even migrate from other CI/CD stacks to Dagger. As those paradigms change, Shipa can provide a common abstraction layer bridging the development pipelines.
ArgoCD to Dagger and Anything In-between
The beauty of Shipa is that no matter how the surrounding ecosystem changes, the Shipa abstractions same the same. For example, I have been deploying a sample application leveraging ArgoCD and Shipa.
Though let’s take a look at what it would take to migrate this simple deployment off of ArgoCD to another tool, such as Dagger.
The moving pieces would be what calls Shipa. Shipa has great integrations with Crossplane which allows GitOps engines to interact in a GitOps model with Shipa. First, we will need to get Dagger installed.
Getting Started With Dagger
Installing Dagger is really straightforward. All you need is a Docker Runtime and if you are using a Mac, you can use Homebrew. Though as v0.2.x of Dagger has just been recently released, we will stick with v0.1 for now and leverage the shell installer.
curl -L https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=0.1.0 sh ./bin/dagger version
Once you have Dagger running, you can modify one of the deployment objects that Shipa leverages and have that called by Dagger instead of another tool like ArgoCD.
Having Dagger Deploy Through Shipa
Shipa can deploy from source e.g using a Buildpack or deploy from an image. Since Dagger is a pretty strong CI solution, assuming that you have an image already built. The v0.1 example Dagger To-Do project specifies an image to deploy. Though as of March 30th, 2022, v0.2.x of Dagger has been released and has an updated To-Do project.
In a previous example, we have set up Crossplane and ArgoCD. We can modify one of the objects to match the Dagger To-Do project. Modifying the deployment object that ArgoCD used to deploy, simply just changing the image name allows you to execute on Dagger.
Now just update the image: to the Dagger Example [public.ecr.aws/j7f8d3t2/todoapp].
Here is a gist of the sample-crossplane-shipa-deployment.yaml.
Now you are ready to wire up a Dagger Project locally and execute it on the Kubernetes Manifest.
Setting Up a Kubernetes Dagger Project
The Dagger Documentation has an example of deploying a Kubernetes Manifest. There are a few files that need to be set up, written in Dagger’s Cue language. The easiest way to organize in this quick example is to keep the files in a root of a folder then create a /manifests folder for the sample-crossplane-shipa-deploymeny.yaml. Also if you downloaded the Dagger Binary via the install.sh, can move that to the root of the directory also.
This example also assumes on your local machine that you have a kubeconfig set to a cluster where the Crossplane Controller is running. Shipa can help to deploy to multiple and disparate clusters where the Crossplane Controller is not running.
Now you are ready to run Dagger.
./dagger init
After the init, you can create a Dagger Environment to execute and run Dagger.
./dagger new 'kube'
After that, your folder/project should have the following files:
Now you can validate what input files need to be provided for Dagger to run.
./dagger input list
The two pieces that need to be provided is the Kubernetes Manifest [e.g sample-shipa-crossplane-deployment.yaml] and your kubeconfig.
Next can provide your kubeconfig location and the manifest path. Note: If in your kubeconfig requires a command [e.g command: aws] you will need to wire Dagger v0.1 to that which is in their docs for additional imports in config.cue.
./dagger input text kubeconfig -f ~/.kube/config -e kube
Lastly can provide the manifest location.
./dagger input dir manifest ./manifests -e kube
You are now ready to have Dagger execute.
./dagger up -e kube
And just like that, you have deployed an application with Dagger and Shipa.
You can head back to the Shipa UI to look at the Application Details and hit the public endpoint for the To-Do application. No need to write extra Kubernetes manifests to cover exposing the service.
Then click on the endpoint and success!
As the CI/CD paradigm continues to evolve, Shipa is here to help partner.
Evolving CI/CD Stacks – Shipa is Your Partner
In technology, the only constant is change. As CI/CD stacks continue to evolve, porting the from ArgoCD to Dagger is entirely feasible in this example. The impact on the developer workflow minus the Dagger Specific actons was minimum. Having Shipa as an abstraction layer to your application makes sense.
Cheers,
-Ravi
