Docker i VMWare Workstation na tym samym komputerze z systemem Windows

Zadanie było proste, umieścić Dockera na moim działającym laptopie z systemem Windows, który ma już zoo. Zainstalowałem Docker Desktop i utworzyłem kontenery, wszystko jest ok, ale szybko odkryłem, że VMWare Workstation przestało uruchamiać maszyny wirtualne z błędem:

VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard.

Prace zostały wstrzymane, konieczna jest pilna naprawa

Docker i VMWare Workstation na tym samym komputerze z systemem Windows

Po googlowaniu okazało się, że ten błąd występuje z powodu niezgodności VMWare Workstation i Hyper-V na tej samej maszynie. Problem jest znany i istnieje takie oficjalne rozwiązanie VMWare naprawić, z łączem do bazy wiedzy Microsoft Knowledge Base Zarządzaj ochroną poświadczeń Windows Defender. Rozwiązaniem jest wyłączenie funkcji Defender Credential Guard (punkt 4 w sekcji Wyłącz funkcję Windows Defender Credential Guard pomógł mi):

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 system Windows zapyta, czy naprawdę chcesz wyłączyć funkcję Defender Credential Guard. Tak! W ten sposób VMWare Workstation powróci do normalnego działania, 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 zaprzyjaźnią się w nowych wersjach.

Inny sposób

Od dawna jestem uzależniony od VMWare Workstation do różnych celów, próbowałem wysiąść na Hyper-V i VirtualBox, ale funkcjonalność nie spełniała moich zadań i tak siedzę do dziś. Okazało się, że istnieje rozwiązanie, jak zaprzyjaźnić się z VMWare, Docker i VSCode w jednym środowisku pracy.

Maszyna Docker - pozwala uruchomić Docker Engine na wirtualnym hoście i połączyć się z nim zarówno zdalnie, jak i lokalnie. I jest do tego sterownik kompatybilności z VMWare Workstation, link do githuba

Nie będę powtarzać instrukcji instalacji, tylko listę składników:

  1. Przybornik dokera (Maszyna Docker dołączony)
  2. Sterownik stacji roboczej Docker Machine VMware
  3. Pulpit Dockera

Tak, Docker Desktop niestety też będzie potrzebny. Jeśli go wyburzyłeś, zainstaluj go ponownie, ale tym razem usuwając pole wyboru dotyczące wprowadzania zmian w systemie operacyjnym, aby ponownie nie zepsuć VMWare Workstation.

Chcę od razu zauważyć, że wszystko działa dobrze od prostego użytkownika, programy instalacyjne będą prosić o eskalację uprawnień, kiedy będą tego potrzebować, ale wszystkie polecenia w wierszu poleceń i skrypty są wykonywane z bieżącego użytkownika.

W rezultacie zespół:

$ docker-machine create --driver=vmwareworkstation dev

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

Tę maszynę wirtualną można podłączyć do GUI VMWare Workstation, otwierając odpowiedni plik vmx. Ale nie jest to konieczne, ponieważ VSCode będzie teraz musiał uruchomić skrypt PowerShell (z jakiegoś powodu moja docker-machine i docker-machine-driver-vmwareworkstation wylądowały w folderze bin):

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

VSCode otworzy się do pracy z kodem na maszynie lokalnej i dokerem na maszynie wirtualnej. podłącz Docker dla Visual Studio Code pozwala na wygodne zarządzanie kontenerami w maszynie wirtualnej bez wchodzenia do konsoli.

Trudności:

W trakcie tworzenia docker-machine proces zawiesił się dla mnie:

Waiting for SSH to be available...

Docker i VMWare Workstation na tym samym komputerze z systemem Windows

I po chwili skończyło się nadmiarem prób nawiązania połączenia z maszyną wirtualną.

Wszystko zależy od polityki certyfikatów. Tworząc maszynę wirtualną będziesz miał katalog ~.dockermachinemachinesdev w tym katalogu będą znajdować się pliki certyfikatów do połączenia przez SSH: id_rsa, id_rsa.pub. OpenSSH może odmówić ich użycia, ponieważ uważa, że ​​mają problemy z uprawnieniami. Tylko docker-machine nic ci o tym nie powie, ale po prostu będzie się łączyć ponownie, aż się znudzi.

rozwiązanie: Gdy tylko rozpocznie się tworzenie nowej maszyny wirtualnej, przechodzimy do katalogu ~ .dockermachinemachinesdev i pojedynczo zmieniamy uprawnienia do określonych plików.

Plik musi należeć do bieżącego użytkownika, tylko bieżący użytkownik i SYSTEM mają pełny dostęp, wszyscy inni użytkownicy, w tym grupa administratorów i sami administratorzy, muszą zostać usunięci.

Mogą również wystąpić problemy z konwersją ścieżek bezwzględnych z formatu Windows do formatu Posix i wiązaniem woluminów zawierających dowiązania symboliczne. Ale to już inna historia.

Źródło: www.habr.com

Dodaj komentarz