As larger and larger users begin to use ControlTier outside of non-production environments, issues rising from scale, network policy and change management begin to enter. One feature found in the typical ControlTier infrastructure is the immediate propagation of configuration model changes to affect running deployments. This is great when you want to reset a port setting, change paths, toggle app settings or whatever, and have these changes take immediate effect. Many development environments would come to a grinding halt if they couldn't have this instantaneous centralized control.
Large scale production environments require a different set of assumptions due to infrastructure and policy differences:
* Infrastructure: Production environments can span multiple data centers and subnets making a single data repository impractical. This means a centralized Workbench may not be accessible to all clients or scale sufficiently across 1000s of nodes.
* Policy: Operations managers often are uncomfortable with the idea of application management data being managed outside of a change control. This means ControlTier metadata should be released using the same policies as application code.
This blog post proposes an alternative to managing and releasing ControlTier data using a "build and release" methodology.
Build and Release process
ControlTier object data can be maintained and released using the same build and release lifecycle as any other application artifact.
• Build: Checkout object XML data, load it in Workbench for data validation, then archive the results in a package that can be distributed.
• Release: Retrieve object archive from software release repository, distributing it to CTL hosts then extract the archive.
This process can be driven from the "ProjectBuilder" module included in the base framework. Below is a diagram showing the basic elements:
Tool support
ProjectBuilder support
ProjectBuilder can be enhanced to prepare static metadata files in a "build" phase of the process life cycle. Specifically, ProjectBuilder can generate entity.properties data for a specified set of objects. The result of the generation is a set of files archived in a single file.
archive-objects: A new command
A new command should be added that takes object name and type parameters and generates the entity.properties file for each one. Below is the proposed option set:
usage: archive-objects [-file] [-object <>] [-type <>]
CTL support
CTL will include a new administrative command that can create and extract CTL object data files (eg, entity.properties). Below is the proposed option set:
usage: ctl-archive -a action -file archive [-p project] [-d dir]
Archive delivery
The diagram below describes how the process and tools drive the build and release of CTL object data:
This process diagram left the distribution tool open to user preference. The next diagram shows how RPM and Yum can distribute the data:
Alternatively, a simple ctl-exec script could push and invoke the extraction process:
Next steps: Your feedback
All the basic bits and pieces to support this new package-centric data management methodology exists in 3.2.3. What's left is formalizing it in a documented configuration.
What will be most helpful is feedback on the approach and any other considerations that should be factored in.
If it seems like the approach is on the right track, my next follow up should be the documented "howto".
Thanks, Alex
