Expand README content, split into multiple files

Signed-off-by: Solomon Hykes <sh.github.6811@hykes.org>

doc/install.md

@@ -0,0 +1,14 @@
+# Installing Dagger
+
+1. Build the `dagger` command-line tool. You will need [Go](https://golang.org) version 1.16 or later.
+
+```
+$ make
+```
+
+2. 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
+```
+

doc/operator.md

@@ -0,0 +1,43 @@
+# Dagger Operator Manual
+
+## 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](https://github.com/jaegertracing/jaeger), ), set the `JAEGER_TRACE` environment variable to the collection address.
+
+A `docker-compose` file is available to help bootstrap the tracing environment:
+
+```sh
+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/](http://localhost:16686/) in your browser to see the traces.
+

doc/programmer.md

@@ -0,0 +1,37 @@
+# Dagger Programmer Guide
+
+## The Dagger programming model
+
+*FIXME*
+
+## What is a DAG?
+
+A DAG is the basic unit of programming in dagger.
+It is a special kind of program which runs as a aipeline of inter-connected computing nodes running in parallel, instead of a sequence of operations to be run by a single node.
+
+DAGs are a powerful way to automate various parts of an application delivery workflow:
+build, test, deploy, generate configuration, enforce policies, publish artifacts, etc.
+
+The DAG architecture has many benefits:
+
+  - Because DAGs are made of nodes executing in parallel, they are easy to scale.
+  - Because all inputs and outputs are snapshotted and content-addressed, DAGs
+  can easily be made repeatable, can be cached aggressively, and can be replayed
+  at will.
+  - Because nodes are executed by the same container engine as docker-build, DAGs
+  can be developed using any language or technology capable of running in a docker.
+  Dockerfiles and docker images are natively supported for maximum compatibility.
+  - Because DAGs are programmed declaratively with a powerful configuration language,
+  they are much easier to test, debug and refactor than traditional programming languages.
+
+To execute a DAG, the dagger runtime JIT-compiles it to a low-level format called llb, and executes it with buildkit. Think of buildkit as a specialized VM for running compute graphs; and dagger as a complete programming environment for that VM.
+
+The tradeoff for all those wonderful features is that a DAG architecture cannot be used for all software: only software than can be run as a pipeline.
+
+## The CUE language
+
+*FIXME*
+
+## The Buildkit runtime environment
+
+*FIXME*

doc/tutorials.md

@@ -0,0 +1,15 @@
+# Dagger Tutorials
+
+## 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=.
+```

doc/what_is_adc.md

@@ -0,0 +1,25 @@
+# What is Application Delivery as Code?
+
+## 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.
+
+
+## The problem with artisanal deploy scripts
+
+Most applications don't fit in any major PaaS. Instead they are deployed by a patchwork of specialized tools, usually glued together by an artisanal shell script or equivalent.
+
+*FIXME: example of specialized tools*
+
+Most teams are unhappy with their deploy script. They are high maintenance, tend to break at the worst possible time, and are less convenient to use than a PaaS. But when you need control of your stack, what other choice is there?
+
+
+## The best of both worlds: Application Delivery as Code
+
+Application Delivery as Code (ADC) is an alternative to PaaS and artisanal deploy scripts, which combines the best of each.
+
+Simply put, with ADC each application gets its own single-purpose PaaS. The platform adapts to the application, not the other way around. And because it’s defined *as code*, this custom PaaS can easily be changed over time, as the application stack and infrastructure evolves.
+
+Because doing this with a general programming language, like Go, would be prohibitively expensive, a good ADC implementation requires a specialized language and runtime environment. For example, Dagger uses [Cue](https://cuelang.org) as its language, and [Buildkit](https://github.com/moby/buildkit) as its runtime environment.