In the previous post we looked at the process of designing a build container, consisting of all the required build tools for generating a static website from source files. In order to see the result of the build process, we still need to design another container, which runs a simple web server, serving the static website (mainly .html, .css, .js and .jpg files).

Designing the blog container

We'll use a light-weight install of Nginx as the base image and simply copy the website files to the default document root (/usr/share/nginx/html) (only after removing any placeholder files that are currently inside that directory). The complete file docker/blog/Dockerfile looks like this:

FROM nginx:1.11-alpine
RUN rm -rf /usr/share/nginx/html
COPY output /usr/share/nginx/html

Eventually, I want to turn this into something more advanced, by configuring SSL, and by making the pages "auto-fast" with the Pagespeed module developed by Google. But for now, this basic image is just fine (and pretty fast).

Let's add the blog container to docker-compose.yml too:

version: '2'

services:
    blog:
        # optional
        container_name: php-and-symfony-blog

        # tag the image, so we can later push it
        image: matthiasnoback/php-and-symfony-blog

        # should Nginx crash, always restart it
        restart: always

        # treat port 80 of the host as port 80 of the container
        ports:
            - 80:80

Remember I've used docker-compose.override.yml to define development-specific configuration for Docker? Since we're only building the container in a development environment, the build configuration for the blog container only needs to be in available in docker-compose.override.yml:

version: '2'

services:
    build:
        # already defined in the previous post...

    blog:
        build:
            context: ./
            dockerfile: docker/blog/Dockerfile
        volumes:
            # Nginx should pick up local changes to files in ./output
            - ./output:/usr/share/nginx/html

For development purposes, we make sure that the current contents of the output/ directory will always be available for Nginx to serve. To achieve this, we only need to mount output/ as a volume at Nginx's default document root location.

After building the website files using docker compose run build all, we can start serving the blog: docker compose up -d blog. We use up -d to start the web server in detached mode and keep it running. We can now look at the website by opening https://localhost in a browser.

Next up: deploying the blog container

The promise of Docker to me was: producing a build artifact that can travel through a build pipeline and eventually be deployed as-is to a production server. Deploying a static website is particularly easy now that we have a simple blog container that really is a self-contained web server. We'll look into deployment in the next post.