#Hello, I'm working a dagger integration

1 messages ยท Page 1 of 1 (latest)

placid verge
#

You shouldn't need async and await for the first function. Dagger is lazy with evaluation until you get to a "leaf" node where the chain of functions need to be evaluated to typically return a scalar like a string, or starting up a service, that doesn't return anything and is the "end of the line".

#

In the PythonSDK, you can tell if you have terminal/leaf node that requires async/await by looking at the signature

https://dagger-io.readthedocs.io/en/sdk-python-v0.16.2/client.html#dagger.Container.as_service - lazy, not a leaf node

https://dagger-io.readthedocs.io/en/sdk-python-v0.16.2/client.html#dagger.Service.up - leaf node, note async

Similarly, in the Go SDK, you have to pass context (e.g. ctx).

For example:
https://pkg.go.dev/dagger.io/dagger#Container.AsService - lazy, not a leaf/terminal node in the graph

https://pkg.go.dev/dagger.io/dagger#Service.Up - leaf node, note ctx

https://docs.dagger.io/api/internals/#lazy-evaluation

If you're interested in how Dagger uses GraphQL, this page provides additional information on the Dagger API's internals.

marble sierra
#

Thank you for your feedback. I've updated the code like this:

    @function
    def nginx_container(self) -> dagger.Container:
        """Returns lines that match a pattern in the files of the provided Directory"""
        return dag.container().from_("nginx:latest").with_exposed_port(80)

    @function
    def nginx_service(self) -> dagger.Service:
        """Returns lines that match a pattern in the files of the provided Directory"""
        service = self.nginx_container().as_service(use_entrypoint=True)
        return service

    @function
    async def run_nginx_service(self) -> None:
        """Returns lines that match a pattern in the files of the provided Directory"""
        await self.nginx_service().up(ports=[dagger.PortForward(80, 8085)])

but still have the same issue. My goal is to run multiple services (front, back & DB) for local testing with only one function (simil docker compose) May be I'm using the wrong class

#
curl http://localhost:8085
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
#
curl http://localhost:8085
curl: (7) Failed to connect to localhost port 8085 after 0 ms: Couldn't connect to server
placid verge
#

Going to look more closely. @unkempt ginkgo please look at this too.

#

Without port forwarding, I can get this to work with Go as a first pass

package main

import (
    "context"
    "dagger/gogogo/internal/dagger"
)

type Gogogo struct{}

func (m *Gogogo) NginxContainer() *dagger.Container {
    return dag.Container().From("nginx:latest").WithExposedPort(80)
}
func (m *Gogogo) NginxService() *dagger.Service {
    return m.NginxContainer().AsService() 
}
func (m *Gogogo) RunNginxService(ctx context.Context) error {
    return m.NginxService().Up(ctx)
}
#

Have to see what equiv is for Python with "leaf" function

unkempt ginkgo
#

going to take a look right now

placid verge
unkempt ginkgo
placid verge
#

no. look at API link

wheat oxide
wheat oxide
#

This way you can return a single service type which can forward traffic to multiple dagger services

#

cc @unkempt ginkgo

marble sierra
placid verge
# wheat oxide <@933501536624054272> I think there's no issue here. IIUC op is raising the fact...

I was looking at the base case of just WithExposedPort on the Go SDK @wheat oxide which works fine, while I noticed issues with it in the Python SDK.

But I see what you mean. The idea being that forwarding a container port to a "host" port would be forwarding it to the runtime container at best, and if it were tunneled all the way through, it would be at odds with the security boundary? But since the proxy module connects to the users's machine via a single exposed port, it's easy to handle in this way.

wheat oxide
#

Since that's breaking the module sandboxing

placid verge
# wheat oxide Since that's breaking the module sandboxing

facepalm in the course of this, I had dagger shell running on the side that had brought up nginx...that was serving it

So, sandboxing for the win!

@marble sierra what you want to do is save the up for the command line if you're using modules/functions like most of us are.

marble sierra
#

Thanks every one for the feedback and help. Keep working in the product, that is game changer for the DevOps world!!