This article is intended for developers new to anynines and Cloud Foundry. We will walk through the typical steps to deploy an application to anynines. You will learn how to use the cf command line tools to interact with the anynines servers.
We assume that you already registered with anynines.com and downloaded and installed the cf CLI tools from here.
Table of Contents
We created a simple example application for demonstration purposes. Please have a look at it here. It is a small, standard Rails app using ActiveRecord with a MySQL backend.
Let’s clone the application to our local machine:
[bash light=”true”]$> git clone https://github.com/anynines/simple_rails_app.git[/bash]
As we want to dive deeper into the cf command line, we won’t use a deployment manifest in this tutorial. For more information on deployment manifests please refer to our article dedicated to that topic.
Before deploying applications to anynines we need to choose the cloud’s API endpoint and login using our anynines user credentials:
[bash light=”false”]$> cf api https://api.de.a9s.eu
<pre>$> cf login
API endpoint: https://api.de.a9s.eu
Targeted org user_example_com
Targeted space production
API endpoint: https://api.de.a9s.eu (API version: 2.6.0)
Now we are logged in and targeting our production space.
As this is only a pet app we wouldn’t want to deploy to our production space directly. So let’s create a new space called “playground” to deploy our experiments to:
[bash light=”false”]$> cf create-space playground
Creating space playground in org user_example_com as firstname.lastname@example.org…
Assigning role SpaceManager to user email@example.com in org user_example_com / space playground as firstname.lastname@example.org…
Assigning role SpaceDeveloper to user email@example.com in org user_example_com / space playground as firstname.lastname@example.org…
TIP: Use ‘cf target -o user_example_com -s playground’ to target new space
As the tip suggests, we switch the space to our playground environment by using the cf target command:
[bash light=”true”]$> cf target -o user_example_com -s playground[/bash]
As we need a MySQL service instance for our demo application let’s have a look at the available plans:
[bash light=”false”]$> cf marketplace
Getting services from marketplace in org user_example_com / space playground as email@example.com…
service plans description
elasticsearch Pluto-free Elasticsearch search service
mongodb 100, Venus-20, Mercury-5 MongoDB NoSQL database
mysql Mercury-5, Pluto-free, Venus-20 MySQL database
postgresql Mercury-5, Venus-20, Pluto-free PostgreSQL database (vFabric)
rabbitmq 100, Venus-2 RabbitMQ message queue
redis 100, Venus-2 Redis key-value store
swift free Swift service
Let’s create a MySQL service instance using the Pluto-free plan:
[bash light=”false”]$> cf create-service mysql Pluto-free mysql-demo-instance
Creating service mysql-demo-instance in org user_example_com / space playground as firstname.lastname@example.org…
We can list the service instances in the current space using the following command:
[bash light=”false”] $> cf services
Getting services in org user_example_com / space playground as email@example.com…
name service plan bound apps
mysql-demo-instance mysql Pluto-free
As our service instance is ready, we can now proceed with our application deployment.
Use the cf push command for deploying applications. You can view a list of available options by using the –help option:
[bash light=”true”]$> cf push –help [/bash]
Let’s push our application to the servers:
[bash light=”false”]$> cf push mydemoapp -b ‘https://github.com/heroku/heroku-buildpack-ruby.git’ -c ‘bundle exec rake db:migrate; bundle exec rails s -p $PORT’ -d de.a9sapp.eu -i 1 -m 512M -n mydemoapp –no-start
Creating app mydemoapp in org user_example_com / space playground as firstname.lastname@example.org…
Creating route mydemoapp.de.a9sapp.eu…
Binding mydemoapp.de.a9sapp.eu to mydemoapp…
Uploading app files from: /Users/dude/Documents/rubydev/anynines/test_apps/ruby/simple_rails_app
Uploading 25.4K, 193 files
A short command explanation:
-b : specify the buildpack to use for configuring our application
-c : specify the start command for our application
-d : specify the domain to use for our application
-i : sets the number of instances for running our application
-m : sets the maximum RAM usage for our application
-n : sets the subdomain under which our application will be available
–no-start : don’t start the application immediately
We added the –no-start option since we did not connect our freshly created service with our application. We will do this in the next section.
A Service Binding represents a connection between an application and a service. The service connection information and credentials will be made available to the application via the VCAP_SERVICES environment variable. For more information on Service Bindings and usage please refer to our documentation.
We can create a binding like this:
[bash light=”false”]$> cf bind-service mydemoapp mysql-demo-instance
Binding service mysql-demo-instance to app mydemoapp in org user_example_com / space playground as email@example.com…
Now our application can read the connection and credential data needed to connect to our demo service. In this special case the buildpack will automatically create a database.yml file for us, so we don’t have manually adjust our application.
Let’s start our application:
[bash light=”false”]$> cf start mydemoapp
Starting app mydemoapp in org user_example_com / space playground as firstname.lastname@example.org…
Cloning into ‘/tmp/buildpacks/heroku-buildpack-ruby’…
—–> Compiling Ruby/Rails
—–> Using Ruby version: ruby-1.9.3
—–> Installing dependencies using 1.6.3
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
Showing health and status for app mydemoapp in org user_example_com / space playground as email@example.com…
requested state: started
usage: 512M x 1 instances
state since cpu memory disk
#0 running 2014-09-30 12:10:52 PM 0.0% 128.2M of 512M 92.3M of 1G
The push command will show the output of the buildpack bundling process and create a summary at the end.
We are able to access our application’s log output by using the cf logs command like this:
[bash light=”true”]$> cf logs mydemoapp[/bash]
This will tail the application logs to your developer machine’s console.
You can test it by opening up your browser and accessing the application’s route. This will produce the following output:
[bash light=”false”] Connected, tailing logs for app mydemoapp in org user_example_com / space playground as firstname.lastname@example.org…
2014-09-30T12:16:10.02+0200 [App/0] OUT Started GET "/" for 18.104.22.168 at 2014-09-30 10:16:10 +0000
2014-09-30T12:16:10.06+0200 [App/0] OUT Processing by PostsController#index as */*
2014-09-30T12:16:10.15+0200 [App/0] OUT Rendered posts/index.html.erb within layouts/application (4.2ms)
2014-09-30T12:16:10.15+0200 [App/0] OUT Completed 200 OK in 90.5ms (Views: 39.4ms | ActiveRecord: 7.3ms)
If you need to access older logs you can use the –recent parameter to display a dump of recent commands.
[bash light=”true”]$> cf logs mydemoapp –recent[/bash]
The cf command line tool provides a help function to access the documentation.
[bash light=”true”]$> cf help[/bash]
This will display all available commands
Or in case you need help with a specific sub-command just use the –help paramenter like this:
[bash light=”true”]$> cf push –help[/bash]
This will display all available options for the cf push command.
As there are a lot of new commands to learn we created a cheatsheet with the most important commands for you. You can download it here.