-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vault with Consul #55
Comments
++ I have the below configured on Datacenter A
I have the below configured on Datacenter B.
When I add a key from B, I can see the key being replicated in A and i am not able to read the value.
From Datacenter B
|
|
Setup from last link doesn't work with current version (latest binary, 0.2) of consul-replicate. See #54 |
@kak-tus I'd be surprised if it didn't work, since we're rolling that version, though we use a patched version to exclude keys. |
@ntnn Yes, replicating in both direction. |
@gvenka008c You have to deactivate consul-replicate in the leader dc and let the hot-standby dc's only replicate from the leader dc. |
@ntnn Just now looked at the consul info. One was master and other was standby. So is it good practice to run the consul-replicate outside the VM's where consul / vault was not setup? Thoughts? |
Do consul-replicate has any official docker image that can be used to run on a different VM for replication purpose? |
Possible, but that'd be wasted resources imho. What I did was letting a process check for the leader dc continuously and start/stop the replicate-agent accordingly. Locking is handled by consul as advised in the documentation. |
Is this managed through systemd service? I am running consul-replicate as a On Sep 14, 2016 4:59 PM, "Nelo-T. Wallus" [email protected] wrote:
|
Yes. |
It works, but I'd rather use a backend with a proper transaction log. |
Can you share the snippet if possible? On Sep 14, 2016 5:07 PM, "Nelo-T. Wallus" [email protected] wrote:
|
I'll check in with my superior tomorrow and get back to you. On 2016-09-14 14:27, Govindaraj wrote:
/"\ ASCII Ribbon Campaign |
@ntnn Also can't we have Active / Active setup? We wanted both the datacenters to accept traffic. If any data written in DC A has been be replicated in DC B and vice versa. Is that a possibility with consul-replicate? After running consul-replicate on both DC's now I am not able to read any data on both DC's
|
Also I stopped consul-replicate on datacenter A. Wrote the below key/value using Vault.
I ran the consul-replicate on datacenter B (which is not consul leader) and see the data being replicated on consul GUI When I run the Vault read command on datacenter B, I am getting the error as below
Thoughts? |
This is unsupported. It is not within the design parameters of Vault and is potentially dangerous. |
@jefferai Sorry, what is unsupported? |
I stopped consul-replicate on datacenter A. Wrote the below key/value using Vault.
I ran the consul-replicate on datacenter B (which is not consul leader) and see the data being replicated on consul GUI When I run the Vault read command on datacenter B, I am getting the error as below
Thoughts? |
@gvenka008c consul-replicate does not support master-master replication. It's only set up to pull in one direction. There are some limited cases where people use consul-replicate with Vault (see hashicorp/vault#633), but it definitely does not support the use case you are going for here with a bidirectional sync, you could lose data or otherwise corrupt Vault's store. |
@slackpad If you see my previous experiment, I stopped master-master replication. It's is setup on only one Data Center. I didn't do a bidirectional sync. |
@gvenka008c I haven't gotten the permission to share details, but I'm allowed to write an article detailing the problem at hand. I'm writing this down and send you a link after I've published it. The problem and resolution is reasonably simple, so if you're under pressure I'd say don't wait for it. The approval of the article might take a week. |
@ntnn Did you had a chance to publish the article? Thanks. |
How does Vault on Datacenter B know that Vault on Datacenter A is already initialized. I followed the document as outlined below http://sysadminsjourney.com/blog/2015/10/30/replicating-hashicorp-vault-in-a-multi-datacenter-setup/ But when I do the below on Datacenter B, i get message as server is not yet initialized. Is there any other data that needs to be copied to ensure a sync up of Vault on DC B with DC A?
Thoughts? Thanks. |
Ah yes, sorry. I forgot about that, I'll haven't heard back about the article, but I'll take care of that today. If I get the approvement it'll be up later today. |
@gvenka008c Got the approvement, though I had to make some adjustment. Here's the post: Primarly note the last two points. |
@ntnn In described setup you have only one vault leader in all DCs. I can't understand how vault elects leader in cross DC setup in your case. In my setup I have vault leader in every DC. And one of the DCs is manually selected by me as master, so I do writes to vaults in this DC. And vaults in other DC's is for read only and replicated from master DC. |
@kak-tus It doesn't. First vault leader to be elected and achieve the lock wins. In my tests I've seen that this works pretty well, the lan clusters usually had a gap big enough before getting to achieve a consensus - and afterwards the leader is set. The problem with the read-only slave-masters in other dc's is that you might get stale secrets and you can't actually restrict not writing to those slaves. |
@ntnn After some tries I can't get it work. Vault in your setup is configured to local consul on each node (as example consul.service.consul)? My actions:
Consul 0.7 Vault config (same in both DC's)
Consul config
P.S. in article you say "the replication has to be done before initializing vault". It means: before initializing vault in second (target) DC or before initializing vault in first (source) DC? |
On 2016-10-25 14:25, Andrey Kuzmin wrote:
The replication has to be prepared and verified working before The rough workflow for setting up a completely new vault cluster is:
After the initialization the consul LAN cluster propagates the k/v After that adding and removing nodes is just a matter of deployment. You only have to initialize one node in one DC, the replication - if set In my tests so far it didn't matter if your consul nodes are local or Though if you have the resources I'd suggest to use an instance of the
/"\ ASCII Ribbon Campaign |
@ntnn Thank you for detailed answer, but it is not work for me. :-( I have created two new test WAN clusters. After that vault node in dc1 began a leader. Node in dc2 shows "Mode: sealed". I think, you have some more different vault configuration than config in documentation. |
@ntnn I can't get it work even with new consul-replicate version (with exclude option). replicate config (I also tried to exclude vault/core/leader) consul config (same in both dc) vault config (vault looks at local consul agent) In my current try, when start vault I have seen some strange notice in log
|
Hey @ntnn, In your article you said :
What other backend do you have in mind ? I was thinking about Cassandra, that supports cross-dc replication, and is supported as a secret backend but not as a storage backend. It's unfortunate that it can't be used for both. This architecture looks also complex to build but Hashicorp says that it's the recommended backend to use for HA as it is what their supported customers use. |
@kak-tus Sorry for coming back so late - the raft protocol works best with an uneven number of nodes, that's probably what you're encountering there. @cscetbon I'm looking towards etcd, DynamoDB or Zookeeper. You could, of course, write a backend plug for cassandra and submit it to be added to the list of community-supported backends. |
I am working on a vault multi DC setup with consul as backend storage. I followed hashicorp/vault#674. |
Hi,
We have Vault integrated with Consul. We normally write all our key/value in the secret path as shown below.
How can this be used in consul-replicate? I see the data is stored under /vault/logical in Consul. (see attached)
Here is the sample config file for consul-replicate
./consul-replicate -config=/srv/consul/consul_replicate.hcl
The text was updated successfully, but these errors were encountered: