Perform analysis on multistage Dockerfiles

[nishakm]

Describe the Feature
Tern can read a Dockerfile, build and image and analyze the image to provide a report and pin a Dockerfile. However, it cannot do these for multistage Dockerfiles accurately because the intermediate stages get thrown away after a build is complete. Why not enable analysis and pinning for multistage Dockerfiles?

Use Cases
Multistage Dockerfiles are the de-facto build mechanism for golang projects in particular. A Dockerfile will typically use the golang image to build and an alpine image to deploy the built golang binary.

Implementation Changes
A proposed implementation can look like this:

1. Split the Dockerfile by stage, making a single Dockerfile for each stage
2. Build and analyze each stage
3. For reporting, perhaps organize each stage as a different section and indicate that each is a build stage of the next. Pinning a multistage Dockerfile is straightforward.

[ForgetMe17]

Maybe i can work on this issue!

[ForgetMe17]

Hi nisha, here is my plan:
While performing analyze on a single-stage dockerfile, we first build it and analyze the image. For a mutilstage dockerfile it should work similarly.

1. Build
For a two-stage dockerfile, we need to get two images corresponding to two stages in the dockerfile. So in the build part, we can use the following dockerfiles to build the images.
Multistage Dockerfile

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app . 
CMD ["./app"]  

into
Dockerfile1: Stage 1

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

Dockerfile2: Stage 1 + Stage 2

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app . # Copy file from previous stage.
CMD ["./app"]  

I am not spliting into seperate stages since the second stage may need to copy files from the previous stage(Stage 2 has dependcy on Stage 1).
While building Dockerfile2, the engine first builds Stage 1 and then Stage 2, during building Stage 2, files in the Stage 1 are copied to Stage 2. Stage 1 is deleted once Stage 2 is finished.

2.Analyze
After we get the image, we can analyze and lock the dockfile. Here we can use analyze_docker_image(image_obj, redo=False, dfile_lock=False, dfobj=None), but this dfobj should be:
Stage 1

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

Stage 2

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app . # Copy file from previous stage.
CMD ["./app"]  

This is different from build part because each image is built according to each stage. So we can lock each stage by analyzing each image.

[nishakm]

@ForgetMe17 That makes sense to me. All the information collected when analyzing an image built from Dockerfile1 are stored in the Image object. So you can instantiate stage1 = DockerImage(repotag1) for the first image and stage2 = DockerImage(repotag2) for the second image. But some of the reports do not take more than one image (most notably the SPDX tag-value) so, focusing on the default report and Dockerfile lock is enough for this part.