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:
The steps we go through during the trial:
- Install XL Deploy on EC2 Linux instance as source
- Create Oracle Java Cloud Service instance as destination
- Prepare the XL Deploy user on the destination hosts for SSH access
- Create and discover the infrastructure and environment CI-s XL Deploy
- Execute the sample deployment
- 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.
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 &
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:
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.
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
Match User oracle
Match User otools
Match User xldeploy
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.