$GOPATH/go.mod exists but should not when building docker container, but works if I manually run commands

Question

I'm building a golang:1.14.2 docker container with go-redis from a Dockerfile.

FROM golang:1.14.2

# project setup and install go-redis
RUN mkdir -p /go/delivery && cd /go/delivery && \
    go mod init example.com/delivery && \
    go get github.com/go-redis/redis/v7 

# important to copy to /go/delivery
COPY ./src /go/delivery

RUN ls -la /go/delivery

RUN go install example.com/delivery
ENTRYPOINT ["delivery"]

However, when I try to build the container using docker-compose up --build -d, I get this error: $GOPATH/go.mod exists but should not ERROR: Service 'delivery' failed to build: The command '/bin/sh -c go get github.com/go-redis/redis/v7' returned a non-zero code: 1.

However, I can create a docker container using the image from the dockerfile docker container run -it --rm golang:1.14.2 and then run the exact same commands as in the Dockerfile, and delivery does what I expect it to. ``

Here is deliver.go:

package main

import (
    "fmt"

    "github.com/go-redis/redis/v7"
)

func main() {
    // redis client created here... 

    fmt.Println("inside main...")
}

What am I doing wrong? I looked up this error message and none of the solutions I've seen worked for me.

EDIT: Here is the compose file:

version: '3.4'
services:
  ...
  delivery:
    build: ./delivery
    environment:
      - REDIS_PORT=${REDIS_PORT}
      - REDIS_PASS=${REDIS_PASS}
      - QUEUE_NAME-${QUEUE_NAME}
    volumes: 
      - ./logs:/logs

Anecdotic

It sounds like something is setting GOPATH=/go/delivery and it shouldn't be. It might be a default for that image. – Aikido

you should add the compose file as well, as given what you have said, the issue is probably there, and it's probably because of some directory you're mounting . – Mages

Also running go install example.com/delivery isn't going to use the local sources, it's going to use the sources from the repo published at go install example.com/delivery. To use local sources you want to cd to the project and just run go install, or better yet, go build. – Aikido

If this is for distributing/running the app rather than just building it, I'd scrap it altogether. Go applications are self-contained binaries and do not require the toolchain at runtime. A Docker container for running the program should just be a base container with the compiled binary copied into it. – Aikido

@Aikido would the command to execute the copied binary be something like CMD ["/bin/bash", "<binary_name>"]? – Anecdotic

No, bash would be for running bash scripts. You'd just run the binary. – Aikido

@Aikido every time I would make changes to the source code I would need to rebuild the binary, and then copy it unto the container. I'd like to change the source file and still get a working application – Anecdotic

You want to edit the source and rebuild it inside the container? The typical flow for containers would be to publish a new container for a new version of the application. If you're editing inside the container it defeats most of the purpose of containers; it's not immutable, and it's not scalable. – Aikido

@Aikido no I have a git repo that contains code, including delivery.go that I copy into the go container in the Dockerfile. I would be able to docker-compose up and have new containers whenever I change the source files on my local machine, not in the container – Anecdotic

Then you can just build the binary and compose. If you don't want to run go build && docker-compose up you could write a bash script with that as its only contents, but that's literally all there is to it. The only time a Docker container should contain the Go toolchain is if the container is running as a build agent for CI/CD; a container running a service written in Go should just have the Go binary. – Aikido

How did u solve that? – Clarineclarinet

Answer 1

I have same problem. You need set WORKDIR /go/delivery

Walkyrie

Would appreciate some explanation. Although, it worked. – Plea