Build go binary without container image

[nalbury-handy]

Type of question

Are you asking about community best practices, how to implement a specific feature, or about general context and help around the operator-sdk?

Implementation Question

Question

What did you do?
Ran operator-sdk build --help

What did you expect to see?
A way to build just the go binary

What did you see instead? Under which circumstances?
Only ways to build the binary and then build a container image with that binary

Environment

• operator-sdk version:

operator-sdk version: "v0.15.1", commit: "e35ec7b722ba095e6438f63fafb9e7326870b486", go version: "go1.13.6 darwin/amd64"

• Kubernetes version information:

  insert output of kubectl version here

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:02:58Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:

Additional context
We have recently removed Docker from our clusters, and are using our own buildkit implementation. This unfortunately means that non of the operator-sdk's build options will work for us. I see this issue, a closed MR to skip image builds via a command line flag, and an issue with lifecycle/frozen about using a Makefile to allow this to be more customizable, all of which leads me believe this isn't a feature that's coming soon.

Is there an easy place to see in the src and/or docs how I can mimic the go build cmd/flags being used by operator-sdk build? Happy to build it ourselves, but would love to avoid using trial and error to get it right.

Thanks!
Love the SDK overall, just trying to deploy our first operator :-)

[Joibel]

I was just about to raise an issue for this. We have a similar problem, and would like to build using kaniko, so just want the things built and a Dockerfile to feed that.
I have a patch for this, so will do the pull request once I've read the rules.

[mhrivnak]

operator-sdk build is a fairly thin wrapper that basically does go build ... and podman|docker|buildah build .... It's reasonable that some build systems either won't want to or won't be able to make operator-sdk itself available at build time, and that's fine.

It might help to make it more clear in the operator-sdk build help text what it's doing, and perhaps even have a "dry run" option or similar that outputs the exact commands it would have run. That would enable the user to directly run the various build commands, which can also be helpful during troubleshooting and certain development tasks.

[camilamacedo86]

Hi @nalbury-handy,

Is there an easy place to see in the src and/or docs how I can mimic the go build cmd/flags being used by operator-sdk build? Happy to build it ourselves, but would love to avoid using trial and error to get it right.

The command operator-sdk build will scaffold the files and build the docker image. Also, as you checked it has some options/flags which can be seen by the --help and or doc and its implementation here.

I assume that you are building a Go operator, so you can check the files scaffolded in the Memcached Go as an example.

The structure required/scaffolded in the build dir is:

.
├── Dockerfile
└── bin
    ├── entrypoint
    └── user_setup

See the Dockerfile:

FROM registry.access.redhat.com/ubi8/ubi-minimal:latest

ENV OPERATOR=/usr/local/bin/memcached-operator \
    USER_UID=1001 \
    USER_NAME=memcached-operator

# install operator binary
COPY build/_output/bin/memcached-operator ${OPERATOR}

COPY build/bin /usr/local/bin
RUN  /usr/local/bin/user_setup

ENTRYPOINT ["/usr/local/bin/entrypoint"]

USER ${USER_UID}

Note that it has the ENTRYPOINT ["/usr/local/bin/entrypoint"] is implemented in the bin/ and will be copied for the image. It will exec/start the operator:

#!/bin/sh -e

exec ${OPERATOR} $@

Also, we have the user_setup which will be copied as well:

#!/bin/sh
set -x

# ensure $HOME exists and is accessible by group 0 (we don't know what the runtime UID will be)
mkdir -p ${HOME}
chown ${USER_UID}:0 ${HOME}
chmod ug+rwx ${HOME}

# no need for this script to remain in the image after running
rm $0

It will create the dir and give the required permissions to allow exec the operator with dynamic UIDs which is required for OCP.

So, besides the scaffolded files, it will create the image such as docker build -f build/Dockerfile . which is used to deploy and run the operator in the cluster. In this way, you are able to customize it by a Makefile and do the same in another way. See: #1964

Hi @mhrivnak,

It might help to make it more clear in the operator-sdk build help text what it's doing, and perhaps even have a "dry run" option or similar that outputs the exact commands it would have run. That would enable the user to directly run the various build commands, which can also be helpful during troubleshooting and certain development tasks.

Please, feel free to contribute with a PR with any idea that you may have for improvements over it. However, as described in this issue the goal is to provide a Makefile, see #1655, to allow users to customize it easily which will be achieved by the integration with Kubebuilder. The reason for that is because we are looking for changes in the design to bring more flexibility to our users.

So, in the same way, I think we should not keep open any issue to tracking a requirement as `a "dry run" option or similar that outputs the exact commands for now at least as the same way that others RFE regards this area was closed. Let's see if it will be required after the integration get done. But again, please feel free to raise any idea/suggestion that you might have for it by doing a PR against master.

Hi, @nalbury-handy and @mhrivnak,
I am closing this one. However, please let us know if has anything reason for it still open.

[nalbury-handy]

Thanks! this is what I ended up coming up with and it seems to work for our purposes. Read the source code for the build cmd to find the go build ... args. Posting it incase anyone else wants to customize the container image a bit.

FROM golang:1.13-stretch as deps
WORKDIR /src/

COPY ./go.mod /src/go.mod
COPY ./go.sum /src/go.sum

RUN go mod download

# Build stage
FROM deps as build

COPY ./ /src/

RUN env GOOS=linux CGO_ENABLED=0 \
  go build -o ./build/bin/autoscaling-operator \
  -gcflags="all=-trimpath=$(dirname $PWD)" \
  -asmflags="all=-trimpath=$(dirname $PWD)" \
  ./cmd/manager

# Run stage
FROM scratch as run

COPY --from=build /src/build/bin/autoscaling-operator /usr/local/bin/autoscaling-operator

ENTRYPOINT ["/usr/local/bin/autoscaling-operator"]