Dockerfile with Go plugins

Question

I have a Dockerfile which creates an image for our project. Setting up everything properly, but I'm looking for the best way I can build my container image, because we have more plugins which determine the behaviour of our project.

So the case, there is the main binary and there is ~10 plugin and I can use 1 or more for my Go binary. Currently these plugins mostly in the same repository as the main project, but in the future there will be other plugins in different repositories.

I'm looking for the best way to have Docker image building mechanism where I can have these plugins.

What I have right now:

FROM golang:alpine AS builder

RUN apk update && apk add --no-cache build-base

# Create appuser.
RUN adduser -D -g '' project-user

WORKDIR $GOPATH/src/bitbucket.org/company/project
COPY . .

RUN GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o /go/bin/project

# Minimal version of image
FROM scratch

COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder /go/bin/project /go/bin/project

USER project-user
EXPOSE 7676

ENTRYPOINT ["/go/bin/project"]

This doesn't have the plugins, so it won't start properly because the binary requires at least one plugin, but there is the plugins flag waits for plugins like plugin.so or plugin1.so;plugin2.so;...

As I told you there is multiple plugins, and right now we have RPM builders and these builds the binary and all plugins separately, and we do yum install project plugin1 plugin2 and in the config file (because the flags could read from config as well) we add the plugins.

We want to change to Kubernetes so this is why I'm looking for this solution in Dockerfile.

Answer 1

So first of all i see some problems with your Dockerfile, i can only address those since i don't fully understand your 'plugins' issues.

1. It's a bad idea to copy /etc/passwd like that, you could get away with this approach but you would have to copy all relevant files for users and groups, cp /etc/{passwd,shadow,group,gshadow} for example, and then be sure to fix permissions. You are safer just creating the user only in the final image, you're not even using it in the builder, and the context size is negligible if that is what you're aiming for by running the adduser in the builder.

2. If your go program calls C code then you will need to base your final image on something other than scratch because it does not have the required libraries. You need a base image with some variant of libc, the most light weight is musl and you get that with the alpine images. If your go program does not call any C code then you can use the CGO_ENABLED=0 flag during go build and then your built binary program won't depend on anything, thus you can use the scratch or busybox base images. You can find more info on cgo here.