PHP 7.2 Release Manager: Start planning to upgrade from 7.2 NOW!
Posted Aug 31, 2019, 11:13 AM UTC
6723
Since we use docker in prod and write tests, this took a whole 5 mins back when we did it. I can't stress the value of containers enough
6
What's your deployment pipeline? Do you use Azure or AWS?
2
Gitlab/gitlab-ci in digital ocean nodes using Rancher for container orchestration
2
Thanks. I'm testing docker and K8s on Azure as I'd like to introduce this workflow in the company I work for. The initial setup is bit cumbersome, dockerfile, yaml config for kubernetes but I can see that it will pay off in the long run. Any tips for someone who is pretty green with this concept? Can you recommend any tools that make your life easier when working with containers?
1
I cannot stress enough how useful https://rancher.com has been. It's an enterprise grade open source administration tool for K8s clusters. It really helped me visualize and learn to manage containers in production and I think reduces the fear associated with such tooling because you don't have be a CLI master to use it. You can use it to setup your initial cluster or add your existing cluster to it and it can be decoupled at any time with zero impact to your cluster since it only taps into K8s events under the covers and uses the k8s CLI itself.
It adds an easy to use interface, visuals, monitoring, notifications, user permissions, clean k8s catalog management (as well as personal helm catalogs), etc. It's a must-have IMO for any environment where folks other than CLI gurus might be interacting with it.
1
How big is the project?
1
It's been in progress over 2-3 years, a side project, but is quite busy
1
Mind if I ask how you're dealing with logging?
Sending the logs to stdout/stderr is a bit inflexible on what you can log (I like to be able to log json request/response object for example), and you lose the log levels.
At the moment I'm using a volume and sidecar container to send the logs to Stackdriver.
Google just say use their logging lib but that added about 2 seconds to response times (thanks google).
1
You can log to a file, then use supervisord to tail the output of that file to STDOUT/STDERR. This sidesteps the issue of the max log length being 1024 bytes in PHP FPM
1
I actually don't have a need to keep any logs for the application. We use Bugsnag for exception handling so when any exceptions occur we have all the context we need to debug.
If I did need to solve for logs, I'd go with something hosted like SumoLogic.
1
Ahh dang time to upgrade my 7.0 instance.
4
7.0 was EOL before 5.6
10
Which is why I need to get to work!
7
In practice, I'm locked to whatever is currently available on Debian Stable. Up until this summer, that meant still running 7.0. It now means 7.3 for the next two years. Thankfully, in the worst case --like what happened with Debian 9 being stuck with 7.0-- the old version is still supported by the distro security team and doesn't get too far EOL before the next Stable.
3
There's a Debian dev who packages newer PHP releases for Debian stable and older releases, if you're interested. I use his repo on my server.
2
Nice. Thanks for the tip. By the time Buster released, I was going slightly mad waiting for something newer than 7.0, as being stuck on 7.0 had started to mean being stuck on various out of date versions of libraries, etc.
1
[deleted]
1
[deleted]
1
I don't get people who say they'll stay with the default version shipped with their OS. You're missing out on so much cool new stuff, isn't that worth a few hours to you?
1
As long as Ubuntu 18.04 is the current LTS, 7.2 isn't going anywhere.
You know it and I know it.
Just to manage your expectations, Ubuntu might not backport down security fixes from php 7.3+ to bionic or xenial, or not all of them.
Upgrading from 7.0 to 7.4 should be absolutely trivial from a code standpoint. I realise actual servers with php installed instead of docker containers might however be problematic. Ondrej's PPA however is safe to use (he's the debian php packager).
on the contrary, they doing it since forever.
[deleted]
That's the unfortunate truth... we are effectively much more constrained by officially supported php versions in current (lts) distributions than anything else. This is ironically even more the case with conservative, "security minded" organisations which are hesitant to use anything else but official repositories.
[deleted]
I think he's implying that they are sabotaging their own objectives. They are security minded so they won't use 3rd party repos and instead rely on the official dist packages. However these may not be updated with every security update because the software is EOL so the package maintainer has to backport security patches from supported versions, but it's no guarantee that every patch will get backported. If the company used those "untrustworthy" 3rd party repos in the first place, they could stay up to date on the latest releases.
They wont upgrade their codebase to p++ and want that long support. Not everyone makes simple blog apps with php.
You do know about ondrej/php, right?
Not everyone is at liberty to install anything they want on prod servers, unfortunately.
Absolutely, but he was ranting about how the official Ubuntu repo in lts would not support the new versions.
7.2 will still have security fixes through the end of 2020. As long as it takes you less than six months to hop LTS releases you'll be fine.