From 5a498c85dbfbb7ccbff49434215c309ada0fa84d Mon Sep 17 00:00:00 2001 From: Renato Mefi Date: Thu, 13 Sep 2018 13:24:36 +0200 Subject: [PATCH 1/2] Document project's motivation --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 4c0a6a8..c2f19dd 100644 --- a/README.md +++ b/README.md @@ -4,12 +4,24 @@ With the ascension of containerized applications it becomes more and more useful This POSIX compliant sh script gets php-fpm status page using `cgi-fcgi` tool, parses it's outcome and allows you to choose a metric which you want to check one, a ping mode is also available which only makes sure php-fpm is answering. +- [Motivation](#motivation) - [Installation](#installation) - [Usage](#usage) - [Kubernetes example](#kubernetes-example) - [Why POSIX sh?](#why-posix-sh) - [Author and License](#author) +## Motivation + +Previously at work we had Docker containers containing both `php-fpm` and `Nginx` processes, while they were managed by another process being [Supervisord](http://supervisord.org/) or [s6 overlay](https://github.com/just-containers/s6-overlay) for instance. +One good example is [this image from Ric Harvey](https://gitlab.com/ric_harvey/nginx-php-fpm) + +It works really well, but I wanted to achieve a few other things like using the official images and its release cycle, logs belonging to their own processes, not mixed, I didn't like to rely on Supervisord since I had bad experiences in the past with it, and other things related to the ["Docker way"](https://docs.docker.com/v17.09/engine/userguide/eng-image/dockerfile_best-practices/), I'm not saying it's perfect but I wanted some of those things. + +Now comes the `php-fpm` healthcheck part, while having in place a healthcheck which requested an url in the application asking if it was alive, it was indirectly testing the whole chain, `Nginx -> php-fpm -> application`, and now I had the chance to test still the whole chain via nginx but also monitor how busy and stable is `php-fpm`, if you [check its `/status` page](https://brandonwamboldt.ca/understanding-the-php-fpm-status-page-1603/) it has quite some useful information, so why not monitor on it? For instance you could make a container unhealthy after a certain amount of requests, or if the queue is too long and even slow requests, and that's what this script tries to achieve! + +Good news is that you can still do it even using the mixed container approach, but I wanted to take a time to explain why I came to do it like this now! The advantage in my opinion is that having separate containers you have a better grasp on where the problem is laying and you can restart only what's failing, not the whole, also avoiding Supervisord to restart it for you since you are already behind a container orchestration tool. + ## Installation ### Enable php-fpm status page From 12db04b96a042f6815d4936e8853582b5fbab480 Mon Sep 17 00:00:00 2001 From: Renato Mefi Date: Thu, 13 Sep 2018 13:32:14 +0200 Subject: [PATCH 2/2] Force removal of container after tests --- test/docker.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/docker.sh b/test/docker.sh index c53d456..e9360f9 100755 --- a/test/docker.sh +++ b/test/docker.sh @@ -10,7 +10,7 @@ set -eEuo pipefail function cleanup { docker stop "$CONTAINER" 1> /dev/null echo "container $CONTAINER: stopped" - docker rmi "$DOCKER_TAG_TEMPORARY" + docker rmi -f "$DOCKER_TAG_TEMPORARY" } trap cleanup EXIT