Skip to main content

Posts

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - environment variables

Why does Cloud Foundry rely on environment-variables? Can you manage environment-variables manually? If so how? Can you name two predefined environment-variables available to any application? Environment variables are the means by which the Cloud Foundry (CF) runtime communicates with a deployed application about its environment.  To view environment variables use 'cf env APP-NAME' command.  The 'cf env'  command displays the following environment variables: The  VCAP_APPLICATION  and  VCAP_SERVICES  variables provided in the container environment The user-provided variables set using the 'cf set-env' command For more details refer  environment-variables

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - 12 Factor Design patterns

What are the 12 Factor Design patterns? Could you list each one from memory? The twelve-factor app is a methodology for building software-as-a-service apps that use declarative formats for automation, have clean contract with underlying OS, are suitable for cloud deployment, have continuous deployment and can scale up. Below are the 12 factors: I. Codebase One codebase tracked in revision control, many deploys. There is only one codebase per app, but there will be many deploys of the app. There is always a one-to-one correlation between the codebase and the app: If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor. Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the  dependency manager . II. Dependencies Explicitly declare and is...

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - ephemeral

What is meant by ephemeral? What are the design implications for an application? Ephermeral: Virtual machines and container are temporary. Ephemeral is the cloud storage model where instance storage ( storage consumed like conventional  virtual disks)  is implemented using DAS i.e. disk attached storage on the compute node/VM itself. This kind storage is not very reliable as it will go away with VM instance, it is called ephemeral. Instance storage can be implemented in a reliable way using NAS i.e. network attached storage or volume storage i.e. db. OpenStack allow users to implement instance storage as ephemeral storage on the host, as files on NFS mount points or as cinder volumes using boot-from-volume. For more details on cloud storage refer  understanding-cloud-storage-models We should a void Writing to the Local File System or ephemeral storage.  Applications running on Cloud Foundry should not write files to the local file system for the following r...

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - Starting, Restarting and Restaging applications

Do you know the difference between restarting, restaging and redeploying an application? How does each of these affect the services, environment-variables available to an  application? Starting an app:   1. ' $ cf push YOUR-APP' command with manifest entry of command attribute i.e. command: node YOUR-APP.js 2.  ' $ cf push YOUR-APP -c "node YOUR_APP.js"', where -c command line option for defining the start command. First time deployment using 'cf push' uses buildpack start command by default. Restarting an app: Restarting your application stops your application and restarts it with the already compiled droplet. Diego cell unpacks, compiles and runs a droplet on a container. 'cf restart YOUR-APP' Restaging an app: Restaging your application stops your application and re-stages it, by compiling a new droplet and starting it. 'cf restage YOUR-APP' For more details refer  start-restart-restage

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - Staging

What is staging? What does it do? Staging is the process of  1. registering the apps metadata in Cloud controller DB (CCDB),  2. storing the application package in Cloud controller blobstore (CCNG) 3. creation of droplet i.e. tarball of compiled and staged application in Diego cell 4. storing the droplet in blobstore for future use 5. starting a long running process on one or more Diego cells For more and sequence diagram Please refer to CF @ how-applications-are-staged

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - BOSH

What is BOSH? Why is it useful? BOSH creates and deploys virtual machines (VMs) on top of a physical computing infrastructure, and deploys and runs Cloud Foundry on top of this cloud. To configure the deployment, BOSH follows a manifest document. BOSH is a recursive acronym for Bosh Outter SHell. In contrast to the “Outter Shell”, the system being deployed and managed by BOSH is called the “Inner Shell”. The below diagram illustrates a simplified model of BOSH. BOSH can be considered as a server or a robot which orchestrates the deployment process of a distributed system. There is a ruby tool which can interact with BOSH Command Line Interface (CLI). Before BOSH starts to deploy a system, it needs three prerequisites: a stemcell, a release (the software to be installed), and a deployment manifest. Let’s look at these three items in more detail. Stemcells:  A stemcell is a VM template containing a standard Ubuntu/CentOS distribution. A BOSH agent is also embedded in the...