Foreground Needs#
Since the explosion of the internet at my friend's house, you had to move the front end and API to the same machine.
But one day, when using someone's mysterious device to access, an error occurred saying "Access denied or API service problem". I thought it was probably because the User-Agent carried by the front end when accessing the back end was from the client, or it was a problem with the IP passed to the CDN when the front end accessed the back end, which perfectly triggered the interception of my abstract WAF.
So, when the front end accesses the back end, it needs to go through the CDN first, and then the CDN comes back to the back end. Since they are on the same server, why take such a big detour? Thus, this article was born.
Bandwidth Saving#
Map the /etc/hosts file of the host machine to the Docker container.
Problem Analysis#
Since both the front end and back end of Mix-Space can be run using Docker, for the sake of convenience, I ran both of them using Docker.
The API of the front end is provided by NEXT_PUBLIC_API_URL in .env, which is the most important part.
In the Docker container, 127.0.0.1 refers to the current container itself. Of course, there is only one front end running in the front end container and no back end, so it cannot be set to 127.0.0.1.
Then, why not set it to the IP of the back end container? In some scenarios on the front end page, this URL needs to be used in plain text. Therefore, it is not practical to directly set it to the internal network address on the server and allow users to access it. So, this solution is not feasible.
Someone suggested putting both containers in the same network, which would indeed make access more convenient. However, going back to the previous problem, this solution is also not feasible.
Since using IP is not feasible, we can use a domain name. We can fix the domain name to the IP of the target container.
However, it seems that the IP of the container changes every time it restarts (？). But the gateway of the docker bridge network always points to the host machine. Therefore, we can map the port of the web service in the back end container to the host machine, and then use nginx to reverse proxy to port 80. Then, point the domain name on the local machine to the IP of the bridge. This way, we can achieve two goals at once (I'm sure).
Solution Process#
First, we need to find out the gateway of the docker bridge network.
Enter ifconfig in the server terminal, and then look for a network card called docker0. That's it.
Then, the corresponding value of inet (which is 172.17.0.1) is the gateway.
You can test it with curl. I ran an nginx on the host machine, and the result of curl is the default page of nginx, which means that this address does point to the host machine (of course, the port of the back end is also accessible through curl).
Then, the first thing I thought of was modifying the /etc/hosts file of the host machine to point the domain name of the back end to this address.
Then, I tested it in the container, but this thing doesn't use the hosts of the host machine at all...
At this point, there are two solutions.
1. Force IP resolution through local DNS#
Actually, you can do this with custom rules in ADGuard Home.
For details on how to set it up, please refer to this article.
Since I don't use this DNS, let's move on to the second solution.
2. Map the hosts file of the host machine to the Docker container#
Add the following line to the docker-compose.yml file of the front end container:
volumes:
- /etc/hosts:/etc/hosts:ro
To prevent the container from making unauthorized changes, it is mounted as read-only.
Then, restart the container.
Go back to the container and test it.
Great, the problem is perfectly solved.
Afterword#
This article is a bit cumbersome, aiming to record the abstract problem encountered.
If you think my ideas are helpful to you, please feel free to like, share, and bookmark, and consider giving me a tip. Thank you, meow.
This article is synchronized updated to xLog by Mix Space
The original link is https://blog.nekorua.com/posts/maintain/121.html