changes.
| | h1. Overview |
| | |
| | QuickBuild 5.0 introduces the [cloud profile] concept to support launching build agents on demand into cloud environment. A cloud profile defines characteristics of the build agent and knows how to launch the build agent. Build agents launched by the same cloud profile will have the same characteristics including operating system, installed software, |
| | environments, system and user attributes etc. So if you have builds with different agent requirements, you will need to define multiple cloud profiles. After a cloud profile is defined, QuickBuild will try to launch a temporal agent to grab agent system and user attributes and store them into the profile. Internally QuickBuild treats cloud profiles as virtual agents, and in case there is no existing agents satisfying requirements of a build step, QuickBuild will match these virtual agents against the step. If a match is found, QuickBuild will launch a concrete agent using the profile to run the step. A launched build agent will be terminated automatically if it is idle for certain period of time, and the administrator can also terminate them manually if necessary. |
| | |
| | h1. Define cloud profile |
| | |
| | Cloud profiles need to be defined by administrators in _Grid/Cloud Profiles_ page like below: |
| | !cloud_profile.png! |
| | |
| | After pressing the add button, QuickBuild will present the profile definition screen as below: |
| | !profile_definition.png! |
| | |
| | Then you can select desired cloud provider via _Node Launcher Setting_ in the screen and define how to launch agent in that cloud. QuickBuild will do a test launch of the defined cloud profile to grab build agent characteristics including system and user attributes to form the virtual node. The test launch screen is as below: |
| | !test_launch.png! |
| | |
| | The test launch should normally complete within two or three minutes. If successful, QuickBuild will present below screen to user: |
| | !test_launch_complete.png! |
| | |
| | h1. Use cloud profiles |
| | |
| | Once cloud profiles are defined and test launch passed, they will be used as virtual nodes to match node requirement of steps if no existing agents matches. You may also define grid resources to match characteristics of certain cloud profiles, so that agents referenced by these profiles can be launched on demand if the resource is exhausted. For a particular cloud profile, launched nodes will be listed in active nodes tab of the profile like below: |
| | !profile_active_nodes.png! |
| | |
| | Nodes listed here will be terminated automatically if it is not being used by any steps for the timeout value defined by the profile, and you may also terminate them manually as demonstrated in the screenshot. |
| | |
| | From time to time, you might see odd entries in inactive node list like below: |
| | !odd_inactive_entries.png! |
| | These entries are created by cloud profiles in order to auto-authenticate launched nodes and the unknown fields will be filled by info of launched nodes when they are active. So do not remove them in normal cases. |
| | |
| | h1. {anchor:diagnose cloud profile issues} Diagnose cloud profile issues |
| | * If test launch fails, you may check the server log to see detailed message about the launch error. |
| | * If test launch does not report any error but just sit there never completes, you may follow below steps to examine the status: |
| | *# Check at cloud provider side to see if the test agent has been launched successfully. |
| | *# If test agent has been launched, login to the agent to check QuickBuild agent console log to see if there are any errors being printed. The agent console log can be found in _<agent install dir>/logs_ directory. |
| | *# If no obvious errors found in agent console log, check _Grid/Active Nodes_ page at QuickBuild server side to see if the launched node appears there. If yes, most probably the node is launched with an image already containing the authentication token, which is NOT suggested. The fix is simple, just unauthorize the launched node and the test launch should be successful shortly. |
| | * If build step is in WAITING_NODE status, and relevant cloud profile does not launch node as expected, please check if virtual node represented by the profile really matches the step. To verify, you may launch a node manually at cloud provider side to see if it can be picked up by the step. |
| | * If cloud profile takes too long to launch an agent, please check if the agent tries to update plugins when it starts up. If yes, please re-create the agent image for the profile after plugins have been updated. Note that you should first unauthorize the agent before creating the image; otherwise, test launch for your updated profile will never complete as described above. |
| | | |
| | h1. {anchor:create build agent AMI} Create build agent AMI |
| | # Manually launch an instance of desired platform using your EC2 account, and install Java Runtime Environment version 6 or higher on the launched instance. You may also want to install other software required by your build to this instance. |
| | # Download QuickBuild plugin package from Grid page, and upload it to launched instance above. |
| | # Login to the EC2 instance and extract build agent package to your chosen agent installation directory. |
| | # Edit file _<agent install dir>/conf/wrapper.conf" to define property _wrapper.java.command_ to point to java binary if it is not in system path. |
| | # Edit file _<agent install dir>/conf/node.properties" to configure QuickBuild server URL. You may also run _<agent install dir>/bin/config.(bat|sh)_ to config node properties such as SSL setting. However this program requires GUI terminal, and if your console does not have that facility, you may run this program at your desktop to populate the node.properties, then transfer this file to launched instance. |
| | # Edit file _<agent install dir>/conf/attributes.properties" to define necessary user attributes for the build agent. |
| | # For Unix instances, edit file _<agent install dir>/bin/agent.sh" to uncomment below line and assign an OS user to run the agent in service mode. |
| | {code} |
| | #RUN_AS_USER= |
| | {code} |
| | The service user should own the agent installation directory. |
| | # Run _<agent install dir>/bin/agent.(sh|bat) install_ to install agent as system service. |
| | # Edit security group associated with the launched instance to allow incoming connections to agent port. |
| | # Restart launched node. After the system comes up, the build agent should be started automatically and will contact QuickBuild server to download necessary plugins. You may check file _<agent install dir>/logs/console.log_ for the progress and possible errors. |
| | # If agent starts up normally, you should be able to see this agent appears at _unauthorized nodes_ list at grid page. Authorize the node and wait for a while to see if it can come active. |
| | # If the agent comes active, create a EBS AMI for the launched instance and this AMI can then be used to define your cloud profiles to run certain builds. After build agent AMI is created, you may terminate the manually launched instance. |
| | # You can certainly define multiple build agent AMIs for multiple cloud profiles to satisfy different build requirements. |
| | |
| | To use this feature, one has to enable the EC2 plugin by providing a property file containing your EC2 access keys in _Administration/Plugin Management_ page as demonstrated below: |
| | !ec2_config.png! |
Working with Cloud Profiles