kjuulh/dagger
Archived
1
0
Fork 0
Code Issues 1 Pull Requests 1 Projects Releases Wiki Activity

Improve overall explanation in README

Browse Source 
Signed-off-by: Solomon Hykes <sh.github.6811@hykes.org>
This commit is contained in:
Solomon Hykes 2021-03-16 23:59:09 +00:00
parent c42ccd4385
commit db40d98d8a
1 changed files with 25 additions and 79 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
README.md
View File

@ -1,67 +1,34 @@
# Dagger: the devops superglu, by the creators of docker
# Dagger
Dagger is a scripting environment for automating the delivery of your application to the cloud,
from code to production.
*WARNING: Dagger is alpha-quality software. It has many bugs, the user interface is minimal, and it may change in incompatible ways at any time. If you are still willing to try it, thank you! We appreciate your help and encourage you to ask questions and report issues.*
If you are familiar with PaaS services like Heroku, Firebase or Openshift:
Dagger makes it easy to create a custom PaaS that is perfectly tailored to each application,
instead of forcing it into a rigid, homogeneous mold. The Dagger philosophy
is that the platform should adapt to the application, not the other way around.
Dagger is a programmable PaaS (*platform-as-a-service*).
This means that, unlike traditional PaaS, you can use Dagger with all your applications,
*without having to change your tooling, software stack or infrastructure*.
Using Dagger, software teams can replace their artisanal deployment scripts with a state-of-the-art PaaS that is perfectly tailored to their application and infrastructure, in just a few lines of code.
TODO:
*[... principles: productivity + compat]*
*[.. do out-of-the-box things that would require months of work otherwise]*
*[.. alternative to the dilemna: paas or build your own?]*
- Do you spend too much time getting your home-made deployment scripts to work?
- Do you wish you could just use a PaaS like Heroku or Firebase but can’t because your stack is too custom?
- Do you put off infrastructure and workflow improvements because changing your tooling is just too much work?
- Do you wish you could visualize your entire application delivery workflow as code, all in one place?
## Warning: alpha software
If you answered “yes” to any of the above, Dagger might be a good fit for you.
Please note that Dagger is *alpha-quality software*. This means it has many bugs,
the user interface is minimal, and it may change in incompatible ways at any time.
## The problem with PaaS
If you are still willing to try it, thank you! We appreciate your help.
Please do not hesitate to ask questions, report bugs, or share feedback,
either in a github or in the discord chatroom.
A PaaS, or platform-as-a-service, is the glue between an application and the cloud infrastructure running it. It automates the deployment process and provides a simplified view of the underlying infrastructure, which makes developers more productive.
However, despite the undeniable productivity benefits of using a PaaS, most applications today do not. Why? Because it's not flexible enough: each PaaS only supports certain types of application stacks and infrastructure. Applications that cannot adapt to the platform are simply not supported, and instead are deployed by a mosaic of specialized tools, usually glued together in an artisanal shell script or equivalent.
## Platform as code
But what if we didn’t have to choose between productivity and flexibility? What if we could have both? That’s where Dagger comes in. With Dagger, *each application defines its own PaaS*, perfectly tailored to its existing stack and infrastructure. The platform adapts to the application, instead of the other way around.
The most important feature of Dagger is that it is *programmable*.
Thanks to its powerful scripting environment and growing catalog of reusable components,
anyone with basic programming knowledge can assemble a custom platform for their application,
and quickly start automating repetitive and complex tasks, so the entire team can spend
less time getting deployment to work, and more time developing.
Whether you're a seasoned SRE building a custom PAAS for your organization, a hobbyist on a fun
over-engineered week-end project, or a developer trying to setup CICD because, well, someone has to do it..
There's a whole community of fellow automation enthusiasts ready to help you write your first script.
## Usage examples
A few examples of how Dagger is used in the wild:
- Use AWS Elastic Container Service to deploy the new API, while continuing to deploy the main app on Heroku.
- Deploy lightweight staging environments on-demand for QA, integration testing or product demos.
- Run integration tests on a live production-like deployment, automatically, for each pull request.
- Deploy the same app on Netlify for testing, and on Kubernetes for production
- Replace a 500-line deploy.sh with a 10-line configuration file
- Control sprawl of serverless functions on AWS, Google Cloud, Cloudflare, Netlify etc. by gradually
moving them to a generic interface, and switching backend at will.
- When the ML team uploads a new model to their S3 bucket, automatically incorporate it into staging
deployments, but not into production until manual confirmation!
- Rotate database credentials, and automatically re-deploy all staging environments with the new credentials.
- Allocate cool auto-generated URLs to development instances, and automatically configure your DNS,
load-balancer and SSL certificate manager to route traffic to them.
- Orchestrate application deployment across 2 infrastructure siloes, one managed with CloudFormation, the other with Terraform.
- Migrate from Helm to Kustomize, without disrupting next week's big release.
And because it’s defined *as code*, this custom PaaS can easily be changed over time, as the application stack and infrastructure evolves.
## Getting started
### Installing the dagger command-line
1. Build the `dagger` command-line tool. You will need [Go](https://golang.org) version 1.16 or later.
```
@ -88,8 +55,7 @@ Here is an example command, using an example configuration:
$ dagger compute ./examples/simple --input-string www.host=mysuperapp.com --input-dir www.source=.
```
## Custom buildkit setup
### Custom buildkit setup
Dagger can be configured to use an existing buildkit daemon, running either locally or remotely. This can be done using two environment variables: `BUILDKIT_HOST` and `DOCKER_HOST`.
@ -112,7 +78,7 @@ $ export BUILDKIT_HOST=docker-container://super-buildkit
$ export DOCKER_HOST=tcp://my-remote-docker-host:2376
```
## OpenTracing Support
### OpenTracing Support
Both Dagger and buildkit support opentracing. To capture traces to
[Jaeger](https://github.com/jaegertracing/jaeger), ), set the `JAEGER_TRACE` environment variable to the collection address.
@ -129,35 +95,15 @@ dagger compute ...
You can then go to [http://localhost:16686/](http://localhost:16686/) in your browser to see the traces.
## Comparison to other automation platforms
## The Dagger programming model
### CICD
*FIXME*.
Github, Gitlab, Jenkins, Spinnaker, Tekton
## Dagger and your application
### Build systems
Bazel, Nix, Skopeo
### Infrastructure automation
Terraform, Pulumi, Ansible
### Traditional scripting
Bash, Make, Python
### PaaS
Heroku, Elastic Beanstalk, Cloud Foundry, Openshift
### Kubernetes management
Kustomize, Helm, jsonnet
### Gitops
Flux, ...
*FIXME*.
## Dagger and your infrastructure
*FIXME*.