Simple Dockerfile

Using FoundationDB
10

Continuing the discussion from the GitHub PR, @bjrnio:

I like that you have made a basic example for docker-compose that others can build upon. I know it was just an off-hand example, so I mention in case someone makes something with it that they will want to use a version string instead of latest, so that the version is never changed accidentally.

We agree in that we could fix this issue with workarounds like stopping the service, this or temporarily changing the runlevel, …

The Dockerfile in my post is a working example as of 5.1.7 meant for people searching until there is a consensus on all of the changes. I didn’t mean to imply its workaround as a choice for a permanent solution.

The best solution so far would be changing the docs, with supporting text, to instruct Ubuntu users installing through apt to run sudo systemctl enable foundationdb, sudo systemctl start foundationdb, and fdbcli --exec "configure new single memory". In the same future PR, the foundationdb-server postinst script would be changed to only write an fdb.cluster file. Whether or not to keep enabling auto-start when the package is installed matters less, though my opinion is the same as yours, to not assume and leave it disabled until the user chooses to enable it.

Regarding cluster files (and foundationdb.conf files, too) , my way would be: leave defaults at build and set permissions properly at startup so that users can mount a volume.

I am inclined to agree after some reading and think that instead of including scripts in a docker directory, that a doc page and a readme could be written to suggest using docker cp to access the initial files from /etc/foundationdb in the image, with a reference to make_public.py, which can be obtained from the repo in case someone is concerned over a syntax issue potentially causing data corruption.

One of the older open PRs questions whether make_public.py is even needed. I did not need it and perhaps anyone who is going to plan and manage a database should already know to read the docs and heed any warnings. I don’t know any facts related to that, so I don’t have an opinion.

What you mention about name resolution to fdb.cluster files is something I was pretty disappointed with FDB, and I expect it to be implemented in the future.

Early yesterday, @wwilson made a good point here, essentially saying that in some setups, hostname resolution could become an unexpected single point of failure.

I would still like to see the feature implemented and think that a warning in the docs should be sufficient, though I would understand if it’s later decided against.

Also, I’m discussing Ubuntu here only, I think we should set down first on what we want from a Docker image, regardless of the underlaying OS, and then port it to Debian, CentOS, and if possible, Alpine.

I don’t have an opinion here as having a Docker image solves compatibility on Linux in general.

While I am typing, looking at your PR:

  • Would you be open to adding version and Debian package revision strings as ARG variables, like in my example?

  • Do you have a reason for using latest, or would you consider switching to use a specific version string?

  • The current sed usage depends on the example config file’s listen_address directive to be placed on line 25. If it is moved in a later commit, the new contents of line 25 will be replaced with the custom directive.

    • How about something like: sed -i "s/^listen_address.*/listen_address = ${LISTEN_ADDR}/" /etc/foundationdb/foundationdb.conf, so that any changes can be made to the file, and using ARG LISTEN_ADDR=0.0.0.0 rather than ARG LISTEN_ADDR "" and ${LISTEN_ADDR:-0.0.0.0} which is completely correct though appears to the uninitiated (me, a few minutes ago) to prepend a dash.

Thanks for your work and constructive discussion so far!