Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker support #554

Closed
2 of 3 tasks
gregmartyn opened this issue Mar 26, 2018 · 7 comments
Closed
2 of 3 tasks

Docker support #554

gregmartyn opened this issue Mar 26, 2018 · 7 comments
Labels

Comments

@gregmartyn
Copy link
Contributor

gregmartyn commented Mar 26, 2018

I've run into a couple issues when running Razzle in a Docker container, mostly because of 127.0.0.1 assumptions.

  • The --inspect parameter to razzle start, which sets INSPECT_ENABLED, doesn't pass through the IP address. E.g. --inspect=0.0.0.0:9229. By default, inspect uses 127.0.0.1, which I can't port forward from the host to port 9229 inside the container.

  • There's no way to tell the client which hostname to connect to. localhost:81 is assumed. PR here: Add CLIENT_PUBLIC_PATH env var #530

  • Environment variables aren't being treated as variables. Docker builds static images that expect to be deployed in different environments and controlled by environment variables. RFC: process.env.RAZZLE_RUNTIME_XXXX #528

@adamjv90
Copy link

I too am running into a similar issue using docker-compose. I would like my client side build to contain the values of ENV vars at build time. But come runtime id like my server to pull from the runtimes ENV vars, basically as stated here #528 (comment) . Reason behind this is because i am docker-composing a nginx reverse proxy which sits in front of my api and razzle application. On the client i need my application to query the exposed reverse proxies port. However on the server i need my application to query my api service directly as described here https://docs.docker.com/compose/networking/

@ikappas
Copy link
Contributor

ikappas commented May 4, 2018

@gregmartyn @adamjv90 have a look at #528 (comment)

@jwickens
Copy link

An issue im running into right now is that RAZZLE_PUBLIC_DIR by default injects the full path from the build machine, which for CI performance reasons is completely different from the runtime machine where i copy the built assets.

@tesharp
Copy link

tesharp commented Jul 27, 2018

@jwickens I have the same problem and ended up with trying to avoid using RAZZLE_PUBLIC_DIR unless running in local dev mode. Using node module is-docker I run following:

const isDocker = require('is-docker');
const env = require('get-env');

const staticPath = env === 'dev' && !isDocker() ? process.env.RAZZLE_PUBLIC_DIR : path.join(__dirname, '../build/public');

server.use(express.static(staticPath));

Not ideal, but at least it works. Runs fine both in local dev mode and inside docker.

@butterybread
Copy link

@jwickens If you know what the location of your public dir will be at runtime, use that to overwrite the RAZZLE_PUBLIC_DIR env var when running the build command and it should work.

@stale
Copy link

stale bot commented Oct 26, 2018

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

@stale stale bot added the stale label Oct 26, 2018
@stale
Copy link

stale bot commented Nov 2, 2018

ProBot automatically closed this due to inactivity. Holler if this is a mistake, and we'll re-open it.

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

No branches or pull requests

6 participants