WEBVTT 00:00:01.440 --> 00:00:05.980 In this demo, we're going to add Dockle to a continuous integration pipeline. 00:00:05.980 --> 00:00:07.350 To be more specific, 00:00:07.350 --> 00:00:09.330 we're going to add it in the pipeline of the 00:00:09.330 --> 00:00:11.710 project we saw in the previous demo. 00:00:11.710 --> 00:00:16.140 We're going to automatically scan a container image, we're 00:00:16.140 --> 00:00:19.080 going to verify the exit code in the pipeline, 00:00:19.080 --> 00:00:22.720 and we're going to configure the scan results. 00:00:22.720 --> 00:00:28.070 In our tools‑image repository, I'm going to open the pipeline definition file, 00:00:28.070 --> 00:00:31.350 which is called .gitlab‑ci.yml. 00:00:31.350 --> 00:00:34.780 I'm going to open it using my favorite editor, 00:00:34.780 --> 00:00:38.350 which is Emacs, but of course it can be something else. 00:00:39.940 --> 00:00:43.140 So this is the pipeline definition file of the pipeline 00:00:43.140 --> 00:00:45.250 we saw in action in the previous demo. 00:00:45.840 --> 00:00:48.960 Yes, where the test stage in my instance failed. 00:00:49.940 --> 00:00:52.870 What we're going to do right now is add a new stage, 00:00:52.880 --> 00:00:53.700 the lint stage, 00:00:53.700 --> 00:00:57.460 where we're going to perform a dockle lint over our container image. 00:00:58.240 --> 00:01:01.750 We're going to add a lint stage right after the build stage. 00:01:02.540 --> 00:01:06.440 If you're not entirely familiar with the GitLab syntax for pipelines, 00:01:06.600 --> 00:01:07.360 don't worry. 00:01:07.940 --> 00:01:11.140 We're talking here about the concepts, and the pipeline syntax, 00:01:11.140 --> 00:01:13.510 to be honest, is fairly similar for say, 00:01:13.510 --> 00:01:18.260 for instance, Azure or AWS or other continuous integration environments. 00:01:19.040 --> 00:01:23.030 Let's create a lint stage with the name lint, 00:01:23.030 --> 00:01:26.810 and it's going to use the Docker image that we used 00:01:26.820 --> 00:01:28.550 in one of the previous demos. 00:01:28.550 --> 00:01:31.670 And I'm going to specify the name, goodwithtech/dockle, 00:01:31.670 --> 00:01:35.690 and I'm going to specify the version number because I 00:01:35.690 --> 00:01:37.750 want the test to be deterministic. 00:01:38.240 --> 00:01:40.610 I'm also going to define the entry point. 00:01:40.620 --> 00:01:41.860 Why is that? 00:01:42.240 --> 00:01:46.800 Well, I want to execute my own commands when the container spins up, 00:01:46.800 --> 00:01:50.860 and these commands can be defined in the script key. 00:01:51.540 --> 00:01:55.130 So in the script key, I'm going to execute the Dockle executable. 00:01:55.130 --> 00:01:56.650 But wait a minute. 00:01:57.140 --> 00:02:00.130 Didn't we see in the previous demo that the image needed 00:02:00.140 --> 00:02:03.890 access to the /var/run/docker.sock binding? 00:02:03.890 --> 00:02:08.949 What if we don't want to do that because of, say, security reasons? 00:02:09.539 --> 00:02:12.850 Is there a different way to execute the Dockle container 00:02:12.860 --> 00:02:16.120 and still lint local container images? 00:02:16.120 --> 00:02:17.760 Why yes, there is. 00:02:18.240 --> 00:02:20.500 You can scan image files. 00:02:20.600 --> 00:02:24.590 So what we can do is save the Docker image to a file 00:02:24.600 --> 00:02:26.660 and let Dockle scan that file. 00:02:27.340 --> 00:02:29.780 Let's create a new variable called IMAGE_TAR, 00:02:29.780 --> 00:02:33.160 and that will contain the file name of the Docker image. 00:02:34.140 --> 00:02:39.140 And then within the build step, we're going to execute the docker save command, 00:02:39.140 --> 00:02:42.880 and we're going to save the freshly created Docker 00:02:42.880 --> 00:02:46.250 image to a file called IMAGE_TAR. 00:02:47.040 --> 00:02:50.120 As we want to use the IMAGE_TAR file in the next stage, 00:02:50.120 --> 00:02:51.190 in the lint stage, 00:02:51.190 --> 00:02:56.010 we have to instruct the lint stage to not clone a fresh repository, 00:02:56.010 --> 00:02:59.060 but use the repository from the previous stage. 00:02:59.640 --> 00:03:04.260 So we're going to add a variable, and for GitLab this is called GIT_STRATEGY, 00:03:04.260 --> 00:03:07.300 and we're going to instruct it to not override the 00:03:07.300 --> 00:03:09.820 repository from the previous stage. 00:03:09.820 --> 00:03:14.950 And now we can use Dockle without mounting /var/run/docker.sock. 00:03:15.640 --> 00:03:19.250 We just need to specify the ‑‑input parameter with the 00:03:19.250 --> 00:03:21.760 name of the file called IMAGE_TAR. 00:03:22.840 --> 00:03:23.860 That's all there is to it. 00:03:24.240 --> 00:03:26.270 Let's save this file, 00:03:26.270 --> 00:03:33.760 and in our console let's add this file .gitlab‑ci.yml to the Git repository. 00:03:34.840 --> 00:03:40.560 Let's commit it with a nice commit message, say feat: add dockle linting step. 00:03:42.240 --> 00:03:47.140 And now let's push our results upstream to our GitLab server, 00:03:47.140 --> 00:03:52.130 and let's switch to the GitLab server web interface. 00:03:52.130 --> 00:03:55.610 It automatically detected the changes in the pipeline 00:03:55.610 --> 00:03:58.040 configuration and started running the pipeline. 00:03:58.290 --> 00:04:02.150 If you now click on the running pipeline, we can see all the details. 00:04:03.640 --> 00:04:06.060 The build stage was successful, as expected. 00:04:06.060 --> 00:04:10.510 It's now running the lint stage, and that stage succeeded, 00:04:10.510 --> 00:04:13.540 even though there were issues with the Docker image. 00:04:13.540 --> 00:04:19.600 Let's click on the lint stage to see the details of Dockle. 00:04:19.600 --> 00:04:22.500 And here you can see that Dockle actually found some issues. 00:04:22.500 --> 00:04:26.560 There's even a fatal issue, but still the pipeline succeeded. 00:04:26.940 --> 00:04:27.860 So what happened? 00:04:28.540 --> 00:04:29.460 Well by default, 00:04:29.470 --> 00:04:34.980 the exit code of Dockle signifies whether the test itself was run successfully, 00:04:35.100 --> 00:04:38.180 and the test itself ran successfully; however, 00:04:38.180 --> 00:04:40.210 the results were different. 00:04:40.210 --> 00:04:41.910 In the next clip, 00:04:41.910 --> 00:04:44.970 we're going to see how we can modify the pipeline in order 00:04:44.970 --> 00:04:47.550 that it fails when it actually finds issues.