Frontend Assets Failing to Load for Docker Compose Installation

[nasanos]

Expected Behavior

Frontend assets would load and display completely following set up and execution of a Docker Compose instance of the Countly server. By assets, I mean things like image assets, such as the Countly application logo, and property assets, like the mapped value for management-applications.application-name.

Current Behavior

After setting up a Docker Compose instance of Countly server and completing the form for registering an administrator user, Countly has failed to load all of its frontend assets.

I have attempted two different Docker Compose setups, one on Ubuntu and another on AlmaLinux (essentially CentOS). Both instances loaded the initial registration page just fine, and both continued to load the login page without issue.

However, the dashboard failed to load properly in both cases. On Ubuntu, pages displayed as in the first two screenshots below. Generally, pages looked okay, but names were not mapped to their appropriate values — I see management-applications.application-name instead of "Application Name".

On AlmaLinux, far fewer assets loaded, as you can see in the third screenshot. This dashboard is essentially not navigable.

Screenshots

Possible Solution

My guess is this is a permissions issue, and likely there is something I can do differently in the process of setting up the Docker Compose instance to remediate the issue. However, I'm not sure what — my attempt is likely what led to the results I got on AlmaLinux. I have scoured the Countly documentation, past issues, and other online resource, but have not had success fixing the issue.

So, at the least, if this ends up being a permissions issue that can be remediated by certain set up steps, I think that information should be added into the Countly documentation for future users.

Steps to Reproduce

1. Download the Countly Docker Compose file and its Docker NGINX configuration file, as per the documentation. Execute the sed command as shown there too (minus the empty quotation, which causes an error consistently for me).

   I have tried downloading these files both using sudo and using a limited user, and the results were the same.

2. Make sure your firewall has the HTTP port open, and the HTTPS if you plan on using that. Also modify the downloaded NGINX configuration to include your hostname/remote IP address should you intend to access the server remotely.

3. Run the instance using sudo docker compose up.

4. Navigate to the instance in your browser, and complete the registration.

5. Observe the dashboard to ensure that all assets have loaded appropriately.

Your Environment

Attempted on two different systems:

• Ubuntu 20.04

• AlmaLinux 8

[ar2rsawseen]

Hello
can you show browser developer console network tab, how those resources are failing to load and what are the responses and HTTP response codes

[AliceZ413]

My english is not good, but I try my best to share how i resolve it.

I run the command docker-compose down, and then run docker-compose up -dagain.
And wait for complete, I have no problem again.

It is worth mentioning that, when I docker-compose up -d at first time, it just take me 10 or 20 seconds, but when I try docker-compose down and docker-compose up -d, it take me about 5 minutes to complete.

At last I put my screenshot -- the broswer developer console error.
I just change port of nginx, from 80:8080 to 8082:8080

[AliceZ413]

Hello can you show browser developer console network tab, how those resources are failing to load and what are the responses and HTTP response codes

#3440 (comment)

Have any idea?

[nasanos]

@AliceZ413 Unfortunately, restarting the instance via docker compose down and docker compose up -d did not affect the results for me. I ended up doing so several times as I attempted to resolve the issue, but nothing changed.

@ar2rsawseen I don't have easy access to the developer console right now — I ended up going with the git clone installation method instead for what I needed, and I've since scrapped the Docker installation.

When I get some time to spare I can see about following the steps I gave above again to reinstall the Docker instance and get the developer console output.

[ar2rsawseen]

I think our @Countly/devops team was able to establish that it does not happen on GKE or other cloud kubernetes, but weirdly only kubernetes on bare metal or VM
But they are not sure yet why

[nahsi]

Same issue. Running in Nomad.

In logs on startup:

Running "uglify:dist" (uglify) task
JS_Parse_Error [SyntaxError]: Unexpected token: operator «*»
    at JS_Parse_Error.get (eval at <anonymous> (/opt/countly/node_modules/grunt-contrib-uglify/node_modules/uglify-js/tools/node.js:1:1), <anonymous>:63:23)
    at formatError (internal/util/inspect.js:1149:38)
    at formatRaw (internal/util/inspect.js:919:14)
    at formatValue (internal/util/inspect.js:774:10)
    at inspect (internal/util/inspect.js:319:10)
    at formatWithOptionsInternal (internal/util/inspect.js:1979:40)
    at formatWithOptions (internal/util/inspect.js:1861:10)
    at console.value (internal/console/constructor.js:328:14)
    at console.log (internal/console/constructor.js:364:61)
    at /opt/countly/node_modules/grunt-contrib-uglify/tasks/uglify.js:144:17 {
  filename: 'countly.utils.concat.js',
  line: 60036,
  col: 1,
  pos: 5539117
}
>> Uglifying source frontend/express/public/javascripts/min/countly.utils.concat.js failed.
Warning: Uglification failed.
Unexpected token: operator «*». 
Line 60036 in frontend/express/public/javascripts/min/countly.utils.concat.js
� Use --force to continue.

[nahsi]

OK, in my case uglify:dist consumed more than 1.5GB memory and got OOM killed. After increasing memory limit the issue is gone.

Not sure why it is not working locally with docker-compose.

[ar2rsawseen]

Oh wow,
in the next sprint we will fix this not to do uglify on docker start