From 2c531d42ba2b0ec8151beed2da445cb0c73c6824 Mon Sep 17 00:00:00 2001 From: Patrick Sy Date: Tue, 15 Oct 2024 18:51:04 +0200 Subject: [PATCH] docs(dagger): further findings on CI usage and conclusion --- README.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 58 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 20c4ce6..e420292 100644 --- a/README.md +++ b/README.md @@ -101,6 +101,61 @@ dagger call security-scan --source=. > wrappers instructing container images with some convenience functions. There > is actually not too much magic here. -> Modules in dagger can be written in Go, Python, or Typescript. Either way, -> they are usable in any other language, e.g. a Python module can be used in a -> Typescript config. The proper API functions are exposed on the `dag` object. +> Modules are extension libraries in dagger that can be written in Go, Python, +> or Typescript. Either way, they are usable in any other language, e.g. a +> Python module can be used in a Typescript config. The proper API functions +> are exposed on the `dag` object. + +> Most modules are just thin wrappers around specific images that contain for +> example some tool and provide convenience functions. + +Push the container image to some registry: + +```shell +dagger call build --source=. publish --address=mtr.devops.telekom.de/... +``` + +### Deployment to Kubernetes + +Dagger at its core does not provide tooling to deploy artifacts to kubernetes +or anywhere else. There are, however, modules that expose APIs for, for +example, [`kubectl`](https://daggerverse.dev/mod/github.com/matipan/daggerverse/kubectl@84cbdbe89185ad94690a9ada1cdfb79f1878ecd7) +and [`helm`](https://daggerverse.dev/mod/github.com/sagikazarmark/daggerverse/helm@126b5fbbdad70dbf2a8689600baec2eb78c05ef4). +Creating automatic deployments based on these should be straight forward. But +at this point one could argue to use better suited tooling for this task rather +than to manually code it again. + +### CI + +Dagger does not provide a Job Runner. Thus, it has to run within a system like +GitHub Actions, Gitlab CI, or Jenkins. Once it's running, any workload within +dagger should run seamlessly like on your local machine thanks to dagger's +container abstraction. + +A critical problem however is the fact that the dagger engine requires running +in privileged mode, see +[FAQ](https://docs.dagger.io/faq#can-i-run-the-dagger-engine-as-a-rootless-container). +Depending on the platform this might be a dealbreaker due to security issues. +If the platform does not provide a somewhat isolated vm environment, the +suggested setup includes hosting one or more shared dagger engines within the +platform, see the Gitlab CI kubernetes +[example](https://docs.dagger.io/integrations/gitlab#kubernetes-executor). + +## Conclusion + +Dagger is an extremely neat tool that puts DX front and center. Easy and fast +setup on proper dev machines is a big plus. Intuitive APIs, easy +programmability and containers make creating a build and test environment an +actually nice experience. The debugging capabilities of your build pipeline are +excellent. + +However, dagger only covers the pipeline up until the point where you push your +image to a registry. After that you are more or less on your own. This is +actually fine as it is somewhat out of scope. + +The requirement of privileged mode and container capabilities in general for +the dagger engine is probably a big headache not only in CI but also on weirdly +restricted dev machines. Furthermore, during testing, dagger seems to not +create actually reproducible builds by default but has to be at least +explicitly configured accordingly, but this needs further investigation. `Nix` +might be a worthwhile alternative.