Those that have subscribed to my YouTube channel, might have noticed that the content has changed a bit away from Django, with more focus on Docker, Kubernetes, and Keptn.

With that in mind, I would like to share you my recent video series here:

Create Docker Containers for GoLang, NodeJS and Python:

How to create a new Keptn project for continuous delivery:

Would love to get some feedback directly on the videos if they are helpful! Thanks!

In one of my recent videos I've disussed the size of the Django/Python Docker Containers and how to decrease it:

I failed to successfully create an image based on alpine, which is known to be very slim. With the help of Aaron Goodrich, who posted a comment with a Dockerfile for alpine, I was able to finally create such an image 🙂 Thanks for the help!

Without further ado, here are the results (and the respective Dockerfiles).

Please note that I have slightly changed the Dockerfile compared to the video above.

Based on Python 3.5 Jessie: 740 MB

FROM python:3.5-jessie

COPY ./app /app

RUN pip install --no-cache-dir -r requirements/dev.txt

Based on Python 3.5 Slim: 188 MB

FROM python:3.5-slim

COPY ./app /app

RUN pip install --no-cache-dir -r requirements/dev.txt

Based on Python 3.5 with Alpine: 248 MB

FROM python:3.5-alpine

COPY ./app /app

RUN apk add --update --no-cache postgresql-client && \
    apk add --update --no-cache --virtual .temp-build-deps gcc libc-dev linux-headers postgresql-dev

RUN pip install --no-cache-dir -r requirements/dev.txt

RUN apk del .temp-build-deps gcc libc-dev linux-headers postgresql-dev


Ever had one of these issues with Pycharm 2018 and Docker?

Couldn't refresh skeletons for remote interpreter
The docker-compose process terminated unexpectedly: /usr/local/bin/docker-compose -f docker-compose.yml -f .PyCharm2018.3/system/tmp/docker-compose.override.8.yml run --rm --name skeleton_generator_643129755 python
Regenerate skeletons


can't open file '/opt/.pycharm_helpers/pycharm/' + "No such file or directory"

Then you should clear all pycharm helpers from your docker containers and images:

docker ps -a | grep -i pycharm | awk '{print $1}' | xargs docker rm
docker images | grep -i pycharm | awk '{print $3}' | xargs docker rmi

This blog is using wordpress and certain tools of wordpress, that allow collecting statistical data, such as information about your web browser (Browser Name + Version). We do not share this information with any third party (such as Google Analytics), everything is kept within this wordpress blog and server.

Read more about it in our "brand new" Privacy Policy.

Sometimes I just love how the open source community works nowadays! Sometimes you  use your favourite search engine to find a package/repository/etc..., just to find out thatit contains a quickstart info, a proper package.json or docker-compose.yml. All you need to do is "npm install && npm run" or "docker-compose build && docker-compose up" and you are good to go.

This helps devs to contribute to open source software soooooo much!

TL;DR: Use Docker, package.json, requirements.txt, and for the love of god, write a Quickstart section into your Readme!

If you have ever gotten this error with your mod passenger installation:

$ passenger-config restart-app
*** ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it
is running, then the causes of this problem could be one of:

1. You customized the instance registry directory using Apache's
 PassengerInstanceRegistryDir option, Nginx's
 passenger_instance_registry_dir option, or Phusion Passenger Standalone's
 --instance-registry-dir command line argument. If so, please set the
 environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory
 and run this command again.
 2. The instance directory has been removed by an operating system background
 service. Please set a different instance registry directory using Apache's
 PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir
 option, or Phusion Passenger Standalone's --instance-registry-dir command
 line argument.

Then you most likely have SystemD running, which uses PrivateTmp folders instead of /tmp folders.

It's annoying, but easy to fix, see this blog post:

Inspired by a recent commitstrip:

Like almost everyone else I had to test my Single Page AngularJS Application, which uses Django Rest Framework as a Backend, with Internet Explorer (11, thankfully). While my SPA works fine in Chrome and Firefox, it does not work very well in Internet Explorer (shocking, lmao).

Anyway, the obvious errors, ranging from needing polyfils to some CSS quirks, were fixed quickly.

But at some point I noticed: Why the hell are changes I make via PUT/POST/PATCH not shown when I make a GET request (retrieving all instances of a model) to the same endpoint afterwards? It kept returning the same data again and again. Where the hell did my changes go? Is my database broken? Is Internet Explorer not firing the PUT/POST/PATCH calls properly?

None of that was true. As it turns out, Internet Explorer 11 caches almost all GET requests to my REST API. I submit a change, I reload the page, and the change has disappeared. Caching at its best.

So I googled and stackoverflowed (is that a word?), and I found some people talking about cache headers. And they are god damn right... Django aswell as Django Rest Framework do not set any cache headers in the response (most likely for a good reason, better be explicit than implicit).

So I tried a couple of the provided solutions, and I must say, I was really unhappy with those approaches. They were either very repetitive (like the ``@never_cache`` decorator added to all my viewsets), or required monkey patches and other sorts of things that I do not like to see. Btw, a cache buster within my JavaScript SPA was a no-go for me.

So I thought to myself: How about I make my whole Django Rest Framework Application "uncachable"? And so I did, with a very few lines of code and as a Django Middleware:

from django.utils.cache import add_never_cache_headers

class DisableClientSideCachingMiddleware(object):
    Internet Explorer / Edge tends to cache REST API calls, unless some specific HTTP headers are added by our

    - no_cache
    - no_store
    - must_revalidate
    def process_response(self, request, response):
        return response

Don't forget to also add this middleware to your settings.


Please note that this disables caching of ALL requests coming to your Django Application. If you are serving static files from your Django Application (instead of serving them directly from your webserver), this will affect your performance.

This middleware works for me. I later discovered that somebody else has already had a similar idea, too. The obvious disadvantage here is that it disables caching for all parts of my Django Application. This is fine for me, as I am only using Django Rest Framework and I do not want caching on client side to happen at all, but it might not be okay for some other applications.

Nevertheless, I hope this piece of code helps people that have similar problems. Also, please feel free to share your experiences and solutions to such caching problems with Internet Explorer.