I have a docker-compose file that builds two basic application. A front-end with angular and a backend with adonis.
version: "3.9"
services:
backend_login:
build:
context: ./apis/apis/login_api
ports:
- "3333:3333"
sendit_frontend:
build:
context: ./frontend/frontend/external
ports:
- "4500:4200"
depends_on:
- api_backend_login
When i run the docker-compose up the two applications go up and they work in their respective ports. The problems comes when i call the api from the front-end app using the name of the service (in this case backend_login).
I attached my terminal to both containers and did a telnet test between them, they seems to work as the y resolve the name and connect to the respective ports
Finally, i discovered that the front-end app, when is called from firefox, tries to resolve the name using the host dns and not the internal docker dns.
Now i don't know where is the problem, if it is in the code or in the way that i build the container.
Edit: I realize that the app is running in the browser of my host machine (i'm a newbie with containers) and obviously it uses my host DNS.
Is there a way to workaround this?
CodePudding user response:
docker compose sets up a docker network for all services inside the compose file that allows it to instrument the DNS rules you're talking about, but only from service to service. As you noted, your Angular application is technically "run" from the browser (e.g. Firefox) which means it's not inside the network.
There's not a practical way to run SPAs or static sites like Angular from inside the container environment, but the simple way around your problem would be to point the frontend to http://localhost:3333
. You've mapped the port to the host so it should be available from the host network directly.
Note: this will be a problem for prod when you get there too. SPAs and static sites can be tricky when it comes to dynamic backend addresses. Most SPA frameworks recommend that you re-build the app every time you deploy to a new environment so that the backend address can be built into the artifact, but that tends to be at-odds with container-centric development which tend to maintain the philosophy of "build once, deploy anywhere".