Question Modifier l'adresse IP et le numéro de port de TeamCity sur Windows Server 2008 multi-hébergé exécutant IIS 7


Après deux jours complets de "recherche" (lire: cogner ma tête contre mon clavier) et de maudire la documentation de TeamCity / MSDN / Tomcat ainsi que les liaisons IIS fantômes, j'ai trouvé une réponse à un problème très complexe: Comment puis-je modifier l'adresse IP et le numéro de port de TeamCity sur un serveur multi-hébergés exécutant Windows Server 2008 ainsi que IIS 7, qui remplit un rôle nécessaire?.

D'abord, un peu de contextualisation. Notre serveur de génération exécute Windows Server 2008 avec deux adresses IP (192.168.1.30 et 192.168.1.31) sur une carte réseau. J'ai configuré IIS pour qu'il lie explicitement son seul et unique site à 192.168.1.30 sur le port 80. À ce stade, je pense que 192.168.1.31 est grand ouvert et prêt à être utilisé pour TeamCity ... pas tout à fait.

Premier inconvénient: lors de l’installation de TeamCity, il ignore totalement le fait qu’il existe plusieurs adresses IP associées à ce serveur ne demandant que le port auquel elle doit se connecter. Pour les logiciels de niveau serveur, c'est assez surprenant.

Deuxième contretemps: TeamCity utilise par défaut le port 8080 (wha ??). En raison de la première gêne, le choix du port est quelque peu ambigu: est-ce que TeamCity va se connecter au port 8080 sur les deux adresses IP? Si vous modifiez la sélection de ports sur 80, un autre service est déjà lié au port 80. Hmm, IIS ne devrait être lié qu'au port 80 sur 192.168.1.30; rien ne devrait être lié à 192.168.1.31. Il est évident que TeamCity est en concurrence avec IIS sur 192.168.1.30.

En terminant l'installation de TeamCity, après avoir choisi le port 80 et ignoré l'avertissement de liaison, j'ouvre "C: \ TeamCity \ server.xml". Note: "C: \ TeamCity \" est la valeur par défaut installation répertoire pour TeamCity alors que "C: \ Users \ .BuildServer" est la valeur par défaut Les données annuaire. Quoi qu'il en soit, "server.xml" est le fichier de configuration dans lequel vous pouvez définir des éléments tels que le port et l'adresse IP de l'interface Web de TeamCity. Après quelques recherches, je propose la configuration permettant de lier l'adresse IP 192.168.1.31 sur le port 80:

Rechercher soit

<Connector
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

ou

<Connector
    port="80"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

en fonction du port que vous avez choisi lors de l'installation. Changer soit en (remarque: changez l'adresse IP!)

<Connector
    port="80"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443"
    address="192.168.1.31" />

Devrait être aussi facile que ça, non ... non? Eh bien, le redémarrage du serveur Web de TeamCity (via le Gestionnaire de services de Windows) ne donne rien sur 192.168.1.31. Pouah.

Il s'avère que, même si le seul et unique site d'IIS a été explicitement lié à 192.168.1.30 sur le port 80, IIS écoute toujours sur tout Adresses IP. Ceci, bien sûr, élimine le serveur Web de TeamCity (Tomcat) qui s'arrête avant même de se connecter. Après avoir démarré manuellement Tomcat à partir de la ligne de commande pour disséquer son erreur stdout et encore plus de recherches, je tombe sur ce petit bijou de StackOverflow: Comment contrôler quelle adresse IP utilisée par IIS7?

Donc, depuis une ligne de commande administrative, je lance (remarque: encore une fois, changez l'adresse IP! Cette fois à l'adresse IP que vous avez vouloir IIS à être lié)

netsh http add iplisten ipaddress = 192.168.1.30

Maintenant, je redémarre le serveur Web de TeamCity et le tour est joué, ça fonctionne !! Je peux naviguer jusqu'à 192.168.1.31 sans avoir à spécifier un numéro de port et l'interface Web de TeamCity apparaît. Un rapide contrôle de validité montre que IIS est toujours correctement lié à 192.168.1.30. Tout est bien.

Désolé pour le long post pour une solution aussi simple. J'espère que cela aidera quelqu'un d'autre, car cela m'aurait certainement évité des heures d'aggravation.


Modifier: Après avoir utilisé TeamCity pendant un certain temps, j'ai constaté que l'agent de compilation installé avec TeamCity n'était pas correctement reconnu. Pour résoudre ce problème, je devais indiquer à l'agent de compilation la nouvelle URL de TeamCity. Cette modification de configuration est effectuée dans "C: \ TeamCity \ buildAgent \ conf \ buildAgent.properties". Là encore, il s’agit du chemin pour une installation par défaut de TeamCity et peut être différent selon la manière dont vous personnalisez votre installation de TeamCity.

Dans "buildAgent.properties", assurez-vous que "serverUrl" pointe vers la nouvelle URL TeamCity. Dans mon cas, je l'ai mis à jour pour:

serverUrl = http \: //192.168.1.31

Une fois cette modification effectuée, redémarrez TeamCity Web Server et TeamCity Build Agent.


20
2017-08-24 18:36


origine


Sérieusement c'est génial. C’est exactement ce que moi-même et un de nos administrateurs avons fini par comprendre nous-mêmes (ce qui était nul). Merci d'avoir posté un bon article. - Ryan Montgomery
Vous voudrez peut-être séparer la question et la réponse si ... - Ryan Montgomery


Réponses:


La réponse fait partie de la "question" originale ci-dessus.


10
2017-08-24 18:38



+1 pour m'avoir économisé quelques heures! - Tim Long