<![CDATA[

Установка и использование Open Build Service

Open Build Service – программное обеспечение с открытым исходным кодом, распространяющееся под лицензией GPL, которое заметно упрощает организацию собственных репозиториев для популярных дистрибутивов Linux и сборку бинарных пакетов.
В статье я приведу способ быстрой установки серверной части на OpenSuse 12.1, настройки окружения для пользователя и дам перечень полезных команд для работы из консоли. Прежде всего, нужно убедиться, что у вас подключен репозиторий Oss (это основной репозиторий OpenSuse, где находится только программное обеспечение с открытым кодом). Он необходим для установки таких пакетов как Apache2, MySQL-server и т.д.
#zypper addrepo download.opensuse.org/distribution/12.1/repo/oss openSUSE-12.1-Oss

Добавим репозиторий для установки Open Build Server.
#sudo zypper addrepo zypper addrepo download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_12.1/openSUSE:Tools:Unstable.repo
#sudo zypper refresh

Теперь можно начать установку.
#sudo zypper in obs-server obs-api
Установка потянет за собой пачку необходимых пакетов, таких как apache, mysql-server, rubygems и т.д. Всего примерно на 90Мб.

Внесём пару изменений в файл конфигурации. Для этого открываем /etc/sysconfig/obs-server, находим и приводим их к следующему виду строки:
OBS_SRC_SERVER=«localhost:5352»
OBS_REPO_SERVERS=«localhost:5252»

Теперь можно запускать сервисы:
rcobsrepserver start
rcobssrcserver start
rcobsscheduler start
rcobsdispatcher start
rcobspublisher start

Переходим к созданию баз данных и их наполнению:
mysql> create database api_production;
mysql> create database webui_production;
mysql> create user ‘obs’@’%’ identified by ‘obspassword’;
mysql> create user ‘obs’@’localhost’ identified by ‘obspassword’;
mysql> GRANT all privileges ON api_production.* TO ‘obs’@’%’, ‘obs’@’localhost’;
mysql> GRANT all privileges ON webui_production.* TO ‘obs’@’%’, ‘obs’@’localhost’;
mysql> FLUSH PRIVILEGES;

Настроим подключение к mysql API и WebUI. Для этого в любом удобном редакторе открываем файлы /srv/www/obs/api/config/database.yml и
/srv/www/obs/webui/config/database.yml, находим и редактируем следующий блок:
production:
adapter: mysql2
database: api_production
username: obs
password: obspassword

Наполним базы и установим необходимые права на папки tmp и log
cd /srv/www/obs/api/
sudo RAILS_ENV=«production» rake db:setup
sudo chown -R wwwrun.www log tmp
cd /srv/www/obs/webui/
sudo RAILS_ENV=«production» rake db:setup
sudo chown -R wwwrun.www log tmp

Настроим Apache. Установим модуль apache2-mod_xforward. Для этого подключим ещё один репозиторий.
zypper addrepo download.opensuse.org/repositories/openSUSE:/Tools/SLE_11/ Tools-SLE
zypper refresh
zypper in apache2-mod_xforward

Подключим необходимые модули в /etc/sysconfig/apache2.
APACHE_MODULES=»… passenger rewrite proxy proxy_http xforward headers»

Включим поддержку SSL и сгенерируем сертификаты.
APACHE_SERVER_FLAGS=»-DSSL»
mkdir /srv/obs/certs
openssl genrsa -out /srv/obs/certs/server.key 1024
openssl req -new -key /srv/obs/certs/server.key -out /srv/obs/certs/server.csr
openssl x509 -req -days 365 -in /srv/obs/certs/server.csr -signkey /srv/obs/certs/server.key -out /srv/obs/certs/server.crt
cat /srv/obs/certs/server.key /srv/obs/certs/server.crt > /srv/obs/certs/server.pem

Установим use_xforward:true в /srv/www/obs/webui/config/options.yml и /srv/www/obs/api/config/options.yml

Теперь один очень важный нюанс. Открываем файл /srv/www/obs/webui/config/environments/production.rb, ищем строчку CONFIG[‘frontend_host’] = «localhost» и вместо localhost пишем имя сервера, которое мы указали при генерации сертификата.
Если этого не сделать, то при попытке открыть WebUI или API, будете получать ошибку “ hostname does not match the server certificate”.

Выполним рестарт.
rcapache2 restart
rcobsapidelayed restart

Проверяем работоспособность.
После перезапуска Apache API должен быть доступен по адресу servername:444.
WebUI будет доступен по адресу servername.
Логин и пароль по умолчанию Admin/opensuse.
Подробно останавливаться на использовании WebUI не буду. Интерфейс интуитивно понятный и удобный.

Лучше больше внимания уделим использованию OSC (openSUSE Build Service Commander). Данный пакет доступен практически для всех дистрибутивов Linux. С его помощью мы сможем создавать проекты, пакеты, загружать исходные файлы.
Я пользуюсь Ubuntu, поэтому для установки использую:
apt-get install osc

Следующим шагом нужно создать файл конфигурации, который необходим для работы с нашим сервером. Создать его можно в автоматическом режиме, используя любую команду osc, к примеру, osc ls. Но проще создать в корне домашней директории файл .oscrc следующего содержания:

[general] apiurl = https://servername:444 use_keyring = 0 [https://servername:444] user = Admin pass = opensuse keyring = 0

Вместо servername пишем имя своего сервера. Имя опять же должно совпадать с указанным во время создания сертификата, иначе получите ошибку «Certificate Verification Error: Peer certificate commonName does not match host»
Проверяем подключение, выполнив команду osc ls (вывести листинг проектов).
Принимаем сертификат.
The server certificate failed verification
Would you like to
0 — quit (default)
1 — continue anyways
2 — trust the server certificate permanently
9 — review the server certificate
Enter choice [0129]: 2

Попробуем создать новый проект.
osc meta prj -e MyProject (MyProject – название вашего проекта).
После этого откроется xml-файл конфигурации нового проекта, где вам нужно будет, как минимум, указать Title и Description. Здесь же можно раскомментировать строки, в которых указано под какую систему будут собираться пакеты в данном проекте.

Пример xml конфигурации для пректа

  MyTestProject        x86_64 i586   x86_64 i586   x86_64 i586   x86_64 i586   x86_64 i586

Создание пакета происходит по такой же схеме
osc meta pkg -e MyProject MyPackage (MyProject – название вашего проекта, MyPackage – ваш новый пакет)

Теперь, когда проект и пакет созданы, нам нужно отправить на сервер файлы исходников, из которых будут собираться бинарные пакеты.
Сначала создадим локальную копию проекта у себя на рабочей машине.
osc co MyProject
После этого у вас должна появиться иерархия каталогов MyProject/MyPackage. Помещаем свои файлы исходников в каталог MyPackage, после чего добавляем их в контроль версий командой:
osc add MyProject/MyPackage /MyFiles
и закачиваем на сервер
osc ci MyProject/MyPackage -m «Your comment» –skip-validation
Результат сборки смотрим командой
osc results MyProject/MyPackage

Теперь, как и обещал, приведу отдельно краткий перечень команд для работы с проектами и пакетами из консоли.
Вывести список проектов.
osc ls

Создать проект.
osc meta prj -e ProjectName

Создать пакет.
osc meta pkg -e ProjectName PackageName

Удалить проект или пакет.
osc rdelete ProjectName/PackageName

Сделать локальную копию проекта.
osc co ProjectName

Добавить новые файлы в контроль версий.
osc add ProjectName/PackageName/YourFiles

Удалить исходные файлы.
osc rremove ProjectName PackageName SourceName
osc update ProjectName

Подтвердить изменения в проекте.
osc ci ProjectName -m «Your comment» —skip-validation

Подтвердить изменения в пакете.
osc ci Project Name/Package Name -m «Your comment»

Показать результат сборки
osc results Project Name/Package Name

Показать лог сборки (выполнять в каталоге пакета).
osc buildlog Platform Arch (osc buildlog xUbuntu_12.04 i586)

OpenBuildService
OpenSUSE

MSBuild Server

MSBuild Server improves the performance of .NET Core builds, which are invoked when you use the dotnet build command from the .NET CLI on Windows, Linux, or Mac .NET Core build environments. Instead of starting the build process each time a build is requested, much of the context is cached in a long-running process so it is available to be reused by the next build. MSBuild Server is not relevant to Visual Studio builds, because Visual Studio acts as a host for MSBuild and already caches all the necessary context.

MSBuild Server is generally not helpful in CI scenarios such as Azure Pipeline builds, because pipelines typically stand up a build environment on demand for each build and then dispose of it when the build is completed.

Enable MSBuild Server

MSBuild server is not enabled by default; to enable it, set the environment variable DOTNET_CLI_USE_MSBUILD_SERVER to true or 1 .

Once enabled, for the first time you start a new build process, the build server is launched. When you start the first build, it enables the cache. The cache is persisted after the completion of the first build; the second build therefore proceeds faster since the startup time is significantly reduced due to the cached information. The cache persists after the build is completed, but after an idle time of 15 minutes, it shuts down. Therefore, it is primarily beneficial in repetitive build scenarios where many builds are requested in close succession.

Читайте также: Что за программа тетрика

Shut down or disable MSBuild Server

There are a few different ways to disable the use of MSBuild server. If you just want to shut down the running server, you can issue the command dotnet build-server shutdown .

To disable the feature for all builds on a machine, you can set the system environment variable DOTNET_CLI_USE_MSBUILD_SERVER to 0 or false . You could also set this variable on a per-project basis in a tool like VS Code in launch.json .

To disable MSBuild Server for a particular invocation of a command-line build, you can use the option /nr:false (or /node-reuse:false ).

To disable the feature entirely, you can opt out of the change wave that enabled it; SET MSBuildDisableFeaturesFromVersion=»17.4″ . This disabled other features in the same change wave. For more information about change waves, see MSBuild change waves.

Determine the current status of the build server

You can view process status on the machine and look for MSBuild server processes. MSBuild server processes are launched with dotnet.exe and show a path to MSBuild.dll and the command option /nodemode:8 , where 8 indicates MSBuild Server ( /nodemode:1 indicates the normal MSBuild worker nodes).

Домашний билд-тест-сервер

Всем привет! Хочу рассказать о своём опыте настройки домашнего билд-тест-сервера.

Допустим, у вас есть хобби-проект, и вы работаете на нём в одиночку. Или вам просто нечем заняться, и вы решили поиграться с CI/CD, Linux администрированием, web разработкой.

Во-первых, почему именно домашний?

Ну, «домашний» значит, что вам не нужно ни за что платить (условно), что ресурсы ваши не ограничены — дисковое пространство, CPU (тоже условно), что у вас всё под контролем (root доступ, выбор операционной системы). Что вам не нужно вникать в правила пользования каким-то сторонним CI/CD сервисом, что вам придётся-таки разобраться с нюансами DevOps, пускай и в домашних условиях, пускай и на коленке.

Итак, допустим, у вас есть старый компьютер. У меня вот, например, такой завалялся: Fanless Mini PC Dual LAN Celeron J1900.

И я считаю, он идеально подходит для моих задач. Не шумит, маленький, у него есть wi-fi.

Следующий этап — это выбор операционной системы. Я давно пользуюсь LXLE и могу только рекомендовать этот дистрибутив.

Установка и настройка LXLE у меня проходит с подключенным монитором, мышкой, клавиатурой. На этом этапе важно добиться хорошего интернет соединения. Я рекомендую настроить как wi-fi, так и ethernet. Подумайте, куда вы запрячете ваш билд-сервер, чтобы у него был хороший доступ к интернету и в то же время можно было дотянуться рукой и перегрузить его, если что. _{(Если он повиснет, например, или сеть в нём глюканёт. Такое случается чаще, чем вы можете себе представить).}

Итак, после перегрузки вашего билд-сервера, он должен появляться в локальной сети и быть доступен через ssh. Активация ssh на билд-сервере:

sudo apt update sudo apt install openssh-server sudo systemctl status ssh sudo ufw allow ssh

Подключение через Putty или с другой Linux машины:

ssh username@ip_address

IP-адрес новоиспечённой машины можно узнать командой:

ifconfig

_{выполненной на самой машине, естественно 🙂}

Важный нюанс: зайдите в консоль управления вашим домашним роутером (тот самый, который раздаёт домашний интернет) и установите статический DHCP для вашего билд-сервера:

Вторая строка — это мой сервер. Это действие необходимо, чтобы сервер всегда был доступен по одному и тому же IP-адресу.

Если у вас два подключения (wi-fi и ethernet), то и IP-адреса будет два. Оба будут ссылаться на вашу машину.

Потренируйтесь удалённо перегружать сервер.

sudo reboot

После перегрузки ваш сервер должен стабильно появляться в локальной сети.

Если всё работает, можно отключать билд-сервер от монитора, периферийных устройств и прятать его в надёжное место _{(но так, чтобы он не перегревался, т.е. с минимальной вентиляцией приточного воздуха)}.

Теперь переходим к настройке софта.

Мой стэк: Java (Spring Boot), Angular.

Установите nginx и добейтесь nginx-приветствия по адресу http://

Перегрузите сервер и убедитесь, что nginx стартует автоматически.

Установите Jenkins. Вот отличная статья, как это сделать.

По умолчанию Jenkins стартует на порту 8080. У себя я настроил reverse proxy в nginx конфигурации. Jenkins доступен по адресу http://192.168.2.11/

sudo vim /etc/nginx/sites-enabled/default

 location / < proxy_pass http://127.0.0.1:8080; proxy_set_header X-Forwarded-Host $http_host; >

Снова перегружаем билд-сервер, убеждаемся, что всё автоматически стартует: nginx, jenkins, что jenkins доступен на 80-том порту.

Переходим к конфигурации Jenkins.

Начнём, как всегда, издалека 🙂

Создадим репозиторий на GitHub, добавим в него простое Spring Boot приложение. Потестируем его локально. Обратите внимание, что по умолчанию порт в Spring Boot такой же, как и у Jenkins: 8080.

Это легко исправить с помощью файла src/main/resources/application.properties в нашем тестовом приложении:

server.port=8000

Наша задача — автоматически редеплоить (перепускать обновленное) тестовое приложение на билд-сервере.

Создадим Jenkins Job. Для логина к закрытому репозиторию я использую Github personal access token:

Оказывается, его можно использовать в самом урле репозитория для беспарольного доступа.

Проверять изменения в репозитории будем каждые 15 минут:

А вот и наш билд:

Рассмотрим его поподробнее. Особенно следующую часть:

sudo systemctl stop lametric.service file="/opt/lametric/lametric.jar" if [ -f "$file" ] ; then rm "$file" fi cp /var/lib/jenkins/workspace/LaMetric/target/lametric-*.jar /opt/lametric/lametric.jar sudo systemctl start lametric.service

Итак, мы выполняем shell команды на той же машине, где запускается build job.

Что из себя представляет lametric.service?

vim /etc/systemd/system/lametric.service

[Unit] Description=Notify LaMetric about different events. After=syslog.target [Service] User=geniot Group=users WorkingDirectory=/opt/lametric ExecStart=/usr/bin/java -jar /opt/lametric/lametric.jar SuccessExitStatus=143 TimeoutStopSec=10 Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

Т.е. этот сервис запускает java процесс с параметрами:

/usr/bin/java -jar /opt/lametric/lametric.jar

Jenkins Job при успешном выполнении maven команд clean package начинает деплоить результат билда:

останавливает локально (для билд-сервера) запущенный lametric.service
удаляет старое приложение lametric.jar
копирует новое (только что собранное) с переименованием
запускает lametric.service

Чтобы всё это работало, необходимо создать папку /opt/lametric. Выдать ей права.

sudo mkdir /opt/lametric sudo chown geniot:users /opt/lametric -R sudo chmod 777 /opt/lametric -R

Важно: чтобы Jenkins мог перепускать сервисы, я добавил его в sudoers:

sudo visudo

jenkins ALL=(ALL) NOPASSWD: ALL

Также важно: данные настройки сгодятся для домашнего билд-сервера. Для чего-то более серьёзного нужно задуматься о привилегиях, которые вы выдаёте пользователю jenkins и папке, в которую он деплоит ваше приложение. _{(Но это отдельная история).}

Добавим контекст приложения в application.properties:

server.servlet.context-path=/lametric

Чтобы он не путался с Jenkins, который расположен в корне.

Добавим ещё один proxy в nginx:

 location /lametric < proxy_pass http://127.0.0.1:8000; proxy_set_header X-Forwarded-Host $http_host; >

не забываем перепускать nginx.

lametric.service добавляем в автостарт:

sudo systemctl enable lametric.service

меняем тестовое приложение (например, response от HelloWorldRestController)

import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import org.springframework.web.bind.annotation.RestController; @RestController public class HelloWorldRestController < Logger logger = LoggerFactory.getLogger(HelloWorldRestController.class); @RequestMapping(value = "/hello", method = RequestMethod.GET) public String handle() < return "New hello"; >>

commit, push
Ждём 15 минут _{(или запускаем job ручками)}, заходим на http://192.168.2.11/lametric/hello Убеждаемся, что всё работает _{(изменения видны)}.

Далее: добавление Angular, деплой в prod, настройка автоматического тестирования.

Расскажу об этом в следующей статье.

]]>При подготовке материала использовались источники:
https://habr.com/ru/sandbox/51731/
https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-server?view=vs-2022
https://habr.com/ru/articles/646269/

Build server что это за программа