Nginx ssl certificates broke client/server communication?
Running Docker container with docker compose on digital ocean droplet.
Containers:
- wasp client (8043:80)
- wasp server (3001:3001)
- fastapi web (8000)
- redis (irrelevant for this, i think)
- background worker (also irrelevant)
- nginx (maybe super relevant? 80:80 & 443:443)
app deployed just fine, everything talked to each other and life was great until I certbotted ssl certificates and plugged them into nginx. Now all of the sudden nothing is talking to anything else. I suspect this is maybe a global middleware misconfiguration but do not have more than around a month or two's worth of experience in wasp so was hoping someone who knows a little bit more than I do might have an idea of what might have happened. Lmk & thx.
18 Replies
Hi @Wlski. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. The knowledge sources provided do not contain specific information about the interaction between Wasp, Docker, Nginx, and SSL certificates.
However, it's worth noting that Wasp applications consist of a client and a server, which communicate over specific ports. If these ports are misconfigured or blocked due to changes in your Nginx configuration or SSL setup, it could potentially disrupt the communication between the client and server.
You might want to check your Nginx configuration and ensure that it's correctly routing traffic to your Wasp client and server. Also, ensure that your SSL certificates are correctly installed and that your Nginx configuration is set up to use them properly.
For more information on deploying Wasp applications, you can refer to the Wasp deployment documentation (https://wasp-lang.dev/docs/advanced/deployment/manually#3-deploying-the-web-client-frontend).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Wlski, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
1. I'd probably not map the client from 8043 to 80 directly but rather just keep it at 8043:8043 - the reason is because you want nginx owning 80 and 443 and if the container binds 80 directly, nginx can't have access to it. Once you do that, set up nginx to reverse proxy to 8043 for the client.
2. Make sure certbot is not running in the background somehow?
3. Check who is listening to various ports you listed -
netstat -tulpn | grep ':<port>' (https://www.cyberciti.biz/faq/unix-linux-check-if-port-is-in-use-command/)
4. Try pinging the services locally with curl localhost:8043 and see what kind of responses you get.
5. Did you run the containers inside of a docker-compose.yml file or one by one?
6. Check if all the container are on the same network? (https://stackoverflow.com/a/43904733)Stack Overflow
Docker : How to find the network my container is in?
I am trying to understand few things about Docker:
How can I find the network my container is in ?
Can I dynamically detach my container and attach on an other network ? How?
If I have two contain...
I think I'm starting to get the hang of it. is WASP_SERVER_URL the same as REACT_APP_API_URL?
and yeah docker-compose.yml is what I'm using
just troubleshooting weird issues with nginx rerouting my api only sometimes. but is callable from curl to get to endpoints I want. So must be env vars issue
Wohooo @Wlski, you just became a Waspeteer level 1!
So must be env vars issueOk, let's figure it out then! 🙂 For the server:
DATABASE_URL, JWT_SECRET, PORT, WASP_SERVER_URL and WASP_WEB_CLIENT_URL are the most relevant ones.
On the server:
WASP_WEB_CLIENT_URL === where your client lives, important for CORS
WASP_SERVER_URL === where your API lives, important for OAuth and redirects
On the client:
REACT_APP_API_URL === should be the same as WASP_SERVER_URL, it's set when building the client e.g. REACT_APP_API_URL=https://api.bla.com npm run buildi know this might be a crazy ask but do you have a working nginx template for wasp frontend and backend?
I can't seem to get the api prefix working so I've reverted to trying to handle a /server/ workaround in the routing. naturally I don't think this was intended at all but since I could never get it set up I kind of gave up on it.
so in essence docker-compose.yml setting:
WASP_WEB_CLIENT_URL=https://domain.com
WASP_SERVER_URL=https://domain.com/server/
JWT_SECRET=[normal 32L string]
MAILGUN_API_KEY=[key]
MAILGUN_DOMAIN=mail.domain.com
PORT=3001
REACT_APP_API_URL=https://domain.com/server/
(before pulling from git I also run the wasp build/npm install script with this var)
Im also deploying directly to my owned domain. so when I say domain.com I mean I own that and need to correlate dns records. Which might mean somewhere I'm also having a firewall issue
apologies for how all over the place I am with this. first time deploying so still figuring things out
Update: Figured this out. It was another instance of nginx running on port 80 which initially didnt catch me off guard because I thought it was my docker container but turns out nginx was installed to run by default at startup. This came from using certbot to install ssl certificates.
Feel like an idiot. @miho thanks for the help though.
FYI that was one of things to check
Check who is listening to various ports you listed - netstat -tulpn | grep ':<port>' (https://www.cyberciti.biz/faq/unix-linux-check-if-port-is-in-use-command/)I'm glad it worked out in the end!
@Wlski if you might have some time for it, we would greatly appreciate if you can write down how you did the whole setup! It would be useful to other Wasp users. You can just create an issue on our Github with the instructions. Then we can take it from there and figure out if we will add it to docs or guides or somewhere.
@Wlski I'd love to hear how you ended up solving this! I'm running into similar problems right now, althought it's not an issue with another instance of nginx, it's more about how the ports are actually mapped in nginx and what ports are used on the server and api, especially for ssl!
@cmilazzo What are you deploying on
It's a RedHat EC2 instance on Amazon. I did end up figuring it out yesterday though. :).
Nice. Sorry—I'm relatively new to discord so I'm not around here often
Wohooo @Wlski, you just became a Waspeteer level 2!
Awesome! @cmilazzo same as for @Wlski , if you find a bit of time, we would appreciate you sharing with us and others how you did the setup, it will be helfpul for other people!
@martinsos . I'm writing it up as I go, but I continue to run into complications, so as soon as everything is working perfectly I'll share that!
Awesome, and we are here to help with any issues!
Use this with the client deployment script in the docs: REACT_APP_API_URL=https:/domain.com/server/ ./setup_client_deployment.sh
In your docker compose you set
wasp-server:
WASP_WEB_CLIENT_URL=https://domain.com
WASP_SERVER_URL=https://domain.com/server/
wasp-client:
REACT_APP_API_URL=https:/domain.com/server/
Nginx also needs to be defined here.
nginx.conf:
upstream wasp-frontend {
server wasp-client:8043;
}
upstream wasp-backend {
server wasp-server:3001;
}
location / {
proxy_pass http://wasp-frontend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /domain.com/server/ {
proxy_pass http://wasp-backend/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
It's a little more complicated than this but these are the key elements that could get you on digital ocean @martinsos
@Wlski nice trick putting the client and the server on the same domain and using a subpath for the server 🙂