We recently started work on an event-sourced application that will run in Azure and we needed to get a quick Event Store instance up for development. We had a hard time finding information about the details of standing up Event Store in Azure, so this post will walk through the various steps required to go from nothing to a working dev instance.
Note that this post does not cover best practices for an instance of Event Store, simply getting Event Store going for development and testing. As such, considerations such as authentication and performance are not covered.
Create and configure Azure VM
As a first step, we’ll create a new Windows Server 2012 R2 Datacenter VM that uses the Resource Manager deployment model. Since this is for development use, we don’t need much in the way of performance or scalability. We’ll sized the VM as a small Basic A1 instance. I do want to be able to easily reach my Event Store repo from my development boxes, so we’ll also change the Public IP address to static. The rest of the options will be left at their defaults. Once the VM is created, the server blade will open. We’ll take note of the Public IP assigned to the VM for later use.
While still in the portal, let’s configure the network to allow Event Store traffic. Connections to the Event Store repo take place over TCP port 1113. The Event Store administration website is hosted on port 2113. We need to be able to read and write to the Event Store repo from external boxes, so let’s open TCP port 1113 to my new VM.
We’ll click on All resources from the main menu blade. When the esdemo VM was created, it automatically created an esdemo network security group. We’ll select that from the resources list, click on Inbound security rules, and click Add to create the new rule. The Protocol should be set to TCP and the Destination port range to 1113.
If we wanted to be able to remotely administer the Event Store instance via the web interface, we would add a second rule for TCP port 2113 as well. Since I plan to only administer the instance locally by remoting into the VM, we will only apply the first rule and continue on.
Note that since we are not covering security and authentication for Event Store, you may wish to limit which IP addresses can access Event Store through the network configuration. This can be done using the CIDR block or Tag options of the Source setting when creating the inbound security rule.
Installing and Configuring Event Store on our VM
Now that the VM and network configuration is ready, let’s RDP in and install Event Store as a service. Before installing, we’ll need to create a local, non-admin user to run the service under (heretofore referred to as “service user account”). Since the user needs no special rights yet, let’s create a standard account and make sure to uncheck the User must change password option so the account doesn’t have any issues starting the service.
>Next, we will create a C:\EventStore directory to hold the Event Store installation and repository. Download the latest release of Event Store and unzip it into the directory. Event Store does not have any built-in support for running as a service, so we’ll also download the latest release of NSSM to run Event Store as a service and unzip it into the same Event Store directory. We’ll need to grant the service user account we just created Full Control access to this new C:\EventStore directory.
To install Event Store as a service, let’s open a command prompt and change to the C:\EventStore directory where NSSM has been unzipped. Running nssm install EventStore allows me to specify the executable to run as a new service.
For Path, we’ll browse to the EventStore_ClusterNode executable where we unzipped Event Store. Startup directory will be the directory where the executable is located. By default, Event Store will only listen for connections on the local interfaces (localhost and 127.0.0.1). Since we want Event Store to be externally accessible, we will tell it to listen on all interfaces by specifying –ext-ip “0.0.0.0” in the Arguments field.
Lastly, switch to the Log on tab and have the service log in as the service user account we previously created. Click Install service and we’re almost ready to start up Event Store.
When Event Store starts up, it will attempt to register with HTTP.SYS to listen on port 2113 for the administration website. We need to grant our service user account permissions to register that port. To do so, we’ll run netsh http add urlacl url=http://*:2113/ user=esuser from the Command Prompt.
And finally, we need to make sure port 1113 is open in the Windows Firewall by creating a new TCP port rule to allow 1113 inbound. We would also create a rule for 2113 if we wanted the administration website to be remotely accessible.
Testing our service
At this point, the service is ready to go! We can start it up using net start EventStore from the command prompt or using the Services control panel. Once started, we’ll open a browser on the VM and attempt to locally browse the web administration website. We go to http://localhost:2113/ and are greeted by the Event Store administration page.
The default admin username is admin and the default password is changeit. The first order of business will be to change that password, especially if you’ve opened port 2113 for external access.
Browsing the web administration site shows that the Event Store service is running and accessible internally, but we need to confirm that Event Store is available externally as well. For this, we’ll open IE on our local desktop and browse to our public IP address, port 1113.
We’re sending a simple GET request and not a proper Event Store request, so we will receive back an Invalid TCP frame received error, but this is confirmation that we’re able to reach the Event Store service externally. Note that if trying this test with Chrome, the error does not show up in the browser window, but instead triggers a download of a text file that contains the error text. Just save yourself the trouble and test in IE.
That’s it! At this point, Event Store is ready to be a repository for your event-sourced dev applications. I’ll cover some best practices for production deployments and configuration in a future post.