#Long-lived container(s) with dagger

1 messages · Page 1 of 1 (latest)

sterile walrus
#

I want to do this as well, I'm currently working on it but have the same unknowns.

#

what SDK are you using? I'm using Go most likely

brave lagoon
#

I'm using the TypeScript SDK right now.

#

Go SDK too verbose imo.

sterile walrus
#

I just started, I am going to look at the node and python ones now

#

I have a tool in Go already, which I may wish to bake some of this into, so I may still stay with Go

#

I think it ought to be possible to do what you want, with exec, but not sure if you can run and walk away yet, like docker-compose up

#

is there API that would fill the docker-compose down side?

frozen thicket
#

Yes Dagger is designed to make this possible. There are a few features missing for a great experience, but you can get it to work with a few workarounds

#

The main missing feature is host-to-container networking.

#

(also a really fun project 🙂

#

I believe is uses an unofficial patch of the Dagger Engine for host-to-container networking though, so pretty extreme

sterile walrus
#

yeah, just saw that

frozen thicket
#

A less radical workaround, that works with the stable Dagger Engine, is to rely on host-to-container unix socket mounting (which works today), and proxy tcp->unix on the host, and unix->tcp in a container

sterile walrus
#

so better support is on the roadmap it sounds like?

frozen thicket
#

As a describe it in the other discussion:

postgres client on host --> socat on host ----- (unix socket) ---> socat in container --> postgres in container

frozen thicket
sterile walrus
#

it would unlock a use-case for use, would probably want both sync & async modes (i.e. docker run [-d])

#

or I suppose being able to life-cycle containers

frozen thicket
#

Yeah we've discussed that... Worth opening an issue for that sync mode. There are UX subtleties (so far every Dagger user shares the universal expectation that run is supposed to return). But nothing a good bikeshedding session can't fix.

brave lagoon
#

ok, keep me up to date on that development. I think I will use something different for this use-case for now until the hostnetworking is supported but just in case someone stumples upon this, here's a quick n dirty example I wrote that spins up 2 containers and keeps them running (no hostnetworking tho) - apparently one needs to await the exitCode to keep the container alive.

import Client, { connect } from "@dagger.io/dagger";

// initialize Dagger client
connect(
  async (client: Client) => {

    const db = client
      .container()
      .from("postgres")
      .withEnvVariable("POSTGRES_PASSWORD", "mysecretpassword")
      .withExposedPort(5432);

    const webServer = client
      .container()
      .from("node:18")
      .withExec(["node", "-e", "console.log('starting fake webserver'); setTimeout(() => {}, 10000000)"])
      .withExposedPort(8080);

    await Promise.all([db.exitCode(), webServer.exitCode()]);
  },
  { LogOutput: process.stderr }
);
frozen thicket
sterile walrus
#

does that alleviate the need for the CACHE=time.Now() business?

#

my hunch is they are two sides of the same coin

#

sync at the end, cache bust in the middle

frozen thicket
#

they are orthogonal , Sync forces evaluation by the engine, but caching happens normally