1
00:00:02,160 --> 00:00:05,730
Now, the approach of using the automatically generated

2
00:00:05,730 --> 00:00:07,950
environment variables, works.

3
00:00:07,950 --> 00:00:10,510
And of course, just to clarify this,

4
00:00:10,510 --> 00:00:13,079
not just in node js applications,

5
00:00:13,079 --> 00:00:16,470
any programming language supports this concept

6
00:00:16,470 --> 00:00:18,190
of environment variables.

7
00:00:18,190 --> 00:00:20,470
The exact code simply then depends

8
00:00:20,470 --> 00:00:22,760
on the programming language.

9
00:00:22,760 --> 00:00:25,020
But this approach works.

10
00:00:25,020 --> 00:00:28,630
Nonetheless, there is an even more convenient one.

11
00:00:28,630 --> 00:00:31,900
Because Kubernetes clusters by default,

12
00:00:31,900 --> 00:00:34,304
when using a modern version of Kubernetes,

13
00:00:34,304 --> 00:00:38,760
come with a built-in service called, CoreDNS.

14
00:00:38,760 --> 00:00:43,570
Now CoreDNS, as the name suggests, is a domain name service,

15
00:00:43,570 --> 00:00:47,440
which in the end helps with creating domain names.

16
00:00:47,440 --> 00:00:52,340
And here I'm talking about cluster internal domain names

17
00:00:52,340 --> 00:00:55,110
which means, not domains you could enter

18
00:00:55,110 --> 00:00:57,850
into the browser, because they will not be registered

19
00:00:57,850 --> 00:01:00,380
with global domain name services.

20
00:01:00,380 --> 00:01:05,250
But instead, domains which are known inside of your cluster.

21
00:01:05,250 --> 00:01:09,130
So just like IP addresses, known inside of your cluster,

22
00:01:09,130 --> 00:01:13,060
there will be domain names, known inside of your cluster.

23
00:01:13,060 --> 00:01:16,440
And this CoreDNS thing,

24
00:01:16,440 --> 00:01:20,840
this service which is installed in your cluster,

25
00:01:20,840 --> 00:01:24,500
automatically creates domain names

26
00:01:24,500 --> 00:01:27,460
which are available and known inside of the cluster,

27
00:01:27,460 --> 00:01:30,790
for all your services.

28
00:01:30,790 --> 00:01:33,140
And now that only leaves one question.

29
00:01:33,140 --> 00:01:35,990
Which domain names would that be?

30
00:01:35,990 --> 00:01:38,520
For that I'll go to the signup request

31
00:01:38,520 --> 00:01:41,870
and replace this environment variable here,

32
00:01:41,870 --> 00:01:44,620
where we still use auth address.

33
00:01:44,620 --> 00:01:48,533
And I wanna pass in a different value for auth address,

34
00:01:49,450 --> 00:01:52,500
not the IP address, which we used before,

35
00:01:52,500 --> 00:01:56,390
but instead this automatically generated domain.

36
00:01:56,390 --> 00:01:59,830
Which again, will only be known inside of your cluster.

37
00:01:59,830 --> 00:02:03,070
But since the code in this user's app js file runs

38
00:02:03,070 --> 00:02:05,813
inside of the cluster, that will not be a problem.

39
00:02:07,700 --> 00:02:10,330
And here the pattern is very simple.

40
00:02:10,330 --> 00:02:12,460
It's your service name.

41
00:02:12,460 --> 00:02:16,310
So if you wanna send a request to the auth-service,

42
00:02:16,310 --> 00:02:19,610
which in my case has a name of, auth-service,

43
00:02:19,610 --> 00:02:23,230
you can simply use auth-service here,

44
00:02:23,230 --> 00:02:26,850
as a domain to send your request to.

45
00:02:26,850 --> 00:02:30,110
And that's of course very similar to Docker compose.

46
00:02:30,110 --> 00:02:33,390
There we could also use our service name,

47
00:02:33,390 --> 00:02:34,930
a service and Docker compose

48
00:02:34,930 --> 00:02:36,940
was a slightly different concept.

49
00:02:36,940 --> 00:02:38,500
In the end it's a container.

50
00:02:38,500 --> 00:02:42,140
But we could use that name to send our requests to.

51
00:02:42,140 --> 00:02:45,200
In the Kubernetes world, now again, it's very similar,

52
00:02:45,200 --> 00:02:47,900
We just use our service name.

53
00:02:47,900 --> 00:02:50,830
Now actually, it's not just your service name,

54
00:02:50,830 --> 00:02:54,830
instead it's your service name, then a dot

55
00:02:54,830 --> 00:02:58,103
and then the namespace this service is part of.

56
00:02:59,350 --> 00:03:02,535
Namespaces are a concept which we haven't talked about yet.

57
00:03:02,535 --> 00:03:05,890
In the end it is a concept which allows you to assign

58
00:03:05,890 --> 00:03:08,320
services and deployments and so on,

59
00:03:08,320 --> 00:03:12,220
to different namespaces within one of the same cluster,

60
00:03:12,220 --> 00:03:14,960
to, for example assign them to different teams

61
00:03:14,960 --> 00:03:17,510
or projects or whatever.

62
00:03:17,510 --> 00:03:20,260
So simply a way of differentiating and grouping

63
00:03:20,260 --> 00:03:22,590
your resources, you could say.

64
00:03:22,590 --> 00:03:24,930
And you can see which namespaces you've got

65
00:03:24,930 --> 00:03:27,920
by running Q control, get namespaces.

66
00:03:28,850 --> 00:03:32,065
And here on mini cube, we got a couple of namespaces

67
00:03:32,065 --> 00:03:35,740
and it's the default namespace to which our services

68
00:03:35,740 --> 00:03:37,590
and deployments are assigned.

69
00:03:37,590 --> 00:03:40,910
If we don't tell Kubernetes to do it in another way,

70
00:03:40,910 --> 00:03:42,300
which we're not doing here

71
00:03:42,300 --> 00:03:46,050
because we don't need this slightly advanced feature here.

72
00:03:46,050 --> 00:03:48,849
So therefore, we need to add dot default here.

73
00:03:48,849 --> 00:03:53,470
So, service name, dot and then namespace name.

74
00:03:53,470 --> 00:03:56,300
And if you don't assign it to a different namespace,

75
00:03:56,300 --> 00:03:58,267
it's the default namespace.

76
00:03:59,150 --> 00:04:01,713
And this is then the address which can be used inside

77
00:04:01,713 --> 00:04:05,480
of the code running in your cluster to send requests

78
00:04:05,480 --> 00:04:07,883
to our services of that cluster.

79
00:04:08,810 --> 00:04:12,560
So, with that, we don't need to change anything

80
00:04:12,560 --> 00:04:13,570
about any code.

81
00:04:13,570 --> 00:04:15,346
I just changed the value for the

82
00:04:15,346 --> 00:04:17,970
auth address environment variable.

83
00:04:17,970 --> 00:04:19,800
And hence, we just need to apply

84
00:04:19,800 --> 00:04:24,800
this updated, users, dash, deployment, dot yaml file.

85
00:04:25,080 --> 00:04:27,648
And now we still should be able to send requests

86
00:04:27,648 --> 00:04:30,150
to slash login.

87
00:04:30,150 --> 00:04:34,040
Because there nothing changed on the login route.

88
00:04:34,040 --> 00:04:39,000
I'm still using the auto generated environment variable.

89
00:04:39,000 --> 00:04:42,165
But we should also be able to send requests to slash signup,

90
00:04:42,165 --> 00:04:45,800
where I use my own environment variable,

91
00:04:45,800 --> 00:04:50,420
which now receives this automatically generated domain name

92
00:04:50,420 --> 00:04:51,690
as a value.

93
00:04:51,690 --> 00:04:56,440
So if you try sending a request to signup, this also works.

94
00:04:56,440 --> 00:04:58,020
We're not getting an error here.

95
00:04:58,020 --> 00:05:02,450
And it works because this is automatically generated

96
00:05:02,450 --> 00:05:06,850
by Kubernetes and this built-in CoreDNS feature.

97
00:05:06,850 --> 00:05:10,570
And therefore, it's super easy to send requests

98
00:05:10,570 --> 00:05:12,310
to other services.

99
00:05:12,310 --> 00:05:15,740
Because we get these auto-generated domains

100
00:05:15,740 --> 00:05:19,383
which we can use in our code to send requests around.