#Docker inspect layer size install
#Docker inspect layer size download

Scratch doesn't add a container or operating system and it doesn't have utilities like shell, which might restrict adequacy for certain use cases and make it harder to debug. Now, there's a trade-off between image size and functionality. In other words, scratch doesn't add anything to the image. So we can opt for the minimal base called scratch, which is a special keyword that enables the initiation of a build stage without adding a layer. Notice that the COPY command in the second stage uses a -from flag to refer to the first stage, using an alias that we assigned above.ДЇor this Go application, we're able to package the executable as a standalone binary and eliminate all other dependencies. And we're copying the resulting executable to the second stage, which uses a much smaller base. We've removed everything from the first stage that is not relevant to building the application. In this Dockerfile, we have to build stages, one to build the application and one to create the runtime image. It also initiates what's called a build stage. We said earlier that the FROM instruction sets the base image. So to eliminate unnecessary components from a runtime image, you can use an approach called a multi-stage build. Now what you need at build time and runtime depends, of course, on your application, but in our case, we can reduce our image size significantly. In the case of our sample app, we needed the base image for building the app, but we don't need it for running the app. It's just slightly bigger than golang, which means that most of the bulk is coming from the base. That simply increases the surface area of images that a malicious person or program could potentially abuse. There's no reason to deploy packages or components to production that are not needed at runtime. In actuality, the biggest motivation for reducing the size of an image is to reduce the surface area of attack. So the size of individual layers that change frequently is more important for efficiency than the total size of an image.

#Docker inspect layer size download

Why should we pay attention to the size of our images? Size impacts the first upload or download time of an image, but after that, only layers that have changed are transferred. In order to grant the user additional permissions or ownership, that needs to be done explicitly through instructions in the Dockerfile.

Now, by default, this user will have read access to the container and write permissions to the /temp directory. And we'll do a quick check to verify that the default runtime user is now 1001. And that'll change the user and privileges. To address this, we can simply add a user instruction to our Dockerfile and use an arbitrary number as the ID.

And from a security perspective, we should follow the principle of least privilege. Our application doesn't require root access.

#Docker inspect layer size install

So this means that the default user in the golang image is root, which makes sense for a base image, because you might want to install packages and so on, but it doesn't make as much sense for an application image. A savvy hacker might even be able to exploit a vulnerability in the operating system and gain access to the host. If an attacker gains access to the container, being root makes it easier to explore and identify other services over the network. Now, being root in the container doesn't imply having root privileges on the host VM, but it's still a concern. Let's use the images we created in the previous lesson to check who the default runtime user is. We'll also explore two ways to inspect images. In this lesson, we'll talk about the default runtime user and reducing image size.

Let's cover a few more examples to continue learning about Dockerfile.