rust-lang / docker-rust

The official Docker images for Rust

About this Repo

This is the Git repo of the Docker official image for rust. See the Docker Hub page for the full readme on how to use this Docker image and for information regarding contributing and issues.

The full readme is generated over in docker-library/docs, specifically in docker-library/docs/rust.

See a change merged here that doesn't show up on the Docker Hub yet? Check the "library/rust" manifest file in the docker-library/official-images repo, especially PRs with the "library/rust" label on that repo. For more information about the official images process, see the docker-library/official-images readme.

Nightly Toolchain

An image tracking the Rust nightly toolchain is available via rustlang/rust:nightly.

docker-rust's Issues

Include rustfmt and clippy components by default

I know this issue has been raised already a couple of times (#16, #36, even by me). But with latest stable 1.31 release and 2018 edition landing, the clippy and rustfmt components are part of stable toolchain (so no versions mess). Maybe they worth to be included into rust image by default as are widely used in comparing to other rustup components?

The current situation with CI is relatively OK:

fmt:rust:
  stage: test
  dependencies: []
  image: rust:1.31
  services: []
  before_script:
    - rustup component add rustfmt
  script:
    - cargo fmt --check

But is trickier when it comes to CLI Docker usage:

docker run --rm -v "$(pwd)":/app -w /app rust:1.31 cargo fmt

error: 'cargo-fmt' is not installed for the toolchain '1.31.0-x86_64-unknown-linux-gnu'
To install, run `rustup component add rustfmt`

Having them baked into the image already will make its usage smoother for almost any project.

Add musl-dev to alpine images

Currently when building something that involves compiling C (bat as an example), at the linking stage the following happens, due to missing /usr/lib/crti.o:

   ...
   Compiling clap v2.33.3
   Compiling chrono v0.4.19
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" ...  "-Wl,-Bdynamic" "-lgcc_s" "-lc"
  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find crti.o: No such file or directory
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

This can be eliminated simply by adding musl-dev after RUN apk add ....

Install gcc-arm-linux-gnueabihf and binutils-arm-linux-gnueabihf for arm builds requiring C packages

Although it isn't the highest priority, building an arm package using C bindings takes several extra minutes because gcc-arm-linux-gnueabihf and binutils-arm-linux-gnueabihfneed to be installed first.

The fix would be to add gcc-arm-linux-gnueabihf and binutils-arm-linux-gnueabihf to the list of installed packages for the image.

Broken image for linux/arm/v7

Hi all,

I discovered a bit of a problem with the linux/arm/v7 version of the Rust image - attempting to build Rust projects with it breaks in various mysterious ways with errors like this:

 > [builder  6/12] RUN cargo install cargo-build-dependencies:                                                                                                                                                                                                                                                                                                                               
#14 0.834     Updating crates.io index                                                                                                                                                                                                                                                                                                                                                       
#14 1.590 warning: spurious network error (2 tries remaining): could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)                                                                                                                                                                        
#14 2.087 warning: spurious network error (1 tries remaining): could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)                                                                                                                                                                        
#14 2.628 error: failed to fetch `https://github.com/rust-lang/crates.io-index`
#14 2.628 
#14 2.628 Caused by:
#14 2.629   could not read directory '/usr/local/cargo/registry/index/github.com-1285ae84e5963aae/.git//refs': Value too large for defined data type; class=Os (2)
------
failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c cargo install cargo-build-dependencies]: exit code: 101

I can't say for certain the cause, but I can say that if you install Rust on linux/arm/v7 using the "standard" sh.rustup.rs script, it is also broken, because of this function:

get_bitness() {
    need_cmd head
    # Architecture detection without dependencies beyond coreutils.
    # ELF files start out "\x7fELF", and the following byte is
    #   0x01 for 32-bit and
    #   0x02 for 64-bit.
    # The printf builtin on some shells like dash only supports octal
    # escape sequences, so we use those.
    local _current_exe_head
    _current_exe_head=$(head -c 5 /proc/self/exe )
    if [ "$_current_exe_head" = "$(printf '\177ELF\001')" ]; then
        echo 32
    elif [ "$_current_exe_head" = "$(printf '\177ELF\002')" ]; then
        echo 64
    else
        err "unknown platform bitness"
    fi
}

This fails to set the bitness to 32bit, instead falling through to "unknown platform bitness" (because no /proc/self/exe), resulting in a broken installation of Rust.

If the Docker image build uses that standard rustup script, that's probably why the image is also broken.

Ubuntu based images

Hi,

The docker-rust is awesome but it would be nice to add ubuntu based images. The main reason is that debian use old version of applications. My example usecase that is based on rust:1 install jupyter in version 4.4. (There is also ubuntu brach to compare).

So to use newer jupyter I needed to create own version of rust based on ubuntu

Provide beta images

It would be nice to have an official repository of up-to-date Rust beta images, to complete the rustup-like trifecta for automated CI runs and the like.

Promote multi-stage builds

In the description from this page https://hub.docker.com/_/rust the Dockerfile looks like this:

FROM rust:1.31
WORKDIR /usr/src/myapp
COPY . .
RUN cargo install --path .
CMD ["myapp"]

But, that creates an image that is 1.8gb. I'd recommend adding another section for using multi-stage Dockerfile build.

FROM rust:1.39 as builder
WORKDIR /usr/src/myapp
COPY . .
RUN cargo install --path .

FROM debian:buster-slim
RUN apt-get update && apt-get install -y libssl-dev
COPY --from=builder /usr/src/myapp /usr/local/bin/myapp
CMD ["myapp"]

This will create an image that only has myapp on the image. Note: Some shared libraries may need to be installed as shown in the installation of the libssl-dev line above.

This creates an image that is less than 200mb

missing cmake

For some packages like grpc-sys requires cmake, and the build fails. It's stretch image, and it's not that easy to have it inside.

error: failed to run custom build command for `grpcio-sys v0.4.4`
process didn't exit successfully: `/usr/src/core/target/release/build/grpcio-sys-297b25e1ee53a7f5/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=grpc_wrap.cc
cargo:rerun-if-changed=grpc
cargo:rerun-if-env-changed=GRPCIO_SYS_USE_PKG_CONFIG
cargo:rerun-if-env-changed=CARGO_CFG_TARGET_OS
running: "cmake" "/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/grpcio-sys-0.4.4/grpc" "-DgRPC_INSTALL=false" "-DgRPC_BUILD_CSHARP_EXT=false" "-DgRPC_BUILD_CODEGEN=false" "-DgRPC_BENCHMARK_PROVIDER=none" "-DCMAKE_INSTALL_PREFIX=/usr/src/core/target/release/build/grpcio-sys-ec7dae99e592018a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Release"

--- stderr
thread 'main' panicked at '
failed to execute command: No such file or directory (os error 2)
is `cmake` not installed?

build script failed, must exit now', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.38/src/lib.rs:813:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

warning: build failed, waiting for other jobs to finish...
error: failed to compile `core v0.1.0 (/usr/src/core)`, intermediate artifacts can be found at `/usr/src/core/target`

Caused by:
  build failed

docker build hangs forever on Cargo install command

I am trying to build a Docker image using Rust official image but it hangs forever on the cargo install command while it works fine when I run cargo install from a terminal.

I have seen a few old issues on this but none of the solutions that were listed then are working.

Anything I can do to solve this?

Output from docker install -t <myapp> . command

Sending build context to Docker daemon 1.73MB
Step 1/5 : FROM rust:1.23.0
---> c694858c0c3c
Step 2/5 : WORKDIR /usr/src/
---> Using cache
---> 7af2b1e4af1f
Step 3/5 : COPY . .
---> Using cache
---> a61f33cd9dd3
Step 4/5 : RUN cargo install
---> Running in c9c573188020
Installing v0.1.0 (file:///usr/src/)
Updating registry https://github.com/rust-lang/crates.io-index

Set default $USER as root

$ docker run -it --rm rust:1.45.0-buster cargo new app
error: Failed to create package `app` at `/app`

Caused by:
  could not determine the current user, please set $USER

To solve this

$ docker run -it --rm -e USER=root rust:1.45.0-buster cargo new app

It's very annoying to have to do this.
Docker user is of course root in normal use, so I want you to set it as the default value.

Ubuntu base images

I'm actually pretty new to the concept of "official" images, but do you know if there's a "generally accepted" practice of base images? The shell code in the debian-generated images is easy enough to copy around, but I'm not sure if there's a practice for what "base images" should be used.

In lieu of that, though, maybe some ubuntu images could be provided as well?

This is sort of a more general question, I'm not really sure at all what idiomatic "official" containers look like

Adding `libudev-dev` to image

Can't compile https://github.com/paritytech/hidapi-rs dependency for Parity Ethereum node without it.

support arm64 architecture

https://github.com/docker-library/official-images/blob/master/library/rust In this file I found that supprot Architectures: amd64, arm32v7, i386. So I want to know this image whether or not support arm64.

Provide Alpine images for ARM

Hey,

I've just ran into a separate issue when trying to set up CI for my little project (rust-lang/cargo#7563).
I wanted to try other alternatives on my Raspberry Pi 4, but I noticed that Alpine-based images are provided only for x64.

Would it be possible to add ARM platforms to the list as well?

Pre-populate cargo cache

Cargo's initial cloning of the registry can take a while (it's 164MB on my machine right now), so it might make sense to run something like

cargo new --quiet foo && cd foo && echo 'libc = "0.2"' >> Cargo.toml && cargo fetch --quiet

at the end of the RUN block, before printing out the versions. (Or in a new RUN block so it creates a new layer.)

Make images workable with /usr/local/cargo bind-mounted to host's directory

As I explained in my answer to a StackOverflow question, currently one has to carefully mount all subdirectories of /usr/local/cargo that Cargo will use as cache during the crate build, to avoid redownloading the crates.io registry and the dependencies with every container run. This is troublesome also because some of these depend on the choice of the VCS that the dependencies use, and basically need trial-and-error to discover them all.

Bind-mounting the entire /usr/local/cargo is not currently possible, because the official images also install the toolchain binaries under it. It would be much more convenient if the binaries would be installed elsewhere where PATH inside the container would find them, and the whole /usr/local/cargo would be treated as a perishable cache directory (what with it being world-writable).

error: override toolchain 'stable' is not installed

Trying to build 3rd party project with rust:1.20-stretch gives this error:

error: override toolchain 'stable' is not installed

info: caused by: the toolchain file at '/build/rust-toolchain' specifies an uninstalled toolchain

Is it possible to ship the stable toolchain with those images?

Include rustfmt

Cannot pull the version after v1.33 with content trust enabled in docker

Below is the difference between v1.33 and v1.34:

$ docker trust inspect rust:1.33
[
    {
        "Name": "rust:1.33",
        "SignedTags": [
            {
                "SignedTag": "1.33",
                "Digest": "ee53576304aa1d5c7ed86b82683c89b716b90efd564fff7ea2c08dc72b808d33",
                "Signers": [
                    "Repo Admin"
                ]
            }
        ],
        "Signers": [],
        "AdministrativeKeys": [
            {
                "Name": "Root",
                "Keys": [
                    {
                        "ID": "395e07cae0e2ea2edf4feeeaacb0487163c82e450db04ee89b0a766c513b1644"
                    }
                ]
            },
            {
                "Name": "Repository",
                "Keys": [
                    {
                        "ID": "08eb187de7ae531eafac4a1ae771fa88fc7a53b0b9b6c01b1b3c553290ce90fd"
                    }
                ]
            }
        ]
    }
]

$ docker trust inspect rust:1.34
[
    {
        "Name": "rust:1.34",
        "SignedTags": [],
        "Signers": [],
        "AdministrativeKeys": [
            {
                "Name": "Root",
                "Keys": [
                    {
                        "ID": "395e07cae0e2ea2edf4feeeaacb0487163c82e450db04ee89b0a766c513b1644"
                    }
                ]
            },
            {
                "Name": "Repository",
                "Keys": [
                    {
                        "ID": "08eb187de7ae531eafac4a1ae771fa88fc7a53b0b9b6c01b1b3c553290ce90fd"
                    }
                ]
            }
        ]
    }
]

The link on description points to previous organization

The link in docker hub's description points to rust-lang-nursery but this repository is placed on rust-lang org now. So it should be replaced to avoid confusing even if it is still redirected.
https://hub.docker.com/_/rust/?tab=description

OpenSSL when cross-compiling for musl

This is a continuation of #11

Rust is no longer able to find the OpenSSL headers as early as July 2019 on the latest tag (1.42.0-buster) despite them being there:

➜ docker run --rm rust:latest head /usr/include/openssl/opensslv.h
/*
 * Copyright 1999-2019 The OpenSSL Project Authors. All Rights Reserved.
 *
 * Licensed under the OpenSSL license (the "License").  You may not use
 * this file except in compliance with the License.  You can obtain a copy
 * in the file LICENSE in the source distribution or at
 * https://www.openssl.org/source/license.html
 */

#ifndef HEADER_OPENSSLV_H

According to this issue trying to get rust to know where all the headers are is a pain point.

Alpine 3.13

A new Alpine version (3.13) has been released. It would be nice to provide packages for it.

Why no caching? All dependencies are re-compiled every time.

I found that upon every run of my docker-compose build, this was by default not caching any of the dependencies, and rebuilding them all from scratch, which would take ~10 minutes per build.

I found this elaborate guide or how to cache dependencies for anyone interested, but it seems like both of the features listed in there: caching the dependencies, and optimizing the image size, should be part of this docker already. They managed to cut the build time by 90%, and build size by 95%.

s390x and ppc64le builds are failing

docker-library/official-images#3273 (comment)

Docker hub image hasn't been updated.

Even though the manifest is bumped to 1.22, the dockerhub repo is stuck at the 1.21 version.

Install elsewhere from /root/.cargo?

I was thinking that if you use these images as a non-root user, then the rustc installation wouldn't be visible?

SSL certificate problem: unable to get local issuer certificate

I'm getting the following error when trying to build docker image:

  Installing myapp v0.1.0 (file:///usr/src/myapp)
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading sqlite v0.23.9
error: failed to compile `myapp v0.1.0 (file:///usr/src/myapp)`, intermediate artifacts can be found at `/usr/src/myapp/target`

Caused by:
  unable to get packages from source

Caused by:
  [60] Peer certificate cannot be authenticated with given CA certificates (SSL certificate problem: unable to get local issuer certificate)
The command '/bin/sh -c cargo install' returned a non-zero code: 101

Here is my dockerfile:

FROM rust:1.24.0

WORKDIR /usr/src/myapp
COPY myapp/ .

RUN cargo install

CMD ["myapp"]

failed to open: /usr/local/cargo/registry/index/github.com-1ecc6299db9ec823/.cargo-index-lock

I want to use official image to bootstrap rust-wasm development environment https://github.com/stereobooster/docker-rust-wasm. But getting this issue

docker run -v "$PWD":/usr/src/myapp -w /usr/src/myapp --rm --interactive --tty --user "$(id -u)":"$(id -g)" stereobooster/rust-wasm
USER=<user name> cargo generate --git https://github.com/rustwasm/wasm-pack-template
cd <project name>
wasm-pack init

  [1/8] Checking crate configuration...
  [2/8] Adding WASM target...
| [3/8] Compiling to WASM...
Compilation of your program failed. stderr:

error: failed to load source for a dependency on `cfg-if`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to open: /usr/local/cargo/registry/index/github.com-1ecc6299db9ec823/.cargo-index-lock

Caused by:
  Permission denied (os error 13)

Am I doing it wrong?

Related rust-lang/cargo#4778

Provide rustfmt by default

It is convenient to have the rustfmt already installed so we avoid getting it every time we build.

If agreed, I can prepare a pull request to include it.

Install kcov for coverage?

I now a point of this image is to be slim, but maybe having kcov will be useful for use in CI/CD systems.

Alpine 3.11

There's a new alpine version, but no rust:1-alpine3.11 image yet :)

Multi-arch builds currently (on 1.26.0) broken

See rust-lang/rust#49462 on why this happens.

Using 1.25 as a workaround on ARM.

Add `lld`

It’s hard to figure out how to add lld, which seems like an important enough tool to include by default.

Windows Support

Are there any plans to get official Windows Server images? Preferably based of microsoft/windowsservercore image?

Figure out the Debian release support story

We currently provide images based off of Debian stable (stretch) and oldstable (jessie). What should the general policy going forward be here? One option is to support whatever stable and oldstable are at the time of release of a Rust version, but we could start more aggressively dropping oldstable.

Docker Hub unfortunately does not have per-image download counts so there isn't really any way to tell if people are still using the jessie images :(

License?

Could there be a LICENSE file added to this repository, so that consumers of this can know what the license is?

Thanks.

Images with default profile

Hey,

I use the official Docker image in a development environment and having an image with the default profile of rustup would be quite handy. So this would mean building images with rustup-init --profile default.

rust 1.28-slim image includes rustc 1.29

As of today (2018-12-17) if you pull rust:1.28-slim you get an image that contains rustc 1.29. We use this in the CI for Gstreamer and Librsvg to test backwards compatibility since most LTS distributions are kinda outdated.

➜  ~ podman pull rust:1.28-slim
Trying to pull docker.io/rust:1.28-slim...Getting image source signatures
Copying blob sha256:802b00ed6f79f48e6a5f44ecbcaf43563d6077aaecb565eee1dfc615c0b18c00
 21.44 MB / 21.44 MB [=====================================================] 44s
Copying blob sha256:bb58e7a6ab879cfb037fad33ae8ec6363295c6ecb86865165dfb5e5e0d27f431
 238.61 MB / 238.61 MB [=================================================] 7m20s
Copying config sha256:0bf92e53f2fb93e6fd5546b982756b0d735ca51c84aa5c275b561c38f77576ee
 4.68 KB / 4.68 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
0bf92e53f2fb93e6fd5546b982756b0d735ca51c84aa5c275b561c38f77576ee
➜  ~ podman run --rm -ti rust:1.28-slim bash
root@80f62216889a:/# rustc --version
rustc 1.29.0 (aa3ca1994 2018-09-11)
root@80f62216889a:/# 

openssl

Please consider adding openssl to your docker images. A ton of rust packages use openssl headers at compile time and I <3 using these from Dockerhub off the shelf to build stuff.

Thanks!

musl image

Would be nice to feature a :musl tag for building musl Rust binaries!

As an example, see https://github.com/mcandre/docker-linux-rust/blob/master/musl.Dockerfile

Base images are HUGE.

It would be awesome to get an alpine (not sure if we are still blocked on musl) version of an image built, as that could drastically reduce base image size (currently around 477MiB compressed). The build pack base image is around 250MiB compressed, whereas alpine base image is about 2MiB compressed. Currently, the build here is nearly doubling the size of the image.

If that is not possible right now, it would be beneficial to strip out as much bloat from the base image as possible. I've only looked over the dockerfiles briefly, and I would have to investigate further to really see what could be stripped out, to find where the bloat may be coming from.

Thoughts?

Please add stable / beta / nightly tags

Currently, there's only images for specific versions, and latest, whatever that means. Having stable, beta and nightly tags would be very useful for Docker-based CI.

Add remaining architectures

Specifically armel, powerpc64le and s390x.

Add dind variants to help running on CI

Many projects depend on other components to run CI pipelines. Would be nice to have a rust + docker dind variant to help with that.

Since dind is based on alpine, most of the work on supporting it would be done already since alpine is already a variant.

I'd be happy to create a PR if the idea is welcome.

Nightly version?

I was trying to dockerize a Rocket app, and wanted to use the official Rust Docker image, but it seems there's no nightly?

Also, I'm new to Docker, so I may be mistaken.

Cargo `install+upgrade` behaviour in 1.48 Docker image?

Hi,

I've just found a strange behaviour in rust:1.48-slim docker image when using cargo install inside Dockerfile with cached cargo dir:

FROM rust:1.48-slim

RUN cargo --version \
    && rustup show \
    && cargo install diesel_cli \
    --branch master --git https://github.com/diesel-rs/diesel \
    --no-default-features --features postgres

....
#14 7.471 cargo 1.48.0 (65cbdd2dc 2020-10-14)
#14 7.477 Default host: x86_64-unknown-linux-gnu
#14 7.478 rustup home:  /usr/local/rustup
#14 7.478 
#14 7.572 1.48.0-x86_64-unknown-linux-gnu (overridden by '/root/rust-toolchain')
#14 7.619 rustc 1.48.0 (7eac88abb 2020-11-16)
#14 7.712     Updating git repository `https://github.com/diesel-rs/diesel`
#14 8.377 error: binary `diesel` already exists in destination
#14 8.379 Add --force to overwrite

This is even though the install+upgrade behaviour of Cargo has been stabilized, and running on my local machine do not yield this error when latest diesel is already installed.

# in localhost

$ cargo --version
cargo 1.48.0 (65cbdd2dc 2020-10-14)

$ rustup show
Default host: x86_64-apple-darwin
....
active toolchain
----------------

1.48.0-x86_64-apple-darwin (overridden by '/Users/chakrit_w/Projects/test-rust-caching/rust-toolchain')
rustc 1.48.0 (7eac88abb 2020-11-16)

$ cargo install diesel_cli \
    --branch master --git https://github.com/diesel-rs/diesel \
    --no-default-features --features postgres

    Updating git repository `https://github.com/diesel-rs/diesel`
     Ignored package `diesel_cli v1.4.0 (https://github.com/diesel-rs/diesel?branch=master#493541dd)` is already installed, use --force to override

Please help investigate this - Thanks!

rust:1.42.0-slim tries to download nightly components

From my GitLab CI log:

 Pulling docker image rust:1.42.0-slim ...
Using docker image sha256:446639396ccf372322506e8d98d1c88aa6f05b2c9e29e6bd593f24cfebd88232 for rust:1.42.0-slim ...

...

 $ rustup component add clippy
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2020-03-20, rust version 1.44.0-nightly (f4c675c47 2020-03-19)
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: installing component 'cargo'
info: installing component 'rust-std'
info: installing component 'rustc'
error: component 'clippy' for target 'x86_64-unknown-linux-gnu' is unavailable for download for channel nightly
Sometimes not all components are available in any given nightly.
ERROR: Job failed: exit code 1

The same happened with rust:latest recently, which is why I switched to rust:1.42.0-slim. I would really appreciate if this could be looked into.

Edition 2018 programs not compiling

When running cargo build | check inside a container based with this image, the crates get downloaded but don't compile. This is the error I get:

    (Omitting big list of crates being downloaded and checked)

    Checking trust-dns-resolver v0.10.0
    Checking actix v0.7.8
    Checking hyper-tls v0.3.1
    Checking reqwest v0.9.5
    Checking actix-net v0.2.4
    Checking sparkpost v0.4.1
    Checking actix-web v0.7.15
    Checking simple-auth-server v0.1.0 (/app)
error: Edition 2018 is unstable and only available for nightly builds of rustc.

error: Could not compile `my-rust-program`.

To learn more, run the command again with --verbose.

cargo build and cargo run is very slow

Environment:
windows 10: docker latest with wsl2
Docker version 19.03.8, build afacb8b
docker-compose version 1.26.0-rc4, build d279b7a8

cargo build and cargo run is very slow. What needs to be done to improve compile time?

1. created Dockerfile

FROM rust:1.31

WORKDIR /work

#RUN cargo install --path .

#CMD ["myapp"]

2. created a folder work

mkdir work

3. created a docker-compose.yml file

version: '3'
services:
  testrust:
    image: rust:latest
    volumes:
      - "./work:/work"
    environment:
      - "USER=vairamsvsjdo"
    working_dir: /work

4. run docker-compose

docker-compose run testrust

4. created a default rust app

root@ca05f88b00c6:/work# cargo init
     Created binary (application) package

5. did cargo run and noticed it took 2.01s to build

root@ca05f88b00c6:/work# cargo run
   Compiling work v0.1.0 (/work)
    Finished dev [unoptimized + debuginfo] target(s) in 2.01s
     Running `target/debug/work`
Hello, world!

6. added 1,2,3 to end of Hello World and did cargo run to notice that it took 2.16s to compile and run

```bash
root@ca05f88b00c6:/work# cargo run
   Compiling work v0.1.0 (/work)
    Finished dev [unoptimized + debuginfo] target(s) in 2.16s
     Running `target/debug/work`
Hello, world 1,2,3!

7. did cargo run again to notice that it ran in 0.10s

```bash
root@ca05f88b00c6:/work# cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/work`
Hello, world 1,2,3!

8. to confirm the performance added ",4" text and noticed that the compile and run took again 2.14s and subsequent run in 0.12s. What needs to be done to improve compile time?

root@ca05f88b00c6:/work# cargo run
   Compiling work v0.1.0 (/work)
    Finished dev [unoptimized + debuginfo] target(s) in 2.14s
     Running `target/debug/work`
Hello, world 1,2,3,4!
root@ca05f88b00c6:/work# cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/work`
Hello, world 1,2,3,4!

Cargo install updating registry forever

I'm having trouble to use rust in docker-rust. When I run sudo docker build -t name . the process runs forever.

    Updating registry `https://github.com/rust-lang/crates.io-index`

Here my Dockerfile

FROM rust:1.23.0

WORKDIR /usr/src/myapp
COPY . .

RUN cargo install

CMD ["myapp"]