Disclaimer: I'm not an expert on Event Store. There might be features specific to Event Store that make it less suitable to run from a container which I am not aware off.
In general, you can 'dockerise' most services and they can perform equally well as a service that is run natively on a server.
The things to be aware off are:
- where do you keep your data
- where do you keep your configuration files
- what performance is required
- what about safety
Data: Because of the way the container is run in the example, your data will be 'inside' the container. Delete or upgrade the container and your data is gone forever.
To make your data persistent use data volumes or data volume containers. These keep your data on the host (their Dockerfile already has support for it, see VOLUME).
There are also storage solutions that allow you to access data remotely using volume plugins.
Configuration Files: Same story as for your data. You can keep your configuration file(s) in a data volume (container) or pass them via the Dockerfile (as they've done in their Dockerfile).
Performance: There can be a slight performance hit in some situations when using Docker versus native. See https://stackoverflow.com/q/21889053/4459346
Safety: Because of the way the container is run in the example, the Event Store will be exposed on the host machine. Anyone can access them externally. To keep them local to the host use -p 127.0.0.1:1113:1113.
At the company I work for I have set up a mysql server in a container. The data and configuration files are 'stored' in a data volume container. I also have set up a cron job that runs another container to back up the mysql data to the host.
A number of applications (also 'dockerised') are happily using mysql that way. We haven't seen any difference with running mysql natively. There can be 50+ users at a time.
