3.4. Git ソース
ソースコードは、指定されている場合は指定先の場所からフェッチされます。
インラインの Dockerfile を指定する場合は、これにより Git リポジトリーの contextDir 内にある Dockerfile が上書きされます。
ソースの定義は BuildConfig の spec セクションに含まれます。
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"
- 1
gitフィールドには、ソースコードのリモート Git リポジトリーへの URI (Uniform Resource Identifier) が含まれます。特定の Git リファレンスをチェックアウトするには、refフィールドの値を指定する必要があります。SHA1 タグまたはブランチ名は、refとして有効です。refフィールドのデフォルト値はmasterです。- 2
contextDirフィールドでは、ビルドがアプリケーションのソースコードを検索する、ソースコードのリポジトリー内のデフォルトの場所をオーバーライドできます。アプリケーションがサブディレクトリーに存在する場合には、このフィールドを使用してデフォルトの場所 (root フォルダー) をオーバーライドすることができます。- 3
- オプションの
dockerfileフィールドがある場合は、Dockerfile を含む文字列を指定してください。この文字列は、ソースリポジトリーに存在する可能性のある Dockerfile を上書きします。
ref フィールドにプル要求が記載されている場合には、システムは git fetch 操作を使用して FETCH_HEAD をチェックアウトします。
ref の値が指定されていない場合は、OpenShift Container Platform はシャロークローン (--depth=1) を実行します。この場合、デフォルトのブランチ (通常は master) での最新のコミットに関連するファイルのみがダウンロードされます。これにより、リポジトリーのダウンロード時間が短縮されます (詳細のコミット履歴はありません)。指定リポジトリーのデフォルトのブランチで完全な git clone を実行するには、ref をデフォルトのブランチ名に設定します (例: main)。
中間者 (MITM) TLS ハイジャックまたはプロキシーされた接続の再暗号化を実行するプロキシーを通過する Git クローンの操作は機能しません。
3.4.1. プロキシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーの使用によってのみ Git リポジトリーにアクセスできる場合は、使用するプロキシーをビルド設定の source セクションで定義できます。HTTP および HTTPS プロキシーの両方を設定できます。いずれのフィールドもオプションです。NoProxy フィールドで、プロキシーを実行しないドメインを指定することもできます。
実際に機能させるには、ソース URI で HTTP または HTTPS プロトコルを使用する必要があります。
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
ref: "master"
httpProxy: http://proxy.example.com
httpsProxy: https://proxy.example.com
noProxy: somedomain.com, otherdomain.com
Pipeline ストラテジー builds の場合には、現在 Jenkins の Git プラグインに制約があるので、Git プラグインを使用する Git の操作では BuildConfig に定義された HTTP または HTTPS プロキシーは使用されません。Git プラグインは、Jenkins UI の Plugin Manager パネルで設定されたプロキシーのみを使用します。どのジョブであっても、Jenkins 内の Git のすべての対話にはこのプロキシーが使用されます。
3.4.2. ソースクローンのシークレット リンクのコピーリンクがクリップボードにコピーされました!
ビルダー Pod には、ビルドのソースとして定義された Git リポジトリーへのアクセスが必要です。ソースクローンのシークレットは、ビルダー Pod に対し、プライベートリポジトリーや自己署名証明書または信頼されていない SSL 証明書が設定されたリポジトリーなどの通常アクセスできないリポジトリーへのアクセスを提供するために使用されます。
以下は、サポートされているソースクローンのシークレット設定です。
-
.gitconfigファイル - Basic 認証
- SSH キー認証
- 信頼された認証局
特定のニーズに対応するために、これらの設定の組み合わせを使用することもできます。
3.4.2.1. ソースクローンシークレットのビルド設定への自動追加 リンクのコピーリンクがクリップボードにコピーされました!
BuildConfig が作成されると、OpenShift Container Platform はソースクローンのシークレット参照を自動生成します。この動作により、追加の設定なしに、作成されるビルドが参照されるシークレットに保存された認証情報を自動的に使用できるようになり、リモート Git リポジトリーに対する認証が可能になります。
この機能を使用するには、Git リポジトリーの認証情報を含むシークレットが BuildConfig が後に作成される namespace になければなりません。このシークレットには、接頭辞 build.openshift.io/source-secret-match-uri- で開始するアノテーション 1 つ以上含まれている必要もあります。これらの各アノテーションの値には、以下で定義される URI (Uniform Resource Identifier) パターンを使用します。これは以下のように定義されます。ソースクローンのシークレット参照なしに BuildConfig が作成され、Git ソースの URI がシークレットのアノテーションの URI パターンと一致する場合に、OpenShift Container Platform はそのシークレットへの参照を BuildConfig に自動的に挿入します。
前提条件
URI パターンには以下を含める必要があります。
-
有効なスキーム:
*://、git://、http://、https://またはssh:// -
ホスト: *` または有効なホスト名、あるいは
*.が先頭に指定された IP アドレス -
パス:
/*または、/の後に*文字などの文字がオプションで後に続きます。
上記のいずれの場合でも、* 文字はワイルドカードと見なされます。
URI パターンは、RFC3986 に準拠する Git ソースの URI と一致する必要があります。URI パターンにユーザー名 (またはパスワード) のコンポーネントを含ないようにしてください。
たとえば、Git リポジトリーの URL に ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git を使用する場合に、ソースのシークレットは、ssh://bitbucket.atlassian.com:7999/* として指定する必要があります (ssh://git@bitbucket.atlassian.com:7999/* ではありません)。
$ oc annotate secret mysecret \
'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'
手順
複数のシークレットが特定の BuildConfig の Git URI と一致する場合は、OpenShift Container Platform は一致する文字列が一番長いシークレットを選択します。これは、以下の例のように基本的な上書きを許可します。
以下の部分的な例では、ソースクローンのシークレットの一部が 2 つ表示されています。1 つ目は、HTTPS がアクセスする mycorp.com ドメイン内のサーバーに一致しており、2 つ目は mydev1.mycorp.com および mydev2.mycorp.com のサーバーへのアクセスを上書きします。
kind: Secret
apiVersion: v1
metadata:
name: matches-all-corporate-servers-https-only
annotations:
build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
...
---
kind: Secret
apiVersion: v1
metadata:
name: override-for-my-dev-servers-https-only
annotations:
build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
...
以下のコマンドを使用して、
build.openshift.io/source-secret-match-uri-アノテーションを既存のシークレットに追加します。$ oc annotate secret mysecret \ 'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
3.4.2.2. ソースクローンシークレットの手動による追加 リンクのコピーリンクがクリップボードにコピーされました!
ソースクローンのシークレットは、ビルド設定に手動で追加できます。sourceSecret フィールドを BuildConfig 内の source セクションに追加してから、作成したシークレットの名前に設定して実行できます。この例では basicsecret です。
apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
name: "sample-build"
spec:
output:
to:
kind: "ImageStreamTag"
name: "sample-image:latest"
source:
git:
uri: "https://github.com/user/app.git"
sourceSecret:
name: "basicsecret"
strategy:
sourceStrategy:
from:
kind: "ImageStreamTag"
name: "python-33-centos7:latest"
手順
oc set build-secret コマンドを使用して、既存のビルド設定にソースクローンのシークレットを設定することも可能です。
既存のビルド設定にソースクローンシークレットを設定するには、以下のコマンドを実行します。
$ oc set build-secret --source bc/sample-build basicsecret
3.4.2.3. .gitconfig ファイルからのシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションのクローンが .gitconfig ファイルに依存する場合、そのファイルが含まれるシークレットを作成できます。これをビルダーサービスアカウントおよび BuildConfig に追加します。
手順
-
.gitconfigファイルからシークレットを作成するには、以下を実行します。
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
.gitconfig ファイルの http セクションが sslVerify=false に設定されている場合は、SSL 検証をオフにすることができます。
[http]
sslVerify=false
3.4.2.4. セキュリティー保護された Git の .gitconfig ファイルからのシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Git サーバーが 2 方向の SSL、ユーザー名とパスワードでセキュリティー保護されている場合には、ソースビルドに証明書ファイルを追加して、.gitconfig ファイルに証明書ファイルへの参照を追加する必要があります。
前提条件
- Git 認証情報が必要です。
手順
ソースビルドに証明書ファイルを追加して、.gitconfig ファイルに証明書ファイルへの参照を追加します。
-
client.crt、cacert.crt、およびclient.keyファイルをアプリケーションソースコードの/var/run/secrets/openshift.io/source/フォルダーに追加します。 サーバーの
.gitconfigファイルに、以下のように[http]セクションを追加します。# cat .gitconfig出力例
[user] name = <name> email = <email> [http] sslVerify = false sslCert = /var/run/secrets/openshift.io/source/client.crt sslKey = /var/run/secrets/openshift.io/source/client.key sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crtシークレットを作成します。
$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \1 --from-literal=password=<password> \2 --from-file=.gitconfig=.gitconfig \ --from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \ --from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \ --from-file=client.key=/var/run/secrets/openshift.io/source/client.key
パスワードを再度入力しなくてもよいように、builds に Source-to-Image (S2I) イメージを指定するようにしてください。ただし、リポジトリーをクローンできない場合には、ビルドをプロモートするためにユーザー名とパスワードを指定する必要があります。
3.4.2.5. ソースコードの基本的な認証からのシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Basic 認証では、SCM (software configuration management) サーバーに対して認証する場合に --username と --password の組み合わせ、またはトークンが必要です。
前提条件
- プライベートリポジトリーにアクセスするためのユーザー名およびパスワード。
手順
シークレットを先に作成してから、プライベートリポジトリーにアクセスするために
--usernameおよび--passwordを使用してください。$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --type=kubernetes.io/basic-authトークンで Basic 認証のシークレットを作成します。
$ oc create secret generic <secret_name> \ --from-literal=password=<token> \ --type=kubernetes.io/basic-auth
3.4.2.6. ソースコードの SSH キー認証からのシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
SSH キーベースの認証では、プライベート SSH キーが必要です。
リポジトリーのキーは通常 $HOME/.ssh/ ディレクトリーにあり、デフォルトで id_dsa.pub、id_ecdsa.pub、id_ed25519.pub、または id_rsa.pub という名前が付けられています。
手順
SSH キーの認証情報を生成します。
$ ssh-keygen -t ed25519 -C "your_email@example.com"注記SSH キーのパスフレーズを作成すると、OpenShift Container Platform でビルドができなくなります。パスフレーズを求めるプロンプトが出されても、ブランクのままにします。
パブリックキーと、それに対応するプライベートキーのファイルが 2 つ作成されます (
id_dsa、id_ecdsa、id_ed25519またはid_rsaのいずれか)。これらが両方設定されたら、パブリックキーのアップロード方法について、ソースコントロール管理 (SCM) システムのマニュアルを参照してください。プライベートキーは、プライベートリポジトリーにアクセスするために使用されます。SSH キーを使用してプライベートリポジトリーにアクセスする前に、シークレットを作成します。
$ oc create secret generic <secret_name> \ --from-file=ssh-privatekey=<path/to/ssh/private/key> \ --from-file=<path/to/known_hosts> \1 --type=kubernetes.io/ssh-auth- 1
- オプション: このフィールドを追加すると、厳密なサーバーホストキーチェックが有効になります。
警告シークレットの作成中に
known_hostsファイルをスキップすると、ビルドが中間者 (MITM) 攻撃を受ける可能性があります。注記known_hostsファイルにソースコードのホストのエントリーが含まれていることを確認してください。
3.4.2.7. ソースコードの信頼されている認証局からのシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Git clone の操作時に信頼される TLS (Transport Layer Security) 認証局 (CA) のセットは OpenShift Container Platform インフラストラクチャーイメージにビルドされます。Git サーバーが自己署名の証明書を使用するか、イメージで信頼されていない認証局によって署名された証明書を使用する場合には、その証明書が含まれるシークレットを作成するか、TLS 検証を無効にしてください。
CA 証明書のシークレットを作成した場合に、OpenShift Container Platform はその証明書を使用して、Git clone 操作時に Git サーバーにアクセスします。存在する TLS 証明書をどれでも受け入れてしまう Git の SSL 検証の無効化に比べ、この方法を使用するとセキュリティーレベルが高くなります。
手順
CA 証明書ファイルでシークレットを作成します。
CA が中間認証局を使用する場合には、
ca.crtファイルにすべての CA の証明書を統合します。以下のコマンドを実行します。$ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt次のコマンドを入力してシークレットを作成します。
$ oc create secret generic mycert --from-file=ca.crt=</path/to/file>1 - 1
ca.crtというキーの名前を使用する必要があります。
3.4.2.8. ソースシークレットの組み合わせ リンクのコピーリンクがクリップボードにコピーされました!
特定のニーズに対応するために上記の方法を組み合わせてソースクローンのシークレットを作成することができます。
3.4.2.8.1. .gitconfig ファイルでの SSH ベースの認証シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
SSH ベースの認証シークレットと .gitconfig ファイルなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- SSH 認証
-
.gitconfigファイル
手順
.gitconfigファイルを使用して SSH ベースの認証シークレットを作成するには、次のコマンドを入力します。$ oc create secret generic <secret_name> \ --from-file=ssh-privatekey=<path/to/ssh/private/key> \ --from-file=<path/to/.gitconfig> \ --type=kubernetes.io/ssh-auth
3.4.2.8.2. .gitconfig ファイルと CA 証明書を組み合わせるシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
.gitconfig ファイルおよび認証局 (CA) 証明書を組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
-
.gitconfigファイル - CA 証明書
手順
.gitconfigファイルと CA 証明書を組み合わせたシークレットを作成するには、次のコマンドを入力します。$ oc create secret generic <secret_name> \ --from-file=ca.crt=<path/to/certificate> \ --from-file=<path/to/.gitconfig>
3.4.2.8.3. CA 証明書ファイルを使用した Basic 認証のシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Basic 認証および CA (certificate authority) 証明書を組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- Basic 認証の認証情報
- CA 証明書
手順
CA 証明書を使用して基本認証シークレットを作成するには、次のコマンドを入力します。
$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=ca-cert=</path/to/file> \ --type=kubernetes.io/basic-auth
3.4.2.8.4. Git 設定ファイルを使用した基本認証シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Basic 認証および .gitconfig ファイルを組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- Basic 認証の認証情報
-
.gitconfigファイル
手順
.gitconfigファイルを使用して基本認証シークレットを作成するには、次のコマンドを入力します。$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=</path/to/.gitconfig> \ --type=kubernetes.io/basic-auth
3.4.2.8.5. .gitconfig ファイルと CA 証明書を使用した Basic 認証シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Basic 認証、.gitconfig ファイルおよび CA 証明書を組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- Basic 認証の認証情報
-
.gitconfigファイル - CA 証明書
手順
.gitconfigファイルと CA 証明書を使用して基本認証シークレットを作成するには、次のコマンドを入力します。$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=</path/to/.gitconfig> \ --from-file=ca-cert=</path/to/file> \ --type=kubernetes.io/basic-auth