#Dagger call stuck on "generating go module" behind corporate proxy

1 messages · Page 1 of 1 (latest)

dawn hollow
#

Hello,

Thanks for all the work you guys are doing on improving dagger behind a corporate proxy. I have been following the issues on Github. From what I understand with the latest v0.11.6, I should be able to build and run a dagger module within my coprorate environment. However, I get the following issue when running dagger -m github.com/shykes/daggerverse/hello@v0.1.2 call hello

It gets stuck on the following

...
32  :     Container.directory(path: "/src"): Directory!
33  :     cache request: copy / /hello
33  :     cache request: copy / /hello DONE [0.0s]
34  :     cache request: oci-layout://dagger/import@sha256:6313b8ab78fd9cc0e46e4311e52f20f41bdf52685a610bd8ee4a30cb14ad2ff8
34  :     cache request: oci-layout://dagger/import@sha256:6313b8ab78fd9cc0e46e4311e52f20f41bdf52685a610bd8ee4a30cb14ad2ff8 DONE [0.0s]
35  :     cache request: [internal] creating dagger metadata
35  :     cache request: [internal] creating dagger metadata DONE [0.0s]
36  :     load cache: creating dagger metadata
36  :     load cache: creating dagger metadata DONE [0.0s]
37  :     load cache: rm /hello/dagger.gen.go
37  :     load cache: rm /hello/dagger.gen.go DONE [0.0s]
38  :     load cache: mkfile /schema.json
38  :     load cache: mkfile /schema.json DONE [0.0s]
39  :     exec /usr/local/bin/codegen --output /src --module-context-path /src/hello --module-name hello --introspection-json-path /schema.json
39  :     [0.2s] | generating go module: hello  <!-- stuck here for both go and python-sdks >

I have set the _DAGGER_ENGINE_SYSTEMENV_GOPROXY env var in the dagger engine container to point to our internal go proxy. However it is still stuck, is there a way to debug further?

Thanks,

mossy helm
#

I am also in interested in this

honest hatch
#

@mossy helm are you having a similar issue?

mossy helm
#

Well not yet. Happy sdk user but have also been monitoring that issue. Our CI inf can’t talk to internet so we are setting up Athens as a go proxy. Haven’t quite got as far as the OP but will soon..

#

Maybe it will just work…

honest hatch
dawn hollow
#

Hi @honest hatch so I have now tested the same comman on an internal VM with internet access. The command above worked and the GOPROXY is working as I can see the go packages installed via our internal package manager. So it seems like it is something else when internet is required through the proxy.

It could potentially be the no_proxy environment variable, where it tries to go to the proxy when contacting our internal registry. Or it’s trying to download something from the internet through our proxy and it doesn’t work.

It is just not very clear since it just hangs.

mossy helm
#

Okay back on this. So I did run the test today and it stuck at the same point as OP. Not sure if it is the same problem, but doesn't look like the goproxy is being respected or used during code gen. I am tailing the logs of my goproxy and see no activity. Also I do get a failure with:
go: github.com/99designs/gqlgen@v0.17.44: Get "https://proxy.golang.org/github.com/99designs/gqlgen/@v/v0.17.44.mod": dial tcp 142.251.46.241:443: i/o timeout`

Which shows the goproxy isn't being used. I am running a custom engine. I am suspecting the codegen is maybe acting differently then a standard go module. I am going to try to set the go proxy as an env variable of the engine and see what happens.

#

Setting goproxy as an env on the engine didn't work. goproxy still seems to be ignored. I did start a separate docker container with go on the same machine, set the go proxy, and confirmed that it hit my go proxy. I see activity and go get worked but can't seem to have codegen use it...

So to summarize. Attempted to set _DAGGER_ENGINE_SYSTEMENV_GOPROXY from the client side and also attempted to set GOPROXY on the container engine, both seem to have codegen fail and the errors indicate that goproxy isn't being respected. I have confirmed GOPROXY is working for a generic docker golang container on same machine as client and engine are running.

#

Oh, and one slight diff from OP and maybe part of their problem is that I am using a local directory dagger module. Their command references a github module, and if they are truly disconnected from internet then it won't be able to download the module.

dawn hollow
#

Just to add I have also tried with a locally installed dagger module with the same result

mossy helm
#

Oh, and to confirm I am also running v0.11.6 of client and engine.

honest hatch
#

@mossy helm have you tried setting _DAGGER_ENGINE_SYSTEMENV_GOPROXY in the engine?

#

the client side shouldn't require any changes

#

@mossy helm @dawn hollow seems like you're both on an airgapped environment?

#

do your engines have no access to internet at all?

mossy helm
#

The engineers do, but the CI env doesn't for me.

mossy helm
#

We have been running the sdk for awhile in that setup, just seeing if we can get modules going.

mossy helm
#

If we could get codegen to use the go proxy I am pretty sure it would work

honest hatch
#

Using the env variable in the engine as I mentioned above should make codegen use the right goproxy

mossy helm
#

Awesome I’ll try and report back

#

Just for clarification you mean hand it an env variable as an argument to my docker run of the engine..

honest hatch
dawn hollow
#

Hi, for me there is access to the internet just via an http proxy

#

Just o clarify the GOPROXY env var is used to download go modules through an internal package registry?

Then does codegeb use the HTTP_PROXY env var to proxy calls to the internet?

Thanks,

mossy helm
#

Btw, setting this env worked and I was able to successfully run a local dagger module. Thanks for the help @honest hatch

dawn hollow
#

@mossy helm could you please share the env vars you are setting for the engine?

dawn hollow
#

I have some extra information now:

Stdout:
generating go module: python-sdk
writing dagger.gen.go
writing go.mod
writing go.sum
creating directory internal
creating directory internal/dagger
writing internal/dagger/dagger.gen.go
creating directory internal/querybuilder
writing internal/querybuilder/marshal.go
writing internal/querybuilder/querybuilder.go
creating directory internal/telemetry
writing internal/telemetry/attrs.go
writing internal/telemetry/batch_processor.go
writing internal/telemetry/init.go
writing internal/telemetry/processor.go
writing internal/telemetry/proxy.go
writing internal/telemetry/span.go
running post-command: go mod tidy
post-command failed: exit status 1
Stderr:
go: github.com/golang/protobuf@v1.5.4: verifying go.mod: github.com/golang/protobuf@v1.5.4/go.mod: Get "https://sum.golang.org/lookup/github.com/golang/protobuf@v1.5.4": tls: failed to verify certificate: x509: certificate signed by unknown authority
Error: exit status 1

I have added our internal ca certificate into the dagger engine container with

FROM registry.dagger.io/engine:v0.11.6
COPY --from=cacert /usr/local/share/ca-certificates/ldnca-rca.crt /etc/ssl/certs/ldnca-rca.pem
COPY engine.toml /etc/dagger/engine.toml

But it seems that it doesn't pick it up when doing /usr/local/bin/codegen --output /src --module-context-path /src --module-name python-sdk --introspection-json-path /schema.json

We use NXRM as our internal package manager and they have support for proxying go sum db. Would it be possible to either:

  1. Use ca-certificates.crt generated by the dagger engine container
  2. Add another environment variable like _DAGGER_ENGINE_SYSTEMENV_GOSUMDB to set proxying the go package validation

Sources: https://help.sonatype.com/en/go-repositories.html#sumdb

mossy helm
#

You need to mount the cert and not copy it in:
docker run --rm -d --name customized-dagger-engine-v6 --privileged --volume /etc/ssl/certs:/usr/local/share/ca-certificates -e _DAGGER_ENGINE_SYSTEMENV_GOPROXY=http://<ip>:3000 hregistry.dagger.io/engine:v0.11.6

Make sure to mount it into the share directory. The dagger engine will run update-cas for you.

mossy helm
dawn hollow
#

Unless they are for different purposes