This post is an extension of Managed services in CloudFoundry and follows the discussion of external services integration. The echo service and python service broker implementation are deployed using the documented procedure for Stackato. If necessary, you can get a Stackato instance up and running quickly. The result should be two apps deployed as shown below. Optional validation It is possible to validate that the deployed apps work as expected. The curl commands below validate the echo service is working properly. watrous@watrous-helion:~$ curl -X PUT http://echo-service.stackato.danielwatrous.com/echo/51897770-560b-11e4-b75a-9ad2017223a9 -w "\n" {"instance_id": "51897770-560b-11e4-b75a-9ad2017223a9", "dashboard_url": "http://localhost:8090/dashboard/51897770-560b-11e4-b75a-9ad2017223a9", "state":......
Continue Reading
CloudFoundry defines a Service Broker API which can be implemented and added to a CloudFoundry installation to provide managed services for apps. In order to better understand the way managed services are created and integrated with CloudFoundry (and derivative technologies like Stackato and HP Helion Development Platform), I created an example service and implemented the Service Broker API to manage it. The code for both implementations are on github. https://github.com/dwatrous/cf-echo-service https://github.com/dwatrous/cf-service-broker-python Deploy the services For this exercise I deployed bosh-lite on my Windows 7 laptop. I then follow the documented procedure to push......
Continue Reading
CloudFoundry, Stackato and Helion Development Platform accommodate (and encourage) external services for persistent application needs. The types of services include relational databases, like MySQL or PostgreSQL, NoSQL datastores, like MongoDB, messaging services like RabbitMQ and even cache technologies like Redis and Memcached. In each case, connection details, such as a URL, PORT and credentials, are maintained by the cloud controller and injected into the environment of new application instances. Injection It’s important to understand that regardless of how the cloud controller receives details about the service, the process of getting those details to......
Continue Reading
It’s possible to add a custom buildpack to Stackato or Helion Development Platform so that it’s available to all applications. When using an installed buildpack it is not necessary to include a manifest or identify the buildpack. Instead it will be selected by the detect script in the buildpack. All files are on the cloud controller node which eliminates download time and bandwidth. Package the buildpack Prepare your buildpack for installation by adding all files to a zip file (of any name). The bin folder should be in the root of the zip......
Continue Reading
In the past PaaS has been rigid and invasive for application developers. CloudFoundry aims to change that perception of PaaS with the use of Buildpacks. A Buildpack allows an application developer to define his deployment environment in plain text. Some refer to this as infrastructure as code since the aspects of a deployment environment that were previously handled by system administrators on dedicated servers now exist in plain text alongside the application files. What’s available out-of-the-box? Before diving into custom buildpacks, a lot of people will ask “What is available out-of-the-box with CloudFoundry?”.......
Continue Reading
Previously I detailed the process to create a buildpack for Stackato or Helion, including reconfiguring the buildpack to be self-contained. In both previous examples, the compile script performed a configure and make on source to build the binaries for the application. Since the configure->make process is often slow, this can be done once and the binaries added to the git repository for the buildpack. Pre-compile nginx The first step is to build nginx to run in the docker container for Stackato or Helion. These steps were previously in the compile script, but now......
Continue Reading
I previously documented the process to create a buildpack for nginx to use with Stackato or Helion Dev Platform. In that buildpack example, the compile script would download the nginx source using wget. In some cases, the time, bandwidth or access required to download external resources may be undesirable. In those cases the buildpack can be adjusted to work offline by adding the external resources to the git repository. The new structure would look like this. Updated compile script The only bulidpack related file that would need to change to accommodate this is......
Continue Reading
CloudFoundry accommodates buildpacks which define a deployment environment. A buildpack is distinct from an application and provides everything the application needs to run, including web server, language runtime, libraries, etc. The most basic structure for a buildpack requires three files inside a directory named bin. The buildpack files discussed in this post can be cloned or forked at https://github.com/dwatrous/buildpack-nginx Some quick points about these buildpack files All three files must be executable via bash Can be shell scripts or any language that can be invoked using bash Explicit use of paths recommended detect......
Continue Reading
One of the major strengths of CloudFoundry was the adoption of buildpacks. A buildpack represents a blueprint which defines all runtime requirements for an application. These may include web server, application, language, library and any other requirements to run an application. There are many buildpacks available for common environments, such as Java, PHP, Python, Go, etc. It is also easy to fork an existing buildpack or create a new buildpack. When an application is pushed to CloudFoundry, there is a staging step and a deploy step, as shown below. The buildpack comes in......
Continue Reading
CloudFoundry is an opensource Platform as a Service (PaaS) technology originally introduced and commercially supported by Pivotal. The software makes it possible to very easily stage, deploy and scale applications, thanks in part to its adoption of buildpacks which were originally introduced by Heroku. Some software design principles are required to achieve scale with cloud foundry. The most notable design choice is a complete abstraction of persistence, including filesystem, datastore and even in memory cache. This is because instances of an application are transient and stateless. Since this is generally good design anyway,......
Continue Reading