Jose Armesto's Blog

Continuous Integrating my Kubernetes controller using Kind

Sat, 18 May 2019 23:47:55 +0000

Kubernetes controllers are processes that react to changes in the state of some objects saved on the Kubernetes API. They do this by watching the Kubernetes API so that they get notified whenever the state changes.

But how do we know if our Kubernetes controller is doing what’s supposed to do? We can write unit tests that test our logic in isolation to get some confidence, but it would be great if we could add some end to end tests using the real Kubernetes API.

However, deploying Kubernetes is not an easy task. And even if we managed to accomplish it, it would take a long time to deploy a Kubernetes cluster so we could test every change to our code base.

In this post, I’m going to explain how I used kind to test that my controller is working as expected, using a real Kubernetes API.

Creating the cluster using kind

My Kubernetes controller is pretty simple. Whenever a Deployment object is created containing an specific annotation, it will add an annotation to the Pods belonging to that Deployment. I created this controller because we needed a way for developers to specify that the application that they were deploying required AWS IAM credentials to use AWS services, but we didn’t want developers to have to know things like the AWS account id to use. By using this controller, the Kubernetes cluster administrators configure which AWS Account to use on every Kubernetes namespace. And developers just indicate whether their application requires IAM authentication or not, by adding an annotation. Simple.

Anyway, I wanted to create an end to end test that would do the following:

Create a Kubernetes cluster
Install the controller using the version that we are testing
Create a Deployment that contains the annotation that will trigger the controller
Test that the Pods of the Deployment contain the IAM annotation

For the Kubernetes cluster I used kind, a recent project that let’s you deploy a Kubernetes cluster using only a Docker container. Obviously, it’s not meant to be used on production, but it’s perfect for testing purposes. To create a cluster with kind, you just need to

$ kind create cluster

And that’s it! It’s that simple. We can see the cluster is running inside a single container

$ docker ps
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                                  NAMES
c27f2c8fa39e        kindest/node:v1.14.1   "/usr/local/bin/entr…"   22 minutes ago      Up 22 minutes       63711/tcp, 127.0.0.1:63711->6443/tcp   kind-control-plane

Now you just need to make kubectl send requests to that cluster, using the command

$ export KUBECONFIG="$(kind get kubeconfig-path)"

I’m also creating a new Namespace where I’ll run all the things required for this test. This is not important during Continuous Integration (CI), where everything will be deleted when the CI job is finished. But I do it this way because I can then easily run the same test locally on other Kubernetes clusters like Minikube, while not on CI. When the test is done, I just remove the namespace to leave no traces of the test execution.

Installing my controller

Now I need to install the piece of code that I want to test: my controller. The controller repository contains a Helm chart to make it easy to install it, so I’ll just use it. That way, I’m also testing whether or not the Helm chart is working as expected.

$ helm upgrade --tiller-namespace ${NAMESPACE} --namespace "${NAMESPACE}" --wait --install "iam-role-annotator" "./charts/iam-role-annotator" --set image.tag="${TRAVIS_COMMIT:-latest}" --set awsAccountId="${AWS_ACCOUNT_ID}"

The value for the AWS_ACCOUNT_ID variable is important. It’s the same AWS Account Id that needs to be added as annotation on applications. Notice that I passed the --wait argument to Helm. This will block the command until my controller is running and ready. If it fails to start for whatever reason, the test would automatically fail.

Create annotated deploy and check the results

My controller is ready and waiting for applications that contain the right annotation. Creating a simple hello world application containing that annotation is enough to trigger my controller. Let’s use a simple nginx deployment

$ cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: ${NAMESPACE}
  labels:
    app: nginx
  annotations:
    armesto.net/iam-role-annotator: "true"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        prometheus.io/scheme: http
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
EOF

Notice the important annotation for my controller: armesto.net/iam-role-annotator: true.

Now I just need to wait for my controller to react.

Then I can test if the pods belonging to the hello world deployment contain the required annotation. For that I used jq, a handly command line tool to inspect json data.

POD_NAME=$(kubectl get pods --namespace ${NAMESPACE} --field-selector=status.phase=Running -l "app=nginx" -o jsonpath="{.items[0].metadata.name}")

if [[ $(kubectl get pod --namespace ${NAMESPACE} ${POD_NAME} -o json | jq '.metadata.annotations' | jq 'contains({"iam.amazonaws.com/role"})') == 'true' ]]; then
  if [[ $(kubectl get pods --namespace ${NAMESPACE} ${POD_NAME} -o json | jq -r '.metadata.annotations."iam.amazonaws.com/role"') == "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${DEPLOYMENT_NAME}" ]]; then
    echo "SUCCESS!"
    exit 0
  else
    echo "ERROR: the annotation contains the wrong value"
    kubectl get pod --namespace ${NAMESPACE} ${POD_NAME} -o json | jq '.'
    exit 1
  fi
else
  echo "ERROR: the POD does not contain the expected annotation"
  kubectl get pod --namespace ${NAMESPACE} ${POD_NAME} -o json | jq '.'
  exit 1
fi

Conclusion

Every time I push some changes to this controller, the CI pipeline kicks in, and my end to end test gets executed creating a Kubernetes cluster thanks to kind.

Now I have much more confidence that my changes will work as expected when deploying the controller to our production clusters, and that makes a huge difference.

Automatically versioning your Application on Jenkins X

Fri, 01 Feb 2019 23:47:55 +0000

Having a good versioning strategy for our applications is key. Specially in Jenkins X, which follows the GitOps flow to deploy our applications, specifying which version of our application will be used on each environment.

But having to manually create tags or releases for our applications can be a tedious task. Jenkins X automatically takes care of versioning for us. It uses a tool called jx-release-version to figure out which is the next version to be released. In order to do that it checks what’s the current released version in the repository looking at the released Git tags. It can also read this version from your pom.xml file, or your Makefile.

If we use semver semantics, and versions are written in the format major.minor.patch, jx-release-version will tell you which is the next patch version.

The cool thing is that you don’t need to use Jenkins X to use jx-release-version!

Let’s go through some examples.

Using git tags

Using git tags is probably the easiest way to handle our application versions. We can create a new git tag for every new version that we want to release.

If we try to use jx-release-version on a Git repository that has no tags, it will return that the next version number to release is 0.0.1. Next time we use jx-release-version, it will increase our patch number.

$ git --no-pager tag -l
$ # there are no tags just yet!
$ RELEASE_VERSION=`jx-release-version` && git tag -fa v${RELEASE_VERSION} -m 'Release version ${RELEASE_VERSION}'
$ git --no-pager tag -l
v0.0.1
$ RELEASE_VERSION=`jx-release-version` && git tag -fa v${RELEASE_VERSION} -m 'Release version ${RELEASE_VERSION}'
$ git --no-pager tag -l
  v0.0.1
  v0.0.2

Using maven pom file

If you are using a pom.xml file that also tracks your current application version, you still can use jx-release-version. It will try to sync the git tags in your Git repository with the version that you specify in the pom.xml file.

Your release process needs to look something like this

# First we call the `jx-release-version` binary that will return the next version number to be released.
# Every time we call the binary it will try to figure out the next version number. Normally it's not a good idea to call it more than once.
RELEASE_VERSION=`jx-release-version`
echo "New release version ${RELEASE_VERSION}

# We update our current pom.xml file with this new version number.
mvn versions:set -DnewVersion=${RELEASE_VERSION}

# Changes to the pom.xml file need to be committed to our repository.
git commit -a -m 'release ${RELEASE_VERSION}'

# The git commit containing both our application changes and the change to the pom.xml file will be tagged using the same version number.
git tag -fa v${RELEASE_VERSION} -m 'Release version ${RELEASE_VERSION}'

# Push the commit and tag to the remote repository.
git push origin v${RELEASE_VERSION}

If we start a new git repository that has no tags, the jx-release-version will use the version in our pom.xml file.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>io.example</groupId>
    <artifactId>example</artifactId>
    <version>1.0-0-SNAPSHOT</version>
    <packaging>pom</packaging>
</project>

The release version for 1.0.0-SNAPSHOT is 1.0.0, so jx-release-version will return 1.0.0 as the next version number to use. Similarly, if our pom.xml file had <version>0.0-23-SNAPSHOT</version> in it, jx-release-version would return 0.0.23 as the next version number to use.

Using a Makefile

Let’s say we have this Makefile that tracks the current version of our application

# This is the current version of your application
VERSION := 2.0.3-SNAPSHOT

# Use jx-release-version to calculate next version
RELEASE_VERSION := $(shell jx-release-version)

build:
	# The git commit containing our application changes will be tagged.
	git tag -fa v${RELEASE_VERSION} -m 'Release version ${RELEASE_VERSION}'

	# Push the tag to the remote repository.
	git push origin v${RELEASE_VERSION}

The current version of our application is 2.0.3-SNAPSHOT. That means that the jx-release-version will return 2.0.3 as the next version number to use.

Releasing a new major/minor version

Sometimes we don’t want to just release a new patch version (like going from 1.0.5 to 1.0.6). Instead, we want to release 1.1.0, or even 2.0.0. We have said earlier that jx-release-version calculates the next version number based on the current Git tag, or current specified version on pom.xml/Makefile. So if we need to release a new major/minor version, we just have to release a new Git tag or update the pom.xml/Makefile.

For example, if the current version is 0.0.2 and we want to release 0.1.0, we first create a git tag for that and let jx-release-version do it’s thing afterwards.

# Manually create new tag for the version that we want
git tag -fa v0.1.0 -m "Release version 0.1.0"
# Use jx-release version normally
$ RELEASE_VERSION=`jx-release-version` && git tag -fa v${RELEASE_VERSION} -m 'Release version ${RELEASE_VERSION}'
$ git --no-pager tag -l
v0.0.1
v0.0.2
v0.1.0
v0.1.1

As said in the project’s README

If your project is new or has no existing git tags then running jx-release-version will return a default version of 0.0.1
If your latest git tag is 1.2.3 and you Makefile or pom.xml is 1.2.0-SNAPSHOT then jx-release-version will return 1.2.4
If your latest git tag is 1.2.3 and your Makefile or pom.xml is 2.0.0 then jx-release-version will return 2.0.0

Jenkins X Environments

Wed, 05 Dec 2018 23:47:55 +0000

This year Jenkins X has been announced. If you haven’t heard, Jenkins X is a tool that lets you automate the whole delivery process of your software to a Kubernetes cluster. One key aspect of Jenkins X is that the deployment of applications is implemented following the GitOps flow. In this approach every environment is represented by a Git repository. In this post we’ll see how Jenkins X environments work.

Environments

An installation of Jenkins X consists of:

A Development Environment which is a kubernetes namespace running tools like Jenkins, Nexus, etc. Each different team within an organization is meant to have its own development environment so that they can be as independent from each other as possible.
Other Permanent Environments which are kubernetes namespaces where our applications will be deployed into. By default Staging and Production are created. Each team can have as many Permanent Environments as they wish and call them whatever they like.
Optional Preview Environments, which are kubernetes namespaces where our applications will be deployed, just like Permanent Environments, but these are created on a PR basis, before you even merge your PR changes into master.

Under the covers this is implemented creating a custom Kubernetes resource jenkins.io/v1/Environment. Assuming that each team has a Kubernetes namespace assigned, each team will normally have a Development Environment and several different Permanent Environments. Each of these environments is represented by a jenkins.io/v1/Environment object on the namespace assigned to that team.

Teams are also represented by a jenkins.io/v1/Team object, but we will cover that on a different post.

These Environment objects contain configuration about which Git repository is associated with it, and which git branch to use.

There could be one namespace which is where all apps run across all teams - though from a kubernetes RBAC perspective, if you are working in microservices teams, it’s better for each team to manage their own microservices in their own production environment and use service linking between teams.

Development Environment

A jenkins.io/v1/Environment object created on the team’s namespace, which spec.Kind field is Dev. This environment is not linked to a Github repository, we will never promote changes here. It’s just a Kubernetes namespace used to run applications while developing, thanks to skaffold.

In the dev environment Jenkins X installs a number of core applications they believe are required at a minimum to start folks off with CI/CD on Kubernetes. They come with configuration that wires these services together meaning everything works together straight away.

Jenkins — provides both Continuous Integration and Continuous Delivery automation.
Nexus — acts as a dependency cache for applications to dramatically improve build times.
Docker registry — an in cluster Docker registry where the pipelines push application images.
Chartmuseum — a registry for publishing Helm charts.
Monocular — a UI used for discovering and running Helm charts.

Permanent Environments

These environments are where the applications will ran. By default Staging and Production are created, but more environments can be created. Staging has the Auto promote strategy and Production the Manual promote strategy. We’ll see what that means in a minute.

These environment are linked to

A GitHub repository containing a Helm chart that defines which application charts are to be installed on the environment, which versions of them and any environment specific configuration and additional resources (e.g. Secrets or operational applications like Prometheus etc).
A Kubernetes namespace where the Helm chart from the repository will be installed.

When you want to deploy to an environment, a Pull Request must be made to that environment’s repository. We can manually create the PR to deploy an application to an environment, or we can use this handy jx command

jx promote --app myapp --version 1.2.3 --env production

Typically we specify the environment while promoting to environments with the Manual promote strategy, like the Production environment. Instead of specifying the environment, we can create a Pull Request in all the environments having the Auto promote strategy using this jx command

jx promote -b --all-auto --timeout 1h --version \$(cat ../../VERSION) --no-wait

Changing the Production environment’s promote strategy from Manual to Auto you can do Continuous Deployment.

When these PRs are merged into the environment’s git repository, the environment pipeline runs, which then applies the Helm chart living on that repo to the environment’s Kubernetes namespace.

Preview Environments

Preview Environments are similar to Permanent Environments in that they are defined in a source code Git repository using Helm charts. The main difference is that Preview Environments are configured inside the application repository in the ./chart/preview folder. Also they are not permanent but created when a Pull Request is made to an application’s git repository, and then deleted some time after (manually or via automatic garbage collection).

When the Preview Environment is up and running Jenkins X will comment on your Pull Request with a link so in one click your team members can try out the preview.

You can create a preview environments using

jx preview

This will create the Environment and Namespace objects for this environment. It will also build the application creating a new Docker image that will be deployed to the preview environment using the preview chart defined in the ./chart/preview folder.

Managing environments

You can create new environments using jx

jx create env --name prod --label Production --namespace my-prod

Some interesting options are

label: The Environment label which is a descriptive string like Production or Staging.
prefix: Environment repo prefix, your Git repo will be of the form environment-$prefix-$envName.
promotion: The promotion strategy, Auto or Manual.

You can then list all existing environments

jx get environments

Or edit an existing environment (-b for no interactive)

jx edit env -b --name prod --label Production --no-gitops --namespace my-prod

Or finally delete it

jx delete environment prod

Deployment Flow

In the workflow that Jenkins X proposes, we will have a repository for each application that we want to deploy. But also we will have a repository for each environment where you want to deploy these applications. The repositories for the different environments describe all the applications that must be running on them.

So while developing your application, the usual flow would be

Create a Pull Request on the application repository: this will execute the application CI pipeline to build and test the application.
Once the Pull Request on the application repository is merged, the application pipeline will release this newly built version to a Docker Registry and promote it to the environments with the Auto promote strategy using a jx command.
If we want to deploy to production or any environment with the Manual promotion strategy, we need to execute the jx command targeting the desired environment.

Layered architecture and Kubernetes operators

Mon, 03 Dec 2018 23:47:55 +0000

If you’ve been developing applications for some time, you’ve probably developed some kind of HTTP application. This is the most solved problem there is in our industry, with lots of frameworks and tools that help you solve this problem easily. Also, there are some patterns and practices that we apply when solving this, that come from years of experience learning the pain points while developing these applications. I’m talking about things like not coupling your business rules to your framework, or using layers to separate things like data access objects from your domain model.

However, sometimes we forget that we can apply these patterns to almost any kind of software project. Lately I’ve been involved in projects that contain some Kubernetes Operators and the code in there could benefit a lot from the patterns that we already apply to our typical HTTP applications.

Don’t let your domain model depend on your framework

I created this Kubernetes controller some months ago. There are several different frameworks to help you create your own Kubernetes Operator/Controller, but in this particular case, I decided to try Kooper. If I search the keyword “kooper” in the codebase of my controller, there are only two matches: the dependency file declaring the dependency on the kooper library, and the main file that bootstraps the controller. All the other files (specially the pkt/service.go file containing all the business logic) don’t depend on the kooper framework at all. If I would switch to a different framework, I wouldn’t need to change pretty much anything, only the bootstrapping of the process that takes care of all the wiring. All the important bits, the business logic containing what my controller actually does, that wouldn’t need to be rewritten or even touched.

You are using a database, believe it or not

Kubernetes Operators and Controllers use the Kubernetes API to get the current state of the cluster, and store data on inside Kubernetes resources. This means that these processes are using etcd as a database, which we normally access through the Kubernetes API using the client-go library.

In other kind of applications, we have been creating specific objects that take care of accessing our data for years. We usually call these objects the data access layer, but somehow we don’t do it when accessing the data stored in Kubernetes objects. It’s pretty normal to find code like this all over a Kubernetes operator or controller

We are coupling our business logic to the client-go library that we use to talk to the Kubernetes API. This makes our Kubernetes operators and controllers hard to test, because when this code is executed, it will try to connect to a real Kubernetes cluster. The client-go library offers some tooling to help you create Fake API’s, but wouldn’t be better if we wouldn’t need to use that to test every part of our application?

By encapsulating the data access parts of your code on its own objects, you could write unit tests for the important bits of your application where the business logic is happening, easily stubbing the data access objects. We could use the Repository pattern for this. This is a repository to fetch ConfigMaps from the Kubernetes API. That’s the real implementation that my controller will use when it’s started. But this is the implementation that my controller will use when running the unit tests. This fake implementation won’t try to connect to a real Kubernetes cluster: it just stores the objects in memory, which is fine to run our tests.

We would still need to write some integration tests, to make sure that everything works well together. But all the complexity of testing your code depending on the client-go library, would only affect your repository objects.

Dependency injection

In order to achieve what we’ve been talking about on this post, it’s really important that we use dependency injection to pass the right objects to our methods. We need to be able to pass either the real data access objects or the stubbed ones.

Instead of instantiating the objects that your service depends on inside its own functions, declare those dependencies as parameters that need to be passed when creating the service. This way you can pass the right implementation that you need. On your unit tests, pass the stubbed implementation. On the real bootstrapping of your service, pass the real implementation that talks to the Kubernetes API, like this

This service doesn’t care if the client is the real one or the stubbed one.

Conclusion

At the end of the day, it’s just applying what we have already been applying to our applications for years. As Kubernetes controllers and operators get more complex, a better structure for our code is needed to keep the code maintainable.

I didn't know you could do that with a Dockerfile!

Tue, 30 Oct 2018 23:47:55 +0000

Docker released the multi-stage builds feature in the version 17.05. This allowed developers to build smaller Docker images by using a final stage containing the minimum required for the application to work. Even though this is being used more and more over time, there are still multi-stage patterns that are not that widely used.

In this post I’ll show you how to use multi-stage builds to:

avoid having different Dockerfiles for every environment
copy files from remote images
use parameters in the FROM image

Multi-stage builds allow us to use the FROM keyword in several places of the same Dockerfile. Every time we use the FROM keyword a new stage will be created. One important thing is that we can name these stages to refer to them later on in the Dockerfile.

You don’t need a Dockerfile for each environment

Imagine the following scenario: you need certain tools installed on the Docker image that you will use for development, but you don’t want those tools on the final image that will be deployed in production. For example, when developing in PHP it’s useful to have xdebug installed, but you normally don’t need it in production.

# Use this image as the base image for dev and prod.
FROM php:7.2-apache as common

# The pdo_mysql extension is required for both dev and prod.
RUN a2enmod rewrite; \
    chown -R www-data:www-data /var/www/html; \
    docker-php-ext-install pdo_mysql;

# Here we configure PHP, but this configuration will be overwritten for prod.
COPY php.ini /usr/local/etc/php/php.ini


# In this image we will download the dependencies, but without the development dependencies.
# The dependencies are installed in the vendor folder that will later be copied.
FROM composer as builder-dev

WORKDIR /app

# Copy only the files needed to download dependencies to avoid redownloading them when our code changes.
# This will download development/testing dependencies.
COPY composer.json composer.lock /app/
RUN composer install  \
    --ignore-platform-reqs \
    --no-ansi \
    --no-autoloader \
    --no-interaction \
    --no-scripts

# We need to copy our whole application so that we can generate the autoload file inside the vendor folder.
COPY . /app
RUN composer dump-autoload --optimize --classmap-authoritative


# This is the image using in development.
FROM common as dev

# We only install xdebug in development.
RUN pecl install xdebug-2.6.0; \
    docker-php-ext-enable xdebug

WORKDIR /var/www/html

# We enable the errors only in development.
ENV DISPLAY_ERRORS="On"

# Copy our application.
COPY . /var/www/html/
# Copy the downloaded dependencies from the previous stage.
COPY --from=builder-dev /app/vendor /var/www/html/vendor
# Setup PHP for development.
COPY php-dev.ini /usr/local/etc/php/php.ini
RUN composer dump-autoload --optimize --classmap-authoritative


# In this image we will download the dependencies, but without the development dependencies.
# The dependencies are installed in the vendor folder that will be copied later into the prod image.
FROM composer as builder-prod

WORKDIR /app

COPY composer.json composer.lock /app/
RUN composer install  \
    --ignore-platform-reqs \
    --no-ansi \
    --no-dev \
    --no-autoloader \
    --no-interaction \
    --no-scripts

# We need to copy our whole application so that we can generate the autoload file inside the vendor folder.
COPY . /app
RUN composer dump-autoload --optimize --no-dev --classmap-authoritative

# This is the image that will be deployed on production.
FROM common as prod

# Add label and exposed port for documentation.
LABEL maintainer="Jose Armesto <jose@armesto.net>"
EXPOSE 80

# No display errors to users in production.
ENV DISPLAY_ERRORS="Off"

# Copy our application
COPY . /var/www/html/
# Copy the downloaded dependencies from the builder-prod stage.
COPY --from=builder-prod /app/vendor /var/www/html/vendor

Building our application image

When building the Docker image now we can choose which stage to build. The stages that will be executed depend on which stage we choose to build and the order in which these stages are defined in the Dockerfile.

If we are developing and need our dev version of the application, we can build the Docker image like

$ docker build --tag "my-awesome-app" --target "dev" .

This will only execute the Dockerfile lines of the stage named dev, and the stages that appear right before it: common and builder-dev. If we would’ve placed the builder-prod stage before the definition of the dev stage (right after the builder-dev stage), the builder-prod stage lines would’ve got executed when building the dev stage, even though we don’t need them. So make sure to plan ahead and put the stages in the right order: every stage related to dev will be placed before any stage related to prod.

If we need the prod version that will be deployed in production, we can pass the prod target or just don’t pass any target at all

$ docker build --tag "my-awesome-app" .

This will execute all the instructions in the Dockerfile, because the prod stage is the last one to appear on the Dockerfile.

Can we improve the building speed for development?

It seems that building our docker image for development is kind of slow. Can we make it faster? Our approach is copying our application files several times from our laptop to the image layer, making the process slow. And it will be slower as our application grows.

We can merge the builder-dev and the dev stages into one big stage to reduce the number of times we copy our application. Let’s remove the builder-dev stage and change our dev stage to this

# In the development image we download dependencies and copy our code to the image.
FROM common as dev

# We only want xdebug in development.
# We need to install some tools required by Composer, which will run in this stage.
RUN apt-get update; apt-get install -y wget zip unzip git; \
    pecl install xdebug-2.6.0; \
    docker-php-ext-enable xdebug; \
    wget https://raw.githubusercontent.com/composer/getcomposer.org/1b137f8bf6db3e79a38a5bc45324414a6b1f9df2/web/installer -O - -q | php -- --install-dir=/usr/bin --filename=composer --quiet

WORKDIR /var/www/html

# Copy only the files needed to download dependencies to avoid redownloading them when our code changes
COPY composer.json composer.lock /var/www/html/
RUN composer install  \
    --ignore-platform-reqs \
    --no-ansi \
    --no-autoloader \
    --no-interaction \
    --no-scripts

# We enable the errors only in development
ENV DISPLAY_ERRORS="On"

# Copy our application. Now the dependencies are already there.
COPY . /var/www/html/
# Setup PHP for development.
COPY php-dev.ini /usr/local/etc/php/php.ini
RUN composer dump-autoload --optimize --classmap-authoritative

Our development image will contain Composer (and wget, zip…) too, but I think that’s not a big deal in this scenario.

Parametrized image tags

Did you know that you can use parameters for the base image to use when building your image? We can define a parameter that sets the PHP version to use

ARG PHP_VERSION=7.2

FROM php:${PHP_VERSION}-apache as common
# Here would go the rest of the Dockerfile
# ...

Then just pass the right PHP version to use when building the image. If we want to use PHP v7.1 instead

$ docker build --tag "my-awesome-app" --build-arg "PHP_VERSION=7.1" .

Combine targets with docker-compose

The reality is that many people use docker-compose while developing locally because it makes it really easy to start other containers along with your application, like a database that your application needs to store information. In this scenario you can tell docker-compose to build your image and which target to use.

version: '2.4'
services:
  web:
    build:
      context: .
      target: dev
      args:
        PHP_VERSION: ${PHP_VERSION}
    ports:
      - 8000:80
    volumes:
      - .:/var/www/html
    depends_on:
      - postgres
  postgres:
    image: postgres:11.0-alpine
    environment:
      POSTGRES_USER: dbuser
      POSTGRES_DB: my-db

You can now fire up your application and its dependencies as usual, but you can pass the desired PHP version as an environment variable

$ PHP_VERSION=7.1 docker-compose up --build

Copying from remote images

We have seen how to copy files from previously generated layers. But did you know that you can copy files from remote images?

For example, instead of installing Composer in our dev stage, we could just copy it from the official Composer image

# In the development image we download dependencies and copy our code to the image.
FROM common as dev

# We only want xdebug in development.
# We need to install some tools required by Composer, which will run in this stage.
RUN apt-get update; apt-get install -y zip unzip git; \
    pecl install xdebug-2.6.0; \
    docker-php-ext-enable xdebug;

# Copy composer binary from official Composer image.
COPY --from=composer /usr/bin/composer /usr/bin/composer

WORKDIR /var/www/html

# Copy only the files needed to download dependencies to avoid redownloading them when our code changes
COPY composer.json composer.lock /var/www/html/
RUN composer install  \
    --ignore-platform-reqs \
    --no-ansi \
    --no-autoloader \
    --no-interaction \
    --no-scripts

# We enable the errors only in development
ENV DISPLAY_ERRORS="On"

# Copy our application. Now the dependencies are already there.
COPY . /var/www/html/
# Setup PHP for development.
COPY php-dev.ini /usr/local/etc/php/php.ini
RUN composer dump-autoload --optimize --classmap-authoritative