Vagrant and event store

EventStoreDB
1

I’ve put together this little experiment of mine, https://github.com/mastoj/winpuppet, where I plan to provision a windows server with event store (and elasticsearch and other stuff). As of know I can’t access the event store or elasticsearch service due to the firewall on the windows server which I discovered I need to turn off right before I went to work this morning. After turning the firewall off in the virtual windows server I can access the elasticsearch service, but I still can’t access the event store service even though I do port forward 2113. I’ve checked that the event store service is running, it’s accessible if I log into the virtual machine and visit localhost/127.0.0.1:2113, but I can’t do the same from my local machine. Why is it so?

I know I can fix this by configuring the network of the virtual machine and adding some configuration parameters to event store in my config here: https://github.com/mastoj/winpuppet/blob/master/modules/eventstore/files/eventstore.json, but I want to do if I do something wrong since I can’t access event store on the virtual server from my hosting machine, or if it is so be design?

2

Probably you need to add an alias it will understand e.g.:
--http-prefixes this is common with systems like azure where you come
in from a different ip that its actually listening on.

3

I know I probably could do that, but if I have a virtual machine and have set up NAT networking on the machine. Shouldn’t I just be able to go to localhost:2113 or 127.0.0.1:2113 given that I’ve forward those ports to the virtual machine? That works fine for my elasticsearch service, so I thought it would for event store as well.

–Tomas

4

I have to agree with MS on this one in that you probably want to opt
in to start receiving requests that appear from other hosts. That said
there are prefixes you can use such as http://*:2113/

5

Basically your answer is, it’s be design, or by design in the sense of that’s how it works in the network abstraction you depend on from the MS stack? Good to know, I just wanted to make sure that you also where aware of it. For me it’s no problem since I think the product is really awesome, but these small things that makes it harder to get started might scare some people.

6

The answer is that and "there is an easy way to opt in"

7

Can you opt in for the tcp part as well? It seems like it won’t connect through the native .NET api when I run the event store in the VM and NAT networking.

8

Not sure if that is the problem, but when I do run event store in the vagrant vm I get the following error in the client:

[15,05:56:36.401,DEBUG] TcpPackageConnection: connection [127.0.0.1:1113, L127.0

.0.1:57485, {b004d5a0-7e3d-4ad2-a05d-f79df4697526}] was closed cleanly.

[18,05:56:36.599,DEBUG] TcpPackageConnection: connected to [127.0.0.1:1113, L127

.0.0.1:57486, {25c0513d-9a58-4ed5-9115-050a0f1ed4e5}].

[13,05:56:39.034,INFO] EventStoreConnection 'ES-6fce9907-afdd-4c25-a288-0edba3c7

fd52’: closing TCP connection [127.0.0.1:1113, L127.0.0.1:57486, {25c0513d-9a58-

4ed5-9115-050a0f1ed4e5}] due to HEARTBEAT TIMEOUT at pkgNum 0.

[13,05:56:39.034,INFO] ClientAPI TcpConnection closed [05:56:39.034: N127.0.0.1:

1113, L127.0.0.1:57486, {25c0513d-9a58-4ed5-9115-050a0f1ed4e5}]:

Received bytes: 0, Sent bytes: 59

Send calls: 2, callbacks: 2

Receive calls: 1, callbacks: 0

Close reason: [Success] EventStoreConnection 'ES-6fce9907-afdd-4c25-a288-0edba3c

7fd52’: closing TCP connection [127.0.0.1:1113, L127.0.0.1:57486, {25c0513d-9a58

-4ed5-9115-050a0f1ed4e5}] due to HEARTBEAT TIMEOUT at pkgNum 0.

If I run event store on the host with exactly the same configuration everything works just fine.

9

Now I had some more time to test. It seems like it is NAT and localhost/127.0.0.1 that’s not working. If I specify an IP for the virtual machine in Vagrant and provide the configuration variable --ext-ip with that IP it seems to work. It doesn’t work if I specify 127.0.0.1 for --ext-ip.

Am I doing something wrong or isn’t supposed to talk over TCP if you run in a windows VM over NAT?

–Tomas

10

If you bind to 127.0.0.1 it won’t be accessible from outside. You need to bind it to the address of the virtual interface over which Vagrant is communicating.

11

That I figured out, that is, I need to provide an IP for the server as it is now. However, it would be nice if you could communicate over localhost/127.0.0.1 and just forward the ports necessary. It is possible for the HTTP with http-prefixes, and would be nice to be able to opt-in for TCP as well. Not a big deal since I can just give the vm an IP now as a workaround.