As requested, I will do a write-up of the high-level architecture, and a list of features in phases.
In terms of security I think the command-line interface could be secured by definition since it will be only available on the prod environment (or qa, or test, or dev respectively). In prod I only use vlans. The whole set of machines is isolated from other network segments all the time. To access them the firewall only allows me to get into the machines through a specific port, but this will depend on the security on each environment. The web interface is probably a little bit different. We will probably like to allow users to connect remotely, but from a secured net segment only available though a vpn or similar. In any case, it will be available over HTTPS only and will need to have user/pass security at the very least. Other options can be considered. On the "Informing the LB question", the tool architecture as I see it will include "hooks" (related to events), so custom scripts could be added to suit specific needs of each installation/environment. This way the end user could the hooks to implement integration points to other systems. Vlad -------------------------------------------- On Wed, 5/6/15, Christopher Schultz <ch...@christopherschultz.net> wrote: Subject: Re: Tomcat Grid To: "Tomcat Developers List" <dev@tomcat.apache.org> Date: Wednesday, May 6, 2015, 10:11 AM Andrew, On 5/6/15 9:21 AM, Andrew Carr wrote: > I can see security of this tool being paramount. What if you had a large > cluster and someone else was able to manipulate it using this tool? If it's built on secure building blocks, such as public-key-based ssh authentication, or TLS client certificates, then I think it would be reasonably secure. Another option is a VPN or VLAN, or a separate physical network. We use the latter technique to communicate between our application servers and database servers to avoid the overhead of encryption. -chris > On Tue, May 5, 2015 at 4:50 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Chris, >> >> On 5/5/15 4:39 PM, Chris Aguirre wrote: >>> I actually use Windows Powershell to execute commands on remote machines, >>> including stopping/starting Tomcat (and other Windows Services). >>> >>> This works well for me - but in this case, I have complete control of all >>> the VMs - and they are not Production Servers. >>> >>> I used the following articles as reference for creating the Powershell >>> scripts: >>> >>> >> http://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/ >>> >>> >> http://stackoverflow.com/questions/6239647/using-powershell-credentials-without-being-prompted-for-a-password >> >> That's great. *NIX also has ssh which can be used to execute remote >> commands, but that's not the hard part. >> >> The hard part is planning a regular configuration that can be deployed >> to possibly hundreds of separate machines (virtual or physical) and then >> controlled in a sane way. >> >> For instance, let's say that I have 12 machines in two separate >> clusters. If I want to shutdown 3 machines in each cluster, I have to >> execute a flurry of commands like these: >> >> $ ssh -c user@server1 /path/to/tomcat/shutdown.sh >> $ ssh -c user@server2 /path/to/tomcat/shutdown.sh >> $ ssh -c user@server3 /path/to/tomcat/shutdown.sh >> >> $ ssh -c user@server7 /path/to/tomcat/shutdown.sh >> $ ssh -c user@server8 /path/to/tomcat/shutdown.sh >> $ ssh -c user@server9 /path/to/tomcat/shutdown.sh >> >> If I had a tool that understood my deployment configuration, I could do >> something like this: >> >> $ cluster shutdown 1 2 3 7 8 9 >> >> If the tool was *really* nice, it might inform my load-balancer that the >> nodes would be coming down as well. >> >> If it was super-nice, a tool would allow me to schedule a shutdown of >> nodes in the near future. For example, say I want to take those same >> nodes offline, but I want to disable them at the lb, then wait for their >> sticky sessions to drain folly before stopping each Tomcat instance. And >> since I don't want to watch the tool while it waits, I want to get an >> email or SMS confirmation when each node goes down. >> >> Maybe I can get integration into monitoring tools as well, so when I >> intentionally take a node offline, I don't get a bunch of text messages >> telling me that a server has gone down. >> >> These are the kinds of things that a "grid" tool could do to help. >> >> Being able to execute remote commands is just one of the primitive >> operations of this kind of thing. >> >> -chris >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
