Opinion on Phusion Baseimage?

[Chris Fidao]

I've used Phusion's base image a few times when building Docker containers. This let's me do a few things:

• group some logical things together in one container, such as Ning and PHP-FPM. 
• allows you to SSH into a container
  
• Claims to fix the "init" process, "apt" issues and other issues when running Ubuntu within a container
• Enables syslog, logrotate and cron to be used/run

I'm wondering if a lot of you using this? Are there cons to Phusion? 

There's definitely disagreement on if this is how Docker is "meant" to be used. I'd be interested to hear how people manage log management and other "issues" in using the Ubuntu base image without the tooling provided by Phusion. 

Is there a consensus on if Phusion is a good (better) base image to use for running web applications?

Thanks

[br...@brianclements.net]

Hi Chris,
I've actually had a pretty in-depth conversation about some of the pros/cons and details of using the Phusion images. You can check out the full conversation here. But in short, my personal opinion is that I feel they are trying to hack docker containers into being full-fledged, long running virtual environments instead of being more of an application wrapper. And adding all that complexity into a container I feel is missing the point of the container, or at least, I feel isn't necessary given other methods that accomplish the same things with less custom scripts and methods. In my images, I've chosen Supervisor as the one program to solve all the issues that the Phusion image solves with custom scripts and at least 3 different programs. Having an easy way to manage configuration was important to me, thus I favor less complexity in this case. I outline my strategies in my responses and you can browse the sources for my images too, but some great alternates are also outlined in Scott Liken's responses in that discussion.

Hope this helps,

Brian

- show quoted text -

[Jérôme Petazzoni]

Hi Chris!

The Phusion base images are a really great thing when you are moving from a old-school, server-oriented workflow, to a modern, service-oriented architecture.

They are a nice gateway drug to use containers without changing all your tools and habits.

However, they also prevent you from unlocking many cool features of containers. And this is a direct result of their very concept — which is to try to make a container look like a small VPS.

• group some logical things together in one container, such as Ning and PHP-FPM. 

Note that there is nothing wrong with grouping tightly coupled elements. I would probably not separate Nginx and FPM, except in some very specific scenario.

We often say "one process per container!" but what we really mean is "one service". If your service includes multiple processes, then fine.

A good way to answer the question "can I put those things together in the same container?" is to ask another question, which is "does it make sense to scale those things separately?" If you need to scale something, it certainly belongs to its own container. 

But then again, this is not a hard golden rule. Just best practice. Sometimes we have to bend the best practice a bit, and that's okay.

 

• allows you to SSH into a container

Allowing SSH in a container is convenient, but it makes me feel very uncomfortable, for many reasons.

1. If you SSH into a container, you will be tempted to tweak some things, and boom, you lose repeat-ability. Do you need to make change? Don't SSH! Author a new container image. This was hard and painful with VM images, but it became trivial with Docker images.

2. SSH daemon is expensive. If you want to run 10s, 100s, 1000s of containers, running SSH in all of them is a big waste of resources.

3. SSH is a security problem. If you run a SSH daemon in each container, that's one extra service to worry about. SSH vulnerability? Great, now you have to upgrade all your containers.

4. Putting SSH in containers breaks "separation of concerns". Wouldn't it be better if you could say "this is a container with a web service", and then "this is a container with a SSH service", and the latter can help you to get into the former? Now if you decide to upgrade SSH, or to remove it, or whatever -- you don't have to touch everything else.

5. "But, SSH is really helpful for troubleshooting, debug, etc!" Sure. But it's not the only tool out there to get into a container. Just look at nsenter, for instance. At least it doesn't require to change your containers. 

• Claims to fix the "init" process, "apt" issues and other issues when running Ubuntu within a container
  

Nothing is broken, there is nothing to fix, move along! :-)

The "broken init" is easily fixed by learning a few tricks, like the CMD [] syntax.

• Enables syslog, logrotate and cron to be used/run

Just copy-paste everything I told about SSH :-)

There are very good ways to keep those in separate containers, and have clean separation of concerns.

To wrap things up: phusion base images are neat, but they will eventually get in your way, "I guarantee it", as the meme says :-)

HTH,

--

@jpetazzo

Latest blog post: http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

[Aidan Hobson Sayers]

The Phusion base images are a really great thing when you are moving from a old-school, server-oriented workflow, to a modern, service-oriented architecture.

They are a nice gateway drug to use containers without changing all your tools and habits.

 

I think the general thrust of the above is worth emphasising. If you want fast, easily rebuildable VM-like development environments then docker/phusion may well be the way to go. I personally find docker nicer to work with than a full-on VM.

To wrap things up: phusion base images are neat, but they will eventually get in your way, "I guarantee it", as the meme says :-)

"they will eventually get in your way"...for doing things the 'true' docker way.

The problem I have with the quote immediately above (and "gateway drug" from the one above that) is that it assumes quite a lot about your situation.

I really like the docker ideal of a container being a little like a static binary, where everything required is contained in the executable and you have to explicitly define communication channels between different applications. It's very neat.

But in an environment where the 'server-oriented workflow' is the way (and has been for over a decade), converting to a service-based is a big shift. It would take a long time. And sometimes you just can't containerise all the way, because replacing raw disk access (for performance) with a data container won't fly with the Serious People who you hold an enterprise support contract with for that technology.

Sometimes people don't have the resources to embrace the entire philosophy (and possibly won't ever), they just want a nice wrapper around LXCs to make some VM-like dev and test environments. I know docker wasn't intended for this and I wouldn't want the 'philosophy push' to change, but it's nice to be aware that one size does not fit all, no matter how compelling a vision is.

Sorry for going off-topic.

Aidan

[Chris Fidao]

Everyone's point of view/comments so far as been invaluable, thanks!