Using Maestro For The First Time
We’ve included a handful demonstration Compositions, our workflows, for you to run in order to get an idea of what and how Maestro does.
If you are a hosted evaluation user, login with the username and password that were emailed to you. For the VM based evaluation, login into Maestro using username ‘admin’ and password ‘admin1’.
There are three Projects already loaded into the evaluation environment:
- Centrepoint – a simple Maven-based build, test, provision and deploy project
- Hello Ivy – a simple Ant-based build, test and deploy project
- WordPress – a simple PHP package, provision and deploy project
Let’s start with Hello Ivy, as its Composition will run without any modifications required.
Looking at the Compositions pane, we see the title, the last activity stamp, and the button bar – where we click to run, edit, delete, or view the history of the last runs for a given Composition.
Hello Ivy is a simple two-step artifact deployment Composition. First we use a ‘Git Clone’ task to get the code to a temporary location, then we use an ‘Ant’ task tobuild and deploy the artifact to an artifact repository. In this case, it’s a typical continuous integration process. Click the ‘pencil’ icon to edit the Composition, and you’ll see the two tasks.
In this demo case, we’ll use Ant and Ivy to build, fetching the dependencies from our Maven repository, then use a Maven plugin to deploy built artifact to Archiva. Press the run button to start that off.
Once the Composition is executed, and returns success, we’ll see the newly deployed artifact sitting in our Archiva repository.
If we run the Composition again, you should see the second snapshot in the repository.
That’s all there is to this one, a simple build and deploy automation.
The Centrepoint project contains several Compositions: two to note are the main Centrepoint composition, and a Selenium test suite.
The default Composition does a bit more than the initial Hello Ivy workflow. Before we can run this one through we need to enter a bit of information to allow us to provision a machine in Amazon Web Services EC2.
The Centrepoint project uses Jenkins to perform the build and artifact deploy steps, in the first task. We then use a ‘wget’ task to retrieve the new artifact from the Archiva Maven repository. Once we have the artifact, we’ll go ahead and provision a new EC2 instance (one that is already pre-configured with Tomcat). Then we will use a ‘Tomcat’ task to deploy the artifact through the remote Tomcat manager interface, and launch the Centrepoint webapp. Next, we use a ‘confirmation’ task which pauses the Composition, waiting for a human yes/no input (within the Maestro interface). Once the confirmation is accepted, the Composition with deprovision the EC2 machine. [Note: in this example, accepting or declining the confirmation will result in the EC2 machine being deprovisioned.]
Update the Provision and Deprovision Tasks
You’ll need to add your AWS Key ID and Secret Access Key in both the ‘Provision’ and ‘Deprovision’ tasks.
The ‘Provision’ task is preconfigured to use a Security Group called quick-start-1. Chances are you probably don’t have one, so you can create one, or enter a new Group name – as long as it looks like this:
The ‘Provision’ and ‘Deprovision’ tasks require a valid Keypair. You must set the ‘Key_name’ fields to a valid AWS EC2 Keypair name.
Once you make the changes click ‘Save & Finish’.
Once you’re back to the Composition pane you can click the ‘play’ (run) button to execute the Composition. [Note: it will take a bit to run through the first time, as Maven will need to download all of the project dependencies to the local repo]
As the Composition goes through its execution you’ll see the tasks change to green:
And, once the Composition gets to the ‘confirmation’ task, it will go into a waiting state, and present a new ‘action’ in the ‘Recent feed’ pane at the bottom of the window:
You can go ahead and accept it, by clicking on the check. You can verify that the provision instance is terminated in your AWS EC2 Management Console.
The WordPress Composition is similar to Centrepoint, however it doesn’t use Jenkins, as it is just a PHP project not requiring the build stage.
The Composition starts with checking out the WordPress codebase with Subversion, then “zipping” up the directory structure. Once the package exists, the Composition will provision a new instance in EC2. Same as the Centrepoint Composition you’ll need to update the AWS key and security group information.
Next, the Composition focuses on copying the package to the newly provision machine and configuring it to run within the remote Apache environment through SCP and SSH commands.
As with the Centrepoint Composition we’ll use a confirmation task to highlight the provisioning and deployment completion. Accepting (or declining) will deprovision the instance and complete the Composition’s execution.
Creating and executing Compositions
We are going to create a new Test project, add two simple Compositions. Maestro has the ability to provide a “failure” handling Composition that gets instantiated when a task in a given Composition fails. We will create the failure handling composition first, then the real-work Composition and link it to the failure Composition.
Creating a New Project
In order to add a project click on the ‘Add Project’ button (in the top-right corner of the Project Pane).
The Add Project dialog window will appear. Just add ‘Test Project’ in the ‘Name’ field, and ‘Evaluating Maestro’ in ‘Description’, then click the ‘Save’ button.
You should now see the new Project in the Project pane:
From the Project list, you can click the ‘Test Project’ row to open its Composition pane. In the top-right corner of the Composition pane, click the ‘Add Composition’ button. This is the Failure Composition, so let’s name it appropriately.
Now, let’s add the second, real-work, Compositions. Be sure to specify the ‘Failure Composition’ in the drop-down, pointing it to the ‘TesterFailHandler’ Composition.
We now have our two Compositions, time to add some tasks.
Let’s keep this simple, in order to follow the flow. We will first add a couple basic ‘shell’ tasks to the RealWork Composition to demonstrate the failure.
Now, go ahead and add three ‘shell’ tasks.
Then save by clicking the ‘Save & Finish’ button.
Executing the Composition
Back in the Composition pane, we can go ahead and click the ‘play’ button to execute our new Composition. It _should_ fail on the second task – unless for some strange reason the /idonotexist directory exists.
Let’s look at the history and see the actual output from the agent.
It’s pretty clear, the shell command fails because the directory doesn’t exist. And because we have yet to add any tasks to the failure Composition, nothing else was executed.
Now to add a simple task to the Failure Composition to show the contents of the /tmp/realwork.txt file that we created in the RealWork Composition. We’ll show that the contents are indeed the correct ones – before the failure of the task.
Save the Composition, and let’s rerun the RealWork Composition. It should fail again. But this time if we click on the history button we should see that the task in the Failure Composition was appended to the RealWork Composition.
You’ll note that the TesterFailHandler never actually gets executed. That’s because Maestro just appends its tasks to the failing Composition (as it’s designated as the Failure Comp).
The Failure Composition can be executed just like any other Composition, and this is useful as you are designing your workflows, and debugging them.
Obviously, this is a really simple use case. We use this failure apparatus to do continuous delivery of our product. We have configured the Failure Composition to restore the previous state – pre-release in the event of an error on production deployment. We hope that this is enough of a teaser that you’ll be able to imagine its potential for you. We would also love the opportunity to discuss your needs – revolving around build, testing, cloud provisioning, deployments, release management, and artifact repositorying.