2 votes

Server admins, PHP/Symfony experts: I need your guidance

Posted by TheFireTheft
Tags: php, symfony, sysadmin, cloud, mysql, ask.advice

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.

3 comments

  1. bme
    Link
    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: The...

    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:

    1. The service should be hosted in a managed instance group (assuming you stay on Google cloud), and once the server is configured on boot it never changes again. If you need to change you update the launch template and spin up a new server and delete the old.
    2. Health checks hooked into the load balancer, s.t. the lb can automatically replace an unhealthy instance and ensure that during a rolling server replacement you don't kill the old server before the new one is healthy, and unhealthy instances aren't exposed to end user requests.

    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.

    2 votes
  2. dedime
    Link
    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...

    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.

    1. Don't change anything about the server yet. It's working, just let it chug along (for now)
    2. Get the app fully working in a Docker environment. Up to date Linux host machine. docker compose to bring up services (PHP, symphony, MySQL).
      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).
    3. Once it's working 1-to-1, or a close approximation to it, schedule some downtime and do the switchover. It'll involve changing DNS records and maybe some database migrations for complex stuff.

    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.

    2 votes
  3. overbyte
    (edited )
    Link
    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...

    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.