emk / rust-musl-builder

Docker images for compiling static Rust binaries using musl-libc and musl-gcc, with static versions of useful C libraries. Supports openssl and diesel crates.
Apache License 2.0
1.54k stars 193 forks source link

No toolchain installed when running from within the container #35

Closed iddm closed 6 years ago

iddm commented 6 years ago

Whenever I try to build my project from the drone ci inside this docker image - it says:

error: no default toolchain configured

The project compiles fine on my desktop machine with the alias proposed in the README but if I try to create my own image based on this one I have this error. Then I add the toolchains and the project build can be started but it does not compile because of libpq and so on, however, again, on my desktop machine it compiles successfully. What is the problem?

emk commented 6 years ago

Hmm, I'm not sure what's going on here.

You can check ./test-image for several working examples of how to use this container. This might help?

tyranron commented 6 years ago

@vityafx @emk the problem seems to be that Drone CI uses another user inside the container. By default it's set to rust and Rust toolchain is completely installed to the home directory of that user, so eveb using root you'll have that no default toolchain configured error. I had pifalls with this too.

@emk the possible solution is to install the whole toolchain under the root user when building image, and only then, at final layers, use USER rust. So the toolchain under `/usr/local/ will be available for any user.

emk commented 6 years ago

Is Drone CI actually trying override the default user inside the container?

That seems like a very awkward design for a CI system. The whole advantage of containers is that you get almost complete control over what happens inside them, and any deployment or CI systems treat the container as an opaque box. The rust-musl-builder container is intended to work under many different build and CI systems. Once I start changing the container internals to work around specific CI systems, then I'd have to know about how each of those systems work, and I might need to produce many customized images. This would defeat the whole purpose of using Docker.

This container was intended to be used as the supplied rust user, with sudo enabled if you need to install more packages. Is it possible to just use a sudo invocation to run code as user rust with a login shell?

tyranron commented 6 years ago

@emk I can't say for Drone CI as I've never used it. But I fall into some troubles with files permissions when have used your Docker image in my workflow (its on GitLab CI mainly) as I use other images too under root user.
For example, I run cargo fetch on earlier step within official rust Docker image and then use your image for cargo build, and it complains about files permissions in Cargo home directory.

As for me, it's more convenient to use root everywhere for such oneshot Docker images. But your effort to not use root by default is understandable.
Fortunately, both cases may be satisfied.
If you put Rust toolchain under /usr/local/ you will make it available for any user (and root too), which is handy. And this won't break anything, as you still may use rust user by default.

emk commented 6 years ago

Personally, I wouldn't recommend running things as root in Docker containers, just on general principles. Even inside a container, root is surprisingly powerful and may be able to break out of the container into the host OS easier than other user accounts.

rust-musl-builder does provide root access using sudo, in case you need to fix permissions or run apt install when building containers. But you also have the option of disabling sudo once everything is set up correctly.

However, for fixing source code permission problems, I recommend using the approach from the examples/using-diesel directory:

# Add our source code.
ADD . ./

# Fix permissions on source code.
RUN sudo chown -R rust:rust /home/rust

As for why I don't install the Rust toolchain globally, as root, well, that's mostly because I definitely want to use rustup to handle the trickier bits of toolchain selection and configuration, and rustup doesn't have any documentation about running as root.