Foreground Needs#
Since the explosion of the internet at my friend's house, the front-end and API that you stand on had to be moved 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 brought by the front-end when accessing the back-end was from the client, or it was because there was a problem with the IP passed to the CDN when the front-end accessed the back-end, and it perfectly triggered the interception of my abstract WAF.
So, when the front-end accesses the back-end, it needs to go to the CDN first, and then the CDN comes back to the back-end. Since they are on the same server, why go around such a big circle? So, this article came into being.
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 currently 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 there is no back-end, so it cannot be set to 127.0.0.1.
Then, can it be set 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, so it is not practical to directly set it to the internal network address on the server and then let the user access it. Therefore, this solution is not feasible.
Someone suggested putting both containers in the same network, which would indeed make access more convenient. But going back to the previous problem, it is not feasible.
Since IP is not feasible, we can only use domain names. So, we can fix the domain name to the IP of the target container.
But it seems that the IP of the container seems to change after each restart (？). However, the gateway of the docker bridge network always points to the host machine. So, 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, the domain name points to the IP of the bridge on the local machine, which can achieve two goals at once (I'm sure).
Solution Process#
First, you need to find out which is the gateway of the docker bridge network.
Enter ifconfig in the server terminal, and then look for a network card called docker0, which is it.
Then, the corresponding value of inet (which is 172.17.0.1) is its gateway.
You can test it with curl. I have an nginx running 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 after curl).
Then, the first thing I thought of was modifying the /etc/hosts file of the host machine to specify the domain name of the back-end to this address.
Then, test it in the container, but this thing doesn't even use the hosts of the host machine,,,
At this time, there are two solutions.
1. Force IP resolution through local DNS#
In fact, you can use the custom rules in ADGuard Home.
For details on how to build it, please refer to this article.
Since I don't use this DNS, let's directly look at the second one.
2. Map the hosts file of the host machine to the docker container#
Add a line to the docker-compose.yml file of the front-end container:
volumes:
- /etc/hosts:/etc/hosts:ro
To prevent the container from making random changes, it is mounted as read-only.
Then restart the container.
Then try it in the container again.
Okay, it's perfectly solved.
Afterword#
This article is a bit cumbersome and aims to record the abstract problems encountered.
If you think my ideas are useful to you, please feel free to like, share, and bookmark, and finally give a tip, thank you meow.
This article is synchronized with xLog by Mix Space
The original link is https://blog.nekorua.com/posts/maintain/121.html