I have a Raspberry Pi 3 B+ with Docker installed on it. I'm trying to pull the latest ARMv7 edition of the golang container image, linked below.
https://hub.docker.com/u/arm32v7/
https://hub.docker.com/r/arm32v7/golang/
When I run the docker pull command on the image, I get the generic error below.
pi#trevorpi:~ $ docker pull arm32v7/golang:latest
Pulling repository docker.io/arm32v7/golang
Tag latest not found in repository docker.io/arm32v7/golang
Here's the version of Docker I'm running:
pi#trevorpi:~ $ docker version
Client:
Version: 1.8.3
API version: 1.20
Go version: go1.4.3
Git commit: f4bf5c7
Built:
OS/Arch: linux/arm
Server:
Version: 1.8.3
API version: 1.20
Go version: go1.4.3
Git commit: f4bf5c7
Built:
OS/Arch: linux/arm
Here's the output from uname -a, which indicates it's ARMv7:
Linux trevorpi 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux
Obviously, the x86 Docker image for golang doesn't work, because it's not ARM-compatible. I can pull the image, but it won't run due to processor architecture:
pi#trevorpi:~ $ docker pull golang:latest
latest: Pulling from library/golang
836de16dcbe9: Already exists
490028bf21ec: Already exists
b9aece5a7acf: Already exists
e5bf67252042: Already exists
a221240e1da3: Already exists
efcf11bc5c78: Already exists
32d2d4bbdbd3: Already exists
599e9bccee8b: Already exists
b77bfa353366: Already exists
dc799d5ef217: Already exists
cb12e793d3e1: Already exists
c984412a4f12: Already exists
Digest: sha256:ce05c9f8151cc4ff3ce508509720597d103b630aa024bcfb012107149abfa361
Status: Image is up to date for golang:latest
pi#trevorpi:~ $ docker run --rm -it golang
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
exec format error
Error response from daemon: Cannot start container 0c04cb7f7192f2059b029637bd6306c0a4ff83299e3a20df920b3ea56339ab7a: [8] System error: exec format error
Question: I manually verified that the latest tag is valid. What do I need to do to pull this image?
Maybe you are trying to download an image not available for your system (OS or Architecture).
$ docker manifest inspect -v arm32v7/golang:latest
[
{
"Ref": "docker.io/arm32v7/golang:latest#sha256:faf19ab885f9d0779bbbd615eee610c5aedfdd203ac5fceefbd5fc8afd73a2ac",
"Descriptor": {
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:faf19ab885f9d0779bbbd615eee610c5aedfdd203ac5fceefbd5fc8afd73a2ac",
"size": 1795,
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
Are you sure your raspberry uses arm v7 architecture? Unfortunately, I don't have raspberry ow my own, so I can't reproduce this problem.
Have you tried do pull with other tags than latest? Also, You could try to build this image yourself. Golang repo
Maybe try with an official repository for golang:
docker pull golang:latest
they also support your architecture:
Supported architectures: md64, arm32v6, arm32v7, arm64v8,
i386, ppc64le, s390x, windows-amd6
Maybe this is a connection/firewall issue. Can you pull from other repositories?
Related
I'm using docker-toolbox on windows home.
I was able to run a jekyll-serve web server image to see the default page on browser, but when I try to edit file on VS Code, I can not see the changes after refreshing the browser.
Any idea why I can not see the changes after refresh?
Step to reproduce:
First I've git cloned this repository into my c:/Users/shaharshokrani/udemy-docker-mastery/bind-mount-sample1 (I'm able to see the files with ls on 'cmder' console).
Then I was able to run this image with:
docker run -v //c/users/shaharshokrani/udemy-docker-mastery/bindmount-sample-1:/site bretfisher/jekyll new .
docker container run -p 80:4000 --name myjekyll -v //c/users/shaharshokrani/udemy-docker-mastery/bindmount-sample-1:/site bretfisher/jekyll-serve
And I'm able to see the default welcome page on http://192.168.99.100/.
I've tried to edit and save using VS Code this 2017-03-05-welcome-to-jekyll.markdown but I can not see the changes after refreshing the browser.
I also checked the VM for shared network - it shows c:/users/.
Even the Mounts on inspect looks good:
"Mounts": [
{
"Type": "bind",
"Source": "/c/users/shaharshokrani/udemy-docker-mastery/bindmount-sample-1",
"Destination": "/site",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
And the image dockerfile's CMD has the --force_polling flag.
Both the images (bretfisher/jekyll-serve, bretfisher/jekyll) are latest.
The docker container logs -f myjekyll looks good:
Bundle complete! 4 Gemfile dependencies, 28 gems now installed.
Bundled gems are installed into `/usr/local/bundle`
Configuration file: /site/_config.yml
Source: /site
Destination: /site/_site
Incremental build: disabled. Enable with --incremental
Generating...
Jekyll Feed: Generating feed for posts
done in 1.031 seconds.
Auto-regeneration: enabled for '/site'
Server address: http://0.0.0.0:4000/
Server running... press ctrl-c to stop.
Docker version:
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24302
Built: Fri Mar 23 08:31:36 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server: Docker Engine - Community
Engine:
Version: 19.03.3
API version: 1.40 (minimum version 1.12)
Go version: go1.12.10
Git commit: a872fc2f86
Built: Tue Oct 8 01:01:20 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683
Issue identified
Bind mounting actually does not work for docker toolbox:
file change events in mounted folders of host are not propagated to
container by Docker for Windows
Solution
This script is intended to be the answer to this issue: docker-windows-volume-watcher.
Side note
This is a common issue with data manipulated outside of your container.
For jekyll, in particular, even the solution described in the issue below does not work for windows-based systems.
https://github.com/jekyll/jekyll-watch/issues/17
In short you need to execute jekyll with the --force_polling flag (Does not work with Windows Hosts). You can find it in the jekyll docs here
https://jekyllrb.com/docs/configuration/options/
On Linux based systems it works out of the box since the image used in the question bretfisher/jekyll-serve already utilizes the --force_polling flag.
just ran
docker run --rm -it -e JEKYLL_NEW=true -p 8080:4000 -v (pwd):/site bretfisher/jekyll new .
to create a new jekyll site and
docker run --rm -it -e JEKYLL_NEW=true -p 8080:4000 -v (pwd):/site bretfisher/jekyll-serve
to run it mounted to a directory on my machine (linux) and was able to edit a file with changes propagating to jekyll.
I just bought a QNAP TS-832X NAS (Firmware: 4.3.4.0695 Build 20180830).
This machine comes with an ARM CPU (Annapurna Labs Alpine AL324 Quad-core ARM Cortex-A57 CPU # 1.70GHz).
I bought it only to install GitLab on it, but the official image doesn't seem to work.
When I try to run the image it fails.
[~] # docker run -d --name gitlab-server --hostname build1 -p 10080:10080 -p 10022:22 -p 10443:443 -v /share/GitLab/config:/etc/gitlab -v /share/GitLab/logs:/var/log/gitlab -v /share/GitLab/data:/var/opt/gitlab --restart always gitlab/gitlab-ce:latest
[~] # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a176158729ad gitlab/gitlab-ce:latest "/assets/wrapper" 5 seconds ago Restarting (1) 1 second ago gitlab-server
[~] # docker logs a1
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
standard_init_linux.go:185: exec user process caused "exec format error"
After googling I figured it might be caused by the host architecture, so I tried running ulm0/gitlab, but with the same result.
I also tried other images with "ARM" in their tags like arm64v8/ubuntu. This one didn't even give any logs.
[~] # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2b2b68bc912c arm64v8/ubuntu:latest "/bin/bash" 7 seconds ago Restarting (0) 1 second ago ubuntu-arm
a176158729ad gitlab/gitlab-ce:latest "/assets/wrapper" 2 hours ago Restarting (1) 51 seconds ago gitlab-server
[~] # docker logs 2b
[~] #
uname -a
Linux build1 4.2.8 #2 SMP Thu Aug 30 07:33:01 CST 2018 aarch64 GNU/Linux
docker version
Client:
Version: 17.09.1-ce
API version: 1.32
Go version: go1.8.3
Git commit: a9fd393
Built: Fri Aug 3 04:31:20 2018
OS/Arch: linux/arm64
Server:
Version: 17.09.1-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: a9fd393
Built: Fri Aug 3 04:31:20 2018
OS/Arch: linux/arm64
Experimental: false
Sorry to hear about your problem, unfortunately I don't believe there is any official GitLab Docker image for ARM devices.
From personal experience I've found that most developers will make a Docker image for Intel devices but not work on ARM Devices.
This topic has been discussed on the QNAP Forums already:
My QNAP is Intel based, so I can't corroborate your results, but quoting a few sentences from a page about docker on Raspberry Pi:
"Docker-based apps you use have to be packaged specifically for ARM architecture! Docker-based apps packaged for x86/x64 will not work and will result in an error such as:
FATA[0003] Error response from daemon: Cannot start container 0f0fa3f8e510e53908e6a459e817d600b9649e621e7dede974d6a65761ad39e5: exec format error
Keep this in mind when searching for apps on the Docker Hub - the source for Docker apps/images. If you see the keyword RPI or ARM in the heading or description, this app can usually be used for the Raspberry Pi."
The TS-831X has a "AnnapurnaLabs, an Amazon company Alpine AL-314 Quad-core 1.7 GHz Cortex-A15 processor" CPU, which is an ARM architecture much like the Raspberry Pi..
So, I suspect you may be limited in what Docker images you have access to and unless an official/canonical maintainer of an app also makes an ARM build, you may be stuck with either rolling your own or trusting a 3rd party hobbyist to do so...
I hate to say this but I'd say you should have picked up an Intel one instead.
I have a QNAP TS-251+ (Intel based) with 8GB RAM and 2x8TB in a RAID Configuration and this works perfectly for my Gitlab instance, in addition to running PLEX and using it as a Webserver as well.
I would also suggest when you do finally get it up and running to map the volumes to directories that are easy to access so you can make configuration changes easily.
I'm trying to pack an application compiled with Bazel into a Docker image, using Bazel.
I have an empty WORKSPACE file, the following main.cc file:
#include <stdio.h>
int main() { printf("Hello World\n"); }
and the following BUILD file (all in the same folder):
load("#bazel_tools//tools/build_defs/docker:docker.bzl", "docker_build")
cc_binary(
name = "hello",
srcs = ["main.cc"],
)
docker_build(
name = "hello_docker",
files = [":hello"],
cmd = ["./hello"],
)
Gist is available here.
When I run bazel run :hello, I can see "Hello World" successfully printed. Then I run bazel build :hello_docker.tar which is supposed to generate a full image for docker in bazel-bin/hello_docker.tar. Looks like it does.
Then I run:
$ docker load -i bazel-bin/hello_docker.tar
51525b594688: Loading layer [==================================================>] 10.24 kB/10.24 kB
Loaded image ID: sha256:252367f43640968343ecd78b2a3533c8ed99c4be66d73fc3ec6ccb137df19625
Then I list all images:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 14.04 b969ab9f929b 3 weeks ago 188 MB
docker/whalesay latest 6b362a9f73eb 21 months ago 247 MB
<none> <none> 252367f43640 292 years ago 8.048 kB
Looks like the image which was just loaded does not have any repository or tag associated with it. Why can that be and how do I fix that? The "created" value is huge as expected (Bazel clears timestamps for reproductibility).
When I look inside hello_docker.tar, I see something related to the expected repository/tag inside the repository file:
{
"bazel/": {
"hello_docker": "3d529b3ceeb0d9ef33f6225e655f3f5a0e061888f25cd6a3fac11604778ef6a8"
}
}
Another problem: when I try to run the image in a new container, it fails:
$ docker run -t -i 25236
docker: Error response from daemon: oci runtime error: exec: "./hello": stat ./hello: no such file or directory.
I looked inside the generated tar file one more time and found out that there is an executable here, but it's named o for some reason. Another attempt and a different error:
$ docker run -t -i 25236 ./o
write pipe: bad file descriptor
Strangely enough, if I pack that hello executable with my own Dockerfile like this, "Hello World" is printed as expected:
FROM ubuntu:14.04
ADD hello .
CMD ./hello
Can anyone suggest how to fix any of these three issues? I think that they're interconnect and I have wrong BUILD file (maybe I should somehow specify which Linux image to use as a base?). Recap:
Repository/tag name is not displayed after image generated by Bazel is imported into Docker.
hello file is added to the image under the name o.
Even when run as o, Dockered executable yields "bad file descriptor" message.
My software versions:
$ bazel version
Build label: 0.4.4
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Feb 1 18:54:21 2017 (1485975261)
Build timestamp: 1485975261
Build timestamp as int: 1485975261
$ docker version
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.2
Git commit: 6b644ec
Built: Mon, 19 Dec 2016 09:20:48 +1300
OS/Arch: linux/amd64
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.2
Git commit: 6b644ec
Built: Mon, 19 Dec 2016 09:20:48 +1300
OS/Arch: linux/amd64
When i try to build docker images using the command docker build -t opencv:2.4.11 . I get following error.
Sending build context to Docker daemon 189.8 MB
Step 1 : FROM ubuntu:trusty
---> b72889fa879c
Step 2 : RUN apt-get update
---> Running in 689f34e138c2
Container command '/bin/sh' could not be invoked.
My docker client and server version are:
Client:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 18:34:23 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 18:34:23 2016
OS/Arch: linux/amd64
Any idea?
I have softlinked my /var/lib/docker directory to one of directories present in my home. And that directory is owned by root. Is this the source of problem?
Before moving and softlinking it was fine. I ran out of space in my root partition and so I had to change it to my home partition.
And my home partition is ext4 file system.
Regards
It looks badly hosed.
I have softlinked my /var/lib/docker directory to one of directories present in my home.
I would recommend amending the daemon parameters to include -g your_other_directory instead. Then stop and restart Docker.
If it still doesn't work, delete both Docker directories, re-install, and start at the -g step again.
I'm trying to dockerize a Stardog 3.1.3 community edition server. The container fails to start because it sees a directory instead of a license file. For the record, I'm on Windows. These are the steps I'm following:
Create a data container
docker create -v /data/stardog:/data/stardog --name stardog_data busybox /bin/true
Copy the local license key to the data container (not done in the Dockerfile that is mentioned below as the license is environment specific)
docker cp .\stardog\stardog-license-key.bin stardog_data:/stardog-license-key.bin
Create an image based on the following Dockerfile
docker build -t me/stardog .
FROM java:openjdk-8-jdk
ENV STARDOG_VER stardog-3.1.3
ENV STARDOG_HOME /data/stardog
COPY ${LOCAL_PATH}/${STARDOG_VER}.zip /
RUN unzip ${STARDOG_VER}.zip
WORKDIR /${STARDOG_VER}
CMD rm $STARDOG_HOME/system.lock || true && bin/stardog-admin server start && (tail -f $STARDOG_HOME/stardog.log &) && while (pidof java > /dev/null); do sleep 1; done
Run a Stardog container
docker run -d -p 5820:5820 --volumes-from stardog_data --name stardog me/stardog
When I execute docker ps -a, I see that the container is stopped after a couple of seconds:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9559b22473e1 me/stardog "/bin/sh -c 'rm $STAR" 26 minutes ago Exited (1) 26 minutes ago stardog
2b929329e35e busybox "/bin/true" 32 minutes ago Created stardog_data
When I check the logs with docker logs stardog, I'm getting this:
com.clarkparsia.license.InvalidLicenseException: java.io.FileNotFoundException: /data/stardog/stardog-license-key.bin (Is a directory)
at com.clarkparsia.license.LicenseValidator.validate(LicenseValidator.java:157)
at com.complexible.stardog.StardogLicense.findLicense(StardogLicense.java:127)
at com.complexible.stardog.StardogLicense.<init>(StardogLicense.java:70)
at com.complexible.stardog.Stardog.<init>(Stardog.java:158)
at com.complexible.stardog.Stardog.initialize(Stardog.java:263)
at com.complexible.stardog.Stardog.initialize(Stardog.java:254)
at com.complexible.stardog.Stardog.buildServer(Stardog.java:247)
at com.complexible.stardog.cli.impl.ServerStart.call(ServerStart.java:144)
at com.complexible.stardog.cli.impl.ServerStart.call(ServerStart.java:47)
at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:54)
at com.complexible.stardog.cli.admin.CLI.main(CLI.java:194)
Caused by: java.io.FileNotFoundException: /data/stardog/stardog-license-key.bin (Is a directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at com.clarkparsia.license.LicenseValidator.validate(LicenseValidator.java:113)
... 10 more
Your Stardog license is invalid. Please contact support#clarkparsia.com for information on obtaining a new license.
It seems that the license file is considered to be a directory. What am I doing wrong?
I'm using the following Docker version:
Client:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 21:49:11 2016
OS/Arch: windows/amd64
Server:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 21:49:11 2016
OS/Arch: linux/amd64
This seems to be a Windows related problem. I've tried these exact same steps on a native Ubuntu (14.04) machine and it works as expected. I've filed this as a bug and hopefully this gets fixed soon.