How to pull docker windows_image on Linux hosted local Registry - docker

I'm trying to set up a local Docker Registry to keep there both Windows and Linux images.
AFAIK there is no Windows docker image for Registry. So I can't set up my own registry on Windows host. Am I right?
Ok, I set up a linux box, got there a registry:
# docker version
Client:
Version: 18.09.0-ce
API version: 1.39
Go version: go1.10.8
Git commit:
Built: Mon Jan 28 16:51:31 2019
OS/Arch: linux/amd64
Experimental: true
Server:
Engine:
Version: dev
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 4d60db4/18.09.0
Built: Thu Jan 17 13:27:44 2019
OS/Arch: linux/amd64
Experimental: true
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7db5178d0215 registry "/entrypoint.sh /etc…" 20 hours ago Up 4 minutes 0.0.0.0:5000->5000/tcp MyReg
and then I want to pull there a windows tagged image NOT to run, just to put there my own tag and let my users to pull it from me after that.
But I can't because the architect problem.
I've already set both the engine and the client to Experimental but still get this error:
# docker pull --platform windows/amd64 hello-seattle
Using default tag: latest
latest: Pulling from library/hello-seattle
image operating system "windows" cannot be used on this platform
So the questions are:
1. Can I have one registry to keep there Linux AND Windows images simultaneously?
2. How should I properly pull Windows tagged image onto linux hosted docker registry to keep it there and redistribute after?

Ran into sort of same problem, so following just to hear a solution.
I noticed that stefanscherer on docker hub has an docker registry image for windows, but i dont like to run unofficial images.
In my case i'm building an asp.net core application that builds an aspnet:60 base docker image that supports both linux and windows. I want the build/deployment process to run on a dedicated build host, which seems have to be installed with a windows OS to build windows containers.
I like to keep my docker registry local instead of using docker hub (at least until it reaches some production ready state). I believe i have to install a linux host as well in order to host a docker registry or build the docker registry from source for windows.

Related

Issue: Cannot connect to the Docker daemon at unix:///home/tonton/.docker/desktop/docker.sock. Is the docker daemon running?

Hello Guys when I run docker version
My docker compose version is : docker compose version
Docker Compose version v2.2.2
Client: Docker Engine - Community
Version: 20.10.18
API version: 1.41
Go version: go1.18.6
Git commit: b40c2f6
Built: Thu Sep 8 23:11:43 2022
OS/Arch: linux/amd64
Context: desktop-linux
Experimental: true
Cannot connect to the Docker daemon at unix:///home/tonton/.docker/desktop/docker.sock. Is the docker daemon running?
I am using ubuntu 22.04 version.
In my case:
I had installed docker desktop by apt in ubuntu20.04 before, but removed it later .
And when I try to check sudo docker images today there is the same issue.
Restarting docker, chown socket and some other strange ways don't work.
Suddenly I discover that there is no such socket file in docker/desktop/, but in the default location /var/run. Then trying to restore docker default context by docker context use default makes everything come back to normal.
So I think that the remained docker-desktop context takes the responsibility.....

'No matching manifest for unknown in the manifest list entries' when pull nanoserver:1903

I want to pull microsoft-windows-nanoserver for my windows container on windows 10 pro.
My environment:
Docker Desktop
Version: 2.0.0.3 (31259)
Channel: stable
Sha1: 8858db33c8692b69de9987a5d672798d778735b2
OS Name: Windows 10 Pro
Windows Edition: Professional
Windows Build Number: 17763
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version:go1.10.8
Git commit:6247962
Built: Sun Feb 10 04:12:31 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.24)
Go version: go1.10.6
Git commit: 6247962
Built:Sun Feb 10 04:28:48 2019
OS/Arch: windows/amd64
Experimental: true
What's strange is:
Pull 1803 is ok:
C:\>docker pull mcr.microsoft.com/windows/nanoserver:1803
1803: Pulling from windows/nanoserver
e46172273a4e: Pull complete
8f7ed89f9e35: Pull complete
Digest: sha256:bc5c1878a69c4538d55bc74e50b7dbafafff1a373120e624e8bad646a0a505dc
Status: Downloaded newer image for mcr.microsoft.com/windows/nanoserver:1803
But pull 1903 is not ok:
C:\>docker pull mcr.microsoft.com/windows/nanoserver:1903
1903: Pulling from windows/nanoserver
no matching manifest for unknown in the manifest list entries
What I notice is there is a table in its dockerhub:
Tags Architecture Dockerfile OsVersion CreatedTime LastUpdatedTime
1903 multiarch No Dockerfile 10.0.18362.239 05/21/2019 18:01:07 07/09/2019 18:29:39
1803 multiarch No Dockerfile 10.0.17134.885 10/05/2018 22:06:26 07/09/2019 17:41:59
Does the OsVersion mean the docker host os's version or my contaner's distrubtion's version? You can see my windows host os is 17763, this could be the reason I cannot pull 1903 or other reason?
Additional, if above guess is correct, then why could this happen? As I know, container just share the host's kernel, shouldn't care the os version, meanwhile, docker for windows on windows10 use hyper-v, why it care my windows os's version?
I really don't want to upgrade my os again and again if I want to use new version container... I hope my guess is wrong, anything I miss?
I find the answer.
After I execute docker pull mcr.microsoft.com/windows/nanoserver:1903, I find there is a debug log in C:\Users\user\AppData\Local\Docker\log.txt, it said:
debug: a Windows version 10.0.18362-based image is incompatible with a 10.0.17763 host
So, it confirms my guess, my issue happens because I use an old windows 10 version, had to upgrade my windows10 to at least 10.0.18362.239 to use nanoserver:1903.
The reason why we had to do above, I see microsoft official explainaiton:
Windows Server 2016 and Windows 10 Anniversary Update (both version 14393) were the first Windows releases that could build and run Windows Server containers. Containers built using these versions can run on newer releases such as Windows Server version 1709, but there are a few things you need to know before you start.
As we've been improving the Windows container features, we've had to make some changes that can affect compatibility. Older containers will run the same on newer hosts with Hyper-V isolation, and will use the same (older) kernel version. However, if you want to run a container based on a newer Windows build, it can only run on the newer host build.
From it, it seems, microsoft still in the process of improve windows container features, so if need to use container which based on newer windows, we had to upgrade host windows os(maybe also related to some hyper-v upgrade I guess).

What is the difference between docker.exe and dockercli.exe on Docker Desktop for Windows?

I am learning about Docker and I have installed Docker for Windows. I am confused by having two command line programs, one is docker.exe (full path: C:\Program Files\Docker\Docker\Resources\bin\docker.exe) and other is DockerCli.exe (full path: c:\Program Files\Docker\Docker\DockerCli.exe)
Why is there two command line interfaces for Docker? Additionally, there are multiple "version" commands I can invoke.
When I run docker version I get following output:
c:\Program Files\Docker\Docker>docker version
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:31 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:13:06 2019
OS/Arch: linux/amd64
Experimental: false
Which is different than when I run docker -v:
c:\Program Files\Docker\Docker>docker -v
Docker version 18.09.2, build 6247962
Finally, when I run dockercli -Version I get:
c:\Program Files\Docker\Docker>DockerCli.exe -Version
Docker Desktop
Version: 2.0.0.3 (31259)
Channel: stable
Sha1: 8858db33c8692b69de9987a5d672798d778735b2
OS Name: Windows 10 Pro
Windows Edition: Professional
Windows Build Number: 16299
Why are there several "version" commands, all with different output?
See next diagram:
Docker project has upstream project, also downstream product. Anyone or company could develop his own product based on the core parts.
So microsoft together with docker company develop their downstream product on windows 10 called docker for windows, it will use docker ce as core part.
Then, in short:
docker.exe: the docker client provided for user to communicate with docker engine. You can use it to do docker pull, docker run etc docker actions.
dockercli.exe: the tool provided by docker for windows for user to communicate with docker for windows. You can use it to switch to linux-container-mode/windows-container-mode etc.
Additional:
docker -v shows the core part that's Docker CE's version while dockercli.exe -Version shows the docker for windows's version.

Unable to copy to Windows container ('docker cp') on Windows 10

I set up Docker for Windows on my laptop and switched from Linux Containers to Windows Containers in Docker's settings (which prompted a couple of restarts and Windows updates). I pulled an image and ran a container based on it using the commands:
docker pull microsoft/dotnet-framework
docker run -it microsoft/dotnet-framework cmd
In a second terminal window, I executed the command:
docker cp app container_id:/
and received this error message:
Error response from daemon: filesystem operations against a running Hyper-V container are not supported
I googled this error, but nothing (explanatory) came up, quite surprisingly. Is there a way I can run the image as a Windows container rather than a Hyper-V container, on Windows 10?
Ultimately, I will deploy this container to a Windows Server 2016 host, but I need to do all development and testing in my laptop running Windows 10 Pro.
Docker Version
Client:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:30:30 2017
OS/Arch: windows/amd64
Server:
Version: 17.06.0-ce
API version: 1.30 (minimum version 1.24)
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 22:19:00 2017
OS/Arch: windows/amd64
Experimental: true
Based on a comment by #GregorySuvalian, I understand that Windows 10 allows Hyper-V runtime only. So my workaround is to stop the container, running the docker cp command and restart the container. (I preferred this over setting up a volume, since it is just a one time operation.)
Edit to Vimes answer as I had a difficult time to use the --mount within my docker run commmand. The actual run command needs to be within the quotes '' starting from type...
--mount 'type=bind,source="c:/host/folder/path/with/forward/slashes",target="C:/container/folder/path/with/forward/slashes"'

missing stack command Docker

If I use: docker stack deploy -c docker-compose.yml getstartedlab I get the error:docker: 'stack' is not a docker command.
If I run docker --help there really isn't a command like this:
rmi Remove one or more images
run Run a command in a new container
save Save one or more images to a tar archive (streamed to STDOUT by default)
search Search the Docker Hub for images
service Manage Docker services
start Start one or more stopped containers
stats Display a live stream of container(s) resource usage statistics
stop Stop one or more running containers
swarm Manage Docker Swarm
tag Tag an image into a repository
Did they change the way to do this? I'm just following the turorial of there site (link to tutorial)
My docker version is:
Version: 1.12.6
API version: 1.24
Go version: go1.6.3
Git commit: 78d1802
Built: Tue Jan 31 23:47:34 2017
OS/Arch: linux/amd64
The docker stack command was introduced in the version 1.13.
As you can see in the prerequisites of the tutorial they said:
"Install Docker version 1.13 or higher"
All you need to do is upgrade the docker version from 1.12 to 1.13

Resources