After we just checked out the new features of PCF 1.7 in part 1, we will just move on to PCF 1.8 in this part. With PCF 1.8 some really cool features for operators were introduced, so let’s have a look at them.
Pivotal Network Integration
One nice feature for operators operating an online environment is the PivNet Integration. To get it working, you just have to enter you PivNet API Token and afterwards you are able to download upgrades right into your Ops Manager. But it does not seem possible to get the stemcells right of the PivNet, I would really appreciate if this could be added, too.
The pictures below will give you a short impression of the feature and how it looks like in the Ops Manager. The first picture depicts the overview of the available upgrades. In the second picture the ‘EULA’ is shown, you have to accept first before the download starts. The last picture shows the queued download of the upgrade.
Since the release of Ops Manager 1.8, there is ‘Settings Page’ centered in the Operations Manager UI. This Settings Page gathers all settings regarding the Ops Manager in one place. I think, such a central place for settings is nice to have. You can access the Settings Page via the drop-down menu of your user account in the upper right corner. There you are able to
- change the decryption phase,
- change the authentication mode,
- add the PivNet API Token,
- make some Proxy settings and
- export your installation here
- in the ‘Advanced Part’ you can access
- Activity Data
- Download the Root CA Cert
- Diagnostic Report
- Delete Installation
To see the different places, where you can find the export installation settings button, have a look at the picture below.
Support for Service Networks
Operators are now able to create a Service Network in the Ops Manager. Service Networks are used to dynamically provision VMs for on-demand services.
Could be configured via Ops Manager Director > Create Networks. When checkbox is selected, Ops Manager does not provision VMs within the Reserved IP Ranges.
With PCF 1.8 several new API endpoints were introduced for the following categories:
- Configuring product tiles
- Configuring Ops Manager authentication
- Downloading product updates from PivNet
- Viewing logs and credentials
- Resources Assigned to a Job
To get to know more about these and all other endpoints of the Ops Manager API, check the completely redesigned API Docs. The API docs were just redesigned but not relocated, so you could still find them via https://<your-ops-manager-url>/docs.
Custom Instance Counts in Ops Manager Director Resource Config
You are able to set the instance count of the Ops Manager Director to any value you want to.
Hostname for Ops Manager Director
Operators can now specify a custom hostname for the Ops Manager Director in the Director Config page.
With setting a hostname, you are able to configure a load balancer for the ops manager director (This is also possible because you are now able to have more than one director instance). How to set up the load balancer in front of your ops manager director is explained in pivotal docs.
Dual-Home Ops Manager Director (BOSH Director)
Customers can now dual-home their Ops Manager Director (BOSH Director) starting with new deployments of v1.8.0. This release includes a new BOSH networking release with the RP Filter necessary for dual-homing scenarios.
Additionally, customers using the dual-homed feature in Ops Manager v1.6 can now import their installations into v1.8.0 and continue to use the dual-homed Ops Manager Director. You can find more information about special use-cases for that scenario in the Pivotal Knowledge Base.
vSphere Admin Default Password Requirement
For all people that are operating PCF on vSphere, and new requirement was added. Some of you might never realized that problem, but it was possible to start the Ops Manager VM of a new installed PCF without a default password. Now the default password is required. If you do not provide any password, the VM will not boot up.
BOSH Director Retries Disabled by Default
I think every operator knows the problem. You can see your bosh task failing, but instead of being able to fix the error immediately, you have to wait until four more tries are failing. That costs lots of time and sometimes lots of nerves. Since PCF 1.8 this feature is turned off by default. Nevertheless, if network issues occasionally cause your deployment to fail, you could enable this feature again in the Ops Manager Director tile.
Support for Post Deployment Scripts
Ops Manager now supports configuring the appropriate settings in the Director to run post deploy scripts. This setting can be toggled on the Director Config form. Post Deployment Scripts are defined in bosh releases. For more information about post deployment scripts and how the could be defined check the BOSH documention.
Releases, that make use of post-deploy scripts and are deployed on older stemcells or with an older Director, may potentially deploy; however, post-deploy script will not be called.
TCP Routing enables developers to run apps on PCF that support non-HTTP TCP protocols (Check HTTP vs. TCP Routes). To support this, routing components fetch tokens from UAA by calling that component directly over TLS. The cert hosted by UAA is generated by Operations Manager.
A developer can create a TCP route for tcp.shared-domain.example.com on an arbitrary port with the following command. If the clients of the app can accommodate addressing an arbitrary port, then developers should use the –random-port to instruct Elastic Runtime pick a port for your route.
cf create-route tcp.shared-domain.example.com --random-port
To request a specific port, a developer can use the –port flag, so long as the port is not reserved for another space. The following command creates a TCP route for tcp.shared-domain.example.com on port 60035:
cf create-route tcp.shared-domain.example.com --port 60035
Console Database Removed
Pivotal Account User Management Tool
Alongside with the rewritten Apps Manager app, Pivotal added the Pivotal Account User Management Tool. This tool could be deployed as an errand of the Elastic Runtime.
The Pivotal Account User Management tool allows you to create and manage their accounts. This functionality was formerly included in the Apps Manager itself.
In version 1.8.0 of PCF the Collector job on the Elastic Runtime is deprecated and no longer used by any PCF services. That means for you that, if you are upgrading to PCF v 1.8.0 from PCF v.1.6.x (via the PCF 1.7.x upgrade path) and previously used the Collector job to obtain log data from legacy DEA-based applications, you can free some resources by scaling the job down to zero instances after upgrading to both JMX Bridge (Ops Metrics v1.7.9 and PCF ERT v1.7.0 or higher).
API Environment Variable Visibility (Feature Flags)
A new feature flag ‘env_var_visibility’ was introduced. Similar to ‘space_developer_env_var_visibility’, this flag can be disabled to deny access to ‘/v2/apps/:guid/env’ for all users, including administrators.
I will show you the difference between the flag enabled/disabled. If ‘env_var_visibility’ is not disabled the output of the command /v2/apps/:guid/env looks like the picture below.
and output of cf env
Follow these steps to disable this feature:
- Use the cf CLI as an administrator
- List the available feature-flags with cf feature-flags
- Disable the feature-flag with cf disable-feature-flag env_var_visibility
- Check the status of the flag with cf feature-flag env_var_visibility
- Afterwards the output of ‘/v2/apps/:guid/env’ command looks like this
and the output of cf env
- If you want to enable the feature once again, you are able to do so by entering cf enable-feature-flag env_var_visibility
You can find more information about the so called ‘Feature Flag’ in the Pivotal Documentation.
Service Broker Improvements
Service brokers are now able to respond with an ‘operation’ string in the body of responses for asynchronous operations.
This string will be returned by the broker when the Cloud Controller polls for the state of asynch operations. That means you could get more detailed information about asynch operations, e.g. not just a ‘operation in progress’ but rather ‘deploying vms’ or ‘starting processes.
Cloud Controllers will now provide ‘service_id’, ‘plan_id’ and ‘operation’ when polling service brokers for last operation state.
CF CLI v3 Plugin
The Elastic Runtime includes the CF CLI v3 plugin, which works with the Cloud Controller API v3. This plugin is useful for experimenting with the Cloud Controller v3 API without having to curl an oauth token.
Please be aware that the Cloud Controller v3 API is under active development and is currently experimental. Perhaps we will share our experiences with the new version of the API in another post.
Configurable SSH Proxy for Diego Containers
Until version PCF 1.8 operators that were not using AWS (in AWS just enter the ELB name in the Resource Config) had to wait till the Diego Brain was deployed before they were able to configure the load balancer that was needed to allow SSH access to the app containers.
But that was in the past, from now on, there is a field where you can specify static IPs for the Diego Brain job.
That allows you to configure a load balancer to forward the SSH traffic over port 2222 to these ssh proxy IPs. You can find the configurations for all IaaS expect AWS under ER-Tile -> Network -> SSH Proxy IPs.
NFS Migration to WebDAV
The internal file storage provisioned by Cloud Foundry for Cloud Controller files has been switched from an NFS server to the WebDAV protocol, but don’t get confused because the VM/deployment will still be called nfs-server.
There is no actual data migration as part of the switch. The protocol changes on the file server. When you upgrade to Elastic Runtime v1.8.0 or later, you are automatically switched over.
Unprivileged App Containers
You can now switch off privileged containers for your apps (See ‘Understanding Container Security’). Including version 1.8 apps (not Docker containers) that are pushed to the PCF are running in privileged containers per default.
To switch off privileged containers go to ER-Tile -> Advanced Features -> Disable privileged app containers (checkbox), but don’t get to familiar with this feature. In PCF 1.9 the next change for that is just published.
The Ops Manager now generates BOSH 2.0 manifests and has enabled BOSH link support. To get to know more about BOSH links see the BOSH documentation.
BOSH Manifest Flag to Remove Compilers
This release adds a flag to the BOSH manifest that removes compilers. Find more information about that feature flag in the BOSH documentation.
Et voilà, that’s it about PCF 1.8. I hope you found some really useful features in this version of PCF, too. But we’re not finished yet, there’s one more part to come about PCF 1.9. I really hope to see you back here for the last part of the series.