Use your existing scripts with ControlTier
From ControlTier
Scenario
You've installed ControlTier and have run through the Getting Started page and want to start taking advantage of the command dispatcher to run your existing scripts across your systems in the simplest and quickest way. You probably want to take advantage of ctl-exec's ability to run scripts across a selection of systems in parallel.
Consider the following:
- You have a set of working scripts that you really don't want to change too much.
- ctl-exec requires a list of nodes to operate against, but ...
- ... you want to avoid installing the ControlTier client on all your systems, or ...
- ... at least defer installing it until you're ready to use "named" commands more broadly, or ...
- ... better still, set things up to use ControlTier itself to install its client!
Alternatives
Here are some alternatives that allow you to use ctl-exec directly with your existing scripts.
Avoid installing the ControlTier client on all your systems
You can avoid installing the ControlTier client on all your systems (the default way to register them as nodes with a project), by creating the node list on the server using a node project XML file and the ProjectBuilder module.
This is quickest way to get going with ctl-exec to execute your existing scripts controlled from the ControlTier server.
Assuming you've just completed the ControlTier server installation you'll have a node list with a single entry. For example:
[anthony@centos54 ~]$ ctl-exec -p Development -v centos54: hostname: centos54 os-arch: amd64 os-family: unix os-name: Linux os-version: 2.6.18-164.el5 tags: [] ---- Attributes ---- dirlist: bin,logs,var
Of course, you could add extra nodes to your project using Workbench or by installing the client on them and running ctl-project, but a quicker way is to prepare a project XML file:
[anthony@centos54 tmp]$ cat nodes.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE project PUBLIC "-//ControlTier Software Inc.//DTD Project Document 1.0//EN" "project.dtd"> <project> <node type="Node" name="node1" description="ControlTier managed node" ctlUsername="user1" ctlPassword="password" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node1" tags="development,webserver"/> <node type="Node" name="node2" description="ControlTier managed node" ctlUsername="user2" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node2" tags="development,appserver"/> <node type="Node" name="node3" description="ControlTier managed node" ctlUsername="user3" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node3" tags="staging,webserver"/> <node type="Node" name="node4" description="ControlTier managed node" ctlUsername="user4" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node4" tags="staging,appserver"/> <node type="Node" name="node5" description="ControlTier managed node" ctlUsername="user5" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node5" tags="production,webserver"/> <node type="Node" name="node6" description="ControlTier managed node" ctlUsername="user6" osFamily="unix" osName="Linux" osArch="amd64" osVersion="2.6.18-164.el5" hostname="node6" tags="production,appserver"/> </project>
 |
Note that each node's name and hostname attributes are set to the resolvable hostname to which you want to dispatch commands. Since the ctl-exec command reports node names, but uses the hostname values to evaluate inclusion/exclusion this convention eliminates the potential for confusion. |
|
Setting only the "ctlUsername" attribute assumes that you have setup SSH key-based authentication between the ControlTier server and that user on all the nodes you wish to manage. Of course, you can also set a password for each node by using the "ctlPassword" attribute (as in node1.mydomain.com above). If you have to use passwords, you can avoid including them in plain text in your project XML by using Workbench to add the password later (either way, it is stored in a hashed form in the resource model). |
... and load it into your project using ProjectBuilder:
[anthony@centos54 tmp]$ ctl -p Development -m ProjectBuilder -c load-resources -- -filename nodes.xml Loading "/home/anthony/tmp/nodes.xml" ... 1 file(s) have been successfully validated. Processing /home/anthony/tmp/nodes.xml to /opt/ctier/ctl/var/tmp/projectxml-888217455.xml Loading stylesheet /opt/ctier/ctl/projects/Development/modules/ProjectBuilder/lib/load-resources/projectxml/project.xsl Mapping XML to properties ... [timer: 0.605 sec] Batching new object creation requests ... [timer: 2.460 sec] No new objects to be created ... [timer: 2.461 sec] Batching object attribute update requests ... [timer: 3.080 sec] Batching resource and referrer updates ... [timer: 3.124 sec] Executing 6 batched object updates ... [timer: 7.292 sec] Adding document transforms to deployments ... [timer: 7.446 sec]
With the nodes loaded you're ready to use ctl-exec (and Jobcenter) to run your existing scripts from the ControlTier server. e.g.:
[ctier@centos54 ~]$ ctl-exec -I '.*' -- id number of nodes to dispatch to: 7, (threadcount=1) uid=101(ctier) gid=103(ctier) groups=103(ctier) Connecting to node1.mydomain.com:22 cmd : id uid=504(user1) gid=504(user1) groups=103(ctier),504(user1) Connecting to node2.mydomain.com:22 cmd : id uid=508(user2) gid=508(user2) groups=508(user2) Connecting to node3.mydomain.com:22 cmd : id uid=509(user3) gid=509(user3) groups=509(user3) Connecting to node4.mydomain.com:22 cmd : id uid=510(user4) gid=510(user4) groups=510(user4) Connecting to node5.mydomain.com:22 cmd : id uid=511(user5) gid=511(user5) groups=511(user5) Connecting to node6.mydomain.com:22 cmd : id uid=512(user6) gid=512(user6) groups=512(user6)
Whether or not you subsequently install the ControlTier client on all your systems, maintaining the nodes.xml provides somewhere to keep node descriptions and the set of tags you'll be exploiting to selectively run commands.
| ||||||||||||||
