As Cloud Foundry is open source and does not rely on proprietary software or cloud infrastructure, it is completely possible to set up a Cloud Foundry client locally to experiment with Bluemix. That’s exactly what we will do later in this posting to get familiar with it. There is nothing better than learning by doing.
There is a user role within Cloud Foundry (OrgManager) that allows users to create orgs. When using Bluemix, this role is assigned to Bluemix administrators and, by default, the Bluemix user does not have permissions to create or delete them however the user is the administrator of the org itself, so it is possible to create/delete/modify spaces within it. By default, the name of the org is the user name. It is possible however to rename the org.
Every application and service is scoped to a space. A space provides a set of users access to a shared location for application development, deployment, and maintenance. Each org contains at least one space and it's called "dev", by default, in Bluemix.
Let's examine Bluemix with the Cloud Foundry client.:
- Go to https://github.com/cloudfoundry/cli/releases and download and install the appropriate release for your platform.
- It is now possible to type:
cf helpto get a full listing of possible commands and:
cf <command> -hor:
cf help <command>to get help on a specific commands.
- Run the following command which sets the API endpoint, or target
URL, of the Cloud Foundry instance's Cloud Controller URL. The Cloud
provider, in this case, Bluemix, typically supplies this.
> cf api https://api.ng.bluemix.net Setting api endpoint to https://api.ng.bluemix.net... OK API endpoint: https://api.ng.bluemix.net (API version: 2.23.0) Not logged in. Use 'cf login' to log in.
- As suggested we will now login into Cloud Foundry. The "-u" option is the username.
> cf login -u <Bluemix username> API endpoint: https://api.ng.bluemix.net Password> Authenticating... OK Targeted org <Bluemix username> Targeted space dev API endpoint: https://api.ng.bluemix.net (API version: 2.23.0) User: <Bluemix username> Org: <Bluemix username> Space: dev
As mentioned previously, the default organization is the username with a default space called "dev". Let's rename the org to something more meaningful. For example
> cf rename-org <Bluemix username> "Boris's Cloud Blog" Renaming org <Bluemix username> to Boris's Cloud Blog as <Bluemix username>... OK
We'll also create a new space for our work.
- Create a new space called "Cloud"
- Target the new space, this will now be used for applications
> cf target -o "Boris's Cloud Blog" -s Cloud API endpoint: https://api.ng.bluemix.net (API version: 2.23.0) User: <Bluemix username> Org: Boris's Cloud Blog Space: Cloud s
> cf create-space Cloud Creating space Cloud in org Boris's Cloud Blog as <Bluemix username>... OK Assigning role SpaceManager to user <Bluemix username> in org Boris's Cloud Blog / space Cloud as <Bluemix username>... OK Assigning role SpaceDeveloper to user <Bluemix username> in org Boris's Cloud Blog / space Cloud as <Bluemix username>... OK
TIP: Use 'cf target -o Boris's Cloud Blog -s Cloud' to target new space
> cf buildpacks Getting buildpacks... buildpack position enabled locked filename liberty-for-java 1 true false buildpack_liberty-for-java_v1.19-20150608-1717-yp.zip sdk-for-nodejs 2 true false buildpack_sdk-for-nodejs_v2.0-20150608-1503-yp.zip noop-buildpack 3 true false noop-buildpack-20140311-1519.zip java_buildpack 4 true false java-buildpack-v2.7.1.zip ruby_buildpack 5 true false ruby_buildpack-cached-v1.3.0.zip nodejs_buildpack 6 true false nodejs_buildpack-cached-v1.2.0.zip go_buildpack 7 true false go_buildpack-cached-v1.2.0.zip python_buildpack 8 true false python_buildpack-cached-v1.2.0.zip php_buildpack 9 true false php_buildpack-offline-v3.1.0.zip aspnet5-experimental 10 true false buildpack_aspnet5-experimental_v0.1.5-20150508-1205.zip liberty-for-java_v1-18-20150519-1642 11 true false buildpack_liberty-for-java_v1.18-20150519-1642-yp.zip sdk-for-nodejs_v1-18-20150519-1759 12 true false buildpack_sdk-for-nodejs_v1.18-20150519-1759-yp.zipDifferent buildpacks have different functionalities specific to the development technology support being provided. For example, the Java buildpack support includes support for Java Main, Servlets, Spring Boot CLI and Play Framework. When "pushing" an app to Cloud Foundry, it will examine the contents to determine which build pack should be used. The buildpack can also be specified on the cf command line when pushing the application, this is how custom/community buildpacks can be used.
In the next blog entry, we'll create an app using the Java buildpack and deploy it to the new "Cloud" space we created.
For More information on these topics visit: