Set environment variables in pivotal application

Environment variable is part of the environment in which a process running. An environment variable is a dynamic-named value that can affect the running processes will behave on a computer. In pivotal, environment variable will play a key role to push and run an application. Cloud foundry will provide different set of command to view and set environment variables through command line interface.

To view specific application environment variables we can use the cf env followed by application name. Syntax look like below,

cf env

 For example, my application_name is usermanagement. Then the command which I need to execute is like below,

cf env usermanagement

The response which I got after the execution of above command is,
Environment Variables:

Getting env variables for app usermanagement in org javaisocean / space development

 as javaisocean@gmail.com...
OK

System-Provided:

{
 "VCAP_APPLICATION": {
  "application_id": "bf7ee518-3722-4dc7-98f4-4c86769769f5",
  "application_name": "usermanagement",
  "application_uris": [
   "usermanagement.cfapps.io"
  ],
  "application_version": "0e6a6fae-4aa5-4d1a-8148-a33a268d62a4",
  "cf_api": "https://api.run.pivotal.io",
  "limits": {
   "disk": 1024,
   "fds": 16384,
   "mem": 650
  },
  "name": "usermanagement",
  "space_id": "ecc72a08-9fd2-4763-bc00-07282a3f528d",
  "space_name": "development",
  "uris": [
   "usermanagement.cfapps.io"
  ],
  "users": null,
  "version": "0e6a6fae-4aa5-4d1a-8148-a33a268d62a4"
 }
}

No user-defined env variables have been set

No running env variables have been set

No staging env variables have been set

If you observe the above information, there are different types of env variables we can see. Those are like, System provided, user-defined, running and staging env variables. We can not change anything which is coming from System provided which was configured by the System while pushing the application or binding services.

As per the above information, there is only VCAP_APPLICATION information and no VCAP_SERVICES information. Because the usermanagement application doesn’t bind with any services. That means, VCAP_APPLICATION which contains the information of application and VCAP_SERVICES will contains the information of services which are bind to the application.

The below is the application environment variables, after binding the ClearDB MySQL database to usermanagement application.

Environment variables after binding ClearDB MySQL service:

Getting env variables for app usermanagement in org javaisocean / space development

as javaisocean@gmail.com...
OK

System-Provided:
{
 "VCAP_SERVICES": {
  "cleardb": [
   {
    "binding_name": "mysql-db",
    "credentials": {
     "hostname": "us-cdbr-iron-east-01.cleardb.net",
     "jdbcUrl": "jdbc:mysql://us-cdbr-iron-east-01.cleardb.net/ad_ce4b59777591895

?user=ba9fca71350825\u0026password=80a3164a",
     "name": "ad_ce4b59777591895",
     "password": "80a3164a",
     "port": "3306",
     "uri": "mysql://ba9fca71350825:80a3164a@us-cdbr-iron-east-01.cleardb.net:3306/

ad_ce4b59777591895?reconnect=true",
     "username": "ba9fca71350825"
    },
    "instance_name": "mysql-spark-db",
    "label": "cleardb",
    "name": "mysql-db",
    "plan": "spark",
    "provider": null,
    "syslog_drain_url": null,
    "tags": [
     "Data Stores",
     "Cloud Databases",
     "Developer Tools",
     "Web-based",
     "Data Store",
     "Online Backup \u0026 Storage",
     "Development and Test Tools",
     "Single Sign-On",
     "Buyable",
     "relational",
     "mysql",
     "Cloud Security and Monitoring"
    ],
    "volume_mounts": []
   }
  ]
 }
}

{
 "VCAP_APPLICATION": {
  "application_id": "5b64b05f-4ba0-4f51-9680-c9fe5c8f109a",
  "application_name": "usermanagement",
  "application_uris": [
   "usermanagement.cfapps.io"
  ],
  "application_version": "d12ee54c-57fd-4973-9eb0-5e20eca520f0",
  "cf_api": "https://api.run.pivotal.io",
  "limits": {
   "disk": 1024,
   "fds": 16384,
   "mem": 650
  },
  "name": "usermanagement",
  "space_id": "ecc72a08-9fd2-4763-bc00-07282a3f528d",
  "space_name": "development",
  "uris": [
   "usermanagement.cfapps.io"
  ],
  "users": null,
  "version": "d12ee54c-57fd-4973-9eb0-5e20eca520f0"
 }
}

No user-defined env variables have been set

No running env variables have been set

No staging env variables have been set

How to set environment variables?

Cloud Foundry provides a command called set-env to set environment variables followed by the application name along with property name and value.

Set-Env command syntax look like,

cf set-env

You can see the environment variables provided by user under User-defined env variables when you ran the below command.

cf env

Advertisement

Design Consideration and 12 Factor Apps

In the previous post we learnt about Platform-as-a-Service (PaaS) like what is Platform, need of using PaaS, Goals of PaaS and various service providers in the market. Now, we look at what are the design consideration and 12 factor apps for PaaS application. These information will be really helpful when we are designing a Cloud application.

1. Codebase
2. Dependencies
3. Config
4. Backing Service
5. Build, Release, Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/Prod Parity
11. Logs
12. Admin Process

The above are the twelve-factors apps, which we should follow while designing the PaaS/Cloud application.

Codebase:

Code should be version controlled. We can track our code changes by using version control systems. Running code and code from version control has to have a one-to-one relationship. We can also deploy our Codebase to multiple deployment environments without any issues. So, we might have different environments like Development, Staging and Production.

Dependencies:

Dependencies are declared and isolated. This factor states that we never use System level packages with in our application. These dependencies like any kind of tools, libraries and even databases. Instead of assuming everything is there, we should define it in manifest.yml/POM.xml file that has the power to bring all need together.
For example, we want to use specific version of libraries for any of the technology instead of latest one. So, we can specify that libraries version. This allows to eliminate conflicts too.

Config:

Configuration is Stored in the Environment. Code should be separated from configuration as much as possible and we can provide the configurations inside the environment that we are running our application in.
For example, Connection string varies from environment to environment. So, that’s not good idea to declare in a static way in our code. The better way is to configure it in the environment and use.

Backing Service:

Backing services as attached resources. This factor is really an important to build an Cloud or any other application. Our application might have lot’s of services that uses like Databases, Queuing, Caching, Web services etc. These all we can access through network which will not differ from our local. Importantly we can attach and detach these services from our application at anytime we want. Only the difference between is, environment variables that we are running our application.

Build, Release and Run:

Build and Run stages are separate. Once we deploy our application in production, there is no come back. Only we can simply change our code in production. Some times it is not possible and even impractical in most cases. So we should have build and run stages separate by using unique identifier. So, if any problem occurs in production we can simply know the problematic version and easy to identify code.

Processes:

Application executed as Stateless processes. We should never assume that State or Processes are part of our application. They can go away at anytime and simply crash. Of course we can go and use state of the application sometimes, but these kind of information should be stored in a state-full backing store. With this way we could separate application logic from states and we can get back to our application where it has been crashed because we know where we left off.

Port Binding:

Services are exported via Port Binding. This is one of the most important factor of 12 factor app which simply states that our application must be self contained. It should not rely on a specific web server or a port. So application should be listening on a very specific port rather than 80, 100 and 44. Because these are the ports can be used for Caching mechanism from a Queuing mechanism.

Concurrency:

Application scaled out via Process Model. Process must be embrace as First class citizens in our application because they simply do everything. We have processes for listening Queue and making HTTP requests and listening coming request. These are all being handled by individual processes.

Disposability:

Processes are disposable. Minimal startup time and graceful shutdown is key here. Assume our application has been crashed. So, do you want it to recover back withing seconds or after few minutes? definitely want to recover Seconds of time because time equals to money.

Dev/Prod Parity:

Important point of Parity between application environments factor is to avoid time personal and through gaps between environment. We should be designing for a Continuous deployment pipeline. For example, developer want to run some sql scripts into production which is working in development. Suddenly it’s not working in production because Parity between the environments are missing. What about the time gap? should a developer go to the production on everyday or a month? if we shift to continuous, developer move code to production very often.

Logs:

Logs treated as Even Streams. Logs are very important aspect of running system because they can capture time order, chronological list of events happened through out the application life cycle. We treat them as Streams of events because they carry important information of application states. An application should never be concerned with storing it’s own log files. Logging framework must be taking care of where it has to collect them.

Admin Process:

Management task run as one-off processes. These task are important in any application to maintain and upgraded. So we should be using identical environments to running them. If our application is running in cloud, then we should run necessary scripts and tasks in the cloud.

For better understanding about the 12 factors of PaaS application use the below official website link.

The Twelve-Factor App

Anti-Patterns of PaaS:

These are few bad practices or Anti-patterns of the PaaS application.

• We should not rely on local file systems
• Scaling up services the old way
• Trying to change the code on the server-side
• Manually coordinating builds
• Hard-coding configuration
• Trying to be monolithic everywhere

Previous: What is Platform and why we need PaaS?

Next: How to create an Account in Pivotal?

What is platform and why we need PaaS?

What is Platform?

A platform is nothing but anything you can leverage to accomplish a task in a simpler/better way. As a programmer or developer we can take advantage of using existing code instead of writing from scratch. The most well known software platforms for Desktop applications are Windows, Mac OS. Even we can say some other examples to these explanation is Unix, Linux and Android, iOS etc.

A Computing platform or Digital platform is the environment in which a peace of software is executed.

Why we need PaaS?

In traditional IT decade, we have to manage everything that is like applications, OS, Servers, etc. So, we have to hire System Engineer to take care of our system and motor 24/7 of a week.

With the improved technology, we no need to worry about taking care of above all parts. There are some parts which are taken care by the service provider. Look at below image,

As per the above image, Virtualization, Servers, Storage and Networking are taken care by the Service providers. These kind of platforms are called as Infrastructure-as-a-Service (IaaS) and delivers to us by Amazon or Redshift.

With the Platform-as-a-Service (PaaS), we no need to worry about taking care of Software or Hardware. Those all taken care by service providers. All we need to do is develop our applications and services on top it. Lets look at below image,

Differences between Traditional IT, IaaS and PaaS:

Goals of Platform-as-a-Service (PaaS):

The ultimate goal of a PaaS is to make it easier for you to run your website or web application no matter how much traffic it get’s. It’s all about giving responsibility to run our applications and services properly with minimum downtime and issues.

We just deploy our application and service figures out what to do with it. Providers give us the guarantee that we can deploy our application without any problems. PaaS should handle scaling seamlessly for us so we can just focus on our application and code running it. We no need to worry about underlying details like, OS, CPU,etc which are taken care by platform.

PaaS Providers:

There are no of service providers available in now a day cloud market. Out of these, we can say the below few are biggest cloud service providers.

Previous: Different Service Models in Cloud

Next: Design Consideration and 12 Factor App