Wednesday, September 2, 2020

Deploy your ASP.NET Core Web Applications on Kubernetes with Bitnami and Helm

Bitnami has released the Helm chart for ASP.NET Core, a framework designed by Microsoft that allows developers to create web applications and services for any platform in a fast and secure way.  

This chart is a good example of the two-way exchange between Bitnami and its community. We are working hard at making more charts available in our catalog and, at the same time, our users are also sending us their proposals for new charts.  

The ASP.NET Core Helm chart is an example of this collaboration. A user proposed this chart for the catalog and, with the help of the Bitnami team, created the manifest files required for building the chart. The result? An updated and production-ready ASP.NET Helm chart that uses not-root containers and ships the latest versions of its components and dependencies. 

This blog post explains how to deploy your custom ASP.NET Core application on a Kubernetes cluster using this new Bitnami Helm chart.

ASP.NET Core: an open source framework for building cloud native applications  


ASP.NET Core provides developers with an open source framework that consists of modular components for cloud-based applications. It has a huge community behind the project paying attention to all user requests and issues. Check out its GitHub repository to learn more. 

ASP.NET Core is completely free, and it is also a multi-platform framework. This means that you can build your applications to run on Windows, Mac and Linux, on-premise or for cloud deployment. 

ASP.NET Core is popular amongst web application developers for its performance, flexibility and ease of use. In addition, this framework also offers the following benefits: 

  • It provides a modular HTTP request pipeline. 
  • It works with Kestrel, IIS, HTTP.sys, Nginx, Apache, Docker
  • It includes Razor Pages that provides page-focused scenarios. 
  • It ships Blazor, a framework for building interactive client-side web UI using C# instead of JavaScript. 
  • It supports the dependency injection software design pattern technique. 

If you decide to build your web applications using this versatile framework, the easiest way to move them to Kubernetes is to use the Bitnami ASP.NET Core Helm chart.  


Deploy a ASP.NET Core application using a Docker image  


Once you have an application image published in your Docker Hub repository (or in another container registry), you can deploy it using the ASP.NET Core Helm chart.  

The first step is to add the Bitnami chart repository as follows:  

$ helm repo add bitnami https://charts.bitnami.com/bitnami 

Then, deploy the chart using the parameters shown below. These will override the default image when deploying the chart. Remember to replace the DOCKER-USERNAME/IMAGE-NAME, TAG_NAME, COMMANDS and ARGUMENTS placeholders with your Docker account username and name of your application, application tag name, and the command and arguments to run your container within a pod.

$ helm install my-release bitnami/aspnet-core 

--appFromExternalRepo.enabled=false \ 

--image.registry=docker.io \ 

--image.repository=DOCKER-USERNAME/IMAGE-NAME \ 

--image.tag=TAG_NAME \ 

--command=COMMAND \ 

--args=ARGUMENTS 

Do you want to learn more about the Bitnami ASP.NET Core Helm chart? Check its README file for a complete list of deployment parameters and then give it a try by installing the chart directly in your cluster or through the Kubeapps catalog!  

Wednesday, July 22, 2020

Helm Chart for Contour: A Chart Contributed by the Bitnami Community

Bitnami has recently released the Helm chart for Contour, an Ingress Controller for Kubernetes. Contour arrives to complete the list of Ingress Controllers available in the Bitnami Helm chart catalog: Nginx Ingress Controller, Kong, and now Contour. 

This chart is a great example of how Bitnami users are contributing to our catalog. Our users are not only sending us Pull Requests and reporting issues, but they are also creating new charts that help extend the Bitnami catalog. 

In this specific case, a user sent a Pull Request containing a proposal for the Contour Helm chart. The Bitnami content team checked it and gave him the support he needed to adapt the chart and make it ready for release. We are very proud of how our community is providing feedback and making our commitment of “creating awesome open source software available for everyone” possible. 

Built following the Bitnami best practices for Helm charts, the Contour Helm chart uses not-root containers and ships the latest versions of its components and dependencies. Continuously maintained by the Bitnami team, this chart is secure and ready to run in production environments.

Keep reading to learn more about the Bitnami Contour Helm chart’s special features and how easy it is to deploy it in your Kubernetes cluster. 

Why use Contour as an Ingress Controller for your Kubernetes cluster? 


As with any other Ingress Controller, Contour lets you control how external users access services in your Kubernetes cluster. It is ideal for organizations with multiple development teams that are using a single cluster concurrently since it helps secure traffic and protect environments when there are changes in Ingress resources. 

One of the most prominent advantages of using Contour is that it is based on Envoy, a powerful open source proxy designed specifically for cloud-native applications.  

Contour offers the following benefits for both cluster administrators and developers: 

Cluster admins can trust Contour as a safe way to connect applications from outside the cluster, helping them to manage TLS secrets and DNS.  

Contour operates Ingress Resources via Custom Resource Definitions (CRDs). This allows developers to interact with Contour by creating Kubernetes objects types that Contour can understand, skipping the need to interact directly with it. 

Apart from these advantages, Contour provides the following features: 

  • It is designed for deploying cloud-native applications using the flexible HTTPProxy API. 
  • It allows dynamic Envoy reconfiguration. When Ingress and underlying components change, the load balancer doesn’t need to be restarted.  
  • It supports TLS Certificate delegation. 
  • It supports Balancing algorithms such as mirroring, auto repetition, and limiting rate of requests.  
  • It enables detailed monitoring of traffic flow and failures. 


Deploy Contour in your Kubernetes cluster using Bitnami Helm charts 


Deploying Contour in your cluster is easy using the Bitnami Helm chart. You can deploy it on any platform without any other dependencies needed. If you are using Minikube, make sure that you do not have the Nginx Ingress Controller already running before installing. 

To deploy the chart, first add the Bitnami repository to your cluster. Then, simply execute the helm install command followed by a name for your release and the name of the Contour chart: 

$ helm repo add bitnami https://charts.bitnami.com/bitnami 

$ helm install my-release bitnami/contour 

These commands will bootstrap a Contour Ingress Controller deployment and an Envoy Proxy Daemonset on your Kubernetes cluster. 



To check the status of the services, execute the kubectl get svc command as shown below. You should see the two services that the chart deploys with their corresponding internal and external IP addresses. 



Now, you will be able to deploy an application in your cluster by enabling Ingress at deployment time. This example shows how to deploy WordPress using the Bitnami Helm chart, but you can choose any other solution from the Bitnami Helm charts catalog or through Kubeapps. 

$ helm install wp  bitnami/wordpress --set ingress.enabled=true 

This will deploy an Ingress rule, which you can check by running kubectl get ingress: 



Note that this deployment uses the same IP address as Contour. Now, you will be able to view your application using the domain name (in this example, the default wordpress.local) or the IP address: 
 



Do you want to learn more about the Bitnami Contour Helm chart? Check its README file for a complete list of deployment parameters and then give it a try by installing the chart directly in your cluster or through the Kubeapps catalog!  

Wednesday, May 13, 2020

Kubeapps Now Supports Private Helm and Docker Registries

The Kubeapps team has released a new version that provides support for private Helm repositories with private Docker images. This is the second release in a month, since last April, Kubeapps also extended its catalog with support for operators. 

From now on, Kubeapps users can include private Docker images in their customized Helm charts and deploy them directly from a private Helm repository.  This support is aligned with the Kubernetes RBAC authentication model with private credentials available only in the configured namespace. Users can only add private repositories in those namespaces in which they have the required permissions.  Similarly, only those users with access to that namespace have access to deploy the charts with private images.

Kubeapps officially supports the following private Helm repositories:


Chose the option that better suits your team and start deploying custom applications from your private repositories from the Kubeapps user interface.

Kubeapps simplifies the deployment from private registries within the Kubernetes security model 


To enable the full support for private repositories, Kubeapps introduced the option of associating Docker credentials to an application repository so that Kubeapps can ensure they are used to pull any matching private images within a chart.

This eliminates the manual configuration you would otherwise need to be able to deploy charts with private Docker images, without which Kubernetes is unable to find Docker images requiring credentials, resulting in a failed deployment.

Without this feature, the user has two options: either create manually an image pull secret in the Kubernetes namespace or ask the cluster operator to make the secret available, and then update the chart values to reference the created secret.

Both situations require that you or the people that will use the application know how to manually add the specific pull secret and reference it in the chart values at deployment time.

Here is where Kubeapps simplify things! How? By associating Docker image pull secrets to an application repository (only available for Helm 3).

From the Kubeapps user interface, create an application repository and after entering the normal URL of the private repository where the app is and basic authentication of the chart:


  • Create the credentials for the image pull secret so that Kubernetes can pull the images from the Docker registry.  
  • Then ensure the newly created image pull secret is selected for the application repository.  



This information tells Kubeapps that whenever deploying any chart from this application repository, if an image matching any associated pull secret is referenced in any pod, then Kubeapps will automatically add an image pull secret to that pod.

Watch the following video to learn step-by-step how to create an application repository to deploy a custom application from external private repositories:



Or check out the documentation for private application repositories to learn more.

Deploy the latest Kubeapps release now!