#gitops

1 messages · Page 1 of 1 (latest)

true zinc
#

Hi 👋 @cold crag

What style of GitOps are you using or do you want to use? Where are you deploying to? What do you want to have happen?

In the most simple GitOps case, you push code changes to version control (git usually) and then one or more things happen somewhere that is consistent with that code.

GitOps is often associated with Kubernetes (k8s):
For example, you push some app code, this triggers a container image build and push to a registry, something notices the new image version and starts a rolling deployment to k8s.

People often use k8s operators like Flux and Argo to do the noticing and pulling/deploying in k8s.

Dagger can be used in this kind of system along with tools like GitHub Actions, GitLab CI, or Jenkins to notice code pushes too and trigger a Dagger plan (dagger do xxxx). That plan might lint code, build the app in a container image, test it, push it to a registry, and then FluxCD or Argo might notice it and deploy. In that case, Dagger is doing the CI part and the GitOps operator is doing the CD part.

Or maybe you want the Dagger plan to trigger the deployment (script, api call, etc), so Dagger is helping to "push" to a deployment target. In this case Dagger could be doing both CI and CD.

A lot of GitOps folks like a "pull" from the deployment target. So an operator running in k8s that pulls from a container registry instead of something pushing to k8s by running kubectl apply or similar.

What's your specific use case look like? 🙂

mint mural
#

Hi @true zinc . Hope I'm not intruding, but looking to use Dagger with Argo Workflows to deploy a Python container upon commits, run the script, then spin down the pod until the next commit.

Based on your reply, what's a good way to get started with Dagger for this outcome?:

Dagger can be used in this kind of system along with tools like GitHub Actions, GitLab CI, or Jenkins to notice code pushes too and trigger a Dagger plan (dagger do xxxx). That plan might lint code, build the app in a container image, test it, push it to a registry, and then FluxCD or Argo might notice it and deploy. In that case, Dagger is doing the CI part and the GitOps operator is doing the CD part.

true zinc
#

Yes, sounds good. Let us know what you hit as you go along and we'll all try to unblock you (Dagger staff and the whole community).

mint mural
#

Appreciate that. Other than the official docs, are there any recommended example repos or tutorials?

true zinc
#

I'd take a look at the todo app example which is used in our tutorial:
https://github.com/dagger/todoapp
It has a build, deploy pattern in it (to local or Netlify).

Here's a Python build example I did for someone using a Dockerfile as well: https://github.com/jpadams/python-build-example/blob/main/main.cue

There is someone in process of moving an ArgoCD package from Dagger 0.1 to 0.2 as well (though not a top priority for them). If you have a sketch of what an Argo Workflows action should look like, we could help as well.

mint mural
#

Appreciate the examples @true zinc ! Where can I find the ArgoCD package for reference?

EDIT: misread. You were referring to Dagger itself as v0.2

true zinc
#

@fervent drum FYI ☝️ (also interested in ArgoCD)

fervent drum
true zinc