THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- The status command now adds more information for each service (Tomcat instances and Grid Agents):
- CPU usage (if possible)
- CPU load (if possible)
- Head usage (if possible)
- Threads (if possible)
- Started on (if possible)
- Any other information deemed useful for managing purposes.
Wiki Markup \[Optional\] Machine information (same page, or maybe an extra tab) shows per machine:
- CPU usage
- CPU load (1 min, 5, min, 15 min)
- Memory usage
- File system drives/mounts space usage (maybe only specific mounts) for the mount where the "webapps" dir is (can this be different per instance?).
Phase 5 - Command-Line Interface (CLI)
...
This phase implements War applications deployment and undeployment to the grid as a whole, or to specific Tomcat instances.
Included features are:#
- New commands:
...
- deploy: deploys a web application (a WAR) to a specific or all grid instances
...
- undeploy: undeploys a web application to a specific or all grid instances
- undeploy: undeploys a web application to a specific or all grid instances
...
- Through this operations Tomcat instances will be able to run multiple web applications.
...
- The status command is revamped so it now lists all war applications deployed on each instance.
Phase 9 - Application Version Management
...
When the a new version of the application (a Release) needs to be deployed the deployment happens in an orderly manner. The grid also keeps track of which version is live, which ones are not live but still on the grid, and also provide rollback capabilities.
Included features are:#
- A Release includes one or more deployables. Deployables are WARs, JARs, etc. that will be part of an application we want to deploy on the grid.
...
- Maybe all deployables are deployed to all instances, maybe each deployable goes to a subset of instances. This will need to be specified on the configuration file.
...
- Releases are first registered into the Grid (maybe even uploaded) under a client-provided unique Version ID. If no Version ID is provided, the system generates it. Behind the scenes, each release deployable is transferred to the corresponding machines automatically during registration. Since this operation may take a while the release will show the states of loading, ready, or removing.
...
- Releases must be deployed to the grid using the Version ID. Since all deployables are already distributed to all machines, a deployment now corresponds to local copy (or sym link) of each deployable to the Tomcat's webapps dir. The deployment automatically registers which Version ID is now deployed on every instance. The deployment operation can be sent to the whole grid or to a single instance.
...
- No two versions are deployed at the same time on a Tomcat instance. When a version is deployed to an instance, the existing one is first unlinked from the instance. It's not actually removed from the grid or the file system, so a rollback operation can be performed quickly if needed.
...
- New commands are implemented:
...
- register: loads a new application version into the grid under a unique Version ID
...
- deregister: removes a non-live application version from the grid
...
- versions: list all loaded and live Version IDs and where they are deployed
...
- deploy: deploys all version's deployables to the corresponding instances, unlinking the old ones
...
- rollback: undeploys the current version from all Tomcat instances, and restores the previous version
...
- deploystop: deploys all version's deployables to the corresponding instances, but keep the Tomcat instances down
...
- undeploy: undeploys a version (or a single deployable) from the grid or a subset of the grid
- undeploy: undeploys a version (or a single deployable) from the grid or a subset of the grid
...
- As shown above the deploy and undeploy commands are revamped.
...
- The deploy, rollback, deploystop, and undeploy command may use, behind the scenes, many low-level "link" and "unlink" tasks. These tasks add/remove a deployable to/from an instance correspondingly.
...
- Each deploy inspects the current state of the grid and saves a Rollback Plan. The rollback commands executes the Rollback Plan. Only one Rollback Plan is saved at any given time.
...
- The Rollback (if saved) is shown on the Web and CLI interfaces.
...
- The status operation now also shows for each instance:
...
- Deployables (the list of war applications deployed in the instance)
...
- Version IDs
...
- Deployed at (date & time)
- Deployed at (date & time)
...
- New hooks are added for the new commands:
...
- pre-register-release
...
- post-register-release
...
- pre-register-deployable
...
- post-register-deployable
...
- pre-deregister-release
...
- post-deregister-release
...
- pre-deregister-deployable
...
- post-deregister-deployable
...
- pre-deploy
...
- post-deploy
...
- pre-rollback
...
- post-rollback
...
- pre-deploystop
...
- post-deploystop
...
- pre-undeploy
...
- post-undeploy
...
- unlink (unlink: low-level operation that removes a deployable from an instance)
...
- post-unlink
...
- pre-link (link: low-level operation that adds a deployable to an instance)
...
- post-link
- post-link
Phase 10 - Collections
Collections are groups and sub-groups of services (instances and/or agents) that are managed together. Essentially, instead of issuing a command on a single service, you can now issue it onto a collection. The commands will now affect all services in the collection and will probably take longer to complete, since multiple operations are now needed to complete the whole command.
Collections may group identical Tomcat instances or maybe Tomcat instances that do not serve the same purpose. For example, one subgroup of Tomcat instances may run the customer facing site (like an HTTP cluster), other group may run the back end site (maybe processing JMS queues), other group may be dedicated to serving or connecting to integration points.
Included features are:#
- The following commands can now be issued on collections in addition to plain services:
...
- status
...
- trigger-start
...
- trigger-stop
...
- trigger-kill
...
- start
...
- stop
...
- kill
...
- restart
...
- killstart
...
- deploy
...
- rollback
...
- deploystop
...
- undeploy
- undeploy
...
- Hooks are modified to provide information of the collection they are affecting.
...
- When a hook runs on a collection, it runs on the machine where the manager application (web or cli) runs, not remotely on the machine of any other instance. This is because in this case the execution is not tied to a specific instance, but to a collection.
...
- Services defined in a collection can be managed in sequential or parallel modes. For example, a restart command on a sequential collection will restart the second service only, when the first one has fully completed. Once the second completes, it will restart the third one, and so on. A parallel collection would issue a restart on all services simultaneously.
...
- Collections are defined in the configuration file and are of a recursive nature: a collection can include plain services, other collections, or both. For sequential mode, each "sub-collection" is treated as a single element so it's considered fully complete when all its included services and collections complete.
Wiki Markup
...
\[To be analyzed and defined if it's useful or not\] Collections editing through the Web interface. This can be useful to graphically update collections when machines/instances are added/removed. \\
Phase 11 - Instance Configuration
...
| Wiki Markup |
|---|
The CLI interface does not offer this functionality. \[to be discussed\] |
Included features are:#
- Using the Web interface the user can change instance's configuration remotely. This operation allows the instances to be changed remotely, for example to:
...
- Add libraries (typically JDBC drivers, MQ drivers, JSF, etc.)
...
- Set JVM parameters (memory settings, GC behavior, JVM tweaking, etc.)
...
- Prepare (add/change/remove) JDBC data sources
...
- Set context parameters
...
- Set JNDI entries
...
- View required WAR resources, and set resources values accordingly
...
- Changing listeners
...
- Other instance configurations
- Other instance configurations
Phase 12 - Instance Provisioning
...
In addition it may not be possible to install, configure, and run the Grid Agents remotely because of fire-walled machines. If that's the case, the Grid Agents will need to be manually setup. Once the Grid Agents are running, the rest of the provisioning can be performed through the Web Manager, using the Grid Agents.
Included features are:#
- The provisioning operation will automate the following tasks:
...
- Login into a machine
...
- Installing the Grid Agents
...
- Configuring & running the Grid Agent
...
- Installing the Tomcat instances
...
- Configuring the Tomcat instances
...
- Configuring the environment (shell variables, other)
- Configuring the environment (shell variables, other)
...
- Using the Web and Command-Line interfaces the user can provision the Grid. Typical operations can be:
...
- Adding a new machine to the Grid.
...
- Removing a machine from the Grid.
...
- Adding a new instance to a machine.
...
- Removing an instance from a machine.
- Removing an instance from a machine.
...
- Once new machine is registered, the machine's Agent is installed and executed.
...
- To deregister a machine all instances must have been removed first.
...
- If a machine is deregistered, the Agent is stopped and optionally uninstalled. Maybe we'll leave it there, so it will be easier in the future to re-provision the machine.
...
- Once a new instance is created the following operations are performed:
...
- Registering the machines on the grid configuration file
...
- Standard instance's directory tree is copied
...
- All the instance extra configuration (libraries, JDBC data sources, etc.) are performed
...
- No deployments are installed yet.
- No deployments are installed yet.
...
- To remove an instance, all deployables must have been undeployed first.
...
- Once an instance is removed:
...
- The instance is removed from the configuration file and any collection that included it
...
- All deployments are removed from it
...
- The whole directory tree for it is removed on the remote machine
- The whole directory tree for it is removed on the remote machine
...
- The provisioning operations require remote access to the new machine, and therefore some kind of connections needs to be setup. For example, an SSH connection could be used if the user provides the user name/password credentials or if if an ssh key exchange had been previously setup between the machines.
Phase 13 - Custom Commands
...