#Cloud Rocker
Cloud Rocker is the convergence of Cloud Foundry and Docker aiming to bring the Cloud Foundry experience to a developer's machine.
##Tutorial
This is a brief tutorial to ease you through your first rocking experience.
###Set up your Docker environment
Select either option 1 or option 2, then move to Test your Docker environment.
####Option 1 : Easy - Mac/Windows/Linux - using Vagrant
vagrant up --provider virtualbox
vagrant ssh
Please use the Vagrantfile in the root of this repository. All later commands are entered as the vagrant user's shell in the vagrant VM.
Modify the Vagrantfile to mount your local workspace to make development easy.
####Option 2 : Advanced users - Linux only - using a local Docker daemon
$ go get github.com/cloudcredo/cloudrocker/rock
The user for 'rock' commands must have permissions to access the Docker daemon.
###Test your Docker environment
$ rock docker
You should see output similar to this:
Client API version: 1.15
Go version (client): go1.3
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f
###Rock your local machine
Download the base Cloud Foundry container image.
$ rock this
###Add a buildpack
$ rock add-buildpack https://github.com/cloudfoundry/java-buildpack
###Deploy your application
Change PWD to the sample Java application.
$ cd /vagrant/sample-apps/java/
Start the application.
$ rock up
Starting the CloudRocker container...
Running Buildpacks...
-----> Java Buildpack Version: 120c640
*--Buildpack output omitted--*
Started the CloudRocker container.
Deleting the CloudRocker container...
cloudrocker-staging
Deleted container.
Starting the CloudRocker container...
5b69950f351d2c843fe2ffd531edd87c09f19a368241ae37a6d2e025000dd6c8
Started the CloudRocker container.
Connect to your running application at http://localhost:8080/
You should now be able to browse the output on the vagrant machine.
$ curl localhost:8080
You should also be able to browse the output on your host machine.
Please note the unsubtle CloudCredo advertising.
###Shut the application down
$ rock off
##Buildpacks
A great list of Cloud Foundry buildpacks is available on the Cloud Foundry community wiki.
List buildpacks
$ rock buildpacks
cf-buildpack-php
go-buildpack
java-buildpack
nodejs-buildpack
python-buildpack
ruby-buildpack
Add a buildpack
$ rock add-buildpack https://github.com/cloudfoundry/php-buildpack
Remove a buildpack
$ rock delete-buildpack php-buildpack
Sample applications to use with the buildpacks are in sample-apps.
##Docker Images
###Building a Docker image from your application code
Ensure you have a corresponding buildpack installed for your application type.
$ rock buildpacks
Ensure your PWD is your application directory.
$ cd <app_dir>
Build a Docker image.
$ rock build
or with a tag
$ rock build user/image:tag
eg
$ rock build hatofmonkeys/rocker-test:latest
<output truncated>
Step 10 : CMD ["/bin/bash", "/app/cloudrocker-start-1c4352a23e52040ddb1857d7675fe3cc.sh", "/app", "bundle", "exec", "rackup", "config.
ru", "-p", "$PORT"]
---> Running in fd810cea3db4
---> 4a88ad7d67ae
Removing intermediate container fd810cea3db4
Successfully built 4a88ad7d67ae
Created image.
In the example above the created image ID is 4a88ad7d67ae.
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
hatofmonkeys/rocker-test latest 4a88ad7d67ae 13 minutes ago 609 MB
This image can be run like any other Docker image.
$ docker run -P -d hatofmonkeys/rocker-test:latest
0e4825d049ba5390699625be145a8d029a5e2899e52c8c5f967d35e08412f3ba
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0e4825d049ba hatofmonkeys/rocker-test:latest /bin/bash /app/cloud 4 minutes ago Up 4 minutes 0.0.0.0:49154->8080/tcp sick_lumiere
$ curl localhost:49154
Hello world!
The image can be uploaded to a Docker registry, or deployed and run in a system such as Kubernetes, Decker, or Diego.
##External Services
Services can be connected to your application by adding a vcap_services.json file to the root directory of your application. This is demonstrated in the ruby-with-services sample application.
#####Note - the following steps are only appropriate to users of the Vagrant image (tutorial option 1 above).
Change PWD to the sample ruby-with-services sample application.
$ cd /vagrant/sample-apps/ruby-with-services
If necessary, install a Ruby buildpack.
$ rock add-buildpack https://github.com/cloudfoundry/cf-buildpack-ruby
Start the application.
$ rock up
Set a value for a key.
http://localhost:8080/set/hello/to/world
Get the value.
http://localhost:8080/get/hello
##Working with Lattice
In the root directory of your application, the workflow is three simple commands to build and deploy your own containers to Lattice.
replace hatofmonkeys/rocker-test:latest with your own user/image:tag
$ rock build hatofmonkeys/rocker-test:latest
$ docker push hatofmonkeys/rocker-test:latest
$ ltc create rocker-test hatofmonkeys/rocker-test:latest
note this may appear to timeout on slow connections. Watch ltc status rocker-test until the application is running
##Debugging your app, your buildpack, your staging process
Build/staging artefacts are placed in $CLOUDROCKER_HOME. By default this is $HOME/cloudrocker, eg. /home/vagrant/cloudrocker. This is a treasure trove of interesting information when debugging staging failures.
##Potential Uses
####For application development
Cloud Rocker gives a fast-feedback, production-like Cloud Foundry environment on a developer's machine. Make a change, rock up, rinse, repeat. When you're finished, just rock off.
####For buildpack development
Cloud Rocker gives a fast-feedback environment for iterating on buildpacks. Buildpacks are stored in $CLOUDROCKER_HOME(default ~/cloudrocker)/buildpacks and can be edited directly.
####For continuous integration
Deploying Cloud Rocker to your CI server means you can quickly get feedback about your Cloud Foundry applications.
####For deploying applications to non-Cloud-Foundry environments
If you aren't fortunate enough to work in an organisation with access to a proper PaaS such as Cloud Foundry - you can still use Cloud Foundry's buildpacks, via Cloud Rocker, to build applications. You will need to host the containers in an IaaS+ offering, such as Kubernetes or Shipyard. IaaS+ systems leave the responsibility with the user to rock themselves.
##Developing Cloud Rocker
Development is against the 'develop' branch, promoted to 'master' by Concourse.
There is a public tracker for this project here.
##FAQ
#####Why have you built Cloud Rocker?
Cloud Foundry, at a high level, has two responsibilities for applications: staging - so they are ready to be run, and then - running them. Decker brought Cloud Foundry's running experience to container developers. Cloud Rocker brings the Cloud Foundry staging experience to application developers. By separating these responsibilities we can discuss the right way to build containers, and the right way to run them.
As a Cloud Foundry Community Advisory Board member - anything I can do to illustrate the great experience Cloud Foundry brings to developers is worthwhile. I think everybody benefits from fast-feedback and small batch sizes. Get code into a production-like environment as soon as possible. Let's iterate faster.
#####How is Cloud Rocker different to Slugbuilder, Building, Buildstep, etc?
Cloud Rocker uses the Cloud Foundry components as far as possible to provide a production-like Cloud Foundry environment to developers.
#####How is this different to Decker?
Decker is about running containers in a remote Cloud Foundry. Cloud Rocker is about running Cloud Foundry applications in local containers.
#####How is this different to BOSH-Lite?
BOSH-Lite is a fantastic development environment for BOSH developers. Cloud Rocker is for application developers.
#####How is this different to Micro Cloud Foundry?
MCF has been defunct since Cloud Foundry v1, and even back then it ate a considerable amount of resources. Cloud Rocker runs on any machine capable of running Docker, only consuming the resources necessary to stage and run the application.
#####Just how 'production-like' is this?
Cloud Rocker attempts to use the same components as Cloud Foundry's 'Diego'.
The base filesystem is exactly the same as a Cloud Foundry container.
Environment variables are currently handled in a different manner to CF. File locations and user mapping are also slightly different, which may cause subtle issues. Cloud Rocker is under development to bridge this gap.
#####How do I enter the running container to 'poke around' in the shell?
We will be automating this process, for now use nsenter.
#####Why can't I use my boot2docker setup on win/mac, not vagrant?
Feel free to try Cloud Rocker with boot2docker, and good luck with the volume mounts.
#####Can I use a non-default base container image?
By default the Cloud Foundry cflinuxfs version 2-1.11.0 image is used. You can choose to download a different base container image using the $ROCKER_ROOTFS_URL environment variable. e.g.
ROCKER_ROOTFS_URL=https://s3.amazonaws.com/blob.cfblob.com/978883d5-2e4d-495b-8aec-fc7c7e2988ad rock this
#####What about 'Error response from daemon: Conflict, The name cloudrocker-runtime is already assigned to 7a519360a3d3. You have to delete (or rename) that container to be able to assign cloudrocker-runtime to a container again.'?
This is what happens when good Cloud Rockers turn bad. Simply run:
$ docker rm cloudrocker-runtime
We will automate this when we have a better understanding of all the scenarios in which it occurs.
#####Did you only create this project so you could have fun making endless double entendres in the README?
No. I enjoyed the portmanteau too.
##A message from our sponsors.
If you've read this far you've demonstrated a remarkable level of tenacity. CloudCredo are recruiting, and would like to hear from you.