Po dwóch pełnych dniach „badań” (czytaj: walenie głową w klawiaturę) i przeklinania dokumentacji TeamCity / MSDN / Tomcat, a także powiązań fantomowych IIS, znalazłem odpowiedź na bardzo kłopotliwy problem: jak to zrobić Zmieniam adres IP i numer portu TeamCity na serwerze multi-homed z systemem Windows Server 2008, a także IIS 7, który służy niezbędnemu celowi? .
Najpierw trochę tła. Na naszym serwerze kompilacji działa system Windows Server 2008 z dwoma adresami IP (192.168.1.30 i 192.168.1.31) na jednej karcie sieciowej. Skonfigurowałem IIS, aby jawnie powiązał swoją jedyną witrynę z 192.168.1.30 na porcie 80. W tym momencie myślę, że 192.168.1.31 jest szeroko otwarty i gotowy do użycia w TeamCity ... niezupełnie.
Pierwsza irytacja: podczas instalowania TeamCity całkowicie pomija się fakt, że z tym serwerem jest powiązanych wiele adresów IP, pytając tylko, z którym portem powinien się połączyć. W przypadku oprogramowania klasy serwerowej jest to dość zaskakujące.
Druga irytacja: TeamCity domyślnie przyjmuje port 8080 (co?). Ze względu na pierwszą irytację wybór portu jest nieco niejednoznaczny: czy TeamCity zamierza połączyć się z portem 8080 na obu adresach IP? Zmiana wyboru portu na 80 powoduje ostrzeżenie, że inna usługa jest już związana z portem 80. Hmm, IIS powinien być związany tylko z portem 80 na 192.168.1.30; nic nie powinno być związane 192.168.1.31. Oczywiście TeamCity konkuruje z IIS 192.168.1.30.
Kończąc instalację TeamCity, po wybraniu portu 80 i zignorowaniu ostrzeżenia o wiązaniu, otwieram „C: \ TeamCity \ server.xml”. Sidenote: „C: \ TeamCity \” to domyślny katalog instalacyjny TeamCity, natomiast „C: \ Users \ .BuildServer” to domyślny katalog danych . W każdym razie „server.xml” to plik konfiguracyjny, w którym możesz ustawić takie rzeczy, jak port i adres IP interfejsu sieciowego TeamCity. Po kilku badaniach wymyśliłem konfigurację wiązania adresu IP 192.168.1.31 na porcie 80:
Poszukaj albo
<Connector
port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
lub
<Connector
port="80"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
w zależności od portu wybranego podczas instalacji. Zmień na ( uwaga: zmień adres IP! )
<Connector
port="80"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
address="192.168.1.31" />
To powinno być takie proste, prawda ... prawda? Ponowne uruchomienie serwera sieci TeamCity (za pomocą Menedżera usług systemu Windows) nie daje nic na 192.168.1.31. Ugh.
Okazuje się, że chociaż jedyna witryna IIS została wyraźnie powiązana z 192.168.1.30 na porcie 80, IIS nadal nasłuchuje na wszystkich adresach IP. To oczywiście wyłącza serwer sieciowy TeamCity (Tomcat), który zatrzymuje się, zanim nawet przejdzie do trybu online. Po ręcznym uruchomieniu Tomcata z wiersza polecenia, aby przeanalizować jego błąd stdout i jeszcze więcej badań, natrafiam na ten mały klejnot z StackOverflow: Jak mogę kontrolować, którego adresu IP używa IIS7?
Tak więc z wiersza polecenia administracyjnego uruchamiam ( uwaga: ponownie zmień adres IP! Tym razem na adres IP, który chcesz powiązać z IIS )
netsh http add iplisten ipaddress = 192.168.1.30
Teraz ponownie uruchamiam serwer sieciowy TeamCity i voila, działa !! Mogę przeglądać do 192.168.1.31 bez konieczności podawania numeru portu i pojawia się interfejs sieciowy TeamCity. Szybka kontrola poczytalności pokazuje, że IIS jest nadal poprawnie powiązany z 192.168.1.30. Wszystko dobrze.
Przepraszamy za długi post za tak prostą naprawę. Mam nadzieję, że to pomoże komuś innemu, ponieważ z pewnością zaoszczędziłoby mi wiele godzin pogorszenia.
Edycja: Po dłuższym korzystaniu z TeamCity zauważyłem, że Agent kompilacji zainstalowany w TeamCity nie został poprawnie rozpoznany. Aby to naprawić, musiałem wskazać Agentowi kompilacji nowy adres URL TeamCity. Ta zmiana konfiguracji odbywa się w „C: \ TeamCity \ buildAgent \ conf \ buildAgent.properties”. Ponownie jest to ścieżka do domyślnej instalacji TeamCity i może się różnić w zależności od sposobu dostosowania instalacji TeamCity.
Wewnątrz „buildAgent.properties” upewnij się, że „serverUrl” wskazuje nowy adres URL TeamCity. W moim przypadku zaktualizowałem go do:
serverUrl = http \: //192.168.1.31
Po wprowadzeniu tej zmiany zrestartuj zarówno TeamCity Web Server, jak i TeamCity Build Agent.