diff --git a/docs/learn/1003-get-started.md b/docs/learn/1003-get-started.md index f2cedf10..c3fa1a3d 100644 --- a/docs/learn/1003-get-started.md +++ b/docs/learn/1003-get-started.md @@ -4,7 +4,7 @@ slug: /1003/get-started/ # 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’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 - inputs and outputs - 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 @@ -57,7 +57,7 @@ ls -la You will now see 2 new directories: - 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. @@ -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. -Let's first create a directory to hold our plan separately from our application code: +Let’s first create a directory to hold our Dagger plan separately from our application code: ```bash mkdir -p ./plans/local @@ -109,8 +109,8 @@ image: os.#Container & { // push the image to a registry push: docker.#Push & { - // leave target as a string here so that - // different environments can push to different registries + // leave target blank here so that different + // environments can push to different registries target: string // the source of our push resource @@ -133,7 +133,7 @@ import ( ) // run our todoapp in our local Docker engine -todoapp: docker.#Run & { +run: docker.#Run & { ref: push.ref name: "todoapp" ports: ["8080:80"] @@ -141,6 +141,8 @@ todoapp: docker.#Run & { } // push to our local registry +// this concrete value satisfies the string constraint +// we defined in the previous file push: target: "localhost:5000/todoapp" ``` @@ -167,7 +169,7 @@ local ...todoapp/.dagger/env/local ### 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: @@ -178,29 +180,29 @@ dagger -e local input list You should see the following output: ```bash -Input Value Set by user Description -app.source dagger.#Artifact false Application source code -todoapp.socket struct false Mount local docker socket +Input Value Set by user Description +app.source dagger.#Artifact false Application source code +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’s provide them now: ```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 ./ ``` -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’s replay the `dagger input list` command: ```bash -Input Value Set by user Description -app.source dagger.#Artifact true Application source code -todoapp.socket struct true Mount local docker socket +Input Value Set by user Description +app.source dagger.#Artifact true Application source code +run.socket struct true Mount local docker socket ``` 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: ```bash -Output Value Description -app.build struct Build output directory -push.ref "localhost:5000/todoapp:latest@sha256:" Image ref -push.digest "sha256:" Image digest -todoapp.ref "localhost:5000/todoapp:latest@sha256:" Image reference (e.g: nginx:alpine) -todoapp.run.env.IMAGE_REF "localhost:5000/todoapp:latest@sha256:" - +Output Value Description +app.build struct Build output directory +push.ref "localhost:5000/todoapp:latest@sha256:" Image ref +push.digest "sha256:" Image digest +run.ref "localhost:5000/todoapp:latest@sha256:" Image reference (e.g: nginx:alpine) +run.run.env.IMAGE_REF "localhost:5000/todoapp:latest@sha256:" - ``` -Congratulations! You’ve deployed your first Dagger plan! You can now open [http://localhost:8080](http://localhost:8080) in your browser! +Congratulations! You’ve deployed your first Dagger plan! You can now [view the todo app](http://localhost:8080) in your browser!