Creating official docker image for Rust


#1

Hey. I’ve created Docker image for Rust, as there is no official one, and unofficial ones were kinda clumsy for my taste. I’m willing to try and push it to docker official image library (still need to add some description/docs to do so).

I wonder whether community would be interested in this?

Here’s link to dockerhub and github. Feel free to help me improve this images by making suggestions here or on github. Any help appreciated.

And let me know what you all think about this. Thanks.


#2

You mentioned existing unofficial ones; what’s are the differences between this one and the others?


#3

I couldn’t find existing one that would be:

  • up to date
  • with minimal container size
  • properly tagged (versions/channels)

#4

I was very into docker for a while, I’ve since lost interest, because it didn’t work particularly well for me in practice. However, at the time I spent some time thinking about how to make a good Rust docker image (though I never did ;)).

Here are some thoughts:

It would be very nice to have deep integration with Cargo. Cargo is after all the expected standard choice for Rust projects. My thinking was to use the ONBUILD instruction to set up so that you get a perfectly working, efficient Cargo setup with a one-line Dockerfile. Off the top of my head, this would look something like:

ONBUILD ADD Cargo.{toml,lock} .
ONBUILD RUN mkdir src && touch src/lib.rs && cargo build --release --lib # build dependencies
ONBUILD ADD . .
ONBUILD RUN cargo build --release
CMD cargo run --release

Or something like this. It’s super convoluted but it’ll cache all dependencies separately and only recompile them if the Cargo.{lock,toml} files have changed. I’m not sure if there’s a more intelligent way of compiling only dependencies with Cargo, it looks like there’s an open issue for it. https://github.com/rust-lang/cargo/issues/1891

Obviously someone actually using the docker image wouldn’t actually have to see this or set up this mess themselves.

EDIT: ONBUILD docs: https://docs.docker.com/engine/reference/builder/#onbuild


#5

Could we make them official by moving to https://github.com/rust-lang or directly to rust repository? That would make it more official and improve visibility.


#6

My thinking was to use the ONBUILD instruction to set up so that you get a perfectly working, efficient Cargo setup with a one-line Dockerfile.

Great input, thanks. Setting an ONBUILD version of images is next on my todo list now. Doing this should be easy enough since i can just inherit everything from existing images and add ONBUILD instruction set on top. After that I’ll need to test it with couple of existing Rust projects, since on my experience you sometimes have an unexpected issues with the way union filesystem operates. I’ll keep updating this post with details.


#7

Could we make them official by moving to https://github.com/rust-lang or directly to rust repository? That would make it more official and improve visibility.

I agree it’s a good idea to move it to https://github.com/rust-lang. Who can i talk to fork my repo there? I’m ok with maintaining it.


#8

Should DEBIAN_FRONTEND environment variable set before apt-get install and why adding $RUST_HOME to PATH, if you use cargo install you should add $HOME/.cargo/bin to PATH instead of $RUST_HOME.

Perhaps $CARGO_HOME environment variable is more important to Rust, for reducing duplicate download the same crates, you’d better make $CARGO_HOME a volume to let user mount an existing directory


#9

Should DEBIAN_FRONTEND environment variable set before apt-get install

Valid point, thanks. Updated images.

why adding $RUST_HOME to PATH, if you use cargo install you should add $HOME/.cargo/bin to PATH instead of $RUST_HOME.

That’s also right, i was thinking package install script puts binaries in current directory for some reason. Removed.

Perhaps $CARGO_HOME environment variable is more important to Rust, for reducing duplicate download the same crates, you’d better make $CARGO_HOME a volume to let user mount an existing directory

Hm, not sure whether this should be solved in base images, onbuild images or left for the user entirely (e.g. docker-compose.yml). I’ll keep this idea in mind and try it out.

Thanks for the input!


#10

I’ve removed rust_home environment variable and added onbuild images, but decided to left volume mounting for the end user, as all of the images in official docker library do it this way.

Some work still needs to be done on onbuild images (i didn’t tested them properly yet).


#11

Hi, happy to see a promising image.
What do you think about the possibility to run more cargo (ex. with cargo-watch for different rust versions) from the same project/volume?
I suppose that it will require a different management of the target directory.


#12

Thanks for the interest.

As far as we talk about official images, I’m pointed out earlier that I leaving out setup related to actual development environment (e.g. volume mounting) to the end user. Cargo-watch and similar tools should be handled in “derived” Dockerfile, as there are widely different development environments for different usecases. That said, I’ll probably create the rust-dev dockerfile later with everything ready to start development on a fairly simple rust project, but this image can claim to have an “official” status, as it will not be generic enough.


#13

Congrats everyone with Rust 1.6!

I’ve updated the Dockerfiles for corresponding versions. Due to the way Rust distribution works, it was quite easy.


#14

What are the plans to make the image official?
It’s a very pratical way to play around with Rust.


#15

Independently, I created my own rust Dockerfiles at https://github.com/psftw/docker-rust and would love to see someone who’s close with the rust release process take on the task of polishing up some Dockerfiles and getting them in to the Official Repositories Program. It’s a serious commitment, and I’m happy to help review/test and get it through the initial proposal, but I can’t take on ownership for the long haul. Also, while I’m here dropping in, much :heart: @ Rust and it’s amazing community!


#16

Awesome to see you’ve been able to keep the images up to date @Scorpil ! Even 1.11 is available :slight_smile:

I would love to have official images as well. Makes it more trustworthy. I like having images in combination with partly because it makes setup easier, but also because Drone CI makes use of Docker images to run builds and tests.


#17

Regarding duplicate downloads, I’m just trying to do automated builds of a Rust program. And so duplicate downloads really slow down builds indeeded. I’ve found that vendoring packages works quite well. /cc @Scorpil

You end up with 0 downloads. At the only cost of having one more folder in your project.

There is some more information about how to do this on crates.io:
http://doc.crates.io/source-replacement.html#directory-sources

Let me know if you have any questions, I’m happy to help when possible :slight_smile:


#18

Here’s a small update on this ‘project’ of mine.

I’ve stopped using dockerhub automated builds because it was not flexible enough. Now I’m generating dockerfiles and building/pushing images with custom python script, so it’s much easier to manage (it was a quite annoying before, since there are now 14 versions supported + onbuilds, and you need readme and automated builds configuration for all of them). Finally similar tags all lead to the same image (e.g. stable, 1, 1.15 and 1.15.1 => sha256:d2d839421d). Saves us some time and bandwith.

Next on my todo is to add alpine images, use rustup as an installation method and optimize size of the images a bit by removing unnecessary stuff like documentation. I’m not sure whether it would be useful to publish report that shows current rustc version of each image (e.g. rustc 1.17.0-beta.1 (408d49e60 2017-03-14)), so I’m giving it low priority for now.

As always, feedback and suggestions are appreciated.


#19

Do you know if it’s also possible when using cargo-vendor and docker to not have to rebuild everything every time?


#20

Yes, you can use some sort of caching of compiled code. For instance, if you use Gitlab to build your Docker images: https://docs.gitlab.com/ce/ci/yaml/#cache