Blast from the past: Procfile for Python cloud apps

One of my first cloud apps

Recently, I tried out a feature of IBM Cloud Code Engine: Deploying my app directly from source code. It was a simple app, but it failed. I was stunned and investigated the problem. To my surprise, I could have known it because it was something from the past: A Procfile was needed.

Custom domain for your serverless Code Engine app

Output of a IBM Cloud Code Engine app

A custom domain, e.g. somethin like myapp.example.com, always puts a nice touch on an app. Often, it is required for corporate identity. Still, not all services offer that capability. As written, I recently migrated some apps from Cloud Foundry to IBM Cloud Code Engine. Right now, Code Engine does not support custom domains out of the box, but I heard that it is planned. Thus, I looked into temporary workarounds for using a custom domain name for my serverless Code Engine apps.

From Bluemix to IBM Cloud, from Cloud Foundry to Code Engine

"Bring Your Own Community"

About seven years ago, I started to work with, then blog about Bluemix and Cloud Foundry. Not my first, but one of the first posts is titled "Some fun with Bluemix, Cloud Foundry, Python, JSON and the Weather". Reading that article again I feel nostalgic and it brings back memories of how I learned to deploy my apps to Cloud Foundry. And how I had fun with new cloud technologies.

Rotate service credentials for Cloud Foundry apps on IBM Cloud

Keep your cloud environment secure

A popular PaaS (Platform as a service) technology is Cloud Foundry. On IBM Cloud, it is available both as public Cloud Foundry instances in multiple regions as well as Cloud Foundry Enterprise Environment (CFEE). Using Cloud Foundry for app development and production has many benefits. Personally, I like the ease of use and how services can be integrated with apps. When you search for my older Bluemix-related blog entries, you will notice that I had (and still have) fun using Cloud Foundry, including my attempts to catch a chocolate thief or testing the hybrid world early on. Similar to my recent blog on rotating credentials when working with IBM Cloud Functions, today, I want to discuss how to bind services and rotate their credentials in a Cloud Foundry environment.

How to: Enable Let's Encrypt SSL wildcard certificates for your IBM Cloud apps

Private data - secured

Early last year, I wrote about how to improve security for your custom domains on IBM Cloud. I pointed out that I was using the bluemix-letsencrypt wrapper for Cloud Foundry app to generate and retrieve SSL certificates issued by Let's Encrypt. Today, I am going to introduce you to another option which I am using. Recently, Let's Encrypt announced the support and availability of wildcard certificates. With such a wildcard certificate, all of my IBM Cloud apps available under a custom domain are covered (and secured). So let's take a look at what I did.

Securing your Python app with OpenID Connect (OIDC)

Authorized access only using OpenID Connect

Some weeks back I introduced to a tutorial on how to analyse GitHub traffic. The tutorial combines serverless technology and Cloud Foundry to automatically retrieve statistics and store them in Db2. The data can then be accessed and analyzed using a Python Flask app. Today, I going to show you how the web site is protected using OpenID Connect and IBM Cloud App ID.

Cloud Foundry Logging Sources Deciphered

Ever deployed a cloud foundry app and ran into errors? I did and still do. My typical reaction is to request the recent app logs and to analyse them for the root cause. The logs contain those strange (if you don't know them) codes, e.g., RTR, STG, APP, PROC, WEB or more. Here is how to decipher them and use them to your advantage.

Happy Cloud Debugging

The codes above denote the Cloud Foundry component emitting the log entry. You can find a list of those component identifiers in the Cloud Foundry documentation or in the IBM Cloud (Bluemix) documentation on Log Sources. There are many component names. I found that remembering the following helps a lot:

• RTR: This is the router which channels HTTP requests to an app. Here you find information about the request itself including client information.
• STG: The staging phase has details about the deployment and restaging of an app. They help with initial errors.
• APP: If your app writes information to stderr or stdout, then you will find it here. For some apps this could be the well-known "printf debugging".

The log entries have either an OUT if the information is from stdout or ERR if from stderr. Else there is not much to remember. Happy Debugging. If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.

Introduction to Cloud App Security - Part 1

Security for Cloud Apps

Providing a secure app or application is a fundamental requirement. This is especially true in a cloud environment. In my post about “Securing Workloads on the IBM Cloud” I discussed the various layers that realize secure cloud computing. Today, I want to focus solely on apps that are built for deployment in the IBM Cloud. What makes up a secure app? What cloud services help establishing app security? Let’s take a look together.

Note that this is part 1 of 2. Part 2 is linked at the bottom.

Write Your Own CLI Plugins for Bluemix Cloud Foundry

README for my Plugin

Last year I blogged about how I am using plugins to extend the Bluemix Cloud Foundry command line interface (CLI). The CLI has a set of commands to manage plugin repositories and to install and uninstall plugins. It is pretty easy to use and there are some useful plugins available from Cloud Foundry and IBM Bluemix. Having mastered the first step, I wanted to know how plugins work and what it takes to write my own plugin. Here is what I learned.

Improve Security for your Domains on IBM Bluemix

Secure Your Apps

Do you use your own domain names with IBM Bluemix? Then you probably know that you can secure access by adding SSL certificates for your domain. During my recent my work with so-called Context Path Routes for Bluemix Cloud Foundry apps I stumbled over a great project, bluemix-letsencrypt.

The project bluemix-letsencrypt (available on GitHub) provides a Python script and Bluemix app that automate generation and upload of SSL certificates. It uses Let's Encrypt as Certificate Authority (CA). The only thing you need to do is to specify your domain name and email address. Thereafter, the script is run. It uses the Bluemix app to generate the SSL certificates. For the details head over to the Bluemix blog and read the entry "Securing Custom Domains with Let’s Encrypt"

Context Path Routing of Apps and Services in Bluemix

Context Paths for Bluemix Apps

As I mentioned in my post yesterday about simplified deployment of complex apps, I have been working on a sample for Context Path Routing to be used with IBM Bluemix. But what are context path routes and what does the sample do? Here are the details.

Cloud Foundry introduced Context Path Routing last year. Until then there was the requirement that each app (or service) was served from its own hostname. Now, apps can share a host with each app being served from a specific path on that host. Here are two examples:

1. When building a larger website, there could be several so-called microsites embedded. With Context Path Routing it is possible to serve, e.g., example.com from one web app and example.com/user-management or example.com/news from other apps. All these apps could be written in different programming languages such as Node.js, Python, Java and others. 
2. For a more complex microservice-based app, following the principles of the Twelve Factor App, there could be several (backing) services involved. The app and each would require their own hostname. With Context Path Routing the app could use app.mybluemix.net and services could be served from app.mybluemix.net/service1, app.mybluemix.net/service2, etc.

So how could you use the new routing feature? There are several Cloud Foundry CLI commands related to routing. They allow to specify an additional path for application routes. Manifest files also have optional route properties that could be set. To get started, take a look at my Context Path Routing sample on GitHub for details. It has two small apps written in Python and Node.js that share a host using specific paths. The apps can be deployed with a single command and allow to experiment with context paths. The "What this samples does" section gives you some ideas.

Bluemix: Simplified Deployment of Complex Cloud Foundry Apps

Two apps from single manifest

Recently, I was looking over a microservice-based app to be deployed to IBM Bluemix. There app consisted of several pieces, the app itself and multiple services. Fortunately, all could be deployed with a single "push". Here is how.

Cloud Foundry allows multiple apps to be described with a single manifest file. That is, properties for several apps (or services) can be put together. For each app its name and the location where its code is found need to be specified. They are shown in blue in my sample manifest file. Each app can be deployed to a specific machine, identified by the host and domain name. For the example I chose a different approach. It is the relatively new "routes" property. It allows to combine those properties and even add paths information. The routing is highlighted in yellow below. All I needed to do is to execute a simple "cf push" command and the entire application with its multiple pieces got deployed.


Here is the sample manifest.yml file:

# This manifest deploys two applications.
#
# Both use the same host and domain name as defined
# by their respective route(s) property. The first app
# uses the root path, the second the "sub" and
# "lower" paths.

applications:
# The Python app starts here
- name: yourname-myapp
  memory: 256M
  command: python myapp.py
  routes:
  - route: yourname-myapp.mybluemix.net
  path: ./top/ 

# 

# The Node.js app starts here 

#

 - name: yourname-myapp-node
  routes:
  - route: yourname-myapp.mybluemix.net/lower
  - route: yourname-myapp.mybluemix.net/sub
  path: ./lower/

If you wonder how the entire project looks like, visit https://github.com/data-henrik/Bluemix-ContextPathRouting for the source code and a more detailed description. I put this repository together to showcase Context Path Routing on IBM Bluemix which I will discuss in an upcoming blog post.