Windows 10 als Build-Server - Lizenzprobleme?

Status
Für weitere Antworten geschlossen.

Autokiller677

Fleet Admiral
Registriert
Jan. 2009
Beiträge
10.002
@Mods: Kann geschlossen werden.

(Ja, ich weiß das man das eigentlich nicht machen sollte. Bitte wirklich an die Lizenzfrage halten, nicht technischen Sinn disktutieren)

Hallo Zusammen,

auf der Arbeit plane ich gerade einen Build-Server auf Windows-Basis um ein paar Software-Projekte automatisch zu bauen.

Gebaut werden muss unter Windows (WPF-Desktop App) in Docker-Containern. Und da fängt der Spaß an.
Normalerweise würde ich ja jederzeit sagen, klar, Windows-Server Lizenz besorgen, Win10 ist kein Server-System.

Aber um mehr als 2 Container mit Hyper-V parallel laufen lassen zu können (wegen diversen Build-Targets auf verschiedenen Windows-Versionen reichen die normalen "Windows-Container" mit Prozessisolation nicht), braucht man gleich die Datacenter-Lizenz für $6000 (https://www.microsoft.com/de-de/windows-server/pricing) und das ist dann doch etwas Overkill, wenn das Ding nix anderes macht als gitlab-runner.exe auszuführen und Container zu starten. Da läuft sonst nix, kein AD, kein Network-Share, gar nichts. 100% single purpose Software kompilieren.

Daher überlege ich jetzt, das ganze unter Windows 10 laufen zu lassen und frage mich, ob es da ein Lizenzproblem gibt?

Hier https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/Useterms_Retail_Windows_10_English.htm steht in 2A

Under this agreement, we grant you the right to install and run one instance of the software on your device (the licensed device), for use by one person at a time, [...].

Letztlich wird die allermeiste Zeit niemand das System direkt benutzen. Keiner meldet sich dran an, greift auf Netzlaufwerke zu oder sonstwas. Die oben erwähnte gitlab-runner.exe fragt alle paar Sekunden beim Gitlab Server ab, ob es einen neuen Job gibt, führt die Jobs aus, und schickt das Ergebnis an den Server zurück. Maximal melde ich mich einmal die Woche an um nach Updates zu schauen.

Indirekt nutzt das natürlich mehreren Leuten, weil die Software von einem Team entwickelt wird.

Ich weiß, dass mir hier natürlich niemand eine rechtssichere Antwort geben kann, aber vielleicht hat sich ja schonmal jemand damit beschäftigt.
Ergänzung ()

Hat sich erledigt wie mir gerade auffällt.

Unter Win10 wären die Container nicht mehr lizensiert, bzw. nur für den Testbetrieb (https://docs.microsoft.com/de-de/virtualization/windowscontainers/about/faq). Muss also wenn es legal sein soll Win Server werden. Na dann geh ich mal Budget suchen :D
 
Zuletzt bearbeitet:
Aus meiner Sicht ist mit Nutzen ertwas anderes gemeint.
Nutzen und Dienste zur Verfügung stellen sind unterschiedliche Dinge - sonst wäre ja schon die Netzwerkfreigabe ein sehr strittig... Man stelle sich nur mal die ganzen Lizenzverstoße vor, nur weil jemand den an seinem PC angeschlossenen Drucker im Netzwerk freigibt.

Aber scheinbar hat sich die Frage ja eh erldigt :-)
 
  • Gefällt mir
Reaktionen: madmax2010
@tollertyp Afaik ist die Netzwerkfreigabe da unstrittig - für jeden User, der einen Netzwerkfreigabe auf einem Windows Server nutzt braucht man eine CAL. Aber so richtig tief stecke ich in der Server-Lizensierung nicht drin.

Mein Problem hat sich aber gelöst, siehe Edit - es ist nicht legal.
 
Ich meine bei der Netzwerkfreigabe da im Retail-Umfeld, auf das du dich im Zitat ja auch bezogen hast.
 
Bin mir sicher das es legal ist
da steht ja "
Windows 10 Pro und EnterpriseUnbegrenzt (nur für Test- oder Entwicklungszwecke)Unbegrenzt (nur für Test- oder Entwicklungszwecke)

-> Entwicklungszwecke

Außerdem, muss es ein Container sein? kannst ja direkt auf dem Eisen laufen lassen

Nur weil das in der Linux welt jeder benutzt, muss das ja nicht in Windows auch nutzen.
 
MIt Entwicklungszwecke ist glaube ich aber etwas anderes gemeint als dedizierte Build-Server, die die Entwicklung unterstützen.

Also ein Entwickler, der ein verteiltes System lokal testen will z.B...
 
tollertyp schrieb:
MIt Entwicklungszwecke ist glaube ich aber etwas anderes gemeint als dedizierte Build-Server, die die Entwicklung unterstützen.

Also ein Entwickler, der ein verteiltes System lokal testen will z.B...
Steht das wo?
Entwicklungssystem ist ein System das zum Entwickeln verwendet wird...
Siehe auch "Warning" text

Warnung

Abgesehen von IoT Core- und IoT Enterprise-Hosts (nachdem Sie weitere Bestimmungen und Einschränkungen akzeptiert haben) ist dieses Feature nur für Entwicklung und Tests gedacht. Sie sollten weiterhin Windows Server als Host für Produktionsbereitstellungen verwenden. ...


Und weiters
Muss es HyperV sein?
Wenn du sicher sein willst, nimm halt Virtual Box mit einigen Images und für jedes Image verwendest du eine eigene Lizenz. Das ist sicherlich auch billiger als die X tausend Euro für Windows Server.
 
Zuletzt bearbeitet:
the_nobs schrieb:
Bin mir sicher das es legal ist
da steht ja "
Windows 10 Pro und EnterpriseUnbegrenzt (nur für Test- oder Entwicklungszwecke)Unbegrenzt (nur für Test- oder Entwicklungszwecke)

-> Entwicklungszwecke
Ich verstehe hier die Entwicklungszwecke so, dass man da den Container / das Setup mit dem Container entwickelt. Der Build-Server später würde jeder Definition die ich kenne nach in den Produktivbetrieb fallen.

the_nobs schrieb:
Außerdem, muss es ein Container sein? kannst ja direkt auf dem Eisen laufen lassen

Nur weil das in der Linux welt jeder benutzt, muss das ja nicht in Windows auch nutzen.
Ich nutze es auch nicht, weil es in der Linux Welt hipp ist, sondern weil ich reproduzierbares Buildverhalten haben will, und immer auf einem sauberen System starten will. Sowas Bare-Metal zu machen müllt auf Dauer nur zu und führt dann zu 1001 Problemen.

Beispiel, was mich gerade letzte Woche ein paar Stunden gekostet hat: Ich stelle gerade ein Projekt von net48 auf net6 um. Auf meinem PC dementsprechend beides installiert. Projekt läuft auf net6 sauber. Dann probiere ich es (im Rahmen der Tests für den Build-Server) im Container, wo nur net6 drin ist und es geht nicht - warum?
Irgendein Hilfstool (lc.exe um genau zu sein) gibt es unter net6 nicht mehr. Wenn es aber durch net48 noch auf dem System ist, wird es scheinbar irgendwie mit benutzt und es läuft.

Daher: Saubere Build-Umgebung im Container, in der nur das drin ist, was da sein soll. Macht das Leben einfacher.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Skysnake
Bist du sicher, dass du für mehrere Container DataCenter brauchst?!
Verwechselst du das vllt. mit VM´s, weil das würde passen.
Mit einer Server Lizenz (nicht DataCenter) kannst du 1 Host + 2 VMs laufen lassen.
Für weiter VMs muss man weitere Server Lizenzen erwerben.

Also ich weiß es an sich nicht, aber ich kann mir nicht vorstellen, dass man nur 2 Container laufen lassen kann....
Sinn von Docker Containern war ja auch, Funktionen und Dienste auf vielen kleinen Container anstatt es in einer großen VM laufen zu lassen
 

Anhänge

  • Container.JPG
    Container.JPG
    30,7 KB · Aufrufe: 147
the_nobs schrieb:
Steht das wo?
Entwicklungssystem ist ein System das zum Entwickeln verwendet wird...
Wie gesagt, dass ist die übliche Definition in Sachen Lizensierung. Der fertige Build-Server fällt unter Produktiv-Betrieb. Deshalb steht das auch immer so als "Für Test- und Entwicklungszwecke" zusammen in Lizenzen.
Ansonsten müsste eine Firma, die nur entwickelt (egal ob Software oder sonstwas), für viele Sachen ja nie eine richtige Lizenz kaufen.

the_nobs schrieb:
Und weiters
Muss es HyperV sein?
Wenn du sicher sein willst, nimm halt Virtual Box mit einigen Images und für jedes Image verwendest du eine eigene Lizenz. Das ist sicherlich auch billiger als die X tausend Euro für Windows Server.
Weil Docker als Virtualisierungsbackend unter Windows halt nur Hyper-v unterstützt. Ich bin auch echt kein Fan von Hyper-V, aber es ist halt das, was da benutzt wird.
Ergänzung ()

snakesh1t schrieb:
Also ich weiß es an sich nicht, aber ich kann mir nicht vorstellen, dass man nur 2 Container laufen lassen kann....
Sinn von Docker Containern war ja auch, Funktionen und Dienste auf vielen kleinen Container anstatt es in einer großen VM laufen zu lassen
In deinem Screenshot steht es doch genau drin - Hyper-V isolierte Container nur zwei Stück.

Die unbegrenzten "Windows-Container" laufen unter Prozessisolation und reicht nicht aus weil wir unter verschiedenen OS-Versionen bauen (bzw. vor allem Unit-Testen) müssen.
 
  • Gefällt mir
Reaktionen: snakesh1t
Autokiller677 schrieb:
Ich verstehe hier die Entwicklungszwecke so, dass man da den Container / das Setup mit dem Container entwickelt. Der Build-Server später würde jeder Definition die ich kenne nach in den Produktivbetrieb fallen.

Ein Build Rechner (ich verwende extra nicht das wort Server) ist ein System das Entwickler den Code baut damit automatisiert immer "reference" builds zur Verfügung stehen
-> Entwicklungszweck
Nach deiner Definition ist ja faktisch alles ein Produktivsystem. weil wenn ich als Entwickler Teste, mach ich ja auch Produktive Sachen!

Aber ist euer Geld, kannst gerne ausgeben


Autokiller677 schrieb:
Ich nutze es auch nicht, weil es in der Linux Welt hip ist, sondern weil ich reproduzierbare Builds haben will, und immer auf einem sauberen System starten will. Sowas Bare-Metal zu machen müllt auf Dauer nur zu und führt dann zu 1001 Problemen.

Beispiel, was mich gerade letzte Woche ein paar Stunden gekostet hat: Ich stelle gerade ein Projekt von net48 auf net6 um. Auf meinem PC dementsprechend beides installiert. Projekt läuft auf net6 sauber. Dann probiere ich es (im Rahmen der Tests für den Build-Server) im Container, wo nur net6 drin ist und es geht nicht - warum?
Irgendein Hilfstool (lc.exe um genau zu sein) gibt es unter net6 nicht mehr. Wenn es aber durch net48 noch auf dem System ist, wird es scheinbar irgendwie mit benutzt und es läuft.

Daher: Saubere Build-Umgebung im Container, in der nur das drin ist, was da sein soll. Macht das Leben einfacher.
Ähnliche Probleme hatte ich auch schon
Wir reden aber 6k€ vs ein paar hundert! ist dir das wirklich > 5k€ Wert?
Wenn das Geld bei euch so locker sitzt, kann ich mich bewerben 😁!!

Und bei deinen Beispiel hätte es ja auch nicht geholfen, weil der Fehler war ja auf dienen Rechner und nicht am Buildsystem.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben