External services for your Cloud Foundry app

By Al
As we have seen in previous posts Cloud Foundry Marketplace offers a large amount of services, including a variety of databases, message queuing, etc which will address the majority of use cases. However the offerings available in the Marketplace can be customized by the provider. For example the offerings from Pivotal Cloud Foundry might differ from Cloud Foundry on Azure or on Google Cloud Platform etc. In general each cloud provider will try to differentiate by extending the platform with whatever managed service they believe is unique to them and is going to help them attract customers.

For example Google offers services like Google Cloud Storage, BigQuery, BigTable or the Machine Learning APIs, etc. Whereas Microsoft Azure offers Azure Storage, Azure SQL or CosmosDB in addition to Redis, MySQL or PostgreSQL.


In any case, incorporating these services into your application should be done by reading credentials and other binding information from the environment so that we adhere to the 12-factor app principles. So what happens if a service is not available in the platform, can we still use it from our app? The answer is yes. Let’s see how.

In addition to environment variables defined by the platform itself, such as when we bind a new service to the app (see the Redis blog post) Cloud foundry allows us to define our own environment variables. We can do this in three different ways:
  • From the Console, app > settings tab > User Provided Environment Variables. In the screenshot below you can see we have defined 3 variables with connection details for a hypothetical database
  • From the CF CLI as follows. Here we have defined the same DB-user variable for our "piperhw" app:
cf set-env piperhw DB-user piper01
  • From the manifest.yml file, if using it
---
# this manifest includes the definition or 2 vars
applications:
- name: piperhw
  memory: 64M
  instances: 1
  path: ./piperhw/
  env:
    DB-user: piper01
    DB-password: S3cr3t_P@ssw0rd

Finally, regardless of the method used, the mechanism to read those vars from within the Python app is the same. Use the "os" Python module

import os
host = os.environ['DB-host'] 
user = os.environ['DB-user']
pasw = os.environ['DB-password']

In the next post we will use this mechanism to access either object storage from either AWS S3 or a compatible service like DellEMC ECS(Elastic Cloud Storage)

Comments

Post a Comment

Popular posts from this blog

Sending PowerStore alerts via SNMP

By Al
Image
In this previous article we discussed how to leverage PowerStore's powerful API to collect audit logs and send them to a Syslog server . We used Logstash to do that because of its extensive list of plugins Sometimes I come across organizations that still have a requirement to send storage array Alerts to SNMP. As in the Syslog case, ultimately most modern monitoring tools today support collecting information via REST API because that's the way the application world is going, i.e. the cloud native way ... it would be fun to see Prometheus monitoring Kubernetes via SNMP :) However there is still some requirement out there for SNMP traps, so we will explore how to do it. For simplicity we will use the same toolset that we used in the previous article. I encourage you to revisit quickly the article as we did an extensive introduction to Logstash, with practical examples as well as a description of the logs available in PowerStore. I won't cover those aspects in this article I
Read more

Sending PowerStore logs to Syslog

By Al
Image
In this article we will explore how to get the logs from a DellEMC PowerStore array to a Syslog server. For this purpose we will use the PowerStore’s REST API, which is a great piece of engineering and a joy to work with as a developer. If you want to learn more about the PowerStore REST API I strongly recommend you quickly skim through the 2 articles I have written about the REST API. Part 1 - http://anzpiper.blogspot.com/2020/08/intro-to-dellemc-powerstore-rest-api.html Part 2 - http://anzpiper.blogspot.com/2020/08/powerstore-rest-api-best-practices.html In particular the second article demonstrates the capabilities of the REST API query language. This is a great feature I will use heavily in the last section so I strongly recommend you read that one at least As a side note, Syslog was developed in 1980. So this year it has turn 40 years old! That is a long time by any measure ... many of my colleagues were not even born in 1980. But in the technology scale it looks even scarier. 198
Read more

Electronic Nose - eNose

By Al
Image
In the previous article I provided details on VeeFarm which was one of the best projects we saw in ANZ Pied Piper 2019 edition and one of the best projects in the history of the program. The program inspired me and others to work together to showcase a great idea and the Pied Piper program itself during our presales conference. An idea I suggested to enhance VeeFarm was an electronic nose that could be used to detect the optimal ripening of the produce to advise the owner that it is the right time to pick it up the produce. This is an idea I had in the backburner for a while but never found the time to work on. Vee gave me the perfect excuse. The electronic nose, or eNose for short, is a custom PCB that hosts a range of gas sensors. For the proof of concept, I used the cheap MQ sensors. These are designed mostly for hobbyists and makers and they barely cost $1 per sensor. As one could expect, tweaking and calibrating these sensors it is even harder than the most expensive counter
Read more