In the SUSE Developer Community we always strive to provide you with the best and latest developer experience. You probably saw that version 2.0 of SUSE Cloud Application Platform was released recently. (If not, you might want to have a look at the release notes or read Thomas di Giacomo’s blog post on the release.) So it goes without saying that we wanted to provide you with this major update in our CAP Developer Sandbox cluster as soon as possible.
Preparations for upgrading the CAP Developer Sandbox system to CAP 2.0 had already started before the GA announcement, but we had to wait until the final release candidate was available before we could start testing the migration procedure. And to tell you a little secret: Updating from our previous version CAP 1.5.2 to CAP 2.0 is actually not an officially supported migration scenario, so we – with a lot of help from our colleagues from the CAP Pm and engineering team (Chris, Troy – you’re legends!) – had to go deep into uncharted territory.
So we are very proud to announce that the CAP Developer Sandbox system now runs SUSE CAP 2.0!
As you may have noted, the update took us a little longer that we originally thought – apologies if that caused you problems. After the upgrade itself, everything looked fine initially. But as we started to migrate all existing user accounts, we noticed that we had to adjust a few system configs to enable the system to cope with the significant load. That took some time to figure out. Since Friday afternoon, things are back to normal operation.
What does the upgrade mean for me?
The most important change CAP 2.0 brings to you as a software developer is that it has the latest versions of the upstream build packs included:
- binary-buildpack: 1.0.36 (release notes)
- dotnetcore-buildpack: 2.3.9 (release notes)
- go-buildpack: 1.9.11 (release notes)
- java-buildpack: 4.29.1 (release notes)
- nginx-buildpack: 1.1.7 (release notes)
- nodejs-buildpack: 1.7.17 (release notes)
- php-buildpack: 4.4.12 (release notes)
- python-buildpack: 1.7.12 (release notes)
- staticfile-buildpack: 1.5.5 (release notes)
- ruby-buildpack: 1.8.15 (release notes)
Some of these have changed the supported language or tooling versions, so it is possible that you’ll have to bump versions in your local toolchain as well if you’ve been running on older versions. Please check the release notes of the build packs you’re using for details.
Also, it might be worth checking your apps if you’re not doing that regularly, to see if everything came up the way it should after the upgrade. From what we’ve been seeing everything went fine, but we haven’t been able to check every app in detail.
What else should I know about CAP 2.0?
I know exactly what you’re thinking – newer build packs and that’s it? Why did they make that a major release? You probably guessed it already: there’s more! Even though the developer experience stays largely the same, the changes under the hood are genuinely exciting and get us much closer to a Kubernetes-native “cf push” experience.
It is the first CAP release that is based on the KubeCF upstream project code base. This is one of the initiatives in the Cloud Foundry community to make the operational side of the project more native to Kubernetes. We’ve removed Monit from the containers and are using the standard Kubernetes health checks and lifecycle management to achieve a large number of improvements (including better availability and observability of the control plane).
What comes next?
There’s a couple of further updates to the system coming soon. We will soon be updating our Web GUI to Stratos 4.0 (which will align with SUSE’s new branding), along with updating Minibroker to it’s 1.0 release (featuring a RabbitMQ message bus service in addition to the already existing database services in the marketplace).
In a few months, we will also be gearing up for the CAP 2.1 release. This will come with a switch to Eirini allowing for even better integration with Kubernetes and gives us significantly better options when the cluster needs to scale out. Due to some of the architectural changes we are electing to adopt, it is unfortunately unavoidable to schedule another maintenance window (or two) for the platform upgrade. As always we will try to reduce end user impact as much as possible. Watch this space for updates!