From 43e33858a6c848dfb130244554ad5e94c38cdc3a Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Sun, 18 Feb 2024 12:31:13 +0530 Subject: [PATCH 01/13] Started Helm templates --- Helm101/helm-charts.md | 4 ++-- Helm101/helm-templates.md | 7 +++++++ 2 files changed, 9 insertions(+), 2 deletions(-) create mode 100644 Helm101/helm-templates.md diff --git a/Helm101/helm-charts.md b/Helm101/helm-charts.md index b34b2c6e..ad809f61 100644 --- a/Helm101/helm-charts.md +++ b/Helm101/helm-charts.md @@ -99,6 +99,6 @@ This template can then be used within all helm charts: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` -This covers the basics of Helm charts, should you need to create one. However, only narrowly covers the full breadth of what Helm has to offer. For more tips and tricks, visit Helm [official docs](https://helm.sh/docs/howto/charts_tips_and_tricks/). Now, let's move on to Chart hooks. +This covers the basics of Helm charts, should you need to create one. However, only narrowly covers the full breadth of what Helm has to offer. For more tips and tricks, visit Helm [official docs](https://helm.sh/docs/howto/charts_tips_and_tricks/). In this section, we briefly touched up on Helm templates as a means to start off the creation of your new Helm chart. However, templates can be a really powerful tool if you want to reduce repetition in your deployment manifests. Therefore, in the next section, we will be diving deep into creating your own helm templates. -[Next: Chart Hooks](chart-hooks.md) \ No newline at end of file +[Next: Helm templates](./helm-templates.md) \ No newline at end of file diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md new file mode 100644 index 00000000..35bcb66c --- /dev/null +++ b/Helm101/helm-templates.md @@ -0,0 +1,7 @@ +# Helm templates + +In even a small-scale organization, you would have at least a couple of applications that work together inside a Kubernetes cluster. This means you would have a minimum of 5-6 microservices. As your organization grows, you could go on the have 10, then 20, even 50 microservices, at which point a problem arises: the deployment manifests. Handling just one or two is fairly simple, but when it comes to several dozen, updating and adding new manifests can be a real problem. If you have a separate git repository for each microservice, you will likely want to keep each deployment yaml within the repo. If this is a regular organization that follows best practices, you will be required to create pull requests and have them reviewed before you merge to master. This means if you want to do something as simple as change the image pull policy for several microservices, you will have to make the change in each repo, create a pull request, have it reviewed by someone else, and then merge the changes. This is a pretty large number of steps that a Helm template can reduce to just 1. + +Now, let's move on to Chart hooks. + +[Next: Chart Hooks](chart-hooks.md) \ No newline at end of file From d2a11589c5f0ae148a300c6b6a248148d4ab53d5 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Mon, 19 Feb 2024 17:17:11 +0530 Subject: [PATCH 02/13] fluentbit sidecar --- Helm101/helm-templates.md | 49 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 35bcb66c..2627c5f2 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -2,6 +2,55 @@ In even a small-scale organization, you would have at least a couple of applications that work together inside a Kubernetes cluster. This means you would have a minimum of 5-6 microservices. As your organization grows, you could go on the have 10, then 20, even 50 microservices, at which point a problem arises: the deployment manifests. Handling just one or two is fairly simple, but when it comes to several dozen, updating and adding new manifests can be a real problem. If you have a separate git repository for each microservice, you will likely want to keep each deployment yaml within the repo. If this is a regular organization that follows best practices, you will be required to create pull requests and have them reviewed before you merge to master. This means if you want to do something as simple as change the image pull policy for several microservices, you will have to make the change in each repo, create a pull request, have it reviewed by someone else, and then merge the changes. This is a pretty large number of steps that a Helm template can reduce to just 1. +To start, we will need a sample application. We could use the same charts that we used in the previous section, but instead let's go with a new application altogether: nginx. + +This will be our starting point: + +``` +# nginx-deployment.yaml + +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:latest + ports: + - containerPort: 80 +``` + +``` +# nginx-service.yaml + +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app: nginx + ports: + - protocol: TCP + port: 80 + targetPort: 80 + type: ClusterIP + +``` + + Now, let's move on to Chart hooks. [Next: Chart Hooks](chart-hooks.md) \ No newline at end of file From ea1bf7ceef83468cde959c9275844d0d6c75eb42 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Tue, 20 Feb 2024 17:28:21 +0530 Subject: [PATCH 03/13] Helm templates cont. --- Helm101/helm-templates.md | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 2627c5f2..0b85ce25 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -47,9 +47,84 @@ spec: port: 80 targetPort: 80 type: ClusterIP +``` + +The above is a rather basic implementaion of an nginx server with 3 replicas, and allows connections on port 80. For starters, let's create a Helm chart from this nginx application. + +Create a Helm Chart: Run the command helm create nginx-chart to create a new Helm chart named nginx-chart. + +Modify Chart.yaml: Update the Chart.yaml file to include relevant metadata for your chart. + +Modify values.yaml: Add any configurable values that you want to expose to users. In this case, you might want to allow users to specify the number of replicas for the Deployment. + +Create Templates: + +deployment.yaml: Convert the Deployment YAML into a Helm template file, deployment.yaml. Use Helm templating to substitute values from values.yaml. +service.yaml: Convert the Service YAML into a Helm template file, service.yaml. Again, use Helm templating where necessary. +Here's how the directory structure might look: + +nginx-chart/ +├── Chart.yaml +├── templates +│ ├── deployment.yaml +│ └── service.yaml +└── values.yaml + +``` +apiVersion: v2 +name: nginx-chart +description: A Helm chart for deploying Nginx service and deployment +version: 0.1.0 +``` + +``` +replicaCount: 3 +image: + repository: nginx + tag: latest + pullPolicy: IfNotPresent +``` ``` +apiVersion: apps/v1 +kind: Deployment +metadata: + name: {{ include "nginx-chart.fullname" . }} + labels: + app: nginx +spec: + replicas: {{ .Values.replicaCount }} + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" + ports: + - containerPort: 80 +``` + +``` +apiVersion: v1 +kind: Service +metadata: + name: {{ include "nginx-chart.fullname" . }} +spec: + selector: + app: nginx + ports: + - protocol: TCP + port: 80 + targetPort: 80 + type: ClusterIP +``` +With this structure, users can now install your Helm chart, and they'll be able to customize the number of replicas and the Nginx image tag through the values.yaml file. Now, let's move on to Chart hooks. From 0f0579ebe009fbe5f2b520a1856022301a4b071c Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Thu, 22 Feb 2024 11:55:20 +0530 Subject: [PATCH 04/13] Helm templates cont. --- Helm101/helm-templates.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 0b85ce25..4b06c3a7 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -51,9 +51,24 @@ spec: The above is a rather basic implementaion of an nginx server with 3 replicas, and allows connections on port 80. For starters, let's create a Helm chart from this nginx application. -Create a Helm Chart: Run the command helm create nginx-chart to create a new Helm chart named nginx-chart. +For starters, let's create the Helm chart. Go into a folder you plan to run this from and type: -Modify Chart.yaml: Update the Chart.yaml file to include relevant metadata for your chart. +``` +helm create nginx-chart +``` + +This will create a chart with the basic needed files. The directory structure should look like this: + +``` +nginx-chart/ +├── Chart.yaml +├── templates +│ ├── deployment.yaml +│ └── service.yaml +└── values.yaml +``` + +By looking at the above structure, you should be able to see where the deployment and service yamls fit in. You will see that there are sample yamls created here. However, you will also notice that these yamls are go templates which have placeholders instead of hardcoded values. We will be converting our existing yamls into this format. But first, update the Chart.yaml file to include relevant metadata for nginx if you require so. Generally, the default Chart.yaml is fine. Modify values.yaml: Add any configurable values that you want to expose to users. In this case, you might want to allow users to specify the number of replicas for the Deployment. From c825881052684d1282899f1494157dbee1ca274b Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Fri, 23 Feb 2024 12:25:16 +0530 Subject: [PATCH 05/13] Helm template cont --- Helm101/helm-templates.md | 74 +++++++++++++++++++++++++++++++++------ 1 file changed, 64 insertions(+), 10 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 4b06c3a7..fc4d4fd4 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -68,23 +68,77 @@ nginx-chart/ └── values.yaml ``` -By looking at the above structure, you should be able to see where the deployment and service yamls fit in. You will see that there are sample yamls created here. However, you will also notice that these yamls are go templates which have placeholders instead of hardcoded values. We will be converting our existing yamls into this format. But first, update the Chart.yaml file to include relevant metadata for nginx if you require so. Generally, the default Chart.yaml is fine. +By looking at the above structure, you should be able to see where the deployment and service yamls fit in. You will see that there are sample yamls created here. However, you will also notice that these yamls are go templates which have placeholders instead of hardcoded values. We will be converting our existing yamls into this format. But first, update the Chart.yaml file to include relevant metadata for nginx if you require so. Generally, the default Chart.yaml is fine. You can also optionally modify values.yaml. Things such as the number of replicas can be managed here. -Modify values.yaml: Add any configurable values that you want to expose to users. In this case, you might want to allow users to specify the number of replicas for the Deployment. +Next, we get to the templating part. We will have to convert our existing deployment yaml into a Helm template file. This is what the yalm would look like after it is converted: -Create Templates: +``` +# templates/deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: {{ .Release.Name }}-nginx-deployment + labels: + app: nginx +spec: + replicas: {{ .Values.nginx.replicaCount }} + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: "{{ .Values.nginx.image.repository }}:{{ .Values.nginx.image.tag }}" + ports: + - containerPort: {{ .Values.nginx.containerPort }} +``` + +Explanation of changes: + +Naming Convention: In the metadata.name field, I've added {{ .Release.Name }}- to prefix the deployment name. This ensures that each deployment has a unique name when installed via Helm, with .Release.Name representing the release name generated by Helm. + +Replica Count: I replaced the hardcoded replica count 3 with {{ .Values.nginx.replicaCount }}. This allows the user to set the number of replicas in the values.yaml file of the Helm chart. + +Image Tag and Repository: I replaced the hardcoded image name nginx:latest with {{ .Values.nginx.image.repository }}:{{ .Values.nginx.image.tag }}. This allows the user to specify the image repository and tag in the values.yaml file. + +Container Port: Similarly, I replaced the hardcoded container port 80 with {{ .Values.nginx.containerPort }}, allowing the user to specify the container port in the values.yaml file. + +These changes make the Helm template more flexible and configurable, allowing users to customize the deployment according to their requirements using the values.yaml file. + +``` +# templates/service.yaml +apiVersion: v1 +kind: Service +metadata: + name: {{ .Release.Name }}-nginx-service +spec: + selector: + app: nginx + ports: + - protocol: TCP + port: {{ .Values.nginx.servicePort }} + targetPort: {{ .Values.nginx.containerPort }} + type: {{ .Values.nginx.serviceType }} + +``` +Explanation of changes: + +Naming Convention: Similar to the deployment template, I've prefixed the service name with {{ .Release.Name }}- to ensure uniqueness when installed via Helm. + +Service Port: I replaced the hardcoded service port 80 with {{ .Values.nginx.servicePort }}. This allows users to specify the service port in the values.yaml file. + +Target Port: I replaced the hardcoded target port 80 with {{ .Values.nginx.containerPort }}, allowing users to specify the target port in the values.yaml file. This should match the container port defined in the deployment template. + +Service Type: I replaced the hardcoded service type ClusterIP with {{ .Values.nginx.serviceType }}, allowing users to specify the service type in the values.yaml file. This provides flexibility in choosing the appropriate service type based on the environment or requirements. deployment.yaml: Convert the Deployment YAML into a Helm template file, deployment.yaml. Use Helm templating to substitute values from values.yaml. service.yaml: Convert the Service YAML into a Helm template file, service.yaml. Again, use Helm templating where necessary. Here's how the directory structure might look: -nginx-chart/ -├── Chart.yaml -├── templates -│ ├── deployment.yaml -│ └── service.yaml -└── values.yaml - ``` apiVersion: v2 name: nginx-chart From 98abe188b6b598693665bc7f690cd080522f9ff8 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Sun, 25 Feb 2024 12:19:48 +0530 Subject: [PATCH 06/13] Helm templates changes --- Helm101/helm-templates.md | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index fc4d4fd4..43c1dedf 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -97,17 +97,9 @@ spec: - containerPort: {{ .Values.nginx.containerPort }} ``` -Explanation of changes: - -Naming Convention: In the metadata.name field, I've added {{ .Release.Name }}- to prefix the deployment name. This ensures that each deployment has a unique name when installed via Helm, with .Release.Name representing the release name generated by Helm. - -Replica Count: I replaced the hardcoded replica count 3 with {{ .Values.nginx.replicaCount }}. This allows the user to set the number of replicas in the values.yaml file of the Helm chart. - -Image Tag and Repository: I replaced the hardcoded image name nginx:latest with {{ .Values.nginx.image.repository }}:{{ .Values.nginx.image.tag }}. This allows the user to specify the image repository and tag in the values.yaml file. - -Container Port: Similarly, I replaced the hardcoded container port 80 with {{ .Values.nginx.containerPort }}, allowing the user to specify the container port in the values.yaml file. +The first thing to change is the naming convention: In the metadata.name field, {{ .Release.Name }}- has been added to prefix the deployment name. This ensures that each deployment has a unique name when installed via Helm, with .Release.Name representing the release name generated by Helm. The replica count has been replaced with {{ .Values.nginx.replicaCount }}. This allows the user to set the number of replicas in the values.yaml file of the Helm chart. When it comes to the image tag and repository, the hardcoded image name nginx:latest has been replaced with {{ .Values.nginx.image.repository }}:{{ .Values.nginx.image.tag }}. This allows the user to specify the image repository and tag in the values.yaml file. Finally, the container port's hardcoded port 80 has been replaced with {{ .Values.nginx.containerPort }}, allowing the user to specify the container port in the values.yaml file. -These changes make the Helm template more flexible and configurable, allowing users to customize the deployment according to their requirements using the values.yaml file. +These changes make the Helm template more flexible and configurable, allowing you to customize the deployment according to their requirements using the values.yaml file. ``` # templates/service.yaml From f6153e333118c86a509259aa12e2ee0b628153c9 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Wed, 28 Feb 2024 11:30:15 +0530 Subject: [PATCH 07/13] Service template changes --- Helm101/helm-templates.md | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 43c1dedf..ff90fc96 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -99,7 +99,7 @@ spec: The first thing to change is the naming convention: In the metadata.name field, {{ .Release.Name }}- has been added to prefix the deployment name. This ensures that each deployment has a unique name when installed via Helm, with .Release.Name representing the release name generated by Helm. The replica count has been replaced with {{ .Values.nginx.replicaCount }}. This allows the user to set the number of replicas in the values.yaml file of the Helm chart. When it comes to the image tag and repository, the hardcoded image name nginx:latest has been replaced with {{ .Values.nginx.image.repository }}:{{ .Values.nginx.image.tag }}. This allows the user to specify the image repository and tag in the values.yaml file. Finally, the container port's hardcoded port 80 has been replaced with {{ .Values.nginx.containerPort }}, allowing the user to specify the container port in the values.yaml file. -These changes make the Helm template more flexible and configurable, allowing you to customize the deployment according to their requirements using the values.yaml file. +These changes make the Helm template more flexible and configurable, allowing you to customize the deployment according to their requirements using the values.yaml file. Now let's take a look at the service yaml and how it would look after it is converted: ``` # templates/service.yaml @@ -117,15 +117,8 @@ spec: type: {{ .Values.nginx.serviceType }} ``` -Explanation of changes: -Naming Convention: Similar to the deployment template, I've prefixed the service name with {{ .Release.Name }}- to ensure uniqueness when installed via Helm. - -Service Port: I replaced the hardcoded service port 80 with {{ .Values.nginx.servicePort }}. This allows users to specify the service port in the values.yaml file. - -Target Port: I replaced the hardcoded target port 80 with {{ .Values.nginx.containerPort }}, allowing users to specify the target port in the values.yaml file. This should match the container port defined in the deployment template. - -Service Type: I replaced the hardcoded service type ClusterIP with {{ .Values.nginx.serviceType }}, allowing users to specify the service type in the values.yaml file. This provides flexibility in choosing the appropriate service type based on the environment or requirements. +Similar to the deployment template, the service name has been replaced with {{ .Release.Name }}- to ensure uniqueness when installed via Helm. For the service port, the hardcoded service port 80 has been changed to {{ .Values.nginx.servicePort }}. This allows you to specify the service port in the values.yaml file. We also replaced the hardcoded target port 80 with {{ .Values.nginx.containerPort }}, allowing you to specify the target port in the values.yaml file. This should match the container port defined in the deployment template. For the service type we replaced the hardcoded service type ClusterIP with {{ .Values.nginx.serviceType }}, allowing users to specify the service type in the values.yaml file. This provides flexibility in choosing the appropriate service type based on the environment or requirements. deployment.yaml: Convert the Deployment YAML into a Helm template file, deployment.yaml. Use Helm templating to substitute values from values.yaml. service.yaml: Convert the Service YAML into a Helm template file, service.yaml. Again, use Helm templating where necessary. From 383a5be93140dba9ff019675c76f6012ff759abc Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Thu, 29 Feb 2024 17:03:31 +0530 Subject: [PATCH 08/13] overriding values yaml --- Helm101/helm-templates.md | 71 +++++++++++---------------------------- 1 file changed, 19 insertions(+), 52 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index ff90fc96..9e34aa1d 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -70,7 +70,7 @@ nginx-chart/ By looking at the above structure, you should be able to see where the deployment and service yamls fit in. You will see that there are sample yamls created here. However, you will also notice that these yamls are go templates which have placeholders instead of hardcoded values. We will be converting our existing yamls into this format. But first, update the Chart.yaml file to include relevant metadata for nginx if you require so. Generally, the default Chart.yaml is fine. You can also optionally modify values.yaml. Things such as the number of replicas can be managed here. -Next, we get to the templating part. We will have to convert our existing deployment yaml into a Helm template file. This is what the yalm would look like after it is converted: +Next, we get to the templating part. We will have to convert our existing deployment yaml into a Helm template file. This is what the yaml would look like after it is converted: ``` # templates/deployment.yaml @@ -120,66 +120,33 @@ spec: Similar to the deployment template, the service name has been replaced with {{ .Release.Name }}- to ensure uniqueness when installed via Helm. For the service port, the hardcoded service port 80 has been changed to {{ .Values.nginx.servicePort }}. This allows you to specify the service port in the values.yaml file. We also replaced the hardcoded target port 80 with {{ .Values.nginx.containerPort }}, allowing you to specify the target port in the values.yaml file. This should match the container port defined in the deployment template. For the service type we replaced the hardcoded service type ClusterIP with {{ .Values.nginx.serviceType }}, allowing users to specify the service type in the values.yaml file. This provides flexibility in choosing the appropriate service type based on the environment or requirements. -deployment.yaml: Convert the Deployment YAML into a Helm template file, deployment.yaml. Use Helm templating to substitute values from values.yaml. -service.yaml: Convert the Service YAML into a Helm template file, service.yaml. Again, use Helm templating where necessary. -Here's how the directory structure might look: +Now that we have defined both the deployment and the service in a template format, let's take a look at what the overriding values file would look like: ``` -apiVersion: v2 -name: nginx-chart -description: A Helm chart for deploying Nginx service and deployment -version: 0.1.0 +nginx: + replicaCount: 3 + image: + repository: nginx + tag: latest + containerPort: 80 + servicePort: 80 + serviceType: ClusterIP ``` -``` -replicaCount: 3 -image: - repository: nginx - tag: latest - pullPolicy: IfNotPresent -``` +n this values.yaml file: -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: {{ include "nginx-chart.fullname" . }} - labels: - app: nginx -spec: - replicas: {{ .Values.replicaCount }} - selector: - matchLabels: - app: nginx - template: - metadata: - labels: - app: nginx - spec: - containers: - - name: nginx - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" - ports: - - containerPort: 80 -``` +replicaCount: Specifies the number of replicas for the nginx deployment. +image.repository and image.tag: Specify the Docker image repository and tag for the nginx container. +containerPort: Specifies the port on which the nginx container listens. +servicePort: Specifies the port exposed by the nginx service. +serviceType: Specifies the type of Kubernetes service to create for nginx. + +With this structure, users can now install your Helm chart, and they'll be able to customize the number of replicas and the Nginx image tag through the values.yaml file. ``` -apiVersion: v1 -kind: Service -metadata: - name: {{ include "nginx-chart.fullname" . }} -spec: - selector: - app: nginx - ports: - - protocol: TCP - port: 80 - targetPort: 80 - type: ClusterIP +helm install my-nginx-release ./my-nginx-chart --values values.yaml ``` -With this structure, users can now install your Helm chart, and they'll be able to customize the number of replicas and the Nginx image tag through the values.yaml file. - Now, let's move on to Chart hooks. [Next: Chart Hooks](chart-hooks.md) \ No newline at end of file From c235eca8c1cbeddd1482da90192d87f76c6cb493 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Fri, 1 Mar 2024 10:44:38 +0530 Subject: [PATCH 09/13] overriding values yaml --- Helm101/helm-templates.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 9e34aa1d..4e0c0f39 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -133,15 +133,9 @@ nginx: serviceType: ClusterIP ``` -n this values.yaml file: +In this values.yaml file, the replicaCount specifies the number of replicas for the nginx deployment image.repository and image.tag specify the Docker image repository and tag for the nginx container. The containerPort specifies the port on which the nginx container listens and servicePort specifies the port exposed by the nginx service. Finally, the serviceType specifies the type of Kubernetes service to create for nginx. You might want to change this to NodePort or LoadBalancer if you plan to provide external access (or use kubectl port forwarding). -replicaCount: Specifies the number of replicas for the nginx deployment. -image.repository and image.tag: Specify the Docker image repository and tag for the nginx container. -containerPort: Specifies the port on which the nginx container listens. -servicePort: Specifies the port exposed by the nginx service. -serviceType: Specifies the type of Kubernetes service to create for nginx. - -With this structure, users can now install your Helm chart, and they'll be able to customize the number of replicas and the Nginx image tag through the values.yaml file. +With this structure, users can now install your Helm chart, and they'll be able to customize the number of replicas and the Nginx image tag through the values.yaml file. Let's go ahead and do the install using the below command: ``` helm install my-nginx-release ./my-nginx-chart --values values.yaml From e7e7f9c1f89b32897770a6222b957d2c7cbbad7e Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Sun, 3 Mar 2024 11:41:51 +0530 Subject: [PATCH 10/13] Helm templates cont. --- Helm101/helm-templates.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index 4e0c0f39..bf27ee9f 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -141,6 +141,10 @@ With this structure, users can now install your Helm chart, and they'll be able helm install my-nginx-release ./my-nginx-chart --values values.yaml ``` +Make sure you run the above command in the same directory as the values.yaml. This will create a release called "my-nginx-release" based on the chart overriding the values.yaml in your Kubernetes cluster. You should be able to run and test the Nginx server that comes up as a result. However, you will notice that we have gone out of our way to define templates and overriding files for something that a simple yaml file could have accomplished. There is more code now than before. So what is the advantage? + +For starters, you get all the perks that come with using Helm charts. But now you also have a template you can use to generate additional helm releases. For example, if you want to run another nginx server with different arguments (different number of replicas, a different image version, different port, etc...), you can use this template. + Now, let's move on to Chart hooks. [Next: Chart Hooks](chart-hooks.md) \ No newline at end of file From f845994be11bfbb2a76529c7f1497b76563fc186 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Tue, 5 Mar 2024 10:29:50 +0530 Subject: [PATCH 11/13] Helm templates cont --- Helm101/helm-templates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index bf27ee9f..fcc6765b 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -143,7 +143,7 @@ helm install my-nginx-release ./my-nginx-chart --values values.yaml Make sure you run the above command in the same directory as the values.yaml. This will create a release called "my-nginx-release" based on the chart overriding the values.yaml in your Kubernetes cluster. You should be able to run and test the Nginx server that comes up as a result. However, you will notice that we have gone out of our way to define templates and overriding files for something that a simple yaml file could have accomplished. There is more code now than before. So what is the advantage? -For starters, you get all the perks that come with using Helm charts. But now you also have a template you can use to generate additional helm releases. For example, if you want to run another nginx server with different arguments (different number of replicas, a different image version, different port, etc...), you can use this template. +For starters, you get all the perks that come with using Helm charts. But now you also have a template you can use to generate additional helm releases. For example, if you want to run another Nginx server with different arguments (different number of replicas, a different image version, different port, etc...), you can use this template. This is especially true if you are working in an organization that has multiple services that require different Nginx setups. You could even consider a situation where your organization has 10+ microservices where the pods you spin up for each microservice are largely boilerplate. The only things that would likely change are the names of the microservice and the image that would spin up in the container. In a situation like this, you could easily create a values file that has a handful of lines that override the Helm template. Now, let's move on to Chart hooks. From c4b78a7cb17fdf02ab310cf07331eb01f97e21b7 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Wed, 6 Mar 2024 18:23:53 +0530 Subject: [PATCH 12/13] New Relic changes --- Helm101/helm-templates.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index fcc6765b..c0d3100e 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -145,6 +145,27 @@ Make sure you run the above command in the same directory as the values.yaml. Th For starters, you get all the perks that come with using Helm charts. But now you also have a template you can use to generate additional helm releases. For example, if you want to run another Nginx server with different arguments (different number of replicas, a different image version, different port, etc...), you can use this template. This is especially true if you are working in an organization that has multiple services that require different Nginx setups. You could even consider a situation where your organization has 10+ microservices where the pods you spin up for each microservice are largely boilerplate. The only things that would likely change are the names of the microservice and the image that would spin up in the container. In a situation like this, you could easily create a values file that has a handful of lines that override the Helm template. +Let's try this. Create a new values-new.yaml and set the below values: + +``` +nginx: + replicaCount: 2 + image: + repository: nginx + tag: alpine3.18-perl + containerPort: 80 + servicePort: 8080 + serviceType: ClusterIP +``` + +The new yaml has a changed replica count, gets a different image tag, and serves on port 8080 instead of 80. In order to deploy this, you can use the same + +``` +helm install my-nginx-release-alpine ./my-nginx-chart --values values-new.yaml +``` + +The release name and the yaml that gets picked up need to be changed here. + Now, let's move on to Chart hooks. [Next: Chart Hooks](chart-hooks.md) \ No newline at end of file From d18675969a085a5f57df3cefe79d03662f1a1966 Mon Sep 17 00:00:00 2001 From: Phantom-Intruder Date: Thu, 7 Mar 2024 12:18:55 +0530 Subject: [PATCH 13/13] Helm templates cont. --- Helm101/helm-templates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Helm101/helm-templates.md b/Helm101/helm-templates.md index c0d3100e..b2357c98 100644 --- a/Helm101/helm-templates.md +++ b/Helm101/helm-templates.md @@ -164,8 +164,8 @@ The new yaml has a changed replica count, gets a different image tag, and serves helm install my-nginx-release-alpine ./my-nginx-chart --values values-new.yaml ``` -The release name and the yaml that gets picked up need to be changed here. +The release name and the yaml that gets picked up need to be changed here. In this same way, you could create different values.yaml with different overriding properties and end up with an infinite number of nginx servers, each with different values. -Now, let's move on to Chart hooks. +This brings us to the end of the section on the powerful use of Helm templates. Now, let's move on to Chart hooks. [Next: Chart Hooks](chart-hooks.md) \ No newline at end of file