Patrick.Sy/hello-dagger
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(dagger): further findings on CI usage and conclusion

Browse source
This commit is contained in:
Patrick Sy 2024-10-15 18:51:04 +02:00
parent e74b8cc185
commit 2c531d42ba
Signed by: Patrick.Sy
GPG key ID: DDDC8EC51823195E
1 changed files with 58 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

61
README.md
View file

@ -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.