Docker healthchecks – things to consider

While working on a recent docker project I encountered an issue when it comes to health checks. You may define a health check for a container from within your Dockerfile, such as

HEALTHCHECK --interval=5s --timeout=5s --start-period=20s
         --retries=5 CMD wget --output-document=- 
         --quiet --tries=1 http://127.0.0.1

The syntax is quite simple to understand, you basically define how and when the health check should be executed and which command(s) to use. Breaking things down from the example

  • –interval=5s – run the check every 5 seconds
  • –timeout=5s – maximum time to wait for the health check to complete
  • –start-period=20s – allow some time for the process to be monitored to come to a functioning state, avoids false alarms during startup, in this case we allow 20 seconds
  • –retries=5 – only trigger an alarm after 5 unsuccessful tries (non zero exit code) – this helps avoiding false alarms in case the process is under heavy load
  • After the CMD follows the command to execute, this is done from inside the container, in the given example we check for the webserver to deliver something indicating the server is working properly

However every one should consider on how flexible the health check should be to match as many use cases as possible. This is especially true if you are dealing with web-based endpoints as pointed out in the example.

Continue reading

Why IPv4 is not better compared to IPv6 in terms of security of your home/office network

If you look at the internet at the moment, from a more technical point of view, you will often find users complaining about the „new“ Internet-protocol IPv6. Most of the time the complaints are about issues with the Internet-Service-Provider ISP used.

I will focus on the issue based on my experience in Germany (things might be different in your location, feel free to leave a note in the comments). In fact the technical introduction of IPv6 went unnoticed for most of the average users. This is partly due to the fact, that in the beginning there were not so much services that were accessible via IPv6 (a typical chicken-egg-problem) and most operating systems seamlessly degrade to IPv4 if a service is not available in IPv6.

Continue reading

Microservices: Ende-zu-Ende, IPv6, Docker und HTTPS / TLS / SSL

IPV6, das neue IP-Protokoll kommt, langsam aber sicher. Amazon ist mit seiner AWS-Cloud voran geprescht und verlangt mittlerweile Aufpreis für externe IPv4-Adressen. Diese werden zunehmend knapper und somit sind auch die Kosten verständlich. Auch bei diversen Hosting-Anbietern hat man seit einiger Zeit zumindest einmal Vorbereitungen getroffen entsprechende Kosten an den Kunden dezidiert weitergeben zu können. Unter anderem wird ein IPv6-only-Betrieb vergünstigt angeboten. Leider ist er auch für mich noch keine wirkliche Option, bereits der Blog benötigt um gut erreichbar zu sein immer noch eine externe IPv4-Adresse, ich möchte ja eine möglichst große Reichweite haben und potentielle Leser nicht aufgrund ihrer IP-Version diskriminieren.

Nun habe ich ja mittlerweile auch einige Dinge nach aktuellem Stand der Technik per Docker virtualisiert (genauer gesagt ist es ja nur eine Paravirtualisierung). IPv6 ist in Docker immerhin angekommen, der Support lässt allerdings immer noch deutlich zu wünschen übrig. Halbwegs tragbar ist der Aufwand wenn man eine feste, öffentliche IPv6-Range hat und mit docker compose bzw. eigenen Docker-Netzwerken arbeitet. Man muss sich dann nur mit der Problematik der Netzwerkaufteilung Gedanken machen. Entgegen der häufig gelesenen Aussage ist aber bei /64-Netzwerken nicht Schluss mit dem Subnetting in IPv6. Derartige Ranges bekommt man in der Regel bei den Hosting-Anbietern im Standard-Paket. Für mich selbst haben sich /80er Aufteilungen für Docker-Netzwerke bisher ganz gut bewährt, das kann man aber je nach Bedarf noch größer oder kleiner schneiden. Continue reading