Skip to content
This repository has been archived by the owner on May 31, 2021. It is now read-only.

FLOOD_BASE_URI does not work in Docker image #621

Open
sgsunder opened this issue Feb 14, 2018 · 7 comments
Open

FLOOD_BASE_URI does not work in Docker image #621

sgsunder opened this issue Feb 14, 2018 · 7 comments

Comments

@sgsunder
Copy link
Contributor

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)
@deed02392
Copy link

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.

@joshuajbrunner
Copy link

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)

@jdelkins
Copy link

jdelkins commented May 5, 2018

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.

@williamkray
Copy link

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.

@deed02392
Copy link

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

@williamkray
Copy link

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

@skyegecko
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants