Add support for building functions with the OpenFaaS function Builder API.

[welteki]

Description

Add a package builder to support building function using the Function Builder API

The README was updated to include a full example for building functions with a more detailed explanation for each step.

Motivation and context

Support building OpenFaaS functions from go code using the SDK.

How has this been tested

Modified the go example from the function builder examples to use the go-sdk for E2E testing.

var (
	image        string
	handler      string
	lang         string
	functionName string
	platformsStr string
	buildArgsStr string
)

func main() {
	flag.StringVar(&image, "image", "", "Docker image name to build")
	flag.StringVar(&handler, "handler", "", "Directory with handler for function, e.g. handler.js")
	flag.StringVar(&lang, "lang", "", "Language or template to use, e.g. node17")
	flag.StringVar(&functionName, "name", "", "Name of the function")
	flag.StringVar(&platformsStr, "platforms", "linux/amd64", "Comma separated list of target platforms for multi-arch image builds.")
	flag.StringVar(&buildArgsStr, "build-args", "", "Additional build arguments for the docker build in the form of key1=value1,key2=value2")
	flag.Parse()

	platforms := strings.Split(platformsStr, ",")
	buildArgs := parseBuildArgs(buildArgsStr)

	// Get the HMAC secret used for payload authentication with the builder API.
	payloadSecret, err := os.ReadFile("payload.txt")
	if err != nil {
		log.Fatal(err)
	}
	payloadSecret = bytes.TrimSpace(payloadSecret)

	// Initialize a new builder client.
	builderURL, _ := url.Parse("http://127.0.0.1:8081")
	b := builder.NewFunctionBuilder(builderURL, http.DefaultClient, builder.WithHmacAuth(string(payloadSecret)))

	// Create the function build context using the provided function handler and language template.
	buildContext, err := builder.CreateBuildContext(functionName, handler, lang, []string{})
	if err != nil {
		log.Fatalf("failed to create build context: %s", err)
	}

	// Create a temporary file for the build tar.
	tarFile, err := os.CreateTemp(os.TempDir(), "build-context-*.tar")
	if err != nil {
		log.Fatalf("failed to temporary file: %s", err)
	}
	tarFile.Close()

	tarPath := tarFile.Name()
	defer os.Remove(tarPath)

	// Configuration for the build.
	// Set the image name plus optional build arguments and target platforms for multi-arch images.
	buildConfig := builder.BuildConfig{
		Image:     image,
		Platforms: platforms,
		BuildArgs: buildArgs,
	}

	// Prepare a tar archive that contains the build config and build context.
	// By default the faas-cli shrinkwraps functions in the `build` folder in the current working directory.
	// MakeTar takes the path to the build context as the second argument.
	if err := builder.MakeTar(tarPath, buildContext, &buildConfig); err != nil {
		log.Fatal(err)
	}

	// Invoke the function builder with the tar archive containing the build config and context
	// to build and push the function image.
	result, err := b.Build(tarPath)
	if err != nil {
		log.Fatal(err)
	}

	// Print build logs
	for _, logMsg := range result.Log {
		fmt.Printf("%s\n", logMsg)
	}
}

[alexellis]

Just a thought b.Build is really more like b.Publish since an image is always pushed/published.

Do you have a multi-arch example too with platforms?

[alexellis]

Do we perhaps want to include the BuildConfig struct and a method to write it out?

I can see that much more than just a build API call is being done via the build() function, it's not obvious from reading that from the function name.

I think the tar step and writing the config could be made more visible to the user. The goal isn't to make this more abstract, but to make it quick to integrate with using the SDK and Go.

[welteki]

I can see that much more than just a build API call is being done via the build() function, it's not obvious from reading that from the function name.

I think the tar step and writing the config could be made more visible to the user. The goal isn't to make this more abstract, but to make it quick to integrate with using the SDK and Go.

I designed this by taking a look at how we would use this SDK functionality in the faas-cli. We allow users to switch between two builders there. The local builder using docker and the remote builder using the OpenFaaS Builder API.

Both ways of building take the same argument: a build context, image name, platforms, build args, etc. Based on this config they build (and push) the function container image.

The fact that in the case of the Remote Build the build context and config are combined in a tar that needs to be send to the builder API is an implementation detail that does not need to be exposed to the caller.

However a do agree that we can take a different approach and have the SDK expose the functions that are now abstracted by the Build method.

It would by up the the users of the SDK to use these function to build a similar abstraction if needed.

Just a thought b.Build is really more like b.Publish since an image is always pushed/published.

My thought around this, building on my previous arguments is that I took a similar approach to the docker buildx command. There is a single build command and you can set the --push flag to publish. In case of the Remote builder implementation the push config parameter would always be true.

Do you have a multi-arch example too with platforms?

That is not in the REAMDE yet but I will add an example of how to specify target architectures.

[welteki]

The PR has been updated with the requested changes.

• The builder package provides a set of functions and structs quickly integrate with the builder API without abstracting all preparation steps.
• The config file is written to the tar archive directly instead of adding it in the provided context path first to ensure context directory is not modified.

[alexellis]

This is much closer to what I had in mind.

Do you have sample arguments I can run to try it out with the tester program?

[alexellis]

I think I'd like to change the approach to shrinkwrap before we move this forward.

[welteki]

I think I'd like to change the approach to shrinkwrap before we move this forward.

The ShrinkWrap helper function has been removed an replaced with CreateBuildContext to programmatically create a Docker build context by providing the function handler and template.

[alexellis]

Approved

[alexellis]

OK that looks good 👍 let's get it written up quickly on the blog and the vendoring back to the CLI can come later on.

[alexellis]

https://github.com/openfaas/go-sdk/releases/tag/v0.2.14