cleanup unnecessary file
Signed-off-by: Richard Jones <richard@dagger.io>
This commit is contained in:
Richard Jones
parent
a1c2d14162
commit
33242a1a7d
@ -1,126 +0,0 @@
|
||||
---
|
||||
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.
|
||||
|
||||
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)
|
||||
|
||||
In this tutorial we will learn how to:
|
||||
- Structure a Dagger project
|
||||
- Write CUE for Dagger
|
||||
- Deploy an application using Dagger
|
||||
|
||||
## Initial setup
|
||||
|
||||
### Install Dagger
|
||||
|
||||
First, make sure [you have installed Dagger on your local machine](../1001-install.md).
|
||||
|
||||
### Setup example app
|
||||
|
||||
You will need a local copy of the [Dagger examples repository](https://github.com/dagger/examples).
|
||||
NOTE: you may use the same local copy across all tutorials.
|
||||
|
||||
```shell
|
||||
git clone https://github.com/dagger/examples
|
||||
```
|
||||
|
||||
Make sure that all commands are run from the `todoapp` directory:
|
||||
|
||||
```shell
|
||||
cd examples/todoapp
|
||||
```
|
||||
|
||||
### Import the tutorial key
|
||||
|
||||
Dagger natively supports encrypted secrets: when a user inputs a value marked as secret
|
||||
(for example, a password, API token, or ssh key) it is automatically encrypted with that user's key,
|
||||
and no other user can access that value unless they are explicitly given access.
|
||||
|
||||
In the interest of security, Dagger has no way _not_ to encrypt a secret value.
|
||||
But this causes a dilemma for this tutorial: how do we give unrestricted, public access to our
|
||||
(carefully sandboxed) infrastructure so that anyone can deploy to it?
|
||||
|
||||
To solve this dilemma, we included the private key used to encrypt the tutorial's secret inputs.
|
||||
Import the key to your Dagger installation, and you're good to go:
|
||||
|
||||
```shell
|
||||
./import-tutorial-key.sh
|
||||
```
|
||||
|
||||
## First deployment
|
||||
|
||||
Now that your environment is set up, you are ready to deploy:
|
||||
|
||||
```shell
|
||||
dagger up
|
||||
```
|
||||
|
||||
That's it! You have just made your first deployment with Dagger.
|
||||
|
||||
The URL of your newly deployed app should be visible towards the end of the command output.
|
||||
If you visit that URL, you should see your application live!
|
||||
|
||||
## Code, deploy, repeat
|
||||
|
||||
This environment is pre-configured to deploy from the `./todoapp` directory,
|
||||
so you can make any change you want to that directory, then deploy it with `dagger up`.
|
||||
You can even replace our example React code with any React application!
|
||||
|
||||
NOTE: you don't have to commit your changes to the git repository before deploying them.
|
||||
|
||||
## Under the hood
|
||||
|
||||
This example showed you how to deploy and develop an application that is already configured with Dagger. Now, let's learn a few concepts to help you understand how this was put together.
|
||||
|
||||
### The Environment
|
||||
|
||||
An Environment holds the entire deployment configuration.
|
||||
|
||||
You can list existing environment from the `./todoapp` directory:
|
||||
|
||||
```shell
|
||||
dagger list
|
||||
```
|
||||
|
||||
You should see an environment named `s3`. You can have many environments within your app. For instance, one for `staging`, one for `dev`, etc...
|
||||
|
||||
Each environment can have a different kind of deployment code. For example, a `dev` environment can deploy locally; a `staging` environment can deploy to a remote infrastructure, and so on.
|
||||
|
||||
### The plan
|
||||
|
||||
The plan is the deployment code that includes the logic to deploy the local application to an AWS S3 bucket. From the `todoapp` directory, you can list the code of the plan:
|
||||
|
||||
```shell
|
||||
ls -l ./s3
|
||||
```
|
||||
|
||||
Any code change to the plan will be applied during the next `dagger up`.
|
||||
|
||||
### The inputs
|
||||
|
||||
The plan can define one or several `inputs`. Inputs may be configuration values, artifacts, or encrypted secrets provided by the user. Here is how to list the current inputs:
|
||||
|
||||
```shell
|
||||
dagger input list
|
||||
```
|
||||
|
||||
The inputs are persisted inside the `.dagger` directory and pushed to your git repository. That's why this example application worked out of the box.
|
||||
|
||||
### The outputs
|
||||
|
||||
The plan defines one or several `outputs`. They can show helpful information at the end of the deployment. That's how we read the deploy `url` at the end of the deployment. Here is the command to list all outputs:
|
||||
|
||||
```shell
|
||||
dagger output list
|
||||
```
|
||||
|
||||
## What's next?
|
||||
|
||||
At this point, you have deployed your first application using Dagger and learned some dagger commands. You are now ready to [learn more about how to program Dagger](./1004-first-env.md).
|
||||
Reference in New Issue
Block a user