TOC

FreeBSDでBuildbotをセットアップする方法

_著者はhttps://www.brightfunds.org/funds/open-internet-free-speech[Open Internet / Free Speech Fund]を選択してhttps://do.co/w4do-ctaの一部として寄付を受け取りました[寄付のために書く]プログラム。

前書き

Buildbotは、continuous integration（CI）の目的で一般的に使用されるジョブスケジューリングシステムです。 CIは、通常、ソフトウェアを定期的に、すべての変更に対して自動的に構築およびテストすることで構成されるソフトウェア開発プラクティスです。 一般的にCIプラットフォームとして使用されますが、Buildbotはコンピューター上で実行される自動化されたタスクにも使用できます。 Buildbotのタスク実行構成には、4つのコンポーネントが含まれます。

  • 変更元：これらは、Gitリポジトリ内の変更などの変更を検出し、それらについてスケジューラに通知します

  • スケジューラー：スケジューラーは、受信した変更に応じてビルダーをトリガーします

  • ビルダー：これらには、ソフトウェアプロジェクトのコンパイルなど、実際のビルド手順が含まれます

  • レポーター：レポーターは、ビルド結果を使用して、失敗の電子メールまたはその他の通知を送信します

Buildbotは、すべてのビルド構成およびその他の設定を実行およびチェックし、実際のビルドをワーカーに配布する少なくとも1つの_Buildbot master_を介して機能します。 さらに、マスターはブラウザーベースのユーザーインターフェイスサブコンポーネントを提供します。これは、有効になっている場合、ビルドのトリガーまたは表示、ステータスレポートおよびその他の設定の確認に使用されます。 マスターに接続してコマンドを受信する、つまりビルドを実行する1つ以上の_Buildbotワーカー_もあります。

このガイドでは、FreeBSD jailを使用して、各Buildbotコンポーネントを個別の分離された環境にインストールして実行します。 次に、Nginx Webサーバーを使用してBuildbotを提供し、ローカルマシンのWebブラウザーを使用してそのWebインターフェイスにアクセスします。 このガイドを完了すると、サンプルプロジェクトビルドを使用した作業セットアップが作成され、独自のCIまたはその他のユースケースに拡張する準備が整います。

前提条件

このガイドを始める前に、次のものが必要です。

  • FreeBSD 11.2を実行しているサーバーでも、サポートされている新しいバージョンと古いバージョンのFreeBSDが動作するはずです。 FreeBSDを初めて使用する場合は、https：//www.digitalocean.com/community/tutorials/how-to-get-started-with-freebsdのガイドに従ってこのサーバーをカスタマイズすると役立つ場合があります[ FreeBSDの使用を開始する方法]。

  • サーバーにインストールされたNginx。 FreeBSD 11.2にNginxをインストールする方法のガイドに従って、これを設定する方法をお読みください。

安全なHTTPSを使用してBuildbotウェブインターフェースをホストする場合は、次のものも必要です。

  • 所有および管理する登録済みドメイン名。 登録済みのドメイン名をまだお持ちでない場合は、多数のドメイン名レジストラーのいずれかに登録できます（例： Namecheap、GoDaddyなど）。

  • ドメインがサーバーのパブリックIPアドレスを指すDNS レコード。 これは、Let’s Encryptが証明書を発行しているドメインを所有していることを検証する方法のために必要です。 たとえば、「+ example.com 」の証明書を取得する場合、検証プロセスが機能するためには、そのドメインがサーバーに解決される必要があります。 これを追加する方法の詳細については、https：//www.digitalocean.com/docs/networking/dns/quickstart/ [このDNSクイックスタートガイド]を参照してください。 このチュートリアルでは、ドメイン名の例として「 example.com +」を使用します。

  • ドメインのSSL / TLS証明書。 FreeBSDでLet’s Encryptを使用してNginxを保護する方法に従って設定してください。

ステップ1 – Buildbotマスターおよびワーカー用のJailsのセットアップ

Buildbotでは、外部の貢献者がシステム上でコードを実行できるため、さまざまなコンポーネントを分離して、任意または悪意のあるコードがサーバーのリソースを占有しないようにすることをお勧めします。 このチュートリアルでは、FreeBSDの刑務所を使用してこれを行います。

LXC、Docker、その他のコンテナメカニズムと同様に、FreeBSDの刑務所はホストシステムからの軽量な分離を提供します。 刑務所内で実行されているプロセスは、刑務所がすでにアクセスを許可されているリソースにのみアクセスできます。それ以外の場合は、他のFreeBSD環境と同様に動作します。 Jailsは同じカーネルを共有しますが、通常はFreeBSDベースシステムのコピーを持つファイルシステムで実行されます。これは、ホストカーネルと互換性のあるFreeBSDの任意のバージョンである可能性があります。 ほとんどのワークロードでは、ホストでのタスク実行と刑務所での実行のパフォーマンスの違いは目立ちません。

FreeBSD刑務所の作成と管理を支援するいくつかの外部ソフトウェアパッケージが存在します。 これらはいずれも事実上の標準ではないため、オペレーティングシステムに組み込まれているhttps://www.freebsd.org/cgi/man.cgi?query=jail.conf&sektion=5&n=1[jail configuration mechanism]を使用します。

まず、システムの刑務所用に別のネットワークインターフェイスを作成します。 刑務所では、カーネルは刑務所に割り当てられた最初のIPv4 / IPv6アドレスにネットワーク接続を書き換えます。 たとえば、最初に割り当てられたIPアドレスがパブリックで、jail内のサービスが「127.0.0.1：1234」をリッスンする場合、ポート「1234」はパブリックにアクセスできます。 https://www.freebsd.org/doc/handbook/jails-ezjail.html [推奨プラクティス]は、刑務所用の個別のネットワークインターフェースを持つことです。 プライマリループバックインターフェイス（ + lo0 +）を別のインターフェイス（ + lo1 +）に_cloning_するというこの推奨事項に従います。 ネットワーク「+ 10.0.0.0 / 24 +」を使用しますが、他の重複しないネットワークでも機能します。

起動時に作成されるクローンインターフェイスを設定することから始めます。 この `+ sysrc `コマンドは、ルールを ` / etc / rc.conf +`ファイルに書き込みますが、インターフェース自体は作成しません：

sudo sysrc cloned_interfaces+=lo1

次に、次のコマンドでネットワークインターフェイスを作成します。

sudo service netif cloneup

インターフェイスの状態とIPは次の方法で確認できます。

ifconfig lo1
Outputlo1: flags=8008<,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: lo

この出力は、インターフェイスは存在するが、まだIPアドレスがリストおよび添付されていないことを示しています。 そのフラグ `+ LOOPBACK +`は、このインターフェースがローカルでのみ使用可能であり、実際のハードウェアデバイスを表していないことを意味します。

次に、好みのエディターを使用してマスターjailの新しい構成ファイルを開きます。 ここでは、 `+ ee +`を使用します。

sudo ee /etc/jail.buildbot-master.conf

次に、ファイルに次のコンテンツを追加します。これにより、 `+ buildbot-master +`という名前のマスターjailが構成されます。

/etc/jail.buildbot-master.conf

buildbot-master {
   host.hostname = buildbot-master.localdomain;
   ip4.addr = "lo1|10.0.0.2/24";
   path = "/usr/jails/buildbot-master";
   exec.start = "/bin/sh /etc/rc";
   exec.stop = "/bin/sh /etc/rc.shutdown";
   mount.devfs; # need /dev/*random for Python
   persist;
}

このコードは、jailネットワークインターフェイスの固定ホスト名とIPアドレス「10.0.0.2」を割り当て、ルートファイルシステム「+ / usr / jails / buildbot-master 」を指定します。 ここで使用される ` exec.start `および ` exec.stop `値は、jailの ` start `および ` stop `サービスがブートプロセスのように動作し、 ` / etcにある起動スクリプトとシャットダウンスクリプトを使用することを宣言します/ + `ディレクトリ。 `+ persist +`オプションを使用すると、すべてのプロセスが終了してもjailを実行し続けることができます。

可能なマスターjail設定の詳細については、https：//www.freebsd.org/cgi/man.cgi？query = jail＆sektion =＆n = 1 [jail（8）]マンページをご覧ください。

このコンテンツを追加したら、エディターを保存して終了します。 `+ ee `を使用している場合は、 ` CTRL + C `を押し、 ` exit `を入力して、 ` ENTER +`を押します。

マスターjailの設定ファイルは、グローバルjail設定ファイル、 `+ / etc / jail.conf +`とは別です。 このため、既知の刑務所のリストにマスター刑務所の名前を追加する必要があります。

sudo sysrc "jail_list+=buildbot-master"

次に、 `+ jail_list +`にリストされているjailを有効にして、ブート時に自動的に開始します。

sudo sysrc jail_enable=YES

`+ / etc / jail.conf `グローバルファイルで設定されたシステムに既にjailがあり、以前に ` jail_list `を使用したことがない場合、この設定を有効にすると、 ` jail_list +`内のjailのみが自動になります-startを実行すると、既存のjailをリストに追加できます。

次に、マスターjailのルートディレクトリを作成し、FreeBSDシステムを抽出します。

刑務所のルートファイルシステムディレクトリが存在することを確認します。 前のメモでZFSコマンドを実行した場合、これは既に行われているため、このコマンドをスキップできます。

sudo mkdir -p /usr/jails/buildbot-master

次に、FreeBSD 11.2ベースシステムアーカイブをダウンロードします。 最初にルート証明書をインストールして、ダウンロードサーバーを信頼します。

sudo pkg install ca_root_nss

このコマンドは、 `+ ca_root_nss `パッケージのインストールを承認するように促します。 そのためには、「 y 」を押してから「 ENTER +」を押します。

次に、アーカイブをダウンロードします。

fetch -o /tmp/base.txz "https://download.freebsd.org/ftp/releases/amd64/11.2-RELEASE/base.txz"

このファイルの内容を刑務所のルートファイルシステムとして抽出します。

sudo tar -x -f /tmp/base.txz -C /usr/jails/buildbot-master

このガイドでは、刑務所に含まれるワーカーを1つだけインストールするプロセスについて説明します。これは、マスターと同じ方法で構成し、ダウンロードしたばかりのベースシステムを再利用します。 `+ ee +`コマンドを使用して、ワーカーjailの別の新しい設定ファイルを開きます。

sudo ee /etc/jail.buildbot-worker0.conf

このファイルに次のコンテンツを追加します。

/etc/jail.buildbot-worker0.conf

buildbot-worker0 {
   host.hostname = buildbot-worker0.localdomain;
   ip4.addr = "lo1|10.0.0.3/24";
   path = "/usr/jails/buildbot-worker0";
   exec.start = "/bin/sh /etc/rc";
   exec.stop = "/bin/sh /etc/rc.shutdown";
   mount.devfs; # need /dev/*random for Python
   persist;
}

これらの行を見て、ワーカーjailがマスターとは異なるホスト名、IP、およびルートファイルシステムディレクトリを持っていることに注意してください。 このファイルを保存して閉じます。

繰り返しますが、グローバルな `+ / etc / jail.conf +`の代わりに別個のjail設定ファイルを使用しているため、既知のjailのリストに名前を追加します。

sudo sysrc "jail_list+=buildbot-worker0"

マスター用に行ったように、既にダウンロードしたFreeBSD 11.2ベースシステムを抽出します。

sudo mkdir /usr/jails/buildbot-worker0
sudo tar -x -f /tmp/base.txz -C /usr/jails/buildbot-worker0

この時点で、両方のjailが設定され、追加のパッケージがインストールされていないFreeBSDベースシステムが含まれています。 刑務所を始めましょう：

sudo service jail start

次のコマンドを使用して、システムで実行中のすべてのjailをリストすることにより、起動が成功したかどうかを確認します。

jls

これにより、サーバーで現在実行中のjailを示す次のような出力が返されます。

Output   JID  IP Address      Hostname                      Path
    1  10.0.0.2        buildbot-master.localdomain   /usr/jails/buildbot-master
    2  10.0.0.3        buildbot-worker0.localdomain  /usr/jails/buildbot-worker0

これにより、刑務所が期待どおりに実行されていることが確認されます。 ただし、この時点では、彼らはインターネットにアクセスできません。つまり、その中にBuildbotパッケージをインストールすることはできません。 これを解決するには、読み続けてください。

ステップ2 –刑務所のインターネットアクセスを設定する

マスター刑務所と労働者刑務所は動いていますが、どちらもインターネットから遮断されています。 パッケージをインストールし、相互に通信できる必要があるため、インターネットに公開する必要があります。

これを解決するには、ホストのDNSリゾルバー設定を両方の刑務所にコピーします。

sudo cp /etc/resolv.conf /usr/jails/buildbot-master/etc/resolv.conf
sudo cp /etc/resolv.conf /usr/jails/buildbot-worker0/etc/resolv.conf

次に、刑務所からの発信インターネットトラフィックをルーティングします。 これを行うには、FreeBSDの組み込みファイアウォールであるIPFWを使用して、NAT（ネットワークアドレス変換）ネットワークルールを設定します。 この手順を完了すると、jailネットワークから出て行くトラフィックは、ホストのパブリックIPアドレスに変換されます。

前提条件からhttps://www.digitalocean.com/community/tutorials/how-to-secure-nginx-letsencrypt-freebsd[Let’s Encrypt tutorial]を実行した場合、ファイアウォールへのアクセスを許可するように既に設定されています。 Webサーバー。 その場合、以下の手順のいくつかは冗長になりますが、再度実行しても問題はありません。

次のコマンドを使用して、定義済みの「+ workstation 」ファイアウォールルールを「 rc.conf 」ファイルに含めます。 ` workstation +`ルールはサーバーを保護しますが、ホストへのpingや動的ホスト構成プロトコルなどの基本的なサービスは許可します：

sudo sysrc firewall_type="workstation"

次に、外部からWebサーバーポートへのアクセスを許可します。 次のコマンドは、SSHのポート「22」を介したトラフィックを許可します。ポート `+ 80 `により、BuildbotをHTTP経由で提供できます。また、ポート ` 443 `により、BuildbotをHTTPS経由で提供できます。 Let's Encryptでサーバーを保護した場合、これらの3つのポートはすべて必要ですが、まだ保護していない場合は、ポート「+443」を除外できます。

sudo sysrc firewall_myservices="22/tcp 80/tcp 443/tcp"

`+ firewall_myservices +`ディレクティブで指定されたポートへの任意のIPアドレスからのアクセスを許可します：

sudo sysrc firewall_allowservices="any"

ブート時に起動するようにファイアウォールを構成します。

sudo sysrc firewall_enable=YES

次に、基本的なルールでファイアウォールを開始します。 次の「+ nohup 」コマンドは、ファイアウォールの起動の中断を回避し、「 stderr 」と「 stdout +」の両方を一時的なログファイルにリダイレクトします。 これは、ファイアウォールルールが一貫性のない状態のままにならないようにするために重要です。これにより、SSH経由でリモートホストにアクセスできなくなる可能性があります。

sudo nohup service ipfw start >/tmp/ipfw.log 2>&1

+ csh +`または `+ tcsh +`シェルを使用している場合、このリダイレクトにより、出力に `+ Ambiguous output redirect。+`が表示されます。 これらのシェルのいずれかを使用している場合は、「+ sudo nohup service ipfw start>＆/ tmp / ipfw.log + `を次のように実行して、 + ipfw + `を起動します。

この時点で、ファイアウォールサービスが開始され、セキュリティで保護されていないポートへの接続からホストを保護し始めます。

次に、インターネットに接続するホストのネットワークインターフェイスを決定する必要があります。 次を実行してこれを見つけます。

ifconfig

このコマンドは、いくつかの異なるインターフェースを出力する場合があります。 ホストがインターネットに接続するために使用するものは、サーバーのパブリックIPアドレスを含むものです。 例として、次の出力例は、「+ vtnet0 +」がホストで使用されるネットワークインターフェイスであることを示しています。

Outputvtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
   ether 9a:3e:fa:2a:5f:56
   hwaddr 9a:3e:fa:2a:5f:56
   inet6 fe80::983e:faff:fe2a:5f56%vtnet0 prefixlen 64 scopeid 0x1
   inet  netmask 0xffffffc0 broadcast
   inet 10.10.0.23 netmask 0xffff0000 broadcast 10.10.255.255
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet 10Gbase-T <full-duplex>
   status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
   inet 127.0.0.1 netmask 0xff000000
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: lo
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   inet 10.0.0.2 netmask 0xffffff00
   inet 10.0.0.3 netmask 0xffffff00
   inet6 fe80::1%lo1 prefixlen 64 scopeid 0x3
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: lo

このインターフェースを書き留めてから、その名前をグローバルに構成します。

sudo sysrc firewall_nat_interface=

新しいファイアウォール構成スクリプトファイルを開きます。

sudo ee /usr/local/etc/ipfw.rules

次に、ファイルに次のコンテンツを追加し、IPFWのファイアウォールルールを定義します。

/usr/local/etc/ipfw.rules

#!/bin/sh
set -e

# Add basic rules as defined by firewall_type, firewall_myservices, etc.
. /etc/rc.firewall

# External network interface
ext_if="$firewall_nat_interface"

# The interface we chose for communication between jails
jail_if="lo1"

for interface in "$ext_if" "$jail_if"; do
   if [ -z "$interface" ]; then
       >&2 echo "Missing network interface"
       exit 1
   fi
   if ! ifconfig $interface >/dev/null 2>&1; then
       >2 echo "No such network interface: $interface"
       exit 1
   fi
done

ipfw nat 123 config if $ext_if
ipfw add 1 allow all from any to any via $jail_if
ipfw add 2 nat 123 ip4 from any to any in via $ext_if
ipfw add 501 skipto 20000 udp from any to any 53 out via $ext_if keep-state
ipfw add 502 skipto 20000 udp from any to any 67 out via $ext_if keep-state
ipfw add 503 skipto 20000 tcp from any to any out via $ext_if setup keep-state
ipfw add 504 skipto 20000 icmp from any to any out via $ext_if keep-state
ipfw add 19999 deny all from any to any
ipfw add 20000 nat 123 ip4 from any to any out via $ext_if
ipfw add 20001 allow ip from any to any

スクリプトの各部分が行うことは次のとおりです。

  • +. / etc / rc.firewall + `には、システムの事前定義済みIPFWルールスクリプトが含まれています。このスクリプトは、 + / etc / rc.conf + の + firewall _ * + `変数の設定に従って基本ルールを追加します。

  • 次のブロックは、構成されたすべてのインターフェースが存在するかどうかを確認します。 これは安全のためであり、設定に誤りがある場合はスクリプトを早期に終了します。

  • `+ ipfw `で始まるディレクティブは、実際のファイアウォール設定とルールを追加します。 ` ipfw add +`で始まる行に追加された各ルールには番号があります。 ファイアウォールはこれらの番号を使用して、ルールを順番に評価します。

  • `+ ipfw nat 123 config if $ ext_if +`は、IDが「123」のカーネル内NATファシリティを作成して、パブリックに面したネットワークインターフェイスを使用してトラフィックを変換します。

  • `+ ipfw add 1は、$ jail_if を介してanyからanyへのすべてを許可します。`jail間のすべてのトラフィックを許可します。 「 allow +」ルールが一致すると、ルール処理が停止し、パケットの通過が許可されることに注意してください。

  • 「+ ipfwは、$ ext_if を介してanyからanyに2 nat 123 ip4を追加します」は、外部インターフェイス上のすべての着信IPv4パケットを変換します。 これは、「 ipfw add 20000 …​ +」の説明で説明されているように、発信パケットの変換に対応するものとして必要です。

  • + ipfw add 501 skipto 20000 udp to any to any 53 through $ ext_if keep-state +`と次の `+ skipto +`ルールは、ネットワークアドレス変換を許可および検討するアウトバウンドトラフィックを定義します。 一致する場合、NATを実行するルール「+20000+」にジャンプして処理が続行されます。 ルール番号 `+ 501 +`は、 `+ 00300 deny ipなど、ローカルのみのネットワーク（ + 127.0.0.0 / 8 + および + :: 1 + `）からのトラフィックを拒否するデフォルトのループバックルールの後に意図的に付けられています。 127.0.0.0/8からany + `まで。 `+ sudo ipfw list +`を実行して、現在アクティブなファイアウォールルールを確認します（ただし、上記の変更はまだ適用していません）。

  • 「+ skipto 」ルールを除き、「 / etc / rc.firewall 」スクリプトが特定の基本ルールを挿入するルール「+2」と「19999」の間に意図的なギャップがあります。 上記の「+ skipto 」ルールのいずれも一致しない場合、基本ルールはループバック、着信ICMP pingメッセージ、および「 firewall_myservices +」で指定されたポートを含むさまざまなタイプのトラフィックを許可します。

  • `+ ipfw add 19999 deny all to any to any `は、すべての基本的なルールの後に来て、非NATルール処理の終了を保証し、以前の ` allow +`ルールと一致しなかったすべてのトラフィックを本質的に禁止します。

  • `+ ipfw add 20000 nat 123 ip4 from any to any out via $ ext_if +`は、すべてのアウトバウンドIPv4パケットのアドレスを外部インターフェイスに変換します。 このチュートリアルでは、刑務所にはIPv4アドレスのみが割り当てられているため、ここでIPv4のみが必要です。

  • 「+ ipfw add 20001 allow any to any 」は、「 nat 」ルールのワンパスモードをオフにした場合にのみ必要です。この場合、ルール「+20000」を通過した後に処理が続行されます。別のルールを使用してこれらのパケットを明示的に許可します。 デフォルトのワンパスモードでは、ファイアウォールは「+ nat 」ルールで処理を停止するため、ルール「+20001」を無視します。

ファイルを保存し、エディターを終了します。

定義済みの基本的なファイアウォールルールを `+ ipfw.rules `スクリプトで定義されたルールで修正したいので、 ` rc.conf +`ファイルでこのスクリプトを指す必要があります。 次のコマンドは、ファイアウォールが起動するたびに実行されるようにスクリプトを構成します。

sudo sysrc firewall_script="/usr/local/etc/ipfw.rules"

このセットアップでは、IPFWのカーネル内NATサポートを使用するため、ブート時に各カーネルモジュールをロードするようにシステムに指示する必要があります。 さらに、再起動を必要とせずにすぐにモジュールをロードします。

sudo sysrc -f /boot/loader.conf ipfw_nat_load=YES
sudo kldload ipfw_nat

ファイアウォールを再起動して、拡張ファイアウォールルールスクリプトを有効にします。

sudo nohup service ipfw restart >/tmp/ipfw.log 2>&1

繰り返しますが、 `+ csh `シェルまたはその派生物（ ` tcsh `など）を使用している場合は、前のコマンドの代わりに ` sudo nohup service ipfw restart>＆/ tmp / ipfw.lo +`を実行して再起動しますファイアウォール：

ファイアウォールルールが正しくロードされていることを確認します。

cat /tmp/ipfw.log

ファイアウォールルールが一覧表示され、成功メッセージが続きます。

OutputFlushed all rules.
00100 allow ip from any to any via lo0
[...]
65500 deny ip from any to any
Firewall rules loaded.

次を使用して、インストールされているファイアウォールルールをいつでも表示できます。

sudo ipfw list
Output00001 allow ip from any to any via lo1
00002 nat 123 ip from any to any in via em0
[...]
65535 deny ip from any to any

すべてのファイアウォールルールを設定すると、刑務所はインターネットにアクセスできるようになります。 刑務所内からウェブページをダウンロードしてみると確認できます：

sudo jexec buildbot-master fetch -q -o- http://example.com/
Output<!doctype html>
<html>
<head>
   <title>Example Domain</title>
[...]

これで、通常のオペレーティングシステムのように実行する両方の刑務所を正常に準備し、各刑務所のインターネットアクセスを設定して、両方を開始しました。 このチュートリアルの次の2つのステップでは、マスターコンポーネントとワーカーコンポーネントの両方をインストールし、それらをサービスとして実行します。

ステップ3 – Buildbotマスターのインストールと実行

Buildbotのコンポーネントはいくつかのパッケージに分割されています。 マスターコンポーネントを実行するには、 `+ py36-buildbot `パッケージのみをインストールする必要がありますが、このガイドでは、Webインターフェースパッケージ ` py36-buildbot-www +`のインストール方法についても説明します。

さまざまなコンポーネントを分割するためにjailを使用しているため、マスターjailで* root *シェルを開くことから始めます。

sudo jexec buildbot-master csh

このガイドでは、jailシェル内で実行する必要がある場合、シェルコマンドブロックは異なる色でマークされていることに注意してください。 さらに、コマンドプロンプトには、刑務所のユーザープロファイル（* root ユーザーまたは非特権 buildbot-master *ユーザー）が反映され、そのコマンドを実行する必要があります。

パッケージをインストールします。

pkg install py36-buildbot py36-buildbot-www

このjailで `+ pkg `パッケージマネージャーをまだインストールまたは使用していない場合、ブートストラップを許可するかどうかを確認するプロンプトが表示されます。 これを行うには、「 y 」を押してから「 ENTER 」を押します。 次に、もう一度「 y +」と入力して、Buildbotパッケージのインストールを承認します。

次に、マスターサービスを実行するための通常の非特権ユーザーを作成します。 次のコマンドはこのユーザーにランダムなパスワードを割り当てますが、ホスト（jailの外部）の* root *ユーザーがパスワードを変更したり、パスワードなしでjail内のユーザーになることができるため、覚えておく必要はありません。

pw useradd -n buildbot-master -m -w random

これに続いて、設定を保存するマスターディレクトリを作成します。

mkdir /var/buildbot-master

そして、サービスユーザーに所有権を与えます。

chown buildbot-master:buildbot-master /var/buildbot-master

この時点から、すべてのマスター関連のセットアップと変更は、権限のないユーザーとして実行する必要があります。これにより、所有権と権限の一貫性が保たれます。

特権のないユーザーに切り替えます。

su -l buildbot-master

次に、組み込みの `+ buildbot +`ユーティリティを使用して、指定したディレクトリにディレクトリと設定構造を作成します。

buildbot-3.6 create-master /var/buildbot-master

Jenkinsなどの他のCIソフトウェアとは異なり、Buildbotの動作は設定ファイルで直接定義され、Pythonで解釈されます。 これにより、構成の合理化されたバージョン管理が可能になり、スクリプト言語の使用により、カスタムビルド構成を自由に作成し、既存のBuildbot機能を拡張できます。

Buildbotパッケージには、独自の構成のテンプレートとして使用できるサンプルマスター構成ファイルが付属しています。 サンプル設定をコピーして、 `+ master.cfg +`という名前を付けます：

cp /var/buildbot-master/master.cfg.sample /var/buildbot-master/master.cfg

次に、好みのテキストエディターで基本構成ファイルを開きます。 ここでは、「+ ee +」を使用します。

ee /var/buildbot-master/master.cfg

構成ファイルには、ワーカーがマスターに接続するために必要なパスワードが含まれています。 デフォルトの `+ pass `を選択した安全なパスワードに置き換えます。 また、ワーカーの名前は「 worker0 」になるため、「 WORKERS 」セクションと「 BUILDERS 」セクションの両方で「 example-worker 」を「 worker0 +」に置き換えます。

終了すると、編集する必要があるファイルの部分は次のようになります。

/var/buildbot-master/master.cfg

####### WORKERS

# ...
c['workers'] = [worker.Worker("", "")]
# ...

####### BUILDERS

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

このファイルを保存して閉じ、 `+ exit +`コマンドを実行して、jail内の* root *ユーザーに切り替えます。

exit

サンプル設定では、変更ソースとしてGitリポジトリ `+ git：// github.com / buildbot / hello-world.git +`を監視しているため、Gitをインストールする必要もあります。

pkg install git-lite

これで、マスターディレクトリの構造と構成を作成しましたが、サービスはまだ実行されていません。 Buildbotを手動で実行するには、マスターディレクトリの `+ / var / buildbot-master `からコマンド ` buildbot start `を実行します。 ただし、これは起動時の起動やその他のシステム全体の構成を考慮しません。 代わりに、サービスを実行するためのFreeBSDの標準的な方法である_rc scripts_を使用します。 具体的には、 ` service`ユーティリティを使用してこれを行います。

このチュートリアルでは、ブートごとにサービスを実行できるようにします。 刑務所の場合、これは刑務所の開始イベントを意味します。 次のコマンドを使用して、マスターディレクトリの場所を定義します。

sysrc buildbot_basedir=/var/buildbot-master

次に、* buildbot-master *ユーザーでサービスを実行するように指定します。

sysrc buildbot_user=buildbot-master

次に、jailの起動時にサービスを実行できるようにします。

sysrc buildbot_enable=YES

執筆時点では、 + py36-buildbot +`パッケージにはサービスの開始を妨げるバグがあります（https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227675 [このバグレポート]を参照） 。 これが修正されるまで、 `+ buildbot-master + jailから次のコマンドを実行して、開始スクリプトに手動でパッチを適用する必要があります。

sed -i '' 's|command="/usr/local/bin/buildbot"|command="/usr/local/bin/buildbot-3.6"|' /usr/local/etc/rc.d/buildbot

次に、サービスを開始します。

service buildbot start

サービスはエラーなしで開始する必要があります。 ログファイルの内容を表示して、成功を確認できます。

tail /var/buildbot-master/twistd.log
Output2018-06-08 15:14:52+0000 [-] Starting BuildMaster -- buildbot.version: 0.9.11
2018-06-08 15:14:52+0000 [-] Loading configuration from '/var/buildbot-master/master.cfg'
[...]
2018-06-08 15:14:52+0000 [-] BuildMaster is running

ホストシェルに戻るには、jailシェルから `+ exit +`を実行します：

exit

Buildbotマスターサービスを正常に構成して開始しました。 2番目のコンポーネントであるワーカーは、実際にビルドを実行するために必要です。 次のセクションで2番目の刑務所内の1つのワーカーをインストールし、マスターサービスへの接続を構成します。

ステップ4 – Buildbot Workerのインストールと実行

Buildbotマスターは実行されていますが、少なくとも1つのワーカーを実行する必要があるため、ビルドは発生しません。 この手順は、最初に別のjailを設定してからサービスをインストールするという点で、前の手順と似ています。 ただし、今回は、Buildbotワーカーコンポーネントがマスターに接続してコマンドをリッスンし、結果を報告します。

この手順の手順は、マスターコンポーネントとほぼ同じですが、ワーカーコンポーネントは別のパッケージの一部であり、マスターへの接続に関する詳細の追加とワーカー自体に関する情報の表示のみを行う構成変更のみを行います。

刑務所内ではなく、ホストシェル内にいることを確認してください。 次に、ワーカーjailで* root *シェルを開きます。

sudo jexec buildbot-worker0 csh

このガイドでは、jailシェル内でコマンドブロックを実行する必要がある場合、コマンドブロックは異なる色でマークされ、コマンドプロンプトはコマンドを実行するユーザープロファイルを反映することに注意してください。

次のコマンドでBuildbotワーカーパッケージをインストールします。

pkg install py36-buildbot-worker

このコマンドを実行すると、 `+ pkg `パッケージ管理ユーティリティをブートストラップするかどうかを確認するプロンプトが表示されます。 そうするには、「 y 」と入力します。 また、パッケージのインストールを承認したことを確認するように求められるため、プロンプトが表示されたら再度「 y +」を入力します。

次に、通常の非特権ユーザーを作成して、ワーカーサービスを実行します。

pw useradd -n buildbot-worker -m -w random

次に、ワーカーディレクトリを作成します。 これは、ワーカーの構成、表示情報、ビルドディレクトリが保存される場所です。

mkdir /var/buildbot-worker

サービスユーザーに所有権を付与します。

chown buildbot-worker:buildbot-worker /var/buildbot-worker

この時点から、すべてのワーカー関連のセットアップと変更は、非特権ユーザーとして実行する必要があります。 そのために、 `+ buildbot-worker +`ユーザーに切り替えます：

su -l buildbot-worker

組み込みの `+ buildbot-worker `ユーティリティを使用して、ディレクトリと設定構造を ` / var / buildbot-worker `ディレクトリに作成します。 前のステップで選択したマスターjailのIPアドレス-「+10.0.0.2」を指定します。これにより、ワーカーはそれに接続し、マスター設定ファイルで定義したパスワードで「+ pass +」を置き換えることができます。

buildbot-worker-3.6 create-worker /var/buildbot-worker 10.0.0.2 worker0 ''

セットアップを完了するには、システム管理者とワーカーの目的に関するいくつかの詳細を入力します。

echo ' <>' >/var/buildbot-worker/info/admin
echo '' >/var/buildbot-worker/info/host

これに続いて、 `+ exit +`コマンドを実行して、jail内の* root *ユーザーに戻ります。

exit

サンプル構成はGitリポジトリ `+ git：// github.com / buildbot / hello-world.git `を複製してサンプルプロジェクトをビルドするため、このjail内にGitをインストールする必要もあります。 変更ソースはマスターで実行されるため、BuildbotマスターもGitを必要としたことに注意してください。 さらに、ビルダーは ` py27-twisted `パッケージの一部である ` trial `というテストランナーを使用するため、これを ` git-lite +`とともにインストールします。

pkg install git-lite py27-twisted

ワーカーを実行するための組み込みメカニズムは `+ buildbot-worker start `で、ワーカーディレクトリ ` / var / buildbot-worker `から実行する必要があります。 ただし、これは起動時の起動を考慮せず、正しいユーザーで実行されることを保証しません。 マスターで行ったように、 ` service `ユーティリティを使用してパッケージ化された ` rc +`スクリプトを活用し、サービスを管理します。

次のコマンドを使用して、ワーカーディレクトリと、サービスを実行するユーザーおよびグループを定義します。

sysrc buildbot_worker_basedir=/var/buildbot-worker
sysrc buildbot_worker_uid=buildbot-worker
sysrc buildbot_worker_gid=buildbot-worker

次に、jailの起動時にサービスを実行できるようにします。

sysrc buildbot_worker_enable=YES

執筆時点で、 + py36-buildbot-worker +`パッケージにはサービスの開始を妨げるバグがあります（https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227675 [このバグレポートを参照] ]）。 これが修正されるまで、 `+ buildbot-worker0 + jailから次のコマンドを実行して、開始スクリプトに手動でパッチを適用する必要があります。

sed -i '' 's|command="/usr/local/bin/twistd"|command="/usr/local/bin/twistd-3.6"|' /usr/local/etc/rc.d/buildbot-worker

最後に、ワーカーコンポーネントを起動します。

service buildbot-worker start

サービスはエラーなしで開始する必要があります。 ログファイルの最新のエントリを表示すると、成功したことを確認できます。

tail /var/buildbot-worker/twistd.log

サービスが正常に開始された場合、「+ Connected to 10.0.0.2:9989; worker is ready + `がログファイルに表示されます。 この手順の前半で新しいパスワードを指定するのを忘れた場合、サービスはマスターへの接続に失敗します。 この場合、ファイル「+ / var / buildbot-worker / buildbot.tac 」を編集し、「 service buildbot-worker restart +」を実行してこの問題を修正します。

サービスが正しく起動したら、jailシェルから `+ exit +`コマンドを実行してホストシェルにドロップアウトします。

exit

これで、2番目の刑務所が構成され、Buildbotを操作するために必要なすべての基本コンポーネントが用意されました。 ユーザーがすぐに使用できるようにするには、ウェブベースのユーザーインターフェースも設定することをお勧めします。 そうすることで、Buildbotを制御し、より便利にビルド結果を見ることができます。

ステップ5 – Buildbot Webインターフェイスのセットアップ

Buildbotは、ビルドの概要と結果を表示するWebベースのユーザーインターフェイスを備えており、サンプル構成のように「強制」スケジューラーが構成されている場合、手動でビルドをトリガーできます。

マスター設定は、ポート `+ 8010 `を介してHTTPを提供するために ` www `コンポーネントをすでに設定しています。 実稼働環境では、暗号化されていないHTTPを提供したり、外部への非標準ポート ` 8010 +`を開いたりしないでください。これにより、システムがセキュリティの脆弱性にさらされることになります。 また、Webインターフェイスは任意のURLパスから提供できます。つまり、ドメインで唯一のアプリケーションである必要はありません。 たとえば、ビルド出力またはログをユーザーに提供できます。 したがって、HTTPSをサポートし、内部ポートを保護し、Buildbot Webインターフェイスとともに他のコンテンツを提供するために、別個のWebサーバー（Nginx）を持つユーザーにUIを提供します。

Nginx構成ファイルを編集用に開きます。

sudo ee /usr/local/etc/nginx/nginx.conf

次の強調表示された「+ location n」ブロックをファイルの既存の「+ server」ブロック内に追加します。

/usr/local/etc/nginx/nginx.conf

. . .
http {
. . .
   server {

. . .
       location / {
           root /usr/local/www/nginx;
           index index.html index.htm;
       }



















       error_page 500 502 503 504 /50x.html;
       location = /50x.html {
           root /usr/local/www/nginx-dist;
       }

               . . .

   }
}

この設定は、URLパス「+ / buildbot / +」の下のすべてのリクエストをWebインターフェースに転送し、WebSocketサポートを有効にします。これは、実行中のビルドのログ出力など、表示される更新をインターフェースが受信するために使用されます。

Nginx構成ファイルを保存して閉じます。 次に、Nginxサービスをリロードします。

sudo service nginx reload

ローカルマシンで好みのWebブラウザを開き、次のURLにアクセスしてBuildbot Webインターフェイスにアクセスします。

https:///buildbot/

または、サーバーのドメイン名を設定していない場合は、代わりにサーバーのパブリックIPアドレス「+ http：/// buildbot / +」を入力する必要があります。

インターフェイスに到達すると、次のような概要が表示されます。

image：https：//assets.digitalocean.com/articles/buildbot_freebsd/web_interface_overview_final.png [Webインターフェイスの概要]

メインページには、Buildbot URLの設定が間違っているという警告が表示される場合があります。 これは、 `+ nginx.conf +`ファイルで指定されたホスト名が、マスターBuildbot設定にリストされているものと一致しない場合に発生します。 ビルド結果の電子メールには、デフォルトでBuildbot Webインターフェイスへのリンクが含まれているため、マスターは、到達可能な正しいURLを知っている必要があります。

設定例では、このメールサービスを設定していないことに注意してください。 これの設定に興味がある場合は、Buildbotのhttp://docs.buildbot.net/current/manual/cfg-reporters.html [レポーターに関するドキュメント]で詳細を参照してください。

とはいえ、警告を解決し、正しいコンテンツを含む電子メールを送信するには、Buildbotマスター構成を編集してドメインをポイントします。

sudo ee /usr/jails/buildbot-master/var/buildbot-master/master.cfg

`+ c ['buildbotURL'] `で始まる行を見つけて、デフォルトオプションをドメイン名に置き換え、その後に ` / buildbot / +`を付けます。

/var/buildbot-master/master.cfg

####### PROJECT IDENTITY
# ...
c['buildbotURL'] = ''
# ...

ファイルを保存して閉じます。 次に、新しい設定を適用するには、 `+ buildbot +`サービスをリロードします：

sudo jexec buildbot-master service buildbot reload

ブラウザーでBuildbot Webインターフェイスを更新すると、警告が消えます。

継続的インテグレーションサーバーは、多くの場合、CI以外の目的にも役立ちます。 たとえば、CIサーバーは、FreeBSDパッケージのビルド出力を提供したり、HTTPS経由でログを記録したりします。 したがって、ウェブインターフェース用にURLパス「+ / buildbot / +」を予約することをお勧めします。 これにより、異なるパスでより多くのアプリケーションをホストできます。 とりあえず、Webインターフェースにリダイレクトするシンプルなホームページを作成します。 Webサーバーのユースケースをさらに実装したら、さらにリンクを追加できます。

次のコマンドを実行してWebルートのインデックスファイルを開き（「++」を独自のドメインに置き換えます）、Buildbot Webインターフェイスへの自動リダイレクトを作成します。

sudo ee /usr/local/www//html/index.html

既存のファイルコンテンツを次の行に置き換えます。

/usr/local/www/nginx/index.html

<html>
<body>
<a href="/buildbot/">buildbot</a>
<script>
   // Auto-redirect while only the web interface should be served
   window.location.href = "/buildbot/";
</script>
</body>
</html>

このファイルを保存して閉じ、ブラウザのURLバーにドメイン名またはIPアドレスを入力します。 Buildbotインターフェースに自動的にリダイレクトされます。

Webベースのコントロールと表示インターフェースを含む、すべてのBuildbotコンポーネントのインストールが完了しました。 これらすべてを準備したら、マスター用にセットアップしたサンプル構成で指定されている実際のビルドを実行しましょう。

ビルダーには、デフォルトで構成された「強制」スケジューラーがあり、これにより、最初のビルドをトリガーできます。 Webインターフェースで、「* Builds 」>「 Builders 」>「 runtests 」>「 force 」>「 Build *」をクリックして、ビルドの実行方法を確認します。 エラーが発生した場合は、サーバーのインターネット接続を確認し、前述のようにすべての依存パッケージがインストールされているかどうかを確認します。

image：https：//assets.digitalocean.com/articles/buildbot_freebsd/sample_build_success.png [ビルド成功のスクリーンショットのサンプル]

ビルドディレクトリの内容を調べると、このビルド（およびその他）のアーティファクトを見つけることができます。

ls /usr/jails/buildbot-worker0/var/buildbot-worker/runtests
Outputbuild

永続的に実行される多用途のCIシステムを正常に構成し、独自のビルドの実装を開始できるようになりました。

結論

このチュートリアルを完了することで、FreeBSD刑務所の作成を練習し、Buildbot自動化フレームワークの基本のいくつかを学び、すぐに使用できるインストールを作成しました。 Buildbotとその構成の詳細については、https：//docs.buildbot.net/ [Buildbotの公式ドキュメント]を読むことをお勧めします。

ここから、独自の継続的統合と自動化のプラクティスを自由に実装できます。 本番環境で使用するための安全で安定した高性能のセットアップを行うには、次のオプションの構成手順を実行することをお勧めします。

  • HTTPSのみを使用する（このチュートリアルで説明されているように）

  • チュートリアルでは、刑務所に別個のホスト内部ネットワーク「+ lo1 」を使用しました。 このガイドでは、NATの目的で「 ipfw +」を使用しましたが、他のファイアウォールにもこの機能があります。 https://www.freebsd.org/doc/handbook/firewalls.html [利用可能なファイアウォール]に関するFreeBSDドキュメントをご覧ください。 ユースケースで別途必要な場合を除き、NATまたはその他のメカニズムを使用して外部からjailネットワークにアクセスできないようにすることをお勧めします。

  • Buildbotのウェブインターフェースは、ログインを必要とせず、デフォルトでユーザー権限を確認します。 これらを実装するには、https：//docs.buildbot.net/latest/developer/auth.html [ユーザー認証]を有効にする必要があります。

Related