DataPower plugin architecture
RapidDeploy objects and DataPower
RapidDeploy consists of three main object types, the Project, Server and Environment objects.
DataPower Project
This is the basic and most important object in the RapidDeploy application. Typically it will have a project root directory, below which artifacts and configuration are stored. A project may be directly related to a specific development project, such as a small web application project, or may be the basis for just one deployable component of a much larger software development effort.
Each project has exactly one orchestration file, which determines the task steps to run for each deployment. This is an environment independent file. You can point multiple projects to the same root directory, but supply different orchestration file names, so that each project can perform different actions on the same set of configurations and deployable artifacts.
Typically a DataPower project will be the basis of one or more version locked deployable components, for example a DataPower domain, that form a Unit of Deployment.
It is likely you will configure multiple DataPower projects. Examples include projects to:
- Manage device firmware across a DataPower estate
- Manage the route-to-live of a development domain
- Manage stop, start, quiesce, unquiesace, reboot operations across a number of devices or domains
- Export domains to a software configuration management tool
- Manage device backup and restore operations across a DataPower estate.
You interact with DataPower using the DataPower plugin. The plugin is not shipped in RapidDeploy and must be installed from the 'System -> 'Plugin Manager' -> 'Available Plugins' tab.
Project 'Deployment Package'
Periodically, all projects are 'built' into a 'deployment package'. Typically this is a zip archive containing everything underneath the project root directory (which might be in an SCM repository). It may also contain external resources defined on the project panel (and stored in a resources.xml file in the project). Typically an exported domain zip file would form an external resource.
The 'deployment package' will typically be named according to the baseline, version or label name of the underlying SCM tool, or based on a root name incremented by 1 each time the project is built, e.g. DATAPOWER-COMMERCE-1.1.17. Each package is a self-contained unit containing all of the configuration to enable it to be deployed to all devices/domains in the 'known' estate for this project.
Packages are stored in an 'Artifact Repository' which by default is a local file system. RapidDeploy supports a number of artifact repositories, determined by the selected artifact repository plugin for the project.
DataPower Server
The RapidDeploy server object defines target physical servers that the MidVision application can communicate with. For DataPower, the server is a centralised server (on Unix, Linux or Windows operating system) from where DataPower management operations are performed. It will hold enough storage to allow management of multiple devices, their domains and firmware levels.
The RapidDeploy server object allows the server connectivity details to be specified (using either SSH or a remoting agent) as well as storage locations for deployment packages.
We sometimes refer to this server as the 'DataPower Deployment Manager', or DPDM
This server may be the same server as the RapidDeploy framework server.
DataPower Environment
A RapidDeploy Environment is one discrete sub-level component of a RapidDeploy server. For DataPower the environment defines either a device only, or a device and one contained domain, depending upon the scope of the environment.
Managing multiple devices with a 'Job Plan'
In RapidDeploy, you can manage multiple devices as a group. For example, you might configure a project to manage firmware upgrades (by use of the appropriate tasks in the projects job orchestration). This project might be configured to 'know about' all of your DataPower devices, by linking the project to all DataPower device environments. You can then create a 'job Plan' that aggregates all of the environments into a single job plan. As you decide to make firmware upgrades you access the job plan, update the version (of firmware to deploy) and execute (or schedule) the job plan. All the target devices will be upgraded. You can choose in the job plan to batch these upgrades into parallel or serial executions, impose dependencies between batches and require manual approvals.
Managing change on a route-to-live with a 'Job Plan'
Promote configuration between various environments (e.g. Development, Test, Production).
- Deployment policies may be used to support environment specific configuration changes. The environment-specific changes are configured once, and reused for each deployment.
- Search/Replace and XPath replace tasks may also be used to replace environment specific configuration values at runtime to make on-the-fly replacements in the deployment package immediately prior to import of the domain components.
Again this is managed by linking the project to the environments (device and domain combinations) that map the route to live. Each target can be deployed independently (with sufficient role access) and or executed as part of a job plan.
In order to manage change through DataPower environments, you may configure a project to manage a DataPower domain, from its development environment through to a production domain. Typically, multiple developers will contribute their own changes made in their domain to a central 'golden' development domain.
The 'golden' domain is exported from the development device to the SCM system periodically by executing a build job. This job will run a task to export the domain and store it in the SCM tool, and is analogous to running a standard code build as you would for a typical development project. The output is a set of files stored in the projects chosen SCM repository, and a baseline being created. This allows technical staff to maintain a change history and perform comparisons between 'versions' of the domain over time. The domain archive zip file is also added to a 'deployment package' which is a zip file of the RapidDeploy project at the point in time where the build was executed, containing all of the project configuration objects and the just built 'golden domain' zip file. The zip file is named according to the label or baseline name applied in the SCM tool.
The output 'deployment package' may be deployed through the DataPower environments linked to the project on the route-to-live using a job plan as above, or by an authorised user performing the actions manually through the RapidDeploy UI.
Managing RapidDeploy from external services
As well as a Graphical user interface, RapidDeploy supports inbound requests via a Web Services and/or JMX API. Using these interfaces, RapidDeploy activities such as deployments can be initiated from scripts or from other enterprise scheduling tools. Please see the framework documentation for more information on using these API's.