Docker build leaves intemediate images

user_1174405 0
Viewed 619

I want to build on my own composer:latest image with Docker version 18.06.1-ce, I use this script to do it:

#!/bin/sh

wget -O Dockerfile https://raw.githubusercontent.com/composer/docker/edf4f0abf50da5d967408849434b9053a195b65f/1.7/Dockerfile
wget -O docker-entrypoint.sh https://raw.githubusercontent.com/composer/docker/master/1.7/docker-entrypoint.sh
chmod +x docker-entrypoint.sh
docker build -t mycomposer:latest .

but besides the created image

mycomposer:latest

i end up having around 10 images none:none.

docker image prune

does not solve the issue.

how to build the composer:latest image form the files here composer github without leaving these intermediate images?

I want to do it manually instead of using command FROM because this is the first step of me using Dockerfile as a template and add,delete commands to/from it where I want. But the first step is to get the image build as it is from local Docker file instead of using FROM command. I don't want to use FROM command because it implies using all the commands in Dockerfile and i want just a few of them as a starting point to my custom Dockerfile and some others edited from which I'll be building my own image.

currently I managed to build image using local Dockerfile but there is a lot of unnecessary images none:none

Actual repository

instead of having repository like that: enter image description here

where there is just one image after build. The single image from the picture above comes from the command:

docker pull composer:latest

but this pulls composer image instead of building it from my local Dockerfile, so it does not fill the bill.

But how come there is just single image after the command pull and several ones after doing build from the same Dockerfile as pull takes (I assume) and how to get rid of these none:none images?

composer-php docker build image php
4 Answers

The images are the build cache. They allow docker to dramatically speed up future builds of the same image. Their actual disk usage is near 0 because the layers are shared between the images, the only impact is some json metadata and directories. Once you build another image and untag the previously built image, a prune will remove the unused dangling images.

user_5962850

Docker images are made of layers; each has a piece of the combined ultimate image filesystem. The layers actually make up a kind of tree, where you might have a base Ubuntu layer, with a child that installs a specific Debian package, with a child that adds your application code, and so on. Each of these layers is actually independently usable as an image, but you can't delete a base-layer image so long as there's another image below it that depends on it.

You're running docker image -a, which lists all of the images, even the ones that only exist as base layers. That produces a bunch of "extra" <none> <none> images, which are the base layers. They're harmless, and required, and don't take up any extra resources. In general using the -a option doesn't really tell you anything and I'd just skip it.

user_100081730

My approach is to build an image from Dockerfile:

clone the repo from the github.

git clone https://github.com/composer/docker.git .
cd 1.7 
docker build -t mycomposer:latest .

That's it.

user_55696030

Please refer to https://docs.docker.com/engine/docker-overview/#docker-objects

Each instruction in a Dockerfile creates a layer in the image. When you change the Dockerfile and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization

Hence docker image prune won't remove them. Without those layers, your image won't work.

user_103451750
Related