I have two Docker containers, one running a React app (built using create-react-app) and another with a Node app API. I have a docker-compose file set up, and according to the documentation I should be able to use the names of the services to communicate between containers.
However, when I try to send a request to the /login endpoint of my API from the React app I received a net::ERR_NAME_NOT_RESOLVED error. I'm using Unirest to send the request.
I've done a bunch of digging around online and have come across a few things describing similar issues but still haven't been able to find a solution. When I run cat /etc/resolve.conf (see this issue) in my React container the container with my API doesn't show up, but Docker is still fairly new to me so I'm not sure if that's part of the issue. I've also tried using links and user-defined networks in my compose file but to no avail.
I've included gists of my docker-compose.yml file as well as the code snippet of my request. Any help is much appreciated!
docker-compose.yml
Unirest request to /login
As discussed in the comments on the original post this was a DNS issue. Configuring the DNS was a little to involved for the use case of this project, so I've solved my problem by using an environment variable to set the URL that is used to make calls to my API container based on whether I'm running on a dev or prod environment:
(process.env.REACT_APP_URL_ROOT || '/app')
I set REACT_APP_URL_ROOT to my localhost address when running locally, and have an nginx container configured to proxy to /app when I build and deploy the React app.
Related
A developer working in Cebu City, Philippines is receiving frequent networking errors using a common configuration between Firebase and Create React App. We use firebase serve to start a local server for static assets in one terminal window. It starts up:
i hosting: Serving hosting files from: build
✔ hosting: Local server: http://localhost:5000
In a separate window, we run yarn start on a Create React App repo with a "proxy": "http://localhost:5000", entry in the package.json file. We frequently observe the following error:
Proxy error: Could not proxy request /__/firebase/8.1.2/firebase-app.js from localhost:3000 to http://localhost:5000. See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (HPE_INVALID_CONSTANT)
with ERR_STREAM_WRITE_AFTER_END exceptions killing the Create React App process.
Note: occasionally the error does not occur.
I can't replicate this problem in the US. With all of the software configurations I can think of being equal, I suspect there might be networking issues in the way as the firebase server does its Reserved URL "magic".
Do you think I'm on the right track to suspect a networking problem? If so, can anyone assist with lower-level networking config that might alleviate the problem? (I'm thinking connection/timeout adjustments).
If you init your project from hosting URLs in public/index.html (like me), try to update URLs to the latest version (8.2.3), so all scripts would look like this:
<script src="/__/firebase/8.2.3/firebase-app.js"></script>
This is what worked for me. I hope so :)
I have a ReactJS project with its own Dockerfile, exposing port 3000:3000.
I also have a PHP project with its own Dockerfile, exposing port 80:80. The PHP app also has containers for MySQL, Redis and Nginx
For the PHP app, I have a docker-compose file that creates a network (my-net) for PHP, Nginx, MySQL and Redis to communicate on. However, I now want the ReactJS (which is in a separate project) to be able to communicate with the PHP app.
I added a docker-compose file to the React project, and added it to the network from the PHP project my-net and declared it as external so that it doesn't try to create it.
This seems to work: From the ReactJS container, I can ping app (the name of my backend service) and it works properly. However, from the ReactJS code, if I use something like axios to try and hit the backend API, it can't resolve app or http://app or any variation. It can however access the underlying IP address if I substitute that into in axios.
So there seems to be some issue with the hostname resolution, and presumably this is on the axios / JavaScript end. is there something I'm missing or a reason this isn't working?
When the JavaScript runs in a browser (outside of Docker) you can not use app because that is only available inside the Docker network (via the embedded DNS server).
To access your PHP server from outside use localhost and the exposed port (80) instead.
I am trying to get a streaming service running from a modified version of an open source repo https://github.com/nabendu82/streams.
I have a frontend client in React, a RTMP server for the stream, and a backend API. I have got a docker compose file to host them all together. If I run docker-compose up on my local computer, everything works perfectly. I can visit http://localhost:3000/matches/view and see two stream windows that aren't loaded, until I open up the streaming software OBS, Settings -> Stream -> Server: rtmp://localhost/live, Stream Key: 7. Then the right stream window will start.
To host this repo on the internet, I've created a basic EC2 instance on AWS (http://13.54.200.18:3000/matches/view). I installed docker-compose and I've copied all the repo files up to it.
However, when running on the AWS box the stream does not load, and the console error is always the spectacularly unhelpful:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://server:3002/streams/6. (Reason: CORS request did not succeed).
So for some reason CORS is preventing the React frontend from reading the server backend while it is hosted on AWS.
Here is the catch. I can actually get the streaming on the AWS hosted site to work, but only by running docker-compose up on my LOCAL computer at the same time. For some unknown reason, the AWS hosted version is able to pick up on the backend server running on my local machine (rather than the one running alongside it in docker-compose on AWS) and connect that way. I can even stream to the website via OBS at rtmp://13.54.200.18/live and everything works. But it only works on exactly my local computer running the docker-compose infrastructure (and only if I use calls to 'localhost' instead of the docker-compose service 'server'), if anyone else tries to see the stream on the live site they will just get Loading... perpetually and the CORS error.
Why is the AWS hosted code not looking at its own docker-compose file and its own server:3002 service? For the rest of the world, and for me if I'm not running a local server, it throws a CORS error. For just my local computer, and only if I'm running a local server and making requests to 'localhost:3002', it works perfectly.
If I ssh on to the AWS image, then docker-compose run client curl localhost:3002/streams will fail, but docker-compose run client curl server:3002/streams will give me back the correct JSON data. From everything I understand about docker compose, my services should be able to access each other and it appears they can, everything works great locally, and the services can talk to each other on the AWS box too, but just somehow this CORS error appears out of nowhere only on the AWS hosted version.
I've tried everything under the sun I can think of. I was originally using json-server, but I thought that might be the issue (as it has to specifically bind to -H 0.0.0.0), so I wrote my own Express server using the cors package to replace it and there has been no change. I've tried every configuration of docker-compose variables I can imagine. As far as I can understand I've done everything right, but somehow the AWS box wants to talk to my own computer's localhost aka "server service" aka 0.0.0.0 instead of its own. What is going on?
Repository here: https://github.com/JeremyEllingham/streams
Any help much appreciated.
I figured out how to get it working, by just posting direct to the Linux box IP address in production instead of trying to get it working with "localhost" or the docker service names. Kind of disappointed that docker-compose doesn't seem to work quite like I thought it did, but it's totally functional to just conditionally alter the base URL.
See also this answer: React app (in a docker container) cannot access API (in a docker container) on AWS EC2
I've created a docker image and added it to the Azure Container Registry. I've then deployed it to a Web App but am having trouble accessing the site. When I browse to it loads for a long time (minutes) and then get a 503 error 'service unavailable.
I thought it might be a port issue as my docker file has:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 15973
EXPOSE 44369
And have added the following key/value pair to the app settings: WEBSITES_PORT: 15973 but still doesn't return anything.
I thought that I'd go back to basics and use the quickstart from the web app for containers (appsvc/sample-hello-world:latest) but that does the same, can't actually start the app.
What could be the issue? Should it be as simple as point it to an image to get a website up and running? Is there another public template I can use as a basic image to see a container runnning?
Update
So I've tried running the image locally a suggested by #Charles. When it starts it definitely runs as if I don't pass environment variables (such as connection string) then I get the related error message.
The issue running locally is that after it's started I'm not sure how it's exposed. I've tried http://localhost:15973, http://localhost:44369, http://localhost/ and tried passing -p 8080:80 and then http://localhost:8080 but they don't don't respond.
The response of starting the image is:
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:80
I think that this is the problem with it being hosted in Azure as well, the requests aren't being routed through to the image.
What do I need to do to call the api in the image?
For your issue, I try a test about Azure Web App for Containers and follow the steps in Deploy a Docker/Go web app in Web App for Containers. It works well.
So, I suggest you can test your image on your local machine first. If it can work as you want on your local machine.
Hi Im running my frontend (create-react-app) and backend server (express.js) on different ports but on the same host.
For example: frontend is on 127.0.0.1:3000 and backend on 127.0.0.1:3003.
in my package.json:
{...
"proxy": "http://localhost:3003",
...}
Everything worked fine till I didn't migrate my app to remote server.
My app started to refresh unexpectedly when I'm trying to send http request (axios) to server (probably due to bad proxy settings).
So I have frontend app running on 35.125.320:10:3000 and server is running on 35.125.320:10:3003. My http requests was unexpectedly cancelled. (I checked the network ). So I changed my proxy settings to
{...
"proxy": "35.125.320:10:3003",
...}
but anyway my app is still refreshing when Im trying to make http req. on server. I think the problem is that I can't reach my express backend server. So proxy is forwarding my requests badly.
UPDATE
scenario:(Im doing two post requests)
1) first request still passed (app is not refreshed)
2) same request passed (but sometimes app is refreshed)
3) second is still cancelled by browser.
QUESTION
How can my frontend communicate with backend server via proxy when they are running on different ports but on the same server and domain ??
Thanks for the answer.
Solution:
The problem was that I used proxy in production that is only suitable for development.
I added this line in my express.js server :
app.use(express.static(`${process.cwd()}/build`));
app.use(express.static(`${process.cwd()}/public`));
I make a build and serve js,css files from my build folder. And also I needed serve static files (images, folders, etc...) from my public folder.
This problem can also cause cancelling http request by browser on production. Means, requests weren't able to reach server.
To make your app publicly available, you will want to make a production build. You mentioned in a comment that you "run npm build and then serve this build as static file in express.js". This is a great way to make your react app publicly available. As it says in the create-react-app documentation:
npm start or yarn start
Runs the app in development mode.
When running yarn start or npm start, you are also given a notification that says "Note that the development build is not optimized." The best option will be to run yarn build or npm build and find a way to serve those static files as you are doing.