Where has the docker image gone about centrifugo

[FZambia]

Hello!

Hmm.. I never created official Docker image for Centrifuge. Just Dockerfile to make one.

Anyway having image on dockerhub is nice.

[FZambia]

@clintonbosch I remember about this - just could not find time.

At moment I am planning to make something like this:

FROM centos:6

RUN \
  curl https://github.com/centrifugal/centrifugo/releases/download/v0.2.0/centrifugo-0.2.0-1434542239.x86_64.rpm -L -o /tmp/centrifugo.x86_64.rpm && \
  rpm -Uvh /tmp/centrifugo.x86_64.rpm && \
  rm -r /tmp/centrifugo.x86_64.rpm

VOLUME ["/etc/centrifugo",  "/var/log/centrifugo"]

CMD ["centrifugo"]

EXPOSE 8000

To run:

docker run -d -v `pwd`:/etc/centrifugo -p 8000:8000 centrifugo_test_image centrifugo -c /etc/centrifugo/config.json -w /opt/centrifugo/web

I have not used Docker a lot - what do you think about Dockerfile above?

Update. Fixed issue with missing wget

[palazzem]

Hi @FZambia,
docker user here :)

I've integrated your (amazing) service within our docker infrastructure and I've seen this "issue" related to a missing official image published in Docker Hub repositories. If you want to take a look to our Dockerfile, this is a link to our repository.

While we're using some customization for our infrastructure purposes (e.g.: using our evonove/scratch as a base image and exposing port 8080 instead of your default 8000), maybe something could be useful. As you can see, during the build process, we're creating a non-privileged Linux user like other official images do (e.g.: Redis Dockerfile).

What do you think? I can even help with a PR if you want to integrate something to your Dockerfile. Furthermore, it could be useful for you to activate an automatic build hook based on your tag releases, so that you can provide your images easily and without efforts.

Let me know if I can help you or if you think that my advice are not suitable / useful for your project.
Cheers.

[FZambia]

Hello @palazzem !

Thanks for a help - as we don't use Docker at work yet I have a little experience with it - just played a little to get a basic understanding.

I already registered this repo on Docker Hub so the last thing missing is proper Dockerfile.

I have several questions:

• do you see something wrong with Dockerfile in comments above?
• is it necessary to create centrifugo group and user as rpm already creates them (spec)?
• Could you show a command to run your Centrifugo container? I am interested in config file and logs.
• I thought Docker Hub automatically works with repo tags (I create tag and docker pull fzambia/centrifugo:v0.2.1 will automatically work) – am I wrong and I need to turn it on somewhere (if yes point me in right direction please)?

[palazzem]

Hi again!
About your points:

1. The only things I will change, is adding the MAINTAINER and the VERSION keys just to easily point out what this build is about (nothing so strictly mandatory, just a personal opinion). We usually provide a docker-entrypoint.sh in which we launch the service using gosu or any other "default operations". Anyway, gosu isn't shipped with centos:6 or centos:7 images and this is why we use our base image. Without something like gosu or any other Linux command to obtain the same effect, your service may run as a root user, which is not so "dangerous" within a container. Anyway, as you can notice in the Docker security section (conclusions), they suggest to:

Docker containers are, by default, quite secure; especially if you take care of running your processes inside the containers as non-privileged users (i.e., non-root)

If your compiled application doesn't make anything particular and the CMD ["centrifugo"] runs as a root user, probably it's better to use something like gosu to run your service within the container as non-privileged user.

2. Didn't notice that you're already creating centrifugo user and group! In this case, user/group creation through Dockerfile is not required.

3. In our case, we're just exposing a custom folder in /centrifugo path (like other official images do). When we start the container using docker-compose or simply docker, we use:

docker run -v /home/foo/bar:/centrifugo -t centrifugo --config=config.json --port=8080

config.json is found because in our Dockerfile /centrifugo is the default working dir.

About our logs, we don't expose that folder because we're investigating if we could provide all centrifugo logs in the container stdout. In this way, we can use logstash to collect and organize containers stdout as a log for the entire application infrastructure. In your case, I think it's really important to expose the logs folder otherwise docker newcomers may lost their logs.

4. If you can already pull your container (seeing this issue I thought that an automatic build isn't available) you're good enough. The only requirement is the automate build and the Docker service in your GitHub repository.

Hope it helps! :)

[FZambia]

In this case your custom config located in /home/foo/bar/config.json?

[palazzem]

Exactly, in this way the config.json could be saved within the application repository or it could be provided in a folder without versioning.

[FZambia]

Thanks for a great explanation!

Maybe using rpm for building image is not a good idea at all?

I see several disadvantages in building from rpm:

• no need in registering in service i.e. service centrifugo start/stop/restart/reload not needed
• no need in built in logrotate which I configure in rpm spec
• building from just a release zip archive is much more explicit - things are not hidden in rpm spec

So something like this in Dockerfile can do the work:

FROM centos:7

ENV VERSION 0.2.1

ENV DOWNLOAD https://github.com/centrifugal/centrifugo/releases/download/v$VERSION/centrifugo-$VERSION-linux-amd64.zip

RUN curl -sSL "$DOWNLOAD" -o /tmp/centrifugo.zip && \
    yum install -y unzip && \
    unzip -jo /tmp/centrifugo.zip -d /tmp/ && \
    mv /tmp/centrifugo /usr/bin/centrifugo && \
    rm -f /tmp/centrifugo.zip && \
    echo "centrifugo - nofile 65536" >> /etc/security/limits.d/centrifugo.nofiles.conf

RUN groupadd -r centrifugo && useradd -r -g centrifugo centrifugo

RUN mkdir /centrifugo && chown centrifugo:centrifugo /centrifugo && \
    mkdir /var/log/centrifugo && chown centrifugo:centrifugo /var/log/centrifugo

VOLUME ["/centrifugo", "/var/log/centrifugo"]

WORKDIR /centrifugo

CMD ["centrifugo"]

USER centrifugo

EXPOSE 8000

The only thing missing here is web interface but I think it's possible to put it into Docker image from https://github.com/centrifugal/centrifugo/tree/master/extras/web directory.

Also I set USER directive - I ran container built from this Dockerfile and it seems to work fine but I am not sure that USER is a replacement for gosu?

[palazzem]

You're welcome! :)
I see your points about rpm building and I totally agree. Services are not useful inside docker (there is no systemd or anything like this in base images and, in this case, CentOS 7 team removes the useless systemd package in favor of a fakesystemd just for dependency resolution).

Furthermore, like you said, building from a zip file is really more explicit. Now that we both agree, I will include your changes in our custom Dockerfile.

About the web interface, if you need to add the extras/web folder executing the update.sh script, I could suggest to create another container that extends from this one (e.g.: FROM fzambia/centrifugo:whatever). Don't know if this is a wise choice but in this way you're providing a container with only the centrifugo service while another one contains the centrifugo together with the web interface (without duping the Dockerfile).

In this way users may choose if use your container with the web interface or not. In this case, I suggest some instructions in the README file explaining the difference between fzambia/centrifugo and (hypothetically) ```fzambia/centrifugo-web`.

Another choice is to provide an all-in container with both service and web interface. If you think that the use of the web interface is a usual choice for developers, you could go straight on with this way.

What do you think about?

Also I set USER directive - I ran container built from this Dockerfile and it seems to work fine but I am not sure that USER is a replacement for gosu?

USER directive provides the execution of all consecutive commands (RUN, CMD and ENTRYPOINT) through the chosen user. Because you don't need any further customization neither an entrypoint script, it's totally fine to use USER. Just to be "consistent" I will place it before the CMD ["centrifugo"] even if it's not required to run centrifugo command as a centrifugo user.

[palazzem]

Ah, obviously, I'm glad to help you with a PR if it's needed (probably you're busy with more interesting issues / features :) ).

[FZambia]

I think it's totally ok to have all-in-one container as web interface not used by default - it must be explicitly set via --web option. There is no need to run update.sh - as this will download actual version of web interface which is not good for building containers as builds won't be repeatable. So the goal is include version of web interface compatible with Centrifugo server release.

[FZambia]

Another option - as web interface is just a directory with files - maybe its ok to just provide it in mounted volume? In this case there is no micromanagement with compatible web interface version.

[palazzem]

OK, I've missed that you could launch independently your web interface using the --web option. In this case I think that the most suitable choice is to provide an all-in-one container that contains the right web version. In this way, users can launch their container using the option --web=/container/path/web/app.

In this way, developers don't need to configure a second data volume to provide the web interface code. Bearing in mind that "developers are lazy", an example to launch the container in two different ways without downloading / configuring the web interface is good enough for an all-in-one container.

The data volume option is still OK but I think that it involves a major number of steps for the purpose of a docker container. I think it's better to use them just for data (databases or anything that changes according to users' actions) or custom configuration files. If these files are static, I think it's better to include them in the docker build process.

[FZambia]

You are right, we are all lazy:) Thanks @palazzem for your suggestions about pull request - but that was very interesting to try so I've made it myself) Just released new version with new Dockerfile - hope that I've made everything right - please check it out - is it ok?

[palazzem]

You're welcome! :))

Yes, it's perfect and works as expected. I think that you can close this issue because this Dockerfile solves the presence of a working container in your Docker hub repository.
Hope to contribute again to your project (maybe with some code) :)

[FZambia]

Thanks!

[FZambia]

Tried to pull by tag - no success, Docker Hub builds only master branch with latest tag automatically. Added 0.2.2 manually though so it's now possible to run docker pull fzambia/centrifugo:0.2.2. But as far as I understand there is no way to build new version tags automatically.

[palazzem]

Currently, you should add the tag version build manually in your docker repository configuration. An automatic tag discovery isn't available at the moment but the Docker team already track this issue / feature request in their internal tracking system.

I don't know when this feature will be implemented (don't see anything about it) but it's really a waste of time especially if a developer provides a lot of monthly release.

[FZambia]

Yes, also saw this issue while searching for solution. So I think we are done here - not so difficult to add tags manually:)