I have a working build that I am trying to dockerise. This is my dockerfile, I added the "pwd" and "ls -l" to see if the build is copied correctly and it is. However when I try to run "docker run " I get the error "No such file or directory. Please let me know what I might be doing wrong. Appreciate your help.
Dockerfile
FROM <base image>
WORKDIR /app
RUN echo 'List all files'
RUN pwd
RUN ls -l
COPY src/mysolution-linux-amd64 /app/
RUN ls -l
ENTRYPOINT ["/app/mysolution-linux-amd64"]
I have tried ENTRYPOINT with both "./mysolution-linux-amd64" and "/app/mysolution-linux-amd64" but both fail when I run.
Output during Docker build
Sending build context to Docker daemon 1.014GB
Step 1/8 : FROM <base image>
---> 3ed27f7c19ce
Step 2/8 : WORKDIR /app
---> Running in 1b273ccccd22
Removing intermediate container 1b273ccccd22
---> 92560bbb67eb
Step 3/8 : RUN echo 'List all files'
---> Running in faddc1b6adfd
List all files
Removing intermediate container faddc1b6adfd
---> b7b2f657012e
Step 4/8 : RUN pwd
---> Running in 8354a5a476ac
/app
Removing intermediate container 8354a5a476ac
---> 204a625b730b
Step 5/8 : RUN ls -l
---> Running in 0d45cf1339d9
total 0
Removing intermediate container 0d45cf1339d9
---> 6df6451aef44
Step 6/8 : COPY src/mysolution-linux-amd64 /app/
---> 44ac2f066340
Step 7/8 : RUN ls -l
---> Running in d17ec6b0c7af
total 11460
-rwxrwxr-x 1 root root 11734780 Nov 26 04:25 mysolution-linux-amd64
Removing intermediate container d17ec6b0c7af
---> 56a879ef9440
Step 8/8 : ENTRYPOINT ["/app/mysolution-linux-amd64"]
---> Running in 33bea73f14dc
Removing intermediate container 33bea73f14dc
---> ef794fe310bc
Successfully built ef794fe310bc
Successfully tagged newtech/mysolution:latest
I am trying to package gotty into a Docker container but found a weird behavior.
$ tree
.
├── Dockerfile
├── gotty
└── gotty_linux_amd64.tar.gz
Dockerfile:
FROM alpine:3.11.3
RUN mkdir -p /home/gotty
WORKDIR /home/gotty
COPY gotty /home/gotty
RUN chmod +x /home/gotty/gotty
CMD ["/bin/sh"]
The image was built without issue:
[strip...]
Removing intermediate container 0dee1ab645e0
---> b5c6957d36e1
Step 7/9 : COPY gotty /home/gotty
---> fb1a1adec04a
Step 8/9 : RUN chmod +x /home/gotty/gotty
---> Running in 90031140da40
Removing intermediate container 90031140da40
---> 609e1a5453f7
Step 9/9 : CMD ["/bin/sh"]
---> Running in 30ce65cd4339
Removing intermediate container 30ce65cd4339
---> 099bc22ee6c0
Successfully built 099bc22ee6c0
The chmod changed the file mode successfully. So /home/gotty/gotty is present.
$ docker run -itd 099bc22ee6c0
9b219a6ef670b9576274a7b82a1b2cd813303c6ea5280e17a23a917ce809c5fa
$ docker exec -it 9b219a6ef670 /bin/sh
/home/gotty # ls
gotty
/home/gotty # ./gotty
/bin/sh: ./gotty: not found
Go into the container, the gotty command is there. I ran it with relative path. Why the not found?
You are running into one of the more notorious problems with Alpine: Musl, instead of glibc. Check out the output of ldd gotty. Try adding libc6-compat:
apk add libc6-compat
and see if that fixes it.
I could not find that spoecifics via web search for site:stackoverflow.com dockerfile RUN fs changes not persisted.
I made Dockerfile and wanted to make some changes in image via RUN. Firstly I wanted to change file attributes, but changes were not there in started container. I've found this post taking about docker bug for chmod and workarounds: https://serverfault.com/questions/772227/chmod-not-working-correctly-in-docker. However, now I just try to create a file via RUN touch /path/file in Dockerfile and already on next command (next layer for docker as I understood the docs) changes (that file) are gone. As far as I see it is strange, otherwise how apt install works then because it will make changes to file system in the image... Why results of that particular RUN do not persist? Docs below tell opposite (or I misunderstand meaning of commit here):
https://docs.docker.com/engine/reference/builder/ :
The RUN instruction will execute any commands in a new layer on top of
the current image and commit the results. The resulting committed
image will be used for the next step in the Dockerfile.
Here is output of docker build --no-cache -t yandex:user5 yandex2/ (see steps 6 and 7; dockeruser is created, btw):
Step 1/8 : FROM artifactory.dev.foo.org:5000/yandex-tank:jmeter
---> b8286a9220ca
Step 2/8 : LABEL maintainer="foo#foo.org"
---> Running in 7cfde9a90bf2
Removing intermediate container 7cfde9a90bf2
---> b5acd9d55f9c
Step 3/8 : WORKDIR /var/loadteest
---> Running in 47e9adc401bb
Removing intermediate container 47e9adc401bb
---> 103f158e0be3
Step 4/8 : USER root
---> Running in 9923d71f7b08
Removing intermediate container 9923d71f7b08
---> bb3aa8672bc6
Step 5/8 : RUN groupadd -r dockeruser && useradd -r -g dockeruser -d /var/loadtest -s /sbin/nologin -c "Docker image user" dockeruser
---> Running in 48c89f33d750
Removing intermediate container 48c89f33d750
---> 5000afa7698d
Step 6/8 : RUN touch /var/loadtest/chmodtest.txt
---> Running in 00b2d1ccad75
Removing intermediate container 00b2d1ccad75
---> c35808f13344
Step 7/8 : RUN ls -al /var/loadtest
---> Running in cc08d129eeb3
total 8
drwxr-xr-x 2 root root 4096 Nov 20 12:19 .
drwxr-xr-x 1 root root 4096 Nov 29 06:15 ..
Removing intermediate container cc08d129eeb3
---> 842678ca5d49
Step 8/8 : ENTRYPOINT /bin/bash
---> Running in 20b92a97c8a8
Removing intermediate container 20b92a97c8a8
---> fefd0d665677
Successfully built fefd0d665677
Successfully tagged yandex:user5
The Problem is using the volumes in the base image:
Changing the volume from within the Dockerfile: If any build steps
change the data within the volume after it has been declared, those
changes will be discarded.
see This
Workaround is to use COPY docker doc
COPY path/to/local/file /var/loadtest/chmodtest.txt
I'm trying to build a stack with one docker-compose that should contain another containers inside. This is to run a development environment with all my projects inside.
So the problem is the volume with application source isn't appearing on built image.
MacOS Sierra
Docker version 17.03.0-ce, build 60ccb22
Boot2Docker-cli version: v1.8.0
my directory tree
/dockers <======= one directory with all docker files for each project
docker-compose.yml <======= The main image
/project1 <======= dockerfile for each project
Dockerfile
/project2
Dockerfile
/project3
Dockerfile
/project1 <======= project1 source folder
test.txt
/project2
/project3
my docker-compose.yml
project1:
build: ./project1
volumes:
- ../project1/:/src
my dockerfile for project1
FROM python:2.7
RUN mkdir -p /src
WORKDIR /src
RUN echo "---------------------"
RUN ls -la
RUN echo "---------------------"
So I try to build the docker-compose file
$ sudo docker-compose build --no-cache
And then it shows an empty folder when I expect test.txt file
Building express
ERROR: Cannot locate specified Dockerfile: Dockerfile
➜ docker git:(master) ✗ sudo docker-compose build --no-cache
Building project1
Step 1/7 : FROM python:2.7
---> ca388cdb5ac1
Step 2/7 : RUN mkdir -p /src
---> Running in 393a462f7a44
---> 4fbeb32d88b3
Removing intermediate container 393a462f7a44
Step 3/7 : WORKDIR /src
---> 03ce193577ab
Removing intermediate container b1cd746b699a
Step 4/7 : RUN echo "--------------------------"
---> Running in 82df8a512c90
----------------------------
---> 6dea58ba5051
Removing intermediate container 82df8a512c90
Step 5/7 : RUN ls -la
---> Running in 905417d0cd19
total 8
drwxr-xr-x 2 root root 4096 Mar 23 17:12 . <====== EMPTY :(
drwxr-xr-x 1 root root 4096 Mar 23 17:12 .. <====== EMPTY :(
---> 53764caffb1a
Removing intermediate container 905417d0cd19
Step 6/7 : RUN echo "-----------------------------"
---> Running in 110e765d102a
----------------------------
---> b752230fd6dc
Removing intermediate container 110e765d102a
Step 7/7 : EXPOSE 3000
---> Running in 1cfe2e80d282
---> 5e3e740d5a9a
Removing intermediate container 1cfe2e80d282
Successfully built 5e3e740d5a9a
Volumes are runtime configurations in Docker. Because they are configurable, if you were to reference volumes during the build phase you would essentially be creating a potentially uncheckable broken dependency.
I'm sure there is a more technical reason - but it really shouldn't be done. Move all that stuff to the runtime setup command and you should be OK.
I made a Docker container which is fairly large. When I commit the container to create an image, the image is about 7.8 GB big. But when I export the container (not save the image!) to a tarball and re-import it, the image is only 3 GB big. Of course the history is lost, but this OK for me, since the image is "done" in my opinion and ready for deployment.
How can I flatten an image/container without exporting it to the disk and importing it again? And: Is it a wise idea to do that or am I missing some important point?
Now that Docker has released the multi-stage builds in 17.05, you can reformat your build to look like this:
FROM buildimage as build
# your existing build steps here
FROM scratch
COPY --from=build / /
CMD ["/your/start/script"]
The result will be your build environment layers are cached on the build server, but only a flattened copy will exist in the resulting image that you tag and push.
Note, you would typically reformulate this to have a complex build environment and only copy over a few directories. Here's an example with Go to make a single binary image from source code and a single build command without installing Go on the host and compiling outside of docker:
$ cat Dockerfile
ARG GOLANG_VER=1.8
FROM golang:${GOLANG_VER} as builder
WORKDIR /go/src/app
COPY . .
RUN go-wrapper download
RUN go-wrapper install
FROM scratch
COPY --from=builder /go/bin/app /app
CMD ["/app"]
The go file is a simple hello world:
$ cat hello.go
package main
import "fmt"
func main() {
fmt.Printf("Hello, world.\n")
}
The build creates both environments, the build environment and the scratch one, and then tags the scratch one:
$ docker build -t test-multi-hello .
Sending build context to Docker daemon 4.096kB
Step 1/9 : ARG GOLANG_VER=1.8
--->
Step 2/9 : FROM golang:${GOLANG_VER} as builder
---> a0c61f0b0796
Step 3/9 : WORKDIR /go/src/app
---> Using cache
---> af5177aae437
Step 4/9 : COPY . .
---> Using cache
---> 976490d44468
Step 5/9 : RUN go-wrapper download
---> Using cache
---> e31ac3ce83c3
Step 6/9 : RUN go-wrapper install
---> Using cache
---> 2630f482fe78
Step 7/9 : FROM scratch
--->
Step 8/9 : COPY --from=builder /go/bin/app /app
---> Using cache
---> 5645db256412
Step 9/9 : CMD /app
---> Using cache
---> 8d428d6f7113
Successfully built 8d428d6f7113
Successfully tagged test-multi-hello:latest
Looking at the images, only the single binary is in the image being shipped, while the build environment is over 700MB:
$ docker images | grep 2630f482fe78
<none> <none> 2630f482fe78 6 days ago 700MB
$ docker images | grep 8d428d6f7113
test-multi-hello latest 8d428d6f7113 6 days ago 1.56MB
And yes, it runs:
$ docker run --rm test-multi-hello
Hello, world.
Up from Docker 1.13, you can use the --squash flag.
Before version 1.13:
To my knowledge, you cannot using the Docker api. docker export and docker import are designed for this scenario, as you yourself already mention.
If you don't want to save to disk, you could probably pipe the outputstream of export into the input stream of import. I have not tested this, but try
docker export red_panda | docker import - exampleimagelocal:new
Take a look at docker-squash
Install with:
pip install docker-squash
Then, if you have a image, you can squash all layers into 1 with
docker-squash -f <nr_layers_to_squash> -t new_image:tag existing_image:tag
A quick 1-liner that is useful for me to squash all layers:
docker-squash -f $(($(docker history $IMAGE_NAME | wc -l | xargs)-1)) -t ${IMAGE_NAME}:squashed $IMAGE_NAME
Build the image with the --squash flag:
https://docs.docker.com/engine/reference/commandline/build/#squash-an-images-layers---squash-experimental
Also consider mopping up unneeded files, such as the apt cache:
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*