Wednesday, November 27, 2019

AWS re:Invent 2019 Is Coming!

Join the Bitnami team at AWS re:Invent 2019, December 2-5, in Las Vegas and learn more about how Bitnami’s range of offerings can help you accelerate software development and delivery.

You can find us at VMware booth #2108 (pod 12) in the Venetian / Sands Expo Hall. Our experts will be able to show you how to leverage our open-source application catalog available on the AWS Marketplace, in a hybrid cloud model on VMC on AWS, and more.

Bitnami will also be sharing more about our recent announcement, Project Galleon - a new enterprise offering focused on delivering a superior developer self-service experience, while simultaneously helping IT enforce security and compliance standards. The focus of this offering is to help development teams go from ideation to production easier, faster, and with best practices built-in from the ground up.

We’ll also be highlighting Bitnami solutions for building modern apps during sessions at the VMware Code booth. Check out all our sessions and presentations below, and remember to add them to your re:Invent agenda today!

{CODE} Sessions 

VMware Booth #309, Aria / Pinyon Ballroom

Wednesday, 1:30 PM

Shortcut and Better Secure Modern App Development with Bitnami Containers and Chart Foundations

Thursday, 12.30 PM

Continuously Refresh and Secure Software Catalogs, Providing Simple and Secure Access


VMware booth #2108 Theatre area, Venetian / Sands Expo Hall

Tuesday, 1.30 PM | Wednesday, 9.30 AM | Thursday, 11 AM

Managing Software Supply Chains with Bitnami and Project Galleon

We’re looking forward to seeing you in Las Vegas!

Wednesday, November 13, 2019

Helm 3 Arrives to Boost the Way to Deploy Applications on Kubernetes

It's been three years since Helm's first release and it is, undoubtedly, the de-facto way of deploying applications in Kubernetes. This is thanks to its simplicity and ease of use and its ability to manage upgrades and rollbacks with ease.

Helm 3 is further evidence the community is continuing to advance and mature. Its new features and improvements make Helm charts even easier to manage, and offers the most secure way to move applications to production. Read on for the details.

Say goodbye to Tiller

Helm is comprised of two parts: Helm (the client) and Tiller (the server). In previous versions, when you initialized Helm running “helm init”, Tiller was installed automatically. 

Tiller had an important role in clusters that were shared across different teams as it allowed multiple operators to interact with the same set of releases at the same time.

When role-based access controls (RBAC rules) came along with the release of Kubernetes v.1.6, the use of Tiller in a production scenario became more difficult due to the multiple security policies that you can set for your cluster. Take a look at the numerous pre-configurations you should do in order to install and configure Helm and Tiller to realize how RBAC rules complicated the management in a multi-tenant cluster.

Based on user feedback, the Helm team removed Tiller in the latest release. They found that fetching the information from the Kubernetes API server, rendering the charts client-side, and storing the record of the installation in Kubernetes was the best way to collect Helm release information (instead of using Tiller as a central hub). 

With Tiller gone, Helm’s security relies on your kubeconfig file where cluster administrators define user’s roles and permissions.

Open Container Initiative: Removing Chart Repository Limitations for Production Environments 

Helm 3 also provides new ways of managing chart repositories. For a long time, Docker Registry has been the de-facto toolset to store and deliver Docker images. Many cloud vendors also offered different versions of the Docker Registry that implemented security features to try and mitigate some of the more common chart repository limitations:

Chart repositories usually take a long time to abstract the security implementations needed for a production environment.

Not every chart repository includes tools for signing and verifying the origin and integrity of a chart.

Using a unique index file for metadata information makes searching and fetching charts hard, and makes it more difficult to manage security in multi-tenant scenarios.

Although it is still experimental, the Open Container Initiative may solve these limitations by adding login support and other features that will be essential for managing charts with Helm 3.

Try Bitnami charts with Helm 3

The Bitnami catalog has already been tested and validated to work with Helm 2 and Helm 3 across the major Kubernetes platforms.

Bitnami runs daily tests on its entire application catalog to make sure that all solutions can be deployed successfully without issues in any platform.

As one of the largest maintainers of Helm charts (currently 60), we have focused our efforts on delivering maintained, secure, and production-ready charts.

Why don’t give it a try? Install Helm 3 in your cluster now and select any of Bitnami charts from our GitHub repository to test its new features!

For more information about Helm 3 new features and changes, read the official announcement or refer to Helm FAQ. 

Friday, October 25, 2019

Kubeapps v1.6.0 is out!

Authored by Andrés Martínez, Member of Technical Staff

Over the past few months, the Bitnami team has been working on adding features to Kubeapps such as the ability to rollback releases and to customize private Helm registriesThis new release adds to these improvements with support for two major new featuresForms to deploy and upgrade applications and OIDC support with OAuth2_proxy.  

Keep reading to discover these new features and how to start using them. 

Simple Forms to Deploy and Upgrade Applications 

Iis now possible to change the default chart configuration for new deployments easily. This feature is already active for the stable versions of WordPress, PostgreSQL, and Apache, and there are more to come! 

By clicking the Deploy button for those charts, a new form is displayed. This form allows you to change common parameters, such as the username or password, without the hassle of knowing how the values.yaml file of the chart is structured. 

With this new feature, iteven easier to adopt Kubernetes applications that are ready for production. Watch the following video to learn how to deploy WordPress after modifying the default values:

How can you add this form to your chart? 

With Helm v3you can include a JSON Schema along with your chart. This file is named values.schema.json and it allows you to describe the content of the values.yaml file. The goal of this new file is to verify that the chart values satisfy the expected structure, but Kubeapps also uses it to render the form mentioned in the section above. With some special annotations, you can specify which parameters should be presentso Kubeapps can render it. To learn more about this feature, check the Kubeapps developer documentation. 

OIDC Support with OAuth2_proxy 

Some time ago, we started to support OpenID Connect (OIDC) as an alternative to the default login experience in Kubeapps. If you enable it, you can login in to Kubeapps with an email account using the identity provider of your choice, such as Google or GitHub:  

By installing Kubeapps v1.6.0you can now configure OIDC to work with more managed platforms for Kubernetes, like GKE, thanks to oauth2_proxy But remember, iyou were using OIDC in previous versions of Kubeappsyou will need to change some of the chart parameters to enable this featureCheck out these instructions to learn how! 

We would like to hear about your experience with the new version of Kubeapps. You can reach out to the Kubeapps team both through our GitHub page and through the #kubeapps channel in Slack. 

Happy Helming!