Echolot

Members
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Echolot's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. See the exact same behavior on my 6.9.2 system... Would love to hear an explanation for what is exactly causing this.
  2. v1.5.0 was just released and adds the feature of stoping (and starting) multiple containers for each proxy host. This is especially useful if your application has multiple supporting containers (database, own reverse proxy, etc.).
  3. That is both good and disappointing to hear lol. Means we found a fix but also means that these editors first save an empty file and then save the correct edited file. The file changed event only gets emitted on the first save since there's an internal debounce logic in the library I use. I will push a small bug fix release in the next few minutes with this change.
  4. A small Update v1.4.0 was released, check the second post for the changelog. @guillelopez & @kjames2001 Could you try the config reload issue again with the dev-config tag? ghcr.io/itsecholot/containernursery:dev-config I added a small delay (500ms) after receiving a file change event before trying to read the config file. Maybe this fixes your issue? I sadly still couldn't reproduce this so it's impossible for me to test this on my own.
  5. I just tried this using VSCode as the editor on Mac with the container running, can't reproduce this. Do you maybe use a different encoding than UTF-8? Does the same config file that produces this error work after a restart of the container?
  6. I sadly can't recreate your issue, config reloading works just fine on my machines... Is there anymore detail you can provide?
  7. @guillelopez The fix to the bug you discovered, as well as the configurable listening port update was just released two hours ago. I also added the guide I mentioned to the first post. Let me know if somethings missing.
  8. @guillelopez This is actually a bug! Thanks for reporting this, will look into getting this fixed in the next few days. The port shouldn't be taken into consideration when examining the domain.
  9. @guillelopez So just to clarify, the ContainerNursery loading page gets displayed correctly when you visit filebrowser.rack but it just never displays the target application itself? This would mean that either the proxyHost and/or proxyPort configuration is wrong for this proxy host, or that no connection can be established between these two applications (ContainerNursery and FileBrowser for example). Using localhost as proxyHost is only correct if ContainerNursery is run in host networking mode, since otherwise localhost refers to the container and not the Unraid machine. It could be that because of your special network situation the two containers can’t connect to each other, maybe try to investigate more into that direction? You could try (not a permanent solution) to use the default bridge network for both Application and ContainerNursery and simply append the port when you open the url in the browser like so: http://filebrowser.rack:8080 Use the docker container settings to map the ContainerNursery port 80 to port 8080 for example. Then use the Unraid machine IP as proxyHost and the application port (which you have configured using the container settings, like for ContainerNursery) as the proxyPort.
  10. A guide is definitely something I thought about doing but haven't found the time yet to do, I will try to do it in the course of the next week. A pretty technical "guide" can already be found on the GitHub Project page in the Readme file. If you're using Docker Bridge Network you can map the port 80 easily to something other you prefer. Either way we're working on making the listening port configurable.
  11. Changelog 12.10.2021 - v1.5.1 Fixed a bug where the loading page wouldn't be displayed when a path other than `/` is requested. Thanks to @JamesDAdams on GitHub for the Bug report. 29.09.2021 - v1.5.0 Added the ability to stop (and start) multiple containers per proxy host. This is useful if the application supports multiple containers. The first container in the list is the main container, which is used to check if the container is ready and reload the loading page. For usage information check the README.md file on GitHub. 24.09.2021 - v1.4.2 Handle SIGTERM. The ContainerNursery container should now stop (and thus also restart) much quicker. 23.09.2021 - v1.4.1 Fixed an issue where certain editors broke the live config reload functionality by introducing a small delay before reading the config file. 23.09.2021 - v1.4.0 Added stopOnTimeoutIfCpuUsageBelow setting to proxyHosts which prevents ContainerNursery from stoping containers if they're still busy (using more CPU than the limit). For usage information check the README.md file on GitHub.
  12. Overview: Puts Docker Containers to sleep and wakes them back up when they're needed. Written in Node.js, this application acts as a HTTP reverse proxy and stops Docker containers which haven't been accessed recently and starts them again when a new request comes in. ContainerNursery also makes sure there are no more active WebSocket connections before stopping the container. To improve the user experience a loading page is presented, which automatically reloads when the containers webserver is ready. GitHub: https://github.com/ItsEcholot/ContainerNursery GitHub Packages: https://github.com/ItsEcholot/ContainerNursery/pkgs/container/containernursery This application is currently in beta! Please report any problems / issues / suggestions in this thread or alternatively using GitHub Issues. Quick Demo: Setup Guide: There are multiple ways to setup and use ContainerNursery depending on your use case and network setup. In this guide I want to give a quick overview which choices have to be made and to present a non exhaustive list of possible solutions for each choice. More information can be found in the README.md file on the GitHub Repo. DNS: Since ContainerNursery is a reverse proxy it will use the host header of the request to decide where the request should be routed to. This means we have to reach CN using a domain name and can't simply use an IP + PORT combination. So you have to find a way to route multiple domain names to the same IP (probably the Unraid IP since CN is running as a Docker Container on that machine). Hosts File: Edit the local hosts file on your device. Your OS uses this file to resolve domain names to IPs. This file is located at /etc/hosts on Linux and MacOS and at C:\Windows\System32\drivers\etc on Windows. Add an entry for each application you want to proxy through ContainerNursery. Example: 192.168.1.2 my-important-app.unraid 192.168.1.2 handbrake.apps.unraid 192.168.1.2 speedtest.apps.unraid In this example 192.168.1.2 is your Unraid (and thus ContainerNursery) IP and the names are freely choosable domains. DNS Server: You can also use your local DNS server to define new domains and point them to your ContainerNursery IP. While more complicated this approach allows all devices which make use of your local DNS server (if you announce it using DHCP, probably all your network devices) to access your apps using the defined domains. Your DNS server could be a PF/OPNSense box, your modem (if it allows adding manual DNS entries) or a dedicated DNS server application like PiHole for example. Since all this sub-methods are configured differently, DuckDuckGo (other search engines are available) is probably the best way to figure this one out by yourself. Ports: By default ContainerNurser is setup, like most reverse proxies, to run on port 80 since this is the default port for HTTP requests. This way you don't have to append a port to the domain name when trying to access your applications. Since port 80 is also used by Unraid to serve it's Webinterface you basically have two options: Change Unraids Webinterface port This is the preferred method since it allows using all your other applications like you would expect them to, i.e without having to append a port to the domain name. This can be accomplished by navigating to the Settings > Management Access page and changing the HTTP port value to something other than 80. 8080 would be a great candidate, since it's easy to remember. This means that from now on you would have to access your Unraid WebUI (only if you don't use https) using the following URL: http://<yourunraidip>:8080 This method also means you could deploy CN using host networking instead of bridge, however I don't recommend this, since the useful isolation layer between host and container is then not used. Change ContainerNurserys port This can be easily done by editing the CN container and making sure you're using bridge networking and maping the port from 80 to 8080 for example. If you use this way the Unraid WebUI will still be available like usual, but all your services have to be accessed with this port appended, for example: http://hanbrake.apps.unraid:8080 Networking: Since you want to use ContainerNursery to proxy your requests to your applications, CN will have to be able to access your other containers. The approach here depends on how your other apps and CNs network is configured. Custom bridge network This is the most elegant solution in my eyes. Custom docker bridge networks allow you to specify which containers should be able to access this network and communicate with each other (without having to map any ports) and most importantly allow you to use the name of the container as a hostname. Docker will then automatically resolve the correct container IP address for you. Using this approach dramatically reduces the attack surface, since less ports are open on the Unraid Host itself. To use this approach open up the Unraid Console using SSH or the WebUI and run the following command, creating a custom bridge network with the name proxy: docker network create proxy Now edit all your applications, which you want to access through ContainerNursery and change the following option: Network Type --> Custom: proxy You can (and should) now remove all port mappings (hint: make a note of what port the app uses inside the container, since they're not always the same), since you will only be accessing the app through the domain (and CN as a reverse proxy) instead of the raw IP + port combination. Make sure ContainerNursery itself is also switched to using your newly created docker bridge network but keep the port mapping (change it to your desired value if needed, see the part about ports above) since we need to be able to access ContainerNursery from other machines so that it can route our requests to the desired containers. Now you can configure ContainerNursery like in this example: proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: handbrake proxyPort: 5800 timeoutSeconds: 14400 Since we use a custom bridge network which translates the container name to the correct IP address we can use handbrake as our proxyHost value. The proxyPort value is the internal port (the port the actual application inside of the container listens on) of the target container since containers of the same bridge network can communicate freely with each other without any port mapping taking place. Default bridge network If you want to use the default bridge network docker provides you will have to map ports on both ContainerNursery and the container you want to access and then use a configuration like in this example: proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: 192.168.1.2 proxyPort: 6800 timeoutSeconds: 14400 192.168.1.2 is the IP of the Unraid machine and the port 6800 is the mapped port of the handbrake container. Host network The same rules as for the default bridge network hold true but now localhost can be used inside the config, since localhost now refers to the Unraid machine and not the CN docker container. proxyHosts: - domain: handbrake.apps.unraid containerName: handbrake proxyHost: 127.0.0.1 proxyPort: 6800 timeoutSeconds: 14400