In the second approach, there is a more clear-cut separation of control between Puppet and JetPatch. Puppet handles the state of server and application components, and JetPatch handles the state of server management tools.
In this approach, JetPatch users set up policies, similar to Puppet classes, that determine the set of management services for each server. Policies are based on server characteristics such as location, operating system, application, type, role, and environment as determined through a tagging system. Puppet sets up server management by assigning servers with appropriate tags, and the JetPatch policy engine interprets these tags and takes care of the rest. These tags, assigned by Puppet or by other means, can also be used within JetPatch for other purposes such as establishing role-based server access.
The steps for deploying a new management service using Approach 2 are as follows:
For example, with this second approach, Puppet can tell JetPatch to tag a database server with database and production tags. JetPatch policies can be set up to automatically deploy an entire set of management tools, bundled as services, to all production databases. As soon as these tags are added to the node in the JetPatch console, JetPatch starts the deployment these tools with the correct agent and console configurations. From that point on, JetPatch continuously ensures that tools are fully functional.
Please sign in to leave a comment.