ControlTier Inc. > Open.ControlTier
 
 
PDF -icon
PDF
Font size:      

Installing Packages

Overview

With packages staged in the package repository, they are ready for deployment. ControlTier is quite flexible when it comes to choosing how to control the distribution and installation of packages. There are three strategies to choose from, each of which are described below. There are advantages and disadvantages to each strategy so be your own judge.

Fast and loose

The first strategy is one we'll just call "fast and loose" since it is the simplest and requires no extra configuration setup.

Execution

To install the package directly on a single host, login to that host and run the Install command on the package you uploaded earlier. 

ctl -p default -t zip -o apache-tomcat-5.5.26.zip -c Install

This example describes a package named "apache-tomcat-5.5.26" of type "zip", stored in the "default" project depot. Calling the Install command causes that package to be installed on the local host and the installation lifecycle commands performed. You will notice messages from each of the four steps: prepare, get, extract and finish.

If you want to run that same command but across multiple hosts, you can simply use CTL's node dispatching capability to target the machines where you want the package installed. Using this approach, you might also want to filter the hosts based on a tag name.

CLI execution

Run the ctl-exec command filtering nodes as desired and specifying the ctl command and options shown: 

ctl-exec -I tags=tomcats -- ctl -p default -t zip -o apache-tomcat-5.5.26.zip -c Install

This example implies that some of the nodes are tagged as "tomcats" so so ctl-exec will execute just on those matching nodes.

GUI execution

You can execute the command shown above using JobCenter GUI. Go to JobCenter and press the "Create a new job" button. Choose the "Dispatch a Command" radio button. In the text box, enter the shell command: ctl -p default -t zip -o apache-tomcat-5.5.26.zip -c Install.

Configure the node dispatch option and then press the button for "Run". Of course, you can save this job to run at a later time, if desired.

Advantages

  • Little to no extra configuration is required. Node tagging is the only configuration to be considered.
  • Good for doing ad-hoc installation.

Disadvantages

  • Package-to-node assignments are not registered, which is useful for later tracking and re-installation.
  • There is no coordination if there are multiple related packages that must be installed on each host.

Bound by Node

The next strategy builds on the first but avoids the disadvantage brought about from the lack of mapping between packages and nodes. This strategy describes how to declare node-to-package dependency relationships which will drive the execution.

Setup

Option 1: XML configuration - Map package to nodes

The XML file containing the package metadata can also accommodate declaring the nodes to which the package should be installed. The example below describes the apache-tomcat-5.5.26.zip zip package should be deployed to node1 and node2. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project PUBLIC "-//ControlTier Software Inc.//DTD Project Document 1.0//EN" 
    "project.dtd">
<project>
  <!--
      **
      ** Describes the nodes where you want the package deployed
      **
  -->
  <node type="Node" name="node1"/>
  <node type="Node" name="node2"/>

  <package 
      arch="noarch"
      base="apache-tomcat-5.5.26" 
      buildtime="2008061570109" 
      description="The Tomcat application server." 
      filename="apache-tomcat-5.5.26.zip" 
      filetype="zip" 
      installroot="/demo/apache-tomcat-5.5.26" 
      installrank="" 
      name="apache-tomcat-5.5.26.zip" 
      release=""
      releasetag=""
      repoUrl="${framework.pkgRepo.upload-url}/default/zip/zips/apache-tomcat-5.5.26.zip" 
      restart="false"
      type="zip"
      vendor=""
      version="5.5.26"      
      >
     <!--
      **
      ** References the nodes as parent dependencies to the package
      **
      -->
    <referrers replace="false">
      <resource type="Node" name="node1"/>
      <resource type="Node" name="node2"/>
    </referrers>
   </package>
</project>

Use the XML file during the upload of the package.... 

	ctl -m zip -c upload -- \
            -xml /tmp/package.xml
	    -filename /tmp/apache-tomcat-5.5.26.zip

... or alternatively, load the metadata using the register command: 

ctl -p default -t zip -c register -- -xml /tmp/package.xml

Option 2: GUI configuration

Package to node assignements can also be done via the Workbench GUI. Go to: Workbench → PackageManager → Package List, and locate the package you wish to deploy. Select that package and find the "Parent Dependencies" link and press the Change button. A list of nodes and checkboxes will be displayed. Select the checkboxes for the nodes where you want the package installed.

Execution

To install the package across all the nodes where the package is registered to be installed, run Install command on the package uploaded earlier, and has been registered as a dependency to the desired nodes.

CLI execution

ctl -I tags=tomcats -p default -t zip -o apache-tomcat-5.5.26.zip -c Install

GUI execution

You can execute the command shown above using JobCenter GUI. Locate the package in PackageManager: Workbench → PackageManager → Package List. Click the package and press the "Commands" button. Then click the blue arrow button for the "Install" command. This will bring you to JobCenter's job creation form.

Configure the node dispatch option and then press "Run". Of course, you can save this job to run at a later time, if desired.

Advantages

  • Declares what nodes the packages are supposed to go
  • Finer grained control

Disadvantages

  • No coordination if multiple related packages must be installed on each host

Bound by Deployment

The last strategy described in this document builds on the idea of making packages dependencies of Nodes but provides extra granularity of control, important when you want something to coordinate a set of package installations.

Setup

To scale up the ability to control multiple related package installations, the Deployment type should be used. A Deployment object provides a single point of control to install multiple packages. Instead of running individual Install commands on Packages, you make Packages dependencies of a Deployment. The Deployment object provides the Deploy command to cycle through each package dependency and manage the install step for each one. Finally, you map Deployments to Nodes, to faciliate distributed execution via CTL node dispatching.

Below is an example of a representative dependency model. Arrow direction depicts child dependency relationships.

dependency model

This model shows there is a Deployment instance named, "tomcat1", that is to be deployed on two Nodes: node1 and node2. Further it shows the tomcat1 Deployment has two package dependencies: apache-tomcat-5.5.26.zip and extras.jar.

To define this dependency model two kinds of steps occur. Firstly, the objects are defined. Secondly, dependency relationships are established between the objects.

Option 1: XML configuration - Map package to deployments and nodes

Using XML configuration is probably the quickest and most succinct way carry out the two-step process of registering objects and assigning dependency relationships. The example below reflects the model described in the earlier graphic. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project PUBLIC "-//ControlTier Software Inc.//DTD Project Document 1.0//EN" 
    "project.dtd">
<project>
  <!--
      **
      ** Describes the nodes where you want the Deployment
      **
  -->
  <node type="Node" name="node1"/>
  <node type="Node" name="node2"/>
  <!--
      **
      ** Describes the packages:
      **
  -->
  <package 
      arch="noarch"
      base="apache-tomcat-5.5.26" 
      buildtime="2008061570109" 
      description="The Tomcat application server." 
      filename="apache-tomcat-5.5.26.zip" 
      filetype="zip" 
      installroot="${entity.deployment-basedir}" 
      installrank="" 
      name="apache-tomcat-5.5.26.zip" 
      release=""
      releasetag=""
      repoUrl="${framework.pkgRepo.upload-url}/default/zip/zips/apache-tomcat-5.5.26.zip" 
      restart="false"
      type="zip"
      vendor=""
      version="5.5.26"      
      />
  <!--
      **
      ** Describes the deployment:
      **
  -->
  <deployment 
      type="Deployment"
      name="tomcat1" 
      description="The Tomcat deployment." 
      installRoot="/demo/apache-tomcat-5.5.26" 
      basedir="/demo/apache-tomcat-5.5.26" >
     <!--
      **
      ** References the packages as child dependencies to the Deployment
      **
      -->
     <resources>
      <resource name="apache-tomcat-5.5.26.zip" type="zip" />
      <!-- 
        ** extras.jar is assumed to have been registered already 
      <resource name="extras.jar" type="jar" />
	-->
     </resources>
     <!--
      **
      ** References the nodes as parent dependencies to the package
      **
      -->
    <referrers replace="false">
      <resource type="Node" name="node1"/>
      <resource type="Node" name="node2"/>
    </referrers>
  </deployment>

</project>

Notice the bolded value for the installroot attribute in the apache-tomcat.5.5.26.zip package metadata. It uses a property reference (${entity.deployment-basedir}) rather than a hard coded path. This is useful when you want the coordinating control object (the Deployment) to locate the package installation root directory.

Load the file with the load-objects command: 

          ctl -m ProjectBuilder -c load-objects -- -filename deployment.xml

Option 2: GUI configuration

GUI configuration is practical when the individual objects are already registered. This means the packages have already been uploaded to the repository and the nodes already defined in NodeManager (probably when the CTL installation occurred). Given those assumptions setup should really just include the creation of the tomcat1 Deployment object and the dependency setup.

  1. Create Deployment object. Navigate to the Deployment type, and create an object called "tomcat1". Fill in the form as desired, specifying description, basedir and install root directories.
  2. Assign deployment-to-package child dependencies. Locate the "Child Dependencies" link and press the Change button. Press the checkboxes for the desired packages.
  3. Assign deployment-to-node parent dependencies. Locate the "Parent Dependencies" link and press the Change button. Press the checkboxes for the desired nodes.

Execution

Run ctl-depot

With the configuration completed, the next step is to ensure the tomcat1 Deployment is installed on all the needed machines. Run the ctl-exec command to execute ctl-depot utility: 

ctl-exec -I tags=tomcats -- ctl-depot -a install

This example used the -I flag to dispatch to the nodes tagged "tomcats".

To install the packages via the tomcat1 Deployment, run the Deploy command. The Deploy command looks at the Deployment's package dependencies and for each one, calls the Package's Install command.

CLI execution

To deploy the packages to the local host run: 

ctl -p default -t Deployment -o tomcat1 -c Deploy

...or to multiple hosts using node dispatching: 

ctl -I tags=tomcats -p default -t Deployment -o tomcat1 -c Deploy

GUI execution

You can execute the command shown above using JobCenter GUI. Go to the JobCenter webapp. Click the "Create a new job" button. Choose your project and then press the "Execute a Defined Command" radio button. Scroll down the list box and locate the "Deployment" type and then click the "tomcat1" object. This will load the commands list box. Scroll down and click the "Deploy" command.

Configure the node dispatch option and then press "Run". Of course, you can save this job to run at a later time, if desired.

Advantages

  • Provides coordinated management of package installation
  • Finer grained control

Disadvantages

  • Extra setup steps