diff --git a/doc/book/src/getting_started/bucket.md b/doc/book/src/getting_started/bucket.md index 8b05ee2..b22ce78 100644 --- a/doc/book/src/getting_started/bucket.md +++ b/doc/book/src/getting_started/bucket.md @@ -1,71 +1,78 @@ # Create buckets and keys -First, chances are that your garage deployment is secured by TLS. -All your commands must be prefixed with their certificates. -I will define an alias once and for all to ease future commands. -Please adapt the path of the binary and certificates to your installation! +*We use a command named `garagectl` which is in fact an alias you must define as explained in the [Control the daemon](./daemon.md) section.* -``` -alias grg="/garage/garage --ca-cert /secrets/garage-ca.crt --client-cert /secrets/garage.crt --client-key /secrets/garage.key" -``` - -Now we can check that everything is going well by checking our cluster status: - -``` -grg status -``` +In this section, we will suppose that we want to create a bucket named `nextcloud-bucket` +that will be accessed through a key named `nextcloud-app-key`. Don't forget that `help` command and `--help` subcommands can help you anywhere, the CLI tool is self-documented! Two examples: ``` -grg help -grg bucket allow --help +garagectl help +garagectl bucket allow --help ``` +## Create a bucket + Fine, now let's create a bucket (we imagine that you want to deploy nextcloud): ``` -grg bucket create nextcloud-bucket +garagectl bucket create nextcloud-bucket ``` Check that everything went well: ``` -grg bucket list -grg bucket info nextcloud-bucket +garagectl bucket list +garagectl bucket info nextcloud-bucket ``` +## Create an API key + Now we will generate an API key to access this bucket. Note that API keys are independent of buckets: one key can access multiple buckets, multiple keys can access one bucket. Now, let's start by creating a key only for our PHP application: ``` -grg key new --name nextcloud-app-key +garagectl key new --name nextcloud-app-key ``` You will have the following output (this one is fake, `key_id` and `secret_key` were generated with the openssl CLI tool): -``` -Key { key_id: "GK3515373e4c851ebaad366558", secret_key: "7d37d093435a41f2aab8f13c19ba067d9776c90215f56614adad6ece597dbb34", name: "nextcloud-app-key", name_timestamp: 1603280506694, deleted: false, authorized_buckets: [] } +```javascript +Key { + key_id: "GK3515373e4c851ebaad366558", + secret_key: "7d37d093435a41f2aab8f13c19ba067d9776c90215f56614adad6ece597dbb34", + name: "nextcloud-app-key", + name_timestamp: 1603280506694, + deleted: false, + authorized_buckets: [] +} ``` Check that everything works as intended (be careful, info works only with your key identifier and not with its friendly name!): ``` -grg key list -grg key info GK3515373e4c851ebaad366558 +garagectl key list +garagectl key info GK3515373e4c851ebaad366558 ``` +## Allow a key to access a bucket + Now that we have a bucket and a key, we need to give permissions to the key on the bucket! ``` -grg bucket allow --read --write nextcloud-bucket --key GK3515373e4c851ebaad366558 +garagectl bucket allow \ + --read \ + --write + nextcloud-bucket \ + --key GK3515373e4c851ebaad366558 ``` You can check at any times allowed keys on your bucket with: ``` -grg bucket info nextcloud-bucket +garagectl bucket info nextcloud-bucket ``` diff --git a/doc/book/src/getting_started/cluster.md b/doc/book/src/getting_started/cluster.md index a17bf14..af6e8f1 100644 --- a/doc/book/src/getting_started/cluster.md +++ b/doc/book/src/getting_started/cluster.md @@ -1,14 +1,72 @@ # Configure a cluster +*We use a command named `garagectl` which is in fact an alias you must define as explained in the [Control the daemon](./daemon.md) section.* + +In this section, we will inform garage of the disk space available on each node of the cluster +as well as the site (think datacenter) of each machine. + ## Test cluster +As this part is not relevant for a test cluster, you can use this one-liner to create a basic topology: + +```bash +garagectl status | grep UNCONFIGURED | grep -Po '^[0-9a-f]+' | while read id; do + garagectl node configure -d dc1 -n 10 $id +done +``` + ## Real-world cluster -For our example, we will suppose we have the following infrastructure: +For our example, we will suppose we have the following infrastructure (Tokens, Identifier and Datacenter are specific values to garage described in the following): -| Location | Name | IP Address | Disk Space | -|----------|---------|------------|------------| -| Paris | Mercury | fc00:1::1 | 1 To | -| Paris | Venus | fc00:1::2 | 2 To | -| London | Earth | fc00:1::2 | 2 To | -| Brussels | Mars | fc00:B::1 | 1.5 To | +| Location | Name | Disk Space | `Tokens` | `Identifier` | `Datacenter` | +|----------|---------|------------|----------|--------------|--------------| +| Paris | Mercury | 1 To | `100` | `8781c5` | `par1` | +| Paris | Venus | 2 To | `200` | `2a638e` | `par1` | +| London | Earth | 2 To | `200` | `68143d` | `lon1` | +| Brussels | Mars | 1.5 To | `150` | `212f75` | `bru1` | + +### Identifier + +After its first launch, garage generates a random and unique identifier for each nodes, such as: + +``` +8781c50c410a41b363167e9d49cc468b6b9e4449b6577b64f15a249a149bdcbc +``` + +Often a shorter form can be used, containing only the beginning of the identifier, like `8781c5`, +which identifies the server "Mercury" located in "Paris" according to our previous table. + +The most simple way to match an identifier to a node is to run: + +``` +garagectl status +``` + +It will display the IP address associated with each node; from the IP address you will be able to recognize the node. + +### Tokens + +Garage reasons on an arbitrary metric about disk storage that is named "tokens". +The number of tokens must be proportional to the disk space dedicated to the node. +Additionaly, ideally the number of tokens must be in the order of magnitude of 100 +to provide a good trade-off between data load balancing and performances (*this sentence must be verified, it may be wrong*). + +Here we chose 1 token = 10 Go but you are free to select the value that best fit your needs. + +### Datacenter + +Datacenter are simply a user-chosen identifier that identify a group of server that are located in the same place. +It is up to the system administrator deploying garage to identify what does "the same place" means. +Behind the scene, garage will try to store the same data on different sites to provide high availability despite a data center failure. + +### Inject the topology + +Given the information above, we will configure our cluster as follow: + +``` +garagectl node configure --datacenter par1 -n 100 -t mercury 8781c5 +garagectl node configure --datacenter par1 -n 200 -t venus 2a638e +garagectl node configure --datacenter lon1 -n 200 -t earth 68143d +garagectl node configure --datacenter bru1 -n 150 -t mars 212f75 +``` diff --git a/doc/book/src/getting_started/control.md b/doc/book/src/getting_started/control.md new file mode 100644 index 0000000..9a66a0d --- /dev/null +++ b/doc/book/src/getting_started/control.md @@ -0,0 +1,77 @@ +# Control the daemon + +The `garage` binary has two purposes: + - it acts as a daemon when launched with `garage server ...` + - it acts as a control tool for the daemon when launched with any other command + +In this section, we will see how to use the `garage` binary as a control tool for the daemon we just started. +You first need to get a shell having access to this binary, which depends of your configuration: + - with `docker-compose`, run `sudo docker-compose exec g1 bash` then `/garage/garage` + - with `docker`, run `sudo docker exec -ti garaged bash` then `/garage/garage` + - with `systemd`, simply run `/usr/local/bin/garage` if you followed previous instructions + +*You can also install the binary on your machine to remotely control the cluster.* + +## Talk to the daemon and create an alias + +`garage` requires 4 options to talk with the daemon: + +``` +--ca-cert +--client-cert +--client-key +-h, --rpc-host +``` + +The 3 first ones are certificates and keys needed by TLS, the last one is simply the address of garage's RPC endpoint. +Because we configure garage directly from the server, we do not need to set `--rpc-host`. +To avoid typing the 3 first options each time we want to run a command, we will create an alias. + +### `docker-compose` alias + +```bash +alias garagectl='/garage/garage \ + --ca-cert /pki/garage-ca.crt \ + --client-cert /pki/garage.crt \ + --client-key /pki/garage.key' +``` + +### `docker` alias + +```bash +alias garagectl='/garage/garage \ + --ca-cert /etc/garage/pki/garage-ca.crt \ + --client-cert /etc/garage/pki/garage.crt \ + --client-key /etc/garage/pki/garage.key' +``` + + +### raw binary alias + +```bash +alias garagectl='/usr/local/bin/garage \ + --ca-cert /etc/garage/pki/garage-ca.crt \ + --client-cert /etc/garage/pki/garage.crt \ + --client-key /etc/garage/pki/garage.key' +``` + +Of course, if your deployment does not match exactly one of this alias, feel free to adapt it to your needs! + +## Test the alias + +You can test your alias by running a simple command such as: + +``` +garagectl status +``` + +You should get something like that as result: + +``` +Healthy nodes: +2a638ed6c775b69a… 37f0ba978d27 [::ffff:172.20.0.101]:3901 UNCONFIGURED/REMOVED +68143d720f20c89d… 9795a2f7abb5 [::ffff:172.20.0.103]:3901 UNCONFIGURED/REMOVED +8781c50c410a41b3… 758338dde686 [::ffff:172.20.0.102]:3901 UNCONFIGURED/REMOVED +``` + +...which means that you are ready to configure your cluster! diff --git a/doc/book/src/getting_started/daemon.md b/doc/book/src/getting_started/daemon.md index 7c303c6..2f2b71b 100644 --- a/doc/book/src/getting_started/daemon.md +++ b/doc/book/src/getting_started/daemon.md @@ -171,6 +171,7 @@ On each machine, you can run the daemon with: ```bash docker run \ -d \ + --name garaged \ --restart always \ --network host \ -v /etc/garage/pki:/etc/garage/pki \