Pre-generate Node Id/keys #929

Open
opened 2025-01-21 18:47:18 +00:00 by zevrant · 0 comments

Currently node keys are generated on initial start, which is great but i would like to pregenerate those keys and be able to set them prior to the initial boot to better be able to utilize the bootstrap_peers parameter in the garage.toml.

The end goal here is to be able to deploy a garage cluster without the need to utilize any form of service discovery, or using post startup scripts/pipelines/cicd tools to setup the cluster to talk to one another.

Essentially so render a template prior to deployment like below and then just configure the cluster layout.

I've considered spinning up a vm or container with the same hostname and grabbing the config but that seems a bit of a hacky workaround and adds additional steps that I'm trying to avoid

Note this is a VM deployment not container based, and without the need for the additional overhead required by something like Consul.

I'm open to alternative approaches if one exists.

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"
metadata_auto_snapshot_interval = "6h"

replication_factor = 1

compression_level = 2

bootstrap_peers = [
    ${bootstrap_peer_1},
    ${bootstrap_peer_2}
]

rpc_bind_addr = "ip_address:3901"
rpc_secret = "rpc_password."
rpc_public_addr = "ip_address:3901"
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = "s3.example.com"

[s3_web]
bind_addr = "[::]:3902"
root_domain = "s3-console.example.com"
index = "index.html"

[admin]
api_bind_addr = "[::]:3904"
Currently node keys are generated on initial start, which is great but i would like to pregenerate those keys and be able to set them prior to the initial boot to better be able to utilize the `bootstrap_peers` parameter in the garage.toml. The end goal here is to be able to deploy a garage cluster without the need to utilize any form of service discovery, or using post startup scripts/pipelines/cicd tools to setup the cluster to talk to one another. Essentially so render a template prior to deployment like below and then just configure the cluster layout. I've considered spinning up a vm or container with the same hostname and grabbing the config but that seems a bit of a hacky workaround and adds additional steps that I'm trying to avoid Note this is a VM deployment not container based, and without the need for the additional overhead required by something like Consul. I'm open to alternative approaches if one exists. ``` metadata_dir = "/var/lib/garage/meta" data_dir = "/var/lib/garage/data" db_engine = "sqlite" metadata_auto_snapshot_interval = "6h" replication_factor = 1 compression_level = 2 bootstrap_peers = [ ${bootstrap_peer_1}, ${bootstrap_peer_2} ] rpc_bind_addr = "ip_address:3901" rpc_secret = "rpc_password." rpc_public_addr = "ip_address:3901" [s3_api] s3_region = "garage" api_bind_addr = "[::]:3900" root_domain = "s3.example.com" [s3_web] bind_addr = "[::]:3902" root_domain = "s3-console.example.com" index = "index.html" [admin] api_bind_addr = "[::]:3904" ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#929
No description provided.