setting up a production instance

[acollign]

I am looking into setting up a production for my own testing. I have a couple of questions regarding the approach used by jinteki.net.

What I have done so far is to build the uberjar with a prod.edn defined in the resources folder which gets embedded into the jar. I am planning to set up a webserver to serve the static files, those below resources/public.

Is it approximately what is done on jinteki.net?

Also, do you bundle the prod.edn file into the jar? I would think that is better to have it outside to allow managing the configuration independently.

Finally, I have a visual warning that shadow-cljs is not able to connect. I am surprised by this as I would assume that the server/mode prod would disable shadow-cljs entirely.

Thanks in advance for the help.

I will be happy to write to documentation once my setup is working.

p.s.: I will accept a RTFM :-)

[NBKelly]

So my process is:

• lein clean, lein fetch
• build css/cljs
• lein uberjar
• nohup java -XX:-OmitStackTraceInFastThrow -jar target/netrunner-standalone.jar # > /home/jinteki/log/clojure.log &

I think this should do everything you want.

[acollign]

Thanks for providing these steps. I will try them and report back.

[NBKelly]

oh, as a follow-up: you might find that only local or https connections work.
You can change the secure key in dev.edn to stop that, or you can set up a reverse-proxy by something like nginx (I don't actually remember how to do this one, sorry)

[acollign]

Here is what's done with a fresh clone

• lein clean
• lein fetch
• npm ci
• npm run css:build
• npm run cljs:build
• lein uberjar
• java -XX:-OmitStackTraceInFastThrow -jar target/netrunner-standalone.jar

and I have the db running (that one is not a fresh instance, though).

I can see that the visual warning that shadow-cljs is now gone. That is good!

However, I am still getting 404s for the images. Somewhat that seems expected since the cards are explicitly excluded from the uberjar build in project.clj.

oh, as a follow-up: you might find that only local or https connections work.

Good to know.

You can change the secure key in dev.edn to stop that, or you can set up a reverse-proxy by something like nginx (I don't actually remember how to do this one, sorry)

Yeah, it was my intention to set up nginx as a reverse-proxy. Could it be that the images are also served by this nginx server in your prod setup?

[acollign]

Setting up a simple reverse proxy is working great. @NBKelly shall I start a draft PR with some documentation and docker files?

[NoahTheDuke]

npm ci then npm run release should generate minified versions of both css and javascript, which you'll want if you're running this for other people.

[acollign]

npm ci then npm run release should generate minified versions of both css and javascript, which you'll want if you're running this for other people.

Thanks for the tip @NoahTheDuke. I've integrated it in my build steps.

[NBKelly]

Setting up a simple reverse proxy is working great. @NBKelly shall I start a draft PR with some documentation and docker files?

Yeah, that would be pretty helpful - feel free to do so if you like

[cody1024d]

Our local play-group was using these instructions to set up an instance for ourselves to use. In doing so, we found a couple of discrepancies with the instructions, and additionally a blocker or two that we had to overcome. These probably need to be addressed before going live.

1. The lein generate-docker command does not support an --name flag. It should instead use the --image flag.

2. This set-up doesn't work perfectly on a Windows machine. The run-with-config script doesn't execute there. You'd probably have to set up docker in WSL or something for it to work. We probably should just note this, for those not as experienced with Docker (like myself). To get around this, I took the commands from the run-with-config script, and added them as commands within the DockerFile.

3. On creating the docker images, there seems to be an issue that it is pulling mongo connection information from the dev.edn. I'm not totally sure how this is happening, but if everything is left as-is, the game-server (server-1) will get socket timeouts, as it's trying to connect to localhost:27017 (which is the connection information in the dev.edn). Once this is changed to the image name (mongo) and the images are built from that, the connection works properly.

   3a. However, once this is done, the populate database scripts no longer work correctly, when run from the host machine. The dev.edn must be changed back to point to localhost so that the populate scripts can find the running mongodb instance (from the host machine).

4. And finally, this is actually a blocker that we were unable to overcome. When deployed, a user is unable to sign-in from a remote machine. On the server itself (if you are accessing via localhost:1042), the session is created correctly (verified with a session cookie), however on any remote machines (accessing via IP or DNS) this cookie is not created. If the cookie is taken and created manually, the session is correctly used, and the remote machine works.

This last step is probably simply my inexperience with Web-App Devops, but figured I'd list it here in case it has something to do with how the server is being stood up.

[Shadow-Night-Black]

@cody1024d
2) I had the same problem, this is due to a combination of a) it not being set to be executable and b) it having windows line ending rather than unix line ending, adding the two following lines to the docker file will fix it
RUN chmod +x ./run-with-config
RUN sed -i -e 's/\r$//' ./run-with-config

4. by default the session cookie is setup to be secure, so it can only be accessed via local host/https. you can either add an ssl cert so that https can be used, or remove the secure flag from the :web/auth section of the prod.edn

[cody1024d]

@Shadow-Night-Black Thank you for the additional info!!

I knew it had to do with line endings! I tried to open it within an editor in windows, and change the line endings manually, and it didn't work; but I'm sure I just did something silly.

As for #4 --- this is my lack of webdev showing for sure haha. Is this something that is the default behavior for a secure cookie? That they will only work locally if no SSL cert is loaded?

[Shadow-Night-Black]

@cody1024d No problem :)

For 4), yes. Secure cookies are only ever sent to the server over https (except on local host) see here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies if you want more information.
Notably, this enforcement is done on the client's browser, rather than the server, hence the page reloading etc as if you had loged-in, but then the client browser does not serve the authentication cookie and hence remains in a logged out state.