A very good (insert time in your timezone here) to you all!
My name is Skipper (Dai), and I was a long time FarmOS user for a site I managed in the UK for a number of years. Life happened and I moved away, got another job etc. But I’ve recently bought my own small holding in Wales (7.5 acres), and am keen to get back into FarmOS.
FarmOS is now at 3.x which is ace! I’ll have to look into deploying that on my linux machine. How well does it play with other sites hosted on Apache?
Assuming you mean bare Apache installed via your system’s package manager…
It should work as well as any other Drupal installation so you can check out the official farmOS and Drupal documentation for that. There’s also a lot of tutorials around… e.g. How to Setup Drupal with Apache Virtual Host | Step-by-Step Guide – PTI WebTech (not specifically recommending this one, just an example)
In terms of more specific farmOS stuff, check out how Apache is configured in the official Drupal, farmOS, and PHP Docker images - even if you don’t plan on using Docker yourself.
All that said, I’d strongly recommend hosting farmOS in Docker and using a reverse proxy like NGINX for routing traffic to farmOS and your other sites. This allows you to maintain the versions of PHP/Apache/etc independently and should make upgrades much easier.
Welcome back @Skipper!! 
I would echo everything @Symbioquine suggested, especially the final recommendation to use Docker if you are able. This is nice because each “app” or website can potentially run their own versions of Apache/PHP/etc in their respective containers, so things are more separated and easier to manage/upgrade individually down the line.
Either way, farmOS should play just fine with other sites hosted on Apache. It’s just a matter of setting things up so that requests go to the correct place.
I believe you could even use Apache as your reverse proxy if you wanted to keep everything else the same.
I gave it a quick spin up in Docker, and it worked pretty well out the bag, so I’ll definately try the Apache reverse proxy approach, it can just slot in then.
Does the docker image have a database included? Or does it still need a separate db? (I’ve not used docker much, can it access a db on the server on the local machine, outside of the container? or does the port have to be passed through or something)
Also - modules - I see it maps the “sites” folder to a location on the drive, can I also map other folders, like the contrib modules? As I’ll probably want to develop some modules again
Great!
The Docker image is only Apache + PHP + farmOS (the “web server”). You need to provide your own database server. PostgreSQL is recommended (we finally did it! 
) but MySQL/MariaDB and SQLite3 are also supported (although long term SQLite3 support might be in question).
You can run a PostgreSQL container alongside the farmOS container if you want, or install it directly on your server. Either way, you’ll just plug in the db credentials when you are installing farmOS. If you set up a local development environment using the official guide, you’ll see how it should work.
If you are going to be adding/creating modules, I would highly recommend adopting a Composer-based workflow right from the start. Composer is PHP’s de-facto dependency manager. We added an official guide for using Composer to build your farmOS codebase recently:
Composer is basically just responsible for building the codebase. Then that codebase can be wrapped in a Docker container. That’s basically what the “stock” farmOS Docker image provides. You can can either use the stock image, and just mount the entire codebase in as a volume (and use Composer to update dependencies over time), or you can create a child image that builds your custom codebase inside your own Docker image that inherits from the stock one.
We will most likely be making the Composer-based workflow the recommended method for managing add-on modules in the next major version of farmOS, so better to get on that bandwagon from the start!
I’ve tried to use reverse proxy in Apache to get example.com/farmOS to redirect to the docker container, and it… half works?
I get the example.com/farmOS/core/install.php loaded up, but all the supporting css/js etc is missing, redirecting to example.com/core/…
I’ve had a google about and it’s recommended $base_url in the settings.php file (done), editing the sites.php file (done), no joy - still getting the page, but no resources.
Any ideas?
Looks like you have an added complexity by putting farmOS in a subdirectory instead of at the root of a domain. You might have luck searching for “Drupal behind a reverse proxy” more generally. farmOS inherits all the same functionality and considerations from Drupal.
https://www.drupal.org/docs/getting-started/installing-drupal/using-a-load-balancer-or-reverse-proxy
Also found this with a quick search: 8 - Site behind a reverse proxy - subfolder - Drupal Answers
I’ve never worked with a) Apache as a reverse proxy, or b) farmOS in a subdirectory. Should work, but you might have to debug those bits specifically yourself.
Regarding the subdirectory issue, there’s a chance you might find this helpful as well: farm-faux-cloud/app/app.py at 4280929236617238727801c3531818f8124a0fa9 · symbioquine/farm-faux-cloud · GitHub
I was unsuccessful.
Following on from your suggestion @Symbioquine editing the sites.php file.
What would the full string for a URL be there?
$sites=[
‘sub.domain.com.farmos’ => ‘default’];
sites.php is for mapping domains to directories in the web/sites directory. If you are only hosting a single farmOS instance, then you’ll use web/sites/default as your main site directory (where your settings.php and uploaded files go). With sites.php you can tell Drupal to route traffic from multiple domains to the same site. It doesn’t handle subdirectory paths at all. I don’t think you will need to touch (edit: I was wrong. see comments below…)sites.php.
Ah fair enough - that would be why that didnt work!
I’ve settled for just another subdomain instead of on a different path, seems easier!
I’m pretty sure sites.php is necessary for configuring subdirectory paths (even with a single instance). Check out the examples in the provided example.sites.php | Drupal API
Other references:
Yes, I think that should be right.
Did you double-check the permissions of the sites.php file? What behaviour are you seeing with that in place?
Same behaviour as before, the ones I navigate directly to load, but the linked resources go back to root
Does your settings.php file contain something like this?
$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];
$settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_FOR | \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_HOST | \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_PORT | \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_PROTO;
Note: Blindly trusting the remote addr as the whitelisted reverse_proxy_addresses could be dangerous if there’s any way external traffic could directly reach the farmOS container. Set your firewall or network configuration to prevent that or figure out a way to whitelist a specific IP there.
Is your reverse proxy configuration set up to pass those x-forwarded-* headers?
In NGINX that looks something like;
server {
...
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
Ah thanks for correcting me on that @Symbioquine! TIL 
Yea, more or less - I’ve got the static IP for the local computer rather than remote_addr, to limit it, thus said some docker stack overflow bit I read!
The subdomain approach seems to be working well, just had issues with it trying to redirect to http instead of https, and rather than faffing with the configs, I just did a rewrite rule there too.
Next to figure out development environment…
So if I’ve got an instance set up and running via docker, and I want to add a module, do I have to re ‘compose’ the entire thing?
@Skipper What are your Docker volume mounts?
If you are already mounting /opt/drupal/web/sites then one option is to just put modules in /opt/drupal/web/sites/all/modules. In most cases you can simply drop a module directory into that folder and then enable it via /admin/modules.
However, better practice would be to use Composer to build your own farmOS codebase and track your dependencies and their versions in your own composer.json file. That provides more protection in the future against incompatible upgrades and other issues caused by a lack of dependency management. We are most likely going to make Composer the recommended way for managing dependencies starting in farmOS v4+.
If you’d like to get set up now, we have some instructions here: Building farmOS with Composer | farmOS
Tl;dr: If you are using the off-the-shelf farmOS Docker container, then you are already using a codebase built with Composer. It just happens in the Docker image build process. You can either mimic that process with your own derivative Docker image, or you can start mounting the whole codebase into the container (not just /opt/drupal/sites) and Composer to manage dependencies. I personally prefer creating a derivative Docker image.