Hacker News Reader

Comment by tyingq | Hacker News Reader

I can see a PHP centric shop not feeling all the upside of containers. The typical PHP model is pretty simplistic, so it's not hard to replicate most of the docker benefits without using containers at all.

That is, I can manage and deploy php apps with different php versions, database versions, repo versions, etc, without too much pain already. Because deploying a PHP app is mostly just dropping files into a directory and restarting a web server.

View on HN

And yet, when I criticized Docker in 2018, in an article much discussed here on Hacker News, many of the comments pointed out how much something like PHP would benefit.

raziel2p wrote:

"However, I think the author trivializes the amount of work required to make different types of Python/PHP/NodeJS/whatever apps all work in a consistent way through configuration management, saying "I can just write a bash script or makefile." or "just download roles from Ansible Galaxy". This is so painfully ignorant and irresponsible that I fail to take the article seriously as a whole."

From here:

https://news.ycombinator.com/item?id=17062288

If a person says that thing X is easy for them in their context, default to believing them.

If a person says that thing X is hard for them in their context, default to believing them.

There is no contradiction there.

This reads as: "believe whatever people say because we're afraid to contradict them."

If you find yourself assuming someone else is motivated by fear, first ask yourself if they might be motivated by truth-seeking.

I recommend applying Bayes Rule:

If someone says they were abducted by aliens, first think about how likely that is to have happened. Then account for the probability that someone who says that it happened is confused or lying about that situation. Then maybe ask a clarifying question.

If someone says they were frustrated and confused by python packaging, first think about how likely that is to have happened. Then account for the probability that someone who says that it happened is confused or lying about that situation. Then maybe ask a clarifying question.

——————————

Personally, I think it is much more common for people to be confused about configuring and packaging software than it is for people to be totally clear yet also confused about whether or not they are confused.

Sounds like I hit the nail on the head.

It sounds like there is a misunderstanding.

I can see both sides. If your PHP app depends on non-core modules, or resources that might clash with more than one instance running (apcu comes to mind, or redis), or a complex database layer, etc...maybe docker would help.

Quite correct, both sides are clearly visible and there might be some point to using containers anyway.

But there's a bigger issue here. The comments the OP received, are heavily worded to the point that they explicitly state that the article made them angry.

Regardless of whether containers are suitable or not for task X or Y, it is very difficult to have a normal conversation, if one's comments can actually make people angry.

It's almost as if tyingq and raziel2p are two different individuals with their own unique viewpoints and opinions... It's not a knock on you - it's just that I never understood comments like this.

We had some software break earlier this week because our Ansible role installs Python 3.8.10 as `python` but the system had 3.8.6 installed as `python3`. This meant that when we ran `/usr/bin/env python` it used the non-system python which wasn't picking up packages from /usr/lib/python3.8/dist-packages or wherever Ubuntu packages are installed.

The default `pip` and `pip3` commands, however, used the system python and did read those directories, meaning that it kept insisting the given package was installed. It was a frustrating amount of digging around that could have been avoided in myriad ways, one of which being containers (though for a 30-line python script, docker seems like overkill).

To avoid this problem I use virtualenv for each project _and_ I point to the pip binary inside that env (env/bin/pip or env/bin/python) in my ansible scripts or any other commands. I settled on this after running into similar problems

> different php versions

How do you do that one? Last time I tried (granted, a long time ago), apache-mod-php was hardcoded into a single php version, and you couldn't have different versions of it on apache either.

I always classified php as one of the most problematic languages that need containment. There's not only that hard dependency on the version, but the language also has a global configuration storage that, last time I used it, can not be overloaded.

There's a number of ways to deal with it now. Having different versions of php installed is the easy part, having the webserver send requests to these is a little more tricky. Using PHP-FPM makes this considerably easier as you can have different versions listening on different unix sockets, for example.

2 different running PHP-FPM instances. Then, any web server virtual host can choose which one to use. Via SetHandler for Apache.

You use PHP FPM (Fast CGI) behind Nginx, so you run multiple PHP-FPMs each with their own PHP version. This falls out of stock Debian/Ubuntu already and can be easily extended to even most recent and older PHP versions through PHP Debian Maintainer Ondrejs PPA. Currently PHP 7.0 - 7.4 and 8.0 available via apt-get

I seem to recall being able to do this with some effort in the old days. You might have to compile the mod_php's yourself though, looks like at least FreeBSD packages have different php versions conflict with each other.

If you use php_fpm as others suggest, it would likely be easier.

Either way, you need to have some way to indicate which version you want; it used to be common on shared hosting to have .php3 vs .php4 vs .php5 files to indicate which version you wanted; but I think modern PHP tends to have less code that doesn't work with newer versions.

I don't think many people who are using containers are using apache.

>> Because deploying a PHP app is mostly just dropping files into a directory and restarting a web server.

Lots of solutions can't "just restart a web server" as part of their deployment.

Lots of solutions don't want to - that's fairly different than "can't". I dare say few companies need nigh-100% uptime, and it costs an incredible amount both in setup and in maintenance to go from "10s outage while updating" to "no downtime while updating".

What exactly do you mean? How do these solutions deal with servers unexpectedly going down? I worked on telecom where you need the service to be up 24/7 and we restarted all the services on deployment. In waves of course.

Alternatively you can change the symlink to your www directory to the new one.

What do you think the net effect of deploying a new container image is? At some point the server goes down and a new copy is loaded.

You could always disable opcaching and then you wouldn't even have to restart the server to deploy a new PHP instance.

Depends on how you set it up, but with a lot of container orchestration these days, you create a new image then point your load balancer at that instead, giving you a clean blue/green deploy without downtime.

Yes, I didn't claim it as an absolute. Lots of solutions can restart a web server or a PHP-fpm instance without trouble. Or use things other than containers to manage zero downtime.

You can always spin a new one and have the load balancer redirect requests.

With most PHP setups, you can usually skip the restart part.

Although if you have multiple projects using the same framework and libraries on the same server, using containers allows you to use opcache preloading.

Reply on news.ycombinator.com