Adding other services to a Docker container

Teclado — Sun, 20 Nov 2022 13:32:21 +0000

If you are about to dockerize a production-ready infrastructure in order to save server-related costs, you may find a problem with certain images that are enough complex to be a pain to override but does not fulfill your requeriments completly.

In that case the common roadmap is to extend that image until you are comfortable with it. But, what if we want or need to add some other services? Simply overriding the ENTRYPOINT layer is often both a risk and a pain too, and you would have to be aware of the changes in the original image. For that we can look after the existence of supervisord.

Learning by example

An example of this is the official Redmine image. This image serves by default the Redmine app in the port 3000 using HTTP. But we want to use HTTPS because we want to use it in a production environment! Then we need a HTTP server acting as a proxy where we configure HTTPS.

Well, that's not an issue, we just extend the image in a Dockerfile like the following:

FROM redmine:5

RUN apt-get update && \
    apt-get install -y \
    nginx \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

COPY conf/default.conf /etc/nginx/conf.d/default.conf

EXPOSE 80
EXPOSE 443

Being conf/default.conf the Nginx config file, something like the following:

server {
    listen       80;
    listen      [::]:80;
    server_name  redmine.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen      443 ssl;
    listen      [::]:443 ssl;
    server_name redmine.example.com;

    ssl_certificate     /path/to/certificate.crt;
    ssl_certificate_key /path/to/certificate.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

}

Ok, but that's not launching Nginx at all yet. That's why we need supervisord. If we inspect the Redmine Dockerfile, we can see the following lines:

WORKDIR /usr/src/redmine
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["rails", "server", "-b", "0.0.0.0"]

Thats all the information we need to configure supervisord to launch Redmine. But first, we need to install it. For that we edit our Dockerfile so it finally remains like the following:

FROM redmine:5

RUN apt-get update && \
    apt-get install -y \
    supervisor \
    nginx \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

COPY conf/supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY conf/default.conf /etc/nginx/conf.d/default.conf

EXPOSE 80
EXPOSE 443

ENTRYPOINT ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]

We have added the supervisor package to the apt-get install command, and the copy of the configuration file of it. As we want supervisord to be our new entrypoint we added the last line too, passing the configuration file to the command.

Then the conf/supervisor.conf file will have to be something like this:

[supervisord]
nodaemon=true
user=root

[program:nginx]
user=root
command=nginx

[program:redmine]
user=redmine
directory=/usr/src/redmine
command=/docker-entrypoint.sh rails server -b 127.0.0.1

The first section is the configuration of the supervisor daemon itself. We simply set the user to be root and indicate that it have to run in foreground with nodaemon=true.

With the second section we just start Nginx using the default configuration file (the one we copied in the Dockerfile).

With the last section we demand supervisord to start Redmine. First we change to the dir /usr/src/redmine, as the Redmine Dockerfile states with the WORKDIR layer. And we start the application linking the ENTRYPOINT and the CMD layers of the original Dockerfile. We also change the IP Redmine will listen on to 127.0.0.1 in order to avoid direct connections from outside the container.

Conclusion

We have tweaked a Docker image to fit the need of other services inside the same container without changing a word of the original image.

You can see more about supervisor in the Debian man page.

Getting the precision for a float

Teclado — Fri, 10 Jul 2020 19:46:28 +0000

When using floating-point numbers, we're not used to think about the precision of theirs value. We only want a variable that can change in a continuous form, but we never take into account that this variables don't take a continuous range of values due to their binary (and finite) representation.

If we attend to the IEEE754 specification, we can see the consensual meaning of each bit of this representation for each of the types we handle.

There we see a space reserved to the sign and other for the exponent. That's ok, since they should be defined as integers. Is the mantissa which should be continuous, but due to its limited size, it's not. It behaves (with a fixed sign and exponent) just as an integer.

Any scientist will agree with that if the floating-point number was matched up with other one (may be one with less precision) that would indicate a range containing the actual (and infinite precision) value of the number we're representing.

However, this has been never implemented in the core logic of any computer, so we need to build it by ourselves.

If we have after some calculations a final result, its least significant digit is never precise. This is because we had to round a real number to fit in a fixed length binary representation, so the error we get in the result is never less than the value of this bit (which changes as the exponent changes) divided by two.

Here is an example of a little C code that get this error for a floating point number in a big-endian machine:

float errf(float x)
{
    float nearest = x;
    void *vnp = &nearest;
    char *cnp = (char *)vnp;
    cnp[0] ^= (char)1;
    return fabsf(x-nearest);
}

If the rounding has been taken correctly, we might divide this by 2 and get a sensible result, but I'm in the doubt right now about this. In addition, if we're in a little-endian machine, we should flip the last byte, and not the first.

This piece of code flips the least significant bit, getting the next faithfully representable number if this bit is a 0, and the previous one if it's a 1, in order to substract it from the provided value.

We could get the manner of get both in each case, and subtract the previuos to the next, but the only difference appears when all bits in the mantissa are 0, so the previous representable number is nearer the value x we're asking for. This means that we can always be sure the actual real (infinite precision again) value is somewhere between x-errf(x) and x+errf(x).

Feel free to comment other methods of getting this error, may be in other languages ;-D.

Doing operations

The trick with this topic is that if we want to operate with float values, we have to take this error into account. If we add up three times 0.5, which have an intrinsic error of 0.000000060, the errors add too, so we get a result of 1.50000000±0.00000018. All having a intrinsic one of errf(1.5)=0.00000012.

Multiplication, division and subtraction have their own rules too. It was wonderful if we take this in account in each operation we do. When we do many of them as often happens, the accumulated error can grow pretty fast, and we should be prepared to discard a result when this one gets greater than some sensible limit.

Credits