Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
注記

パイプラインストラテジーのビルドの場合には、現在 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/*'
Copy to Clipboard Toggle word wrap

手順

複数のシークレットが特定の 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:
  ...
Copy to Clipboard Toggle word wrap

  • 以下のコマンドを使用して、build.openshift.io/source-secret-match-uri- アノテーションを既存のシークレットに追加します。 

    $ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
    Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

手順

oc set build-secret コマンドを使用して、既存のビルド設定にソースクローンのシークレットを設定することも可能です。

  • 既存のビルド設定にソースクローンシークレットを設定するには、以下のコマンドを実行します。 

    $ oc set build-secret --source bc/sample-build basicsecret
    Copy to Clipboard Toggle word wrap

3.4.2.3. .gitconfig ファイルからのシークレットの作成
リンクのコピー

アプリケーションのクローンが .gitconfig ファイルに依存する場合、そのファイルが含まれるシークレットを作成できます。これをビルダーサービスアカウントおよび BuildConfig に追加します。

手順

  • .gitconfig ファイルからシークレットを作成するには、以下を実行します。 
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
Copy to Clipboard Toggle word wrap
注記

.gitconfig ファイルの http セクションが sslVerify=false に設定されている場合は、SSL 検証をオフにすることができます。 

[http]
        sslVerify=false
Copy to Clipboard Toggle word wrap

3.4.2.4. セキュリティー保護された Git の .gitconfig ファイルからのシークレットの作成
リンクのコピー

Git サーバーが 2 方向の SSL、ユーザー名とパスワードでセキュリティー保護されている場合には、ソースビルドに証明書ファイルを追加して、.gitconfig ファイルに証明書ファイルへの参照を追加する必要があります。

前提条件

  • Git 認証情報が必要です。

手順

ソースビルドに証明書ファイルを追加して、.gitconfig ファイルに証明書ファイルへの参照を追加します。

  1. client.crt、cacert.crt、および client.key ファイルをアプリケーションソースコードの /var/run/secrets/openshift.io/source/ フォルダーに追加します。

  2. サーバーの .gitconfig ファイルに、以下のように [http] セクションを追加します。 

    # cat .gitconfig
    Copy to Clipboard Toggle word wrap

    出力例

    [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
    Copy to Clipboard Toggle word wrap

  3. シークレットを作成します。 

    $ 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
    Copy to Clipboard Toggle word wrap
    1
    ユーザーの Git ユーザー名
    2
    このユーザーのパスワード
重要

パスワードを再度入力しなくてもよいように、ビルドに Source-to-Image (S2I) イメージを指定するようにしてください。ただし、リポジトリーをクローンできない場合には、ビルドをプロモートするためにユーザー名とパスワードを指定する必要があります。

3.4.2.5. ソースコードの基本的な認証からのシークレットの作成
リンクのコピー

Basic 認証では、SCM (software configuration management) サーバーに対して認証する場合に --username と --password の組み合わせ、またはトークンが必要です。

前提条件

  • プライベートリポジトリーにアクセスするためのユーザー名およびパスワード。

手順

  1. シークレットを先に作成してから、プライベートリポジトリーにアクセスするために --username および --password を使用してください。 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

  2. トークンで Basic 認証のシークレットを作成します。 

    $ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

3.4.2.6. ソースコードの SSH キー認証からのシークレットの作成
リンクのコピー

SSH キーベースの認証では、プライベート SSH キーが必要です。

リポジトリーのキーは通常 $HOME/.ssh/ ディレクトリーにあり、デフォルトで id_dsa.pub、id_ecdsa.pub、id_ed25519.pub、または id_rsa.pub という名前が付けられています。

手順

  1. SSH キーの認証情報を生成します。 

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    Copy to Clipboard Toggle word wrap
    注記

    SSH キーのパスフレーズを作成すると、OpenShift Container Platform でビルドができなくなります。パスフレーズを求めるプロンプトが出されても、ブランクのままにします。

    パブリックキーと、それに対応するプライベートキーのファイルが 2 つ作成されます (id_dsa、id_ecdsa、id_ed25519 または id_rsa のいずれか)。これらが両方設定されたら、パブリックキーのアップロード方法について、ソースコントロール管理 (SCM) システムのマニュアルを参照してください。プライベートキーは、プライベートリポジトリーにアクセスするために使用されます。

  2. 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
    Copy to Clipboard Toggle word wrap
    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 証明書ファイルでシークレットを作成します。

  1. CA が中間認証局を使用する場合には、ca.crt ファイルにすべての CA の証明書を統合します。以下のコマンドを実行します。 

    $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力してシークレットを作成します。 

    $ oc create secret generic mycert --from-file=ca.crt=</path/to/file>
    1
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
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>
    Copy to Clipboard Toggle word wrap
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
    Copy to Clipboard Toggle word wrap
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
    Copy to Clipboard Toggle word wrap
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
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat