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 が含まれます。オプションで、ref
フィールドを指定して特定の git 参照をチェックアウトします。SHA1 タグまたはブランチ名は、ref
として有効です。- 2
contextDir
フィールドでは、ビルドがアプリケーションのソースコードを検索する、ソースコードのリポジトリー内のデフォルトの場所を上書きできます。アプリケーションがサブディレクトリーに存在する場合には、このフィールドを使用してデフォルトの場所 (root フォルダー) を上書きすることができます。- 3
- オプションの
dockerfile
フィールドがある場合は、Dockerfile を含む文字列を指定してください。 この文字列は、ソースリポジトリーに存在する可能性のある Dockerfile を上書きします。
ref
フィールドにプル要求が記載されている場合には、システムは git fetch
操作を使用して FETCH_HEAD
をチェックアウトします。
ref
の値が指定されていない場合は、OpenShift Container Platform はシャロークローン (--depth=1
) を実行します。この場合、デフォルトのブランチ (通常は master
) での最新のコミットに関連するファイルのみがダウンロードされます。これにより、リポジトリーのダウンロード時間が短縮されます (詳細のコミット履歴はありません)。指定リポジトリーのデフォルトのブランチで完全な git clone
を実行するには、ref
をデフォルトのブランチ名に設定します (例: master
)。
中間者 (MITM) TLS ハイジャックまたはプロキシーされた接続の再暗号化を実行するプロキシーを通過する Git クローンの操作は機能しません。
3.4.1. プロキシーの使用
プロキシーの使用によってのみ Git リポジトリーにアクセスできる場合は、使用するプロキシーを BuildConfig
の source
セクションで定義できます。HTTP および HTTPS プロキシーの両方を設定できます。いずれのフィールドもオプションです。NoProxy フィールドで、プロキシーを実行しないドメインを指定することもできます。
実際に機能させるには、ソース URI で HTTP または HTTPS プロトコルを使用する必要があります。
source: git: uri: "https://github.com/openshift/ruby-hello-world" httpProxy: http://proxy.example.com httpsProxy: https://proxy.example.com noProxy: somedomain.com, otherdomain.com
Pipeline ストラテジーのビルドの場合には、現在 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 キー認証
- 信頼されている認証局
特定のニーズに対応するために、これらの設定の組み合わせを使用することもできます。
手順
ビルドは builder サービスアカウントで実行されます。 この builder アカウントには、使用するソースクローンのシークレットに対するアクセスが必要です。
- 以下のコマンドを実行してアクセスを付与します。
$ oc secrets link builder mysecret
シークレットを参照しているサービスアカウントにのみにシークレットを制限することはデフォルトで無効にされています。つまり、マスターの設定ファイルで serviceAccountConfig.limitSecretReferences
がマスター設定の false
(デフォルトの設定) に設定されている場合は、サービスにシークレットをリンクする必要はありません。
3.4.2.1. ソースクローンシークレットのビルド設定への自動追加
BuildConfig
が作成されると、OpenShift Container Platform はソースクローンのシークレット参照を自動生成します。この動作により、追加の設定なしに、作成される Builds
が参照される Secret
に保存された認証情報を自動的に使用できるようになり、リモート git リポジトリーに対する認証が可能になります。
この機能を使用するには、git リポジトリーの認証情報を含む Secret
が BuildConfig
が後に作成される namespace になければなりません。この Secret
には、プレフィックスbuild.openshift.io/source-secret-match-uri-
で開始するアノテーション 1 つ以上含まれている必要もあります。これらの各アノテーションの値には、以下で定義される URI パターンを指定します。ソースクローンのシークレット参照なしに BuildConfig
が作成され、git ソースの URI が Secret
アノテーションの URI パターンと一致する場合に、OpenShift Container Platform はその Secret
への参照を 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/*'
手順
複数の Secrets
が特定の 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
セクションに追加してから、作成した secret
の名前に設定して実行できます (この例では basicsecret
)。
apiVersion: "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
追加リソース
-
BuildConfig
にシークレットを定義すると、このトピックの詳細情報を表示できます。
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
パスワードを再度入力しなくてもよいように、ビルドに S2I イメージを指定するようにしてください。ただし、リポジトリーをクローンできない場合には、ビルドをプロモートするためにユーザー名とパスワードを指定する必要があります。
追加リソース
-
アプリケーションソースコードの
/var/run/secrets/openshift.io/source/
フォルダー。
3.4.2.5. ソースコードの基本的な認証からのシークレットの作成
Basic 認証では、SCM サーバーに対して認証する場合に --username
と --password
の組み合わせ、または token
が必要です。
前提条件
- プライベートリポジトリーにアクセスするためのユーザー名およびパスワード。
手順
secret
を先に作成してから、プライベートリポジトリーにアクセスするためにユーザー名とパスワードを使用してください。$ 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 rsa -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> \ --type=kubernetes.io/ssh-auth
3.4.2.7. ソースコードの信頼されている認証局からのシークレットの作成
git clone
の操作時に信頼される TLS 認証局 (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>
- builds/creating-build-inputs.adoc
3.4.2.8.3. CA 証明書ファイルを使用した Basic 認証のシークレットの作成
Basic 認証および CA 証明書を組み合わせるシークレットなど、特定のニーズに応じてソースクローンシークレットを作成するための複数の異なる方法を組み合わせることができます。
前提条件
- 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
- builds/creating-build-inputs.adoc
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
- builds/creating-build-inputs.adoc
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