Archive May 2019

wait for db with docker and python

In this post we will see how to resolve classic problem to let python application wait to mysql docker container to be ready.

We have two ways to put the waiting process:

In python application

# assume 'db' is a peewee database object

def wait_for_db_connection(max_tries, sleep_duration_in_seconds):
    try_count = 0
    while True:
        try_count += 1
        try:
            db.connect()
            logger.info("database server connection try {0}: OK".format(try_count))
            return
        except Exception as error:
            if try_count < max_tries:
                logger.info("database server connection try {0}: FAILED".format(try_count))
                time.sleep(sleep_duration_in_seconds)
                pass
            else:
                logger.error("database server connection reached max tries. Unable to connect to DB")
                logger.exception(error)
                raise

Then call wait_for_db_connection(..)

In Dockerfile

COPY ./wait-for-db.sh /wait-for-db.sh
RUN chmod +x {{ compose_project_path }}/wait-for-db.sh
CMD [ "/wait-for-db.sh", "python", "app.py" ]

Where wait-for-db.sh (jinja2 like):

#!/bin/sh
# wait-for-db.sh

set -e

host="{{ database_host }}"
port={{ database_port }}

shift
cmd="$@"

until nc -z -v -w30 $host $port; do
  >&2 echo "Database server is unavailable - sleeping"
  sleep 2
done

>&2 echo "Database server is up - executing command"
exec $cmd

Jersey backward incompatible changes in 2.26

Jersey 2.26 and newer are not backward compatible with older versions.

The reason behind that has been stated in the release notes:

Unfortunately, there was a need to make backwards incompatible changes in 2.26. Concretely jersey-proprietary reactive client API is completely gone and cannot be supported any longer - it conflicts with what was introduced in JAX-RS 2.1 (that's the price for Jersey being "spec playground..").

Another bigger change in Jersey code is attempt to make Jersey core independent of any specific injection framework. As you might now, Jersey 2.x is (was!) pretty tightly dependent on HK2, which sometimes causes issues (esp. when running on other injection containers. Jersey now defines it's own injection facade, which, when implemented properly, replaces all internal Jersey injection.

To fix errors when upgrading to 2.26 and newer, add following dependency:

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>2.26</version>
</dependency>

Of course, set version to 2.26 or newer if any

https://stackoverflow.com/a/46405129

renew expired let’s encrypt certificate with certbot

Firstly my certificates were created for mysubdomain.witr.net with certbot like so:

sudo apt-get install certbot -t stretch-backports
sudo certbot certonly --webroot -w /path/to/http/server/web/dir1

All is fine.

Some days after, I changed the directory of http server web path (ansible refactoring)

When certificate is near to expire, and I’m going to renew its validity, always with certbot, I’m having following error:

could not find path /path/to/http/server/web/dir1

Fixed by changing certbot configuration in /etc/letsencrypt/renewal/mysubdomain.witr.net.conf

# edit following line option to set the good path: 
mysubdomain.witr.net = /new/path