Updated some language and formatting in the dev-server guide
This commit is contained in:
parent
49dd4f70df
commit
3a981ae7b4
|
@ -16,16 +16,16 @@ storage and backends. All operations done via the Vault CLI interact
|
|||
with the server over a TLS connection.
|
||||
|
||||
In this page, we'll start and interact with the Vault server to understand
|
||||
how the server is started, and understanding the seal/unseal process.
|
||||
how the server is started.
|
||||
|
||||
## Starting the Dev Server
|
||||
|
||||
To start, we're going to start the Vault _dev server_. The dev server
|
||||
is a built-in flag to start a pre-configured server that is not very
|
||||
secure but useful for playing with Vault locally. Later in the getting
|
||||
started guide we'll configure and start a real server.
|
||||
First, we're going to start a Vault _dev server_. The dev server
|
||||
is a built-in, pre-configured server that is not very
|
||||
secure but useful for playing with Vault locally. Later in this guide
|
||||
we'll configure and start a real server.
|
||||
|
||||
To start the Vault dev server, run `vault server -dev`:
|
||||
To start the Vault dev server, run:
|
||||
|
||||
```
|
||||
$ vault server -dev
|
||||
|
@ -62,33 +62,39 @@ another shell.
|
|||
|
||||
As you can see, when you start a dev server, Vault warns you loudly. The dev
|
||||
server stores all its data in-memory (but still encrypted), listens on
|
||||
localhost without TLS, and automatically unseals and shows you the unseal key
|
||||
`localhost` without TLS, and automatically unseals and shows you the unseal key
|
||||
and root access key. We'll go over what all this means shortly.
|
||||
|
||||
The important thing about the dev server is that it is meant for
|
||||
development only. **Do not run the dev server in production.** Even if it
|
||||
was run in production, it wouldn't be very useful since it stores data in-memory
|
||||
and every restart would clear all your secrets.
|
||||
development only.
|
||||
|
||||
-> **Note:** Do not run the dev server in production.
|
||||
|
||||
Even if the dev server was run in production, it wouldn't be very useful
|
||||
since it stores data in-memory and every restart would clear all your
|
||||
secrets.
|
||||
|
||||
With the dev server running, do the following three things before anything
|
||||
else:
|
||||
|
||||
1. Copy and run the `export VAULT_ADDR ...` command from your terminal
|
||||
1. Launch a new terminal session.
|
||||
|
||||
2. Copy and run the `export VAULT_ADDR ...` command from the terminal
|
||||
output. This will configure the Vault client to talk to our dev server.
|
||||
|
||||
2. Save the unseal key somewhere. Don't worry about _how_ to save this
|
||||
3. Save the unseal key somewhere. Don't worry about _how_ to save this
|
||||
securely. For now, just save it anywhere.
|
||||
|
||||
3. Do the same as step 2, but with the root token. We'll use this later.
|
||||
4. Do the same as step 3, but with the root token. We'll use this later.
|
||||
|
||||
## Verify the Server is Running
|
||||
|
||||
Verify the server is running by running `vault status`. This should
|
||||
Verify the server is running by running the `vault status` command. This should
|
||||
succeed and exit with exit code 0. If you see an error about opening
|
||||
a connection, make sure you copied and executed the `export VAULT_ADDR...`
|
||||
command from above properly.
|
||||
|
||||
If it ran successfully, the output should look like below:
|
||||
If it ran successfully, the output should look like the below:
|
||||
|
||||
```
|
||||
$ vault status
|
||||
|
|
Loading…
Reference in a new issue