Jak zainstalować i skonfigurować Buildbot na CentOS 7

• Wymagania wstępne
• Zainstaluj zależności Python
• Zainstaluj PostgreSQL
• Zainstaluj Buildbot
• Skonfiguruj Buildbot Master
• Skonfiguruj Buildbot Worker
• Konfigurowanie usługi systemowej
• Włączanie uwierzytelniania
• Zabezpieczanie Buildbota za pomocą Let's Encrypt SSL

Buildbot to otwarte narzędzie do ciągłej integracji oparte na języku Python, służące do automatyzacji budowy, testowania i wdrażania oprogramowania. Buildbot składa się z jednego lub więcej wzorca Buildbot i kilku pracowników. Buildbot master lub Buildmaster ma centralne sterowanie systemem. Odpowiada za zarządzanie środowiskiem kompilacji, pracownikami i podejmuje wszystkie decyzje dotyczące wysyłania zadań do pracowników. Buildmaster wykrywa zmiany w repozytorium kodu i wysyła polecenia lub zadania do pracowników w celu wykonania. Pracownicy wykonują zadania i zwracają wynik Buildmaster. Buildmaster następnie powiadamia programistów wieloma obsługiwanymi kanałami. W tym samouczku zainstalujemy Master Builder i Workbota na CentOS 7. Skonfigurujemy również uwierzytelnianie i Nginx jako bezpieczne odwrotne proxy.

Wymagania wstępne

• Instancja serwera Vultr CentOS 7 z co najmniej 1 GB pamięci RAM.
• Użytkownik sudo .
• Zarejestrowana nazwa domeny wskazuje na serwer.

W tym samouczku użyjemy 192.168.1.1jako publicznego adresu IP i ci.example.comnazwy domeny wskazanej na instancję Vultr. Pamiętaj, aby zastąpić wszystkie wystąpienia przykładowej nazwy domeny i adresu IP faktycznym.

Zaktualizuj system podstawowy za pomocą przewodnika Jak zaktualizować CentOS 7 . Po zaktualizowaniu systemu przejdź do instalacji PostgreSQL.

Zainstaluj zależności Python

Zainstaluj Pip, który jest menedżerem pakietów dla Pythona.

sudo yum -y install epel-release
sudo yum -y install python-pip gcc python-devel git
sudo pip install --upgrade pip

Zainstaluj PostgreSQL

Buildbot obsługuje wiele typów serwerów baz danych, takich jak MySQL, PostgreSQL i SQLite. W tym samouczku wykorzystamy PostgreSQL do obsługi serwera bazy danych Buildbot.

PostgreSQL to obiektowo-relacyjny system bazy danych, znany ze swojej stabilności i szybkości. Domyślne yumrepozytorium zawiera starą wersję PostgreSQL, więc dodaj repozytorium PostgreSQL.

sudo yum -y install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-1.noarch.rpm

Zainstaluj serwer bazy danych PostgreSQL.

sudo yum -y install postgresql10-server postgresql10-contrib postgresql10 

Zainicjuj bazę danych.

sudo /usr/pgsql-10/bin/postgresql-10-setup initdb

Uruchom serwer PostgreSQL i włącz go automatycznie podczas uruchamiania.

sudo systemctl start postgresql-10
sudo systemctl enable postgresql-10

Zmień hasło dla domyślnego użytkownika PostgreSQL.

sudo passwd postgres

Zaloguj się jako użytkownik PostgreSQL.

sudo su - postgres

Utwórz nowego użytkownika PostgreSQL dla Buildbot.

createuser bb_user

Możesz użyć dowolnej nazwy użytkownika zamiast bb_user, jeśli wolisz. PostgreSQL zapewnia psqlpowłokę do uruchamiania zapytań w bazie danych. Przejdź do powłoki PostgreSQL.

psql

Ustaw hasło dla nowo utworzonego użytkownika.

ALTER USER bb_user WITH ENCRYPTED password 'DBPassword';

Zastąp DBPasswordbezpiecznym hasłem.

Utwórz nową bazę danych dla instalacji Buildbot.

CREATE DATABASE buildbot OWNER bb_user;

Wyjdź ze psqlskorupy.

\q

Przejdź do sudoużytkownika.

exit

Edytuj pg_hba.confplik, aby włączyć uwierzytelnianie oparte na MD5.

sudo nano /var/lib/pgsql/10/data/pg_hba.conf

Znajdź następujące wiersze i zmień wartości peeroraz ident, w METHODkolumnie, odpowiednio na trusti md5.

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident

Po aktualizacji konfiguracja będzie wyglądać jak następujący tekst.

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

Zapisz plik i zamknij edytor. Zainstaluj adapter bazy danych PostgreSQL dla języka Python.

sudo pip install psycopg2

Uruchom ponownie PostgreSQL, aby zmiany mogły zostać wprowadzone.

sudo systemctl restart postgresql-10

Zainstaluj Buildbot

Zainstaluj Buildbot za pomocą Pip.

sudo pip install 'buildbot[bundle]' pyopenssl service_identity

Powyższe polecenie instalacji buildbota wraz z buildbot-www, buildbot-workeri kilka takich jak www wtyczek buildbot-waterfall-view.

Aby upewnić się, że Buildbot został pomyślnie zainstalowany, możesz to sprawdzić, sprawdzając wersję Buildbot.

buildbot --version

Dane wyjściowe powinny przypominać następujący tekst.

[user@vultr ~]$ buildbot --version
Buildbot version: 0.9.15.post1
Twisted version: 17.9.0

Zmodyfikuj reguły zapory, aby zezwolić na port 8010. Buildbot używa tego portu do nasłuchiwania żądań internetowych.

sudo firewall-cmd --zone=public --add-port=8010/tcp --permanent
sudo firewall-cmd --reload

Skonfiguruj Buildbot Master

Utwórz nowego nieuprzywilejowanego użytkownika, aby uruchomić procesy główne i robocze Buildbot. Nie zaleca się uruchamiania usług głównych Buildbot jako rootużytkownik.

sudo adduser buildbot
sudo passwd buildbot

Zaloguj się jako nowo utworzony buildbotużytkownik.

sudo su - buildbot

Skonfiguruj master Buildbot w /home/buildbot/masterkatalogu. Ten katalog będzie zawierał pliki konfiguracji, statusu i dziennika każdej kompilacji.

buildbot create-master --db 'postgresql://bb_user:DBPassword@localhost/buildbot' ~/master

Pamiętaj, aby zastąpić poświadczenia użytkownika bazy danych w powyższym poleceniu.

Uwaga: Jeśli chcesz używać bazy danych SQLite zamiast PostgreSQL, po prostu pomiń tę --db 'postgresql://bb_user:DBpassword@localhost/buildbot'opcję. Baza danych SQLite zostanie utworzona w tym samym katalogu.

Powyższe polecenie utworzy ~/masterkatalog do przechowywania plików Buildmaster. Zapisuje również dane w bazie danych PostgreSQL. Otrzymasz następujące dane wyjściowe.

[buildbot@vultr ~]$ buildbot create-master --db 'postgresql://bb_user:DBPassword@localhost/buildbot' ~/master
mkdir /home/buildbot/master
creating /home/buildbot/master/master.cfg.sample
creating database (postgresql://bb_user:DBPassword@localhost/buildbot)
buildmaster configured in /home/buildbot/master

Skopiuj przykładowy plik konfiguracyjny do pliku konfiguracji na żywo.

cp ~/master/master.cfg.sample ~/master/master.cfg

Edytuj plik konfiguracyjny.

nano ~/master/master.cfg

Znajdź następujące linie.

c['workers'] = [worker.Worker("example-worker", "pass")]
...

c['builders'].append(
    util.BuilderConfig(name="runtests",
      workernames=["example-worker"],
      factory=factory))
...

c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
...

c['buildbotURL'] = "http://localhost:8010/"
...

c['db'] = {
    'db_url' : "postgresql://bb_user:DBpassword@localhost/buildbot",
}

Powyższa konfiguracja zawiera wpis dla przykładowego pracownika. Zmodyfikujemy przykładowy wpis dla pracownika, na którym będziemy działać localhost. Zmień na example-workerdowolną odpowiednią nazwę dla localhostpracownika i zmień na passinne hasło. Zanotuj nazwę pracownika i hasło, ponieważ będziemy tego wymagać w dalszej części samouczka. Zmień nazwę pracownika na liście konstruktorów. Zmień nazwę aplikacji i URL projektu zgodnie ze swoimi potrzebami.

Zmień adres URL Buildbot z localhostna rzeczywistą nazwę domeny lub publiczny adres IP. Sprawdź również, czy informacje o bazie danych w pliku konfiguracyjnym są zgodne z faktycznymi poświadczeniami bazy danych.

Na końcu pliku dodaj c['buildbotNetUsageData'] = None. Ten parametr wyłączy wysyłanie informacji o wersji oprogramowania i szczegółach użycia wtyczki do programistów. Aby włączyć wysyłanie informacji o użytkowaniu, zmień opcję na Full.

Konfiguracja powinna wyglądać jak poniższy tekst.

c['workers'] = [worker.Worker("localhost-worker", "Password123")]
...    

c['builders'].append(
    util.BuilderConfig(name="runtests",
      workernames=["localhost-worker"],
      factory=factory))
...

c['title'] = "My Application CI"
c['titleURL'] = "https://example.com/my-app"
...

c['buildbotURL'] = "http://192.168.1.1:8010/"
...

c['db'] = {
    'db_url' : "postgresql://bb_user:DBpassword@localhost/buildbot",
}
...

c['buildbotNetUsageData'] = None

Zapisz plik i zamknij edytor. Sprawdź plik konfiguracyjny pod kątem błędów.

buildbot checkconfig ~/master

Jeśli plik konfiguracyjny nie zawiera błędów, zobaczysz następujące dane wyjściowe.

[buildbot@vultr ~]$ buildbot checkconfig ~/master
Config file is good!

Teraz, gdy wszystko jest poprawnie skonfigurowane, możesz uruchomić Buildbot master.

buildbot start ~/master

Zobaczysz następujące dane wyjściowe.

[buildbot@vultr ~]$ buildbot start ~/master
Following twistd.log until startup finished..
The buildmaster appears to have (re)started correctly.

Teraz, gdy master Buildbota uruchomił się poprawnie, interfejs użytkownika jest dostępny pod adresem http://192.168.1.1:8010. Powinieneś zobaczyć następujący interfejs Buildbot.

Skonfiguruj Buildbot Worker

Ponieważ zmodyfikowaliśmy już konfigurację pracownika ~/master/master.cfg, możemy przystąpić do tworzenia nowego pracownika.

buildbot-worker create-worker ~/worker localhost localhost-worker Password123

Upewnij się, że używasz dokładnie tej samej nazwy pracownika i hasła, jakie podano w ~/master/master.cfgpliku. Jeśli występuje niezgodność nazwy pracownika lub hasła, pracownik nie będzie mógł połączyć się z masterem Buildbot. Po pomyślnym wykonaniu zobaczysz następujące dane wyjściowe.

[buildbot@vultr ~]$ buildbot-worker create-worker ~/worker localhost example-worker pass
mkdir /home/buildbot/worker
mkdir /home/buildbot/worker/info
Creating info/admin, you need to edit it appropriately.
Creating info/host, you need to edit it appropriately.
Not creating info/access_uri - add it if you wish
Please edit the files in /home/buildbot/worker/info appropriately.
worker configured in /home/buildbot/worker

Informacje o pracowniku są przechowywane w /infokatalogu. Edytuj informacje administracyjne o deweloperze.

nano ~/worker/info/admin

Zastąp przykładową nazwę faktycznym imieniem i adresem e-mail.

Your Name <[email protected]>

Teraz otwórz plik zawierający informacje o hoście.

nano ~/worker/info/host

Zamień przykładową instrukcję na rzeczywistą informację o systemie hosta.

Localhost, CentOS 7

Dane administratora i hosta pracownika służą wyłącznie do informowania użytkowników o systemie. Możesz także dodać dodatkowe informacje o systemie, takie jak wersja Buildbot i wersja Twisted.

Uruchom pracownika.

buildbot-worker start ~/worker

Dane wyjściowe będą wyglądały jak następujący tekst.

[buildbot@vultr ~]$ buildbot-worker start ~/worker
Following twistd.log until startup finished..
The buildbot-worker appears to have (re)started correctly.

Aby sprawdzić, czy pracownik jest zarejestrowany, przejdź do interfejsu WWW Buildbota i przejdź do Builds >> Workerslewej nawigacji. Powinieneś zobaczyć, że pracownik jest gotowy i gotowy do budowy.

Aby uruchomić przykładową kompilację, aby sprawdzić, czy proces roboczy Buildbot działa poprawnie, przejdź do Builds >> Builders. Kliknij runtestsnazwę konstruktora, aby otworzyć interfejs konstruktora, a następnie kliknij Forceprzycisk, aby wymusić kompilację. Podaj swoje imię i kliknij Start Buildprzycisk, aby rozpocząć kompilację. Ponieważ jest to przykładowy test kompilacji w celu sprawdzenia środowiska Buildbot, zakończy się on za kilka sekund. Otrzymasz komunikat o powodzeniu i wynik kompilacji.

Konfigurowanie usługi systemowej

Chociaż wzorzec i proces roboczy Buildbot można łatwo uruchomić za pomocą powyższych poleceń, zaleca się używanie jednostek Systemd do uruchamiania i zarządzania usługami Buildbot. Zapewni to ich automatyczne uruchomienie przy ponownym uruchomieniu systemu i awariach.

Uwaga: Przełączenie na sudoużytkownikiem ponownie uruchamiając albo exitalbo su <username>. Odtąd wszystkie polecenia muszą być wykonywane przez sudoużytkownika.

Zatrzymaj działającą robotę roboczą i główną usługę Buildbot.

sudo su buildbot -c "buildbot stop /home/buildbot/master" 
sudo su buildbot -c "buildbot-worker stop ~/worker"

Utwórz nowy plik jednostki Systemd dla wzorca Buildbot.

sudo nano /etc/systemd/system/buildbot.service

Wypełnij plik.

[Unit]
Description=BuildBot master service 
After=network.target

[Service]
Type=forking
User=buildbot 
Group=buildbot 
WorkingDirectory=/home/buildbot/master 
ExecStart=/usr/bin/buildbot start
ExecStop=/usr/bin/buildbot stop
ExecReload=/usr/bin/buildbot restart

[Install]
WantedBy=multi-user.target

Uruchom główny Buildbot i włącz go automatycznie podczas uruchamiania.

sudo systemctl start buildbot
sudo systemctl enable buildbot

Utwórz nowy plik jednostki Systemd dla pracownika Buildbot.

sudo nano /etc/systemd/system/buildbot-worker.service

Wypełnij plik.

[Unit]
Description=BuildBot worker service
After=network.target

[Service]
Type=forking
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/worker
ExecStart=/usr/bin/buildbot-worker start
ExecStop=/usr/bin/buildbot-worker stop
ExecReload=/usr/bin/buildbot-worker restart

[Install]
WantedBy=multi-user.target

Uruchom proces roboczy Buildbot i włącz go, aby uruchamiał się automatycznie podczas uruchamiania.

sudo systemctl start buildbot-worker
sudo systemctl enable buildbot-worker

Możesz sprawdzić status usług.

sudo systemctl status buildbot buildbot-worker

Jeśli usługi działają płynnie, zobaczysz to w danych wyjściowych.

[user@vultr ~]$ sudo systemctl status buildbot buildbot-worker
● buildbot.service - BuildBot master service
...
Active: active (running) since Fri 2018-01-12 16:00:59 UTC; 1min 25s ago
...
Jan 12 16:00:59 vultr.guest systemd[1]: Started BuildBot master service.

● buildbot-worker.service - BuildBot worker service
...
Active: active (running) since Fri 2018-01-12 16:02:00 UTC; 24s ago
...
Jan 12 16:02:00 vultr.guest systemd[1]: Started BuildBot worker service.

Włączanie uwierzytelniania

Domyślnie uwierzytelnianie nie jest włączone w interfejsie internetowym Buildbot. W przypadku witryn internetowych zdecydowanie zaleca się skonfigurowanie uwierzytelniania, aby tylko autoryzowani użytkownicy mogli wykonywać zadania administracyjne. Aby skonfigurować uwierzytelnianie, otwórz ponownie główny plik konfiguracyjny Buildbot.

sudo su buildbot -c "nano /home/buildbot/master/master.cfg"

Dodaj następujące wiersze na końcu pliku.

c['www']['authz'] = util.Authz(
       allowRules = [
           util.AnyEndpointMatcher(role="admins")
       ],
       roleMatchers = [
           util.RolesFromUsername(roles=['admins'], usernames=['admin_user'])
       ]
)
c['www']['auth'] = util.UserPasswordAuth({'admin_user': 'AdminPassword'})

Zamień oba wystąpienia admin_userna rzeczywistą nazwę użytkownika, której chcesz użyć, i AdminPasswordna silne hasło.

Sprawdź błędy w pliku konfiguracyjnym.

sudo su buildbot -c "buildbot checkconfig /home/buildbot/master"

Uruchom ponownie główną usługę Buildbot, aby zmiany mogły zostać wprowadzone.

sudo systemctl restart buildbot

Przejrzyj ponownie interfejs sieciowy, aby zobaczyć, że anonimowi użytkownicy mogą wyświetlać tylko podstawowe informacje o serwerze kompilacji. Teraz zaloguj się przy użyciu poświadczeń ustawionych w master.cfgpliku, a zobaczysz, że wszystkie inne funkcje administracyjne są dostępne tylko dla zalogowanego użytkownika administratora.

Zabezpieczanie Buildbota za pomocą Let's Encrypt SSL

Domyślnie Buildbot nasłuchuje na porcie 8010w niezabezpieczonych połączeniach. HTTPSZaleca się zabezpieczenie interfejsu sieciowego za pomocą, aby zapewnić bezpieczeństwo danych podczas transportu z przeglądarki na serwer. W tej części samouczka zainstalujemy i zabezpieczymy Nginx za pomocą Let's Encrypt darmowych certyfikatów SSL. Serwer WWW Nginx będzie działał jako odwrotny serwer proxy do przekazywania przychodzących żądań do punktu końcowego HTTP Buildbota.

Zainstaluj Nginx.

sudo yum -y install nginx

Uruchom Nginx i włącz automatyczne uruchamianie podczas uruchamiania.

sudo systemctl start nginx
sudo systemctl enable nginx

Zainstaluj Certbot, czyli aplikację kliencką Let's Encrypt CA.

sudo yum -y install certbot

Aby móc zażądać certyfikatów, musisz zezwolić na porty 80i / 443lub standardy HTTPi HTTPSusługi za pośrednictwem zapory. Usuń także port 8010, który nasłuchuje niezabezpieczonych połączeń.

sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --zone=public --remove-port=8010/tcp --permanent
sudo firewall-cmd --reload

Uwaga: Aby uzyskać certyfikaty z Let's Encrypt CA, domena, dla której mają być generowane certyfikaty, musi być skierowana w stronę serwera. Jeśli nie, dokonaj niezbędnych zmian w rekordach DNS domeny i poczekaj na propagację DNS przed ponownym żądaniem certyfikatu. Certbot sprawdza urząd domeny przed podaniem certyfikatów.

Wygeneruj certyfikaty SSL.

sudo certbot certonly --webroot -w /usr/share/nginx/html -d ci.example.com

Wygenerowane certyfikaty prawdopodobnie będą przechowywane w /etc/letsencrypt/live/ci.example.com/katalogu. Certyfikat SSL będzie przechowywany jako, fullchain.pema klucz prywatny będzie przechowywany jako privkey.pem.

Ważność certyfikatów Let's Encrypt wygasa za 90 dni, dlatego zaleca się skonfigurowanie automatycznego odnawiania certyfikatów za pomocą zadań Cron.

Otwórz plik zadania cron dla rootużytkownika.

sudo crontab -e

Dodaj następujący wiersz na końcu pliku.

30 5 * * * /usr/bin/certbot renew --quiet

Powyższe zadanie crona będzie uruchamiane codziennie o 5:30. Jeśli termin ważności certyfikatu upływa, zostanie on automatycznie odnowiony.

Teraz zmień domyślny plik konfiguracyjny Nginx, aby usunąć default_serverlinię.

sudo sed -i 's/default_server//g' /etc/nginx/nginx.conf

Utwórz nowy plik konfiguracyjny dla interfejsu WWW Buildbot.

sudo nano /etc/nginx/conf.d/buildbot.conf

Wypełnij plik.

upstream buildbot {
server 127.0.0.1:8010;
}

server {
    listen 80 default_server;
    server_name ci.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    server_name ci.example.com;

    root html;
    index index.html index.htm;

    ssl on;
    ssl_certificate         /etc/letsencrypt/live/ci.example.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/ci.example.com/privkey.pem;

    ssl_session_cache      shared:SSL:10m;
    ssl_session_timeout  1440m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

    access_log  /var/log/nginx/buildbot.access.log;

    proxy_set_header HOST $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-Server  $host;
    proxy_set_header X-Forwarded-Host  $host;

    location / {
        proxy_pass http://buildbot;
    }
    location /sse/ {
        proxy_buffering off;
        proxy_pass http://buildbot/sse/;
    }
    location /ws {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://buildbot/ws;
        proxy_read_timeout 6000s;
    }
}

Sprawdź błędy w nowym pliku konfiguracyjnym.

sudo nginx -t

Jeśli wyświetli się następujący wynik, konfiguracja jest wolna od błędów.

[user@vultr ~]$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli wystąpił jakiś błąd, sprawdź dokładnie ścieżkę do certyfikatów SSL. Uruchom ponownie serwer WWW Nginx, aby wprowadzić zmianę w konfiguracji.

sudo systemctl restart nginx

Otwórz plik konfiguracyjny Buildmaster.

sudo su buildbot -c "nano /home/buildbot/master/master.cfg"

Znajdź następujący wiersz.

c['buildbotURL'] = "http://192.168.1.1:8010/"

Zmień adres URL zgodnie z nazwą domeny, której używasz.

c['buildbotURL'] = "https://ci.example.com/"

Uruchom ponownie główną usługę Buildbot.

sudo systemctl restart buildbot

Teraz możesz uzyskać dostęp do pulpitu nawigacyjnego Buildbot pod adresem https://ci.example.com. Zobaczysz, że połączenia z Buildbot są teraz zabezpieczone przez SSL.

Zaloguj się przy użyciu poświadczeń administratora i dodaj swój pierwszy potok, aby rozpocząć tworzenie aplikacji.