search

will-moss / isaiah

Self-hostable clone of lazydocker for the web. Manage your Docker fleet with ease
MIT License
86 stars 3 forks source link

Support multi-node environments #1

Closed vutsalsinghal closed 5 months ago

vutsalsinghal commented 5 months ago

Hi,

Lazydocker is great and I have also always wanted it over web so thanks a ton for this 🙏🏼 !!!

Does isaiah support or plan to support multiple hosts? For example I've 3 raspberry pis in my home VPN and I would like to deploy isaiah to one of the rpi but manage containers on all Rpis. I use dozzle for container logs and this feature was added to it not too long ago - https://github.com/amir20/dozzle/issues/1608 (both isaiah and dozzle are implemented in Go).

will-moss commented 5 months ago

Hi !

I'm very happy to inform you that I have been working on this feature for the last few weeks, and I am in the testing phase. So far, everything seems to work correctly, with all the functionalities available and implemented in a multi-node setup.

The way it works right now on my local development environment is : The Master node acts as a gateway between the web client and the Agent nodes. Every request meant to be sent to an Agent node is first sent to the Master node, which forwards it to the designated Agent node. When the Agent node has finished processing their task, they reply to the Master node, which forwards the response back to the web client.

For example, let's assume :

I chose this implementation as it allows for exposing only one service while being able to manage multiple nodes. The other good news is that, when configured as an Agent node, isaiah doesn't even start a server. As a result, it makes the node (theoretically) unattainable / unattackable from the outside.

Eventually, you can expect the multi-node feature to be released next week. Everything is already done really, I just need to do more testing as I'm afraid to deliver half-baked features.

vutsalsinghal commented 5 months ago

Perfect! Love it ❤️

But could you expand more on this pls

when configured as an Agent node, isaiah doesn't even start a server. As a result, it makes the node (theoretically) unattainable / unattackable from the outside.

Q. Will there be a hub spoke model of isaiah? 1 hub and multiple spokes?

Ideally there shouldnt be a need for installing anything on B,C. Just by passing apt docker host to the docker command, you can manage B,C from A.

will-moss commented 5 months ago

Sure !

When configured as an Agent node, isaiah performs the following operations :

Because it is the Agent node initiating the connection with the Master node, it is not exposed and doesn't have to! That said, in that setup, you will indeed have to install isaiah both on the "Agent" machine and on the "Master" machine.

Regarding the hub spoke model, I had never heard of that model before! Thanks a lot for teaching me something new. I had thought of that implementation before, and decided to discard it as I thought that it would be very risky to expose a Docker host on the web. In my understanding, what you describe implies that the Docker daemon is publicly exposed, making it accessible for isaiah to control. If my understanding is wrong, let me know!

Ultimately, now that I think of it, I can imagine many scenarios where it wouldn't be "so" risky to expose Docker (using a reverse proxy with authentication, or staying inside a private network, etc.). It shouldn't be too hard to implement, and I think I'll be able to make it happen after next week's release.

vutsalsinghal commented 5 months ago

hi @will-moss

Thanks a lot for the lucid explanation 🙏🏼

No, I'm not implying exposing docker daemon over internet. All my services on the homelab are behind Authentik and Nginx proxy.

As I mentioned in my first comment - home VPN (virtual private network). I use docker-socket-proxy to selectively expose certain docker APIs to manage container on my VPN via portainer. Dozzle also use the internally exposed docket host endpoints to display logs. That way you dont need a constant websocket connection between agent/server or even need to install anything on agent VMs. I would prefer this as there is less overhead.

There is nothing wrong with your current approach... Like they say - more than one way to skin a cat 😉

will-moss commented 5 months ago

Hi,

Thanks a lot for clarifying!! And thanks also for making me discover those awesome projects.

I think I'm getting it now, and everything's clear. You can expect an alternative implementation of the multi-node support in the coming weeks as I find time to work on it.

On another note, I have just released the first implementation, and it is available as of today!

I will update this Github Issue as I progress on the second implementation.

Thanks again for taking the time to explain 👍 👍 👍

will-moss commented 5 months ago

Hi,

I finally found the time to implement and release support for multi-host deployment !

The new version is available, and the documentation was updated to explain how to proceed.

I hope this works out for you, and I'll close the issue unless you encounter any inconvenience while setting that up!

Let me know, and thanks again for opening that issue, ultimately leading to this awesome feature.

vutsalsinghal commented 5 months ago

Awesome! Thanks a lot Will. I'll give it a try.

Quick questions

  1. I noticed that you used scratch as base image in Dockerfile, whats the primary intention for that? size?
  2. For multi-host approach, where should I mount the docker_hosts file on the container? I think its in the root dir (based on the Dockerfile). Pls confirm

EDIT: ok for no.2 I was right. I'm able to get it up and running and its working as expected! Love it ❤️

vutsalsinghal commented 5 months ago

I've been using it for sometime now and abs love it - super small footprint (<10MB RAM usage for me). Amazing job 🍾 🙏🏼

will-moss commented 5 months ago

Thanks for your feedback, and I'm glad it works!

For future readers, just in case :