Vom Docker Image über Kubernetes-Manifeste hin zu Helm Charts Thorsten Hans @ThorstenHans Cloud-Native Consultant

Consultant @ Thinktecture #Azure #Kubernetes #CloudNative #Docker [email protected] thinktecture.com thorsten-hans.com @ThorstenHans Microsoft MVP | Docker Captain Thorsten Hans

What we won’t cover • Docker & Kubernetes Basics • Automated Deployments • Continuous Deployment • GitOps Non-Scope

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• As developers we use Docker to run our dependencies and apps locally • We leverage Docker CLI to poke containers and images • From Ops perspective, Docker unifies packaging & distribution • Docker support is (almost) everywhere Introduction

However, having just a bunch of Docker images laying around is not enough. We must provide additional context, configuration, and instruct the application platform on how it should connect the dots between all components of the bigger system Introduction

• In Platform-as-a-Service (PaaS) like Azure App Services, we use service capabilities to provide context and configuration • AppSettings & ConnectionStrings • Autoscaling • Diagnostics • We orchestrate PaaS applications using additional cloud services (e.g. Azure Virtual Network, Azure Application Gateway, Azure Front Door, …) Introduction

• In Kubernetes, we provide context and configuration by providing corresponding Kubernetes Manifests • ConfigMap, Secret • HorizontalPodAutoscaler • Service • We deploy additional apps to a cluster to support advanced capabilities • We use Cert-Manager to create, rotate, and renew SSL certificates • We use Ingress Controllers to route requests to certain applications in Kubernetes Introduction

• Serverless services like Azure Container Apps are based on Kubernetes, their deployment manifests are a superset of regular Kubernetes Manifests • Knowledge about underlying Kubernetes manifests is a benefit • Microsoft.App/containerApps is a combination of • Kubernetes Deployment • Kubernetes Service • Kubernetes HorizontalPodAutoscaler Introduction

Bottom line, your Docker Images must be customizable or configurable to run in different environments without having to build a new Docker image when switching the application platform Introduction

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

We want to… • Run our Docker Image Kubernetes Manifests

We want to… • Run our Docker Image • Provide Configuration Kubernetes Manifests

We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption Kubernetes Manifests

We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption We use a Pod (the simplest way to run a particular Docker Image) in Kubernetes. Kubernetes Manifests

We want to… • Run our Docker Image • Provide Configuration • Constraint resource consumption • Run our application twice (replicas: 2) We use a Deployment (which technically contains a Pod spec) in Kubernetes to gain more control over the application at runtime and configure things like replications or upgrade strategies Kubernetes Manifests

In Kubernetes we enforce loose coupling by defining labels on resources like Pods. Other resources like HorizontalPodAutoscaler or Deployment are connected using label- selectors. Kubernetes Manifests

• Build Kubernetes Manifests for an ASP.NET Core WebAPI • Deploy the app to Kubernetes Demo

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Think of Helm (https://helm.sh) as the Kubernetes Package Manager • With Helm we can deploy applications (called Charts) • A Chart is • A collection of logically related Kubernetes manifests • A customizable set of values that allow customization upon deployment • When we install a Chart in a Kubernetes cluster, we create a Release • Helm leverages Kubernetes API server (no server-side component necessary) Helm Charts

• In Helm, templates are written using the Go Template Language • Helm comes with predefined functions & pipelines that we use in our templates • We can build custom helpers to address DRY and ensure consistency • Installing a Helm Chart is an atomic operation (no matter how many manifests are part of the Chart) • Helm Charts can have dependencies • Helm Charts are distributed using Helm Repositories or Docker Registries (OCI compliant artifacts) Helm Charts

• Create a Helm Chart for an ASP.NET Core WebAPI • Deploy a single Helm Chart with different configurations to Kubernetes Demo

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Introduction • From the Docker Image to Kubernetes Manifests • From Kubernetes Manifests to Helm Charts • Conclusion Agenda

• Use decarative manifests instead of deploying applications imperatively with kubectl • Learn basic Kubernetes Resources (e.g. Deployment, Service, HorizontalPodAutoscaler) • This is also useful if your intent is to use services like Azure Container Apps • Due to indentions, YAML is painful enough! Don’t make it worse by putting multiple resources in a single YAML file • Applying multiple manifests with interconnectivities at once may result in errors • E.g. deploy resources to a namespace that is still being deployed by the same deployment command Conclusion

• Use Helm Chart for deploying your applications if • You deploy multiple replications of your app (either to a single or to multiple clusters) • Someone else has to deploy the application and must provide contextual configuration • Trim-down your Helm charts and allow only necessary configuration (values) • Think about implementing an umbrella chart for your entire application to simplify deployment even more • Lint your Helm charts before distributing them Conclusion

Thanks for your attention @ThorstenHans