1
00:00:00,000 --> 00:00:07,700
Hi, Let us understand about

2
00:00:07,700 --> 00:00:15,200
Helm, the package manager for kubernetes, whenever an application needs to be deployed within kubernetes cluster

3
00:00:15,200 --> 00:00:22,333
It involves n number of components and organising those components in the right order for the right dependencies

4
00:00:22,333 --> 00:00:25,399
and deploying the right version into the cluster

5
00:00:25,400 --> 00:00:30,866
After testing, it's going to be a challenging task depending on the size of the application.

6
00:00:30,866 --> 00:00:37,999
And here's where the helm will facilitate to deploy the entire package into the kubernetes cluster.

7
00:00:38,000 --> 00:00:43,100
And it's going to visualize the application as a package where all the dependencies will be packed

8
00:00:43,100 --> 00:00:49,700
together and the entire package can be shared as well as deployed into the kubernetes cluster.

9
00:00:49,700 --> 00:00:57,533
Also, it facilitates to upgrade and roll back the changes by maintaining the versions.

10
00:00:57,533 --> 00:01:04,899
We can visualize helm like APT or yum package managers available within the Linux world, and it

11
00:01:04,900 --> 00:01:08,500
automates the version handling as well as automate the deployment

12
00:01:08,500 --> 00:01:11,400
upgrade and roll back of various versions

13
00:01:11,400 --> 00:01:17,566
And the entire package can be packaged as a file and it can be shared with the team members or with other teams.

14
00:01:17,566 --> 00:01:23,966
The main concept of helm is about templatisiinig the deployment descriptor so that the values that

15
00:01:23,966 --> 00:01:31,966
are going to get changed for different environments can be fed as an input value or as a separate value files.

16
00:01:31,966 --> 00:01:35,432
So the templates can be stored within the repositories and only the

17
00:01:35,433 --> 00:01:40,599
Values that are going to get changed depending on the environment, can be maintained in different files

18
00:01:40,600 --> 00:01:44,766
and the required files can be provided as a input.

19
00:01:44,766 --> 00:01:49,466
So basically, helm can handle the entire lifecycle of the application.

20
00:01:49,466 --> 00:01:52,499
Right, from creating, installing, upgrading, rollback

21
00:01:52,500 --> 00:01:57,600
delete, status maintenance as well as version handling of the applications.

22
00:01:57,600 --> 00:02:03,400
So overall, helm going to provide the following benefits, that is repeatability, reliability, and

23
00:02:03,400 --> 00:02:06,700
it can manage multiple environments with the same templates

24
00:02:06,700 --> 00:02:13,000
And it's going to facilitate easy collaboration as everything will be defined within the files and

25
00:02:13,000 --> 00:02:15,533
no configurations will go out of the file.

26
00:02:15,533 --> 00:02:24,099
So the entire file can be versioned and it can be integrated easily with the CICD environment and it can

27
00:02:24,100 --> 00:02:26,633
handle any complex environment

28
00:02:26,633 --> 00:02:32,133
within the  production world. As a part of this particular course, we will be seeing all the features that

29
00:02:32,133 --> 00:02:33,099
are listed over here.

30
00:02:33,100 --> 00:02:40,200
That is automation of upgrade, roll back, templatizing for different environments as well as involving

31
00:02:40,200 --> 00:02:45,800
helm in different stages, creating our own custom repositories and lot more.

32
00:02:45,800 --> 00:02:48,900
So don't worry about the terminologies that I have used over here.

33
00:02:48,900 --> 00:02:54,033
We are going to have detailed discussion on each and every topic by using a production grade, kubernetes

34
00:02:54,033 --> 00:02:59,766
cluster, and we will be seeing the simple scenario to complex scenario of helm.

