Would love to be able to tinker by just grabbing an official image and dropping it into my local development compose file! :)
I would second this. There are several non-official images in the hub, but it'd great to have an official one.
I tried to create one. But I needed my container to run a couple of curl commands, to deploy a few artifacts (projections, actually).
So i took a look at what was done for the postgres image here https://hub.docker.com/_/postgres/. This image allows you to specify some SQL scripts to be run, before starting postgres as the PID1 process. It actually launches postgres once, run the script using the dedicated command line tool, stop postgres, and finally execute postgres a second time, so that it becomes the PID1 process. You can find the docker-entrypoint.sh here https://github.com/docker-library/postgres/blob/916a840510b481e7d3f0f74fa04fde3edfdfbd04/9.5/docker-entrypoint.sh.
I never managed to do it with EventStore. Every time I try to launch it in background, it just stop running. Not completely, but in a stale mode: the ports are open, but the server does not respond to a curl command. It completes the curl command only when it runs in foreground.
I may have missed something, but for the moment, I give up, and I'll try to deploy my artifacts, once the container is up.
This is on the cards and we will link to this ticket when the work on this starts.
Since I didn't find any other image that worked and was up to date, I created https://hub.docker.com/r/ruudud/eventstore/ and has been tracking releases since August.
Source is here: https://github.com/ruudud/dockerfiles/tree/master/eventstore
Please use it if you want.
Because EventStore also features a web-gui, it might be worthwhile to look to RabbitMQ for inspiration: https://hub.docker.com/_/rabbitmq/
What exactly are you guys looking for from an EventStore docker image?
My image supports the web UI through the standard port 2113, and the same for the TCP API.
@ruudud Why do you do the following as default:
ENTRYPOINT ["./run-node.sh", "--ext-ip=0.0.0.0", \
"--ext-http-prefixes=http://*:2113/", \
"--add-interface-prefixes=false"]
CMD ["--db /data/db", "--log /data/logs", "--run-projections=all"]
Here I mean, running all projections and those switches. That's a bit fixed.
The stuff in ENTRYPOINT is for eventstore to accept requests on all interfaces (and hostnames). Eg. if you bind port 2113 to the host network, it's nice to have eventstore answering on http://localhost:2113. Also, it's kind of hard knowing the local IP address in advance when using standard Docker networking..
Both ENTRYPOINT and CMD are easily overriden at run time, this is just my opinion on the most sane default for local development. Up for discussion of course!
If you run docker run -d ruudud/evenstore --db /someplace all of the stuff in the CMD directive will be overriden, so the resulting command executed is ./run-node.sh --ext-ip=0.0.0.0 --ext-http-prefixes=http://*:2113/ -add-interface-prefixes=false --db /someplace.
The same goes for ENTRYPOINT using docker run --entrypoint <...> ruudud/eventstore.
We will be putting up the official event store docker hub image at https://hub.docker.com/r/eventstore/eventstore-docker/
The repo is currently private, but will probably open that up so that we can track issues/PRs.
@ruudud : I explained it in a previous post, in this stream.
And I also had a HUGE issue with some docker images I tried.
And that was a reason why I chose to switch to another solution.
The problem is that when I launch an Eventstore container with a volume, I stop the container, I run a brand new container on the same volume, Eventstore does not work, and the database is empty.
That's a big issue for me, because I want to use docker to simplify production tasks, like moving a database from a server to another, or making snapshots.
Maybe I missed something at some point, but I really tried many times, and with different databases (like Redis, which I finally chose as an event store).
And I wanted to let you know about it, as I think that it can be an issue for other persons.
"The problem is that when I launch an Eventstore container with a volume, I
stop the container, I run a brand new container on the same volume,
Eventstore does not work, an the database is empty."
It sounds like you aren't keeping data from one to the other. The data is
just files no magic associated with it.
On Tue, Mar 15, 2016 at 12:42 PM, Jérôme Avoustin [email protected]
wrote:
@ruudud https://github.com/ruudud : I explained it in a previous post,
in this stream.And I also had a HUGE issue with some docker images I tried.
And that was a reason why I chose to switch to another solution.
The problem is that when I launch an Eventstore container with a volume, I
stop the container, I run a brand new container on the same volume,
Eventstore does not work, an the database is empty.
That's a big issue for me, because I want to use docker to simplify
production tasks, like moving a database from a server to another, or
making snapshots.Maybe I missed something at some point, but I really tried many times, and
with different databases (like Redis, which I finally chose as an event
store).
And I wanted to let you know about it, as I think that it can be an issue
for other persons.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/EventStore/EventStore/issues/755#issuecomment-196761322
Studying for the Turing test
That's exactly what I expected : By starting a new container on existing files, I would get the store as I left it.
I tried many times, but I'll take some time to make another try.
We have opened the docker repository. We accept contributions and relevant issues can be discussed over there.
Are there any plans to make it production-worthy? Is that realistic to expect?
What would a "production-worthy" image look like especially for a cluster.
Would it just basically expose all the config arguments so you can change
them from outside as opposed to inside?
On Wed, Mar 16, 2016 at 4:40 PM, Alexander Trauzzi <[email protected]
wrote:
Are there any plans to make it production-worthy?
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/EventStore/EventStore/issues/755#issuecomment-197359329
Studying for the Turing test
Yeah, as much as possible, expose as env vars. There can also be some additional conveniences that are offered via an entrypoint script to configure the environment initially (where applicable).
Considerations beyond that would be to just make sure the process responds correctly and shuts down gracefully when told to do so. There's a bunch of stuff to do with not requiring init as your parent process that was a little over my head but might also be good to nail down.
Clustering based on linked containers is also a thing but I'm not quite experienced enough with any of my chosen stack to confidently suggest best practices there.
Apologies if I've just stated the obvious/stuff you already know in all this.
Most helpful comment
We will be putting up the official event store docker hub image at https://hub.docker.com/r/eventstore/eventstore-docker/
The repo is currently private, but will probably open that up so that we can track issues/PRs.