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:
wget http://192.168.1.200/static/js/main.3cee5571.js returns a 404 error, as expectedwget 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 formattedSurprisingly, 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.
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:
npm run build and then npm startIt 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.
Most helpful comment
the
npm run buildcommand 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:npm run buildand thennpm start