Docker image build for use with Laravel 5.x, including deployer.
Based on work from Ian Olson, specifically https://gist.github.com/iolson/791fb1c1d1a8cfb5ffa7 and https://gist.github.com/iolson/5e3695bc5c9f7afafeb3 as well as The Laravel 5.1 Starter.
As a general rule, to speed up GitLab CI builds it is better to bake in any apt-get or composer package, within reason. The largest bottleneck is the network latency of working with the various package managers on the Digital Ocean network.
Configuring a dedicated droplet showed identical build times that I initially thought may have been attributed to load but that doesn't appear to be the case. Even with caching both apt-get and eventually composer and vendor directories, builds were still comparable.
As of 10/5/2016, this image was largely in a private registry which meant it could only be ran via a dedicated runner. Shared runners don't have the capability to expose the "docker login" requisite yet, but it is coming. The hope in making this public is the shared runners can benefit from a relatively streamlined and custom image for our needs.
There are more feature-rich Laravel docker images like https://hub.docker.com/r/bobey/docker-gitlab-ci-runner-php5.6/ if this isn't suitable for your needs.
To support a new version of PHP:
7.3
.Dockerfile
, essentially cp 7.2/Dockerfile 7.3
.FROM php:7.2-fpm
to FROM php:7.3-fpm
.
docker build ./7.3 -t w0rddriven/docker-laravel-deployer:7.3
.php:7.3-fpm
you should inspect the list of supported tags to see what that image is built from.libzip
is no longer included so it needs to be added explicitly.
docker rmi w0rddriven/docker-laravel-deployer:7.3
.docker image prune --all
.docker push w0rddriven/docker-laravel-deployer:8.1
Due to what looks like breaking changes with bookworm
based images, which affect PHP 8.1 and 8.2 so far, we've explicitly referenced the bullseye
base via FROM php:8.2-fpm-bullseye
.
There may be a trick to get this working or PHP upstream has to correct something but considering this affects Python, another dynamic interpreted language something tells me that may not happen unless bookworm
itself handles it.
See https://forum.gitlab.com/t/jobs-fails-shell-not-found-version-python/88340 for details.
While I was on an older version of the Gitlab runner i.e. Unpacking gitlab-runner (16.3.1) over (15.9.1) ...
, upgrading this didn't help.
I will try again moving the runner itself to a newer Ubuntu version because the VM needs a refresh but I don't expect anything new.
doctrine/dbal
needing composer-runtime-api ^2
and not surprising given something like this.1. [Docker in Development](https://serversforhackers.com/s/docker-in-development)
2. Docker
1. [Docker Hub for official PHP image](https://hub.docker.com/_/php).
2. [Github repository for official PHP image](https://github.com/docker-library/php).