(For more resources related to this topic, see here.)
Auto reconfigure
Most application’s life cycle will involve using different databases in different environments. For example, you may use one database locally for development environments, but when you deploy to production, you will most likely have a production database in high-end machines. It can be a very tedious task to manage these changes during each deployment. AppFog supports the auto configure feature that automatically detects the database settings in your application and rewrites them using the bound service’s credentials and settings. However, only some of the frameworks, such as Ruby on Rails and the Java Spring framework, are supported by AppFog for auto reconfigure.
Enabling auto reconfigure
AppFog will turn on auto configure automatically if you deploy a Spring application with the javax.sql.DataSource bean defined in the spring context XML file. AppFog will parse this file and override the driver class, URL, username, and password that form to match the service bound to the application. The following is an example snippet of the Spring context XML that will enable the AppFog auto reconfigure feature during deployment:
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="jdbc:mysql://127.0.0.1:3306/test" />
<property name="username" value="spring" />
<property name="password" value="spring" />
</bean>
This is because this file includes a reference to the org.apache.commons.dbcp.BasicDataSource bean that implements the javax.sql.DataSource interface, and therefore turns on the auto reconfigure feature. This feature is very helpful because it enables developers to deploy to AppFog without changing a single line of code. AppFog supports more auto recon figure features for Spring applications for other services such as MongoDB, Redis, and RabbitMQ. There are a couple of requirements to enable auto reconfigure on AppFog, and they are:
- Only one javax.sql.DataSource bean definition should be allowed in the Spring context XML file.
- Only one type of service should be bound. For example, for a relational database, only either one of the bound MySQL or PostgreSQL will enable auto reconfigure.
Disabling auto reconfigure
In some situations, you may not want to use the auto reconfigure feature; for example, you may want to use other database solutions such as MongoDB from MongoLab, MySQL from RDS by Amazon Web Services, or your own database installation on the same infrastructure.
Java Spring application
If you don’t want to enable the AppFog auto reconfigure feature for your Java Spring application while creating the project, you can just select JavaWeb instead of choosing Spring.
Ruby on Rails
If you do not want to enable the AppFog auto reconfigure feature for your Rails application database, you can disable it easily by creating a new file config/cloudfoundry.yml and then add the following line to disable the auto reconfigure feature:
autoconfig: false
So all in all, AppFog’s auto reconfigure feature is a great time-saving option that allows you to deploy your app without even knowing the details involved, and you still remain in control, so if you don’t want to use it you can just disable it as we have seen earlier.
Custom SSL
If you are dealing with any sensitive information such as login credentials or credit card information, then having SSL is essential. SSL encrypts your data before it is sent, which can prevent man-in-the-middle attacks, where people intercept the data that otherwise would be transferred in plain text.
AppFog provides a default SSL for applications that use an AppFog-provided subdomain under *.af.cm. The AppFog platform enables developers to deploy applications that easily enable custom SSL. This feature is only available for a paid plan. At the time of writing, the cheapest plan that offers SSL is priced at $50 per month with one end point. Be aware that AppFog custom SSL support is currently available only for those applications on AppFog that are hosted in the Amazon Web Service infrastructure; thus, applications that are deployed to Rackspace, Windows Azure, and HP Cloud cannot use this feature even when you are using a paid plan.
The Install tool
To generate an RSA private key, you need to have OpenSSL installed on your machine. Most of the Linux distro install OpenSSL by default. To install OpenSSL in Windows, you need to download the installer from http://gnuwin32.sourceforge.net/packages/openssl.htm and then install it according to the installer instructions.
With OpenSSL installed, we can move on to generating our own private key.
Generating a private key
It is easy to generate an RSA private key using OpenSSL. openssl genrsa is the command to generate an RSA private key. Make sure OpenSSL’s bin folder is in the PATH environment variable, or you can use the console to navigate to OpenSSL’s bin folder. The location of the bin folder of my machine is c:Program Files (x86)GnuWin32bin.
c:Program Files (x86)GnuWin32bin>openssl genrsa -des3 -out server.key
1024
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
...........++++++
..........++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:
The preceding command will generate the RSA private key with 1024 bit strength. The pass phrase was required to generate the key but we will remove it later.
Generating Certificate Signing Request
In Public Key Infrastructure (PKI) systems, a Certificate Signing Request is a message sent from an applicant to the Certificate Authority in order to apply for a digital identity certificate. So we need to generate a Certificate Signing Request for the Certificate Authority to sign. To generate a Certificate Signing Request, use the openssl req command:
c:Program Files (x86)GnuWin32bin>openssl req -new -key server.key -out
server.csr
Loading 'screen' into random state - done
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:MY
State or Province Name (full name) [Some-State]:Kuala Lumpur
Locality Name (eg, city) []:Kuala Lumpur
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dream and Me
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:Dream and Me
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
If you are on a Windows machine and encounter the following error:
Unable to load config info from /usr/local/ssl/openssl.cnf
Then you need to add the following for the command to load the config file from the custom location:
-config "C:Program Files (x86)GnuWin32shareopenssl.cnf"
Please note that the path to the config file might be different based on your installation. You can send the created server.csr file to the SSL certificate provider to sign it. The next step is to remove the pass phrase protection so that we can use it on AppFog:
c:Program Files (x86)GnuWin32bin>openssl rsa -in server.key -out
server.key
Enter pass phrase for server.key:
writing RSA key
The new private key file will be created without the pass phrase protection. You will need to upload this new private key to AppFog.
Installing the SSL certificate
To install our new SSL certificate to AppFog, we will need to log in to the AppFog web console. On the main page, open the SSL tab and click on the Get Started button. On the new page, you will need to upload the server.csr file along with your server.key private key. Once they are uploaded, AppFog will provide you with an SSL terminator that will look like the following:
af-ssl-term-0-000000000.us-east-1.elb.amazonaws.com
You will need to sign in to your domain provider and create/modify CNAME to point to the SSL terminator provided to you. It could take a while for the DNS to propagate, but once done, you will have your custom SSL set up! This will give your users more confidence in your application, and is a lot more secure than the HTTP protocol.
Teams
Most applications are developed by teams, and deploying them is no exception. As such, AppFog allows you to create and manage teams with permissions for starting, stopping, and restarting applications. This feature is still in beta and only available to the paid plans, as of the time of writing this article.
Once you start using the paid plan, you can navigate to the Teams tab and start to invite people to join your team. Once the invitation is approved by the user, then he/she can start to manage your application! You can also manage team members from the console as follows:
c:optappfog-starterappfog-blog>af -u [email protected] update appfogblog
Currently, the team feature only supports basic permission controls, but in the future, AppFog will implement more complex authorizations, such as roles and groups, which will allow different permissions for different environments, such as allowing QA engineers to be able to manage only the QA environment but not production applications.
Third-party add-ons
AppFog provides third-party services that you can easily install and tie into your application. A list of add-ons can be found in the Add-ons tab of the application’s details page. These add-ons can be very useful for developers, such as the Mailgun add-on, which provides a service for developers to send e-mails via the cloud without setting up a mail server or relying on the Gmail SMTP that will limit the request. Another useful add-on is Blitz, which is a cloud-based load testing tool for developers to find performance bottlenecks. This add-on allows you to easily set it up and start load testing in minutes!
Installing an add-on
A great example for showing off the process of using an add-on is the Logentries add-on. The Logentries add-on allows you to manage your application’s logs from the cloud. To install it, just go to the Add-ons page and hit the Install button, which you will find right under the description, as shown in the following screenshot:
Managing add-ons
After successfully installing an add-on, you will see two buttons being displayed that will help you to manage the add-ons:
After clicking on the Manage button, you will be able to sign in to Logentries with a single sign-on feature. AppFog and the AppFog add-on provider provide good integration that allows you to sign in to the add-on console without a username and password as they are integrated using a single sign-on.
Configuring Rails to use Logentries
The next step is to set up your application to use Logentries. For a Rails application, you need to add the le gem into the Gemfile and then install it with a bundler using the bundle install command.
Once installed, we need to configure the logger by modifying the config/environment.rb file. All you have to do is just add the following lines:
if Rails.env.development?
Rails.logger = Le.new('LOGENTRIES_TOKEN', true)
else
Rails.logger = Le.new('LOGENTRIES_TOKEN')
end
Replace LOGENTRIES_TOKEN with the token created in the Logentries UI. The second parameter tells the app if it should be dumped to the console instead. So for development, we will just be printing our errors to the console, whereas in production, we will be logging to the Logentries service.
Rails.logger.info("information message")
Rails.logger.warn("warning message")
Rails.logger.debug("debug message")
For more information on Logentries, you can view its documentation page at https://logentries.com/doc/.
There are many other add-ons such as Redis Cloud, IronWorker, Blitz, Mailgun, and more. All of these add-ons provide good documentation on how to install, configure, and use them in your application. This is just another great example of how AppFog speeds up the development process for developers besides just providing a great infrastructure to work on.
Tunnel
AppFog secures its services, such as databases, from outside access, which is great in most situations, as only your application should have access to the database. However, there are situations where you will need remote access, for example, while running ad-hoc queries against your database for one-time analysis. For these types of situations, you will need to tunnel into the AppFog environment to locally access the resources.
Install Caldecott Gem
To begin with, we need to install the caldecott gem that will allow us to connect through TCP over an HTTP tunnel.
c:optappfog-starterappfog-blog>af tunnel
appfog-blog-data
To use af tunnel, you must first install caldecott:
gem install caldecott
Note that you’ll need a C compiler. If you’re on OS X, Xcode will provide one. If you’re on Windows, try DevKit.
To install caldecott, simply run gem install caldecott from the console. With it installed, we are ready to create a tunnel.
Tunnel to service
You can use the af tool to create a tunnel and bind a local port to the remote port on the AppFog infrastructure. Just run af tunnel <servicename> [–port], where <servicename> is the name of the service you want to tunnel to, and you can optionally specify the port number to bind to.
c:optappfog-starterappfog-blog>af tunnel appfog-blog-data
Getting tunnel connection info: OK
Service connection info:
username : uf52effea2387407ba14bb0d94b820af1
password : pf79b4c9e197841298386f2543a5d7857
name : d5198ab07a6434a68adeaa9162e31e8d5
infra : rs
Starting tunnel to appfog-blog-data on port 10000.
1: none
2: psql
Which client would you like to start?: 1
Open another shell to run command-line clients or
use a UI tool to connect using the displayed information.
Press Ctrl-C to exit...
During the tunneling process, you can choose to either run the psql client or none. In my example, I have chosen none since I will use PG Admin3 to manage. The following table shows the clients that can start by caldecott. You need to make sure the client executable is in the PATH environment variable.
|
Service
|
Client
|
|
MongoDB
|
mongo
|
|
MySQL
|
mysql
|
|
PostgreSQL
|
psql
|
If your favorite client is not in the list, you can choose none. The af tool will output the details of the credentials, so you can paste them into your favorite client to manage the databases.
The following is an example of me using PG Admin3 to sign in. Once connected, you can use it as if the database was local, view data, and even create new tables.
AppFog provides a secure channel for you to manage and tunnel your data service. Moreover, you can use your favorite database client, such as a MySQL workbench or pgAdmin3.
Export/import service
One of the features you must know is the export/import service. This feature allows you to export existing services’ data and import this data to new services. This is very helpful for developers to clone production data to another service for other purposes, such as to analyze data or use as a development database. At the time of writing, AppFog only provides the af tool to export/import services. You can export a service using the af export-service <service> command:
c:optappfog-starterappfog-blog>af export-service appfog-blog-data
Exporting data from 'appfog-blog-data': OK
http://dl.rs.af.cm/serialized/postgresql/
dcb9c83b851524c17bfc9778ba8f5c1ac/snapshots/1629?token=PEXKgYJy9B8e
After running the export command, you will be provided with a link to the snapshot. You can download it and take its backup. Using this link, you can import into a new service and initialize with the data. To import a service, you can use the af import-service <service> <url> command, where <service> is the new service’s name and <url> is the link you exported from another service.
For example, if you want to name the new service as appfog-blog-data-singapore, you can simply use the following command:
c:optappfog-starterappfog-blog>af import-service appfogblog-
data-singapore http://dl.rs.af.cm/serialized/postgresql/
dcb9c83b851524c17bfc9778ba8f5c1ac/snapshots/1629?token=PEXKgYJy9B8e
Importing data into 'appfog-blog-data-singapore': OK
It’s worth noting that you can only create a service of the same type with the snapshot tools. For example, you cannot create a MySQL database from the snapshot of a PostgreSQL database.
Cloning
We have just seen some features for cloning the database services. AppFog also offers a similar feature for your application itself. The cloning abilities allow you to replicate your application, optionally including the services. The difference between this and the previous export/import method is, of course, that here you clone the application as well. When cloning your application, you can choose a different infrastructure. So for instance, you may have deployed your app to the HP infrastructure, but the clone feature allows you to replicate it—let’s say, on the AWS cloud—with zero downtime. To clone a complete application including its services, you can use the Clone tab on the application’s admin section, as shown in the following screenshot:
Choosing an infrastructure
The first step is to choose the infrastructure, which, at the time of writing, had the following options:
- AWS Asia Southeast
- AWS Europe West
- AWS US East
- HP Openstack AZ 2
- MS Azure AZ 1
Choosing a subdomain
Your new application needs a new subdomain to map to. Currently, the AppFog clone feature is only able to map to the *.af.cm subdomain when you clone, but once the application is set up, you can map your own custom domain.
To clone an application from the command line, you can use the af clone <src-app> <dest-app> [infra] command. To view a list of the available infrastructures, you can just run the af infras command:
c:optappfog-starterappfog-blog>af infras
+--------+-------------------------+
| Name | Description |
+--------+-------------------------+
| aws | AWS US East - Virginia |
| eu-aws | AWS EU West - Ireland |
| ap-aws | AWS Asia SE - Singapore |
| hp | HP AZ 2 - Las Vegas |
+--------+-------------------------+
So, to clone your application to AWS Singapore, just execute the following:
c:optappfog-starterappfog-blog>af clone appfog-blog appfog-
blogsingapore-
clone ap-aws
1: AWS US East - Virginia
2: AWS EU West - Ireland
3: AWS Asia SE - Singapore4: HP AZ 2 - Las Vegas
Select Infrastructure: 3
Application Deployed URL [appfog-blog-singapore-clone.ap01.aws.af.cm]:
Pulling last pushed source code: OK
Cloning 'appfog-blog' to 'appfog-blog-singapore-clone':
Uploading Application:
Checking for available resources: OK
Packing application: OK
Uploading (33K): OK
Push Status: OK
Exporting data from appfog-blog-data: OK
Creating service appfog-blog-singapore-clone-data: OK
Binding service appfog-blog-singapore-clone-data: OK
Importing data to appfog-blog-singapore-clone-data: OK
Staging Application 'appfog-blog-singapore-clone': OK
Starting Application 'appfog-blog-singapore-clone': OK
This simple one-line command just cloned your entire application from one infrastructure to another within minutes! Cool, right? You can then view the new application from the web console and check its status.
AppFog provides an awesome clone feature that allows you to clone an application from one infrastructure to another. While this needs to be carefully done on a production application, this feature still has many use cases that will ease the developer’s workload.
As I hope you have now seen, AppFog is not just a simple PaaS that allows you to deploy applications. AppFog extends this basic functionality with tons of features such as custom domains, app-cloning, and multiple data center setup options. Besides offering amazing features for developers, AppFog also offers features for your customers, such as allowing you to deploy to their location, for example Singapore, which will decrease the latency across Asia.
Third-party add-on is yet another cool feature that is available on the AppFog platform. For example, MongoLab/MongoHQ provides free add-ons to an AppFog user with maximum 500 MB of storage, which is a huge amount of storage and is enough for small productions. Moreover, Logentries allows you to rapidly develop and test your backend with load testing and logging features
Summary
This article introduced you to the AppFog features and showed how to use them in a real-world environment. The features included load balancing, SSL, add-ons, teams, clones, tunnels, and so on.
Resources for Article :
Further resources on this subject:
- Introduction to Cloud Computing with Microsoft Azure [Article]
- Apache CloudStack Architecture [Article]
- Troubleshooting in OpenStack Cloud Computing [Article]
