search

rust-lang / rustwide

Execute your code on the Rust ecosystem.
Apache License 2.0
180 stars 41 forks source link

Allow Rustwide to run inside a Docker container #8

Closed pietroalbini closed 4 years ago

pietroalbini commented 4 years ago

r? @Mark-Simulacrum

Mark-Simulacrum commented 4 years ago

Okay, I briefly looked through the code and it all seems reasonable for what it's doing (though I won't say that I guarantee it'll work, in particular the temporary file creation for detecting the appropriate docker seems a bit much).

On a more general note, it is pretty unclear to me why we would want to do this. As far as I know, mounting the docker socket inside a docker container is essentially granting root access to the host. Presumably that means we're not using this as a way to further isolate the rustwide-run container(s).

But if that's true, then I am uncertain as to the benefits that putting rustwide (and crater, etc) inside a docker container really gives us. I guess it might make it somewhat easier to deploy, though I'm not entirely certain about that -- especially when viewed in concert with needing to mount the docker socket and such inside the rustwide running container.

However, I also think that we shouldn't let perfect be the enemy of good enough here so if this is helping us in a real way then let's land the code and go from there.

pietroalbini commented 4 years ago

My goal for this is indeed to dockerize Crater. The advantage of shipping Crater in a Docker container is the removal of the need to compile it on the host platform, which after a Rust update takes more than 20 minutes on rust-bots (for example). Having everything as a Docker container will also help standardize our tooling in the future.

though I won't say that I guarantee it'll work, in particular the temporary file creation for detecting the appropriate docker seems a bit much

There is a test that runs a Rustwide build with Rustwide itself in a Docker container, so once CI pass it should be ok. It's not the prettiest solution but I couldn't think of anything better.

Mark-Simulacrum commented 4 years ago

My goal for this is indeed to dockerize Crater. The advantage of shipping Crater in a Docker container is the removal of the need to compile it on the host platform, which after a Rust update takes more than 20 minutes on rust-bots (for example). Having everything as a Docker container will also help standardize our tooling in the future.

I think we should consider moving to generating host-agnostic (for the most part) binaries instead, e.g. by building for the musl x86_64 target, and uploading those to S3 (or maybe even GH releases, or so) from CI for our use. This seems less of a heavy weight solution than Docker for most use cases.

pietroalbini commented 4 years ago

I think for now deploying the Crater agent through Docker is better than the status quo, and it's the same approach we've been starting to use across all the other services we host. We should definitely discuss as a team what we want to do in the future for hosting dynamic applications though, and possibly write guidelines like we did with static websites.