Deploy Xibo CMS on AWS Fargate - No bed on roses

Community Discussion General
1

Hi
I try to deploy Xibo CMS on AWS Fargate with Typescript CDK.
I use AWS EFS as file storage and a schema in MySQL RDS Database.

In Fargate, I create one service, with exposed ports 443-> and 9505 tied to an Network Load Balancer. The CMS can read and write files to the EFS Access points and there is (should be) an internal link between the XMR container on container port 50001 exposed to the CMS container. However, I think the XMR instance is intended to run as one instance even in a cluster setup, but as long as I only have a single instance that should not be an issue.

However, there are several issues that I hope you may be able to help me with.

    1. When CMS container starts, a lot of errors chown: /var/www/cms/web/theme/custom: Operation not permitted and similar paths is shown in log. I know that this is due to that the user is squashed into a custom POSIZ user. Is there a way to tell CMS that there is no root privilegies to the file system?
    1. I have found that set XMR_DEBUG=“true” on the XMR instance should enable extended logging. However, I can not see anything else in the logs but xmr.DEBUG: Heartbeat... [] []. I can see in the players that they are connected to XMR, but can not see if the CMS itself is connected. Should connecting clients be visible here?
    1. The players does not download content. Occasionally, I get this error on windows player:

2021-09-06 15:59:22
LogAgent
LogAgent - Run
Exception in Run: Client found response content type of 'text/plain;charset=UTF-8', but expected 'text/xml'.
The request failed with the error message:

There has been an unknown error with XMDS, it has been logged. Please contact your administrator.
–.

I googled a bit and found that there may be an PHP settings in php.ini that must be set: always_populate_raw_post_data=1. Is there a shortcut to modify this in the Docker file or do I need to create an custom Dockerfile to fix this?

It is clearly shown that Xibo is not originally intended to run on docker instances and deployed on “serverless” infrastructures. So far, I would like to see following changes in the development:

  • a) Change message queue system to an widely spread one, for example MQTT or Websocket.
  • b) Start to use only http based communication. It makes deployment easier on cloud environment where only simple application load balancer is needed, and not level 4 balancers.
  • c) Get rid of all http/https redirects from the application and always let the infrastructure handle that, for example an apache rewrite that is enabled throught an environment variable as opt-in.
  • d) Get rid of all https/tls setup in application and let infrastructure handle it (Load balancers, reverse proxies etc). There are so many use cases out there so there is impractible to handle that by the application.
2

No there isn’t. The platforms we support do not have this limtation.

No, they won’t be. You’ll see messages there when the CMS pushes a message to the queue.

No you don’t. The images we provide work fine in the environments we support deploying them in. The log you have there suggests something other than the CMS sent a response to the Player, so perhaps an error page from a reverse proxy?

We have good reason for selecting ZeroMQ and it is widely deployed in other systems.

The CMS needs to handle http → https redirects ideally, as there are scenarios where some URLs need to be available over http and others should be handled over https. For example, where you have Android Players that rely on connecting to the CMS to get the time, they cannot make an HTTPS connection because they have no valid time source, and so need to be able to make that connection over http to get that, and then they can move to https.

If you don’t want the CMS to do any redirection of http → https, then simply turn the Force HTTPS option off, and then the CMS will let your upstream do that - however you’d then have to cater for that application logic in your load balancers.