You can still use docker desktop but you are on windows 17763

I have a fairly clean machine, its an AWS Workspace so I have no control over installing windows updates. I want to use the AWS SDK and SAM CLI which requires Docker, so i installed Docker and upon installation got this error message:

Windows 17763 is deprecated
you an still use Docker Desktop but you are on Windows 17732.
You will not be able to install further major updates (3.6.0 and above).

I rebooted the machine and opened Docker, it said «Starting Docker», then said Docker I Closed…

When I click on the settings button it hangs. even tho this is a new install, I checked the option to restore factory defaults with no success.

I looked for download for older versions of docker but didn’t see any links.

• [x ] I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• i dont know where these are. if in settings, i have no access to them
• [x ] I have uploaded Diagnostics
• Diagnostics ID: E5E8F9C8-E78D-4167-B20C-00A767DD0F60/20220721144100

Actual behavior

see above

Expected behavior

start docker

Information

• Windows Version:17732
• Docker Desktop Version: ? downloaded yesterday, what ever that is
• WSL2 or Hyper-V backend? What ever AWS Workspaces is
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: What ever AWS Workspaces is

Output of & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check

not sure what u r looking for here:
self-diagnose.json
self-diagnose.txt
self-diagnose.log
these are huge files, 102 mb, 29 mb and 42 mb.
can I zip and attach them somewhere?

Steps to reproduce the behavior

See original description above. has all details

1. …
2. …

Docker is deprecated — и как теперь быть?

Kubernetes объявил Docker устаревшим и планирует прекратить его использование примерно через год, в версии 1.22 или 1.23. Эта новость вызвала много вопросов и непонимания. В блоге Kubernetes появилось целых две статьи, разъясняющих смысл записи в Changelog (раз и два). Если все обобщить, то для разработчиков (те, которые Dev) ничего не меняется — они все так же могут продолжать использовать docker build для сборки своих контейнеров, а вот для инженеров, ответственных за эксплуатацию кластера (Ops), пришла пора разобраться и освоить несколько новых инструментов.

Но для начала давайте вернемся в 2016 год, когда Kubernetes представил Container Runtime Interface (CRI). До версии Kubernetes 1.3 kubelet умел работать только с Docker, а в 1.3 анонсировали поддержку rkt Container Engine (этот проект уже прекратил свое существование). При этом код, отвечающий за взаимодействие с Docker и rkt, был глубоко и широко интегрирован в исходники kubelet. Процесс добавления поддержки rkt показал, что для добавления новых container runtime необходимо хорошо разбираться в устройстве и алгоритмах работы kubelet, а результат получился очень сложным для поддержки и развития.

Поэтому решили все упростить, и добавили новую абстракцию — Container Runtime Interface. Весь код, реализующий высокоуровневый интерфейс работы с Docker, был убран из kubelet, а вместо него kubelet стал использовать CRI. Но тут возникла небольшая проблемка — Docker не умеет в CRI. Чтобы ее решить, в Kubernetes написали программу-прокладку между kubelet и Docker. С одной стороны она принимает запросы от kubelet через CRI, а с другой — транслирует их в docker-демон.

И назвали эту программу dockershim, и вот как раз ее и хотят убрать к версии 1.23.

Возвращаемся назад, в конец 2020 года, и смотрим чего у нас новенького по сравнению с 2016 в плане развития Container Runtime Interface.

Проект rkt закрыт.

RedHat создали и всячески продвигают свой собственный движок для запуска контейнеров CRI-O.

Монолитный Docker разделили на containerd, dockerd и docker-cli.

В итоге у нас сейчас есть два движка для запуска контейнеров, которые умеют в CRI — это containerd и cri-o. Естественно, все эти события произошли не прямо в 2020 году, но массовый интерес к ним возник именно после объявления Kubernetes о прекращении поддержки Docker.

Сборка

Давайте же разберемся, чем нам это грозит. Начнем с наиболее частого вопроса: «Как же собирать образ контейнера с помощью containerd или cri-o?»

И ответ очень простой: «Никак». Потому что containerd и cri-o предназначены только для запуска контейнеров из готовых образов. Плюс они умеют еще несколько вещей, необходимых для эксплуатации:

загрузка образов из интернета;

просмотр информации о запущенных подах и контейнерах;

удаление образов, подов и контейнеров;

подключение внутрь контейнера (запуск внутри контейнера процесса с bash).

Но они не умеют ни собирать новый образ, ни пушить его в какой-либо registry. И как теперь быть?

Начнем с того, что в 2015 году «Docker и остальные лидеры индустрии контейнеризации» основали Open Container Initiative (OCI) и опубликовали в ее рамках спецификацию формата хранения образов контейнеров. Эту спецификацию поддерживают Docker, containerd и cri-o, так что образ, собранный с помощью docker build на машине разработчика, должен без проблем запуститься с помощью containerd или cri-o. И так и происходит в подавляющем большинстве случаев, но время от времени попадаются «нюансы реализации». Эти нюансы, конечно, исправляются, но иногда не так быстро, как хотелось бы.

Если вы за стабильность и минимальные изменения — запускайте новые кластеры с containerd в качестве движка контейнеризации. А на машинах разработчиков и CI runners сборки смело оставляйте Docker.

Если вы выбрали безопасность из коробки, кровавый enterpise и платную поддержку, то наверняка используете Openshift (платформа на базе Kubernetes), в котором для запуска контейнеров применяется cri-o. А для сборки образов RedHat создала отдельную утилиту, которую назвала buildah. В отличие от Docker, этой утилите для сборки образов не нужен запущенный движок контейнеризации.

Из альтернатив можно еще посоветовать kaniko — утилиту для сборки образов от Google. Она поставляется в виде образа контейнера, так что для запуска ей нужен движок контейнеризации, но для сборки — уже нет.

Эксплуатация

Фундаментальная проблема тут в том, что Docker изначально ориентировался на взаимодействие с человеком, и к последним версиям у него появился очень классный и удобный консольный интерфейс, а вот компоненты, реализующие CRI — они by design ориентированы на взаимодействие с программой-оркестратором, а не с человеком.

Но внезапно оказалось, что человек тоже хочет взаимодействовать с CRI, и для этого была написана отдельная утилита crictl, которая представляет собой CLI-консоль к CRI-движку. То есть одна и та же утилита crictl позволяет посмотреть список контейнеров запущенных с помощью containerd или cri-o.

С другой стороны надо помнить, что CRI был придуман командой разработки Kubernetes и для Kubernetes, и поэтому, на мой взгляд, правильнее было бы его назвать Pod Runtime Interface.

И crictl оптимизирован для работы с контейнерами, созданными kubelet. Например, в выводе не показываются служебные PODSandbox контейнеры, а имена контейнеров показываются в более понятном виде, чем в Docker. Да и возможности по работе с CLI постоянно улучшаются.

Еще одна вещь, с которой часто возникают проблемы понимания. Многие путают docker (бинарник из пакета docker-cli) и dockerd (демон, управляющий контейнерами). Пытаются сделать crictl image save/load и внезапно оказывается, что в crictl таких команд нет. А на созданный issue авторы устало отвечают, что crictl — консоль для CRI runtime, который должен только запускать контейнеры, ну еще образ скачать из registry. А про манипуляции с образами в спецификации ничего нет.

Но выход есть! Для манипуляции с образами контейнеров можно воспользоваться дополнительной утилитой skopeo, если вы используете cri-o, или утилитой ctr из комплекта containerd.

И в завершение дам ответ на идею, которая наверняка возникнет после прочтения этой статьи:

«Подождите, но ведь есть containerd, с которым умеет работать kubelet и dockerd! Давайте поставим Docker (три пакета docker-cli, docker, containerd), kubelet настроим на работу с containerd напрямую, и у нас при этом останется старая добрая команда docker ».

Docker for Windows 3.x release notes

Estimated reading time: 26 minutes

This page contains release notes for Docker Desktop for Windows 3.x.

Update to the Docker Desktop terms

This page contains information about the new features, improvements, known issues, and bug fixes in Docker Desktop releases.

Docker Desktop 3.6.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.5.2

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Dev Environments Preview: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members’ machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see Development Environments Preview.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.5.1

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Dev Environments Preview: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members’ machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see Development Environments Preview.

Bug fixes and minor changes

Docker Desktop 3.5.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Dev Environments Preview: Dev Environments enable you to seamlessly collaborate with your team members without moving between Git branches to get your code onto your team members’ machines. When using Dev Environments, you can share your in-progress work with your team members in just one click, and without having to deal with any merge conflicts. For more information and for instructions on how to use Dev Environments, see Development Environments Preview.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.4.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Volume Management: Docker Desktop users can now create and delete volumes using the Docker Dashboard and also see which volumes are being used. For more information, see Explore volumes.

Skip Docker Desktop updates: All users can now skip an update when they are prompted to install individual Docker Desktop releases. For more information, see Docker Desktop updates.

Deprecation

Upgrades

Bug fixes and minor changes

Docker Desktop 3.3.3

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.3.2

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.3.1

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Bug fixes and minor changes

Docker Desktop 3.3.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

You can now specify when to download and install a Docker Desktop update. When an update becomes available, Docker Desktop displays an icon to indicate the availability of a newer version. You can download the update in the background whenever convenient. When the download is complete, all you need to do is to click Update and restart to install the latest update.

Developers who use Docker Desktop for professional development purposes may at times need to skip a specific update. For this reason, users with a paid Docker subscription can skip notifications for a particular update when a reminder appears.

For developers in IT managed environments, who don’t have administrative access to install updates to Docker Desktop, there is now an option in the Settings menu to opt out of notifications altogether for Docker Desktop updates if your Docker ID is part of a Team subscription.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.2.2

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Bug fixes and minor changes

Docker Desktop 3.2.1

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Docker Desktop 3.2.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Deprecation

Bug fixes and minor changes

Docker Desktop 3.1.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.0.4

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Upgrades

Bug fixes and minor changes

Docker Desktop 3.0.0

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected. By downloading Docker Desktop, you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

First version of docker compose (as an alternative to the existing docker-compose ). Supports some basic commands but not the complete functionality of docker-compose yet.

Supports basic volumes, bind mounts, networks, and environment variables

Let us know your feedback by creating an issue in the compose-cli GitHub repository.

Upgrades

Bug fixes and minor changes

Known issues

Download Docker Desktop

We’ve updated the Docker Subscription Service Agreement. Please read the announcement and FAQs to learn how companies using Docker Desktop may be affected.

By clicking «Accept and Download», you agree to these updated terms, the Docker Data Processing Agreement, and the Data Privacy Policy.

Message «Docker for Windows doesn’t Support your Windows version» but it did yesterday and nothing changed #4482

Comments

ShawnDigital commented Aug 9, 2019 •

Expected behavior

Docker for Windows Starts

Actual behavior

Docker for windows says my OS isn’t supported

Information

From log see two things of note.

‘[Error ] Unable to send engine/start: Docker doesn’t support your Windows version. Check documentation for minimum requirements
[11:02:03.670][Installer ][Error ] Feature(s) not available: Hyper-V, Containers

Which it is and I reinstalled it even. but then I see.

The specified module ‘Hyper-V’ was not loaded because no valid module file was found in any module directory..

In the diagnostics I saw.

time=»2019-08-09T10:59:42-05:00″ level=warning msg=»exec: «powershell»: executable file not found in %PATH%» type=directorylist

Which I don’t use powershell.exe and «Powershell for Windows 2.0» is not enabled in «windows features» dialog for apps & programs. I do use PowershellCore (pwsh.exe) but this is not new or has changed as far as I know. Automatic Windows Updates are disabled at work so it shouldn’t have updated anything. I did run them just now to see if it would help and it did not.

I.T. could have pushed something but I see no evidence they did.

Is Powershell required for docker? It doesn’t mention it anywhere I saw`

The text was updated successfully, but these errors were encountered:

Kubernetes Docker Deprecated Wait, Docker is deprecated in Kubernetes now? What do I do?

For developers

Don’t panic, Docker containers and images are still alive. It’s not that it will change everything.

Also worth reading:

For K8s admins

Read this carefully and start considering Docker alternatives

Is it true?

Yes, it is true. Docker is now deprecated in Kubernetes.

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called «dockershim» which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

In short, what it means here is that Docker does not support Kubernetes Runtime API called CRI(Container Runtime Interface) and Kubernetes people have been using a bridge service called «dockershim». It converts Docker API and CRI, but it will no longer be provided from Kubernetes side within a few minor releases.

Docker in local is a very powerful tool to create dev environment for sure, but in order to understand what’s causing this, you need to understand what Docker does in the current Kubernetes architecture.

Kubernetes is an infra orchestration tool that groups up many different compute resources such as virtual/physical machines and make it look like a huge compute resource for your application to run and share with others. In this architecture, Docker, or a container runtime, is used only to run those applications in an actual host by being scheduled by Kubernetes control plane.

Look at the architecture diagram. You can see that each Kubernetes node talks to the control plane. kubelet on each node fetch metadata and it execs CRI to run create/delete containers on the node.

But why is Docker deprecated?

Again, Kubernetes only talks in CRI and talking to Docker requires a bridge service. So that’s reason 1.

To explain the next reason, we have to see the Docker architecture a bit. Here’s the diagram.

So yeah, Kubernetes actually needs inside of the red area. Docker Network and Volume are not used in Kubernetes.

Having more features while you never use, itself can be a security risk. The less features you have, the smaller the attack surface becomes.

So this is where you start considering alternatives. It’s called CRI runtimes.

CRI runtimes

There are two major CRI runtime implementations.

containerd

If you just want to migrate from Docker, this is the best option as containerd is actually used inside of Docker to do all the «runtime» jobs as you can see in the diagram above. They provides CRI and it’s 100% what Docker provides, too.

containerd is 100% open source so you can see docs on GitHub and even contribute to it too.

CRI-O is a CRI runtime mainly developed by Red Hat folks. In fact, this runtime is used in Red Hat OpenShift now. Yes, they do not depend on Docker anymore.

Interestingly, RHEL 7 does not officially support Docker either. Instead, they provide Podman, Buildah and CRI-O for container environment.

CRI-O’s strength in my opinion is its minimalism because it was created to be a «CRI» runtime. While containerd started as a part of Docker trying to be more open source, they are pure CRI runtime so CRI-O does not have anything that CRI does not require.

It can be more challenging to migrate from Docker to CRI-O because of that, it still provides what you needs to run applications on Kubernetes.

One more thing.

When we talk about Container Runtimes, we need to be careful which type of runtime you’re talking about. We do have two types of runtimes; CRI runtimes and OCI runtimes.

CRI runtimes

As I described, CRI is an API that Kubernetes provides to talk to a container runtime in order to create/delete containerised applications.

They talk in gRPC via IPC as kubelet and the runtime runs on the same host, and a CRI runtime has responsibility for getting request from kubelet and execute OCI container runtime to run a container. Wait, what? Maybe I should explain with a diagram for this one.

So what a CRI runtime does is the following

OCI runtimes

appendix1: how runC works

runC spawns containers after CRI executes the binary by calling Linux system calls. That indicates runC relies on the kernel that is running on your Linux machine.

It also implies that if you ever discover runC’s vulnerability that makes you take the root privilege of your host, a containerized application can also do so. A bad hacker could take your host machine’s root and boom! Things surely will get bad. This is one of the reasons why you should keep updating your Docker(or any other container runtimes) too, not just your containerized application.

appendix2: how gVisor works

gVisor is an OCI runtime that were originally created by Google folks. It actually runs on their infrastructure to run their Cloud services such as Google Cloud Run, Google App Engine(2nd gen), and Google Cloud Functions(and even more!)

What’s interesting here is that gVisor has a «guest kernel» layer which means a containerised applications cannot directly touch to the host kernel layer. Even if they think they do, they only touch the gVisor’s guest kernel.

gVisor’s security model is actually very interesting and worth reading the official doc.

Notable differences from runC is as follows.

Conclusion

1. Docker is surely deprecated but only in Kubernetes, so if you’re a K8s admin, you should start thinking to adopt a CRI runtime such as containerd and CRI-O.

a. containerd is Docker compatible where the core components are the same.
b. CRI-O can be a strong option where you want more minimal functionality for Kubernetes

2. Know what the difference of CRI and OCI runtime responsibility and scope

Depending on your workload, runC might not be always the best option to use!

Issue with Docker linux containers on Windows 2019

I am facing issue while pulling Sitespeed image in Docker running on Windows Server 2019, this however works fine while using Docker Desktop on Windows 10.

PS C:Sitespeed> docker info Client: Context: default Debug Mode: false Plugins: app: Docker Application (Docker Inc., v0.8.0) cluster: Manage Mirantis Container Cloud clusters (Mirantis Inc., v1.9.0) registry: Manage Docker registries (Docker Inc., 0.1.0)

Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 20.10.7 Storage Driver: windowsfilter (windows) lcow (linux) Windows: LCOW: Logging Driver: json-file Plugins: Volume: local Network: ics internal l2bridge l2tunnel nat null overlay private transparent Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog Swarm: inactive Default Isolation: process Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434) Operating System: Windows Server 2019 Standard Version 1809 (OS Build 17763.1911) OSType: windows Architecture: x86_64 CPUs: 8 Total Memory: 48GiB Name: TITAN-201 ID: 4H6Y:QSND:DBPU:5BOG:WWO3:2QQS:HD54:BLYH:3SDD:FTXH:56OL:RN2F Docker Root Dir: C:ProgramDatadocker Debug Mode: false Registry: https://index.docker.io/v1/ Labels: Experimental: true Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false

PS C:Sitespeed> docker pull sitespeedio/sitespeed.io Using default tag: latest latest: Pulling from sitespeedio/sitespeed.io 7b1a6ab2e44d: Pull complete bcb4974c0deb: Pull complete 77a421e32a02: Pull complete 8bd632b8efc3: Pull complete 942355027341: Pull complete 1e27cb521d29: Pull complete a3ed95caeb02: Pull complete cf72937d856a: Pull complete 681fa6bf53a9: Pull complete c817bdd68a11: Pull complete 2fecef929f71: Pull complete 134027b45827: Pull complete 7389adaf2698: Pull complete e8b6fefb903a: Pull complete ae6f57572e5d: Pull complete ea4212fcc5d6: Pull complete 9a149b9510ab: Download complete 81758f1fd3c7: Download complete 28531e33d129: Download complete f13785a12256: Download complete 2bc054a28005: Download complete b01ed0ff33fc: Download complete 21209f5f8994: Download complete 8f4a91166a41: Download complete e27bb1f1deec: Download complete failed to register layer: re-exec error: failed to start service utility VM (diffgetter b4bbd55cc342d8d45b2870bbc0dd227d6b9f9f0e70379b7c08a458e794fbdb42): hcsshim::CreateComputeSystem b4bbd55cc342d8d45b2870bbc0dd227d6b9f9f0e70379b7c08a458e794fbdb42_svm: The virtual machine could not be started because a required feature is not installed.: stderr:

Источники информации:

• http://docs.docker.com/desktop/previous-versions/3.x-windows/
• http://github.com/docker/for-win/issues/4482
• http://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
• http://stackoverflow.com/questions/70299217/issue-with-docker-linux-containers-on-windows-2019

Docker is a platform for creating and deploying applications in self-sufficient containers. The installation of Docker is pretty easy in Linux, but this is usually not the case with Windows. In this post, I will show you how to install Docker in Windows 10 or Windows 11 in multiple ways. You’ll learn there is indeed a way that makes the Docker Desktop installation in Windows as simple as in Linux.

Prerequisites

You might already be aware that Docker relies on virtualization technology. On Windows, Docker can use either the Windows Subsystem for Linux (WSL) 2 or Hyper-V as a backend.

Docker with WSL2 backend

The current version of Docker Desktop only works on the 64-bit edition of Windows, whether you’re running Windows 10 or Windows 11. To run Docker with the WSL2 backend, your system must meet the following prerequisites:

• Windows 10: Home/Pro 21H1 (build 19043) or higher, or Enterprise/Education 20H2 (build 19042) or higher
• Windows 11: Home/Pro version 21H2 or higher, or Enterprise/Education version 21H2 or higher
• WSL2 feature enabled
• Linux kernel update package for WSL2
• For WSL2, the following are the hardware requirements:
  • 64-bit CPU with second-level address translation (SLAT)
  • Hardware virtualization support, which must be enabled in BIOS/UEFI
  • 4 GB RAM

Docker with Hyper-V backend

To be able to run Docker with a Hyper-V backend and Windows containers, your system must meet the following prerequisites:

• Windows 10: Pro 21H1 (build 19043) or higher, or Enterprise/Education 20H2 (build 19042) or higher
• Windows 11: Pro/Enterprise/Education version 21H2 or higher
• Optional Windows features for Hyper-V and Containers must be enabled

  

  Enable Hyper V and Containers windows features for Docker

For Hyper-V, following are the hardware requirements:

• 64-bit CPU with second-level address translation (SLAT)
• Hardware virtualization support, which must be enabled in BIOS/UEFI
• 4 GB RAM

In addition to the aforementioned requirements, if you want to run Docker in a Hyper-V guest VM, you need to enable nested virtualization by running this PowerShell command on the Hyper-V host:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $True

Make sure your VM is powered off before running this command. Without nested virtualization support, Docker will not work in a VM, and you will receive the error message shown below.

Install Docker using the GUI

To install Docker Desktop in Windows using the GUI, follow these steps:

Download Docker Desktop. You will see a configuration screen, as shown in the screenshot:

To use Docker with the WSL 2 backend, check the box that says Use WSL 2 instead of Hyper-V (recommended). If you want to use Hyper-V instead, uncheck this option and click OK.

When the installation is complete, click the Close and Restart button to restart your computer.

After restarting, you will be able to run Docker Desktop using either a shortcut or a command prompt. If you did not install WSL 2 before installing Docker, you will receive the WSL 2 installation is incomplete error when you try to start Docker.

To fix this error, run the wsl —update command in an elevated PowerShell console, and restart your computer.

Install Docker using winget

Winget is a command-line package manager for modern versions of Windows, which works just like apt or DNF in Linux. If you have a little experience with package installation in Linux, you probably know that you usually just have to type a command and the package is ready for use. Well, winget does the exact same thing in Windows. All you need is Windows 10 1809 (build 17763) or Windows 11. To install Docker in Windows using winget, follow these steps:

Launch an elevated command prompt or PowerShell console, and type the following command:

winget install --exact --id Docker.DockerDesktop --accept-source-agreements --accept-package-agreements

The —exact (or -e in short) parameter tells winget to find the package using an exact match. The installation can take a while, but it is pretty much automatic, so there is nothing you need to do but wait.

When the command is finished, open a new command prompt (or PowerShell console) and run the docker —version command.

If you try to run docker —version in the same command prompt, you will likely see The term ‘docker’ is not recognized as the name of a cmdlet, function, script file, or operable program error, as shown in the screenshot.

This error occurs because your current command session (cmd or PowerShell) is still using the old environment variables. To be able to recognize the newly added Docker variable, you must reload the environment variables. Launching a new command session is the easiest way to load new variables.

Install Docker using PowerShell

To install Docker Desktop using PowerShell, follow these steps:

Download Docker Desktop.

Once the installer package is downloaded, open an elevated PowerShell console or Windows Terminal, and type the following command to start Docker installation:

Start-Process "D:\Docker Desktop Installer.exe" -Wait -NoNewWindow "install --quiet --accept-license"

Make sure you adjust the installer path. The -Wait parameter causes the Start-Process cmdlet to wait for the new process to finish, and the -NoNewWindow parameter prevents the new process from opening in a new window. The —quiet switch is offered by Docker’s install command and suppresses the installation information. To see the information, skip this switch. Since we are using PowerShell, notice how —quiet and other flags are enclosed in quotes along with the install command—this is very important to avoid errors. By default, Docker will use the WSL 2 backend, but you could include the —backend=hyper-v flag to use the Hyper-V backend instead.

Once the above command is finished, you will see a shortcut for Docker Desktop on your desktop. Double-click the shortcut to launch Docker.

All of these installation methods are self-sufficient, so there is nothing additional you need to do. But you may still get an error message that says Docker Desktop – Access denied. You are not allowed to use Docker. You must be in the «docker-users» group.

If you get this error, run the following command in an elevated PowerShell console:

Add-LocalGroupMember -Group "docker-users" -Member $env:UserName -Verbose

Don’t forget to log off and log on again after running this command. If you want to delegate another user to run Docker Desktop, you can specify that username with the -Member parameter instead of $env:UserName.

Subscribe to 4sysops newsletter!

That was all for this guide. You just learned how to install Docker in Windows using the GUI, winget, and PowerShell. I am curious to know which method you prefer, and why.

Ask
questionsDocker Stopped on Windows Server 2019 Datacenter

docker/for-win

Answer
questions

docker-robott

useful!