Un problème récurrent que les clients CloudBees reportent au support est l'utilisation de machines de build Windows. Nous recommandons clairement d'utiliser un Linux pour le master, mais bien sur il est nécessaire à de nombreux projets de faire tourner les diverses variantes de Windows comme "esclave" de build.
Jenkins offre de contrôler les slaves Windows via DCOM. Soucis, ce protocole historique a deux modes : "marche" et "marche pas". Autrement dit, une quelconque erreur de configuration se traduit systématiquement par un "Access is denied. [0x00000005]" sans plus d'explication.
Bien plus grave, les différentes astuces référencées sur le wiki et récemment mises au propre par Jesse nécessitent toutes de bricoler les droits système et le registre Windows, sans compréhension claire de l'impact de ces changements sur le système. Il n'est pas exclu qu'on ouvre par ce biais une énorme faille de sécurité. Bonus, il s'avère que les versions 64 bits de Windows se comportent assez différemment, et nous avons des retours assez étrange sur l'utilisation de Windows 8. Je ne vous parle même pas des versions "serveur" de Windows (dont je n'ai jamais compris ce qu'il a de "serveur" mais bon).
Nous décourageons donc à nos clients d'utiliser ce mécanisme. L'approche alternative utilise Java Web Start, autrement dit la création d'une connection à l'initiative de la machine Windows, ce qui coupe court aux problèmes de sécurité. Installé comme service windows, l'agent jenkins slave va donc se connecter au Jenkins master au démarrage. Dans de nombreux cas c'est très nettement mieux, cependant il s'avère que cette connection est parfois instable, pour des raisons encore inexpliquées, et bien difficile à diagnostiquer.
Une autre solution, qui s'avère plus stable, est de remplacer le slave Windows par un slave GNU/Linux. Pas de panique, je parle en fait d'installer Cygwin sur la machine Windows, pour la "GNU-ifier" et d'y faire tourner un service openSSH. La machine peut alors être contrôlée par Jenkins comme n'importe quel esclave Linux SSH, ce qui accessoirement unifie l'infrastructure de build.
Ce qui est triste dans l'affaire c'est de se dire qu'on aurait pas besoin de toute cette tambouille si Windows avait un server SSH natif :'(
Jenkins offre de contrôler les slaves Windows via DCOM. Soucis, ce protocole historique a deux modes : "marche" et "marche pas". Autrement dit, une quelconque erreur de configuration se traduit systématiquement par un "Access is denied. [0x00000005]" sans plus d'explication.
Bien plus grave, les différentes astuces référencées sur le wiki et récemment mises au propre par Jesse nécessitent toutes de bricoler les droits système et le registre Windows, sans compréhension claire de l'impact de ces changements sur le système. Il n'est pas exclu qu'on ouvre par ce biais une énorme faille de sécurité. Bonus, il s'avère que les versions 64 bits de Windows se comportent assez différemment, et nous avons des retours assez étrange sur l'utilisation de Windows 8. Je ne vous parle même pas des versions "serveur" de Windows (dont je n'ai jamais compris ce qu'il a de "serveur" mais bon).
Nous décourageons donc à nos clients d'utiliser ce mécanisme. L'approche alternative utilise Java Web Start, autrement dit la création d'une connection à l'initiative de la machine Windows, ce qui coupe court aux problèmes de sécurité. Installé comme service windows, l'agent jenkins slave va donc se connecter au Jenkins master au démarrage. Dans de nombreux cas c'est très nettement mieux, cependant il s'avère que cette connection est parfois instable, pour des raisons encore inexpliquées, et bien difficile à diagnostiquer.
Une autre solution, qui s'avère plus stable, est de remplacer le slave Windows par un slave GNU/Linux. Pas de panique, je parle en fait d'installer Cygwin sur la machine Windows, pour la "GNU-ifier" et d'y faire tourner un service openSSH. La machine peut alors être contrôlée par Jenkins comme n'importe quel esclave Linux SSH, ce qui accessoirement unifie l'infrastructure de build.
Ce qui est triste dans l'affaire c'est de se dire qu'on aurait pas besoin de toute cette tambouille si Windows avait un server SSH natif :'(
2 commentaires:
Jenkins/Windows sucks +1
On utilise la connection java web start. Du coup, quand le slave windows craque... ben c'est ticket à la prod pour relancer un service...
C'est con, mais je ne vois pas de vrai solution packagé de serveur SSH pour windows (à la client git qui cache un cygwin...)
J'ai l'impression que depuis Win Server 2008, il y a des capacité de remoting via Powershell.
http://technet.microsoft.com/en-us/library/hh849694.aspx
ça serait pas une piste alternative ?
Le problème du Powershell, c'est qu'il faut un Windows comme client. Non ? Ça me parait fumeux http://geekdefrance.fr/2010/09/23/powershell-sous-linux-cest-possible/ Sinon il alternative "Windows Services for UNIX" http://technet.microsoft.com/fr-fr/interopmigration/bb380242.aspx
Enregistrer un commentaire