Docker Hostnames not resolving in next.js prod but working in dev mode (Error: getaddrinfo ENOTFOUND) - node.js

I'm running a next.js react app in a docker container. It's being composed with several other contains: one running Ghost (I'm using the API), one running mysql, and one running NGINX. I've got everything running in development mode.
It works perfectly when run using next dev. But when I run it by doing next build and next start, I start seeing errors like Error: getaddrinfo ENOTFOUND ghost-api when I try to make server-side HTTP requests to my Ghost API container. I'm not entirely sure what the issue is but it seems like there's some issue with how Node is making requests after being built. I've been digging through a lot of Docker/Node questions trying to figure this one out but haven't had any luck.
The entire project can be found here: https://github.com/MichaelWashburnJr/react-cms

The problem may exist in the environment variable that you are using. In both getGhostApi and getGhostApiKey function, you are using the environment variable.
In NextJs you'll have to specify a next.config.js in which you define the variables that you need for
Ex. next.config.js
module.exports = {
serverRuntimeConfig: {
// Will only be available on the server side
mySecret: 'secret',
secondSecret: process.env.SECOND_SECRET, // Pass through env variables
},
publicRuntimeConfig: {
// Will be available on both server and client
staticFolder: '/static',
},
}
You can also refer to the next documentation for the same.
https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration

I'm not able to reproduce the error. How are you starting the frontend container in prod mode?
From the error it appears like you might be trying to start the frontend container or the frontend app as a separate process without starting it as part of the compose project. If that is the case, the name ghost-api won't be resolvable and you would get the Error: getaddrinfo ENOTFOUND ghost-api error.
I've changed the command key of frontend container as follows:
command: [ "yarn", "start-prod" ]
Changed the "start-prod" script in frontend/package.json as follows:
"start-prod": "next build && NODE_ENV='production' next start"
and everything worked as it worked in dev mode. I got some UNKNOWN_CONTENT_API_KEY error in both dev and prod mode but definitely there is no ghost-api name resolution error.

After cloning your repos:
$ grep -R ST_API *
frontend/.env.development:GHOST_API_URL=http://ghost-api:2368
frontend/.env.production:GHOST_API_URL=http://ghost-api:2368
frontend/src/constants/Config.js:export const getGhostApi = () => process.env.GHOST_API_URL || 'http://localhost:8000';
ghost-api is not a domain name: to make it work you need to edit your hosts file or (for a real production environment) to change http://ghost-api:2368 in frontend/.env.production file with the real deploy domain name.
If you are asking why you can't trust on docker compose networking, the answer is: you can, but only in the containers; while the front end will run in the browser of your application client, which is outside the containers.
Hope this helps.

It seems that Docker's hostname resolution does not work during build time. That is why ghost-api is not found.
Instead of referencing the other container by its name (ghost-api), on Mac you can try host.docker.internal. On Linux, using host networking during build worked for me:
nextjs-app:
build:
network: "host"
# ...
network_mode: "host"
This way, you can reference the other container using localhost.

Related

Vue.js Webpack Template in a Docker Container: How do I add Webpack-Dev-Server --watch-poll flag?

I am running the webpack / webpack-dev-server portion of the base Vue.js Webpack template (https://github.com/vuejs-templates/webpack/) inside of a docker container I created. The container also contains the vue CLI in order to create new projects (you can get my container here if you want: https://hub.docker.com/r/ncevl/webpack-vue/).
Hot-reload does not work after moving from the webpack-simple template to this one.
Everything was working using the Webpack-Simple template which you can clone / see over here: https://github.com/vuejs-templates/webpack-simple
I was able to get the simple template running (with hot-reload working as intended) with the following webpack-development-server launch command:
webpack-dev-server --hot --inline --progress --host 0.0.0.0 --watch-poll
That said the full (not simple) version of the webpack template does not appear to use a webpack-dev-server launch command and instead appears to use additional middleware as referenced in build/dev-server.js (https://github.com/vuejs-templates/webpack/blob/master/template/build/dev-server.js) and the webpack dev config.
Since the --watch-poll was the key to getting the WDS hot-reload functionality to work within a docker container in the last project, my thinking is that I need to do something similar with the webpack-hot-middleware but I dont see anything in their docs (over here: https://github.com/glenjamin/webpack-hot-middleware) that talks about changing to a polling based approach.
I am not 100% sure the polling flag will do the trick since I can see the container recompile my source when I make a change. I can also see the change in my browser if I refresh it manually.
Whats stranger still is if I inspect my page in browser within chrome dev tools, and then head over to network / XHR I can see that the browser actually does receive information from the webpack-dev-server, but visually it does not update.
Give the above I assume websockets (or socket.io which I think is used) are working and communicating between the browser and the WDS so maybe this is a browser caching issue of some sort?
I checked in my console and found this so it is looking like a header issue:
For reference the text error from that image (to make it easier for anyone having the same issue to find this post) is:
EventSource cannot load http://__webpack_hmr/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://0.0.0.0:8080' is therefore not allowed access.
Again the Hot-Reload / Hot Module Reload was working with this identical container setup when using the webpack-simple Vue.js template.
I am wondering if anyone has run into anything similar or has any ideas on how to add the polling option . I guess my alternative would be roll back to a more basic webpack config and rebuild that portion of things to use the traditional webpack-dev-server / webpack config but give the above I am not sure that is going to fix it.
I am adding this as a separate answer since it more specifically answers the question in the title, while my other answer more specifically explains what solved my actual problem.
The vue.js webpack template project (which can either be init'd from the Vue CLI or pulled from its repo over here: https://github.com/vuejs-templates/webpack) separates its config files into several different directories.
I am posting this answer so that anyone who runs into the need to add polling to their project will be able to understand how / where to do that.
The base project structure for a Vue.js webpack template project looks like this:
The files that you care about if you are messing with trying to get hot module reload working are related to creating your server primarily with webpack-dev-middleware. The most important files related to that are highlighted here:
Basically if you want to add the polling code to the webpack-dev-middleware server you need to be in the /build/dev-server.js file on lines 20 to 24 that look like this:
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
quiet: true
})
To add polling you would add it just before or after quiet: true. As a side note, if you are having trouble with HMR I would change "quiet:true" to queit false to get a more verbose read out of whats going on from webpack-dev-middleware. I have included verbose and polling modifications to the above code here:
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
quiet: false, //Changed to for additional verbosity
watchOptions: { //Add Polling
aggregateTimeout: 300,
poll: 1000
}
})
My other answer is in regards to what ended up solving my problem, not necessarily how to actually add polling (which might be necessary for someone else but did not end up being needed to make my dockerized setup work).
It should also be noted that sometimes when HMR (webpack hot module reload) is not detecting changes it is due to the fact that webpack-hot-middleware or webpack-dev-middleware is running into an issue whereby some invisible characters are / were added to the name of the base project directory (probably by someone building the base Vue project) and therefore webpack on certain OSes is not able to see the changes.
If that happens to you and you are on OSx or running webpack inside of a docker container and you can't get HMR to detect changes, try to rename your vue-webpack project directory and it should work.
Ok. So I can't really take credit for this one since it was actually answered by Discuss user Cristian Pallarés over here: http://webpack.github.io/docs/webpack-dev-server.html#combining-with-an-existing-server
Christian says:
I was just trying the same. I just use "php artisan serve" on localhost:8000, and Webpack Dev Server on localhost:3000. You should make this:
set your webpack config "output.publicPath" as "http://localhost:3000/static/" instead of "/static/"
make your php application load this:
The key is the output.publicPath being absolute. Now, you should run "php artisan serve" and launch your webpack dev server too (in my case I use gulp).
Basically I took that and dug through the Vue.js Webpack Template files to locate the config file where webpack was looking for the public path. the public path setting ended up being in the index.js file located in the /config directory of the template.
I changed my code to look like this:
assetsSubDirectory: 'http://localhost:8080/static/', //!!Changed from /static/
assetsPublicPath: 'http://localhost:8080/', //!!Changed from /
As opposed to the previous setting which DID NOT WORK and looked like this:
assetsSubDirectory: '/static/',
assetsPublicPath: '/',
After that I was able to see my changes hot reload while running the vue.js Webpack template from within my docker container.

Running blockchain-wallet-service on a Heroku worker

I'm trying to deploy my Django app on Heroku, that makes use of the Blockchain.info API V2 (https://github.com/blockchain/service-my-wallet-v3) and thus needs to run blockchain-wallet-service in the background, which in turn needs Node.js and npm installed.
On localhost, I have used this API successfully by running the service on my own machine, but I'm having trouble deploying to Heroku. Firstly, I assume I will need to run the service on a separate dyno, and that I will need node and npm installed on my instance.
Can someone tell me how to achieve this? I'm new to more advanced features of Heroku, I've tried to use the nodejs buildpack but I doubt this is the correct way. There is also this: https://elements.heroku.com/buttons/kmhouk/service-my-wallet-v3 which I've deployed as a separate app but I've failed to merge it in some way to my Django app.
Any help is much appreciated!
I had this exact same issue, bro, and i finally got some light in the end of the tunnel.
I've cloned the https://github.com/blockchain/service-my-wallet-v3 repository and deployed it to heroku and made some changes on "package.json" file. The problem is that (in heroku) you need to declare the dependencies on package file. I've added these lines:
"dependencies": {
"blockchain-wallet-service": "~0.22.4",
}
and a script to test in the deploy:
"scripts": {
"postinstall": "blockchain-wallet-service -V"
}
Also, by cloning this repository, i needed to add this line too:
"license" : "(ISC OR GPL-3.0)",
hope it works for you

How to correct a Bluemix Node.js app that can't accept connections

I created a new Node.js app on Bluemix this morning and downloaded the boilerplate code. I worked on it locally and then pushed it up. On Bluemix, it refuses to start. The error according to the logs is:
Instance (index 0) failed to start accepting connections
So I Googled for that, in every case where I found the result, the answer was that my application was trying to use a specific port instead of letting Bluemix set it.
Ok, but I'm setting the host/port with the exact code the boilerplate uses:
var appEnv = cfenv.getAppEnv();
// start server on the specified port and binding host
app.listen(appEnv.port, function() {
// print a message when the server starts listening
console.log("server starting on " + appEnv.url);
});
So if this is incorrect, it means the code Bluemix told me to download itself is incorrect as well, and I can't imagine that is the issue.
To identify whether cfenv is at fault, I've tested that piece of code with a number of more complex Node.js apps I have, and they work perfectly on Bluemix.
That message can also come when an application you've deployed to Bluemix fails to start at all. Here's a few things you can do to troubleshoot your Node.js application on Bluemix.
Tail logs in another terminal while pushing with "cf logs
". Inspect logs after the failure to see if something
failed during the staging process.
Check that your start command in one of two recommended places, scripts.start in package.json or in a Procfile with web: node <start-script>.
Check that your application works locally. First (optional), create a .cfignore file with "/node_modules" in it, so that when you push the app to Bluemix, CF CLI doesn't push your entire folder of node_modules (as they will be installed dynamically). Next, wipe out your node_modules directory and do an npm install --production followed by npm start (or your custom start command). This is what Bluemix does when trying to start your application, so you should double check that it works locally.
Finally, try bumping up your memory, although this is very unlikely that this is why your application fails to start.

Deploying NodeJS application to Openshift

I have working SailsJS app that I want to deploy to Openshift, but as usual it doesn't go smoothly.
Here's what I did so far:
rhc app create myApp nodejs-0.10
rhc cartridge add mongodb-2.4
After these two, I can see that app is created and when I visit given URL, I got Welcome page.
I installed RockMongo, and I see that I can visit my mongodb as well.
Since I already have code, I proceed with following:
git remote add openshift -f <openshift-git-repo-url>
git merge openshift/master -s recursive -X ours
git push openshift HEAD
After I merge my existing code with remote openshift (like in commands above), things start to go wrong.
When I visit url to application, I receive 503 Service temporarily unavailable. If I visit RockMongo and try to login with given credentials, I receive
Unable to connect MongoDB, please check your configurations.
MongoDB said:Failed to connect to: 127.10.37.130:27017: Transport endpoint is not connected.
Also, in Applications Panel, status of my application is building (and stays like that for hours). After pushing code to openshift, application stopped, and after rebuilding it (automatically) I receive some errors, where the last one is
remote: An error occurred executing 'gear postreceive' (exit code: 34)
remote: Error message: CLIENT_ERROR: Failed to execute: 'control build' for /var/lib/openshift/538f1c205004461655000227/nodejs
Does anyone has idea what's going on?
Maybe I didn't set up ports, application url, db url properly? But then again, why RockMongo stopped working?
UPDATE
Here's my mongo config:
mongo: {
module: 'sails-mongo',
user: 'admin',
password: '********',
url: process.env.OPENSHIFT_MONGODB_DB_URL + 'surge'
}
Do I need to set up server_port = process.env.OPENSHIFT_NODEJS_PORT and server_ip_address = process.env.OPENSHIFT_NODEJS_IP as well?
I have some server.js file in root of my application, and I see that these variables are used here.
Here's what I get if I run env | grep NODEJS
OPENSHIFT_NODEJS_PATH_ELEMENT=/var/lib/openshift/538f1c205004461655000227//.node_modules/.bin:/opt/rh/nodejs010/root/usr/bin
OPENSHIFT_NODEJS_PORT=8080
OPENSHIFT_NODEJS_LD_LIBRARY_PATH_ELEMENT=/opt/rh/nodejs010/root/usr/lib64
OPENSHIFT_NODEJS_IDENT=redhat:nodejs:0.10:0.0.17
OPENSHIFT_NODEJS_LOG_DIR=/var/lib/openshift/538f1c205004461655000227/app-root/logs/
OPENSHIFT_NODEJS_IP=127.10.37.129
OPENSHIFT_NODEJS_PID_DIR=/var/lib/openshift/538f1c205004461655000227/nodejs//run/
OPENSHIFT_NODEJS_VERSION=0.10
OPENSHIFT_NODEJS_DIR=/var/lib/openshift/538f1c205004461655000227/nodejs/
and here's what I get for env | grep mongo:
OPENSHIFT_ROCKMONGO_DIR=/var/lib/openshift/538f1c205004461655000227/rockmongo/
PHPRC=/var/lib/openshift/538f1c205004461655000227/rockmongo/etc/conf/php.ini
OPENSHIFT_ROCKMONGO_IDENT=redhat:rockmongo:1.1:0.0.12
OPENSHIFT_MONGODB_IDENT=redhat:mongodb:2.4:0.2.11
OPENSHIFT_MONGODB_DB_URL=mongodb://admin:PASSWORD_HERE#127.10.37.130:27017/
OPENSHIFT_MONGODB_DIR=/var/lib/openshift/538f1c205004461655000227/mongodb/
Just in case someone else stumbles upon this problem, here is what I had to do.
I created separate file config/application.js, and there I placed
module.exports = {
port: process.env.OPENSHIFT_NODEJS_PORT,
host: process.env.OPENSHIFT_NODEJS_IP,
environment: 'production'
};
Also I found what was the problem with application not starting. Post-install was failing (bower install did not finish successfully). To fix it, one should add to scripts section of package.json
"postinstall": "export HOME=/var/lib/openshift/[instance-id]/app-root/runtime/repo; ./node_modules/bower/bin/bower install"

backbone boilerplate: How to start the development server

I've cloned Backbone boilerplate which comes with an example Todo app. I have also read that the boilerplate comes with a development server, but I don't know how to start it. In the tutorial, it says you can run this command
node build/server
but I get an error saying that it can't find the module /build/server
Can anyone explain?
If you've installed nodejs it should be as simple as changing directory to the root of the TODO application and running the following command (although you may also need to add the path to node to your environment settings):
bbb server
You should then be able to access the example on localhost:8000.
Just as an FYI, you can change the server values in grunt.js to run bbb on a specific host and port.
server: {
host: "10.111.X.1", port: 3303,
...
}

Resources