Add Nginx Reverse proxy #174
Conversation
Gitea is a lightweight implementation of a Git server. Makers who are already running a local IOTstack server may prefer to commit their work to a local repository running on their Raspberry Pi, rather than GitHub/GitLab/etc. Implementing Gitea under the IOTStack umbrella inherits the existing IOTstack backup mechanisms for free. Candidate page for the wiki at https://www.dropbox.com/s/onqndgyamo2h74i/Gitea.md.zip?dl=1
Route filter.acl to add the option in mosquitto/mosquitto.conf of filtering wich topics can be read or writen by defined users.
Added the file where the user creates filters. The example filters don´t affect usage in any way.
Version "2" of the docker-compose.yml cannot use "Healthcheck" instructions. Only 2.1+ can do this. I propose we upgrade the version to at least 3 so we can incorporate HealthCheck commands and any other new features as appropriate. We're running the latest version of docker - the latest version of the docker-compose.yml is 3.7 - unless there's a really, really good reason to use an older format of the docker-compose.yml, can we please update it to at least 3.0, preferably 3.7?
s/restart you device/restart your device/
|
I have submitted this PR on your behalf over at the fork: SensorsIot#1, If you would like to have your name to the commits, please submit the PR there and let me know so I can remove the PR I created on your behalf. |
Added Mkdocks action and github pages intergration for the documentation.
menu.sh: Fix small typo in msg "Restart Required"
Changed each menu item to be on a separate line to make merges easier.
Update menu.sh
Adds a Gitea container to IOTstack
Updated readme with quick install instructions so people don't have to dig for it in the documentation.
Update README.md
Mosquitto changes update to security
Hi robert, I've tried to bring your changes to my personal fork of IOTstack and have them running. After I got the script to generate the entries for the containers you added, I don't see the nginx configuration being generated anywhere, so I was wondering if there is something that needs to be done in order to generate the config correctly. |
|
I've been watching your PR638 on the SensorsIot/IOTstack repo. I'm going to make some more comments there in a bit. I'm assuming the reason why you've posted this message on gcgarner/IOTstack is because @robertcsakany started working on an nginx proxy here on gcgarner before this repo (gcgarner) was forked to SensorsIot after Graham Garner stopped responding.
PR174 on gcgarner (this PR) was inherited by SensorsIot as PR21 but it is in the same state of having conflicts that must be resolved. The point I'm trying to make is that this repo (gcgarner) is effectively abandoned so it is highly unlikely that anything you do here will get anywhere. On the other hand, because PR21 on SensorsIot hasn't moved in a very long time, it's probably reasonable to conclude that it is also unlikely to go anywhere. I'll now move to your PR638 and continue my comments there. |
Add support of nginx reverse proxy. It tracking all container where VIRTUAL_HOST env is defined,
automatically generate nginx proxy config for it.
As described in https://github.com/nginx-proxy/nginx-proxy. We use separate containers.
The HTTPS implementation as documented here: https://medium.com/@francoisromain/host-multiple-websites-with-https-inside-docker-containers-on-a-single-server-18467484ab95
By default the xip.io is used to be able make subdomains for IP address. So for example the nodered service can be accessed:
nodered.X.X.X.X.xip.io
where X.X.X.X is the IP address of IOTstack.
Any other domain can be used, on that case please replace VIRTUAL_HOST env variable of the given instance with the coresponding value.
HTTPS can be used, but xip.io method is not suitable for that, so as the links describes any container can be exposed with the definition of HTTPS proto, but some domain have to be defined.