On Tue, Nov 8, 2016 at 1:33 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx> wrote: > On 11/08/2016 10:00 AM, bruce wrote: >> Hey Rick!! >> >> Thanks for the reply... >> >> That was kind of going to be my thinking.. >> >> I came across some apps that appear to be devOps related, one of which >> was ClusterSSH/Cluster SSH. >> >> As far as I can tell, it appears to allow you to setup the given >> ipAdress, as well as user to run the ssh connection as and the ssh >> ocnfig files, to allow the user to connect/access to the given term >> sessions for the remote instances. >> >> The app also appears to allow you to then run the different commands >> to the given systems. (Not sure if you can "package" the commands you >> want to run, so you can run group of cmnds to different groups of >> systems.) >> >> I'm currently looking at information on this, as well as a few others. >> >> My use case, has a bunch of vms on digitalocean, so I need a way of >> "managing"/starting the processes on the machines - manual ain't going >> to cut it when i have 40-50 to test, and if things wrk, will easily >> scale to 300-500 where I have to spin up, run the stuff, and then spin >> them down.. >> >> Actually, it would be good to have a gui/tool to be able to implement >> the DO/digitalocean API to generate/create, run, create the snapshots, >> destroy, to save costs. >> >> Whew!! > > Ok, what I suggested was really aimed at launching processes in the > background on a remote machine in a way where you could check on them. > > ClusterSSH (a.k.a. "cssh") is a different beastie. It's a GUI tool that > allows you to open parallel ssh sessions to a whole bunch of remote > machines simultaneously. We use it a lot, as we have about 300 machines > in our data center broken into "clusters" that do specific things. > > ClusterSSH opens a small terminal window for each machine so you can > see what's going on. You can enter commands for THAT machine in that > window as well. It also opens a "master" command line window, and > whatever you type into that master window gets sent to ALL of the open > windows. Fairly handy, but be REALLY careful, as sometimes (due to > network load, etc.) some keystrokes may NOT make it to all of the open > windows. This can be disastrous if you're, say, editing files and such. > > cssh does offer a way to specify a command to be sent to all of the > windows by using its "-a" option. I'd imagine it'd be something like: > > cssh -a "screen -d -m -S firstsessionname 'command you wish to > run on the VM'" user1@1.2.3.4 user1@5.6.7.8 > > which should run that screen command on the two machines specified. I > can't speak to that too well. We don't typically use it like that--we > tend to use it in the interactive mode only. > > I can give you examples of cssh usage (such as an /etc/clusters file > and such) if you want to go down that road. > >> On Tue, Nov 8, 2016 at 12:12 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx> wrote: >>> On 11/08/2016 04:02 AM, bruce wrote: >>>> Hi. >>>> >>>> Trying to get my head around what should be basic/trivial process. >>>> >>>> I've got a remote VM. I can fire up a local term, and then ssh into >>>> the remote VM with no prob. I can then run the remote functions, all >>>> is good. >>>> >>>> However, I'd really like to have some process on the local side, that >>>> would allow me to do all the above in a shell/prog process on the >>>> local side, >>>> >>>> Psuedo Processes:: >>>> -spin up the remoter term of user1@1.2.3.4 >>>> -track the remote term/session - so I could "log into it" see what's >>>> going on for the initiated processes" >>>> -perform some dir functions as user1 on the remote system >>>> -run appA as user1 on 1.2.3.4 (long running) >>>> -run appB as user1 on 1.2.3.4 (long running) >>>> -etc.. >>>> -when the apps/processes are finished, shut down the "remote term" >>>> >>>> I'd prefer to be able to do all of this, without actually having the >>>> "physical" local term be generated/displayed in the local desktop. >>>> >>>> I'm going to be running a bunch of long running apps on the cloud, so >>>> I'm trying to walk through the appropriate process/approach to >>>> handling this. >>>> >>>> Sites/Articles/thoughts are more than welcome. >>> >>> 1. Set up ssh keys so you don't need to use passwords between the >>> two systems (no interaction). >>> >>> 2. Launch your tasks on the remote VM using screen over ssh by doing >>> something like: >>> >>> ssh user1@1.2.3.4 screen -d -m -S firstsessionname "command you wish to >>> run on the VM" >>> ssh user1@1.2.3.4 screen -d -m -S secondsessionname "second command you >>> wish to run on the VM" >>> >>> 3. If you want to check on the tasks, log into the VM via ssh >>> interactively and check the various screen sessions. I recommend setting >>> the screen session names via the "-S" option so they're easier to >>> differentiate. >>> >>> That should do it. The items in step 2 could be done in a shell script >>> if you're lazy like me. :-) ------ Hey Rick!! Thanks for the reply.. Slowly slogging through this. My use case (for now) has DigitalOcean (DO) as the cloud provider. The project is working on the ability to be able to spin up/down 500-1000 droplets as needed. DO provides the api, to create/delete the actual instances, so cost of the actual cloud usage can be handled. This is trivial. However, on the devops side, it appears that clusterSSH would/will be useful (needed), in order to be able to kind of manage/track the overall progress of the running apps on the droplets. I'm envisioning a process that allows: 1) The ability to use a "config" process to spin up the terms for the required droplets -droplet would have user1:passwd1 and use sshkey -droplet would have known ipAddress -as the process/droplets change the required config file could be script generated 2) The ability to spin down the terms 3) The ability to "see" the progress of the generated/viewed terms -The assumption is if the Screen process is used to run the remote processes, then when the term is reconnected via clusterSSH --ssh - then the screen session can automatically be attached, to then see the current status/process... 4) As the term is spun up, process needs to be able to do invoke/run the remote process **Also/aside, need to be able to generate a remote cmd, to check if a given process is running on the droplet -- This should be trivial once the clusterSSH stuff is nailed down, use the same/similar process for generating the remote Screen app/sessions on the remote droplets.. If the project is running 100-200 droplets, there's no way to check all the droplets within a gui on the desktop, so there should be a way to "view" 20-30 at a time... So... whatever you have regarding the clusterSSH/Screen session part, hit me up. Or, if someone has thoughts/comments, feel free to post! Thanks _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
