Looking to see if I am moving in the right direction. Looking to leverage consul to supplement some of our configuration values in our Terraform code. Basically looking to only leverage consul as a key/value store at this point that we manage with TF code, and then we will have other TF code that looks up those values. This seems like a super simplified use of consul, but I am just wondering if this is a good direction, or if there is something that might be better. Thanks!
1 Like
Sounds like a good idea.
Thanks for the reply!
Hey @donwlewis,
Thanks for posting! This is a really interesting use case. I would love to hear more about how you’re implementing this, if you want to share.
I would like to point out that there are limitations on Consul’s K/V. For a starting point, and likely well on the way to large requests, Consul KV can handle a fair bit of scale. That said - there is a known limitation on the k/v at 512kb. Depending on the number of look ups, blocking queries, and other scaling factors, you may outgrow the size.
Looking forward to hearing how you’re putting this all together!
Specifically we are looking to support storing data about our hub deployments in Azure. We are using a hub/spoke model, and we are using private link for everything. Therefore, our network/routing information gets a bit complicated. Our spokes are basically applications that are different depending on the apps team we are supporting. So we are trying to connect disconnected TF code together so that when we build out a spoke for our customers to deploy their application to, the spoke can get information about the hub without have to hardcode things like the hubs name and such in the TF code. We want to use consul to store that data since the data will be specific to each region that we have. Does this give some clarity as to what we are trying to do?
1 Like