5.4. Container Configuration#

A lot depends on your container image. If you build it correctly you’ll find that it “just works” as you build a scalable system around it. If there are problems with it, it’ll seem like Kubernetes is fighting you every step of the way. In this lab and the next one we’ll get into the little details that make a good container image, starting with setting environment variables and data locations.

Default Settings#

The settings for your application should be set with environment variables that are documented in your README.md and have defaults in your Dockerfile. Users of your container will be able to read how to configure your application to meet their needs while also being able to rely on working defaults if they just want to try it out.

Here are the environment variables that are the code:

Environment Variable

Dockerfile Default

Purpose

STUDENT_NAME

"No Name"

Puts your name on the index page.

SITE_NAME

"www.cis-92.com"

The URL of your site.

SECRET_KEY

"fixme-12345"

The key used to encrypt session cookies. Must be kept secret or attackers can bypass your login screen.

DEBUG

1

Enables debugging mode, which is less secure but gives application developers important help.

DATA_DIR

"/data"

The place where the db.sqlite3 data is located. A new one will be created if it doesn’t exist.

PORT

8080

The TCP port your application will use.

DJANGO_SUPERUSER_NAME

test

The login name of the superuser.

DJANGO_SUPERUSER_EMAIL

test@test.test

The email address of the superuser.

DJANGO_SUPERUSER_PASSWORD

test

The password of the superuser.

For each of the environment variables add a line to your Dockerfile that sets them to their defaults. Like this:

ENV STUDENT_NAME="No Name"

Should Defaults be Secure?#

There is a strong argument to make for not setting a default for SECRET_KEY and DEBUG. Having an insecure key and DEBUG turned on creates an application that’s vulnerable. What’s more important, having users be able to easily start your application in their own environments or making sure they never deploy your application in an insecure configuration?

Warning

Notice the warning you get when you try to build this container. Think about what the alternative might be.

Try a Build and Run#

Error

The container is broken at this point. Keep going!

$ mkdir ~/data
$ docker build -t myapp .
$ docker run -it --rm \
    -u $(id -u):$(id -g) \
    -p 8080:8080 \
    -v $HOME/data:/data \
    myapp