Introduction#
Some time ago, I came across the project RSSerpent/RSSerpent, which is similar to RSSHub and uses Python. Unlike RSSHub, which requires importing each "rule/route" in the code file, RSSerpent adopts a "plugin/modular" approach.
Although the author finally added some plugin development documentation during the National Day, and even wrote two rules after overcoming the hurdle of "environment configuration" (one of which is for the official route), it seems that while it is possible to fetch and output RSS content during development and debugging, it cannot be used when actually deployed -_-!
After all, it is a new project, so let's wait for it to be improved slowly.
On the other hand, RSSHub is sufficient for my needs. The biggest problem is not the rules, but the availability of instances - for example, if an instance goes down completely or if a certain rule is no longer available on that instance - even if you self-host, you cannot avoid it.
(Yesterday, I found that the certificate for rss.shab.fun had expired, but I just checked and it was quickly renewed.)
Although I check it every day, it requires a high level of sensitivity to notice when a subscription hasn't been updated for a long time.
Indeed, the best solution so far is this:
Exploring GitHub Actions Reverse Proxy RSSHub + Multiple Instance Polling_Computer Networking_沉冰浮水
However, it was unexpectedly affected by the following reasons before:
A Minor Thing: Python Docker Image Update_Miscellaneous_沉冰浮水
(It seems that it always turns into a ramble.jpg)
Main Content#
The reason for this article is that I worked on the following:
wdssmq/proxy_nginx: Nginx Docker image suitable for reverse proxy:
↑ Although it is a code repository, it feels more like a tutorial after finishing it, and it also includes a Git repository.
The README.md contains many notes on deploying Nginx in a Docker environment, as well as how to customize various related configurations in /etc/nginx/ through mapping, and also how to configure SSL certificates.
A previous article that has already been covered:
Pseudo-Static Related to php-nginx Inside Docker_Computer Networking_沉冰浮水
Then I realized that including "Nginx reverse proxy configuration" would make it very long. "- Although it's also long when separated here.jpg -"
Requirements:
I have already deployed an RSSHub instance using Docker, running on the default port 1200, and I want to deploy a separate Nginx container for reverse proxy.
The image is based on webdevops/php-nginx:7.4 and extracts /etc/nginx for custom mapping.
There are quite a few preset files, including many that have been deprecated but not deleted. After sorting out the relationships, the following conclusions were drawn:
Files in nginx/conf.d/ are used to place files that need to be globally included or written outside the port listener.
nginx/vhost.common.d/*.conf are included inside the server {} for both 80 and 443.
Actually, the main purpose is to achieve reverse proxy for multiple RSSHub instances, but it seems that the design does not support the usage I envisioned.
Write the following configurations according to the paths:
#; nginx/conf.d/5-proxy.conf
upstream rss1200 {
server getrss2021.xyz:1200;
}
#; nginx/vhost.common.d/5-proxy.conf
location /rss/ {
proxy_set_header Host $host/rss;
proxy_pass http://rss1200/;
}
The containers are isolated from each other, so you need to ensure that *:1200 is accessible or add the containers to the same network and use the container name for addressing.
Afterwards, map it into the Docker container or restart the existing container.
Now you can access the RSSHub instance I built using https://getrss2021.xyz/rss/.
Conclusion:
In fact, for the current example, the upstream module is not necessary, but it is not practical to turn everything "possible" into a process.