11 thoughts on “Lesser known Docker tips for advanced users”

  1. Solid list and described pretty well. I would be wary of putting the database check in the application. It can cause cascading failures in the cluster. A single responsibility healthcheck is better and applications should handle the dependency failures gracefully.

    Reply
  2. I feel embarrassed for learning about ssh forwarding from blog where it was just sidenote

    now on my i3wm I finally added to my .zshrc

    eval $(/usr/bin/gnome-keyring-daemon –start –components=pkcs11,secrets,ssh)
    export SSH_AUTH_SOCK

    and i no longer have to use `SSH_AUTH_SOCK=0 git push` to push to github

    I know I was trying to solve some shit with this and got gnome keyring or some shit but never got much passed cuz it was not that essential at the moment

    Reply
  3. Wondering what the use cases could be for the LABELs mentioned as opposed to tagging the image with the version string.
    (Apart from having some basoc dovumentation on the project URL etc)

    What does it enable you to do?

    Reply
  4. The first point thows me off. Best practice list without an explanation in how to do it. I have a snipped I use but is the way I do it the correct one? Lets look into the best practices. Oh snap, its not explained. 🙁

    Reply
  5. Solid content, to the point without much waisting time, site works without javascript (and still looks good), no annoying cookie banners that cover half the text. Very well done!

    Reply
  6. For `HEALTHCHECK` I would strongly consider putting it into your docker-compose.yml file instead of Dockerfile and use variable substitution so that you can control what happens during a health check in development and production.

    In practice having a health check hit a URL in development every few seconds is super distracting and spams your logs which are often used to help debug real problems.

    So in development you can just set an env variable to have your health check do a no-op like `/bin/true` and then have it curl your endpoint in production by default.

    This is what I’ve been doing now for a long time and it works nicely. Here’s a working implementation: https://github.com/nickjj/build-a-saas-app-with-flask

    Reply

Leave a Comment