Permalink
Browse files

Retire the Clound Foundry launch plan which does not work anymore

  • Loading branch information...
1 parent 5938fa2 commit 79bcc408955e9244cfb6a7705eeecd0dd0c4901c @priteau priteau committed Dec 12, 2012
View
@@ -1,130 +0,0 @@
-Cloud Foundry example
-================================
-
-Introduction
-------------
-
-Cloud Foundry is an open Platform-as-a-Service (PaaS) project. This launch plan
-will allow you to set up either a simple single node installation, or a multi
-DEA worker node installation.
-
-
-Prerequisites
--------------
-
-Ensure that you have cloudinit.d installed. See the `cloudinit.d quickstart`_
-for instructions.
-
-Ensure that you have your IaaS credentials exported into your environment::
-
- $ export CLOUDINITD_IAAS_ACCESS_KEY=<your EC2 access key>
- $ export CLOUDINITD_IAAS_SECRET_KEY=<your EC2 secret key>
- $ export CLOUDINITD_IAAS_SSHKEY=<the path to your ssh key>
- $ export CLOUDINITD_IAAS_SSHKEYNAME=<the name of your ssh key in EC2>
-
-Boot Cloud Foundry
-------------------
-
-Once you have your credentials set up, you need to build a tarball for both the
-Chef cookbooks used to build your Cloud Foundry installation, and the
-readytests used to verify that your service is running properly. This is
-scripted, so change to your plans directory and run the following::
-
- $ cd plans
- $ ./common/prepare-tarball.sh
- Created cookbooks.tar.gz
- $ ./cloudfoundry/01/prepare-tarball.sh
- Created readytests.tar.gz
-
-If you later modify the Cloud Foundry cookbooks, or the readytests, you will
-need to re-run these scripts before you re-deploy Cloud Foundry.
-
-Now run cloudinit.d to boot a single node installation::
-
- $ cloudinitd boot -v -v -v cloudfoundry/main.conf -n cf-single
- Starting up run cf-single
- Started IaaS work for singlenode
- Starting the launch plan.
- Begin boot level 1...
- Started singlenode
-
-Please be patient. The Cloud Foundry setup scripts can take about 30 minutes to
-run on a standard EC2 VM. This is because the Cloud Foundry setup installs
-numerous packages, builds two versions of Ruby, Erlang/OTP, and node.js, in
-addition to installing Cloud Foundry itself.
-
-
-Testing Installation
---------------------
-
-To test your installation, you should log in to your Cloud Foundry VM, and
-switch to the cf user. You can get the domain name of the VM from the cloudinit.d
-output (These instructions are based on the ones from the `Cloud Foundry
-README <https://github.com/cloudfoundry/vcap/blob/master/README.md>`_)::
-
- $ ssh ubuntu@ec2-0-0-0-0.compute-1.amazonaws.com
- [on vm]
- $ sudo su - cf
- [now cf user]
-
-Test that we can connect to the Cloud Foundry service with the pre-defined
-vcap.me address::
-
- $ vmc target api.vcap.me
- $ vmc info
-
-Now we will register and login with our new account::
-
- $ vmc register --email cfuser@bar.com --passwd password
- $ vmc login --email cfuser@bar.com --passwd password
-
-Run a Hello World app::
-
- $ mkdir hello && cd hello
-
-Paste the following into hello.rb::
-
- require 'rubygems'
- require 'sinatra'
-
- get '/' do
- host = ENV['VMC_APP_HOST']
- port = ENV['VMC_APP_PORT']
- "<h1>XXXXX Hello from the Cloud! via: #{host}:#{port}</h1>"
- end
-
-And now push the app to Cloud Foundry, and test it out::
-
- $ vmc push hello --instances 4 --mem 64M --url hello.vcap.me -n
- $ curl http://hello.vcap.me
- <h1>XXXXX Hello from the Cloud! via: 0.0.0.0:00000</h1>
-
-It worked!
-
-
-Teardown
---------
-
-Why don't we tear down our Cloud Foundry install now that we know that it
-works. To do this, run the following::
-
- $ cloudinitd terminate cf-single
- Terminating cf-single
- SUCCESS level 1
- deleting the db file /Users/patricka/.cloudinitd/cloudinitd-cf-single.db
-
-
-What now?
----------
-
-Now that you've seen that cloudinitd can start a single Cloud Foundry node, you
-could try the cloudfoundry-multinode plan, and boot a multinode Cloudfoundry
-installation.
-
-To do this, follow the same steps from the Boot Cloud Foundry section, but change
-cloudfoundry to cloudfoundry-multi, like so::
-
- $ cloudinitd boot -v -v -v cloudfoundry-multi/main.conf -n cf-multi
-
-.. _cloudinit.d quickstart: http://www.nimbusproject.org/doc/cloudinitd/latest/quickstart.html
-.. _Cloud Foundry README: https://github.com/cloudfoundry/vcap/blob/master/README.md
View
@@ -12,7 +12,6 @@ set before they can be used (mainly for security reasons) but otherwise
no customization should be needed.
* :ref:`WordPress <wpref>`
-* :ref:`CloudFoundry <cfref>`
WordPress
=========
@@ -47,35 +46,3 @@ WordPress
This launch plan will boot two VMs. One that runs a MySQL server and
the other runs an apache2 server with WordPress. More details on this
launch plan can be found :doc:`here <wordpress>`.
-
-
-Cloud Foundry
-=============
-.. _cfref:
-
-.. image:: vmware_cloud_foundry.png
- :width: 256
- :height: 256
-
-#. `Download <http://www.nimbusproject.org/downloads/cloudfoundry-multinode.tar.gz>`_
-
- .. code-block:: none
-
- wget http://www.nimbusproject.org/downloads/cloudfoundry-multinode.tar.gz
- tar -zxvf cloudfoundry.tar.gz
-
-#. Set the security information
-
- .. code-block:: none
-
- $ export CLOUDINITD_IAAS_ACCESS_KEY=<your EC2 access key>
- $ export CLOUDINITD_IAAS_SECRET_KEY=<your EC2 secret key>
- $ export CLOUDINITD_IAAS_SSHKEY=<the path to your ssh key>
- $ export CLOUDINITD_IAAS_SSHKEYNAME=<the name of your ssh key in EC2>
-
-#. Boot it
-
- .. code-block:: none
-
- cloudinitd -v -v -v boot cloudfoundry-multinode/main.conf
-
View
@@ -18,13 +18,12 @@ commands, but it can also be automated with tools such as crond.
Manual Monitoring
=================
-First let us take a look at how to manually use cloudinit.d for monitoring
-and repair.
-We take for example the CloudFoundry reference launch plan. In the
-example an operator launches CloundFoundry with 1 head node and 8
-DEA nodes. It is important that all the nodes remain up and function
-to handle the expected load of this CloudFoundry application. If (when)
-something does go wrong the operator would like to repair it as quickly
+First let us take a look at how to manually use cloudinit.d for monitoring and
+repair. We take for example a typical web application platform with a load
+balancer and web servers. An operator launches the infrastructure with 1 load
+balancer and 8 web servers. It is important that all the web server nodes
+remain up and function to handle the expected load of this web application. If
+(when) something does go wrong the operator would like to repair it as quickly
and surgically as possible. cloudinit.d is well suited for this task.
To launch an application the user simply runs::
@@ -236,4 +236,3 @@ Example launch plans
:maxdepth: 1
wordpress
- cloudfoundry
Deleted file not rendered

0 comments on commit 79bcc40

Please sign in to comment.