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

proofreading corrections

Browse Source 
Signed-off-by: Richard Jones <richard@dagger.io>
This commit is contained in:
Richard Jones 2021-10-04 09:59:14 -06:00
parent b78169ed3f
commit 46c02c7563
1 changed files with 27 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
docs/learn/1003-get-started.md
View File

@ -4,7 +4,7 @@ slug: /1003/get-started/
# Get Started with Dagger # Get Started with Dagger
In this tutorial, you will learn the basics of Dagger by building a Dagger project from scratch. This simple project deploys a [React](https://reactjs.org/) application to your local machine via Docker. In later tutorials, you will learn how to configure Dagger to deploy to your infrastructure. And, for advanced users, how to share access to your infrastructure in the same way that we share access to ours now. In this tutorial, you will learn the basics of Dagger by building a Dagger project from scratch. This simple project deploys a [React](https://reactjs.org/) application to your local machine via Docker. In later tutorials, you will learn how to configure Dagger to deploy to remote infrastructure such as EKS and GKE.
This tutorial does involve writing CUE, so if you haven&rsquo;t already, be sure to read [What is CUE?](../introduction/1005-what_is_cue.md) This tutorial does involve writing CUE, so if you haven&rsquo;t already, be sure to read [What is CUE?](../introduction/1005-what_is_cue.md)
@ -16,7 +16,7 @@ In this tutorial we will learn:
- environments - environments
- inputs and outputs - inputs and outputs
- How to write CUE for Dagger - How to write CUE for Dagger
- How to deploy an application using `dagger up` - How to deploy an application with Dagger
## Deploy an Application Locally ## Deploy an Application Locally
@ -57,7 +57,7 @@ ls -la
You will now see 2 new directories: You will now see 2 new directories:
- The `.dagger` directory will store metadata about _environments_, _inputs_, and _outputs_ which we will cover later. - The `.dagger` directory will store metadata about _environments_, _inputs_, and _outputs_ which we will cover later.
- The `cue.mod` directory stores libraries such as [dagger/universe](https://github.com/dagger/universe) which can be _imported_ into your Dagger _plan_. - The `cue.mod` directory stores libraries such as [dagger/universe](https://github.com/dagger/universe) which can be _imported_ into your Dagger plan.
Dagger will load all `.cue` files recursively in the current Dagger project. More directories can be added to help organize code. Dagger will load all `.cue` files recursively in the current Dagger project. More directories can be added to help organize code.
@ -67,7 +67,7 @@ Dagger will load all `.cue` files recursively in the current Dagger project. Mor
A Dagger _plan_ is written in CUE and defines the _resources_, _dependencies_, and _logic_ to deploy an application to an environment. Unlike traditional glue code written in a scripting language such as Bash or PowerShell, a Dagger plan is _declarative_ rather than _imperative_. This frees us from thinking about the order of operations, since Dagger will infer dependendencies and calculate correct order on its own. A Dagger _plan_ is written in CUE and defines the _resources_, _dependencies_, and _logic_ to deploy an application to an environment. Unlike traditional glue code written in a scripting language such as Bash or PowerShell, a Dagger plan is _declarative_ rather than _imperative_. This frees us from thinking about the order of operations, since Dagger will infer dependendencies and calculate correct order on its own.
Let's first create a directory to hold our plan separately from our application code: Let&rsquo;s first create a directory to hold our Dagger plan separately from our application code:
```bash ```bash
mkdir -p ./plans/local mkdir -p ./plans/local
@ -109,8 +109,8 @@ image: os.#Container & {
// push the image to a registry // push the image to a registry
push: docker.#Push & { push: docker.#Push & {
// leave target as a string here so that // leave target blank here so that different
// different environments can push to different registries // environments can push to different registries
target: string target: string
// the source of our push resource // the source of our push resource
@ -133,7 +133,7 @@ import (
) )
// run our todoapp in our local Docker engine // run our todoapp in our local Docker engine
todoapp: docker.#Run & { run: docker.#Run & {
ref: push.ref ref: push.ref
name: "todoapp" name: "todoapp"
ports: ["8080:80"] ports: ["8080:80"]
@ -141,6 +141,8 @@ todoapp: docker.#Run & {
} }
// push to our local registry // push to our local registry
// this concrete value satisfies the string constraint
// we defined in the previous file
push: target: "localhost:5000/todoapp" push: target: "localhost:5000/todoapp"
``` ```
@ -167,7 +169,7 @@ local ...todoapp/.dagger/env/local
### Define Input Values per Environment ### Define Input Values per Environment
Our Dagger plan includes a number of references to `dagger.#Input` which inform the Dagger engine that the concrete value should be pulled from inputs. While some things such as the registry target we saw above can be expressed purely in CUE, others such as directories, secrets, and sockets are required to be explicitly defined as _inputs_ to protect against malicious code being injected by third-party packages. If Dagger allowed such things to be stated in CUE, the entire package system could become a source of attacks. Our Dagger plan includes a number of references to `dagger.#Input` which inform the Dagger engine that the concrete value should be pulled from inputs at runtime. While some values such as the registry target we saw above can be expressed purely in CUE, others such as directories, secrets, and sockets are required to be explicitly defined as _inputs_ to protect against malicious code being injected by third-party packages. If Dagger allowed such things to be stated in CUE, the entire package system could become a source of attacks.
List the inputs Dagger is aware of according to our plan: List the inputs Dagger is aware of according to our plan:
@ -178,29 +180,29 @@ dagger -e local input list
You should see the following output: You should see the following output:
```bash ```bash
Input Value Set by user Description Input Value Set by user Description
app.source dagger.#Artifact false Application source code app.source dagger.#Artifact false Application source code
todoapp.socket struct false Mount local docker socket run.socket struct false Mount local docker socket
``` ```
Notice that `Set by user` is false for both, because we have not yet provided Dagger with those values. Notice that `Set by user` is _false_ for both, because we have not yet provided Dagger with those values.
Let&rsquo;s provide them now: Let&rsquo;s provide them now:
```shell ```shell
dagger -e local input socket todoapp.socket /var/run/docker.sock dagger -e local input socket run.socket /var/run/docker.sock
dagger -e local input dir app.source ./ dagger -e local input dir app.source ./
``` ```
This defines the `todoapp.socket` as a `socket` input type, and the `app.source` input as a `dir` input type. This defines the `run.socket` as a `socket` input type, and the `app.source` input as a `dir` input type.
Now let's replay the `dagger input list` command: Now let&rsquo;s replay the `dagger input list` command:
```bash ```bash
Input Value Set by user Description Input Value Set by user Description
app.source dagger.#Artifact true Application source code app.source dagger.#Artifact true Application source code
todoapp.socket struct true Mount local docker socket run.socket struct true Mount local docker socket
``` ```
Notice that Dagger now reports that both inputs have been set. Notice that Dagger now reports that both inputs have been set.
@ -216,12 +218,12 @@ dagger up
Once complete you should get logs, and a final output like this: Once complete you should get logs, and a final output like this:
```bash ```bash
Output Value Description Output Value Description
app.build struct Build output directory app.build struct Build output directory
push.ref "localhost:5000/todoapp:latest@sha256:<hash>" Image ref push.ref "localhost:5000/todoapp:latest@sha256:<hash>" Image ref
push.digest "sha256:<hash>" Image digest push.digest "sha256:<hash>" Image digest
todoapp.ref "localhost:5000/todoapp:latest@sha256:<hash>" Image reference (e.g: nginx:alpine) run.ref "localhost:5000/todoapp:latest@sha256:<hash>" Image reference (e.g: nginx:alpine)
todoapp.run.env.IMAGE_REF "localhost:5000/todoapp:latest@sha256:<hash>" - run.run.env.IMAGE_REF "localhost:5000/todoapp:latest@sha256:<hash>" -
``` ```
Congratulations! You&rsquo;ve deployed your first Dagger plan! You can now open [http://localhost:8080](http://localhost:8080) in your browser! Congratulations! You&rsquo;ve deployed your first Dagger plan! You can now [view the todo app](http://localhost:8080) in your browser!