Установка teamcity centos 7



Постилка

TeamCity — серверное программное обеспечение от компании JetBrains, написанное на языке Java, билд-сервер для обеспечения непрерывной интеграции.

Я узнал о TeamCity два года назад, когда ребята поднимали CI на нашем проекте. В то время я не совсем понимал что из себя представляет CI и как это работает. Со временем мне пришлось создавать новые билды и описывать их конфигурацию в Ant-скриптах. Недавно мне пришлось самому устанавливать TeamCity на «чистую» CentOS. Об этом и расскажу. Будете удивлены, но делается это очень просто.

Для примера я взял CentOS 6.4 и TeamCity 8.3.

1. Устанавливаем Oracle 1.6 JDK.

2. Устанавливам tomcat 6.*-7.*. Я выбрал шестую версию. Разработчики TeamCity рекомендуют Tomcat 6.0.27+.

5. TeamCity скачан, распакован, и находится в папке /opt/jetbrains/TeamCity. Пришло время запустить TeamCity сервер и дефолтный билд-агент.

Всё готово. Теперь вы можете открыть http://your_host:8111/ и начинать работать с TeamCity. Если всё установилось правильно, то вы должны увидеть страницу с таким содержанием:

Я описал как просто и быстро «завести» TeamCity. О детальной настройке можно прочитать в разделе документации TeamCity.

Источник

Установка Teamcity на Linux Ubuntu

Опубликовано: 14.02.2021

В нашей инструкции мы выполним развертывание Teamcity 2020.2.2 на Linux Ubuntu 20.04.

Системные требования

Требования к Teamcity не высокие, однако, необходимо обратить внимание на требования к программной части.

Требования к оборудованию

В основном, требования предъявляются к агентам.

• Процессор: рекомендуется процессор с 4-я ядрами и более.
• Память: рекомендуется использовать сервер с 4 Гб оперативной памяти.
• Диск: зависит от количества проектов и получаемых в результате сборки артефактов.

Программные требования

Teamcity является приложение Java и запускается на веб-сервере Tomcat. Полный список программных требований:

• Apache Tomcat версии 8,5 и выше.
• Java 8 — версия 8u16 (или 1.8.0_16) и выше.
• Операционная система Windows, Linux, FreeBSD, Solaris, HP-UX.

Поддерживаемые базы данных

Для работы Teamcity необходим сервер баз данных. Поддерживается достаточно большое количество СУБД:

• Oracle.
• MS SQL.
• HSQLDB.
• PostgreSQL.
• MySQL/MariaDB.

Подготовка системы

Для установки свежих пакетов, обновляем их список в репозиториях:

Задаем часовой пояс, например:

timedatectl set-timezone Europe/Moscow

* где Europe/Moscow — московское время. Список всех возможных зон смотрим командой timedatectl list-timezones.

Устанавливаем службу для автоматической синхронизации времени:

apt-get install chrony

А также разрешаем его автозапуск:

systemctl enable chrony

Если в нашем Ubuntu используется брандмауэр (по умолчанию только разрешающие правила), необходимо открыть порт 8111:

iptables -A INPUT -p tcp —dport 8111 -j ACCEPT

* 8111 — порт по умолчанию, на котором запускается Teamcity. При смене этого номера, нужно также добавить его в правила firewall.

Сохраняем правила с помощью утилиты iptables-persistent:

apt-get install iptables-persistent

Если в процессе установки мы отказались сохранять правила, выполняем команду:

Установка Java

Для работы Teamcity нужен Java. Вы воспользуемся пакетом openjdk. Для его установки вводим:

apt-get install default-jdk

* будет установлена последняя версия, максимально совместимая с используемой версией операционной системы Ubuntu.

Если в системе окажется несколько версий java, выберем последнюю. Для этого вводим команду:

update-alternatives —config java

. и выбираем в списке соответствующий вариант.

Если мы увидим что-то на подобие:

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-11-openjdk-amd64/bin/java
Nothing to configure.

. то значит, что у нас только одна версия Java — продолжаем настройку сервера.

Посмотрим используемую версию java:

Мы должны увидеть что-то на подобие:

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)

Установка и настройка СУБД MariaDB

Как было сказано выше, для работы Teamcity нужна база данных. Мы воспользуемся MariaDB, которая является форком MySQL.

Для ее установки вводим:

apt-get install mariadb-server

Разрешим автозапуск сервера:

systemctl enable mariadb

Зададим пароль для суперпользователя:

mysqladmin -u root password

Подключимся к командной строке SQL:

Создаем базу данных для нашего приложения:

> CREATE DATABASE teamcity DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* данной командой мы создадим базу teamcity.

Создадим пользователя для доступа к базе:

> GRANT ALL PRIVILEGES ON teamcity.* TO teamcity@localhost IDENTIFIED BY 'teamcity123';

• teamcity.* — разрешает доступ к любой таблице базы teamcity;
• teamcity@localhost — разрешает доступ пользователю teamcity с локального компьютера;
• teamcity123 — пароль для создаваемого пользователя.

Выходим из командной оболочки SQL:

Установка Teamcity

Создадим каталог, где будет размещаться наше приложение:

Переходим на страницу загрузки Teamcity — начнется загрузка файла — прерываем ее. Копируем ссылку на скачивание архива:

С помощью нашей ссылке, скачиваем архив на компьютер:

wget -O TeamCity.tar.gz https://download.jetbrains.com/teamcity/TeamCity-2020.2.2.tar.gz?_ga=2.175301669.60879802.1613028860-1795692882.1612763354

* в данном примере мы указали опцию -O, чтобы скачанный архив был назван TeamCity.tar.gz.

tar zxf TeamCity.tar.gz -C /opt/teamcity —strip-components 1

* этой командой мы распакуем содержимое архива TeamCity.tar.gz в каталог /opt/teamcity.

Запустим необходимые сервисы для работы приложения:

Пробуем открыть браузер и перейти по ссылке http://<IP-адрес нашего сервера>:8111 — мы должны увидеть стартовую страницу установки Teamcity. В форму для каталога данных вводим путь /opt/teamcity/.BuildServer:

После кликаем Proceed. Откроется страница выбора используемой СУБД — мы выбираем MySQL:

Для работы MySQL необходим дополнительный драйвер — просто нажимаем по Download JDBC driver:

Заполняем поля для подключения к базе данных:

* в нашем примере мы создали базу teamcity; для подключения мы указали пользователя teamcity и пароль teamcity123.

Нажимаем Proceed — начнется установка и настройка приложения. Ждем:

На следующей странице принимаем лицензионное соглашение и кликаем Continue:

Создаем нового пользователя с правами администратора:

* в данном примере мы создадим пользователя admin.

Откроется стартовая страница Teamcity:

Приложение установлено и работает.

Настройка автозапуска

На предыдущем шаге мы смогли запустить приложения, но сделали это вручную. После перезагрузки компьютера, оно не будет стартовать автоматически. Создадим службу в виде юнита в systemd.

Создаем пользователя, от которого будет работать наше приложение:

useradd teamcity -U -s /bin/false -d /opt/teamcity -m

* мы создадим пользователя teamcity с опциями:

• -U — будет создана группа с таким же именем.
• -s /bin/false — запрещает пользователю интерактивный вход в систему.
• -d /opt/teamcity — указывает путь до домашней директории.
• -m — сразу создает домашнюю директорию.

Для каталога с нашим приложением установим владельца — нашего созданного пользователя:

chown -R teamcity:teamcity /opt/teamcity

Создаем юнит в systemd:

[Unit]
Description=Teamcity Service
After=network.target

ExecStart=/opt/teamcity/bin/runAll.sh start
ExecStop=/opt/teamcity/bin/runAll.sh stop

• User/Group — пользователь и группа пользователя, от кого будет запускаться сервис.
• ExecStart/ExecStop — пути к скриптам, которые запускают или останавливают работу Teamcity.
• Restart/RestartSec — задают поведение сервиса при необходимости выполнить перезапуск. В нашем примере выполнять при сбое с интервалом в 10 секунд.

Перечитаем конфигурацию systemd:

Можно запустить наш сервис и разрешить его автозапуск:

systemctl start teamcity

systemctl enable teamcity

Проверить состояние службы можно командой:

systemctl status teamcity

После пробуем открыть приложение в браузере.

Установка агента

Для сборки кода на удаленной системе, нам необходимо установить на нее агента Teamcity. Мы рассмотрим инструкцию для его развертывания на Linux — Ubuntu, Debian, CentOS.

Сначала установим утилиты, которые нам понадобятся для выполнения установки.

а) Для Ubuntu / Debian:

apt-get install wget unzip default-jdk

yum install wget unzip java-11-openjdk-devel

• wget — утилита для загрузки файлов из сети по http.
• unzip — программа для распаковки zip-архивов.
• default-jdk/java-11-openjdk-devel — реализация java.

Скачиваем архив с агентом с нашего сервера:

* где 192.168.1.15 — это адрес нашего сервера.
* если мы получим сообщение об ошибке, что команда wget не найдена, необходимо установить одноименную утилиту — yum install wget или apt-get install wget.

Распакуем архив в каталог /opt/teamcity-agent:

unzip buildAgent.zip -d /opt/teamcity-agent

Копируем шаблонный файл с конфигурацией:

cp /opt/teamcity-agent/conf/buildAgent.dist.properties /opt/teamcity-agent/conf/buildAgent.properties

Агент готов к работе. Теперь создадим юнит в systemd для его запуска:

[Unit]
Description=TeamCity Build Agent
After=network.target

[Service]
Type=forking
PIDFile=/opt/teamcity-agent/logs/buildAgent.pid
ExecStart=/opt/teamcity-agent/bin/agent.sh start
ExecStop=/opt/teamcity-agent/bin/agent.sh stop

Перечитываем конфигурацию systemd:

Разрешаем автозапуск агента teamcity и стартуем его:

systemctl enable teamcity-agent —now

Проверить состояние выполнения можно командой:

systemctl status teamcity-agent

По умолчанию агент работает на порту 9090. Если необходимо поменять номер, открываем конфигурационный файл:

* в данном примере мы хотим запустить агента на порту 9088.

Источник

TeamCity: установка на CentOS

Установка проводится на:

Если не установлена — устанавливаем Java:

В файл настроек оболочки добавляем необходимые пути:

Перечитаем файл настроек, что бы применились изменения:

Создадим каталог, в котором будет работать наш TeamCity:

Архив не маленький:

Структура каталогов в TeamCity выглядит так:

Управление приложением выполняется с помощью скриптов runALL :

По-умолчанию — TeamCity работает на порту 8111, проверим:

При необходимости — выгрузим IPTABLES:

И заходим на страничку TeamCity:

Жмём Proceed для продолжения:

После инициализации всего требуемого — соглашаемся с лицензией:

Создаём аккаунт администратора:

И, наконец-то, попадаем «внутрь» самого TeamCity:

Источник

Настройка TeamCity для новичков

Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.

Что такое «непрерывная интеграция», отлично рассказано здесь и вот здесь, повторять эту тему в сотый раз вряд ли нужно.

Ну и для начала – что может TeamCity (далее – просто TC)? А может он следующее: при появлении изменений в указанной ветке репозитория (или ином событии) выполнить сценарий, включающий в себя, например, сборку приложения, прогон тестов, выполнение других сценариев, заливку файлов на удаленный сервер и т.п.

Важным моментом является то, что «сервер интеграции» и «машина, на которой будет проходить этот процесс», – обычно (не обязательно) разные серверы. Более того, машинок, на которых запускаются сборки и тесты, может быть несколько, даже много, и все на разных ОС – в общем, есть, где развернуться.

Для запуска процесса сборки используется программа-агент, принимающая команды от TC-сервера, запустить ее можно на любой из основных ОС (слава мультиплатформенности Java). На один компьютер можно установить несколько агентов и запускать их параллельно, но важно помнить, что один агент единовременно может обрабатывать только один проект. При старте задачи TC выбирает первый подходящий незанятый агент, причем можно устанавливать «фильтры», например, выбирать агента только с ОС Windows или только с установленным .NET версии не ниже 4.0 и т.п.

1. release – содержит актуальный код, рабочую версию, которая находится на боевом сервере;
2. dev – в неё идут все новые фичи, позже вливается в release;
3. отдельная ветка на каждую фичу, которая отпочковывается от dev и в неё же возвращается.

В связи с этим наш сценарий будет выглядеть так:

1. забрать свежие изменения из репозитория ветки dev;
2. скомпилировать проект;
3. если всё прошло успешно на предыдущем шаге – прогнать юнит-тесты;
4. если всё прошло успешно на предыдущем шаге – прогнать функциональные тесты;
5. если всё прошло успешно на предыдущем шаге – залить изменения на тестовый сервер.

А теперь вперёд – реализовывать сценарий!

Забрать свежие изменения из репозитория

Начинается всё с немудрёного создания проекта.

После – создание «build configuration» (конфигурации сборки). Конфигурация определяет сценарий сборки.

На втором же шаге создания конфигурации нас спросят об использованной VCS, так что отвечаем честно, что у нас тут git. У вас может быть другая VCS – не теряйтесь. Добавление нового репозитория производится кнопкой Create and attach new VCS root.

Итак, ключевые настройки:

• VCS root ID можно не трогать – уникальный код, как ни крути. Если оставить пустым, генерируется автоматически;
• Fetch URL – тот адрес, с которого мы будем забирать содержимое репозитория;
• Default branch – ветка, с которой будет браться информация;

Далее, нужно настроить автоматический запуск задания. Идём в «Build Triggers» (условия сборки) и выбираем условие VCS Trigger – при настройках по умолчанию он будет раз в минуту проверять наличие новых коммитов в репозитории, а если таковые найдутся – запустит задание на выполнение.

Скомпилировать проект

Поскольку у нас проект на ASP.NET в виде Solution’а из Visual Studio – тут тоже было всё просто.

Идём в меню «Build Steps» (Шаги сборки), выбираем runner type (а их тут действительно много) и останавливаемся на MSBuild. Почему именно на нём? Он даёт достаточно простой способ описать процесс сборки, даже достаточно сложный, добавляя или удаляя различные шаги в простом XML-файле.

Далее всё элементарно.

Build file path – путь к sln-файлу.
MSBuild version, MSBuild ToolsVersion и Run platform выбираем под требования своего проекта.

Если в проекте несколько конфигураций, то можно использовать опцию Command line parameters для ввода примерно такого ключа:

где Production заменить на нужный конфиг.

Включить скачивание NuGet-пакетов

Важный пункт, в случае если вы используете NuGet-пакеты; если нет – можно переходить сразу к следующему пункту.

Поскольку NuGet-пакеты весят немало, да и хранить в репозитории бинарники библиотек без особой необходимости не хочется, можно использовать замечательную опцию NuGet Package Restore:

В этой ситуации бинарники библиотек в репозиторий не включаются, а докачиваются по мере необходимости в процессе сборки.

Но MSBuild – настоящий джентльмен и не будет без разрешения делать лишних телодвижений, поэтому и докачивать пакеты просто так не будет – ему сей процесс нужно разрешить. Для этого придется либо на клиенте установить переменную окружения Enable NuGet Package Restore в значение true, либо пойти в меню Build Parameters и выставить его там.

Прогнать юнит-тесты

У нас юнит-тесты являются отдельным проектом внутри решения. Так что на предыдущем шаге они уже скомпилированы – осталось их запустить.

• If all previous steps finished successfully (zero exit code) – если все предыдущие шаги завершились без ошибок. При этом проверка выполняется чисто на агенте;
• Only if build status is successful – аналогично предыдущему, но при этом агент ещё и уточняет у сервера TC статус билда. Нужно для более тонкого управления логикой задания, например, если нулевой код возврата конкретного шага для нас является ошибкой;
• Even if some of the previous steps failed – даже если какой-то из предыдущих шагов завершился с ошибкой;
• Always, even if build stop command was issued – выполнять шаг, даже если подана команда на отмену выполнения сборки.

%teamcity.build.checkoutDir% – это переменная, указывающая на папку, в которую скачиваются данные из репозитория. В принципе, она не обязательна для указывания, т.к. по умолчанию путь идёт именно относительно этой директории, поэтому путь можно было бы сократить до:

Отдельно отмечу опцию Run recently failed test first – если в предыдущем прогоне какие-то тесты упали, то в следующем запуске первыми запустятся именно они, и вы быстро узнаете об успешности последних изменений.

Прогнать тесты интерфейса (функциональные тесты)

Здесь все гораздо интереснее, чем с юнит-тестами. Кэп тут подсказывает, что, чтобы протестировать проект в браузере, его, т.е. проект, необходимо запустить. Но тут мы схитрили, запуская веб-сервер прямо из кода тестов Selenium:

А сам запуск выглядит абсолютно точно так же, как на шаге с юнит-тестами.

Залить изменения на тестовый сервер

Сервер, на котором находится агент TC, и сервер, на котором установлен IIS, – разные серверы, причем, более того, находятся они в разных сетях. Поэтому файлы нужно как-то на конечный сервер доставить. И вот тут решение выбрано, может, не очень элегантное, зато крайне простое. Используем заливку через FTP, причем делает сие за нас MSBuild.

1. настраиваем на сервере FTP аккаунт для заливки файлов. Для дополнительной безопасности можно запретить заливку для всех IP, кроме внутреннего, если TC-сервер лежит во внутренней сети, конечно;
2. устанавливаем на агента MSBuild Community Tasks, чтобы получить возможность использовать задачу «Залить по FTP». Качать тут;
3. подготовить файл-сценарий для MSBuild, который будет производить следующие действия:
   1. сборка приложения во временной папке;
   2. подмена конфигурационного файла;
   3. заливка файлов по FTP.

   А так – задание по его вызову:

   

   Недостаток решения – заливаются ВСЕ файлы, а не только новые изменившиеся. На проекте с кучей файлов верстки или множеством модулей это может стать проблемой из-за затрачиваемого на заливку времени.

   Ещё один замеченный недостаток – при встрече файла с нелатиницей в названии падает с ошибкой. Латиница и буквы/цифры обрабатываются нормально. Ноги этой проблемы, похоже, растут из специфики протокола FTP: тот основан на ASCII, но, как именно кодировать не ASCII-символы, он не описывает, предлагая «делать так, как будет понимать ваш сервер». Соответственно, чтобы вылечить проблему, не меняя схему, нужно пропатчить MSBuild Community Tasks, благо, исходники открыты. Ну, или воспользоваться альтернативным способом заливки файлов, например через WinSCP.

   Остановка и запуск сервера для релизного сценария

   Мы её решаем чуть диким, но симпатичным способом. У IIS’а есть особенность: если в корень сайта положить файл с именем app_offline.html, то сайт отрубается, при обращении ко всем файлам будет выдаваться содержимое этого файла.

   Минус – обращение именно что КО ВСЕМ файлам, включая статичные. Так что, если хочется сделать заглушку с оформлением, CSS и картинками, используйте инлайн-стили и data:url, ну, или как вариант – выложите их на отдельном сервере.

   Включаем-отключаем мы сервер через WinSCP-сценарий и такие вот файлики:

   Т.е., изначально файл лежит в корне и называется _app_offline.html. Когда нужно заблокировать доступ на время апдейта, мы переименовываем его в app_offline.html. При заливке файлов заливается новый файл _app_offline.html, а после окончания – удаляется файл app_offline.html. И получаем именно то, что было изначально.

   В тексте страницы-заглушки крайне рекомендую воспользоваться мета-тегом refresh, который периодически будет обновлять страницу. Если к этому времени процесс обновления завершился, пользователь вернётся обратно в сервис, чему наверняка будет несказанно рад.

   Вызов сценария включения заглушки (отключение заглушки происходит аналогично):

   

   Да, WinCSP лежит в результате прямо в репозитории. Да, пароли в открытом виде лежат в файле. Да, не самое элегантное решение, но, поскольку доступ в репозиторий и к виртуальной машине с агентом имеют только разработчики из нашей команды, почему бы и нет? Да, можно было бы хранить файл с паролями, например, непосредственно на агенте, но принципиально безопасность это не повысило бы, а вот развертку нового агента, например, замедлило бы.

   Данные настройки используются нами на протяжении где-то полугода, и пока ни единой проблемы не возникло – всё работает как часы, что не может не радовать.

   На этом всё. С удовольствием выслушаю комментарии и советы по улучшению этих шагов, а также ваши рассказы о том, какие возможности TC вы используете у себя.

   Update от 3 ноября 2014 года.
   Выбирая Runner Type «Command line» не требуется как-либо экранировать пробелы — Team City озаботится об этом самостоятельно.

   Источник