La tasko estis simpla, instali Docker sur mia labortekkomputilo kun Vindozo, kiu jam havas zoon. Mi instalis Docker Desktop, kreis ujojn, ĉio estis en ordo, sed mi rapide malkovris, ke VMWare Workstation ĉesis lanĉi virtualajn maŝinojn kun la eraro:
VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard.
La laboro ĉesis, necesas urĝe ripari ĝin
Guglinte, oni trovis, ke ĉi tiu eraro okazas pro la nekongrueco de VMWare Workstation kaj Hyper-V sur la sama maŝino. La problemo estas konata kaj ekzistas oficiala VMWare-solvo tia , kun ligilo al la scibazo de Microsoft . La solvo estas malŝalti Defender Credential Guard (la punkto 4 de la sekcio Malŝalti Windows Defender Credential Guard helpis min):
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: /dPost rekomenco, Vindozo demandos vin ĉu malŝalti Defender Credential Guard. Jes! Tiel VMWare Workstation revenos al normala funkciado kaj ni estos en la sama loko kiel antaŭ ol instali docker.
Mi ankoraŭ ne trovis solvon por akordigi Hyper-V kaj VMWare Workstation, mi esperas, ke ili amikiĝos en novaj versioj.
Alimaniere
Mi jam delonge estas ligita al VMWare Workstation por diversaj celoj, provis ŝanĝi al Hyper-V kaj VirtualBox, sed la funkcieco ne kontentigis miajn bezonojn, kaj mi ankoraŭ restas tie ĝis hodiaŭ. Evidentiĝis, ke ekzistas solvo pri kiel kombini VMWare, Docker kaj VSCode en unu labormedio.
— permesas al vi ruli Docker Engine sur virtuala gastiganto kaj konekti al ĝi kaj malproksime kaj loke. Kaj ekzistas VMWare Workstation kongrua pelilo por ĝi,
Mi ne precipe rerakontos la instalinstrukciojn, nur la liston de ingrediencoj:
- ( inkluzivita)
- docker labortablo
Jes, Docker Desktop, bedaŭrinde, ankaŭ estos bezonata. Se vi malkonstruis ĝin, tiam instalu ĝin denove, sed ĉi-foje forigante la markobutonon pri fari ŝanĝojn al la OS, por ne rompi VMWare Workstation denove.
Mi ŝatus noti tuj, ke ĉio funkcias bone de simpla uzanto, la instalprogramoj petos eskaladon de rajtoj kiam ili bezonos ĝin, sed ĉiuj komandoj sur la komandlinio kaj skriptoj estas ekzekutitaj de la nuna uzanto.
Kiel rezulto, la komando:
$ docker-machine create --driver=vmwareworkstation devdev virtuala maŝino estos kreita de Boot2Docker, en kiu Docker estos instalita.
Ĉi tiu virtuala maŝino povas esti kunligita al la grafika interfaco de VMWare Workstation malfermante la respondan vmx-dosieron. Sed ĉi tio ne estas necesa, ĉar VSCode nun devos esti lanĉita de PowerShell kiel skripto (ial docker-machine kaj docker-machine-driver-vmwareworkstation finiĝis en la bin dosierujo):
cd ~/bin
./docker-machine env dev | Invoke-Expression
codeVSCode malfermos por labori kun la kodo sur la loka maŝino kaj Docker en la virtuala maŝino. Konekti permesas vin oportune administri ujojn en virtuala maŝino sen eniri la konzolon.
Malfacilaĵoj:
Dum la kreado de docker-machine, mia procezo frostiĝis:
Waiting for SSH to be available...
Kaj post iom da tempo ĝi finiĝis per pliaj provoj establi ligon kun la virtuala maŝino.
Ĉio temas pri atestpolitiko. Kreante virtualan maŝinon, vi havos dosierujon ~.dockermachinemachinesdev.En ĉi tiu dosierujo estos atestildosieroj por konekti per SSH: id_rsa, id_rsa.pub. OpenSSH eble rifuzas uzi ilin ĉar ĝi pensas, ke ili havas problemojn pri permesoj. Nur docker-machine diros al vi nenion pri tio, ĝi simple rekonektos ĝis ĝi enuiĝos.
solvo: Tuj kiam komenciĝos la kreado de nova virtuala maŝino, iru al la dosierujo ~.dockermachinemachinesdev kaj ŝanĝu la rajtojn al la specifitaj dosieroj, unuope.
La posedanto de la dosiero devas esti la nuna uzanto, nur la nuna uzanto kaj SISTEMO havas plenan aliron, ĉiuj aliaj uzantoj, inkluzive de la grupo de administrantoj kaj la administrantoj mem, devas esti forigitaj.
Povas ankaŭ esti problemoj pri konvertado de absolutaj vojoj de Vindoza formato al Posix, kaj kun ligaj volumoj enhavantaj simbolan ligon. Sed tio estas alia historio.
fonto: www.habr.com