This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Tony Worm a1ba7aa59c implement .daggerignore
Signed-off-by: Tony Worm <tony@hofstadter.io>
2021-03-17 19:55:28 -04:00
.github move timeout to golangci-lint command 2021-03-16 15:33:52 -04:00
cmd/dagger opentracing support 2021-03-04 10:45:20 -08:00
dagger implement .daggerignore 2021-03-17 19:55:28 -04:00
examples Rename dagger.#Dir to dagger.#Artifact 2021-03-13 00:11:59 -08:00
pkg buildkitd: store state persistently in a volume 2021-03-02 18:53:15 -08:00
stdlib fix TitleCase error 2021-03-16 16:59:32 -04:00
tests implement .daggerignore 2021-03-17 19:55:28 -04:00
.daggerignore implement .daggerignore 2021-03-17 19:55:28 -04:00
.gitattributes test: add secrets for testing 2021-03-12 17:03:22 -08:00
.gitignore update .gitignore 2021-02-03 14:58:33 -08:00
.golangci.yml pkg/progressui: customization callbacks 2021-02-23 15:34:41 -08:00
ARCHITECTURE.md Simplify runtime code by removing layers of abstraction 2021-02-12 22:20:20 +00:00
doc.go add a go file to the root folder 2021-02-17 13:13:17 -08:00
Dockerfile build(deps): bump golang from 1.16.1-alpine to 1.16.2-alpine 2021-03-12 07:07:03 +00:00
go.mod build(deps): bump cuelang.org/go from 0.3.0-beta.5 to 0.3.0-beta.6 2021-03-12 07:21:01 +00:00
go.sum Merge pull request #173 from dagger/push-container 2021-03-12 15:52:52 -08:00
LICENSE add LICENSE file 2021-01-14 12:36:19 -08:00
Makefile move timeout to golangci-lint command 2021-03-16 15:33:52 -04:00
README.md README: Application Delivery as Code (ADC) 2021-03-17 01:11:40 -07:00
tracing.compose.yaml opentracing support 2021-03-04 10:45:20 -08:00

Dagger

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.

Dagger is an Application Delivery as Code (ADC) platform.

Using Dagger, software teams can replace their artisanal deployment scripts with a state-of-the-art deployment pipeline, tailor-made for their application and infrastructure, in just a few lines of code.

  • 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 cant because your stack is too custom?
  • Do you put off infrastructure and workflow improvements because it would slow down development?
  • Do you wish you could visualize your entire application delivery workflow as code, all in one place?

If you answered “yes” to any of the above, Dagger might be a good fit for you.

The problem with PaaS

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.

But what if we didnt have to choose between productivity and flexibility? What if we could have both? Thats 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.

And because its 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 version 1.16 or later.
$ make
  1. Copy the dagger tool to a location listed in your $PATH. For example, to copy it to /usr/local/bin:
$ cp ./cmd/dagger/dagger /usr/local/bin
  1. Compute a test configuration

Currently dagger can only do one thing: compute a configuration with optional inputs, and print the result.

If you are confused by how to use this for your application, that is normal: dagger compute is a low-level command which exposes the naked plumbing of the Dagger engine. In future versions, more user-friendly commands will be available which hide the complexity of dagger compute (but it will always be available to power users, of course!).

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

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.

To use a buildkit daemon listening on TCP port 1234 on localhost:

$ export BUILDKIT_HOST=tcp://localhost:1234

To use a buildkit daemon running in a container named "super-buildkit" on the local docker host:

$ export BUILDKIT_HOST=docker-container://super-buildkit

To use a buildkit daemon running on a remote docker host (be careful to properly secure remotely accessible docker hosts!)

$ export BUILDKIT_HOST=docker-container://super-buildkit
$ export DOCKER_HOST=tcp://my-remote-docker-host:2376

OpenTracing Support

Both Dagger and buildkit support opentracing. To capture traces to Jaeger, ), set the JAEGER_TRACE environment variable to the collection address.

A docker-compose file is available to help bootstrap the tracing environment:

docker-compose -f ./tracing.compose.yaml up -d
export JAEGER_TRACE=localhost:6831
export BUILDKIT_HOST=docker-container://dagger-buildkitd-jaeger

dagger compute ...

You can then go to http://localhost:16686/ in your browser to see the traces.

The Dagger programming model

FIXME.

Dagger and your application

FIXME.

Dagger and your infrastructure

FIXME.