Server admins, PHP/Symfony experts: I need your guidance
I've been the sole developer for my company's website for over a decade now. It's gone through a bunch of evolutions throughout the years, but I've been sidetracked lately and have let things stagnate as far as maintenance goes. Now, I'm looking to do some upgrades for security purposes and I'm trying to wrap my head around everything.
Some facts:
- PHP 8.0.12
- MySQL 5.7
- Symfony 5.4
- Web server is currently Apache only because that's what I've always used. I'm open to nginx or other options.
- Running on a Google Cloud VPS with Ubuntu 20.04
- I also use Google Cloud Storage to host thousands of images
My first thought was to take baby steps and start by upgrading Symfony as much as possible. However, the next major version (6.0) requires PHP 8.0.2. Symfony 6.1 requires PHP 8.1. Symfony 7.2 (the current release) requires PHP 8.2. So, then it just makes sense to upgrade PHP to the latest version.
However, I am terrified of upgrading PHP in the current (outdated) Ubuntu environment. So I might as well upgrade the distro while I'm at it.
And then, MySQL 5.7 is no longer supported, so I might as well bring that up to date too (8.0, I believe).
There will be no baby steps. I'm gonna have to just upgrade everything all at once. Which then leads me to my next question: should I stick with the self-managed VPS, or is it time to look at something like Google App Engine or Fly.io that is a little bit more managed and "locked down" than what I'm doing right now? Should I look into just going with Docker instead?
Put another way, if I'm going to start from ~scratch, what's the modern best practice to host all of this, given that I'm going to have to upgrade a bunch of different things all at once? (Turns out the "baby step" of upgrading Symfony will actually have to come last since I need to hit these prerequisites first).
Please let me know if I've left anything out. PS, security is a pretty big concern for us because we manage user auth, so I'm all for anything the cloud providers can do to take some of that responsibility away from me.
DevOps engineer here, The way I'd personally do it (without additional context here) is to shove all that into containers. Dockerizing is the first step to running things in a modern way, from there you can go to other cloud native solutions if you want.
Since the main website is still chugging along, you can experiment here. What happens if you update to the latest versions of PHP / MySQL? Maybe you try using cloud hosted MySQL (a good option)? What if you try Nginx instead of apache (my preference, but it might make sense to use what you're used to).
Disclaimer: I don't know your environment, I don't know your usage / size / budget constraints, I don't know what tech you're familiar with. This doesn't account for continued development of the site. This is just how I'd go about it personally with the limited info I have.
the above is the solution to this; docker has a bit of a steep curve to get started on and get your head around but it will allow you to permanently decouple the OS version from the application version(s).
I've got Ubuntu VMs running containers with a mix of Ubuntu/CentOS/Alpine/Debian/other OS based containers and never have to worry about finding packages for the base VM that docker is running on.
If you are likely to be sticking with a single VM for running the application in production then is it totally acceptable to use a docker compose setup with host mode networking to keep everything as simple as possible. For a basic symfony application you may end up with as little as three containers, one for the PHP application, one for nginx/apache and one for MySQL, likely building the PHP one and official container images unchanged for the others.
Once you have the application running as a docker container it becomes, relatively, easy to change how is it hosted and make moving onto fancy modern things like kubernates, container engine, etc as far smaller jump.
I think the only "one true" principle that everyone should do when modernising is making sure that your VM can die and nothing bad happens. Typically the best way to get there is at a minimum:
If you have these two things in play it doesn't matter if it's docker, k8s, ECS, nomad or whatever flavour of the month cluster tool you'll have a nice service that is a pleasure to change.
First off, check if you have a recent snapshot and database backup. That will help you safely try out things so you can go back to the current state. If the database is on the same VM hosting the web server, I'd split that off first.
For something in between a traditional VM and Kubernetes, don't bother with installing an OS then Docker on the VM, just provide a container image directly to Compute Engine and it will handle all the setup for you with it running COS instead of a regular Linux distro. Once you get that working you can move on to a managed instance group to give some autoscaling.
Personally I'd run a setup like this on GKE and the DB in CloudSQL (if you haven't moved it there already), but we host a heap of things more than a site and I'm familiar with GKE already.
As a reference, we're fully containerized and have Github Actions workflows build and push an image into Artifact Registry, our manifests are configured to pull images from GAR and the applications on the cluster use a CloudSQL Proxy sidecar to connect to their designated databases so we don't have to stick TLS certificates to pods or anything.
What sort of cloud provider constraints does your organization have? Are they wanting to remain flexible or would they be fine with vendor lockin in exchange for managed features? As a concrete example, you mentioned auth and I'm curious if organization would be interested in using entirely managed solutions such as AWS Cognito.
Admittedly most of my experience is in AWS, but presumably the main cloud providers offer relatively equivalent things for the use cases that would be of value to you. I think there's already other good advice in other directions, but my background is pretty heavy in leveraging managed services. So if you have more information to provide on that front I could potentially tell you what I'd do if my goal was an upgrade+managed migration.
Also, does your stack support parallel deployments? Blue-green? Slow rollout?