Working with containers


Pushing a certain applications image

In this repository the Django app that is being served is called simpleblog. In the projects folder is it’s Dockerfile. In order to speed up the docker-compose flow, creating and then pushing an updated projects image is important.

  1. Make changes to the Django project (td)
  2. cd into the project directory that houses the Dockerfile
  3. docker build -t code .
  4. docker push aleccunningham/code

And that will update the image on the official Docker hub. Now in our web container, we can replace build: ./td/ with image: aleccunningham/code, and each version will be cached to your machine, and will update when a new version is pushed. You can do this with multiple projects in the same parent directory, as long as each have their own Dockerfile. If needed, you can use the -f flag to specify a custom Dockerfile.

Working on a specific container

Use the --no-deps flag to start just one individual container when running a command. For example:

docker-compose run --no-deps web python manage.py shell

Which would open a Django shell without bringing up any of the other containers.

Virtual Machines

There are multiple ways to go about booting up the services externally. All, however, are basically the same as they prep a barebones server for docker and then run’s the docker-compose. For Production software like Ansible is the easiest, especially when load balancing/using swarms. But in development, a service like hypersh works really well. In just a few minutes you can assign a public IP address to the service(s) and bring them online (underneath the magic are AWS servers). The best part of hyper are its similarities to Docker’s CLI. Assign a public IP using hyper fip and then bring the service up:

$ hyper fip allocate 1
147.75.99.77

Then, add a fip option to your docker-compose file:

services:
  web:
    image: wordpress:latest
    fip: 147.75.99.77
    links:
      - db:mysql
    depends_on:
      - db
    ports:
      - "8080:80"

Now run hyper compose up to visit your web service on 147.75.99.77.

Production

If you would like to serve your Django project through Gunicorn and Nginx, replicating a prod environment, just run the up command but with the normal compose file:

$ docker-compose up -d

Inline-style: alt text

This will use the Nginx config file located in /etc/nginx, and builds from the Dockerfile located there. All other commands can be used as if you were using the dev environment, just ommiting the docker-compose.dev.yml, as it will fall back onto the prod one.

Note, this does not run migrations on start.

To restore the production database to a local Postgres database, open a bash shell and run the following:

$ createdb NAME_OF_DATABASE
$ psql NAME_OF_DATABASE < NAME_OF_BACKUP_FILE