Virenscanner verhindern Share Mapping bei Docker for Windows

Docker for Windows - kurz D4W - ist nun seit einigen Tagen zu haben; und es ist wunderbar! Es war schließlich auch aller hächste Zeit, dass auch Windows direkt - oder über Hyper-V - eine Plattform für die Docker-Entwicklung darstellt.

Wer jedoch mit Visual Studio eine ASP.NET Core Anwendung entwickeln möchte und dabei einen Virenscanner bzw. eine Sicherheitssuite im Einsatz hat, der dürfte bereits auf die ersten Probleme gestoßen sein. Für Visual Studio 2015 gibt es die Docker Tools for Visual Studio als Preview; diese ermöglicht das Scaffolding, also das automatische generieren von Templates für .NET Core Anwendungen.

Dabei werden vier Dateien generiert:

  • Dockerfile.debug
  • Dockerfile
  • docker-compose.debug.yml
  • docker-compose.yml

Die Debug Dateien sind hierbei entsprechend für den Debug-Build vorhanden; und genau hier ist der Grund das Problem.

Die Datei docker-compose.debug.yml sieht folgendermaßen aus:


version: '2'

services:
  aspnetcore_rtm_windows_docker_sample:
image: username/aspnetcore_rtm_windows_docker_sample:Debug
build:
  context: .
  dockerfile: Dockerfile.debug
environment:
  - REMOTE_DEBUGGING=${REMOTE_DEBUGGING}
ports:
  - "80:80"
volumes:
  - .:/app

Der Eintrag volumes ist dazu da, dass beim Build ein sogenanntes Shared Mapping stattfindet. Eigentlich sind die Dateien in einem Docker-Container isoliert; das ist gut so und auch richtig so. Beim Debuggung würde es aber dazu führen, dass jedes mal der Docker-Container neu gebaut werden muss, wenn man zum statische Dateien wie HTML bearbeitet. Wer mit der ASP.NET Entwicklung schon länger vertraut ist: es würde total nerven und ineffizient sein, wenn jedes Mal beim Schreiben von statischen Dateien auch der Bau der Anwendung und dann auch der Bau des Docker Containers ausgeführt werden müsste. Das Mapping ist nun dazu da, dass der Docker-Container-Inhalt nicht im Docker-Container ist, sondern eben extern unter C:\Users\Public.

Mit Hilfe dieser Brücke kann am statischen Inhalt entwickelt werden, ohne, dass der Container neu gebaut werden muss. Eine enorme Effizienzsteigerung!

Virenscanner

Ich selbst habe festgestellt, dass auf meinem PC das Debugging von ASP.NET Core 1 mit Docker-Support nicht funktioniert. Es äußert sich darin, dass beim Starten des Debugging dieses in Visual Studio sofort wieder abbricht: ohne Fehlermeldung. Auf meinem Laptop trat dieser Fehler nicht auf. Also habe ich 5 Stunden investiert, um meinem PC mit Windows 10 neu zu installieren. Als erstes erfolgte dabei die Installation von Visual Studio und Co; wobei anschließend das Debugging von ASP.NET Core 1 perfekt funktioniert hatte. Nach der Installation meiner Sicherheitssuite - Kaspersky Internet Security - dann plötzlich nicht mehr...

Das Deaktivieren des Schutzes hatte keine Besserung gebracht; erst eine Deinstallation von Kaspersky lies mich wieder die ASP.NET Core 1 im Docker Container debuggen.

Das Kaspersky Protokoll, das man aktivieren muss, zeigte mir dann folgende Ausgabe, die ich komisch empfang:

22:32:36.868      0x1314  INF         sbank.launch_sequence_controller          Searching safe browser launch info for: parentPid=11988 and cmd=["powershell" -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass -Command "C:\Users\Ben\documents\visual` studio` 2015\Projects\WebApplication1\src\WebApplication1\DockerTask.ps1 -Run -Environment Debug -Machine '' -RemoteDebugging $True -OpenSite $False"]
22:32:36.868      0x1314  INF         sbank.launch_sequence_controller          Launch info not found for: parentPid=11988 and cmd=["powershell" -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass -Command "C:\Users\Ben\documents\visual` studio` 2015\Projects\WebApplication1\src\WebApplication1\DockerTask.ps1 -Run -Environment Debug -Machine '' -RemoteDebugging $True -OpenSite $False"]

Bei genauere Analyse ist mir aufgefallen, dass der Docker-Container, den Visual Studio hier erstellt, zwar vorhanden ist, aber leer ist. Der Ordner App, den wir über die volumes konfiguration in docker-compose.debug.yml angeben, war einfach leer!

Wenn diese Konfiguration entfernt wird; auch dann funktioniert das Debugging wieder. Visual Studio bricht dieses nicht ab.

Schuld ist das Mapping

Ich wusste also, dass irgendwas an dieser Konfiguration krumm sein muss.

So wirklich viele Treffer zu diesem Zeitpunkt gab es nicht und ich musste ziemlich grubeln, woran das denn liegen könnte. Kaspersky war hier auch nicht alleine betroffen. Habe auch Avira wie auch Norton versucht: mit identischem Verhalten.

Auch heute weiß ich noch nicht, was genau das Problem ist. Fakt ist, dass die Sicherheitssoftware genau diesen Vorgang des Mappings nicht mag und unterbindet.

Problemlösung

Für die Problemlösung habe ich mich nun sowohl an Microsoft, wie auch an Docker wie auch an Kaspersky gewandt. Wer letzten Endes für die Problemlösung verantwortlich ist; das kann ich nicht sagen.

Ich hoffe nur, dass die Lösung bald zu finden sein wird. Denn der aktuelle Zustand - entweder ohne Sicherheitssoftware oder ohne die Bearbeitungsmöglichkeit von statischen Dateien - stellt für mich keine zufriedenstellende Lösung dar.

Share this article