Recently (October 2016) I had the opportunity to attend an Oracle Compute Cloud workshop that was very interesting. As a side effect I got access to the Cloud for a month thus I could experiment with the Cloud outside the workshop as well.
I’ve had some experience with Amazon EC2 and with creating my own image to upload to that Cloud. There are some nice articles out there on how to do that. I’ve used Jeff Hunter’s article last year, and used that to upload an Oracle Linux 6.x image to Amazon. I ran into some issue’s there due to the fact that I’m not based in the US and needed to upload to Ireland but somehow my S3 bucket got created in the US. The uploading was pretty tiring because of the many pieces I had to cut my image into and the fact that it failed many times. Probably due to my home connection but irritating none the less. But that is not what this blog is about and might be an other blog’s topic.
The Oracle documentation makes it seem very easy to create and upload your own Linux image into that Cloud. A tutorial can be found here.
I thought it might be a good thing to start with OL 7.2 and get some more experience with that as well. But that turned out to be a mistake. The time I was trying to get my own image of OL7 in the Cloud I could not find one provided by Oracle. But at the end of my trial period I noticed that there were some available. I hadn’t seen them before, the documentation did mention that OL7.2 is supported. I might write a part two to blog about that, but I want to test some more and hope to be able to get an other trial account so I can finish that successfully as well.
In part one I will describe what I did to create and upload my own OL 6.7 image. Basically it is the same as what was written in the tutorial mentioned above. A few things I did differently.
First of all I did a minimal server install and enabled ssh for the root account by editing the file: /etc/ssh/sshd_config and set PermitRootLogin to without-password.
PermitRootLogin without-password
I also added my public key to the authorized_keys file for the root account. I did this because I needed to test my configuration of the cloud scripts and I wanted to make sure I could login. Of course you do not want to do this for your production cloud images. I could also have used Jeff Hunter’s script for Amazon and edited it to work for the Oracle Cloud. That would probably have been an easier way to fix my root access without putting my public key in the image. Because I know that script works fine. But I decided to install cloud-init via the epel repository. I also could have used opc-init from Oracle. But that isn’t available (yet?) for OL7.x and that was my first choice. For OL6.7 you can download it from here.
You also need to set your network interface to get it’s ip address via dhcp because it will be provide by the Cloud tools to your instance, and have it start at boot. If you do not have network access you will not be able to access your host.
My ifcfg-eth0 looks like:
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
Before you shutdown your VirtualBox server to convert it to a raw image you should also remove the file: /etc/udev/rules.d/70-persistent-net.rules and make sure your ifcfg-eth0 file in /etc/sysconfig/network-scripts/ doesn’t have HWADDR and IPADDR specified.
For the other steps I followed the tutorial.
The easy part comes next. To convert your virtualbox vdi file to a raw image:
VBoxManage internalcommands converttoraw /path/to/myVM.vdi /path/to/myImage.img
To make the image sparse I followed the tutorial by using:
cp --sparse=always /path/to/myImage.img /path/to/myImage_sparse.img
But on my iMac that doesn’t work nor in cygwin on my laptop. Thus I had to use an other VirtualBox linux instance to make the image sparse and create a tarbal.
Now the easy part of Oracle Cloud comes. You logon to your Compute Cloud and upload your image.
Select the tarbal that you just created with a descriptive but short name. E.g. OL67_8GB.tar.gz. Once that is uploaded (and at home that took about 30 minutes for 826MB and at work it was done in a few minutes) you have to create a private image.
Select the just uploaded tarfile and give it some name.
Once that is done, you can start to create a server in the Cloud:
Choose the shape you want or need:
Fill in the instance details:
Make sure you select the SSH keys that you want associated with this instance once it is started and make sure you have a security list created that allows you to connect via ssh from the internet to your Cloud Instance.
Next select the storage that you want to use or keep the default values that are provided by the wizzard.
Notice that my 8GB image now is put on an 9 GB disk. You can also attach an existing volume here or add extra space for your instance.
Check your choices in the next step or go back and make some changes:
Press the Create button to kick your instance alive. Go get some coffee or something else because it takes some time before you will be able to login to your instance. First some orchestrations will be created and started. One Master Orchestration, One Storage Orchestration and One Instance Orchestration. They get names that are derived from the Name you used when creating the instance. See the previous image.
The master orchestration starts and starts the others when they should. First the storage needs to be created, once that is there the instance will be started. Or the instance orchestration that is.
When they all have started (and show status Ready) it will take some time before your instance will show up in your dashboard. It seems to take 10 minutes each time I tested it. But your instance is available sooner. But as I used an Auto Generated Public IP address I had to wait to be able to see what IP address was used for my instance.
On your dashboard you will see the IP you need to use to login to your instance. As I had opened up root access I could login as root and see that it had been up for 8 minutes already.
Et voila, you have a server in the cloud.
You should be aware that once you STOP an orchestration it will DELETE the things it CREATED. Thus make sure you make yourself familiar with the Cloud before you are depending on it. Stopping the storage orchestration will DELETE the disk your server was using. Starting it again will create a new one. My trial is over and my servers have been deleted but I can’t wait to get working in the Cloud again. There is so much more to explore.
