Docker i VMWare Workstation na jednym komputerze z systemem Windows

Zadanie było proste, zainstalować Docker na swoim laptopie z Windows, na którym i tak już panowała bałagan. Zainstalowałem Docker Desktop, stworzyłem kontenery, wszystko w porządku, tylko szybko odkryłem, że VMWare Workstation przestało uruchamiać wirtualne maszyny z błędem:

VMware Workstation i Device/Credential Guard są ze sobą niekompatybilne. VMware Workstation można uruchomić po wyłączeniu Device/Credential Guard.

Praca stanęła, muszę szybko naprawić

Metodą googlenia udało się ustalić, że ten błąd wynika z niezgodności VMWare Workstation i Hyper-V na jednym komputerze. Problem jest znany, a VMware ma oficjalne rozwiązanie, jak to naprawić, z odniesieniem do bazy wiedzy Microsoftu Zarządzaj Windows Defender Credential Guard. Rozwiązanie sprowadza się do wyłączenia Defender Credential Guard (pomógł mi punkt 4 sekcji Wyłącz Windows Defender Credential Guard):

mountvol X: /s
copy %WINDIR%System32SecConfig.efi X:EFIMicrosoftBootSecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "EFIMicrosoftBootSecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

Po ponownym uruchomieniu Windows zapyta, czy naprawdę chcesz wyłączyć Defender Credential Guard. Tak! Dzięki temu VMWare Workstation wróci do normalnej pracy, a my znajdziemy się w tym samym miejscu, co przed instalacją Dockera.

Nie znalazłem rozwiązania, jak pogodzić Hyper-V i VMWare Workstation, mam nadzieję, że w nowych wersjach będą współpracować.

Inna droga

Już od dawna korzystam z VMWare Workstation do różnych celów, próbowałem przejść na Hyper-V i VirtualBox, ale funkcjonalność nie spełniła moich wymagań, więc wciąż używam tego samego. Okazało się, że istnieje sposób na zintegrowanie VMWare, Dockera i VSCode w jednym środowisku roboczym.

Docker Machine — pozwala uruchamiać Docker Engine na wirtualnym hoście i łączyć się z nim zarówno zdalnie, jak i lokalnie. Dla niego istnieje sterownik zgodności z VMWare Workstation, link do GitHuba

Nie będę powtarzać instrukcji instalacji, tylko wypiszę składniki:

1. Docker Toolbox (Docker Machine w zestawie)
2. Docker Machine VMware Workstation Driver
3. Docker Desktop

Tak, Docker Desktop, niestety, również będzie potrzebny. Jeśli go usunięto, to instalujemy ponownie, ale tym razem odznaczając pole wyboru dotyczące wprowadzania zmian w systemie, aby ponownie nie zepsuć VMWare Workstation.

Od razu chcę zauważyć, że wszystko działa doskonale z konta zwykłego użytkownika, instalatory poproszą o eskalację uprawnień, gdy będą tego potrzebowały, ale wszystkie polecenia w wierszu poleceń i skrypty są wykonywane z bieżącego użytkownika.

W rezultacie polecenie:

$ docker-machine create --driver=vmwareworkstation dev

Z Boot2Docker zostanie utworzona wirtualna maszyna dev, w której będzie Docker.

Tę wirtualną maszynę można podłączyć do graficznego interfejsu VMWare Workstation, otwierając odpowiedni plik vmx. Nie jest to jednak konieczne, ponieważ VSCode będzie teraz wymagać uruchomienia skryptu PowerShell (jakimś cudem docker-machine i docker-machine-driver-vmwareworkstation znalazły się w katalogu bin):

cd ~/bin
./docker-machine env dev | Invoke-Expression
code

Otworzy się VSCode do pracy z kodem na lokalnej maszynie i Dockerem w wirtualnej maszynie. Wtyczka Docker for Visual Studio Code pozwala wygodnie zarządzać kontenerami w wirtualnej maszynie bez zaglądania do konsoli.

Trudności:

Podczas tworzenia docker-machine proces u mnie się zawiesił:

Waiting for SSH to be available...

I po pewnym czasie zakończył się z przekroczeniem prób nawiązania połączenia z wirtualną maszyną.

Cała sprawa dotyczy polityki certyfikatów. Przy tworzeniu wirtualnej maszyny pojawi się katalog ~/.dockermachinemachinesdev, w którym będą pliki certyfikatów do połączeń SSH: id_rsa, id_rsa.pub. OpenSSH może odmawiać ich użycia, ponieważ uważa, że mają problemy z prawami dostępu. Tylko docker-machine nic o tym nie powie, po prostu będzie próbować się ponownie połączyć, aż się znudzi.

Rozwiązanie: Gdy tylko zacznie się tworzenie nowej wirtualnej maszyny, wchodzimy do katalogu ~/.dockermachinemachinesdev i zmieniamy prawa dostępu do wskazanych plików, jeden po drugim.

Właścicielem pliku powinien być bieżący użytkownik, a pełne prawa powinny mieć tylko bieżący użytkownik i SYSTEM; wszystkich pozostałych użytkowników, w tym grupę administratorów i samych administratorów, należy usunąć.

Mogą także wystąpić problemy z konwersją absolutnych ścieżek z formatu Windows na Posix oraz z powiązaniem wolumenów zawierających linki symboliczne. Ale to już inna historia.

Źródło: habr.com