Docker is an amazing tool for developers. It allows us to build and replicate images on any host, removing the inconsistencies of dev environments and reducing onboarding timelines considerably.<\/p>\n
To provide an example of how you might move to containerized development, I built a simple In a two-part series, I will cover the development and pipeline creation steps. In this post, I will cover the first part: developing and testing with Docker Compose.<\/p>\n This tutorial requires you to have a few items before you can get started.<\/p>\n The todo app here is essentially a stand-in, and you could replace it with your own application. Some of the setup here is specific for this application. The needs of your application may not be covered, but it should be a good starting point for you to get the concepts needed to Dockerize your own applications.<\/p>\n Once you have everything set up, you can move on to the next section.<\/p>\n At the foundation of any Dockerized application, you will find a In the root directory of the application, create a new Open the newly created If you run With only one instruction in the Dockerfile, this doesn\u2019t do too much, but it does show you the build process without too much happening. At this point, you now have an image created, and running The This particular Docker file uses RUN<\/a>, COPY<\/a>, and WORKDIR<\/a>. You can read more about those on Docker\u2019s reference page to get a deeper understanding.<\/p>\n Let\u2019s add the instructions to the Here is what is happening:<\/p>\n You can now run You have now successfully created the application image using Docker. Currently however, our app won\u2019t do much since we still need a database, and we want to connect everything together. This is where Docker Compose will help us out.<\/p>\n Now that you know how to create an image with a Create the file The Docker Compose file will define and run the containers based on a configuration file. We are using compose file version 3<\/a> syntax, and you can read up on it on Docker\u2019s site.<\/p>\n An important concept to understand is that Docker Compose works at \u201cruntime.\u201d Up until now, we have been building images using For example, the Open your This will take a bit to unpack, but let\u2019s break it down by service.<\/p>\n The first directive in the web service is to The Like the Python image we used, the Docker Store has a prebuilt image for PostgreSQL<\/a>. Instead of using a Now that we have our services defined, we can build the application using At this point, the application is running, and you will see log output in the console. You can also run the services as a background process, using At a new command prompt, you can run This will tell you the name of the services, the command used to start it, its current state, and the ports. Notice A small but important step not to overlook is the schema migration for the database. Compose comes with an Now we can try out the API:<\/p>\n The schema and all of the data in the container will persist as long as the Feel free to check out the source code, play around a bit, and see how things go for you.<\/p>\n The application itself includes some integration tests. There are various ways to go about testing with Docker, including creating The current containers are running using the project name Instead, we will use a different project name to run the application, isolating the tests into their own environment. Since containers are ephemeral (short-lived), running your tests in a separate set of containers makes certain that your app is behaving exactly as it should in a clean environment.<\/p>\n In your terminal, run the following command:<\/p>\n The Since the At this point, you should have a solid start using Docker Compose for local app development. In the next part of this series about using Docker Compose for Python development, I will cover integration and deployments of this application using Codeship.<\/p>\n Is your team using Docker in its development workflow? If so, I would love to hear about what you are doing and what benefits you see as a result.<\/p>\ntodo<\/code> API with Python<\/a>, Django REST Framework<\/a>, and PostgreSQL using Docker Compose<\/a> for development, testing, and eventually in my CI\/CD pipeline.<\/p>\nRequirements for This Tutorial<\/h2>\n
\n
Creating the Dockerfile<\/h2>\n
Dockerfile<\/code><\/a>. The Dockerfile<\/code> contains all of the instructions used to build out the application image. You can set this up by installing Python and all of its dependencies. However, the Docker ecosystem has an image repository with a Python<\/a> image already created and ready to use.<\/p>\nDockerfile<\/code>.<\/p>\n\/> touch Dockerfile<\/pre>\n
Dockerfile<\/code> in your favorite editor. The first instruction, FROM<\/code><\/a>, will tell Docker to use the prebuilt Python image. There are several choices, but this project uses the python:3.6.1-alpine<\/code> image. For more details about why I\u2019m using alpine<\/code> here over the other options, you can read this post<\/a>.<\/p>\nFROM python:3.6.1-alpine<\/pre>\n
docker build .<\/code>, you will see something similar to the following:<\/p>\nSending build context to Docker daemon 10.53MB\r\nStep 1\/1 : FROM python:3.6.1-alpine\r\n3.6.1-alpine: Pulling from library\/python\r\n90f4dba627d6: Pull complete\r\n19bc0bb0be9f: Pull complete\r\ne05eff433916: Pull complete\r\ne70196200a87: Pull complete\r\na6d780959950: Pull complete\r\nDigest: sha256:0945574465b917d524ce9b748479a286c2ed3c5a97311ac5950464907d4d8b53\r\nStatus: Downloaded newer image for python:3.6.1-alpine\r\n ---> ddd6300d05a3\r\nSuccessfully built ddd6300d05a3<\/pre>\n
docker images<\/code> will show you the images you have available:<\/p>\nREPOSITORY TAG IMAGE ID CREATED SIZE\r\npython 3.6.1-alpine ddd6300d05a3 5 weeks ago 88.7MB<\/pre>\n
Dockerfile<\/code> needs more instructions to build out the application. Currently it\u2019s only creating an image with Python installed, but we still need our application code to run inside the container. Let\u2019s add some more instructions to do this and build this image again.<\/p>\nDockerfile<\/code> now:<\/p>\nFROM python:3.6.1-alpine\r\n\r\nRUN apk update \\\r\n && apk add \\\r\n build-base \\\r\n postgresql \\\r\n postgresql-dev \\\r\n libpq\r\n\r\nRUN mkdir \/usr\/src\/app\r\nWORKDIR \/usr\/src\/app\r\nCOPY .\/requirements.txt .\r\nRUN pip install -r requirements.txt\r\n\r\nENV PYTHONUNBUFFERED 1\r\n\r\nCOPY . .<\/pre>\n
\n
apk<\/code> packages and then install a few additional requirements<\/li>\n\/usr\/src\/app<\/code><\/li>\n\/usr\/src\/app<\/code><\/li>\nrequirements.txt<\/code> to the working directory<\/li>\nrequirements.txt<\/code> file<\/li>\nPYTHONUNBUFFERED<\/code> to 1<\/li>\ndocker build .<\/code> again and see the results:<\/p>\nSending build context to Docker daemon 10.53MB\r\nStep 1\/8 : FROM python:3.6.1-alpine\r\n ---> ddd6300d05a3\r\nStep 2\/8 : RUN apk update && apk add build-base postgresql postgresql-dev libpq\r\n ---> Running in 22bfdcf8a0dd\r\nfetch http:\/\/dl-cdn.alpinelinux.org\/alpine\/v3.4\/main\/x86_64\/APKINDEX.tar.gz\r\nfetch http:\/\/dl-cdn.alpinelinux.org\/alpine\/v3.4\/community\/x86_64\/APKINDEX.tar.gz\r\nv3.4.6-165-g6b9a79f [http:\/\/dl-cdn.alpinelinux.org\/alpine\/v3.4\/main]\r\nv3.4.6-160-g14ad2a3 [http:\/\/dl-cdn.alpinelinux.org\/alpine\/v3.4\/community]\r\nOK: 5974 distinct packages available\r\n\r\n## APK packages installed ##\r\n\r\nExecuting busybox-1.24.2-r13.trigger\r\nOK: 215 MiB in 65 packages\r\n ---> 782357cafece\r\nRemoving intermediate container 22bfdcf8a0dd\r\nStep 3\/8 : ENV PYTHONUNBUFFERED 1\r\n ---> Running in 0d6de64f5f8b\r\n ---> 609106526013\r\nRemoving intermediate container 0d6de64f5f8b\r\nStep 4\/8 : RUN mkdir \/usr\/src\/app\r\n ---> Running in b30ac1098156\r\n ---> 17def88f6c5f\r\nRemoving intermediate container b30ac1098156\r\nStep 5\/8 : WORKDIR \/usr\/src\/app\r\n ---> 158d43ac2a47\r\nRemoving intermediate container fef446ea4ed0\r\nStep 6\/8 : COPY .\/requirements.txt .\r\n ---> 2751d1f4c313\r\nRemoving intermediate container a49b090cb8e3\r\nStep 7\/8 : RUN pip install -r requirements.txt\r\n ---> Running in eaf9912e4810\r\n\r\n## PIP Requirements Installed ##\r\n\r\nInstalling collected packages: pytz, Django, djangorestframework, psycopg2, django-cors-headers, dj-database-url, gunicorn, virtualenv\r\nSuccessfully installed Django-1.11.3 dj-database-url-0.4.2 django-cors-headers-2.1.0 djangorestframework-3.6.3 gunicorn-19.7.1 psycopg2-2.7.2 pytz-2017.2 virtualenv-15.1.0\r\n ---> dfcca42a45b0\r\nRemoving intermediate container eaf9912e4810\r\nStep 8\/8 : COPY . .\r\n ---> 61f356fba3ea\r\nRemoving intermediate container fda87c3db8cf\r\nSuccessfully built 61f356fba3ea<\/pre>\n
Docker Compose Services<\/h2>\n
Dockerfile<\/code>, let\u2019s create an application as a service and connect it to a database. Then we can run some setup commands and be on our way to creating that new todo list.<\/p>\ndocker-compose.yml<\/code>:<\/p>\n\/> touch docker-compose.yml<\/pre>\n
docker build .<\/code> \u2014 this is \u201cbuildtime.\u201d This is especially important when we add things like volumes<\/code> and command<\/code> because they will override what is set up at \u201cbuildtime.\u201d<\/p>\nusr\/src\/app<\/code> directory will be created during the build. We then map that directory to the host machine, and the host machine application code will be used during \u201cruntime.\u201d This allows us to make changes locally, and those are then accessible in the container.<\/p>\ndocker-compose.yml<\/code> file in your editor, and copy paste the following lines:<\/p>\nversion: '3'\r\nservices:\r\n web:\r\n build: .\r\n command: gunicorn -b 0.0.0.0:8000 todosapp.wsgi:application\r\n depends_on:\r\n - postgres\r\n volumes:\r\n - .:\/usr\/src\/app\r\n ports:\r\n - \"8000:8000\"\r\n environment:\r\n DATABASE_URL: postgres:\/\/todoapp@postgres\/todos\r\n postgres:\r\n image: postgres:9.6.2-alpine\r\n environment:\r\n POSTGRES_USER: todoapp\r\n POSTGRES_DB: todos<\/pre>\n
The web service<\/h3>\n
build<\/code> the image based on our Dockerfile<\/code>. This will recreate the image we used before, but it will now be named according to the project we are in, name<\/code>. After that, we are giving the service some specific instructions on how it should operate:<\/p>\n\n
command: gunicorn -b 0.0.0.0:8000 todosapp.wsgi:application<\/code> \u2013 Once the image is built, and the container is running, this command will start the application.<\/li>\ndepends_on:<\/code> \u2013 This will tell Docker Compose to start up the postgres<\/code> service when the web<\/code> service runs.<\/li>\nvolumes:<\/code> \u2013 This section will mount paths between the host and the container.<\/li>\n.:\/usr\/src\/app<\/code> \u2013 This will mount the root directory to our working directory in the container.<\/li>\nenvironment:<\/code> \u2013 The application itself expects the environment variable DATABASE_URL<\/code> to run.<\/li>\nports:<\/code> \u2013 This will publish the container\u2019s port, in this case 8000<\/code>, to the host as port 8000<\/code>.<\/li>\n<\/ul>\nDATABASE_URL<\/code> is the connection string. postgres:\/\/todoapp@postgres\/todos<\/code> connects using the todoapp<\/code> user, on the host postgres<\/code>, using the database todos<\/code>.<\/p>\nThe Postgres service<\/h3>\n
build<\/code> directive, we can use the name of the image, and Docker will grab that image for us and use it. In this case, we are using postgres:9.6.2-alpine<\/code>. We could leave it like that, but it has environment<\/code> variables to let us customize it a bit.<\/p>\n\n
environment:<\/code> \u2013 This particular image accepts a couple environment variables so we can customize things to our needs.<\/li>\nPOSTGRES_USER: todoapp<\/code> \u2013 This creates the user todoapp<\/code> as the default user for PostgreSQL.<\/li>\nPOSTGRES_DB: todos<\/code> \u2013 This will create the default database as todos<\/code>.<\/li>\n<\/ul>\nRunning The Application<\/h2>\n
docker-compose up<\/code>. This will show the images being built and eventually starting. After the initial build, you will see the names of the containers being created.<\/p>\nPulling postgres (postgres:9.6.2-alpine)...\r\n9.6.2-alpine: Pulling from library\/postgres\r\ncfc728c1c558: Pull complete\r\nb749e72b24f9: Pull complete\r\n0abdb8c9c36b: Pull complete\r\n90ca3848ef7e: Pull complete\r\n3ecf037a5034: Pull complete\r\n9327e3c5554c: Pull complete\r\n3133782bad17: Pull complete\r\n143bac6c8910: Pull complete\r\nd6da9f4bd18e: Pull complete\r\nDigest: sha256:f88000211e3c682e7419ac6e6cbd3a7a4980b483ac416a3b5d5ee81d4f831cc9\r\nStatus: Downloaded newer image for postgres:9.6.2-alpine\r\nBuilding web\r\n...\r\nCreating pythondjangotodoapp_postgres_1 ...\r\nCreating pythondjangotodoapp_postgres_1 ... done\r\nCreating pythondjangotodoapp_web_1 ...\r\nCreating pythondjangotodoapp_web_1 ... done\r\n...\r\nweb_1 | [2017-08-03 13:23:18 +0000] () [INFO] Starting gunicorn 19.7.1\r\nweb_1 | [2017-08-03 13:23:18 +0000] () [INFO] Listening at: http:\/\/0.0.0.0:8000 (1)<\/pre>\n
docker-compose up -d<\/code>. During development, I prefer to run without -d<\/code> and create a second terminal window to run other commands. If you want to run it as a background process and view the logs, you can run docker-compose logs<\/code>.<\/p>\ndocker-compose ps<\/code> to view your running containers. You should see something like the following:<\/p>\nName Command State Ports\r\n------------------------------------------------------------------------------------------------\r\npythondjangotodoapp_postgres_1 docker-entrypoint.sh postgres Up 5432\/tcp\r\npythondjangotodoapp_web_1 gunicorn -b 0.0.0.0:8000 t ... Up 0.0.0.0:8000->8000\/tcp<\/pre>\n
pythondjangotodoapp_web_1<\/code> has listed the port as 0.0.0.0:8000->8000\/tcp<\/code>. This tells us that you can access the application using localhost:8000\/todos<\/code> on the host machine.<\/p>\nMigrate the database schema<\/h3>\n
exec<\/code><\/a> command that will execute a one-off command on a running container. The typical function to migrate schemas is python manage.py migrate<\/code>. We can run that on the web service using docker-compose exec<\/code>.<\/p>\n\/> docker-compose exec web python manage.py migrate\r\nOperations to perform:\r\n Apply all migrations: admin, auth, contenttypes, sessions, todos\r\nRunning migrations:\r\n Applying contenttypes.0001_initial... OK\r\n Applying auth.0001_initial... OK\r\n Applying admin.0001_initial... OK\r\n Applying admin.0002_logentry_remove_auto_add... OK\r\n Applying contenttypes.0002_remove_content_type_name... OK\r\n Applying auth.0002_alter_permission_name_max_length... OK\r\n Applying auth.0003_alter_user_email_max_length... OK\r\n Applying auth.0004_alter_user_username_opts... OK\r\n Applying auth.0005_alter_user_last_login_null... OK\r\n Applying auth.0006_require_contenttypes_0002... OK\r\n Applying auth.0007_alter_validators_add_error_messages... OK\r\n Applying auth.0008_alter_user_username_max_length... OK\r\n Applying sessions.0001_initial... OK\r\n Applying todos.0001_initial... OK<\/pre>\n
\/> curl localhost:8000\/todos\r\n\r\n[]<\/pre>\n
postgres:9.6.2-alpine<\/code> image is not removed. Eventually, however, it would be good to check how your app will build with a clean setup. You can run docker-compose down<\/code>, which will clear things that are built and let you see what is happening with a fresh start.<\/p>\nTesting the Application<\/h2>\n
Dockerfile.test<\/code> and docker-compose.test.yml<\/code> files specific for the test environment. That\u2019s a bit beyond the current scope of this article, but I want to show you how to run the tests using the current setup.<\/p>\npythondjangotodoapp<\/code>. This is a default from the directory name. If we attempt to run commands, it will use the same project, and containers will restart. This is what we don\u2019t want.<\/p>\n\/> docker-compose -p tests run -p 8000 --rm web python manage.py test\r\nStarting tests_postgres_1 ... done\r\nCreating test database for alias 'default'...\r\nSystem check identified no issues (0 silenced).\r\n........\r\n----------------------------------------------------------------------\r\nRan 8 tests in 0.086s\r\n\r\nOK\r\nDestroying test database for alias 'default'...<\/pre>\n
docker-compose<\/code> command accepts several options<\/a>, followed by a command. In this case, you are using -p tests<\/code> to run the services under the tests<\/code> project name. The command being used is run<\/code><\/a>, which will execute a one-time command against a service.<\/p>\ndocker-compose.yml<\/code> file specifies a port, we use -p 8000<\/code> to create a random port to prevent port collision. The --rm<\/code> option will remove the containers when we stop the containers. Finally, we are running in the web<\/code> service python manage.py test<\/code>.<\/p>\nConclusion<\/h2>\n