I‘m excited by Fly — it looks well-designed and well-executed, and I want to jump in with both feet.
My current use case is a (decidedly non-esoteric) LAMP stack:
I don’t really care what Linux, but fairly stable and very current is good
Apache/httpd alone or (better) combined with Nginx
MariaDB 10.7.3 (current stable)
PHP 8.1.5 (current stable)
for running an efficient CMS/Framework called ProcessWire to host a mid-sized site. My site’s audience is global, with about 10K unique visitors per day, evenly split three ways between North America, Europe and the U.K., and the rest of the world. I love the idea of server instances following daylight around the Earth…
I’m reasonably facile with all the pieces of the LAMP stack, though I’m better on the application end than the system end. I’ve built out the site, and have both a development instance hosted on a VM in New Jersey and a production instance hosted on another VM in Amsterdam.
However, I have no experience with Docker or with CNB or Paketo Buildpacks; I’m usually a pretty quick study, but after bumbling around with them for the past two days, I fear the total learning curve may prove too steep.
Is a one-click LAMP stack being developed? If not, could someone advise me as to whether Docker or Paketo would make more sense for me to focus on? Do I need separate containers/packs for Linux, httpd, MariaDB, PHP, and for ProcessWire? Or can I simply find a LAMP Docker container and somehow add ProcessWire and all my PHP code to it? Or…?
I’m grateful for any guidance anyone here can give!
I discovered Fly, btw, through Tailscale, which advertises its compatibility with Fly. I’m excited by the prospect of my Fly servers being “local” on my Tailscale network!
I don’t know of a one-click LAMP stack. You have two options really: either multiple apps (likely one app for Apache/Nginx+PHP which would run the code, and another app for the database) or run one app using a multi-process approach. Both have advantages and disadvantages. Fly have some thoughts about multi-process which is quite helpful: Running Multiple Processes Inside A Fly.io App
Personally I would favour making multiple apps. Easier to monitor, scale. And you could then take advantage of multi-regions, which you mention (following daylight!). Like, you could make two app VMs (say, in NA and EU). And one database vm. And they can talk over Fly’s encrypted private network (Private Networking).
You could even go one step further: I assume your CMS will generally be doing reads and so you could create a read replica database app (Multi-region PostgreSQL). Maybe one database app in EU, and then a read replica database app in NA. For super-fast reads in both EU and NA Though Fly only provides PostgreSQL as a service. And you say MariaDB. So you would have to make your own variant of that approach, if you wanted to delve into that. Depending on the complexity vs performance trade-off.
The biggest hangup here is going to be MySQL. Postgres on Fly.io is easy, MySQL on Fly.io is pretty much do-it-yourself. You can use PlanetScale but they don’t have easy multiregion.
Apps that need databases tend to not follow the sun very well. The best deployments are 3-6 regions that get instances close to the bulk of your users, each with a database read replica. We make global postgres + read replicas reasonably manageable for full stack apps.
Running a few regions full time works well because we route traffic to the nearest app instance with available capacity. So if you’re running in Amsterdam, and another app in London, requests from London might be routed to Amsterdam if the London instance is full. This adds ~50ms of latency, which isn’t noticeable to most users.
I would figure out how to handle the database then build a Docker image with PHP + nginx, like this one: Docker Hub
Thank you for your responses, @greg and @kurt . I’ll mull them over overnight, and investigate some tomorrow.
I should have said that the db (honestly, I‘d prefer PostgreSQL, but I’m committed to ProcessWire at this point, and it doesn’t support it) could be either MySQL or MariaDB; I’d prefer the latter, but it doesn’t really matter. I gather the problems would be the same with either one.
However, in “Production,” the only writing done to the db in production is some session data, and I believe I have the option of writing that out directly to the file system rather than to the db. In other words, though I need regularly to add data to the db, it’s only my own process that needs to do so. In fact, if I change how the session data is stored, we can think of the database exactly as we think of interpreted PHP scripts.
Would I be right in thinking that simplifies things somewhat?
Well, not needing a database at all would greatly simplify things so if you can use a file system, perfect. However I’m guessing (being a CMS) that your data is being read from a database and so one would need to be there for the site to work.
You are right - I haven’t used ProcessWire and it seems it’s tied into MySQL/MariaDB. The code looks for specific MySQL-ish stuff. So alas Fly’s Postgres magic won’t work for you with that particular CMS. As @kurt says, it would need a DIY install of either MySQL or MariaDB on a Fly app in order to make a database compatible with it. So for example you could make a database VM which just has MySQL installed. And then have an app VM with Apache+PHP (+code) on. And then as long as both apps are in the same Fly organization, the app VM should be able to connect to the database VM using Fly’s network e.g app-name.internal:3306.
You also mentioned the version of Linux. Well the neat thing with using a Dockerfile is you can put whatever you want in it and Fly runs it. Kurt put an example using a base of Alpine Linux which is great for something like Fly as it is tiny. But you can use any Linux: Ubuntu etc, if you want more and are less concerned about size. The Dockerfile is simply a list of instructions the Fly system should do to “make” an image, like what to install to make it work. PHP apps are made a bit more complicated than e.g Nodejs or Go in that they don’t have their own web server. And hence you need Apache/Nginx in front. But it looks like that image from Kurt already has that. So it would be a case of writing a Dockerfile using that as a base and that copied your code in.
One final thing to consider is that it again it appears (not sure) that ProcessWire stores conf data in a file. If so, you’d need that to either be part of the image or use a volume attached to the app (Volumes). A volume being like an AWS EBS - a separate store to the temporary storage the app has. Else if the app is restarted, it would lose the configuration data. You would want that to persist if it holds e.g database connection details. I don’t know enough about ProcessWire to advise as other CMS I have used use ENV values (e.g like DB_HOSTNAME) and those variables are handled by Fly’s system without needing a volume.
I’ll follow @kurt’s links in the morning — it’s great to see that there’s already a Docker container I might use as a base.
I see how what I added about the db might have been misleading: there’s lots of CMS information in the database, and there’s no way I’d be able to do without it or use a non-MySQL/MariaDB db… I just thought it might simplify the the picture if I took advantage of ProcessWire’s ability to put session info in the file system so that no writing would need to occur — so no real-time sync issues to think about…
Though Fly only provides PostgreSQL as a service. And you say MariaDB. So you would have to make your own variant of that approach, if you wanted to delve into that. Depending on the complexity vs performance trade-off.