Looks very promising. Two comments:

You should use Docker build args (ARG) for DUMB_INIT_VERSION and GOSU_VERSION if the intention is to let other people override them for building a custom dockerfile. If that's not the intention, you should either use env inside the RUN line, or inline them; otherwise the final image will get those unnecessary envvars.

Long RUN lines like this are better put in a build script, since you're gaining absolutely nothing from layering. I tend to create a build.sh and just put everything there. That lets me write clean bash code using local variables, comments, functions and so on. It also lets me do things like set temporary build-on envvars (e.g. TERM) that should not leak into the final image.

These are some top tips, thank you! In this case, however, I would rather leave these for the next iteration, as a refactoring step. This patch already introduces at least 3 significant dependencies and may not be particularly easy to reason about. It's also made trickier by the fact that the files are auto-generated from templates.

Can we merge this?
Does someone test this Dockerfile / entrypoint.sh on actual environment?
If there is no breaking compatibility, I want to merge this patch.

I have been testing the change and realised that it is a bad idea to chown the data/config directory in the entrypoint. This may cause potentially undesired modification of permissions on host and poses a security risk. So this step has now been removed. [EDIT: added back, otherwise it breaks when files are not mounted from host, but used inside the container, e.g. with onbuild images] Apart from the above concern everything seems to work as expected. The reproducible steps are given below.
First of all, it works with default config without any mounts:

docker run -it --rm -p 24224:24224 -p 24224:24224/udp fluent/fluentd:v0.12.34

Starting from uid 1000 on the host system

vagrant@infra:/tmp/fluentd$ cat /etc/passwd | grep $(whoami)
vagrant:x:1000:1000:Vagrant User,,,:/home/vagrant:/bin/bash

let's create the volumes and populate a sample configuration file to mount over the defaults in the container

vagrant@infra:/tmp/fluentd$ mkdir data etc
vagrant@infra:/tmp/fluentd$ curl -s -o etc/fluent.conf https://raw.githubusercontent.com/fluent/fluentd-docker-image/master/v0.12/alpine/fluent.conf

Let's also drop some permissions on the config file which is a likely use case

vagrant@infra:/tmp/fluentd$ chmod 400 etc/fluent.conf

At this point container could be started successfully without specifying FLUENT_UID which defaults to 1000

docker run -it \
                   --rm \
                   -p 24224:24224 \
                   -p 24224:24224/udp \
                   -v $(pwd)/data:/fluentd/log \
                   -v $(pwd)/etc:/fluentd/etc \
                   fluent/fluentd

Now we create a new user and set ownership accordingly (note: user name could be anything else here, it is the id that matters)

vagrant@infra:/tmp/fluentd$ sudo /usr/sbin/useradd fluent -u 9001 
vagrant@infra:/tmp/fluentd$ sudo chown -R fluent data/ etc/

If we now run the container with the default FLUENT_UID we get Permission denied, as expected. Correct operation is restored if we provide user id matching the one existing on the host

docker run -it \
                   --rm \
                   -p 24224:24224 \
                   -p 24224:24224/udp \
                   -v $(pwd)/data:/fluentd/log \
                   -v $(pwd)/etc:/fluentd/etc \
                   -e FLUENT_UID=9001 \
                   fluent/fluentd

The above was verified both for alpine and debian base images.

@repeatedly as far as could be ascertained, this should be working as expected. There certainly are areas for improvement, such as, using tini instead of dumb-init for alpine images, not running dumb-init itself as root (although this is not something done commonly in a number of official images), using exec form of CMD to avoid spawning an extra shell process, as well as everything mentioned by @atombender above.. however, perhaps those could be tackled separately at some point.

@ValFadeev Out of curiosity, why are gosu and dumb-init not installed here via apk / apt-get ?
It appears that packages exist for both gosu alpine package and
dumb-init alpine package exist. Otherwise, this worked in our environment, and seems merge-able.

@StevenACoffman dumb-init is indeed available as an alpine package and is up-to-date, so I have changed that. Unfortunately, the same is not true for gosu which appears only to exist in the testing repository; also su-exec is the recommended alternative for alpine anyway.

@repeatedly do you think this one could be merged some time? It keeps falling behind on version which causes conflicts. I have this deployed in my staging environment, so far everything is as expected

@repeatedly it works in our environment as well, and is a high quality, high value improvement. I would also like to see it merged.

Sorry for the late. I took 10 days vacation.

Thanks for the testing. I will merge this patch tomorrow.
I will announce this change on mailing list and slack first.

Sorry for the late but just merged!
Thanks for the awesome patch 👍