In my previous post, I described how to set up a Weblogic cluster in Amazon EC2 using the Oracle-supplied Amazon AMI image. In this post, I will describe how to create a cluster using RightScripts, an alternative technology offered by RightScale.
In Amazon EC2, you work on an AMI – installing software, configuring – until you are happy with it. Then you ‘freeze’ it, storing it in S3 so that you can create many different instances based on this AMI. Amazon give you the possibility to pass configuration data to each new instance using “user-supplied data” which allows you do differ one launched AMI from another.
RightScale offer you an alternative. Instead of doing all the installation and configuration work on an AMI and then freezing it, you capture all the installation and configuration work in scripts – RightScripts. Each time you start up an instance in RightScale, you decide which RightScripts to execute against a base operating System to construct the complete machine that you wish to deploy.
For example, if you want to deploy an Apache Web Server, you write a RightScript that downloads, installs and configures Apache. You start up a new instance (with a base operating system e.g. CentOS) and run the RightScript. Once it has finished, you have an Apache server up and running. You can even associate one or more RightScripts with a base AMI to make a RightScale Server Template.
The benefits over the use of highly personalised AMIs are:
- It is easier to change the configuration of your machines in the future – you can just execute another RightScript ‘on the fly’
- You are not tied to one particular cloud vendor. RightScale allow you to execute RightScripts on machines in non-Amazon clouds
This article will show you how to create a Weblogic cluster using RightScale Server Templates made up of various RightScripts. You will need some familiarity with Amazon EC2 and S3 to get the full benefits from this article and I also assume that you’ve read my previous post on this theme.
You will need to sign up for a RightScale account to follow the steps in this post.
We will create two server templates – one for the primary cluster node that runs the admin server and a managed server and one that contains just a managed server. We will create these templates from various RightScripts that completely automate the installation and configuration process and just require a few variables to be set. This should mean that we can deploy many managed server instances with just a few clicks.
Creating the RightScripts
Log into the RightScale service and click on the Design > RightScripts link in the navigation bar on the left. Click on the ‘new’ button to add a RightScript and add each of the scripts described below, naming them the same as the header:
This script installs weblogic on top of the base operating system. It relies on a tar-gzipped copy of the Weblogic installation being stored in an S3 bucket (folder) to which you have access. To create this copy (a one-off procedure), run an instance based on AMI “ami-6a917603″ and execute the following commands, substituting “my-new-bucket-name” for an Amazon S3 bucket name that does not already exist e.g. [my-company-name]-[weblogic]
wget ftp://mirror.switch.ch/pool/1/mirror/epel/5/x86_64/s3cmd-0.9.9-1.el5.noarch.rpm rpm -ivh s3cmd-0.9.9-1.el5.noarch.rpm tar -czvf /tmp/oracle-weblogic-103.tgz /opt/oracle s3cmd mb s3://my-new-bucket-name s3cmd put /tmp/oracle-weblogic-103.tgz s3://my-new-bucket-name/oracle-weblogic-103.tgz
(For more information on s3cmd, see here).
You can check that the weblogic zip was uploaded correctly using a tool such as S3Fox.
Here is the RightScript. Substitute “my-new-bucket-name” for the bucket name you created in the step above.
#!/bin/bash # NOTE: relies on AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables having been set. echo "Using AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID" echo "Using AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY" # get WL zip out of S3 using the s3cmd tool that's installed by default s3cmd get my-new-bucket-name:oracle-weblogic-103.tgz /tmp/wl.tgz # untar WL to install it tar -zxvf /tmp/wl.tgz -C / # report success exit 0
Install the Domain
When I say “install”, I really mean “extract”! Download the test_domain Domain from here and use S3Fox or another equivalent tool to copy it over to the “my-new-bucket-name” folder in S3 that you created earlier. The RightScript below retrieves this domain from S3, extracts it and places it in the /mnt/domains folder. You must substitute “my-new-bucket-name” for your S3 bucket name. This domain is a basic domain that has no servers or clusters configured – these will be configured later in RightScripts.
#!/bin/bash # NOTE: relies on $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY environment variables having been set. # get domain zip out of S3 using the s3cmd tool that's installed by default s3cmd get my-new-bucket-name:test_domain.tgz /tmp/test_domain.tgz # untar domain to install it tar -zxvf /tmp/test_domain.tgz -C / # report success exit 0
Start Weblogic Admin Server
This script simply runs the admin server and redirects output to a log file. This should probably be replaced with an init.d script in a production setup.
#!/bin/bash mkdir /mnt/logs/ # start up weblogic nohup /mnt/domains/test_domain/startWebLogic.sh > /mnt/logs/weblogicAdmin.log 2>&1 &
This script contacts the Administration server on a defined hostname and port and creates a Weblogic cluster using the Weblogic Scripting Tool (WLST).
#!/bin/bash -e PY_FILE="/tmp/create-cluster_"`date "+%s"`.py cat < $PY_FILE connect('$ADMIN_SERVER_USERNAME', '$ADMIN_SERVER_PASSWORD', 't3://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT') edit() startEdit() cd('/') cmo.createCluster('$CLUSTER_NAME') cd('/Clusters/$CLUSTER_NAME') cmo.setClusterMessagingMode('unicast') cmo.setClusterBroadcastChannel('') activate() EOF /opt/oracle/weblogic/common/bin/wlst.sh $PY_FILE rm -rf $PY_FILE
Add Server To Domain
This script uses WLST to connect to an admin server and create a new server in the domain. The server’s name will be that of the machine’s EC2 public DNS name.
#!/bin/bash -e SERVER_NAME=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname") SERVER_LISTEN_ADDRESS=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname") PY_FILE="/tmp/create-server_"`date "+%s"`.py cat < $PY_FILE connect('$ADMIN_SERVER_USERNAME', '$ADMIN_SERVER_PASSWORD', 't3://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT') edit() startEdit() cd('/') cmo.createServer('$SERVER_NAME') cd('/Servers/$SERVER_NAME') cmo.setListenAddress('$SERVER_LISTEN_ADDRESS') cmo.setListenPort($SERVER_PORT) cmo.setCluster(getMBean('/Clusters/$CLUSTER_NAME')) activate() EOF /opt/oracle/weblogic/common/bin/wlst.sh $PY_FILE rm -rf $PY_FILE
Start Managed Weblogic
This script starts up a Weblogic managed server instance which connects to the admin server and downloads all the domain info required. It relies on being able to download a security file – SerializedSystemIni.dat from your “my-new-bucket-name” folder in S3. Download this file here and upload it to S3 using S3Fox or an equivalent tool. Change the “my-new-bucket-name” folder in the script below to reflect your bucket name. This should probably be replaced with an init.d script in a production setup.
#!/bin/bash # uses $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY SERVER_NAME=$(eval "curl http://169.254.169.254/latest/meta-data/public-hostname") START_ROOT=/tmp DOMAIN_HOME=$START_ROOT/servers/$SERVER_NAME/security BOOT_FILE=$DOMAIN_HOME/boot.properties # create the server domain directory structure mkdir -p $DOMAIN_HOME mkdir -p /mnt/logs # create the boot.properties file echo "username=$SERVER_USERNAME" >> $BOOT_FILE echo "password=$SERVER_PASSWORD" >> $BOOT_FILE echo "using admin URL: http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT" mkdir -p $START_ROOT/security s3cmd get my-new-bucket-name:SerializedSystemIni.dat $START_ROOT/security/SerializedSystemIni.dat # start up weblogic cd $START_ROOT nohup /opt/oracle/weblogic/common/bin/startManagedWebLogic.sh $SERVER_NAME http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT > /mnt/logs/weblogicManaged-$SERVER_NAME.log 2>&1 &
Create the ServerTemplates
Now that we have the basic RightScripts to construct Weblogic instances, we can create the ServerTemplates that logically group the scripts together.
Click on the Design > ServerTemplates link in the navigation bar in RightScale. Click on ‘new’ to create a new Server Template and call the template “Weblogic Admin”. Choose “EC2 US” and “m1.small” for the cloud and instance type attributes respectively. Use the browser tool to select the image “RightImage CentOS5_2V4_1_10″. Leave the rest of the attributes as their defaults and click ‘save’.
Click on the ‘scripts’ tab in the newly-created server template and add the RightScripts that you created earlier as boot scripts, in the following order: Install Weblogic, Install Domain, Start Weblogic Admin Server, Create Cluster, Add Server To Domain, Start Managed Weblogic. As you can see, this should install a weblogic server, create the domain and start the admin server. It should also create a cluster and a server in the domain and then finally start up the server.
Create another server template called “Weblogic Managed” with the same cloud, instance type and image attributes as “Weblogic Admin”. Add the following scripts as boot scripts in this order to the template: Install Weblogic, Add Server To Domain, Start Managed Weblogic.
Start the instances
In the RightScale navigation bar, go to Manage > Deployments and click on ‘default’. Click on “Add EC2 US server”. For the Server Template, select Private > Weblogic Admin. Enter “Weblogic Admin 1″ as the nickname and choose the SSH key that you want to use. Use a security group that has ports 7001 and 7002 open. Leave the rest of the attributes as defaults and click “Add”.
Repeat these steps to create “Weblogic Managed 1″ which uses the Weblogic Managed template. You should now have two servers configured in the “Default” deployment and it should look something like the screenshot below (note that my servers are in the EU):
Launching the servers
Click on the launch icon next to the “Weblogic Admin – 1″ server and you should see a screen prompting you for some parameters. These are all the input parameters required by the RightScripts that will run at boot time. Enter the information as shown in the screenshot below and click on the ‘Launch’ button:
Wait until RightScale shows the status of the server as “operational” – this can take a while (8mins or so), so be patient! Once it’s started, click on the server name and then on the audit entries tab. The latest audit entry should have status “operational”. Click on this and you should see a list of the scripts that ran at startup and their outcomes:
On the info tab of the server, you should see the public DNS name of the server e.g. “ec2-79-125-41-54.eu-west-1.compute.amazonaws.com”. Go to the URL: http:://[public-dns-name]:7001/console and log in with the username/password weblogic/weblogic.
If you click on the environment > servers link, you should see an Admin server and a managed server configured in a cluster. The managed server name should correspond to the public DNS of the machine:
Now, in the RightScale console, start up the other server – “Weblogic Managed – 1″ using the following inputs (substituting “Weblogic Admin – 1″ for “Weblogic EU Admin – 1″) :
Once the managed server has started up, hit refresh in the Weblogic console. You should see the second managed server appear and the screen should look something like my one below:
Using the RightScripts provided in this post, you can easily deploy a Weblogic cluster using just two server templates. Adding new nodes is simple – just create another server based on the “Weblogic Managed” template and when the node starts up, provide it with the parameters it needs to connect to the admin server. The RightScripts take care of the rest for you.