In this article I will show you how to set up and run Radiant CMS on DB2 Express-C in the Cloud. Before getting started, let’s define each of these components:
In order to run Radiant and DB2 in the Cloud and follow this tutorial, you’ll need to register with both Amazon Web Services and RightScale. You will also need to explicitly provide your AWS credentials to RightScale in order to manage Amazon’s services. If you haven’t taken these steps already, you can follow this short screencast to learn how to do so now.
Rather than setting up the whole deployment stack from scratch, when using RightScale you can use special templates called RightScale ServerTemplates. These will take care of installing the required stack for you, thereby saving you time – and a possible headache, too.
IBM provides a RightScale ServerTemplate for your convenience called “Radiant CMS on IBM DB2 Express-C”, which installs Apache, Rails, Radiant, and DB2 on CentOS. Thanks to this template, it’s possible to have a Radiant and DB2 stack running in the Cloud in just a few minutes. This tutorial will show you how.
Before adding a server to our deployment we need to create a security group. This is a set of firewall rules that are used to define which ports are open on the server, as well as which IPs are accepted.
A security group is created within a specific geographical Cloud. For our particular ServerTemplate, the currently supported Clouds are US-East, US-West, EU, and AP-Singapore. AP-Tokyo is likely to be added in the upcoming weeks.
Select a Cloud of your choice (the closest one to you will do) and create a new security group from the Clouds menu as shown in the figure below.
You’ll be asked to provide a name for the group. It’s best to call it something meaningful, such as DB2 Public Access or Default Web Access. When prompted, you should open port 80 (for the web server) and port 50000 (for DB2), but you may want to enable port 22 as well for SSH access (admittedly not quite a best practice, but let’s keep things simple and standard), and any other port you think you may need. In the input mask, use 0.0.0.0/0 to indicate that all IPs are accepted for such ports.
The first step will be importing IBM’s template in our RightScale account from the RightScale public Library. You can always find a link to said library by clicking on the Design menu and then on Library. There you’ll be able to search and browse all of the available templates. For your convenience, here’s a link you can click to bring you directly to the Radiant CMS on IBM DB2 Express-C template.
Click import and you’ll be prompted with a DB2 Express-C licensing agreement. Read it through (cough) and if you agree with the terms, click the accept check box and then Finish. The ServerTemplate will be imported for you, as shown in figure below.
At this point, you can click Add To Deployment and select one of the available Clouds that are close to you (e.g., AWS US-East). Select the same Cloud you picked when creating a security group and then click Continue.
In the new popup dialog, you can select several parameters like Deployment, MultiCloud Image, Nickname, and so on. You can leave all the defaults on, but you should specify an Instance Type and Security Group(s). The former indicates what type of EC2 instance you need for your server (e.g., a micro instance), while the latter should be the security group (or groups) you created earlier on.
Keep in mind that Amazon will charge you based on an hourly basis, as well as depending on the instance type and Cloud you chose. A micro instance on the US-East Cloud as per this example is the cheapest solution. (Amazon even allows new customers to obtain a micro instance for free for the first year.)
You will be redirected to the deployment you specified or that was selected by default (the default is unsurprisingly called Default). From this deployment you’ll be able to administer your instance of the server. (Note: You can always access your deployments from the Manage -> Deployments menu link.)
From within the Default deployment, start the server by clicking the triangular blue launch icon on the right side of the screen, which is located on the same line as your server’s nickname.
On the new page that appears, click the Launch button. The server will boot and you’ll be brought back to your deployment. While the server boots, you should see several status update messages that will help keep you in the loop regarding the status of the server.
If all goes well, and depending on your Cloud/instance choices, you should have the server up and running (i.e., the status will be operational) in five minutes or less.
You can now click on the nickname of the server (e.g., Radiant CMS on IBM DB2 Express-C), where you’ll find a clickable link corresponding to the “Public DNS name”. If you click on this link a Radiant CMS installation should appear.
Append /admin to that URL, and you’ll be able to login with the default username (admin) and password (radiant). From there you can experiment and change things as you wish in order to make the site yours. Your changes will be persisted in the database, even if you reboot your instance.
To learn more about how to use Radiant as you play around with it in the Cloud, feel free to consult the official Radiant documentation.
That’s it. Enjoy Radiant CMS and DB2 in the Cloud.
Remember to stop your server if you are not using it in production or if you were just experimenting with it and you don’t need it at the moment. Keep in mind that Amazon will charge you for the time you have the server up (unless of course you took advantage of the AWS Free Usage Tier). You can stop a server from the deployment or by clicking the Stop button from the server information page where you found the public DNS name.
If you plan on keeping the server running, you must change your Radiant CMS admin password to a stronger and more secure one. You can do so from /admin, by clicking on the Users link at the top of the page, and then on Administrator.
At this time the ServerTemplate doesn’t allow you to change the password for DB2 users. You must do so manually from the console. It’s important that you change the password for the database/system users db2inst1, dasusr1, and db2fenc1 from ‘password’ to more secure ones. If you don’t take this step, you run the risk of having your server hacked in no time. When you update the password for these three users, you also need to update the /opt/www/blog/config/database.yml file with the password you just changed for the database/system user db2inst1.
You can access a root SSH console for your server from the deployment area (when the server is running a small console icon is visible). Click on this icon, then select the type of console that you want to operate (OpenSSH or Mindterm), and accept the RSA key fingerprint that you’re presented with. As root you can fully manage the server, including changing passwords for users (e.g., passwd db2inst1).
Of course, if you are just demoing or experimenting for 15 minutes, you can probably ignore these password related steps (which are quick, but admittedly more tedious).
If you have any questions, please feel free to ask in the comment section or via email.
I sincerely welcome and appreciate your comments, whether in agreement or dissenting with my article. However, trolling will not be tolerated. Comments are automatically closed 15 days after the publication of each article.