smol wrote:
@jlutherthomas Is there anything I can do to make this easier to be reviewed?
Maybe it would be a good starting point to identify if the message of "Trying to update FME Server services..." from the Core container is a critical message. Currently, I am unable to identify the risk of this message as I can not find any documentation about this message.
Also, how important is it to identify a custom "PORTPOOL" range, I have seen it work without this. But I can imagine this causing issues when a lot of Workbenches have to run.
Another question: Would there be a product-ready docker-compose example of running the FME Engine on a separate server? I have not found a ready docker-compose for this setup, but only for when the engine is running on its own server. This can be useful to be absolutely certain that all the correct ports are opened, which can be related to this initially reported message of "Trying to update FME Server services...".
Hi @smol
I managed to get this working and 'out of the box', adapting your compose files with my IP addresses etc it works totally fine for me. PORTPOOL was exposed in this test.
There are 2 situations that I think might cause this error that you're seeing:
- After setting up FME Server, if you change the FME Server users by creating a new superuser account and delete the existing one, I can get this critical error to show by manually starting the services script that's throwing those errors.
- If after the initial set up of FME Server you change either the EXTERNALHOSTNAME, EXTERNALPORT or WEBPROTOCOL values in your core compose file and then restart (recreating the core or web containers) you may find this error appearing.
PORTPOOL should have no impact on the error messages coming from the services script. My guess is that something changed with one of the inputs (mentioned above) after the initial set up which when containers are recreated, the values no longer match what was set on first install, so the script throws an error. As your services are working correctly (confirmed by the ability to run jobs etc) I think that script must have run successfully at some point, my assumption is the very first time you started FME Server.
I think you have two options:
- Easy one, ignore the error message. However as it's logging every 5 seconds this takes up unnecessary log file space.
- Try bringing your deployment down completely - making sure both the database and fme server file share are removed. Then re-deploy your FME Server and hopefully everything is ok on the first start. (If you do change the admin user post install you may still end up with this issue down the line)
One thing to be aware of with this type pf deployment (you may have already figured it out) is that you'll be stuck with 1 engine per VM (which maybe you're happy with).
FME Server engines in container deployments are managed by docker (or kubernetes) so if you wanted to increase engines you would do this. In this distributed deployment, you're exposing 7500 for one container. If you try to scale up more engine containers on the same host you'll get port binding errors:
ERROR: for fmeserverengine Cannot start service fmeserverengine: driver failed programming external connectivity on endpoint azureuser_fmeserverengine_2 (ceb18e2cf1e380d00088c6744c6a07b0bfdf3bed82534d6e8f0465b2eabd245a): Bind for 10.1.0.5:7500 failed: port is already allocated