mirror of
https://github.com/edgelesssys/constellation.git
synced 2025-07-28 17:54:09 -04:00
docs: refer to apply command instead of init or upgrade apply (#2487)
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
This commit is contained in:
Daniel Weiße
GitHub
parent
fff35bdb2a
commit
f4bfbe3564
18 changed files with 49 additions and 40 deletions
|
|
@ -90,7 +90,7 @@ Any changes to the image will inevitably also change the measured boot's PCR val
|
|||
To create a node attestation statement, the Constellation image obtains a CVM attestation statement from the hardware.
|
||||
This includes the runtime measurements and thereby binds the measured boot results to the CVM hardware measurement.
|
||||
|
||||
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../workflows/create.md#the-init-step) that irrevocably marks the node as initialized.
|
||||
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../workflows/create.md#the-apply-step) that irrevocably marks the node as initialized.
|
||||
The measurement is created using the [*clusterID*](../architecture/keys.md#cluster-identity), tying all future attestation statements to this ID.
|
||||
Thereby, an attestation statement is unique for every cluster and a node can be identified unambiguously as being initialized.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ In addition, the cluster's [identifier](orchestration.md#post-installation-confi
|
|||
2. Each CVM boots the Constellation node image and measures every component in the boot chain
|
||||
3. The first microservice launched in each node is the [*Bootstrapper*](microservices.md#bootstrapper)
|
||||
4. The *Bootstrapper* waits until it either receives an initialization request or discovers an initialized cluster
|
||||
5. The CLI `init` command connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
|
||||
5. The CLI `apply` command connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
|
||||
6. The *Bootstrapper* of **that** node [initializes the Kubernetes cluster](microservices.md#bootstrapper) and deploys the other Constellation [microservices](microservices.md) including the [*JoinService*](microservices.md#joinservice)
|
||||
7. Subsequently, the *Bootstrappers* of the other nodes discover the initialized cluster and send join requests to the *JoinService*
|
||||
8. As part of the join request each node includes an attestation statement of its boot measurements as authentication
|
||||
|
|
|
|||
|
|
@ -116,16 +116,17 @@ attaching persistent storage, or autoscaling aren't available.
|
|||
3. Initialize the cluster
|
||||
|
||||
```bash
|
||||
constellation init
|
||||
constellation apply
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation init
|
||||
$ constellation apply
|
||||
Your Constellation master secret was successfully written to ./constellation-mastersecret.json
|
||||
Note: If you just created the cluster, it can take a few minutes to connect.
|
||||
Initializing cluster ...
|
||||
Connecting
|
||||
Initializing cluster
|
||||
Installing Kubernetes components
|
||||
Your Constellation cluster was successfully initialized.
|
||||
|
||||
Constellation cluster identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
|
||||
|
|
@ -141,7 +142,7 @@ attaching persistent storage, or autoscaling aren't available.
|
|||
|
||||
:::info
|
||||
|
||||
Depending on your setup, `constellation init` may take 10+ minutes to complete.
|
||||
Depending on your setup, `constellation apply` may take 10+ minutes to complete.
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -141,16 +141,17 @@ If you encounter any problem with the following steps, make sure to use the [lat
|
|||
4. Initialize the cluster.
|
||||
|
||||
```bash
|
||||
constellation init
|
||||
constellation apply
|
||||
```
|
||||
|
||||
This should give the following output:
|
||||
|
||||
```shell-session
|
||||
$ constellation init
|
||||
$ constellation apply
|
||||
Your Constellation master secret was successfully written to ./constellation-mastersecret.json
|
||||
Note: If you just created the cluster, it can take a few minutes to connect.
|
||||
Initializing cluster ...
|
||||
Connecting
|
||||
Initializing cluster
|
||||
Installing Kubernetes components
|
||||
Your Constellation cluster was successfully initialized.
|
||||
|
||||
Constellation cluster identifier g6iMP5wRU1b7mpOz2WEISlIYSfdAhB0oNaOg6XEwKFY=
|
||||
|
|
@ -166,7 +167,7 @@ If you encounter any problem with the following steps, make sure to use the [lat
|
|||
|
||||
:::info
|
||||
|
||||
Depending on your CSP and region, `constellation init` may take 10+ minutes to complete.
|
||||
Depending on your CSP and region, `constellation apply` may take 10+ minutes to complete.
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ terraform init
|
|||
terraform apply
|
||||
```
|
||||
|
||||
The Constellation [init step](#the-init-step) requires the already created `constellation-config.yaml` and the `constellation-state.yaml`.
|
||||
The Constellation [apply step](#the-apply-step) requires the already created `constellation-config.yaml` and the `constellation-state.yaml`.
|
||||
Create the `constellation-state.yaml` using the output from the Terraform state and the `constellation-conf.yaml`:
|
||||
|
||||
```bash
|
||||
|
|
@ -199,12 +199,12 @@ Continue with [initializing your cluster](#the-init-step).
|
|||
</tabItem>
|
||||
</tabs>
|
||||
|
||||
## The *init* step
|
||||
## The *apply* step
|
||||
|
||||
The following command initializes and bootstraps your cluster:
|
||||
|
||||
```bash
|
||||
constellation init
|
||||
constellation apply
|
||||
```
|
||||
|
||||
Next, configure `kubectl` for your cluster:
|
||||
|
|
@ -215,6 +215,6 @@ export KUBECONFIG="$PWD/constellation-admin.conf"
|
|||
|
||||
🏁 That's it. You've successfully created a Constellation cluster.
|
||||
|
||||
|
||||
### Troubleshooting
|
||||
In case `init` fails, the CLI collects logs from the bootstrapping instance and stores them inside `constellation-cluster.log`.
|
||||
|
||||
In case `apply` fails, the CLI collects logs from the bootstrapping instance and stores them inside `constellation-cluster.log`.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ constellation terminate --yes
|
|||
```
|
||||
|
||||
This deletes all resources created by Constellation in your cloud environment.
|
||||
All local files created by the `create` and `init` commands are deleted as well, except for `constellation-mastersecret.json` and the configuration file.
|
||||
All local files created by the `create` and `apply` commands are deleted as well, except for `constellation-mastersecret.json` and the configuration file.
|
||||
|
||||
:::caution
|
||||
|
||||
|
|
|
|||
|
|
@ -65,12 +65,12 @@ kubectl patch configmaps -n kube-system join-config -p "{\"data\":{\"attestation
|
|||
|
||||
:::
|
||||
|
||||
You can use the `upgrade apply` command to change measurements of a running cluster:
|
||||
You can use the `apply` command to change measurements of a running cluster:
|
||||
|
||||
1. Modify the `measurements` key in your local `constellation-conf.yaml` to the expected values.
|
||||
2. Run `constellation upgrade apply`.
|
||||
2. Run `constellation apply`.
|
||||
|
||||
Keep in mind that running `upgrade apply` also applies any version changes from your config to the cluster.
|
||||
Keep in mind that running `apply` also applies any version changes from your config to the cluster.
|
||||
|
||||
You can run these commands to learn about the versions currently configured in the cluster:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Constellation provides an easy way to upgrade all components of your cluster, without disrupting it's availability.
|
||||
Specifically, you can upgrade the Kubernetes version, the nodes' image, and the Constellation microservices.
|
||||
You configure the desired versions in your local Constellation configuration and trigger upgrades with the `upgrade apply` command.
|
||||
You configure the desired versions in your local Constellation configuration and trigger upgrades with the `apply` command.
|
||||
To learn about available versions you use the `upgrade check` command.
|
||||
Which versions are available depends on the CLI version you are using.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ When using this flag, the `kubernetesVersion`, `image`, `microserviceVersion`, a
|
|||
Once you updated your config with the desired versions, you can trigger the upgrade with this command:
|
||||
|
||||
```bash
|
||||
constellation upgrade apply
|
||||
constellation apply
|
||||
```
|
||||
|
||||
Microservice upgrades will be finished within a few minutes, depending on the cluster size.
|
||||
|
|
@ -73,7 +73,7 @@ The phases are `infrastracture` for the cloud resource management through Terraf
|
|||
## Check the status
|
||||
|
||||
Upgrades are asynchronous operations.
|
||||
After you run `upgrade apply`, it will take a while until the upgrade has completed.
|
||||
After you run `apply`, it will take a while until the upgrade has completed.
|
||||
To understand if an upgrade is finished, you can run:
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ If attestation fails for a new node, it isn't permitted to join the cluster.
|
|||
## The *verify* command
|
||||
|
||||
:::note
|
||||
The steps below are purely optional. They're automatically executed by `constellation init` when you initialize your cluster. The `constellation verify` command mostly has an illustrative purpose.
|
||||
The steps below are purely optional. They're automatically executed by `constellation apply` when you initialize your cluster. The `constellation verify` command mostly has an illustrative purpose.
|
||||
:::
|
||||
|
||||
The `verify` command obtains and verifies an attestation statement from a running Constellation cluster.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue