@JaredBusch So... now that you've had this up and running for a while, care to report on how that is going? Inquiring minds are curious. Particularly w.r.t. resource utilization comparison, performance differences, etc. comparatively. I think you were on Mongo previously, correct? Cuz I am right there with you on the license bullshit. All it takes is one bump in the road, merger, and wham, history repeats and next major version changes license again - only this time to something closed. Have no interest in betting on community to fork and continue. Need a safer bet. It would appear that percona may have already done so w/their percona mongodb offering but I wonder if that would continue as a full fork if/when upstream became closed source.
I don't know if it's strictly required, I'd add it.
Because the one tells the port to listen on. The other tells it what protocol to use. Since you can use any port, with any protocol, it has to be listed. You can just add it to port 80 if you want, for example.
s your setup is Cloudflare proxy -> Nginx proxy -> apache (mattermost)?
CF Proxy > Nginx Proxy > Mattermost (MM is its own server)
And yes, if I disable the CF Proxy, it works.
Why the double reverse proxies?
That's the standard. You are always expected to have your node.js servers behind a reverse proxy. And CloudFlare is the CDN cache in front. This is the universal standard for all web servers. Plenty of times to avoid it, of course, but this is the baseline system design.
In this case, MM is a raw node server so has none of the protections or handling of a system like Nginx. Nginx also provides the ability to have multiple sites behind one IP address. MM doesn't do that on its own, nor does CloudFlare. No different than how MangoLassi is on NodeBB, also a node platform, behind Nginx, behind CloudFlare.
CF can't do the details port and IP handling, Nginx can't do the globally distributed cache.
Thanks for the clarification Scott. I (wrongly) thought that Cloudflare was a full featured proxy and could do the same job as haproxy, nginx etc.
I'd normally keep swap space too but I know for sure you can run without it successfully because we used to do that with embedded linux for years - with devices that had years of uptime.
With memory ballooning you can overcommit RAM and the hypervisor can swap guest RAM to disk if it comes to that. I don't know which hypervisors supports it though. As always it depends on how much you want to cram out of your gear.