Hands on Pivotal Cloud Foundry 1.7

Hands on Pivotal Cloud Foundry 1.7

Before we start, just a quick note that this post is the first of three parts about comparing different PCF versions to each other. In this case we will have a look at PCF 1.7 / 1.8 and 1.9. In this post we will start with PCF  1.7.

During the last twelve months, Pivotal subsequently improved Pivotal Cloud Foundry (PCF) and has released three major versions since the beginning of May 2016. It was just last Thursday that Pivotal released version 1.9 of its version of Cloud Foundry. Sometimes it might be hard to stay on track with all these new versions and the changes that are coming with them; but it is necessary for operations to get to know them.

For that reason, I decided to summarize the new features/changes of PCF 1.7/1.8/1.9 and compare them to each other or sometimes even to version 1.6.

For all the operators that did not update their system to 1.9 yet, I will list things you should take care off. Nevertheless, check the official Pivotal Documentation before upgrading to a new major version.

So let’s start right ahead because we do not know when the next major version is coming ;-)

PCF 1.7

First we will concentrate on the new features and major changes PCF 1.7 came up with.

Diego completely replaces DEA

In my opinion, this is the ‘largest’ change Pivotal introduces in this version of PCF. It was obvious, that, after introducing Diego in PCF 1.6, it would replace DEAs by some time, but that this moment comes that fast surprised me a bit. As you might already know, Diego are the DEAs rewritten in Go.
But Diego is not just DEA with the ruby code replaced by some Go code, the architecture also changed. You could find more detailed information about the Diego Architecture in Pivotal’s documentation. 
Along with Diego, Pivotal introduced the possibilities to enter the container your app is running in (cf ssh) and you are able to push Docker container to PCF.

Before you are upgrading from PCF 1.6 to PCF 1.7, please make sure that all your apps are deployed to Diego Cells instead of DEAs, because if not, your apps are not longer running after the upgrade. Please follow the guide to ‘Migrate Apps to Diego’.

Identity (aka UAA Server)

Version 1.7 of Pivotal Elastic Runtime allows you to configure some UAA specific values. First, operators are able to configure a password policy inside the ER tile. This policy configuration includes password length, specific character type requirements, expiration and maximum password attempts allowed.

After the configuration of the password policy there is a feature that allows you to define the lifetime of different tokens (Apps Manager Access Token, Cloud Foundry CLI Token).

You are also able to configure some SAML features. Find more about those solutions in the documentation about ‘Configuration Authentication and Enterprise SSO’.

elastic_runtime_17_password_policy elastic_runtime_17_token_lifetime

Floating Stemcells

A feature that really improves security was the ‘Floating Stemcells’ feature. With that, operators do not have to wait until a new .pivotal file is uploaded to the PivNet to apply OS level security patches to the installed services. The major version of the stemcell will stay the same. This also means that only products with the same major version of a stemcell will be affected/updated by the floating stemcell feature.

On the one hand, this feature is a good thing from a security point of view, on the other hand, updating a single stemcell can cause multiple tiles to be upgraded; which may significantly increase update times on large environments. If you want to turn this feature off manually, you have to change the manifest for the tile.

Elastic Runtime Tile Changes

With version 1.7 of PCF, Pivotal redesigned the Elastic Runtime Tile to improve workflow for operators. Also they added advanced logic to make configuration of complicated network use cases more easy for operators. This was a really nice move, because the Runtime was really messed up with all those configurations stuffed into a little number of points.

elasticruntime_blogpost

Compiled Releases

The Elastic Runtime is now shipped with compiled binaries instead of source code which improves speed of installing and upgrading Elastic Runtime.

Automated Backups

With version 1.7, Pivotal provides a feature that enables automatic backups on S3-compatible blobstores. This backups cover the internal MySQL configured in the ER-Tile. In general, this is a nice feature to have as an operator.

Unused Docker Image Cleanup

After introducing the feature to push Docker Containers to PCF, the PCF environment might be ‘polluted ‘ by unused Docker Images. At this point, PCF supports operators by providing an automation to clean up unused docker images.

PCF operator can decide how aggressively unused Docker Images are removed. You have the choice between a routinely cleanup (routine in this case is defined by Pivotal and is not specified in detail) and a cleanup conducted once a threshold, defined by an PCF operator, is reached. This threshold refers to the size of all Docker  Images (regardless if they are in use or not) on an individual Cell VM. The default choice is the routinely cleanup.

The advantage of less frequently cleaning up is that subsequent push/scale events for Docker images that have previously been run on the platform may be faster, because the image does not have to be downloaded again.

elastic_runtime_17_docker_image_config

Route Services

Route Services are a new kind of Marketplace Service, that developers can use to apply various transformations to application requests by binding an application’s route to a service instance. We are planning to explain this feature in more detail in a separate blog post. Stay tuned for that.

Space Scoped Private Service Brokers

With the introduction of space-scoped service brokers, space developers are allowed to create and manage a service broker that is scoped to a single space. This is very useful to allow faster iteration on service brokers without requiring full admin privileges.
This feature allows a space developer to develop a service broker without making the service useable by other spaces. In addition to that, you could add a service only for a specific space. The command to register a service broker with the CF CLI is:

cf create-service-broker SERVICE_BROKER USERNAME PASSWORD URL --space-scoped

To be able to to register your own service broker, an operator has to enable the feature via the ‘space_scoped_private_broker_creation’ cloud controller flag.

Apps Manager White Labeling

Operators can now visually brand Apps Manager by changing certain text, colors, and images of the interface. This interface will be seen by developers when logging in, creating an account, resetting a password, or using Apps Manager.

That’s it for version 1.7 of Pivotal Cloud Foundry. In Part 2 we will have a look at PCF 1.8 before we will checkout PCF 1.9 in the last part of the series. So stay tuned for more to come. 

Leave a Reply

Your email address will not be published. Required fields are marked *