Test Django Applications Using Docker Containers

Earlier I had an issue in which my machine wasn’t able to connect to the Django webserver (runserver) inside the container, even though I had the correct port published using Docker, so, this is the solution.

By default the app runs on and has ALLOWED_HOSTS = [] this means that the app will only allow connections from within the container but since we want to access to the application from our local machine we need to change the following:

Under <yourappname>/settings.py :


And when you run the application pass the following arguments:

# python manage.py runserver

Instead of ‘binding’ to the default by using it will bind to every interface (lo, ethX, etc).

Hope it helps!


Docker Logo

Docker Reference: Troubleshooting Containers Using a Volume


We all know, once the main process in any given container stops running, well, our container stops as well and every log goes with it. Well, creating a volume might just be solution.


What happens when we have a container that ‘fails’ and we don’t really have a way to know why such thing happen since now that our container is dead, well, logs and everything else have died as well.

A nice way to approach this problem is to create a local host volume to store our container(s) log files for any given application, for this example we are using NGINX.

Example & Solution — Volume Creation

Let’s say we have a custom Nginx image that is giving us problems and dies after an ‘X’ amount of time and we have no way to know what is happening since we can’t access such logs, well, let’s create a local host volume that will include every Nginx log file!

First, we need to create the container with such volume path:

docker run --name webserver -d -P -v /containers/logs/nginx:/var/log/nginx nginx

  • –name webserver is optional… You can provide any name you like or none
  • -P is so we can have a network port to access our nginx container
  • -v will create a local /containers/logs/nginx folder in the host

Now, we can easily access such logs:

cd /containers/logs/nginx && ls

We should see access.log and error.log

Now, figure out the problem and keep on working! ūüôā

Docker Logo

Docker Reference: Docker Tag (Tagging Images)


Docker tag is helpful when you are trying to push a locally created image to Docker hub but the name of your Docker Hub image repository is different than the local version, example:

You might have a local image named: local/ubuntu:1.0

Now, every repository created in Docker Hub begins with your username, in this case we will use my nickname: salcoder

Your repository is essentially named salcoder/ubuntu:1.0 so as you can see the problem is that local should be salcoder instead, well, lets fix it!

Solution — docker tag

Docker provides a tool (docker tag)which will allow us to change the name of our local image so it can match with Docker Hub.

We type the following:

docker tag local/ubuntu:1.0 salcoder/ubuntu:1.0

Now, push:

docker push salcoder/ubuntu:1.0

Remember that :1.0 is the actual tag, you can name it latest or whatever else you like.

I hope this quick reference was helpful! Questions, suggestions are always appreciated!

Quick Reference: Meteor.Js Iron Router Vocabulary

Iron Router Vocabulary

  • Routes:¬†A route is the basic building block of routing. It’s basically the set of instructions that tell the app where to go and what to do when it encounters a URL.
  • Paths:¬†A path is a URL within your app. It can be static (/about) or dynamic (/posts/abc), and even include query parameters (/search?keyword=meteor).
  • Segments:¬†The different parts of a path, delimited by forward slashes (/).
  • Hooks:¬†Hooks are actions that you’d like to perform before, after, or even during the routing process. A typical example would be checking if the user has the proper rights before displaying a page.
  • Filters:¬†Filters are simply hooks that you define globally for one or more routes.
  • Route Templates:¬†Each route needs to point to a template. If you don’t specify one, the router will look for a template with the same name as the route by default.
  • Layouts:¬†You can think of layouts as a “frame” for your content. They contain all the HTML code that wraps the current template, and will remain the same even if the template itself changes.
  • Controllers:¬†Sometimes, you’ll realize that a lot of your templates are reusing the same parameters. Rather than duplicate your code, you can let all these routes inherit from a single routing controller which will contain all the common routing logic.


Ref. Discover Meteor & Iron:Router Documentation

Quick Reference: Meteor.Js Packages

Meteor.Js Packages

  • meteor-base: Contains¬†Meteor’s core components¬†– a Meteor app can’t run without it
  • First-party packages:¬†come bundled with Meteor, examples:¬†mongo and/or session.¬†Included by default with new Meteor projects but can be removed
  • Local packages:¬†Specific to your app; live in its local¬†/packages dir
  • Atmosphere packages:¬†Custom, third-party packages published to¬†Atmosphere
  • NPM packages:¬†Node.js packages. Can’t be included in Meteor package list directly, but can be imported/used within Meteor local/Atmosphere package

Ref. Discover Meteor