Closed iddm closed 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?
@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.
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?
@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.
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.
Whenever I try to build my project from the drone ci inside this docker image - it says:
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 oflibpq
and so on, however, again, on my desktop machine it compiles successfully. What is the problem?