goibm-cloudopenwhisk

How to run a Go function with redis package on OpenWhisk?


I am having some troubles to run a golang package on OpenWhisk (IBM Cloud Functions).

I ran the following on my local computer and it works without any problems (go run sample.go):

package main


import (
    "fmt"
    "encoding/json"
    "github.com/go-redis/redis"
)


func main() {

    var redisClient *redis.Client = redis.NewClient(&redis.Options{
        Addr: "...",
        Password: "...",
        DB: 0,
    })

    redisClient.Set("foo", "bar", 0)

    defer redisClient.Close()

    msg := map[string]string{"msg": ("Done !")}
    res, _ := json.Marshal(msg)
    fmt.Println(string(res))

}

But i didn't find any way to make it working on OpenWhisk. I ran the following:

GOOS=linux GOARCH=amd64 go build -o exec sample.go

zip exec.zip exec

bx wsk action update myfunction --native exec.zip

bx wsk action invoke myfunction -r
bx wsk activation logs --last --strip

"error": "The action did not return a dictionary."

"2018-02-21T01:21:05.962244788Z stdout: [Errno 2] No such file or directory: '/action/exec'"

The problem is related to the github.com/go-redis/redis package, when i remove it and its code then the function is running well. I met the same problem with the mgo package (MongoDB)...

I am new in Golang so it may be obvious, but for now i am stuck :/


Solution

  • The binary in the zip file is dynamically linked against shared libraries not available on the platform.

    Using file and ldd confirms this:

    $ file exec 
    exec: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped 
    $ ldd exec
    /lib64/ld-linux-x86-64.so.2 (0x7f3f63f10000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3f63f10000)
    libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3f63f10000)
    

    Build a static binary or build a dynamically linked binary inside the Docker image used by the platform (openwhisk/dockerskeleton).

    The file not found error is misleading but reported by bash when executing files with this issue.