#Debugging Services the running system

1 messages · Page 1 of 1 (latest)

cursive lantern
#

Dear,

I'm trying to change an existing unit test from within in our company to use dagger. But i'm not sure how i can debug the services used in the container.


_, err = client.Container().
        From(fmt.Sprintf("gradle:%s-jdk%s-alpine", t.BuildToolVersion, t.JavaVersion)).
                WithServiceBinding("redis", self.redis.AsService()).
                WithServiceBinding("toxiproxy", self.redisToxiProxy.AsService()).
        //WithMountedCache("/home/gradle/.gradle", client.CacheVolume("measurements"), dagger.ContainerWithMountedCacheOpts{Sharing: dagger.Shared}).
        WithExec(strings.Fields("gradle --build-cache test --no-daemon")).
        Directory("build/test-reports/").
        Export(ctx, "test-results")

It isn't clear out of the documentation that services can contact eachoter so I'm not sure the toxiproxy can be setup to reach redis.
Why trying to setup the tests i seem to miss some basic tooling to check which dockers are running in the dagger engine and to log into the services to verify them.

I.e. is there an equivalent to docker exec -ti container /bin/bash and docker ps or do i need to setup my dagger engine differently so it uses my docker deamon?

Another question: would there be an easy way to setup the same services on the localhost of the machine so developers can run the tests directly to make it easier to debug and develop the application.

calm shuttle
#

It isn't clear out of the documentation that services can contact eachoter so I'm not sure the toxiproxy can be setup to reach redis.

for this to happen you also need to bind toxiproxy to the redis service

#

Why trying to setup the tests i seem to miss some basic tooling to check which dockers are running in the dagger engine and to log into the services to verify them.

unfortunately there's no straightforward way of doing this now. If you're on linux, you can use some nsenter-fu to access your service containers.

cursive lantern
#

At the end i got stuck that the service didn't want to boot fully and i suspect it is stuck because of the health checks. In golang i enabled the logging. But i think dagger is missing some debug logging of the dagger runtime itself. I also tried docker log <dagger-runtime> but no success.
So the service part feels a bit flaky that it sometimes runs fully and other times it gets stuck.

for this to happen you also need to bind toxiproxy to the redis service
I'll try that, if i share the same service will it start once or with every bind?

I had another idea:
Currently most of our test use localhost:<redis-port> to connect to the services. But when using dagger you have to use redis:<redis-port>. As a workaround i set the /etc/hosts on my machine to have a consistent system between local development and the ci dagger run.

But it might be easier if there was a way to expose the ports directly on the docker host when running in dagger.

unfortunately there's no straightforward way of doing this now. If you're on linux, you can use some nsenter-fu to access your service containers.

I'm fortuned enough to be a linux user, sadly i don't have the nsenter-fu skills to do it. I think it might be useful to have some CLI tooling to inspec the containers and be able to enter them.

FYI i like dagger and it is already easier to optimize the application building compared to github actions.

calm shuttle
#

At the end i got stuck that the service didn't want to boot fully and i suspect it is stuck because of the health checks. In golang i enabled the logging. But i think dagger is missing some debug logging of the dagger runtime itself. I also tried docker log <dagger-runtime> but no success.

if you run dagger with dagger run --debug you'll see more information about service healthchecks

#

I'll try that, if i share the same service will it start once or with every bind?

only once since it's the same service instance

#

But when using dagger you have to use redis:<redis-port>. As a workaround i set the /etc/hosts on my machine to have a consistent system between local development and the ci dagger run.

is there a reason why you wouldn't run your tests in Dagger instead of localhost? That way, running tests allways boils down to dagger run tests

#

I'm fortuned enough to be a linux user, sadly i don't have the nsenter-fu skills to do it. I think it might be useful to have some CLI tooling to inspec the containers and be able to enter them.

yep, that's coming https://github.com/dagger/dagger/issues/4463

GitHub
Interactive debugger · Issue #4463 · dagger/dagger

It would be amazing to have a way to add "breakpoints" to the DAG, and interactively inspect the state at the given point (via an interactive shell for example). This has been requested a...

#

FYI i like dagger and it is already easier to optimize the application building compared to github actions.

daggerfire

cursive lantern
#

I'm a bit derailing my own request thread. Is it possible to do something like COPY --link --from=stage1 /file /file? I.e. where link creates this layer that is just a blob instead of a diff layer?
https://docs.docker.com/engine/reference/builder/#copy---link

I use it often to optimize my dockers by installing the common dependencies.

Docker Documentation
Dockerfile reference

Find all the available commands you can use in a Dockerfile and learn how to use them, including COPY, ARG, ENTRYPOINT, and more.

calm shuttle
#

when you do something like container.WithDirectory("/some/path", <some_dir>). Intenrally, that's the same as a COPY --link by default.

cursive lantern
#

is there a reason why you wouldn't run your tests in Dagger instead of localhost? That way, running tests allways boils down to dagger run tests

The reason is that developers want to debug there tests and quickly iterate. Only running a few subtests.

#

Ah cool, that makes it a lot easier.

cursive lantern
#

Today i looked again into the service issue. I use toxi proxy which doesn't have any proxy service started yet so the healthchecks never succeed. I wonder if it would be possible to disable health checks for specifc ports?

cursive lantern
#

A nice feature when binding a service on host to be able to set the localhost ip adress. I.e. it would be easier to bind ports on 172.0.0.2 to avoid port collisions.

calm shuttle