Building docker for the ARM-64 architecture - docker

I have been trying to compile docker for the ARM-64 architecture. Docker doesn’t officially support ARM 64-bits (at least not through the package management tools); hence I have to build it from source. Building docker binary set needs docker itself as a dependency. I’ve already managed to compile both the docker daemon and the client via the following (hack) command:
./hack/make.sh dynbinary
However, I haven’t managed to run it successfully. Both binaries are compiled and work, but when I want to start up the daemon it complains about other dependencies:
Failed to connect to containerd. Please make sure containerd is installed in your PATH or you have specified the correct address. Got error: exec: "docker-containerd": executable file not found in $PATH
As I mentioned earlier, I cannot build all the binaries as they need docker itself running.
Looking forward to your help.

Two weeks ago, I was able to install Docker on a Pine64 running Armbian (Debian based). It was as easy as following the official documentation for armhf with one exception, change [arch=armhf] by [arch=arm64] when you add the new apt source.
After the install you have a real Arm64 docker running :
root#pine64:~# docker system info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 60
Server Version: 17.12.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 28
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 3.10.107-pine64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 979.6MiB
Name: pine64
ID: xxx
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: xxx
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Related

Kubernetes `RuntimeHandler "runc" not supported` when creating container

I was trying to specify the runtime of containers deployed using Kubernetes. I follow the guide in this link and creating the following RuntimeClass:
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: runc
handler: runc
# $ kubeclt get RuntimeClass
# NAME HANDLER AGE
# runc runc 59m
Then, I set my Pod spec.runtimeClassName="runc". However, when deploying this using Kubernetes, I got the following error:
Warning FailedCreatePodSandBox 2m43s (x141 over 32m) kubelet, jetson1 Failed to create pod sandbox: rpc error: code = Unknown desc = RuntimeHandler "runc" not supported
I can run the container with docker and --runtime=runc without any error. But when deploying it with K8s, the error occur. The following is my docker info:
Client:
Debug Mode: false
Server:
Containers: 11
Running: 5
Paused: 0
Stopped: 6
Images: 12
Server Version: 19.03.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: nvidia runc
Default Runtime: nvidia
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.140-tegra
Operating System: Ubuntu 18.04.4 LTS
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 3.871GiB
Name: jetson1
ID: HLZ4:DQKM:J7YY:OMDN:JXXZ:PFL5:YJGT:DJBM:SMSL:UTZA:WCZ4:GUD4
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Any suggestions will be appreciated. Thank you!
While runc is able to create containers, it's a rather low-level component. Most tools we know as container runtimes actually rely on it in some way. This answer to another question gives a great overview of it.
The RuntimeClass feature in Kubernetes to target a specific conainer runtime requires it to implement the CRI (Container Runtime Interface) on the local nodes (the "Setup" part of your shared link briefly talks about it). I did some quick research and there is no hint that runc is implementing CRI directly. If it was, Kubernetes would skip accessing Docker as you did; it would use that interface to talk to another component directly from kubelet. Checking Docker settings therefore doesn't help to see if runc is a viable Kubernetes container runtime.
So, you should review why you're trying to do this - runc is likely already used in your default container rumtime stack without you maybe realizing it. Kubernetes has documentation for alternative container runtimes, you can look into installing these if you are looking for something more lightweight than Docker.

Docker seccomp error after upgrade from debian 8 to debian 9

The following error occurs during docker run and docker build after upgrading from Debian 8 to Debian 9:
ERROR: Service 'etherpad' failed to build: OCI runtime create failed: container_linux.go:344: starting container process caused "error loading seccomp filter into kernel: invalid argument": unknown
I was able to solve the problem when running a container by using --seccomp-profile:unconfined but build doesn't support this flag (https://github.com/moby/moby/issues/21105). I also tried to pass it to the daemon via the daemon.json but this caused an error during startup.
Kernel support is enabled:
grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y
docker info:
Containers: 38
Running: 9
Paused: 0
Stopped: 29
Images: 119
Server Version: 18.09.2
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 275
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
init version: fec3683
Security Options:
seccomp
WARNING: You're not using the default seccomp profile
Profile: /root/labs/security/seccomp/seccomp-profiles/default.json
Kernel Version: 3.16.0-7-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.71GiB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Does anyone have an idea how to solve it? Thank you very much.
TLDR; reboot your server after upgrading to Stretch.
Your issue looks similar to one that I experienced. I received the below error:
OCI runtime create failed: container_linux.go:345: starting container process caused "error loading seccomp filter into kernel: invalid argument": unknown
The issue occurred after upgrading from Jessie to Stretch and installing a fresh copy of Docker (https://docs.docker.com/install/linux/docker-ce/debian/).
I believe your issue is similar because your docker info output shows
Kernel Version: 3.16.0-7-amd64
and for me:
# uname -a
Linux debian 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux
Stretch should be using a later kernel version than that, so the fix was:
# reboot
# uname -a
Linux debian 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux

exec: "docker-runc": executable file not found in $PATH: unknown

Using ubuntu 18.04
after upgrading docker to "Docker version 18.09.0-ce-tp5, build 9eb3d36"
Everything works fine before updating docker
Getting following error on docker-compose up:
ERROR: for mysql_1 Cannot start service mysql: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v1.linux/moby/242793c2e7ad05e93ccff53ae37e5d8b054a72f9c2076c1b480f33929dbb45aa/log.json: no such file or directory): exec: "docker-runc": executable file not found in $PATH: unknown
docker info gives
linux#linux-linux:/$ docker info
Containers: 14
Running: 14
Paused: 0
Stopped: 0
Images: 1091
Server Version: 18.09.0-ce-tp5
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 1038
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: containerd runc
Default Runtime: containerd
Init Binary: docker-init
containerd version: ce243288e27971e324363de8f322d221635a8521 (expected: 468a545b9edcd5932818eb9de8e72413e616e86e)
runc version: 1555a78945e56737bc3d15565191d857ee6fa2b9 (expected: 69663f0bd4b60df09991c08812a60108003fa340)
init version: fec3683
Security Options:
apparmor
Kernel Version: 4.15.0-32-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.719GiB
Name: linux-linux
ID: F475:F7JY:3HSG:XLGM:BAPD:CZYD:HRRO:SN3N:SFSX:7XOK:VDZ4:SNMV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: No swap limit support
Using ubuntu 18.04 after upgrading docker to "Docker version 18.09.0-ce-tp5, build 9eb3d36"
The TP# releases are pre beta (I suspect it stands for technical preview). These will have issues, and there were lots of changes with the containerd integration. You can try upgrading to beta1, or go back to the stable 18.06.1 release. You can see the releases here:
https://github.com/docker/docker-ce/releases
Issue:
I faced the same issue.
Solution
first i restart docker,but when i tried to start my container i was having Error response from daemon: OCI runtime create failed: container with id exists:xxxxxxxxxx
but in ps -a it was showing nothing.
while i was able to run the new container using the same id.
than tried
reboot my server and it is working fine.
as you can see in this 2 rows:
containerd version: ce243288e27971e324363de8f322d221635a8521 (expected: 468a545b9edcd5932818eb9de8e72413e616e86e)
runc version: 1555a78945e56737bc3d15565191d857ee6fa2b9 (expected: 69663f0bd4b60df09991c08812a60108003fa340)
docker expects another internal container id as the tagged container has. i guess this causes the problem.
have you tried to rebuild your container?
I faced a similar problem.
Try committing your container.
Then run it again.
e.g.
docker commit RUNNING_CONTAINER IMAGE1
docker run -d IMAGE1
service docker restart solved the problem in my case

How to find whether a image is present in the docker repository

Trying to pull a docker image in my local repo.
Command used:
docker pull buzybox:1.24
Error response from daemon: repository buzybox not found: does not exist or no pull access
My questions:
1:How to find the repository name which am connected with?
2.Whats the access issue in the error its talking about? Do we also have any kind of access issues in the default repo?? How to find that out?
3.How to change the repo if in case i dont find a image in my currect repo.
4.Do we have any web portal from where we can search if the image is present in repository.
Output id docker info :
docker info
Containers: 5
Running: 0
Paused: 0
Stopped: 5
Images: 2
Server Version: 17.06.2-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk
syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.41-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.941GiB
Name: moby
ID: RJWZ:HXFZ:5FQX:V2AB:YAXP:BKSU:RLQH:H24C:LNUD:USDA:VIF7:W2M3
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 15
Goroutines: 26
System Time: 2018-01-28T06:34:45.7011515Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Thanks in advance Guys!!
Nilotpal
You do not connect to a repository. You connect to a registry. You are probably connected to https://index.docker.io/v1/ but to be sure, you can run sudo docker info and look for the registry line. The repository in your case is buzybox and you are trying to download the image with tag 1.24 from that repository.
The access issue is probably that you mispelled busybox (notice the 's' instead of a 'z').
To log into a different registry, then run
docker login https://<YOUR-DOMAIN>:8080
and then make sure to specify the new registry when you download an image like so:
docker pull <YOUR-DOMAIN>:8080/busybox:1.24

Error on commit - How to increase Docker default container size when using Docker Toolbox and Windows 7

I'm running Docker on Windows 7, so Docker runs within a Virtual Box.
I've got an issue where I've got an Oracle image which has then had a database restored to it, pushing the image size up to 7.5 gigs. I want to do a docker commit on this, but I'm getting an out of space error when I do the commit.
I've seen a lot of posts on changing the default container size, but I'm not sure if this is possible with aufs, or how to change to a different file system type when running on Windows 7/VirtualBox.
Does anyone know how to increase the default container size in this environment ?
Error response from daemon: Error processing tar file(exit status 1): write /u01/app/oracle/oradata/XE/support.dbf: no space left on device
Docker info:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 72
Server Version: 17.10.0-ce
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 127
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.4.93-boot2docker
Operating System: Boot2Docker 17.10.0-ce (TCL 7.2); HEAD : 34fe485 - Wed Oct 18 17:16:34 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.79GiB
Name: default
ID: 2NWU:57WJ:4QAP:EBMY:MMF2:JFWA:IBWU:THGO:A4VD:SGVW:YQBP:MP2N
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 24
Goroutines: 35
System Time: 2017-12-06T09:33:14.736388742Z
EventsListeners: 2
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
The default size for a docker machine is 20GB, you can double-check by running docker-machine inspect default. This size can be configured when creating the machine from the cli. You can recreate the default machine and set the size as follows:
docker-machine rm default
docker-machine create -d virtualbox --virtualbox-disk-size "400000" default
You can also edit the file C:\Program Files\Docker Toolbox\start.sh to set default values for size and ram for created machines.

Resources