Using Docker Compose for PHP Development

This post was originally published on the Codeship Blog and is posted here with the author's permission.

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.

To provide an example of how you might move to containerized development, I built a simple todo API with PHP, Laravel, and PostgreSQL using Docker Compose for development, testing, and eventually in my CI/CD pipeline.

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.

Requirements for This Tutorial

This tutorial requires you to have a few items before you can get started.

• Install Docker Community Edition
• Install Docker Compose
• Download Todo App Example - Non- Docker branch

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, and 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.

Once you have everything set up, you can move on to the next section.

Creating the Dockerfile

At the foundation of any Dockerized application, you will find a Dockerfile. The Dockerfile contains all of the instructions used to build out the application image. You can set this up by installing PHP and all of its dependencies, however, the Docker ecosystem has an image repository with a PHP image already created and ready to use.

In the root directory of the application, create a new Dockerfile.

/> touch Dockerfile

Open the newly created Dockerfile in your favorite editor. The first instruction, FROM, will tell Docker to use the prebuilt PHP image. There are several choices, but this project uses the php:5.6.30-fpm-alpine image. For more details about why I'm using alpine here over the other options, you can read this post.

FROM php:5.6.30-fpm-alpine

If you run docker build ., you will see something similar to the following:

Sending build context to Docker daemon 1.141 MB
Step 1/1 : FROM php:5.6.30-fpm-alpine
5.6.30-fpm-alpine: Pulling from library/php
709515475419: Pull complete
2cda85d7c7d4: Pull complete
dd7a8556500b: Pull complete
96365c659331: Pull complete
2c7770354fce: Pull complete
be277856d200: Pull complete
1ffa80d6c3a1: Pull complete
abd20be2d28d: Pull complete
d8275ff24d93: Pull complete
c5f0cf74515d: Pull complete
Digest: sha256:8c53cd1d1739023e4fd4b5ee5732ba26fcf9db7c8731275f8eb6bfe780a5b942
Status: Downloaded newer image for php:5.6.30-fpm-alpine
 ---> 4461ceb8e332
Successfully built 4461ceb8e332

With only one instruction in the Dockerfile, this doesn't 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 docker images will show you the images you have available:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
php                 5.6.30-fpm-alpine   4461ceb8e332        8 weeks ago         54.5 MB

The Dockerfile needs more instructions to build out the application. Currently it’s only creating an image with PHP installed, but we still need our application code to run inside the container. Let's add some more instructions to do this and build this image again.

This particular Docker file uses RUN, COPY, and WORKDIR. You can read more about those on Docker's reference page to get a deeper understanding.

Let's add the instructions to the Dockerfile now:

FROM php:5.6.30-fpm-alpine

RUN apk update && apk add build-base

RUN apk add postgresql postgresql-dev \
  && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \
  && docker-php-ext-install pdo pdo_pgsql pgsql

RUN apk add zlib-dev git zip \
  && docker-php-ext-install zip

RUN curl -sS https://getcomposer.org/installer | php \
        && mv composer.phar /usr/local/bin/ \
        && ln -s /usr/local/bin/composer.phar /usr/local/bin/composer

COPY . /app
WORKDIR /app

RUN composer install --prefer-source --no-interaction

ENV PATH="~/.composer/vendor/bin:./vendor/bin:${PATH}"

Here is what is happening:

• Update apk packages and then install the base-build package
• Add additional packages, then update the PHP config and install extensions
• Download and setup composer
• Copy the files from root to /app
• Set the working directory to /app
• Install required composer packages
• Set the PATH environment variable

You can now run docker build . again, and see the results:

Sending build context to Docker daemon 1.141 MB
Step 1/9 : FROM php:5.6.30-fpm-alpine
 ---> 4461ceb8e332
Step 2/9 : RUN apk update && apk add build-base
 ---> Running in 65b476b2930f
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.6-111-g0e3ca69 [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.6-83-g67e50bc [http://dl-cdn.alpinelinux.org/alpine/v3.4/community]
OK: 5977 distinct packages available

## APK packages installed ##

Executing busybox-1.24.2-r13.trigger
OK: 167 MiB in 44 packages
 ---> cdc2c3372082
Removing intermediate container 65b476b2930f
Step 3/9 : RUN apk add postgresql-dev   && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql   && docker-php-ext-install pdo pdo_pgsql pgsql
---> Running in c841a3c3e218

## APK packages installed ##

Executing busybox-1.24.2-r13.trigger
OK: 200 MiB in 56 packages
---> 12bf760a8c33
Removing intermediate container 1490da0824e9
Step 5/9 : RUN curl -sS https://getcomposer.org/installer | php         && mv composer.phar /usr/local/bin/         && ln -s /usr/local/bin/composer.phar /usr/local/bin/composer
---> Running in 1ba7e9478e8c
All settings correct for using Composer
Downloading...

Composer (version 1.4.1) successfully installed to: /var/www/html/composer.phar
Use it: php composer.phar

---> 2c750fbd7005
Removing intermediate container 1ba7e9478e8c
Step 6/9 : COPY . /app
---> 45fb65033911
Removing intermediate container ec20dc5b20d7
Step 7/9 : WORKDIR /app
---> 52a1093b4739
Removing intermediate container 473e3313e5c3
Step 8/9 : RUN composer install --prefer-source --no-interaction
---> Running in f7f34475a00a

 ## Composer packages installed ##

Generating optimized class loader
The compiled services file has been removed.
 ---> 8f8788e274ab
Removing intermediate container f7f34475a00a
Step 9/9 : ENV PATH "~/.composer/vendor/bin:./vendor/bin:${PATH}"
 ---> Running in e67555179ae3
 ---> 06f03b121b05
Removing intermediate container e67555179ae3
Successfully built 06f03b121b05

You have now successfully created the application image using Docker. Currently, however, our app won't do much since we still need a database and nginx, and we want to connect everything together. This is where Docker Compose will help us out.

Docker Compose Services

Now that you know how to create an image with a Dockerfile, let's create the application as a service and connect it to a database, and then run it on nginx. Then we can run some setup commands and be on our way to creating that new todo list.

Create the file docker-compose.yml.

/> touch docker-compose.yml

The Docker Compose file will define and run the containers based on a configuration file. We are using compose file version 2 syntax, and you can read up on it on Docker's site.

An important concept to understand is that Docker Compose spans "buildtime" and "runtime." Up until now, we have been building images using docker build ., which is "buildtime." This is when our containers are actually built. We can think of "runtime" as what happens once our containers are built and being used.

Compose triggers "buildtime" -- instructing our images and containers to build -- but it also populates data used at "runtime," such as env vars and volumes. This is important to be clear on. For instance, when we add things like volumes and command, they will override the same things that may have been set up via the Dockerfile at "buildtime."

Open your docker-compose.yml file in your editor, and copy paste the following lines:

version: '2'
services:
  nginx:
    image: nginx:1.11.10-alpine
    ports:
      - 3000:80
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
  web:
    build: .
    ports:
      - 9000:9000
    volumes:
      - .:/app
      - /app/vendor
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgres://todoapp@postgres/todos
  postgres:
    image: postgres:9.6.2-alpine
    environment:
      POSTGRES_USER: todoapp
      POSTGRES_DB: todos

This will take a bit to unpack, but let's break it down by service.

The NGINX service

A typical setup on our local environment will require we run some sort of web server. For this example, I'm using nginx. Like the PHP image we used, the Docker Store has a prebuilt image for NGINX. Instead of using a build 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 nginx:1.11.10-alpine.

• image: nginx:1.11.10-alpine - Similar to the other services, we are using the alpine version.
• ports: - This will publish the containers port, in this case 80, to the host as port 3000.
• volumes: - nginx needs a configuration file. We can build that locally, and this will use the local file as the default.conf file.

The web service

The first directive in the web service is to build the image based on our Dockerfile. This will recreate the image we used before, but it will now be named according to the project folder we are in, phplaraveltodoapp. After that, we are giving the service some specific instructions on how it should operate:

• volumes: - This section will mount paths between the host and the container.
• .:/app/ - This will mount the root directory to our working directory in the container.
• /app/vendor - This will connect the /app/vendor at runtime, so we don't overwrite the built vendor directory.
• environment: - The application itself expects the environment variable DATABASE_URL to run. This is set in ./config/database.php.
• ports: - This will post the container's port, in this case 9000, to the host as port 9000.

The DATABASE_URL is the connection string. postgres://todoapp@postgres/todos connects using the todoapp user, on the host postgres, using the database todos.

The Postgres service

The Docker Store also has a prebuilt image for PostgreSQL that we will use just like the other two.

• environment: - This particular image accepts a couple environment variables so we can customize things to our needs.
• POSTGRES_USER: todoapp - This creates the user todoapp as the default user for PostgreSQL.
• POSTGRES_DB: todos - This will create the default database as todos.

Running the Application

Now that we have our services defined, we can build the application using docker-compose up. This will show the images being built and eventually starting. After the initial build, you will see the names of the containers being created.

Creating network "phplaraveltodoapp_default" with the default driver
Pulling postgres (postgres:9.6.2-alpine)...
9.6.2-alpine: Pulling from library/postgres
627beaf3eaaf: Pull complete
e351d01eba53: Pull complete
cbc11f1629f1: Pull complete
2931b310bc1e: Pull complete
2996796a1321: Pull complete
ebdf8bbd1a35: Pull complete
47255f8e1bca: Pull complete
4945582dcf7d: Pull complete
92139846ff88: Pull complete
Digest: sha256:7f3a59bc91a4c80c9a3ff0430ec012f7ce82f906ab0a2d7176fcbbf24ea9f893
Status: Downloaded newer image for postgres:9.6.2-alpine
Building web

## Builds the web image ##

Pulling nginx (nginx:1.11.10-alpine)...
1.11.10-alpine: Pulling from library/nginx
709515475419: Already exists
5142c3ee45c6: Pull complete
6393d8407bbe: Pull complete
0816ea01673a: Pull complete
Digest: sha256:aa0daf2b17c370a1da371a767110a43b390a9db90b90d2d1b07862dc81754d61
Status: Downloaded newer image for nginx:1.11.10-alpine
Creating phplaraveltodoapp_postgres_1
Creating phplaraveltodoapp_web_1
Creating phplaraveltodoapp_nginx_1

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 docker-compose up -d. During development, I prefer to run without -d 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.

At a new command prompt, you can run docker-compose ps to view your running containers. You should see something like the following:

          Name                          Command              State               Ports
----------------------------------------------------------------------------------------------------
phplaraveltodoapp_nginx_1      nginx -g daemon off;            Up      443/tcp, 0.0.0.0:3000->80/tcp
phplaraveltodoapp_postgres_1   docker-entrypoint.sh postgres   Up      5432/tcp
phplaraveltodoapp_web_1        docker-php-entrypoint php-fpm   Up      0.0.0.0:9000->9000/tcp

This will tell you the name of the services, the command used to start it, its current state, and the ports. Notice phplaraveltodoapp_nginx_1 has listed the port as 443/tcp, 0.0.0.0:3000->80/tcp. This tells us that you can access the application using localhost:3000/todos on the host machine and we aren't currently exposing 443.

Migrate the database schema

A small but important step not to overlook is the schema migration for the database. Compose comes with an exec command that will execute a one-off command on a running container. The typical function to migrate schemas is php artisan migrate; we can run that on the web service using docker-compose exec.

/> docker-compose exec web php artisan migrate

**************************************
*     Application In Production!     *
**************************************

 Do you really wish to run this command? (yes/no) [no]:
 > yes  ## you will need to type 'yes'

Migration table created successfully.
Migrating: 2017_03_24_162139_create_todos_table
Migrated: 2017_03_24_162139_create_todos_table

Now we can try out the API:

/> curl localhost:3000/todos

[]

The schema and all of the data in the container will persist as long as the postgres:9.6.2-alpine 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, which will clear things that are built and let you see what is happening with a fresh start.

Feel free to check out the source code, play around a bit, and see how things go for you.

Testing the Application

The application itself includes some integration tests built using phpunit. There are various ways to go about testing with Docker, including creating Dockerfile.test and docker-compose.test.yml files specific for the test environment. That's a bit beyond the current scope of this article, but I want to show you how to run the tests using the current setup.

The current containers are running using the project name phplaraveltodoapp. 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't want. 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.

In your terminal, run the following command:

/> docker-compose -p tests run --rm web phpunit

## Images build ##

PHPUnit 5.7.17 by Sebastian Bergmann and contributors.

......                                                              6 / 6 (100%)

Time: 1.27 seconds, Memory: 16.50MB

OK (6 tests, 16 assertions)

The docker-compose command accepts several options, followed by a command. In this case, you are using -p tests to run the services under the tests project name. The command being used is run, which will execute a one-time command against a service. The --rm option will remove the containers after the command runs. Finally, we are running in the web service phpunit.

Conclusion

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 PHP development, I will cover integration and deployments of this application using Codeship.

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.