序章

FreeBSDポートおよびパッケージコレクション(以下ポートツリーと呼びます)は、FreeBSDの外部ソフトウェア用ビルドシステムです。 Makefileベースの一貫したパッケージ構築方法を提供します。 port は、ビルドレシピ、つまりMakefileと関連ファイルを指します。 一方、 package は、1つのポートをパッケージファイルとそのメタ情報のバイナリ(圧縮)アーカイブに構築した結果です。

30,000を超えるポートのサブセットまたはすべてを手動で構築およびインストールすることは、 make install. ただし、ビルドは、クリーンな環境ではなく、サーバーの1つで実行されます。 実稼働のユースケースの場合、手動ビルドは、各ホストがポートツリーの同じリビジョンを必要とし、それ自体のためにすべてのパッケージをコンパイルする必要があることも意味します。 これは、人間とサーバーによる繰り返しのエラーが発生しやすい作業を意味します。 各ホストで同一のビルド済みバイナリパッケージを取得して使用し、中央の安全なパッケージリポジトリから提供することをお勧めします。

これを実現するために、 Poudriere は、パッケージをビルド、テスト、監査し、パッケージリポジトリを維持するためのFreeBSDの標準ツールです。 各ビルドは、新しい jail で分離して実行され、目的のバージョンのFreeBSDを実行し、パッケージがインストールされていない状態で開始されます。 クリーンビルドで使用できるのは、基本システムと明示的に指定された依存関係のみです。 Poudriereは、必要に応じてパッケージを再構築し、ビルドの完了後にパッケージリポジトリを更新します。 The poudriere コマンドラインツールは、さまざまなポートツリー、FreeBSDバージョン、ポートビルドオプションの管理、そして最後にビルドの実行の中心です。

このチュートリアルでは、Poudriereを構成し、必要なパッケージのセットをビルドし、HTTPベースのパッケージホスティングをセットアップし、継続的インテグレーションプラットフォームとしてBuildbotを使用してビルドを自動化します。 最後に、クライアントマシンからパッケージに安全にアクセスします。

注:本番環境のようなユースケースをカバーするために、チュートリアルの例では、ポートツリーの四半期ごとに安定したブランチを使用しています。 そのようなブランチの1つにとどまると、変更を壊さないように保護され、必要に応じてセキュリティとビルドの修正が提供されます。アップストリーム(SubversionまたはそのGitHubミラー)からツリーを定期的に更新する場合です。 開発者/インフラストラクチャチームがシステムの更新を処理できるペースに応じて、1つのブランチに長期間滞在することを選択できます。 ポートコレクションは、保守終了(EOL)になるまでFreeBSDリリースをサポートします(サポートされているFreeBSDリリースを参照)。これにより、OSとパッケージの更新を個別に処理できます。 または、アップストリームツリーから複製されたローカルバージョン管理リポジトリを検討することもできます。 これにより、パッチを管理し、必要なときにのみアップストリームの変更をマージできます。

前提条件

Note: As of July 1, 2022, DigitalOcean no longer supports the creation of new FreeBSD Droplets through the Control Panel or API. However, you can still spin up FreeBSD Droplets using a custom image. Learn how to import a custom image to DigitalOcean by following our product documentation.

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

  • FreeBSD11.2を実行しているサーバー。 FreeBSDを初めて使用する場合は、 FreeBSDの使用を開始する方法のガイドに従って、このサーバーをカスタマイズすると役立つ場合があります。 注: FreeBSD 12.0には現在ネストされたjailsの問題があり、このチュートリアルで12.xを使用する前に最初に修正する必要があります。
  • パッケージとログを保存するのに十分な容量を持つための10GB以上の空きディスク容量。
  • FreeBSDでBuildbotをセットアップする方法チュートリアルを完了することによる、基本的なBuildbotのセットアップ。
  • 同じバージョンのFreeBSDを実行している別のサーバー。これは、HTTP /HTTPSベースのパッケージリポジトリで自動的にビルドおよびホストするパッケージをフェッチしてインストールするためのクライアントとして使用します。

ステップ1—BuildbotWorkerで使用するためのPoudriereのインストール

前提条件のチュートリアルを完了すると、Buildbotマスターとワーカーのjailに加えて、Nginxのセットアップが機能します。 次の手順で、この既存の設定に基づいて構築します。 この最初のステップでは、ビルドツールPoudriereをワーカーjail内にインストールします。これは、Buildbotワーカープロセスが後でビルドをトリガーする場所だからです。

Buildbotをホストしているサーバーに接続し、次のコマンドを使用してワーカーjailでrootシェルを開きます。

  1. sudo jexec buildbot-worker0 csh

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

  1. pkg install poudriere

次に、を押してインストールを確認します y その後 ENTER.

注: Buildbot、Poudriereなどのインストールには、公式のFreeBSDパッケージリポジトリを使用することをお勧めします。 これらのツールパッケージを自分でビルドする場合は、鶏が先か卵が先かという状況から始めます。外部ソフトウェアをインストールしたいが、クリーンにビルドされたパッケージを取得するにはPoudriereをインストールする必要があります。 Poudriereは非常に安定しており、下位互換性のあるツールであるため、製品パッケージから定期的かつ独立して更新することに反対するものはありません。

前提条件のチュートリアルに従った場合、これはすでに当てはまり、このメモに従わなくても続行できます。

これで、最新のPoudriereツールと依存関係が正常にインストールされました。 次のいくつかのステップでは、Poudriereを構成するための準備を行います。

ステップ2—パッケージ署名キーの作成(オプション)

セキュリティを強化するために、ビルドされたパッケージにデジタル署名を設定することをお勧めします。 後で、または別の方法でインストールを保護する場合は、この手順をスキップしてください。 それ以外の場合は、先に進んで、パッケージの署名(秘密鍵を使用)とパッケージの検証(公開部分を使用)に使用する鍵ペアを作成しましょう。

デフォルトでは、パッケージは次のようにビルドされます .txz パッケージの内容の強力に圧縮されたtarballであるファイル。 圧縮されたファイルのチェックサムは、HTTP / HTTPS(TCPチェックサム)を介してファイルを提供するとともに、破損したデータに対するある程度の保護をすでに提供しています。 パッケージの内容は通常、ファイルとディレクトリに加えて、パッケージ名、バージョン、その他のオプションなどのメタ情報で構成されます。 ファイルには、 setuid-ableプログラムが含まれている場合もあります( sudo パッケージ-sudoはFreeBSDに組み込まれていませんが)、インストール時のスクリプトはrootユーザーとして実行されます。 したがって、未確認のソースからインストールすると、セキュリティ上のリスクが発生します。

HTTPS経由でパッケージを提供することにより、誰かがディスク上のパッケージを改ざんしたかどうかを検出できません。 パッケージの整合性と信頼性は、RSA秘密鍵を使用してパッケージリポジトリに署名するようにPoudriereを構成することで追加できます。 これにより、署名されたダイジェストと対応する公開鍵がパッケージリポジトリに保存されます。 digests.txz ファイル。 必要な鍵のペア(RSA秘密鍵と公開鍵)は、秘密鍵を紛失したり侵害したりしない限り、長期間変更しないでおくことができます。

このステップでは、ビルドが実行されるキーペア(ワーカーjail)を作成し、後でパッケージクライアントで使用するためにパブリックパーツをダウンロードします(後のステップで説明します)。

まだワーカージェイルrootシェルにいることを確認してください。

新しいRSA秘密鍵を作成します。

  1. openssl genrsa -out /usr/local/etc/poudriere.key 4096

秘密鍵ファイルには、Poudriereを実行するユーザーであるrootのみがアクセスできる必要があります。 アクセス許可を保護します。

  1. chmod 0600 /usr/local/etc/poudriere.key

後で、パッケージの署名を検証するために、クライアントで利用可能な公開鍵部分が必要になります。 ここで公開鍵を抽出しましょう:

  1. openssl rsa -in /usr/local/etc/poudriere.key -pubout -out /tmp/poudriere.pub

最後に、自分のコンピューターから公開鍵ファイルをダウンロードします。

  1. scp your-server:/usr/jails/buildbot-worker0/tmp/poudriere.pub /tmp/poudriere.pub

これで、パッケージ署名用のキーペアのオプションの作成は完了です。 後でPoudriereを使用して実際の署名を構成し、クライアントでダウンロードした公開鍵ファイルを使用して検証します。

別のオプションの手順は次のとおりです。ZFSファイルシステムを使用する場合、Poudriereはそれを利用してビルドを高速化できます。 それ以外の場合は、ステップ4 にスキップして、Poudriereを構成し、最初のビルドを実行する準備をすることができます。

ステップ3— ZFSのセットアップ(オプション)

このステップは、ZFSファイルシステム上でFreeBSDシステムを実行している場合にのみ適用されます。 このステップでは、Poudriereがjailの作成と管理を高速化するために使用できるファイルシステムを作成し、ビルドを高速化する可能性があります。

プールを一覧表示することで、ZFSを使用しているかどうかを確認できます。 刑務所の中ではなく、サーバーのシェル上にいることを確認してください。

  1. exit

次のコマンドを実行して、zpoolを一覧表示します。

  1. sudo zpool list

利用可能なプールがある場合は、それに関する情報が出力されます。

Output
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zroot 148G 94.4G 54.1G - - 66% 63% 1.00x ONLINE -

それ以外の場合、ZFSサポートが利用できない場合、ツールは印刷します no pools available、 また failed to initialize ZFS library. これは、どのシステムもZFSを使用していないことを意味します。 この場合、次のステップにスキップしてください。 UFSファイルシステムなど、別のディスクまたはストレージタイプを使用することにした場合は、次の手順に進むこともできます。

ZFSを使用する場合は、ビルド関連のデータを格納する印刷されたプール名を覚えておいてください。 数ギガバイトのストレージを計画する必要があります。

ZFSは、ビルドジェイル、ポートツリー、ログ、パッケージ、その他のデータなど、Poudriereのさまざまなデータセットを分離するのに役立ちます。 これらは個別に保存されるため、空き領域やトレースを残さないようにして、すばやく削除できます。

PoudriereがZFSを利用するには、次の3つのことを行う必要があります。親ZFSデータセットの作成、ZFSデータセットの作成と削除の許可(Buildbotワーカーの刑務所またはその他の刑務所ではデフォルトでは実行できません)、および編集それに応じてPoudriereの構成。

前提条件のチュートリアルでは、Buildbotワーカーの刑務所を構成しました /etc/jail.buildbot-worker0.conf. 好みのテキストエディタでこのファイルを開き、次の強調表示された行を追加して親データセットを委任し、jailが親の下のZFSデータセットを管理できるようにします。 交換することを忘れないでください zroot ご希望のプール名で:

  1. 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;

    exec.poststart = "/sbin/zfs jail buildbot-worker0 zroot/pdr/w0";
}

この記事では、ビルド関連のデータをZFSプールに保存します zroot-別の名前のプールを選択した場合は、このZFS関連の構成をここと記事の残りの部分全体に適合させてください。

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

構成ファイルに記載されている親ZFSデータセットを作成します。

  1. sudo zfs create zroot/pdr
  2. sudo zfs create zroot/pdr/w0

これは、将来さらにワーカーを追加する可能性があることを意図的に想定しているため、最初のワーカーのサブデータセットを作成します。 古いバージョンのFreeBSD(12.0より前)には88文字のマウント名制限があったため、データセット名は意図的に短くなっています。

刑務所が親データセットを制御し、子を管理するには、データセットに次のフラグを付ける必要があります。

  1. sudo zfs set jailed=on zroot/pdr/w0

前提条件が満たされると、jailは新しい構成で正しく開始されます。

  1. sudo service jail restart buildbot-worker0

これらの手順により、必要なファイルシステム(ZFSデータセット)が正常に作成され、jailが親データセットを管理できるようになりました。 次のステップでは、Poudriereを構成します。これには、ビルド関連のデータを格納するために使用する、選択したzpoolとデータセットを指定することが含まれます。

ステップ4— Poudriere、Build Jail、およびPortsTreeの構成

この時点までに、Poudriereをインストールし、オプションでパッケージ署名とZFSの要件をカバーしました。 Poudriereを「jailed」方式で実行できるようにするには、つまり、Buildbotワーカーjail内から正しく機能させるには、jailに特定の権限を付与する必要があります。 たとえば、ZFSを使用している場合、jailによる使用と管理のために親データセットをすでに委任しています。

最初にループバックIPとすべてのアクセス許可を構成し、次に変更に続いてそれぞれの意味をステップスルーしてみましょう。

Poudriereは、ビルドごとに2つのビルドジェイルを開始したいと考えています。1つはループバックのみのネットワークを使用し、もう1つはインターネットアクセスを使用します。 インターネットに到達することになっているビルドステージのみが後者を使用します。 たとえば、 fetch ソースtarballをダウンロードする可能性がありますが、 build フェーズはインターネットアクセスを許可されていません。 労働者刑務所の既存の構成には ip4.addr = "lo1|10.0.0.3/24" それはインターネットアクセスを可能にします。 Poudriereが新しく開始されたビルドジェイルにループバックアドレスを割り当てることができるようにするには、IPをその親(ワーカージェイル)にも渡す必要があります。 これを機能させるには、ファイアウォール構成ファイルの最新バージョンを適用していることを確認してください /usr/local/etc/ipfw.rules ループバックインターフェイスをブロックする前提条件のチュートリアルから lo0 NATを介して発信接続を開くことから。

強調表示された行をワーカーjail構成に追加します。

  1. 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";
    ip4.addr += "lo0|127.0.0.3";
    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;

    # If you followed the ZFS setup step, you have this line
    # already (keep it). For non-ZFS setup, this line must be absent.
    exec.poststart = "/sbin/zfs jail buildbot-worker0 zroot/pdr/w0";

    allow.chflags;
    allow.mount;
    allow.mount.devfs;
    allow.mount.nullfs;
    allow.mount.procfs;
    allow.mount.tmpfs;
    allow.mount.zfs; # only needed if you use ZFS
    allow.raw_sockets; # optional
    allow.socket_af; # optional
    allow.sysvipc; # optional
    children.max=16;
    enforce_statfs=1;
}

ここに以下を追加しました( jail(8)のマンページも参照してください)。

  • ip4.addr += "lo0|127.0.0.3" 刑務所に別のIPv4アドレスを追加します。 後でPoudriereを構成します LOIP4 このループバックアドレスを割り当てて、インターネットやネットワーク内の他のマシンと通信することを想定していない刑務所を構築するための変数 build 段階。 ビルド中にインターネットアクセスを必要とするビルドがある場合、Poudriereは変数をサポートします ALLOW_NETWORKING_PACKAGES 回避策として。 ただし、ベストプラクティスに従い、ダウンロードやその他のインターネット向けタスクを早い段階で実行することをお勧めします。 fetch Poudriereがインターネットアクセスを許可するフェーズ。
  • allow.chflags Poudriereが次のような特定のシステムファイルをレンダリングできるようにします /bin/sh ビルド刑務所で不変。
  • allow.mount と他の allow.mount.* オプションを使用すると、Poudriereは特定の必要なファイルシステムをビルドジェイルにマウントできます。
  • allow.raw_sockets rawソケットの使用を許可します。 allow.socket_af 任意のソケットアドレスファミリの使用を許可するものは、どちらもインターネット対応のビルドジェイルに適用されます。 これは、次のようなツールを実行できるようにするのに役立ちます。 ping 問題をデバッグするためにビルドジェイルに入るときのように、インタラクティブモードで。
  • allow.sysvipc 3つの個別の設定を優先して非推奨になりました sysvmsg/sysvsem/sysvshm ジェイルが自分の共有メモリオブジェクトのみを表示するように制限します(「SYSV」IPCプリミティブを介して)。 ただし、Poudriereは渡すことしかできません allow.sysvipc (FreeBSD 11.2以降)3つの別々のパラメーターに関連するsysctl情報を読み取ることができないため、jailをビルドします。 この非推奨の構成では、jailはjailの外部のプロセスの共有メモリを読み取ることができます。 これは、PostgreSQLなどのIPC機能に依存する特定のソフトウェアにのみ関連するため、セキュリティに影響を与える可能性はほとんどありません。 ビルド中に必要なポートに依存しない限り、この構成を削除できます。
  • children.max=16 労働者の刑務所の下に16のサブ刑務所を許可します。 CPUが多く、Poudriereが許可されているよりも多くのビルドジェイルを作成しようとする場合は、後でこの数を増やすことができます。 各Poudriereビルドは、「ジョブ」ごとに参照ジェイルと2つのビルドジェイルを作成しようとします。デフォルトでは、CPUの数を使用します( sysctl -n hw.ncpu)ジョブ数として。
  • enforce_statfs=1 と一緒に必要です allow.mount 特定のファイルシステムをマウントするため。

構成ファイルを保存して終了します。

構成をすぐに有効にするために、jailを再起動します。

  1. sudo service jail restart buildbot-worker0

Poudriereがマウントを実行できるように、それぞれのカーネルモジュールをロードする必要があります。 次のコマンドを実行して、起動時および即時にモジュールをロードします。

  1. sudo sysrc -f /boot/loader.conf nullfs_load=YES
  2. sudo kldload -n nullfs
  3. sudo sysrc -f /boot/loader.conf tmpfs_load=YES
  4. sudo kldload -n tmpfs

サンプルファイルをコピーしたPoudriereパッケージを以前にインストールしました /usr/local/etc/poudriere.conf.sample/usr/local/etc/poudriere.conf. 次に、構成ファイルを編集します。 考えられるすべての構成変数はサンプルにすでに存在するため、ファイル内のそれぞれの行のコメントを解除または調整して、変数を特定の値に設定します。

次のコマンドについては、ワーカーjailのrootシェルにいることを確認してください。

  1. sudo jexec buildbot-worker0 csh

次のコマンドでファイルを開きます。

  1. ee /usr/local/etc/poudriere.conf

ZFSを使用することにした場合は、目的のzpoolと親データセットを入力してください。

/usr/local/etc/poudriere.conf(スニペット)
. . .
# Poudriere can optionally use ZFS for its ports/jail storage. For
# ZFS define ZPOOL, otherwise set NO_ZFS=yes
#
#### ZFS
# The pool where poudriere will create all the filesystems it needs
# poudriere will use ${ZPOOL}/${ZROOTFS} as its root
#
# You need at least 7GB of free space in this pool to have a working
# poudriere.
#
ZPOOL=zroot

### NO ZFS
# To not use ZFS, define NO_ZFS=yes
#NO_ZFS=yes

# root of the poudriere zfs filesystem, by default /poudriere
ZROOTFS=/pdr/w0
. . .

それ以外の場合、ZFSに反対することにした場合は、ZFSサポートを無効にしてください。

/usr/local/etc/poudriere.conf(スニペット)
. . .
# Poudriere can optionally use ZFS for its ports/jail storage. For
# ZFS define ZPOOL, otherwise set NO_ZFS=yes
#
#### ZFS
# The pool where poudriere will create all the filesystems it needs
# poudriere will use ${ZPOOL}/${ZROOTFS} as its root
#
# You need at least 7GB of free space in this pool to have a working
# poudriere.
#
#ZPOOL=zroot

### NO ZFS
# To not use ZFS, define NO_ZFS=yes
NO_ZFS=yes

# root of the poudriere zfs filesystem, by default /poudriere
# ZROOTFS=/poudriere
. . .

後で、PoudriereにFreeBSDベースシステムをダウンロードして、最初のビルドjailをブートストラップするように指示します。 これには、ダウンロードホストを指定する必要があり、次の強調表示された行を追加します。

/usr/local/etc/poudriere.conf(スニペット)
. . .
# the host where to download sets for the jails setup
# You can specify here a host or an IP
# replace _PROTO_ by http or ftp
# replace _CHANGE_THIS_ by the hostname of the mirrors where you want to fetch
# by default: ftp://ftp.freebsd.org
#
# Also note that every protocols supported by fetch(1) are supported here, even
# file:///
# Suggested: https://download.FreeBSD.org
FREEBSD_HOST=https://download.FreeBSD.org

Poudriereはjailで実行されるため、12.0より前のFreeBSDバージョンの88文字のマウント名制限は、jailのフルパスとして特に有害です。 /usr/jails/buildbot-worker0 各マウントパスの一部です。 制限を超えるとビルドが致命的に破壊されるため、パスの長さを短くするように注意してください。 通常のディレクトリの代わりに /usr/local/poudriere、使用できます /pdr 次のように:

/usr/local/etc/poudriere.conf(スニペット)
. . .
# The directory where poudriere will store jails and ports
BASEFS=/pdr

次に、そのディレクトリを作成します。

  1. mkdir /pdr

の編集者に再度切り替えます poudriere.conf:

  1. ee /usr/local/etc/poudriere.conf

Poudriereは、ビルドの実行中に distファイル(各ポートのソースコードtarball)の中央ディレクトリをマウントして、すべてのビルダーが同じキャッシュを共有するようにします。 デフォルトのディレクトリは次のとおりです。

/usr/local/etc/poudriere.conf(スニペット)
. . .
# If set the given directory will be used for the distfiles
# This allows to share the distfiles between jails and ports tree
# If this is "no", poudriere must be supplied a ports tree that already has
# the required distfiles.
DISTFILES_CACHE=/usr/ports/distfiles

次に、そのディレクトリを作成します。

  1. mkdir -p /usr/ports/distfiles

手順2に従って、パッケージリポジトリの署名キーを作成した場合は、エディタをもう一度入力して指定してください。

  1. ee /usr/local/etc/poudriere.conf
/usr/local/etc/poudriere.conf(スニペット)
. . .
# Path to the RSA key to sign the PKG repo with. See pkg-repo(8)
PKG_REPO_SIGNING_KEY=/usr/local/etc/poudriere.key

次回のためにC/C ++コンパイラとリンカの出力をキャッシュすると、ビルドははるかに高速に実行されます。 ポートツリーは、ツール ccache を利用して、これを直接サポートします。 少なくとも5GBのスペース(デフォルトのキャッシュサイズ)を確保できる場合は、それを有効にして、それぞれのキャッシュディレクトリを作成してください。

/usr/local/etc/poudriere.conf(スニペット)
. . .
# ccache support. Supply the path to your ccache cache directory.
# It will be mounted into the jail and be shared among all jails.
# It is recommended that extra ccache configuration be done with
# ccache -o rather than from the environment.
CCACHE_DIR=/var/cache/ccache
  1. mkdir /var/cache/ccache

Linuxソフトウェアのビルドと実行は一般的ではないため、必要になるまで無効にします。

  1. ee /usr/local/etc/poudriere.conf
/usr/local/etc/poudriere.conf(スニペット)
. . .
# Disable linux support
NOLINUX=yes

刑務所にはループバックアドレスが割り当てられる必要があります。そうしないと、Poudriereが警告を発します。 刑務所のIPはループバックのみのネットワークインターフェイス上にあるため、継承できます(lo1). このために、構成ファイルの最後に次の行を追加してください。

/usr/local/etc/poudriere.conf(スニペット)
LOIP4=127.0.0.3

構成ファイルを保存して終了します。

ビルドを機能させるには、さらに2つのリソースが必要です。ビルドjailテンプレートとして使用するFreeBSDベースシステムと、最新のポートツリーです。 対象とするFreeBSDバージョンを選択してください。 このチュートリアルでは、Poudriereにamd64アーキテクチャ用のFreeBSD11.2をダウンロードするように指示します。 あなたは好きなように刑務所に名前を付けることができますが、次のような一貫した命名スキーム 112amd64 がおすすめ。 また、四半期ごとに安定したポートツリーブランチを選択することにも注意してください(ここでは、 2019Q2)そして、時々更新後にビルドを壊す可能性のある最先端の「ヘッド」ブランチ。 サーバー上のバージョンよりも新しいFreeBSDバージョンは、ビルドjailでは使用できません。

ビルドジェイルをダウンロードして作成します。

  1. poudriere jail -c -j 112amd64 -v 11.2-RELEASE -a amd64

最後に、portsツリーをダウンロードしましょう。 デフォルトのダウンロード方法はportsnapで、履歴情報なしでツリーの圧縮スナップショットを使用します。 アップストリームの変更をマージしたり、貢献したりするには、SubversionまたはGitのいずれかを使用することをお勧めします。 これは、バージョン管理システムでカスタムのセルフホストツリーを使用する場合にも重要です。 次のコマンドで、現在の年と四半期を入力してください。

アップストリームの公式ポートツリーから始めたい場合は、次のようにします。

  1. poudriere ports -c -p 2019Q2 -m svn+https -B branches/2019Q2

方法 svn+https FreeBSD Subversionホストから同期します(ここでオンラインで表示可能)。 別のソースを使用する場合は、次の注をお読みください。それ以外の場合はスキップしてください。

注:別の方法として、この方法 git デフォルトでは、GitHubのmirrorからツリーのクローンを作成します。

「head」ブランチを使用するには、最後のパラメーターを次のように置き換えます。 -B head (Subversionの場合)または -B master (Gitの場合)。

独自のGitリポジトリを使用する場合は、リポジトリのURLとブランチ名を明示的に指定する必要があります。 ツリーに名前を付けたいとしましょう customtree ブランチを使用します custom:

  1. poudriere ports -c -p customtree -m git -B custom -U https://github.com/AndiDog/freebsd-ports.git

サンプルURLは、GitHub上のfreebsd-portsのフォークを指していますが、CIサーバーがアクセスできる任意のGitまたはその他のサポートされているタイプのリポジトリである可能性があります。

利用可能な木はでリストすることができます poudriere ports -l、次のようなリストを出力します。

Output
PORTSTREE METHOD TIMESTAMP PATH 2019Q2 svn+https 2019-04-20 19:23:19 /pdr/ports/2019Q2

これで、Poudriereの構成とリソースの設定が完了しました。 最初のビルドをトリガーするために必要なデータを使用してPoudriereを構成し、jailがサブjailを作成できるようにしました。 次に、最初のビルドを手動で実行して、セットアップが機能していることを確認します。

ステップ5—手動テストビルドの実行

コマンドを使用できます poudriere bulk 1つ以上のパッケージとそのすべての依存関係を構築します。 パッケージの最初のビルド後、Poudriereは、再構築が必要かどうかを自動的に検出するか、既存のパッケージファイルをそのままにします。 ながら bulk サブコマンドはパッケージのみをビルドし、を使用してビルドを実行します poudriere testport また、ポートのMakefileで指定された「テスト」の定義を使用して、指定されたポートをテストします。 この記事の範囲では、クライアントにインストールするためのパッケージを提供することにのみ関心があるため、バルクビルドを使用しています。

Poudriereをインストールしたワーカー刑務所のルートシェルにいることを確認してください。 後で、これはBuildbotワーカープロセスがビルドを自動的に実行する場所でもあります。

ビルドを実行し、プレースホルダーに前に選択したビルドjail名とportsツリー名を入力します。

  1. poudriere bulk -j 112amd64 -p 2019Q2 ports-mgmt/pkg

これにより、ポートが構築されます ports-mgmt/pkg. 公式ツリーのポートは、 <category>/<name> 階層、およびそれらのパス( package origin と呼ばれる)は、どのパッケージを構築する必要があるかをPoudriereに伝えるために使用されます。 最初に、パッケージマネージャー pkg のみをビルドすることを選択しました。これは、サードパーティの依存関係がないため、構成をすばやくすばやく確認できます。 すべてが正常に実行されると、次のような出力が表示されます。

Output
[00:00:00] Creating the reference jail... done [00:00:06] Mounting system devices for 112amd64-2019Q2 [00:00:06] Mounting ports/packages/distfiles [00:00:06] Using packages from previously failed build [00:00:06] Mounting ccache from: /var/cache/ccache [00:00:06] Mounting packages from: /pdr/data/packages/112amd64-2019Q2 /etc/resolv.conf -> /pdr/data/.m/112amd64-2019Q2/ref/etc/resolv.conf [00:00:06] Starting jail 112amd64-2019Q2 [00:00:07] Logs: /pdr/data/logs/bulk/112amd64-2019Q2/2019-04-20_19h35m00s [00:00:07] Loading MOVED for /pdr/data/.m/112amd64-2019Q2/ref/usr/ports [00:00:08] Ports supports: FLAVORS SELECTED_OPTIONS [00:00:08] Gathering ports metadata [00:00:08] Calculating ports order and dependencies [00:00:08] pkg package missing, skipping sanity [00:00:08] Skipping incremental rebuild and repository sanity checks [00:00:08] Cleaning the build queue [00:00:08] Sanity checking build queue [00:00:08] Processing PRIORITY_BOOST [00:00:08] Balancing pool [00:00:08] Recording filesystem state for prepkg... done [00:00:08] Building 1 packages using 1 builders [00:00:08] Starting/Cloning builders [00:00:14] Hit CTRL+t at any time to see build progress and stats [00:00:14] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.10.5_5 [00:03:24] [01] [00:03:10] Finished ports-mgmt/pkg | pkg-1.10.5_5: Success [00:03:25] Stopping 1 builders [00:03:25] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:03:25] Committing packages to repository [00:03:25] Removing old packages [00:03:25] Built ports: ports-mgmt/pkg [112amd64-2019Q2] [2019-04-20_19h35m00s] [committing:] Queued: 1 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:03:18 [00:03:25] Logs: /pdr/data/logs/bulk/112amd64-2019Q2/2019-04-20_19h35m00s [00:03:25] Cleaning up [00:03:25] Unmounting file systems

この出力は、ビルド後にパッケージがどこに移動するか、および再構築が必要ない場合に既存のパッケージがどこから取得されるかを示しています(ここでは: /pdr/data/packages/112amd64-2019Q2). また、出力には、Poudriereの実行中に実行されているビルドの概要が表示されます( CTRL+T 進行状況を印刷するためのインタラクティブシェルで)。 最終的な要約では、1つのパッケージが作成されたことがわかります。 ログディレクトリで詳細なビルド出力を表示できます(/pdr/data/logs/bulk/112amd64-2019Q2/*).

この出力は、ビルドが成功したことを確認します。 Poudriereが少なくとも1つのパッケージを正常にビルドした場合、Poudriereはそれをパッケージリポジトリに自動的にコミットします。 つまり、他のパッケージのビルドに失敗した場合でも、パッケージはすべてのビルドが完了した後にのみ使用可能になります。 これで、作業パッケージリポジトリが次の場所にあります。 /pdr/data/packages/112amd64-2019Q2 Buildbotワーカー刑務所内。

動作中のPoudriereビルドを返すために必要なすべての構成を完了し、手動ビルドで正常に検証しました。 Buildbotでバルクビルドを自動化すると、チュートリアルの後半でこれと同じ出力が表示されます。 さらに、詳細なログを表示するためのリンクは、Webインターフェイスからアクセスできる必要があります。 これを実現し、パッケージリポジトリをクライアントに提供するために、次にWebサーバーをセットアップします。

ステップ6—PoudriereWebインターフェイスとパッケージリポジトリを提供するようにNginxを構成する

Poudriereは、Webサーバーを使用してホストするいくつかの出力アーティファクトを提供します。

  • パッケージリポジトリがクライアントに提供されるため、クライアントは通常のリポジトリにアクセスできます。 pkg updatepkg install トランスポートとしてHTTPSまたはHTTPを使用するコマンド。
  • 詳細なビルドログは、開発者が問題のあるビルドをデバッグしたり、ビルド出力を調査したりするのに役立ちます。 これらはパッケージごとおよびビルドごとに保存されます。最後のステップのPoudriere出力では、ログがビルドごとに1つのディレクトリに保存され、日付と時刻のラベルが付けられていることがわかりました。
  • Poudriereの組み込みWebインターフェイスは、ビルドごとに小さな単一のHTMLページであり、WebSocketを使用してページに表示されるステータスを定期的に更新します。 これは、ビルドの距離、他のパッケージビルドが失敗する原因となった依存関係の概要を把握するのに役立ちます。最後に、コマンドライン出力の代わりに使用します。コマンドライン出力では、特に印刷しない限り、最後に要約のみが表示されます。現在のビルドの進行状況。

静的ファイルのみを提供する必要があるため、Nginxの構成変更は短時間です。 それらを外部に提供するので、次に、サーバー上の既存のNginxインスタンスを、刑務所の外で、ワーカー刑務所内のパスから上記のファイルを提供するように構成します。

サーバーで作業するので、jailシェルを終了してください。

  1. exit

Nginx構成でエディターを開きます /usr/local/etc/nginx/nginx.conf:

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

内に次の場所を追加します server { ブロック:

/usr/local/etc/nginx/nginx.conf
. . .
http {
    . . .
    server {
        . . .
        location / {
            root /usr/local/www/nginx;
            index index.html index.htm;
        }

        # poudriere logs
        location ~ ^/logs(/(.*))?$ {
            include mime.types;
            types {
                text/plain log;
            }

            alias /usr/jails/buildbot-worker0/pdr/data/logs/bulk$1;
            index index.html index.htm;
            autoindex on;
        }

        # poudriere packages
        location ~ ^/packages(/(.*))?$ {
            alias /usr/jails/buildbot-worker0/pdr/data/packages$1;
            index no-index-file-but-required-directive-to-list-dir-contents;
            autoindex on;
        }

        location /buildbot/ {
            proxy_pass http://10.0.0.2:8010/;
        }

        . . .
    }
}
. . .

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

  1. sudo service nginx reload

最初の手動ビルドで作成されたアーティファクトを確認してみましょう。 ローカルマシンでお好みのWebブラウザを開いて、リソースにアクセスします。

パッケージリポジトリは以下のとおりです https://your-domain/packages/ (また http://your-server-ip/). ルートディレクトリにメタ情報があります。例: 112amd64-2019Q2、およびサブディレクトリ内のすべてのビルド済みパッケージ All:

詳細なビルドログおよびPoudriereの組み込みWebインターフェイスは以下にあります。 https://your-domain/logs/. ディレクトリ階層をクリックして、以前の手動ビルドのデータにアクセスします。 この例では、次のようなURLになってしまう可能性があります https://your-domain/logs/112amd64-2019Q2/latest/build.html.

サーバーのドメイン名を設定しなかった場合は、これらの例でサーバーのパブリックIPアドレスを入力する必要があります。 http://your-server-ip/logs/.

これで、ビルドを機能させ、出力(パッケージとログ)を可視化するためのすべての手動セットアップが完了します。 今後は、ビルドを自動化して継続的インテグレーションを実現します。

ステップ7—パッケージ用のBuildbotBuilderのセットアップ

このステップの目標は、既存のBuildbotサンプル構成に追加することにより、すでに手動で行っているのと同じ方法でPoudriereを実行することにより、バルクパッケージビルドを自動化することです。 このステップの終わりまでに、Buildbotは、portsツリーの選択されたブランチが変更されるたびにパッケージビルドをトリガーします。 このチュートリアルの例では、それは四半期ごとのブランチになります 2019Q2.

必要な変更はすべてBuildbotマスター構成で行われるため、マスターjailでrootシェルを開いてください。

  1. sudo jexec buildbot-master csh

まず、ビルドを実行するために実行されるコマンドとアクションを記述するビルダーを定義する必要があります。 既存の構成では /var/buildbot-master/master.cfg、セクションがあります ####### BUILDERS-エディタを開き、次の見出しが始まるまでセクション全体を置換します ####### ...、次の構成で:

  1. ee /var/buildbot-master/master.cfg
/var/buildbot-master/master.cfg(スニペット)
. . .
####### BUILDERS

c['builders'] = []

PORTS_TO_BUILD = {
    'security/sudo',
    'shells/bash',
    'sysutils/tmux',
}


# Custom classes
class PoudriereLogLineObserver(util.LogLineObserver):
    _logsRe = re.compile(r'Logs: /pdr/data/logs/bulk(/[-_/0-9A-Za-z]+)$')

    def __init__(self):
        super().__init__()
        self._hadUrls = False

    def outLineReceived(self, line):
        if not self._hadUrls:
            m = self._logsRe.search(line.strip())
            if m:
                poudriereUiUrl = f'''{re.sub('/buildbot/$', '', c['buildbotURL'])}/logs{m.group(1)}'''
                self.step.addURL('Poudriere build', poudriereUiUrl)
                self.step.addURL('Poudriere logs', poudriereUiUrl + '/logs/')
                self._hadUrls = True


class PoudriereCompileStep(steps.Compile):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.addLogObserver('stdio', PoudriereLogLineObserver())


# Poudriere bulk build
bulkBuildFactory = util.BuildFactory()
bulkBuildFactory.addSteps([
    steps.ShellCommand(
        name='update ports tree',
        command=['sudo', 'poudriere', 'ports', '-u', '-p', '2019Q2', '-v'],
        haltOnFailure=True,
    ),
    PoudriereCompileStep(
        name='make bulk',
        command=['sudo', 'poudriere', 'bulk', '-j', '112amd64', '-p', '2019Q2'] + list(sorted(PORTS_TO_BUILD)),
        haltOnFailure=True,
    ),
])
c['builders'].append(util.BuilderConfig(name='bulk-112amd64-2019Q2',
                                        workernames=['worker0'],
                                        factory=bulkBuildFactory))
. . .

これがBuildbotの拡張性をどのように利用しているかに注意してください。カスタムクラスは、Poudriereのログ出力からの情報を監視および解析するために使用されます。 つまり、 PoudriereLogLineObserver 「ログオブザーバー」として追加されます。 ビルド中に新しいログ行が出力されるたびに呼び出されます。 クラスはログでログディレクトリを検索し、それをハイパーリンクに変換します。 これらのリンクはビルドステップと一緒に表示され、ユーザーはPoudriereのWebインターフェイスとログに直接移動します。

最初のビルドステップ「portsツリーの更新」では、Poudriereの組み込みの更新コマンド(ports -u)最新バージョンのportsツリーをプルします。 これにより、以前に構成されたメソッド(SVN / Gitなど)が自動的に使用されます。 このようにして、パッケージが常に最新のコミットされたツリーに対してビルドされていることを確認できます。これは、ソフトウェアのバージョンとパッチを維持する独自のバージョン管理されたリポジトリがある場合に特に役立ちます。

上部のリスト PORTS_TO_BUILD 構築するポートを指定します。 これは、ブロックの下部に指定されているビルドファクトリの手順で使用されます。 ビルドファクトリは、ビルドをインスタンス化するために使用されるテンプレートです。 Buildbotは、トリガーされるたびに一意のビルドを作成し、ビルドは、その時点でビルドファクトリに対して定義されたステップのコピーを使用します。 この場合、正確に2つのステップを構成しました。

  • ポートツリーを更新します。 この例では四半期ブランチを使用しているため 2019Q2、変更を頻繁に受け取ることはありません(通常はセキュリティとビルドの修正のみ)。
  • 同じツリーを使用して一括ビルドを実行します。

追加したコードブロックを機能させるには、ファイルの先頭に必要なインポートを追加してください。

/var/buildbot-master/master.cfg(スニペット)
# -*- python -*-
# ex: set filetype=python:

import re

from buildbot.plugins import *

The re Pythonのライブラリは、正規表現を実装しています。これは、文字列の一部を検索または置換する機能です。 PoudriereLogLineObserver クラスはそれを使用して行を検索します Logs: /pdr/data/logs/... ログディレクトリについて言及しています。

ビルドコマンドは sudo 特定のコマンドを実行します。 これが必要なのは、ビルドを実行するときにPoudriereがスーパーユーザー権限を必要とし、ビルドjailを作成、管理、および破棄するためです。また、Poudriereが管理するポートツリーは、rootユーザーを所有者として作成されます。 前のチュートリアルでは、Buildbotワーカープロセスを実行するユーザーを次のように構成しました。 sysrc buildbot_worker_uid=buildbot-worker. したがって、 buildbot-worker ユーザーはrootとして必要なコマンドを正確に実行しますが、他のコマンドは実行しません(セキュリティ上の理由から)。 インストールしましょう sudo プログラムし、それに応じて構成します。

これは、マスターではなく、労働者の刑務所で行う必要があります。 マスター刑務所シェルを終了し、ワーカー刑務所に入ります。

  1. exit
  1. sudo jexec buildbot-worker0 csh

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

  1. pkg install sudo

でインストールを確認します yENTER.

FreeBSDでは、sudoパッケージはデフォルトで設定ファイルを /usr/local/etc/sudoers.d/. エディターを開いて、新しい構成ファイルを作成します。

  1. env EDITOR=ee visudo /usr/local/etc/sudoers.d/buildbot-worker

の用法 visudo 構文エラーを警告し、不適切な構成をコミットする代わりにそれらを修正できるようにするため、意図的です。

どのコマンドを指定するか buildbot-worker ユーザーはパスワードを必要とせずにrootとして実行できます。

/usr/local/etc/sudoers.d/buildbot-worker
buildbot-worker ALL=(ALL) NOPASSWD: /usr/local/bin/poudriere bulk *
buildbot-worker ALL=(ALL) NOPASSWD: /usr/local/bin/poudriere ports -u *

ファイルを保存し、マスターjailに戻って、Buildbotマスターのさらに必要な構成を行います。

  1. exit
  1. sudo jexec buildbot-master csh

バルクビルドを機能させるための要件を満たしました。 ただし、前述のように、実行するには、各ビルドをトリガーする必要があります。 Buildbotは、ビルドがトリガーされるタイミングと、どのブランチが変更されたかなどの追加情報を定義するオブジェクトにスケジューラーという用語を使用します。 既存のセクションを削除してください SCHEDULERS 構成ファイルから、次のコンテンツをの後にに配置します。 BUILDERS セクション。コードが既存のすべてのビルダー名を使用できるようにします。

  1. ee /var/buildbot-master/master.cfg
/var/buildbot-master/master.cfg(スニペット)
. . .
####### SCHEDULERS

c['schedulers'] = []

# Forceful scheduler allowed for all builders
c['schedulers'].append(schedulers.ForceScheduler(
    name='force',
    builderNames=[builder.name for builder in c['builders']]))

# Watch ports tree for changes on given branch
c['schedulers'].append(schedulers.SingleBranchScheduler(
    name='sched-bulk-112amd64-2019Q2',
    change_filter=util.ChangeFilter(project='freebsd-ports', branch='branches/2019Q2'),
    builderNames=['bulk-112amd64-2019Q2']))
. . .

これにより、サンプル構成が置き換えられ、すべてのビルダーにforceボタンが表示されます。 そして最も重要なことは、与えられたものに関連するすべての変更を監視するスケジューラーを作成することです project/branch 変更ごとにビルドをトリガーします。 ただし、そのような変更イベントは発生しません。最初に変更ソースを作成する必要があります。 通常、これらはSVNやGitなどのバージョン管理システムであり、ブランチの変更を検出できます。 Buildbotは最も人気のあるものをサポートしているため、その機能を使用して、選択したアップストリームポートツリーリポジトリをソースとして追加できます。 セクションを完全に置き換えます CHANGESOURCES 次の構成で:

/var/buildbot-master/master.cfg(スニペット)
. . .
####### CHANGESOURCES

c['change_source'] = []

c['change_source'].append(changes.SVNPoller(
    'svn://svn.freebsd.org/ports/',
    project='freebsd-ports',
    split_file=util.svn.split_file_branches,
    svnbin='svnlite',
    pollInterval=4 * 3600))

# Example for Git:
# c['change_source'].append(changes.GitPoller(
#     repourl='https://github.com/AndiDog/freebsd-ports.git',
#     project='freebsd-ports',
#     branches=['custom'],
#     pollInterval=4 * 3600))
. . .

これにより、Buildbotマスターで4時間ごとにSVNリポジトリがポーリングされ、新しい(以前は表示されなかった)変更が一致するスケジューラーに転送され、ビルドがトリガーされて、最終的に単一のBuildbotワーカーで実行されるようにディスパッチされます。 ポートツリーは非常に大きく、最初に実行すると、これらのポーラーは完全な履歴(Gitの場合、指定されたブランチのみ)をダウンロードします。これには数分かかり、かなりのスペース(数ギガバイト)が必要になる場合があります。

Buildbotを再起動して、新しい構成ファイルを適用します。

  1. service buildbot restart

この例では、からのアップストリームポートコレクションを使用しています svn://svn.freebsd.org/ports/ ブランチはいつでもビルドがスケジュールされます 2019Q2 変更します。 前に述べたように、四半期ごとのブランチはほとんど安定しており、更新を頻繁に受信しません。 ビルドが最初にトリガーされる前に、このような変更が行われるのを待ちたくない場合があるので、手動で1回実行してみましょう。

Buildbot Webインターフェイスを開きます(https://your-domain/buildbot/)、ビルド>ビルダー>バルク-112amd64-2019Q2に移動します。 ビルドはまだ表示されません。

右上のforceボタンをクリックし、 StartBuildをクリックします。 これにより、デフォルト設定を使用してビルドがトリガーされます。 reason、branch、およびその他の値はオーバーライドされません。 「portsツリーの更新」ステップの実行には1分かかる場合があり、最終的にはPoudriereビルドも正常に実行されるはずです。 Webインターフェースは、ビルドが成功したことを示します。

リンクの1つ(PoudriereビルドおよびPoudriereログ)をクリックすると、それぞれこの特定のビルドのPoudriere Webインターフェイスとビルドログに移動します(手順6を参照)。 make Bulk の横にある矢印をクリックして展開し、 stdio>すべての…行を表示して、 poudriere bulk ... 指図。

最初のビルドが完了すると、ステップ6のNginxで構成されているように、パッケージが利用可能になります。 に行く https://your-domain/packages/ (また http://your-server-ip/packages/)ブラウザで、Poudriereによって作成されたパッケージリポジトリをクリックします。 あなたは実際のパッケージファイルを見つけることができます(*.txz)リポジトリの1つに入り、に移動したら All/ サブディレクトリ。

パッケージがHTTPS(または、必要に応じてHTTP)で利用可能になり、ポートツリーの変更に基づいて自動的に構築されるようになったため、これらのパッケージを使用するように1つ以上のホストを構成できます。

ステップ8—パッケージクライアントの構成

このステップでは、2番目のFreeBSDサーバーが必要であり、CIサーバー上に構築されたパッケージをフェッチしてインストールできるようにセットアップします。 この2番目のサーバーをパッケージクライアントと呼びます。

クライアントホストにSSHで接続します。 このセクションの残りのほとんどの手順は、クライアントで実行されます。

  1. ssh package-client

カスタムパッケージリポジトリ構成用のディレクトリを作成します。

  1. sudo mkdir -p /usr/local/etc/pkg/repos

root ユーザーとして、エディターを開いてファイルを作成します /usr/local/etc/pkg/repos/ci.conf、およびパッケージを取得する方法と場所を指定します。

  1. sudo ee /usr/local/etc/pkg/repos/ci.conf

パッケージ署名を選択した場合は、次のコンテンツを使用してください。

/usr/local/etc/pkg/repos/ci.conf
ci: {
    url: "https://your-domain/packages/112amd64-2019Q2",
    signature_type: "pubkey",
    pubkey: "/usr/local/etc/pkg/repos/ci.pub",
    enabled: yes
}

または、パッケージ署名を使用しないことにした場合は、次のように署名チェックを無効にします。

/usr/local/etc/pkg/repos/ci.conf
ci: {
    url: "https://your-domain/packages/112amd64-2019Q2",
    signature_type: "none",
    enabled: yes
}

注:この注は、ステップ2に従ってパッケージリポジトリ署名キーを作成した場合にのみ適用されます。 それ以外の場合はスキップしてください。

ローカルマシンから、公開鍵をパッケージクライアントにアップロードします。

  1. scp /tmp/poudriere.pub package-client:/tmp/ci.pub

クライアントシェルを再度使用して、キーを所定の位置に移動し、パッケージの信頼性を検証できるようにします。

  1. sudo mv /tmp/ci.pub /usr/local/etc/pkg/repos/ci.pub

パッケージリポジトリの設定を完了して有効にしましたが、通常のFreeBSDインストールでは、公式のパッケージリポジトリ「FreeBSD」も有効になります。 異なるソースからインストールされたパッケージを混合することは、互換性のないソフトウェアバージョン、または異なるABI、API、またはビルドオプションが原因で、ある時点で本番ソフトウェアをクラッシュさせる確実な方法です。 ホスト上のすべてのパッケージは、同じソースから派生している必要があります。

公式リポジトリのデフォルト設定はに保存されます /etc/pkg/FreeBSD.conf. このファイルは基本システムに属しているため、変更しないでください。 ただし、設定ファイルにそれぞれのフラグを追加することで、その設定を上書きできます(つまり、リポジトリを完全に無効にします)。 /usr/local/etc/pkg/repos、独自のリポジトリも構成されています。 新しいファイルを作成してください /usr/local/etc/pkg/repos/FreeBSD.conf エディターを使用し、次のコンテンツを使用してFreeBSDリポジトリーを無効にします。

  1. sudo ee /usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
    enabled: no
}

完全に元のパッケージクライアントホストを使用している場合、パッケージはまだインストールされていないため、すぐに独自のパッケージリポジトリの使用を開始できます。 ただし、別のソースから1つのパッケージしかインストールされていない場合は、それらのパッケージをアンインストールし、独自のソースを使用して最初から開始することをお勧めします。 パッケージマネージャー pkg それ自体はパッケージとしてインストールされます—鶏が先か卵が先かという問題を解決するために、FreeBSDの基本システムには小さな実行可能ファイルが付属しています /usr/sbin/pkg、パッケージマネージャーをブートストラップできます。 つまり、ダウンロードします pkg パッケージ化して、システムの最初のパッケージとしてインストールします。 その時点から、実行可能ファイル /usr/local/sbin/pkg そのパッケージのは、本格的なパッケージマネージャーとしてあなたをサポートします。

次のコマンドを実行してブートストラップします pkg:

  1. sudo pkg bootstrap

の出力で pkg bootstrap、パッケージは、私たちが呼び出した独自のパッケージリポジトリから取得されていることがわかります。 ci 構成ファイル内。 パッケージ署名キーを使用している場合、出力にはセキュリティ検証についてのヒントも表示されます。

Output
The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from https://your-domain/packages/112amd64-2019Q2, please wait... Verifying signature with public key /usr/local/etc/pkg/repos/ci.pub... done Installing pkg-1.10.5_5... Extracting pkg-1.10.5_5: 100%

この正常な出力が表示された場合は、次のノートブロックにスキップしてください。 ただし、パッケージマネージャーまたは他のパッケージがすでに別のソースからインストールされている場合は、次のエラーが発生します。

Output
pkg already bootstrapped at /usr/local/sbin/pkg

次に、メモの指示に従ってください。

注–パッケージマネージャーがすでにブートストラップされている場合のみ:

インストールされているパッケージを一覧表示できます pkg info. この場合、それらを含むすべてをアンインストールする必要があります pkg、後で再インストールします。 これを行うには、最初に手動でインストールされたパッケージをリストしてください。 pkg query -e "%a==0" "%n". 後でもう一度インストールするものを覚えておいてください。 たとえば、ベースシステムの一部ではないシェルを使用する場合(例: bashは外部パッケージです)、後で再インストールする必要があります。そうしないと、再度ログインできない場合があります。

次のコマンドは、既存のすべてのパッケージとパッケージマネージャーを削除し、独自のパッケージリポジトリからパッケージマネージャーを再度ブートストラップし、bashなどの目的のパッケージを再インストールする例を示します。 ただし、CIを介してビルドしたパッケージのみをインストールできることに注意してください。 Buildbotマスター構成にリストされています(変数 PORTS_TO_BUILD).

まず、アンインストールする前にrootシェルを開きます sudo パッケージを使用しないと、スーパーユーザー権限を取得できなくなる可能性があります。 ブートストラップするまで開いたままにします pkg チュートリアルの過程で、正常に再インストールされました sudo:

  1. sudo sh

を含むすべてのパッケージをアンインストールします pkg:

  1. pkg delete --all --force

パッケージマネージャーをブートストラップします。

  1. pkg bootstrap

を押して、パッケージマネージャーをブートストラップすることを確認します y、 に続く ENTER.

HTTPS用のLet’sEncrypt証明書を使用してパッケージホストを設定する可能性が高い場合、パッケージホストが信頼されていないが、パッケージをインストールする必要がある鶏が先か卵が先かという問題が発生します。 ca_root_nss (信頼できるルート認証局を含む)Let’s Encrypt CAを信頼し、それによってカスタムビルドパッケージをホストしているサーバーも信頼します。 内部CA(あなたまたはあなたの会社によって自己署名された)を使用した場合にも同じ問題が発生します。 証明書検証エラーは、パッケージマネージャーをブートストラップするときに次のようなエラー出力をもたらします。

Output
The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from https://example.com/packages/112amd64-2019Q2, please wait... Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34389740104:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269: [...]

このエラーが表示された場合は、以下の注の指示に従ってください。 それ以外の場合は、すべて設定されており、この部分をスキップしてメモの後に続行できます。

注– HTTPSの使用と証明書の検証が失敗した場合のみ:

直接的な回避策が1つあります。パッケージ署名キーのセキュリティを信頼し、ブートストラップを行うことです。 pkg とインストール ca_root_nss 暗号化されていないHTTPを介したパッケージ。 プライバシーの懸念、ブロックされたHTTPポートなどのため、これが常にオプションであるとは限らないため、より「ベストプラクティス」の方法を選択する必要があります。 公式のFreeBSDリポジトリもLet’sEncryptによって署名されているため、単純にインストールすることはできません。 ca_root_nss そこからパッケージ。 どのCAであっても、信頼できるHTTPSCAの固定セットを使用してパッケージクライアントを設定することをお勧めします。 次のいくつかの手順でそれを正確に達成できます。 これはLet’sEncryptの場合であると想定しますが、手順は、独自の自己署名CAでも同じように機能します(証明書チェーンが手元にある必要があります)。

Webブラウザーで、https://letsencrypt.org/certificates/にあるLet’sEncryptの証明書リストにアクセスします。 Webサイトがブラウザによって信頼されていることを確認してください。 ルート証明書>アクティブ>ISRGルートX1(自己署名)および中間証明書>アクティブ> Let’s Encrypt Authority X3(ISRGルートX1による署名)の下の証明書をPEM形式でダウンロードします。 /tmp/root.pem/tmp/intermediate.pem それぞれローカルコンピュータで。

ダウンロードが成功したら、ファイルを証明書チェーンに連結します。

  1. cat /tmp/intermediate.pem /tmp/root.pem >/tmp/letsencrypt-chain.pem
  1. scp /tmp/letsencrypt-chain.pem package-client:/tmp/.

パッケージクライアントのシェルに戻る、パッケージマネージャー構成でこの信頼の鎖を指定する必要があります /usr/local/etc/pkg.conf そのため、TLS検証に使用されます。 エディターを使用してこれらの行を追加し、ファイルがまだ存在しない場合はファイルを作成します。

  1. sudo ee /usr/local/etc/pkg.conf
/usr/local/etc/pkg.conf(スニペット)
pkg_env: {
    SSL_CA_CERT_FILE: "/usr/local/etc/pkg/repos/letsencrypt-chain.pem",
}

CAチェーンを所定の位置に移動します。

  1. sudo mv /tmp/letsencrypt-chain.pem /usr/local/etc/pkg/repos/.

sudoパッケージが削除されたためにこれまでルートシェルにとどまっていた場合、このコマンドは sudo. このメモ内の次のコマンドにも同じことが当てはまります。

この設定を使用すると、ブートストラップをもう一度試すことができ、TLSエラーが発生することはありません。 小さなひねりが1つあります。FreeBSDビルトインです。 /usr/sbin/pkg、完全なパッケージマネージャーをブートストラップしますが、構成されたものを尊重しません pkg_env 設定されているため、構成されているのと同じ値を使用して、それぞれの環境変数を1回だけオーバーライドする必要があります。

  1. sudo env SSL_CA_CERT_FILE=/usr/local/etc/pkg/repos/letsencrypt-chain.pem pkg bootstrap

以前に既存のパッケージを削除したことがある場合は、今すぐ重要なツールを再インストールすることをお勧めします(例: sudo)、およびその他の必要なパッケージ。

  1. pkg install bash sudo

それでも問題が解決しない場合は、ルートシェルからドロップアウトします。

  1. exit

すべてが機能するかどうかをテストするには、Buildbotマスター構成で指定されたリストからパッケージをインストールします(可変 PORTS_TO_BUILD). たとえば、Bashシェルとsudo:

  1. sudo pkg install bash sudo tmux

もう一度、を押してインストールを確認します y その後 ENTER. パッケージのインストールは問題なく実行されます。

使用できます pkg info 現在インストールされているパッケージを一覧表示します(依存関係がある場合はそれを含む)。 他のソースからのパッケージがインストールされていないことを確認するために、クラッシュや非互換性を引き起こす可能性があります。以下を使用して、インストールされているパッケージとこれらの詳細を一覧表示できます。 pkg query "%n: autoinstalled=%a from repo=%R". 気をつけて pkg からブートストラップされたものとして表示されます unknown-repository—これが、以前にブートストラップ出力を検証して、パッケージマネージャー自体も独自のパッケージリポジトリから取得されていることを確認した理由です。

この最後のステップでは、クライアント上のCIのパッケージリポジトリへのアクセスを構成し、オプションでセキュリティ目的でパッケージ署名の検証を有効にし、互換性の問題を回避するためにパッケージが単一のソースからのみ取得されるようにし、パッケージマネージャーをブートストラップしました pkg、CIによってビルドされた目的のパッケージをインストールします。

結論

このチュートリアルでは、Poudriereのインストールと構成、パッケージビルドの自動実行、クライアントホストからのパッケージリポジトリへの安全なアクセスの構成を行い、最終的に単一の中央ソースからインストールされた最新のビルドパッケージを作成しました。 このセットアップにより、サーバーの一貫性と最新性を維持し、外部ソフトウェアパッケージのバージョンアップグレードを管理できる優れた立場になります。

現在の設定をさらに強化するために、次のフォローアップ手順を選択することを検討できます。

  • プライベートアクセスのみ:デフォルトでは、ドロップレットはインターネット上でパブリックIPアドレスを持っています。 また、Buildbot は認証をサポートしていますが、デフォルトでは保護されていません。
  • ビルドの問題に関するアラート:開始するには、Buildbotレポーターのセットアップ方法を確認してください。
  • ポートツリーを最新の状態に保つ:チュートリアルの例では、四半期ブランチ 2019Q2が使用されましたが、最終的には新しいツリーに切り替えるか、独自のバージョン管理されたリポジトリを使用する必要があります必要なパッチを適用します。
  • 独自のプロジェクトのビルドの追加 FreeBSD Porter’s Handbook は、内部ソフトウェアをビルドしてインストールする場合のビルドレシピ( port )の書き方を説明しています。 FreeBSDパッケージ。
  • クライアントで古いパッケージを監視する:クライアントにインストールされているパッケージを、CIで利用可能な最新のパッケージと比較するには、次の出力を使用します。 sudo pkg update -q && sudo pkg version -q --not-like "=" バージョンが完全に一致しないすべてのパッケージを印刷します。 詳細については、pkg-versionマンページを参照してください。
  • クリーンアップジョブの追加:時間の経過とともに、Buildbotワーカーjailは、古いビルドログファイル、ソースtarball、および場合によっては非推奨のパッケージでいっぱいになります。 コマンドを使用する poudriere {logclean,distclean,pkgclean} クリーンアップする( poudriereのマンページを参照)。