git-init and creds-init images are too big

[imjasonh]

git-init and creds-init images are both based on gcr.io/cloud-builders/gcloud:latest, which includes every optional gcloud component, and clocks in at ~2 GB. This makes builds slow, and ko apply -L -f config/ slow because the image is always rebuilt and pushed into the daemon (google/go-containerregistry#205)

git-init probably only needs git, and creds-init probably only needs ssh-keygen, so base images that include those packages (or a single base image that includes both) would help a lot.

[imjasonh]

As a test, I created a minimal Dockerfile:

FROM launcher.gcr.io/google/ubuntu16_04
  
RUN apt-get -y update && \
    apt-get -y install keychain git

I pushed this to gcr.io/my-project/init-base and updated .ko.yaml so that the images are based on this image. git-init is now 112.3 MB, down from 947.3 MB. tests/git-ssh/ passes against the cluster running these smaller images, so I think everything's working.

The question is, how we keep this base image up-to-date, ideally building it as part of the release, or even building it at the beginning of ko apply -f config/ -- I'm not sure the best place to hook this into the current release workflow. @mattmoor thoughts?

[nader-ziada]

All the tests ran successfully with a base image based on alpine. The init-base image using alpine is only 23.2 MB vs 112.3 MB for image using ubuntu

FROM alpine:latest
RUN apk add --update git openssh-client

To help with running the builds faster on a smaller image, I have the following proposal

Proposal

1. Maintain this init-base image separately from the release process to allow for updates based on its base image (FROM entry) to be published as needed.
2. Use automated builds linked to the Dockerfile to publish the init-base image on a publicly available repo, for example gcr.io/knative-build/init-base-image
3. As long as the .ko.yaml is pulling latest, it would pick it the latest image irrespective of when it was updated, and we can use tags in case we need to make sure some release is using a specific version of the image.
4. Since this is only one Dockerfile, we probably don’t need to have this in a separate repo similar to cloud-sdk-docker or cloud-builders, but this is also an option.

@mattmoor @imjasonh thoughts?

[imjasonh]

That seems totally reasonable to me. I don't have a strong preference about alpine, we can always change it later if we decide we want to.