Flood: FLOOD_BASE_URI does not work in Docker image

Created on 14 Feb 2018  路  7Comments  路  Source: Flood-UI/flood

I am trying to run flood, using the provided Dockerfile, behind a nginx reverse proxy.

In my docker-compose file I pass the environment variable FLOOD_BASE_URI = /flood to the container. I have even checked using docker exec to make sure this variable is actually passed.

When accessing http://192.168.1.200/flood from a browser returns a blank, dark blue page.

Viewing the source of the page reveals the problem:
<script src="/static/js/main.3cee5571.js" type="text/javascript"></script>

Of course, the URL should be /flood/static/js/main.3cee5571.js, so it seems that flood is not properly using the baseURI variable in generating the page.

Testing further:

  • Running wget http://192.168.1.200/static/js/main.3cee5571.js returns a 404 error, as expected
  • Running wget http://192.168.1.200/flood/static/js/main.3cee5571.js works and returns a javascript file. So this seems to indicate to me that nginx is not the issue, as it is forwarding URLs correctly when properly formatted

Surprisingly, bypassing the proxy by accessing http://192.168.1.200:3000/ still gives a fully functional flood page, even with the baseURI variable set to '/flood', and http://192.168.1.200:3000/flood still does not work. Again, this seems to me an issue with flood not handling the baseURI variable properly, instead of an issue with the reverse proxy configuration.

Here's my nginx proxy configuration

location /flood/ {
        proxy_http_version 1.1;
        rewrite ^/flood/(.*) /$1 break;
        proxy_pass http://localhost:10660/flood/;
        proxy_set_header  Host            $http_host;
        proxy_set_header  Upgrade         $http_upgrade;
        proxy_set_header  Connection      "upgrade";
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Scheme        $scheme;
        proxy_set_header  X-Script-Name   /flood;
}

I also tried running without the proxy_set_header commands with no luck.

Your Environment

  • Version used: Dockerfile built from latest commit (2cb40c4), NGINX 1.13
  • Environment name and version (Firefox version 58 on macOS 10.12, MS Edge 41 on Win10, Safari 11.0.3 on macOS 10.12):
  • Operating System and version: (Debian Stretch running Docker version 17.12.0-ce)
bug docker

Most helpful comment

the npm run build command would just have to be a part of the container startup, which will slow things down but ensure that static assets are generated at runtime, allowing them to pull the environment variables in properly. i messed with this for all of 5 seconds and then decided i had other things that were more pressing at the time, but it shouldn't be difficult. something along the lines of:

  1. have a startup script that gets executed to run npm run build and then npm start
  2. use this startup script as the CMD of the container
  3. ???
  4. PROFIT

All 7 comments

I think you need to modify the config file in the container itself. Start by updating the config.docker.js file to include support for getting the new base URI from environment variables.

Make sure the baseURI = '/flood/' in config.js

Also you should not need the proxy_set_header stuff, nor the additional /flood/ on the proxy_pass portion (ie should just be proxy_pass http://localhost:10660)

config.docker.js contains this

baseURI: process.env.FLOOD_BASE_URI || '/',

When I run docker setting FLOOD_BASE_URI environment variable, it is apparently ignored exactly in the manner described above. However, when I edit config.js to hard code the variable setting, it works fine.

i've been able to confirm that it's due to the static content not being regenerated since the container build process.

if you run docker exec -it <container-name> sh to gain access to a shell in the container, and then run npm install and npm run build, then restart the _existing_ container, the environment-variable URI is used.

Great detective work. Is there a better general approach to this in Docker?

the npm run build command would just have to be a part of the container startup, which will slow things down but ensure that static assets are generated at runtime, allowing them to pull the environment variables in properly. i messed with this for all of 5 seconds and then decided i had other things that were more pressing at the time, but it shouldn't be difficult. something along the lines of:

  1. have a startup script that gets executed to run npm run build and then npm start
  2. use this startup script as the CMD of the container
  3. ???
  4. PROFIT

It turns out that the reason for this is that there's no direct way of passing environment variables to a container during the build process. The workaround is to specify the variable as an ARG instead, and then set an ENV based on the ARG.

I modified my Dockerfile like this:

@@ -18,7 +18,12 @@ RUN apk add --no-cache --virtual=build-dependencies \
 # Build static assets and remove devDependencies.
 COPY client ./client
 COPY shared ./shared
 COPY config.docker.js ./config.js
+
+ARG FLOOD_BASE_URI=/
+ENV FLOOD_BASE_URI $FLOOD_BASE_URI
+
 RUN npm run build && \
     npm prune --production
 COPY server ./server

Now you can pass the setting using docker build --build-arg FLOOD_BASE_URI=/flood/, or set it in a docker-compose.yml:

# <snip>
    build:
      context: ./flood/
      args:
        - FLOOD_BASE_URI=/flood/

I'd suggest something to this effect gets added to the Dockerfile and wiki.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jvacek picture jvacek  路  3Comments

valdearg picture valdearg  路  3Comments

rkkoszewski picture rkkoszewski  路  6Comments

jr64 picture jr64  路  3Comments

angristan picture angristan  路  4Comments