I am working on containerizing one react app & provision it using ECS cluster with alb.
Everything looks great but whenever I accessing the ALB DNS in the browser it returns an empty page with 2 words only "react app"
I checked health check all the backend instances are healthy and returning 200 code.
I have used the ec2 instances IP address in the browser and the page loaded completely.
It seem issue with the alb, why not loaded the complete page
It should be a problem on how you have configured the DockerFile.
You would have added some default route to nginx configuration which displays 'react app'.
To debug, please try to run the DockerFile from your local using Docker Desktop and see if you are able to browse the react app.
If it works fine in your local then for sure 100% it'll work in ECS without any problem.
Related
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 am trying to scale my express server that runs in a docker swarm.
when run my stack and there are 2 replicas of the express server on the same machine everything works fine, but as soon as i add another server to the swarm and my express app runs a container on each server then the issue begins.
The issue that I experience is:
POST REQUEST FROM UI
OPTIONS preflight is performed - gets 204 status code from my backend
the request hangs and the POST is not being sent.
What I have tried:
tried to see if it is something that has to do with CORS, but i don't think so because i have managed to make it work on one server which is also in a different origin from the frontend.
tried running the express application only on the worker node (the new node i added to the cluster), and it managed to get the post request to it.
tried running the application on the master node only - it worked.
both servers are behind a load balancer i created (don't know if that is an issue or not when it comes to express)
both servers run on EC2 instances on aws
base image - node:8-alpine
express version : "express": "^4.17.1",
After a while i found out that the issue was that i didn't run swarm on the public IP of both of the ec2 instances.
make sure that when you initialise swarm that you listen on the public ip of the server.
docker swarm init --advertise-addr <public ip>
same thing for joining the swarm.
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.
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.
I built a Meteor app and would like to run it on Google Compute Engine. I followed the guide found here to get a basic instance of my app up and running, changing the disk size/type, the instance type, the disk and instance zones (to both match where I live), and added export METEOR_SETTINGS={ ... } to the second to last line of the startup.sh file.
Everything seemed to work fine, I have the persistent disk and vm instance listed on my Google Cloud dashboard. I created a new firewall rule on my default network to tcp:80 and tcp:443 incoming traffic, and now when I access the instance's external IP address from my browser, I'm shown a 502 Bad Gateway nginx/1.8.0 page (where I'd instead expect the homepage of my Meteor app).
Is there anything in the configuration details in the startup.sh file that I'm missing or should modify? Could there be an issue with how the compute vm instance is communicating with the persistent disk? Frankly I'm far outside of my domain with this type of thing.
After ssh-ing into my instance and dinking around a bit, I called export ROOT_URL='<the_instances_external_ip>', rather than 'http://localhost', at which point everything started to work. It's unfortunate how little documentation there is on getting Meteor apps configured and running in production (I only thought to mess with ROOT_URL after searching something unrelated), so hopefully this will at least be helpful for someone else.