Starting up your docker php microservices

Final tests prior to deployment are a good time to blog.

You may not expect that much to go wrong during the hour-long build, but if it does, you still want to pay attention, as to fix issues, and then resume from there, or start the build process again.

When you build your php server platform in terms of docker microservices, you will find that php adapts itself surprisingly well to a microservice architecture. Php really hits the ground running.

Only linux supports the control group primitive mechanism needed for this, the kernel logic for which was originally contributed by the Google Infrastructure Group.

Microservices are now emerging as the winning successor to existing server-side approaches. A “No microservices” architecture is increasingly acquiring the meaning of “questionable, outdated, and insecure server architecture”. Google is certainly right in that respect.

In theory, the idea is to run just one service process inside a container, aka linux control group, but in practice things vary. Therefore, you may at some point have to deal with the equivalent of systemd for your container service script initialization.

In the face of fiery and vocal opposition — “the sky is falling” — debian migrated in its latest version (version 8) from traditional system-v to systemd. I never gave it a second thought, because systemd actually has acceptable support for traditional system-v init scripts too. Therefore, I did not really have to migrate anything at all.

However, now we also have the core docker team up in arms against systemd, suggesting that the thing will never work properly inside a control group container.

All attempts at rescuing systemd, and make it adapt to the new situation have failed, and have certainly wasted precious time in the docker team. Jessie Frazelle even wore a badge during the dockercon conference in November, in Barcelona last year, saying: “I say no to systemd specific pull requests”:

 

devconf-badge-sm.png

 

My own solution is to circumvent the problem, and let whatever subsystem that manages the startup process, start supervisord, which in turn will start my own service initialization scripts.

Supervisord does pretty much the same as systemd in this context, without causing angry mobs to draw their daggers and start clamouring for Louis XVI’s head to roll from the guillotine.

Therefore supervisord is mostly just a way of keeping my own server applications safe and out of the ongoing “system init” skirmishes!

 

Advertisements

Published by

eriksank

I mostly work on an alternative bitcoin marketplace -and exchange applications. I am sometimes available for new commercial projects but rather unlikely right now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s