This article is about experimenting configuration, connection and deployment from one cloud instance to the other using the basic installation, connections and features like on a local network. I will demonstrate how to deploy a Java application on the Oracle Java Cloud Service (JCS) using XL Deploy (running on AWS EC2).

To go further with special cloud facilities instead, consult the XebiaLabs documentation or blog:

• XebiaLabs’ EC2 plugin for XL Deploy
• XL Scale
• XL Deploy and Amazon AWS OpsWorks (© by Andrew Phillips)

The steps we go through during the trial:

1. Install XL Deploy on EC2 Linux instance as source
2. Create Oracle Java Cloud Service instance as destination
3. Prepare the XL Deploy user on the destination hosts for SSH access
4. Create and discover the infrastructure and environment CI-s XL Deploy
5. Execute the sample deployment
6. Verify the access to the deployed service

XL Deploy on EC2

First of all, we need the proper access to AWS to set up an EC2 instance for XL Deploy. It is possible either through a business (e.g. employer) or a private account: https://aws.amazon.com/

Once in EC2, we can create an instance, which is adequate for an XL Deploy server.

According to the system requirements and my goals, I chose Amazon Linux platform of the type t2.medium, but it is up to the actual purpose.

We could accept all defaults but it is very handy to give it a good name and also some safety like termination protection.

After the (recommended) security group assignment, we can review it and launch.

As part of the launch we must have a security key pair for (initial) connection to the instance. Either use an existing PEM or obtain a new pair and save it for your SSH client.

Once created, the instance will have a Public IP address assigned. In order to stick this IP to the instance we may allocate and associate an elastic IP to it. This depends on the allocation limit and the active associations.

What we have now, is a Linux machine with a static, public IP address, a DNS host name, the group of IP addresses where we can access the instance from, the standard ec2-user to log in and the key pair for our SSH client.

We need an SSH client to run a terminal on the instance (I used PuTTY) and some tool using SCP to upload the XL Deploy installation pack (I used WinSCP). Don’t forget to assign the private key from the previously specified or downloaded key pair to the client sessions.

Following the Installation Manual we should have a working XL Deploy server instance with default or customized settings. This trial instance is just using http connection on port 4516 to bypass the certificate limitations.

Let’s start it up detached from our session. We have two options, either use the service installation method with the service wrapper, or execute:

nohup /app/software/xebialabs/xl-deploy/xl-deploy-5.1.4-server/bin/run.sh > $HOME/xld.out 2>&1 &

in which case we need the process ID for a later shutdown (kill the process).

We can then log out from the instance and open the XL Deploy GUI from our location.

Oracle Java Cloud instances

This article is going to show the deployment of the XL Deploy sample application PetClinic. This is a generic Java Web Service for which we need an application server container and not necessarily WebLogic.

Yet, for this case we configure a WebLogic instance, as that comes with the JCS instance, furthermore was my real target project an ADF application, PetClinic I took for this article only.

First we need a subscription to the cloud service, either trial or normal.
Getting started with Oracle Cloud: Requesting a Trial Subscription
An existing Oracle account is a requirement of course.

Once registered, you can see the different cloud services on the dashboard, including Database Cloud, Storage Cloud, Compute Cloud and Java Cloud.

Next action is to create your Java Cloud Service Instance. The linked tutorial leads you through all the necessary steps including SSH key generation, storage containers, database instance and java service instance.

It is very important to use the copy-paste method to save the SSH public key.

Also, backup-restore container is optional for a database instance, however, when creating a Java Cloud instance, only databases with an assigned container will be available to select.

In my case, storage containers are called TrialDBContainer and TrialJCSContainer. I used one managed server and no load balancer.

Accordingly, the storage container commands are (replace the tutorial name with them):

curl -i -X PUT -H “X-Auth-Token: AUTH_tk55709e8b2ee18df85901bd821e55bb1d” https://em2.storage.oraclecloud.com/v1/Storage-ahetenyi/trialJCSContainer

curl -i -X PUT -H “X-Auth-Token: AUTH_tk55709e8b2ee18df85901bd821e55bb1d” https://em2.storage.oraclecloud.com/v1/Storage-ahetenyi/trialDBContainer

The tutorial reminds you that the tokens are temporary and you have to renew them after 30 minutes.

In the Java Cloud instance section, it refers to the WebLogic management consoles and SSH connection. However, initially, the network rules to access these features may be disabled. They must then be enabled through the Network section of the Compute Cloud Service.

Additionally, in this sample, I configured my managed server to listen on ports 8001 and 8002 (SSL). There was no predefined security rule for these ports, which means they are closed and needs to be opened. We use the same network section to allow them.

First we create a Security Application (I called it adf) for the ports:

Next, we link this application to the managed server creating a new Security rule (I called it ora_p2ms_adfhttp).

This rule takes care to access our application from the browser once deployed. You can test revoking the access by disabling the rule, then the page will not show up any more.

Prepare the Cloud target instances for XL Deploy

Similar to the EC2 instance, we can now access the JAVA and Database Cloud instances via the SSH connection. The public IP address is available in the service instance details.

This time, the user to connect is opc. We have to add the private key file, we generated during the tutorial, to the session (the PPK format when using PuTTY or the OpenSSH format with other client).

The opc user is able to become root

sudo su –

and so manage additional users like the xldeploy we need for discovery and deployment.

useradd xldeploy
passwd xldeploy

This new user is not yet eligible to do a deployment. See the Middleware Server Requirements in he XL Deploy installation.

The database and WebLogic installation is owned by the oracle user. To simplify the rights, just let xldeploy execute all commands as oracle.

Still as root, edit the sudoers file (e.g. running visudo). Locate the corresponding section and define the new rule:
…
## Allow root to run any commands anywhere
root  ALL=(ALL)   ALL
## Allow xldeploy to run any commands as oracle anywhere
xldeploy    ALL=(oracle) NOPASSWD:  ALL
…
The SSH access for xldeploy is also incomplete. First of all, we have to register it for access.

After, even though we gave a password to xldeploy user, we are not yet able to login with it using that password. The XLD Remoting plugin provides the option to use a private key. Still, if we decide to use password authentication, it requires further adjustment.

Again as root, edit the /etc/ssh/sshd_config file. Locate the (probably last) section and modify AllowUsers. Using key file only, you can set the last value as no:

AllowUsers  opc  oracle otools xldeploy
Match User opc
PasswordAuthentication no
Match User oracle
PasswordAuthentication no
Match User otools
PasswordAuthentication no
Match User xldeploy
PasswordAuthentication yes

Restarting the SSHD process is required:

Set up Java Cloud target in AWS XL Deploy

Now, from XL Deploy on the EC2 instance, we can create the target host infrastructure items, verify the connection to them and discover the WebLogic domain on our Java Cloud instance.

Create the logical environment and assign the target containers to it:

Let’s import the PetClinic package the usual way and we can execute  the deployment.

Connect to the deployed application

In case of success, let’s verify the result. From the Java Cloud Instance’s WebLogic console, locate the deployed application in Deployments. Go to the Testing page to identify the entry points.:

As we see, the entry points contain local IP address rather than public. For the URL we use for testing, we have to replace it with the public IP.

Then we should finally see the home page of PetClinic.