When you want to get your code from laptop to production, there’s nothing better than Pivotal Cloud Foundry. Just cf push your app, and the platform does the rest for you. Moments later, your updates are in prod.
Platform operators have their own glorious workflow. With Pivotal Cloud Foundry (PCF), patches, updates, and upgrades are automated and effortless.
Both sets of capabilities are on full display in PCF 2.4, which is now generally available. Let’s start by looking at how the app deployment process gets better.
PCF now supports native zero-downtime rolling deployments. Cloud Foundry has supported blue-green deployments for a while. But you needed two app versions, and some client-side orchestration to make it work. Now, client-side coordination is no longer required. Instead, the coordination now happens on the other side of the PCF API. It’s not a substitute for a full-featured CD tool, but it’s handy in lots of scenarios. Try it out as a beta in PCF 2.4!
Developers can scale their app in new ways in PCF 2.4. App Automator (in beta) allows you to define scaling rules based on custom app metrics. This new service uses other new capabilities (like the Metric Registrar and the new Log-Cache metrics endpoint) to give you more control over how your app behaves.
Here’s what’s new for platform teams in PCF 2.4:
Dynamic egress policies. Want to make a policy change with Application Security Groups (ASGs)? In the past, you had to restart your app. Now, operators can instead use dynamic egress policies to make policy changes with zero downtime. This feature debuts as a beta, as well; experiment with them to see how they can replace ASGs over time. Say goodbye to those annoying app restarts!
Zero-downtime stack updates. In PCF 2.4, the new
cflinuxfs3rootfs (based on Ubuntu 18.04 LTS) is the default stack for new apps. With previous versions, migrating your app to the new stack would have required a restage and restart. Now the platform executes this in a automated and rolling fashion. That means no effort and no downtime.
PCF 2.4 continues the zero-downtime OS updates across the whole platform. Dealing with Operating System end of general support dates can be stressful, but with PCF this should be a minor and fully automated change in your environment. More PCF software has updated to Ubuntu 16.04 with this release ensuring you can keep getting non-disruptive security updates for all software on the platform.
Zero downtime stack updates are a massive boost to productivity. Engineers can just go about their day, while PCF updates the bits under the hood.
But you really start to appreciate the power of zero-downtime updates when a new CVE hits. And what do you know, a Kubernetes Critical CVE was revealed earlier this month. Pivotal tested the fix, and pushed it out shortly after the vulnerability was discovered. Many Pivotal Container Service customers had their Kubernetes clusters patched in production before the news about the CVE became public. We recap this story below because it’s a terrific example of how you should run your most important business systems.
The other great thing about the automation PCF brings to your enterprise is that comprehensive security is baked into the platform. Developers inherit loads of security controls from PCF. For example, CredHub protects your passwords and other secrets, you get multi-tenancy through the permissions model, and you enjoy automated dependency management with buildpacks. (And your platform teams keep PCF in a healthy state using the aforementioned automated process.)
On to the release highlights!
One popular way to reduce risk when rolling out a new version of your app is to use a blue-green deployment. Here’s the scenario:
Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.
At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.
As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.
Cloud Foundry has supported this scenario for quite some time, but you had to have two different versions of an app plus some homegrown scripting or orchestration. Now, PCF 2.4 gives you the option to do a similar process natively in the platform. First, cf push an app (i.e. your-app-name) like normal. Then, when you want the platform to cut-over to the new version, you just type:
From there, PCF gradually brings instances of the new version online. As they prove to be working and healthy, the older versions are subsequently removed. This option isn’t meant to be used in lieu of a continuous deployment tool. But you’ll find it useful for loads of other scenarios, like performance tuning, code-level security fixes -- even chaos engineering!
For a screenshot tutorial, check out Richard Seroter’s thread:
Blue/green deploys are a popular way to update apps without taking downtime. There's complexity there, however. Want to see a neat feature coming to @pivotalcf 2.4 in a couple weeks?— Richard Seroter (@rseroter) December 5, 2018
First, I built a #dotnetcore web API, and told @cloudfoundry that I wanted 4 instances.
You can also watch Zach Robinson’s demo from Cloud Foundry Summit earlier this year.
Long-time Cloud Foundry operators are intimately familiar with Application Security Groups (ASGs). Operators use ASGs to control how applications interact with off-platform services. With ASGs, you create and manage rules that specify the protocols, ports, and IP address ranges where application or task instances send traffic.
ASGs work fine for the most part. But there is one annoying thing about ASGs: you have to restart your apps when you apply a new policy or update an existing one. This results in undesirable downtime. Another constraint with ASGs is that permissions are too coarse. Policies can only apply at the space level, not the application level. So you must grant access to an external service for all the apps in a given space, even if you just need a single app to talk to said service.
In PCF 2.4, there is a better way to govern these traffic flows: Dynamic Egress Policies, a beta capability in PCF 2.4. (This feature was released as part of open source Cloud Foundry v2.19.0.) With Dynamic Egress Policies, you can configure egress policies for CF apps and spaces, just by using the IP address range.
Zero Downtime Stack Updates to cflinuxfs3: We Maintain the Base rootfs in Your Containers So You Don’t Have to!
In PCF 2.3, Pivotal added support for the Ubuntu 18.04 stack and
cflinuxfs3 for all supported buildpacks. New installs of PCF 2.4 will run the
cflinuxfs3 stack and related buildpacks by default.
A few items to note:
cflinuxfs2remains the default stack for PCF 2.2 and PCF 2.3.
The default stack can be toggled between
cflinuxfs3. This setting will be inherited upon upgrade.
While the upgrade to
cflinuxfs3 is seamless, there may be some impact to your apps. Make sure to test them before cutting over to the new version in production. As always, work with your account team to work through this transition!
In PCF 2.3, we bumped the OS version of several tiles to Ubuntu 16.04, the latest release. Since then, a slew of additional services have bumped their stemcells to Ubuntu 16.04, including:
It’s almost 2019. Are you still patching your operating systems manually? Or worse, not patching them at all? Ask any Pivotal customer how liberating it feels to never worry about an OS patch again!
I like to say there are three certainties in life: death, taxes, and security updates. The Kubernetes world was jolted with a CVE earlier this month when a privilege escalation vulnerability was discovered. Here’s how ZDNet described the issue:
With a specially crafted network request, any user can establish a connection through the Kubernetes application programming interface (API) server to a backend server. Once established, an attacker can send arbitrary requests over the network connection directly to that backend. Adding insult to injury, these requests are authenticated with the Kubernetes API server's Transport Layer Security (TLS) credentials.
Yikes. Surprised by this? You shouldn’t be. CVEs exist in every piece of software. Expect more of them to hit. The question is how fast can you respond to them. If it’s more than a day, you need to get serious about modernizing your infrastructure operations.
Here’s the good news: we can help you with that! Our own John Allwright explained how PKS customers instantly and effortlessly applied this patch to their Kubernetes clusters before the news was even widely reported:
For PKS customers with automated upgrade pipelines, updates from PivNet are automatically applied to their PKS instances. In this case, these pipelines detected a new PKS release (v1.2.3), and immediately updated the customer’s PKS environments, with zero downtime.
Without an automated process, CVEs are stressful, white-knuckle moments in enterprise IT. This fun video captures how much easier life can be with automated patching for your most important business systems!
Were you out partying when the latest @kubernetesio CVE news broke out? Did you rush to work to discuss your upgrade strategy?— Oded Shopen (@odedia) December 10, 2018
If only you had #PKS and @concourseci... You could have patched it from your wrist 😎
(Directed and filmed by @KobiShamama. Video editing by @odedia) pic.twitter.com/RA1zQSrIfg
More and more organizations are leaving the drudgery of OS management to automated platforms. DISA recently updated its Security Technical Implementation Guides (STIGs) to certify the use of embedded operating systems for DoD work.
We are all for this movement, and want to help accelerate it. So we’re launching the Compliance Scanner for PCF. Here’s how this tool will help auditors and compliance teams at big organizations.
There’s a universe of third-party configuration scanners for determining security and compliance in operating systems. By and large, these tools were for the pre-platform era, when the OS wasn’t embedded. So, the industry needs scanning tools that are purpose-built for platforms. Hence, Compliance Scanner for PCF!
The tile includes the best of both worlds: remastered tests that simultaneously fit the stemcell model, while aligning with industry-recognized guidelines for secure configurations. What’s not to like?
With just a few clicks, your compliance team will get a full report on the compliance posture of the entire platform. That means you get the green light to go to production, without waiting for a prolonged compliance period.
The results from the Compliance Scanner for PCF, coming soon!
The Compliance Scanner for PCF includes:
The OpenSCAP scanner that does the actual scanning.
Tests written by Pivotal Compliance Innovation in YML.
XGen: XCCDF Generator, which translates the YML tests to XCCDF formatted XML, as defined by the SCAP standard.
This piece of tech should make the auditor’s job much easier. Want to make their job even easier? Make sure you send them this whitepaper: Pivotal Cloud Foundry: The Auditor’s Guide!
Here’s a neat feature. What if you could schedule scaling events for your apps - or schedule recurring batch jobs with a simple manifest file? That’s App Automator, and it’s a beta in PCF 2.4. So how does it work?
Developers can express when & what workloads should run via “Triggers” & “Actions”. These parameters live an App Automater manifest that lives within the app code. The manifest would look something like this:
App Automator includes predefined Triggers and Actions based on common scenarios:
Triggers: schedule/cron, event, and metric
Actions: scale, curl, task
It’s easier to build pipelines. Scheduling and scaling behavior lives in the App Automator manifest.
Simplified operations. No database, no service broker. Just install via CLI, and App Automator is available in the Space.
App Automator will be available in the coming weeks. We’ll update this post with a download link to the CLI plug-in. In the meantime, contact your account team for access!Note that App Automator is compatible with PAS 2.2 and above.
Once you have hundreds - or thousands - of apps running PCF, you’re going to need an easy way to find a specific app or service instance. You may want an easy way to search across your orgs and spaces too.
Now you can, with the new global search capability in Apps Manager! Simply type your search terms in the top search bar, shown below. Hit enter, and the search will quickly return results for that string across all your orgs, spaces, service instances, and apps.
Apps Manager in PCF 2.4 now features a global search.There’s more. Apps Manager is really useful for developers just ramping up on Pivotal Cloud Foundry, especially when compared to the cf CLI. We want Apps Manager to have pragmatic parity with the CLI wherever possible. So, in PCF 2.4, Apps Manager gains additional parity with the CLI for restaging your app and service instance sharing.
Pivotal wants to help operators efficiently manage the platform and onboard new developments teams. We already talked about all the zero downtime goodness in this release, so let’s dig into new enhancements that unlock efficiency in other areas.
Improved permissions logic eases day-to-day administration.
Ops Manager users with write access can use the UI and API when another user with write access is logged in at the same time. This is the finishing touch on a recent round of new role-based access control features.
Expiring cert warning
PCF now protects several communication pathways with the TLS protocol. TLS, of course, uses certificates to ensure that the “client” and “server” on each side of the transaction are authorized and authenticated to share data. Managing all these new certs gets a little easier over the last 18 months, going way back to PCF 1.12 with certificate rotation APIs. We’ve further enhanced this workflow in PCF 2.4. Now, Operations Manager will now proactively prompt you with a banner when your certs may be expiring soon. Here’s a sample of the UX:
Operations Manager 2.4 warns you about expiring certificates.Now, it’s easier to ensure that your certs stay current!
Bring your own antivirus software for the BOSH Director VM
Need to run antivirus software on the VMs that power PCF? Use PCF’s ClamAV Add-On. Prefer a different option? Now you can bring your own! This option will appeal to operators with specific antivirus requirements.
New tools for IaaS customization - Global CPI extensions
PCF is, of course, a multi-cloud platform. The platform’s underlying cloud provider interface (CPI) handles the subtle differences between IaaS providers for you. The end result is a uniform, consistent operational experience across any private and public cloud. But what if you want to customize how you consume the underlying infrastructure? Now you can customize this experience via self-service, with the new Global CPI extensions feature in Ops Manager. Now hundreds of different config extensions are at your disposal!Note that Global CPI extensions are API only. In this way, they are quite similar conceptually to the
-extensionsfeature announced earlier this year.
“Advanced Mode” offers streamlined workflows for power users
OpsManager "locks" certain fields after a successful deployment. If you need to “unlock” some of these fields, you may do so with via Advanced Mode. As the name suggests, this feature is recommended for advanced users only. And please use this feature in conjunction with Pivotal Support!
Metric Registrar allows app developers to export custom app metrics as native CF Metrics. Developers can use it easily create custom metrics that better signal app health and performance, using standard client libraries like Micrometer or Prometheus.
There is a new CLI plugin which you can install via:
This will allow you to register your app with the Metric Registrar and gives you two options for emitting custom app metrics: via a public metrics endpoint or through structured logs.
An Overview of Metric Registrar
One other quick note: this capability is off by default. To enable it, simply go to Ops Manager > PAS > Metric Registrar for the settings.
When you think of a cloud-native database, what attributes leap to mind? On-demand provisioning for sure. You want lots of availability provisions, like leader-follower and automated failover. And you want security built-in, with something like TLS.
Our MySQL tile team has been busy shipping these features (and more!) over the last year. Now in MySQL for PCF 2.5, we’ve added another essential feature your enterprise will appreciate: high availability through Galera clustering.
Now, enterprise application developers and operators can now enjoy resilience and application availability even in the face of platform and network failures. Jagdish Mirani offers this excellent write-up with all the details.
MySQL for PCF 2.5 is now GA! Check out all of the new features: https://t.co/pMZmBS8V2s— Pivotal (@pivotal) December 18, 2018
The adoption of TLS in PCF continues apace in this release. Here’s what’s new on the TLS front:
You can configure PAS 2.4 to use TLS for all components' connections to the internal PXC MySQL database.
Similarly, you can configure PAS to use TLS for all components' connections to an external MySQL database. Just provide a CA cert!
Two other updates, related to TLS:
App developers can use CF SSH when a platform operator enables authenticated container ingress. Previously, SSH was disabled in this scenario. That restriction is now gone!
Every PCF 2.4 deployment will now feature improved routing consistency, security, and stability from Gorouters to Linux cells. This feature was opt-in in PCF 2.3; now it’s enabled by default.
Need a reminder why PCF loves TLS? Check out this excellent article by our own Brian McClain.
While security in general is a huge topic in @pivotalcf, the topic of encryption and identification has had quite the journey. So much so that I wanted to take a look at where it’s been and where we can expect it to go in the future! https://t.co/SZrD0bAxYi— Brian McClain (@BrianMMcClain) November 8, 2018
Do you use file servers supporting the CIFS/SMB protocol? Then the SMB volume service is for you! It ships as part of the PAS 2.4 tile.
Developers can use SMB volume services to bind existing SMB shares to their apps. The feature supports the key advantage of the SMB protocol: native password authentication, which means you can control access to file shares without the overhead of configuring an LDAP server.
Concourse for PCF
This service got a significant security upgrade: user-based authentication. Previously, you had to log in under a specific team without an association to a user. In Concourse 4.2.1+, users can authenticate into teams as specific users. (Users can be added to a team by configuring the team’s allowlist as described in Configuring Team Authentication.) Another cool thing about this feature: it enables the possibility of other security capabilities, like role-based access control. Stay tuned on this front!
PAS for Windows 2.4
Two things of note on the Windows and .NET side of the house:
Operators can now control the density of Windows cells. This is a useful feature if you want to trim your infrastructure costs.
Pivotal now provides and maintains a Windows Stemcells for AWS GovCloud. You can now use PAS for Windows to run .NET workloads on this IaaS target.
Built-in MySQL database
If you are using the PAS built-in MySQL compatible database (rather than an externally managed MySQL), you must complete the transition from MariaDB to Percona in PAS 2.3 or prior before the PAS 2.4 upgrade. Read more about the straight-forward migration procedure here.
Try Pivotal Cloud Foundry for Free
Ready to get started? You can take PCF for a spin on Pivotal Web Services for free. Want to dive into the release a bit more? Check out the links below and read up on the newest capabilities. Then make the move to Pivotal Cloud Foundry!
SAFE HARBOR STATEMENT
This blog contains statements relating to Pivotal’s expectations, projections, beliefs and prospects which are "forward-looking statements” within the meaning of the federal securities laws and by their nature are uncertain. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors, including but not limited to: (i) our limited operating history as an independent company, which makes it difficult to evaluate our prospects; (ii) the substantial losses we have incurred and the risks of not being able to generate sufficient revenue to achieve and sustain profitability; (iii) our future success depending in large part on the growth of our target markets; (iv) our future growth depending largely on Pivotal Cloud Foundry and our platform-related services; (v) our subscription revenue growth rate not being indicative of our future performance or ability to grow; (vi) our business and prospects being harmed if our customers do not renew their subscriptions or expand their use of our platform; (vii) any failure by us to compete effectively; (viii) our long and unpredictable sales cycles that vary seasonally and which can cause significant variation in the number and size of transactions that can close in a particular quarter; (ix) our lack of control of and inability to predict the future course of open-source technologies, including those used in Pivotal Cloud Foundry; and (x) any security or privacy breaches. All information set forth in this release is current as of the date of this release. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time in documents filed by us with the U.S. Securities and Exchange Commission (SEC), including our prospectus dated April 19, 2018, and filed pursuant to Rule 424(b) under the U.S. Securities Act of 1933, as amended. Additional information will be made available in our quarterly report on Form 10-Q and other future reports that we may file with the SEC, which could cause actual results to vary from expectations. We disclaim any obligation to, and do not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.
This blog also contains statements which are intended to outline the general direction of certain of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract. Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an if and when available basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. Any purchasing decisions should only be based on features currently available. The development, release, and timing of any features or functionality described for Pivotal's offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.
About the AuthorFollow on Twitter Follow on Linkedin More Content by Jared Ruckle