1
00:00:00,690 --> 00:00:06,110
Let's take a minute to understand how exactly Gottleib works from an architecture point of view.

2
00:00:07,930 --> 00:00:13,510
Not the first thing that you need is the Gittel observer, not the little observer offers you the interface,

3
00:00:13,810 --> 00:00:21,430
allows you to create repositories and manage everything which is related to your project.

4
00:00:21,790 --> 00:00:24,760
And everything that you do will be saved in a database.

5
00:00:25,570 --> 00:00:29,040
And this is the main job of the observer.

6
00:00:29,580 --> 00:00:36,390
Now, as soon as you create a pipeline, that pipeline will be managed by digital observer as well,

7
00:00:37,000 --> 00:00:41,150
but it will be delegated to a so-called getler runner.

8
00:00:42,040 --> 00:00:43,230
So what, Gottleib?

9
00:00:43,570 --> 00:00:49,450
So what Digital Observer will do is we'll say to Getler Brunner, this is what you need to do next.

10
00:00:49,960 --> 00:00:55,960
Download this image, execute the following steps, and eventually, if there are any artifacts, make

11
00:00:55,960 --> 00:00:57,010
sure that you save them.

12
00:00:58,130 --> 00:00:58,790
And that's about it.

13
00:00:58,820 --> 00:01:06,170
So what the observer does, it doesn't do the heavy lifting of actually running the steps, but it manages

14
00:01:06,170 --> 00:01:07,130
the entire process.

15
00:01:07,130 --> 00:01:12,950
It makes sure that a runner is picking up this job, that output from the runner is somewhere stored

16
00:01:12,950 --> 00:01:14,570
and saved and so on.

17
00:01:15,320 --> 00:01:21,770
And that allows for a very scalable architecture because at a minimum, you'll have to gittel observer

18
00:01:21,800 --> 00:01:27,280
and at least one Gillibrand, because without a runner, you will not be able to run any pipelines.

19
00:01:28,340 --> 00:01:35,270
But in case your necessities are much higher, you can add as many get labor as needed.

20
00:01:35,690 --> 00:01:41,900
So you can see it's easily scalable and it can happen at some of your power plants have really special

21
00:01:41,900 --> 00:01:47,720
needs or that maybe use the pipelines only during the day, but not so much during the night or the

22
00:01:47,750 --> 00:01:48,590
other way around.

23
00:01:48,740 --> 00:01:52,310
So we can easily scale up and scale down the runners.

24
00:01:52,310 --> 00:01:59,600
So the retexture that Giddyap has in this case is very flexible and it is definitely aligned to how

25
00:01:59,600 --> 00:02:02,360
modern continuous integration, service work.

26
00:02:06,320 --> 00:02:14,060
So if we look at the first job, build a car, this has been executed by a Getler Brunner and you will

27
00:02:14,060 --> 00:02:20,240
see here that by default, ticketless Brunner is using an image, a docker image, Ruby inversion,

28
00:02:20,240 --> 00:02:21,190
that five.

29
00:02:22,370 --> 00:02:26,300
And of course, this is using this image and then it's starting.

30
00:02:26,300 --> 00:02:31,400
The runner in the first step is cloning the repository that we have.

31
00:02:33,090 --> 00:02:34,080
You will see it here.

32
00:02:35,680 --> 00:02:42,430
And then it's starting to execute the steps it has found in the script, and the last step is once the

33
00:02:42,430 --> 00:02:48,700
artifacts have been generated to upload those artifacts and says they're uploading artifacts to coordinator,

34
00:02:49,030 --> 00:02:54,310
the coordinator is, in this case, the server itself, because it coordinates everything.

35
00:02:55,120 --> 00:02:57,880
And then digital observer knows about these artifacts.

36
00:02:58,120 --> 00:02:59,410
And then the job succeeded.

37
00:02:59,810 --> 00:03:05,170
And after the job was successful, this runner is stopping this task.

38
00:03:05,170 --> 00:03:11,800
So as soon as this has finished, the image is being destroyed and nobody else will ever have access

39
00:03:11,800 --> 00:03:12,100
to it.

40
00:03:12,430 --> 00:03:17,200
And the only thing that is being saved are this logs, which you can then later inspect and understand

41
00:03:17,200 --> 00:03:17,860
what has happened.

42
00:03:18,280 --> 00:03:22,510
And of course, the job artifacts, which you can download and inspect.

43
00:03:24,550 --> 00:03:28,780
Since I talk about runners, let's have a look on how the runners are currently configured.

44
00:03:29,230 --> 00:03:32,970
So if you go to your project settings, see ICD.

45
00:03:36,920 --> 00:03:44,310
Would be able to find a setting regarding runners, and currently the project is running on schedule

46
00:03:44,310 --> 00:03:49,080
runners, and they are actually at this moment, eight available shared runners.

47
00:03:49,710 --> 00:03:56,030
Notice said runners are provided by Guillebeau itself and are available for everybody using guillebeau

48
00:03:56,040 --> 00:03:56,490
dot com.

49
00:03:57,150 --> 00:04:03,150
So you can see here just runners, but you can have the possibility of specifying your own runners as

50
00:04:03,150 --> 00:04:04,740
well if you need more power.

51
00:04:04,750 --> 00:04:08,550
So you can still use clap dotcom, but have your own runners.

52
00:04:08,820 --> 00:04:16,380
And for instance, maybe you are doing some very intensive GPU work in your tasks and shed runners are

53
00:04:16,380 --> 00:04:21,240
maybe two too small for what you need and maybe would like to have your own runner, which has some

54
00:04:21,240 --> 00:04:25,260
characteristics which are specially designed for the kind of jobs you are running.

55
00:04:25,530 --> 00:04:31,290
And then you can define such specific runners and even say this kind of job, this project needs to

56
00:04:31,290 --> 00:04:37,560
run on these runners so that one runner is only used for something and the other runners can be available

57
00:04:37,560 --> 00:04:38,940
for other projects and stuff like that.

58
00:04:39,210 --> 00:04:42,090
So it's really flexible on what you can do on these runners.

59
00:04:43,370 --> 00:04:48,950
So this is a very short overview of the Gottleib architecture and what exactly happens once a pipeline

60
00:04:48,950 --> 00:04:49,760
has been started.

61
00:04:50,240 --> 00:04:54,080
How is the code being executed and how everything fits together?

62
00:04:54,470 --> 00:05:01,280
And hopefully any terminology you will find while using get left dot com will be now a bit much clearer.

63
00:05:01,280 --> 00:05:05,870
And you will understand, at least at this level, what is going on.