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