3.4. Git ソース
ソースコードは、指定されている場合は指定先の場所からフェッチされます。
インラインの Dockerfile を指定する場合は、これにより Git リポジトリーの contextDir
内にある Dockerfile が上書きされます。
ソースの定義は BuildConfig
の spec
セクションに含まれます。
source: git: 1 uri: "https://github.com/openshift/ruby-hello-world" ref: "master" contextDir: "app/dir" 2 dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3
- 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
パイプラインストラテジーのビルドの場合には、現在 Jenkins の Git プラグインに制約があるので、Git プラグインを使用する Git の操作では BuildConfig
に定義された HTTP または HTTPS プロキシーは使用されません。Git プラグインは、Jenkins UI の Plugin Manager パネルで設定されたプロキシーのみを使用します。どのジョブであっても、Jenkins 内の Git のすべての対話にはこのプロキシーが使用されます。
関連情報
- Jenkins UI でのプロキシーの設定方法は、JenkinsBehindProxy を参照してください。
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
パスワードを再度入力しなくてもよいように、ビルドに Source-to-Image (S2I) イメージを指定するようにしてください。ただし、リポジトリーをクローンできない場合には、ビルドをプロモートするためにユーザー名とパスワードを指定する必要があります。
関連情報
-
アプリケーションソースコードの
/var/run/secrets/openshift.io/source/
フォルダー。
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) 攻撃を受ける可能性があります。注記know_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 証明書ファイルを使用して Basic 認証のシークレットを作成し、以下を実行します。
$ 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. .gitconfig ファイルを使用した Basic 認証シークレットの作成
Basic 認証および .gitconfig
ファイルを組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- Basic 認証の認証情報
-
.gitconfig
ファイル
手順
.gitconfig
ファイルで Basic 認証のシークレットを作成するには、以下を実行します。$ 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 証明書ファイルを合わせて Basic 認証シークレットを作成するには、以下を実行します。$ 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