Concourse >

目次

サンプルソース

Tips

ルートCA証明書の設定

  • リソースやタスクはすべてコンテナ内で実行されますので、コンテナから必要なCA証明書にアクセス可能であるかを常に注意する必要があります。
  • 内部CAによって署名されたサーバ証明書を用いたサーバ(各リポジトリ等)にアクセスする場合には、CA証明書の設定を必ず確認しましょう。

git-resourceの場合

  • git-resourceでは、git_config ソースオプションでGitの設定を行えますが、Gitの http.sslCAInfo オプションはCA証明書ファイルへのパスを要求するため、実質的に(リソースの設定にファイルを投入できないため)設定することができません。
  • したがって公式のgit-resourceイメージを拡張してあらかじめ目的のCA証明書をシステムストアに含めるのがベストですが、やや手間がかかります。
  • note.png非推奨ではありますが、手っ取り早い回避策としては skip_ssl_verification ソースオプションを有効にする方法があります。
    1. resources:
    2. - name: src-git
    3.   type: git
    4.   source:
    5.     uri: https://gitlab.io.example.com/concourse/examples.git
    6.     skip_ssl_verification: true
    7.     branch: master
    8.   #check_every: 1h  # default: 1m

semver-resourceの場合

  1. gitドライバ
    1. HTTPSでアクセスする場合、残念ながらCA証明書を設定するオプションがありません。
    2. SSHで接続する場合にはノーチェックでknown_hostへの追加処理が行われますので、独自CAを運用している場合にはこちらを利用することになるでしょう。

docker-image-resourceの場合

  • docker-image-resourceの場合、ca_certs ソースオプションが用意されていますのでそれを利用します。証明書自体の設定は、{{mustache}}記述でパラメータ化し、外部ファイルで管理するとよいでしょう。
    1. resources:
    2. - name: docker-reg
    3.   type: docker-image
    4.   source:
    5.     repository: gitlab.io.example.com:5050/concourse/examples/image-build00
    6.     tag: 0.0.1  # default: latest
    7.     username: {{docker-id}}
    8.     password: {{docker-pw}}
    9.     ca_certs:
    10.     - domain: gitlab.io.example.com:5050
    11.       cert: {{docker-reg-ca-cert}}
    12.   check_every: 12h  # default: 1m

タスク実行時の証明書インストール

  • 環境変数を介して、タスク実行時の先頭で証明書をインストールすることができます。
  • 以下の例では簡単なインストールスクリプト(https://github.com/wdstar/concourse-utils)を用意して、それを実行しています。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: https://github.com/wdstar/concourse-utils
    7.     branch: master
    8.   #check_every: 1h  # default: 1m
    9. - name: alpine
    10.   type: docker-image
    11.   source:
    12.     repository: alpine
    13.     tag: 3.6
    14.     registry_mirror: https://((registry-mirror-domain))
    15.     ca_certs:
    16.     - domain: ((registry-mirror-domain))
    17.       cert: ((docker-reg-ca-cert))
    18.   check_every: 12h  # default: 1m
    19. - name: buildroot
    20.   type: docker-image
    21.   source:
    22.     repository: concourse/buildroot
    23.     tag: base
    24.     registry_mirror: https://((registry-mirror-domain))
    25.     ca_certs:
    26.     - domain: ((registry-mirror-domain))
    27.       cert: ((docker-reg-ca-cert))
    28.   check_every: 12h  # default: 1m
    29. - name: centos
    30.   type: docker-image
    31.   source:
    32.     repository: centos
    33.     tag: 7
    34.     registry_mirror: https://((registry-mirror-domain))
    35.     ca_certs:
    36.     - domain: ((registry-mirror-domain))
    37.       cert: ((docker-reg-ca-cert))
    38.   check_every: 12h  # default: 1m
    39. - name: debian
    40.   type: docker-image
    41.   source:
    42.     repository: debian
    43.     tag: 9
    44.     registry_mirror: https://((registry-mirror-domain))
    45.     ca_certs:
    46.     - domain: ((registry-mirror-domain))
    47.       cert: ((docker-reg-ca-cert))
    48.   check_every: 12h  # default: 1m
    49.  
    50. jobs:
    51. - name: install-ca-certs-tests
    52.   plan:
    53.   - get: src-git
    54.     params:
    55.       depth: 5
    56.   - get: alpine
    57.   - task: alpine-test
    58.     image: alpine
    59.     params:
    60.       CA_CERTS: ((ca-certs))
    61.     config:
    62.       platform: linux
    63.       inputs:
    64.       - name: src-git
    65.       run:
    66.         #path: src-git/install-ca-certs/alpine.sh
    67.         path: /bin/sh
    68.         args:
    69.         - -c
    70.         - |
    71.           src-git/install-ca-certs/alpine.sh
    72.           tail /etc/ssl/certs/ca-certificates.crt
    73.   - get: buildroot
    74.   - task: buildroot-test
    75.     image: buildroot
    76.     params:
    77.       CA_CERTS: ((ca-certs))
    78.     config:
    79.       platform: linux
    80.       inputs:
    81.       - name: src-git
    82.       run:
    83.         #path: src-git/install-ca-certs/buildroot.sh
    84.         path: /bin/sh
    85.         args:
    86.         - -c
    87.         - |
    88.           src-git/install-ca-certs/buildroot.sh
    89.           tail /etc/ssl/certs/ca-certificates.crt
    90.   - get: centos
    91.   - task: centos-test
    92.     image: centos
    93.     params:
    94.       CA_CERTS: ((ca-certs))
    95.     config:
    96.       platform: linux
    97.       inputs:
    98.       - name: src-git
    99.       run:
    100.         #path: src-git/install-ca-certs/centos.sh
    101.         path: /bin/sh
    102.         args:
    103.         - -c
    104.         - |
    105.           src-git/install-ca-certs/centos.sh
    106.           tail /etc/pki/tls/certs/ca-bundle.crt
    107.   - get: debian
    108.   - task: debian-test
    109.     image: debian
    110.     params:
    111.       CA_CERTS: ((ca-certs))
    112.     config:
    113.       platform: linux
    114.       inputs:
    115.       - name: src-git
    116.       run:
    117.         #path: src-git/install-ca-certs/debian.sh
    118.         path: /bin/sh
    119.         args:
    120.         - -c
    121.         - |
    122.           src-git/install-ca-certs/debian.sh
    123.           tail /etc/ssl/certs/ca-certificates.crt

タスク定義の分離

  1. hello-world/say-hello.yml: 個々のタスクはそれぞれ別ファイルに分離でき、fly executeコマンドで個別に実行することができます。
    1. ---
    2. platform: linux
    3.  
    4. image_resource:
    5.   type: docker-image
    6.   source:
    7.     repository: alpine
    8.  
    9. run:
    10.   path: echo
    11.   args: ["Hello, world!"]
  2. パイプラインを設定せずに実行してみます。
    $ cd hello-world
    $ fly -t target e -c say-hello.yml
    executing build 40
    initializing
    running echo Hello, world!
    Hello, world!
    succeeded
  3. hello-world/concourse.yml: 次にパイプラインの中に上記のタスクを定義し、これらのソースをGitにプッシュします。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: https://gitlab.io.example.com/concourse/examples.git
    7.     skip_ssl_verification: true
    8.     branch: master
    9.   #check_every: 1h  # default: 1m
    10.  
    11. jobs:
    12. - name: hello-world
    13.   plan:
    14.   - get: src-git
    15.     params:
    16.       depth: 5
    17.   - task: say-hello
    18.     file: src-git/hello-world/say-hello.yml
  4. パイプラインをサーバにセットし、ポーズ状態を解除の上、ジョブを実行します。
    $ fly -t target sp -p hello-world -c concourse.yml
    ...
    apply configuration? [yN]: y
    pipeline created!
    ...
    
    $ fly -t target up -p hello-world
    unpaused 'hello-world'
    
    $ fly -t target tj -j hello-world/say-hello -w
    started hello-world/say-hello #1
    
    Cloning into '/tmp/build/get'...
    Fetching HEAD
    9a9308f adds a credential sample file.
    initializing
    running echo Hello, world!
    Hello, world!
    succeeded

同一ジョブ内の成果物の受け渡し

  • 同一ジョブ内に定義されたタスクやリソースは inputs や outputs に定義されたディレクトリによってそれぞれの成果物を受け渡すことができます。ただし、以下の点に注意する必要があります。
    • タスクでは、参照するためには必ず明示的に input を、書き出すためには必ず明示的に output を定義する(つまりそれらの名前またはパスでボリュームマウントされる)必要があります。
    • 一方、リソースでは(おそらくリソース自身がその名前でボリュームマウントされるため)暗黙的に先行する(get済みの)リソースとタスクの output を参照できますし、暗黙的に後続のリソースとタスクに(自らのgetした)成果物を渡すことができます。
    • タスク内で同じ名前の input および output オブジェクトを(当然ながらすでに存在する他のリソースと同名の output オブジェクトも)定義することはできません。path 設定を多用することなく、リソース、input および outputの名前は、一意と考えるのがよいでしょう。
    • 当然ながら、inputディレクトリに書き込むことはできません(書き込めているように見えても後続のステップからその内容を参照することはできません)。
  1. image-build00/concourse.yml: これは、image-build00/ci/build.yml でビルドした成果物を含めてコンテナイメージをビルドし、レジストリにプッシュするパイプラインの例です。作業ディレクトリである docker-build をビルドコンテキストとしてイメージをビルドしています。さらにそのイメージをプルしテストを実施しています。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: https://gitlab.io.example.com/concourse/examples.git
    7.     branch: master
    8.     paths:
    9.     - image-build00
    10.     # for the internal CA signed server certificate
    11.     skip_ssl_verification: true
    12.   #check_every: 1h  # default: 1m
    13. - name: docker-reg
    14.   type: docker-image
    15.   source:
    16.     repository: gitlab.io.example.com:5050/concourse/examples/image-build00
    17.     #tag: latest
    18.     username: {{docker-id}}
    19.     password: {{docker-pw}}
    20.     ca_certs:
    21.     - domain: gitlab.io.example.com:5050
    22.       cert: {{docker-reg-ca-cert}}
    23.   check_every: 12h  # default: 1m
    24.  
    25. jobs:
    26. - name: build-img
    27.   plan:
    28.   - get: src-git
    29.     params:
    30.       depth: 5
    31.     trigger: false
    32.   - task: ci-build
    33.     file: src-git/image-build00/ci/build.yml
    34.   - put: docker-reg
    35.     params:
    36.       build: docker-build  # <- src-git/image-build00/ci/build.yml
    37.       #build: src-git/image-build00
    38.       tag: src-git/image-build00/tag
    39.       tag_as_latest: true  # default: false
    40.     get_params:
    41.       #skip_download: true  # default: false
    42.       skip_download: false  # set false for the following ci-test task.
    43.   - task: ci-test
    44.     file: src-git/image-build00/ci/test.yml
    45.     image: docker-reg  # overrides the task's image_reosurce.
    1. image-build00/tag: タグ情報ファイルです。
      1. 0.0.1
    2. image-build00/ci/build.yml: docker-build ディレクトリ以下に成果物(echoによるダミーですが)を書き出すタスクです。
      1. ---
      2. platform: linux
      3.  
      4. image_resource:
      5.   type: docker-image
      6.   source:
      7.     repository: alpine
      8.  
      9. inputs:
      10. - name: src-git
      11.  
      12. outputs:
      13. - name: docker-build
      14.  
      15. run:
      16.   path: /bin/sh
      17.   args:
      18.   - -c
      19.   - |
      20.     cp -R ./src-git/image-build00/*                     ./docker-build
      21.     echo '['`date '+%Y/%m/%d %H:%M:%S'`'] '`uname -a` > ./docker-build/ci-output/build-env.log
      22.     # NG: Even if you write it to the input directory, the following resources and tasks can't read it.
      23.     #echo '['`date '+%Y/%m/%d %H:%M:%S'`'] '`uname -a` > ./src-git/image-build00/ci-output/build-env.log
    3. image-build00/Dockerfile
      1. FROM alpine
      2.  
      3. ADD ci-output/ /var/log/
    4. image-build00/ci/test.yml: 生成されたイメージをテストするタスクです(イメージに含めたログファイルをcatしているだけですが)。
      1. ---
      2. platform: linux
      3.  
      4. image_resource:
      5.   type: docker-image
      6.   source:
      7.     repository: gitlab.io.example.com:5050/concourse/examples/image-build00
      8.     tag: latest
      9.     # workaround!!
      10.     insecure_registries:
      11.     - gitlab.io.example.com:5050
      12.     # NG, setting disable
      13.     #registry_mirror: https://registry.docker.example.com:5000
      14.     #ca_certs:
      15.     #- domain: gitlab.io.example.com:5050
      16.     #  cert: {{docker-reg-ca-cert}}
      17.     #- domain: registry.docker.example.com:5000
      18.     #  cert: {{docker-reg-ca-cert}}
      19.  
      20. inputs:
      21. - name: src-git  # for exstra test resources.
      22.  
      23. run:
      24.   path: /bin/sh
      25.   args:
      26.   - -c
      27.   - |
      28.     date
      29.     cat /var/log/build-env.log
  2. 秘密情報を記述した別ファイル(~/credentials.yml)を用意し、パイプラインを設定の上、該当のジョブを実行します。
    $ fly -t target sp -p image-build00 -c concourse.yml -l ~/credentials.yml
    ...
    $ fly -t target up -p image-build00
    ...
    $ fly -t mycc tj -j image-build00/build-img -w
    started image-build00/build-img #11
    
    Cloning into '/tmp/build/get'...
    Fetching HEAD
    ca421f9 changes job name.
    initializing
    running /bin/sh -c cp -R ./src-git/image-build00/*                     ./docker-build
    echo '['`date '+%Y/%m/%d %H:%M:%S'`'] '`uname -a` > ./docker-build/ci-output/build-env.log
    # NG: Even if you write it to the input directory, the following resources and tasks can't read it.
    #echo '['`date '+%Y/%m/%d %H:%M:%S'`'] '`uname -a` > ./src-git/image-build00/ci-output/build-env.log
    
    Login Succeeded
    Sending build context to Docker daemon  10.24kB
    Step 1/2 : FROM alpine
    latest: Pulling from library/alpine
    43d680a959df: Pulling fs layer
    43d680a959df: Verifying Checksum
    43d680a959df: Download complete
    43d680a959df: Pull complete
    Digest: sha256:b09306f2dfa3c9b626006b2f1ceeeaa6fcbfac6037d18e9d0f1d407260cb0880
    Status: Downloaded newer image for alpine:latest
     ---> 665ffb03bfae
    Step 2/2 : ADD ci-output/ /var/log/
     ---> 7371ddef3844
    Removing intermediate container 973bed71ca90
    Successfully built 7371ddef3844
    Successfully tagged gitlab.io.example.com:5050/concourse/examples/image-build00:0.0.1
    The push refers to a repository [gitlab.io.example.com:5050/concourse/examples/image-build00]
    e3a04eb1856d: Preparing
    404361ced64e: Preparing
    404361ced64e: Layer already exists
    e3a04eb1856d: Pushed
    0.0.1: digest: sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2 size: 735
    The push refers to a repository [gitlab.io.example.com:5050/concourse/examples/image-build00]
    e3a04eb1856d: Preparing
    404361ced64e: Preparing
    e3a04eb1856d: Layer already exists
    404361ced64e: Layer already exists
    latest: digest: sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2 size: 735
    gitlab.io.example.com:5050/concourse/examples/image-build00:0.0.1 tagged as latest
    Login Succeeded
    Pulling gitlab.io.example.com:5050/concourse/examples/image-build00@sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2...
    sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2: Pulling from concourse/examples/image-build00
    43d680a959df: Pulling fs layer
    38d475defdc5: Pulling fs layer
    38d475defdc5: Verifying Checksum
    38d475defdc5: Download complete
    43d680a959df: Download complete
    43d680a959df: Pull complete
    38d475defdc5: Pull complete
    Digest: sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2
    Status: Downloaded newer image for gitlab.io.example.com:5050/concourse/examples/image-build00@sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2
    
    Successfully pulled gitlab.io.example.com:5050/concourse/examples/image-build00@sha256:4985d0c4238e31fe3c997052e07d3813616ac27bd8a9e90428b0ea1c0d36b8f2.
    
    initializing
    running /bin/sh -c date
    cat /var/log/build-env.log
    
    Sat Jun 24 01:56:51 UTC 2017
    [2017/06/24 01:56:26] Linux 8a6d241a-0823-42a9-65e8-56a23e15b114 4.8.0-56-generic #61-Ubuntu SMP Wed Jun 14 08:15:42 UTC 2017 x86_64 Linux
    succeeded
  3. dockerコマンドでも成果物が含まれていることが確認できます。
    $ docker run --rm gitlab.io.example.com:5050/concourse/examples/image-build00:0.0.1 cat /var/log/build-env.log
    [2017/06/24 01:56:26] Linux 8a6d241a-0823-42a9-65e8-56a23e15b114 4.8.0-56-generic #61-Ubuntu SMP Wed Jun 14 08:15:42 UTC 2017 x86_64 Linux

ジョブ間の成果物の受け渡し

  • ジョブ間の成果物の受け渡しにはリソースを利用します。タスクの inputs や outputs は、それが属するジョブの完了とともに揮発しますので、ジョブ間の成果物の受け渡しには利用できません。

semver-resourceによるバージョン番号付け

  • semver-resource(SemanticVersioning?)をして、バージョン番号付けを自動化することができます。
  1. バージョン情報の格納先にGitを利用する場合には、gitドライバを用います。まず、バージョン情報格納用の専用ブランチ(例えば version)を用意します。このブランチは、master等の他のブランチにはマージしません。
    $ git checkout --orphan version
    $ git rm --cached -r .
    $ rm -rf *
    $ rm .gitignore .gitmodules
    $ touch README.md
    $ echo '0.0.0' > tag
    $ git add .
    $ git commit -m "version branch"
    $ git push origin version
  2. 以下のパイプライン例では、最初にソースと現在のバージョン情報を取得してインクリメントした後に、ビルドを実行し、成功時にはバージョンファイルのコミットとソースへのタグ付けを行っています。バージョン情報は、暗黙的に <semver-resourceリソース名>/version というファイルで遣り取りされますので、注意が必要です。note.png一度でインクリメントの後、そのバージョン情報をコミットしてしまう方法(atomic put)もありますが、常に成果物が正常に生成されるとは限りませんので以下のようにトランザクションとして扱うのがよいでしょう。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: git@gitlab.io.example.com/concourse/examples.git
    7.     branch: master
    8.     private_key: ((git-private-key))
    9.   #check_every: 1h  # default: 1m
    10. - name: tag-ver
    11.   type: semver
    12.   source:
    13.     driver: git
    14.     uri: git@gitlab.io.example.com:concourse/examples.git
    15.     branch: version
    16.     file: tag
    17.     private_key: ((git-private-key))
    18.     git_user: ((git-user))
    19.   check_every: 12h
    20. # ...
    21. jobs:
    22. - name: build-artifact
    23.   plan:
    24.   - aggregate:
    25.     - get: src-git
    26.       params:
    27.         depth: 5
    28.       trigger: true
    29.     #- put: tag-ver  # alternative: atomic put
    30.     - get: tag-ver
    31.       params:
    32.         bump: patch  # or major, minor, final
    33.   # execute some tasks ...
    34.   - aggregate:
    35.     - put: tag-ver
    36.       params:
    37.         file: tag-ver/version
    38.     - put: src-git
    39.       params:
    40.         repository: src-git
    41.         tag: tag-ver/version
    42.         only_tag: true
    43.         #annotate: tag-ver/version  # NG!?
    44.         #annotate:   # path to a file containing the annotation message.

((param))プレイスホルダ記述のサポート(fly 3.2.0以上)

  • 新しいプレイスホルダ記述((param))がサポートされました。新たに文字列の連結もサポートされています。note.pngただし、置換変数が定義されていない場合には、エラーは発生せず ((param)) のまま(空文字列にはならない)文字列として残されますので注意が必要です。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: https://gitlab.io.example.com/concourse/examples.git
    7.     branch: master
    8.     # for the internal CA signed server certificate
    9.     skip_ssl_verification: true
    10.   #check_every: 1h  # default: 1m
    11. - name: docker-reg
    12.   type: docker-image
    13.   source:
    14.     repository: gitlab.io.example.com:5050/concourse/examples/image-build00
    15.     #tag: latest
    16.     # ((param)) style: fly >= 3.2.0
    17.     username: ((docker-id))
    18.     password: ((docker-pw))
    19.     registry_mirror: https://((registry-mirror-domain))
    20.     ca_certs:
    21.     - domain: gitlab.io.example.com:5050
    22.       cert: ((docker-reg-ca-cert))
    23.     - domain: ((registry-mirror-domain))
    24.       cert: ((docker-reg-ca-cert))
    25.   check_every: 12h  # default: 1m
    26. - name: alpine-latest
    27.   type: docker-image
    28.   source:
    29.     repository: alpine
    30.     registry_mirror: https://((registry-mirror-domain))
    31.     ca_certs:
    32.     - domain: ((registry-mirror-domain))
    33.       cert: ((docker-reg-ca-cert))
    34.  
    35. jobs:
    36. - name: build-img
    37.   plan:
    38.   - get: src-git
    39.     params:
    40.       depth: 5
    41.     trigger: false
    42.   - get: alpine-latest
    43.   - task: ci-build
    44.     file: src-git/image-build00/ci/build.yml
    45.     # for testing typically.
    46.     image: alpine-latest  # overrides the task's image_reosurce.
    47.   - put: docker-reg
    48.     params:
    49.       build: docker-build  # <- src-git/image-build00/ci/build.yml
    50.       #build: src-git/image-build00
    51.       tag: src-git/image-build00/tag
    52.       tag_as_latest: true  # default: false
    53.     get_params:
    54.       #skip_download: true  # default: false
    55.       skip_download: false  # set false for the following ci-test task.
    56.   - task: ci-test
    57.     file: src-git/image-build00/ci/test.yml
    58.     image: docker-reg  # overrides the task's image_reosurce.

ビルドの高速化

並列化

  • 実行の順序が他のステップに依存していないステップは、aggregate ステップでまとめると実行を並列化することができます。
  • aggregate ステップの中でも実行順序を保証したいステップの束がある場合には、do ステップでまとめると実現できます。
    1. # ...
    2. jobs:
    3. - name: update-system-tests
    4.   plan:
    5.   - get: src-git  # (1)
    6.     params:
    7.       depth: 5
    8.   - aggregate:    # (2)
    9.     - do:         # (2.1)
    10.       - get: alpine        # (2.1.1)
    11.       - task: alpine-test  # (2.1.2)
    12.         image: alpine
    13.         config:
    14.           platform: linux
    15.           inputs:
    16.           - name: src-git
    17.           run:
    18.             path: src-git/update-system/alpine.sh
    19.     - do:         # (2.1)
    20.       - get: centos        # (2.1.1)
    21.       - task: centos-test  # (2.1.2)
    22.         image: centos
    23.         config:
    24.           platform: linux
    25.           inputs:
    26.           - name: src-git
    27.           run:
    28.             path: src-git/update-system/centos.sh
    29. # ...

ソース変更履歴の取得を最小限に

  • 自動ビルドに必要なソースコードはほぼ最新のもののみで十分であり、変更履歴を取得する理由はあまりありません。したがって、gitリソースのgetパラメータでは depth を適切に設定し履歴の取得を抑止するとよいでしょう。特に更新が頻繁なリポジトリでは有効です。
  • ただし、depthを 1 に設定した場合、コミットにスキップラベル([ci skip][skip ci])を使用した直後に(最新のソースはスキップ対象なので)ビルド対象ソースを取得できなくなるという問題に遭遇することになります。スキップラベルを常用することは良い習慣ではありませんが、場合によっては便利な機能ですのでdepthは 5 くらいがよいでしょう。
    1. # ...
    2. jobs:
    3. - name: build-img
    4.   plan:
    5.   - get: src-git
    6.     params:
    7.       depth: 5
    8.     trigger: true
    9. # ...

外部アクセスの効率化

  • 当然ながらCIでは同じ処理が繰り返し行われます。もし各ステップで外部アクセスが必要な場合にはプロキシサーバを経由するように設定すると、不要な外部アクセスが削減でき、ビルド処理が高速化します。
  • 各ステップでは、params オプションで環境変数をセットできますので、一例としては HTTP_PROXY(またはhttp_proxy)を設定するとよいでしょう。
    • 以下の例では、bundle や rake コマンド実行時にプロキシが有効になります。
      1. jobs:
      2. - name: build-cookbook
      3.   plan:
      4.   - get: src-git
      5.     params:
      6.       depth: 5
      7.     trigger: true
      8.   - get: chefdk-cache
      9.   - task: ci-build
      10.     image: chefdk-cache
      11.     params:
      12.       http_proxy: ((http-proxy))  # e.g. http://proxy.example.com:3128
      13.     config:
      14.       platform: linux
      15.       inputs:
      16.       - name: src-git
      17.       run:
      18.         path: /bin/bash
      19.         args:
      20.         - -c
      21.         - |
      22.           cd ./src-git/cookbooks/((cookbook-name))
      23.           bundle install
      24.           rake

イメージ取得の効率化

  • Workerでは実行に必要なイメージはキャッシュされますのでそのままでもある程度は効率的ですが、さらに組織内部のミラーレジストリをパイプライン定義に設定することによりイメージ提供元へのトラフィックを大幅に削減することができます。
  • info.pngミラーレジストリの構築については、Dockerのレジストリの項をご参照ください。

docker-image-resourceにミラーレジストリを設定

  1. 以下の例では docker-image-resource で内部的に起動されるDockerデーモンにミラーレジストリが設定されますので、(ミラーに設定されたDockerHub?の)イメージの取得時にはミラーを経由します。
    1. ---
    2. resources:
    3. - name: docker-reg
    4.   type: docker-image
    5.   source:
    6.     repository: gitlab.io.example.com:5050/concourse/examples/image-build00
    7.     #tag: latest
    8.     username: {{docker-id}}
    9.     password: {{docker-pw}}
    10.     registry_mirror: {{registry-mirror}}  # e.g. https://registry.docker.example.com:5000
    11.     ca_certs:
    12.     - domain: gitlab.io.example.com:5050
    13.       cert: {{docker-reg-ca-cert}}
    14.     - domain: {{registry-mirror-domain}}  # e.g. registry.docker.example.com:5000
    15.       cert: {{docker-reg-ca-cert}}
    16.   check_every: 12h  # default: 1m

タスクのimage_resourceをimage設定で上書き

  • タスク定義の image_resource ではミラーレジストリが設定できないようですので、ややトリッキーですがタスクの image でミラーレジストリが設定された docker-image-resource オブジェクトをセットします。タスク定義が別ファイルに分離されている場合には、image_resource の設定内容が image のそれでオーバーライドされる動作となります。
  1. 以下の例では、イメージサイズのかなり大きな chef/chefdk をミラーレジストリ経由で取得するようにしています。
    1. ---
    2. resources:
    3. - name: src-git
    4.   type: git
    5.   source:
    6.     uri: git://git.osdn.net/gitroot/metasearch/grid-chef-repo.git
    7.     branch: master
    8.   #check_every: 1h  # default: 1m
    9. - name: chefdk-cache
    10.   type: docker-image
    11.   source:
    12.     repository: chef/chefdk
    13.     tag: 0.17.17
    14.     registry_mirror: {{registry-mirror}}  # e.g. https://registry.docker.example.com:5000
    15.     ca_certs:
    16.     - domain: {{registry-mirror-domain}}  # e.g. registry.docker.example.com:5000
    17.       cert: {{docker-reg-ca-cert}}
    18.   check_every: 12h  # default: 1m
    19.  
    20. jobs:
    21. - name: build-cookbook
    22.   plan:
    23.   - get: src-git
    24.     params:
    25.       depth: 5
    26.     trigger: false
    27.   - get: chefdk-cache
    28.   - task: ci-build
    29.     image: chefdk-cache
    30.     config:
    31.       platform: linux
    32.  
    33.       #image_resource:
    34.       #  type: docker-image
    35.       #  source:
    36.       #    repository: chef/chefdk
    37.       #    tag: 0.17.17
    38.           # NG, setting disable
    39.           #registry_mirror: {{registry-mirror}}
    40.           #ca_certs:
    41.           #- domain: {{registry-mirror-domain}}
    42.           #  cert: {{docker-reg-ca-cert}}
    43.  
    44.       inputs:
    45.       - name: src-git
    46.  
    47.       run:
    48.         #dir: ./src-git/cookbooks/concourse-ci
    49.         #path: rake
    50.         path: /bin/bash
    51.         args:
    52.         - -c
    53.         - |
    54.           cd ./src-git/cookbooks/concourse-ci
    55.           bundle install
    56.           rake

既知の問題

git-resource

annotateオプション不自然仕様(3.8.0以前)

  • annotateオプションを指定するとファイルパスの設定によりステップが失敗します。
    1. サンプルタスク(抜粋)
      1.     - put: src-git
      2.       params:
      3.         repository: src-git
      4.         tag: tag-ver/version  # OK
      5.         only_tag: true
      6.         annotate: tag-ver/version  # NG?!
    2. エラーメッセージ
      1. fatal: could not open or read 'tag-ver/version': No such file or directory
  • info.pngFix annotate file path. #131
    1. バグではなく、ソースのルートからのパスを設定することを想定した仕様とのことです。特にドキュメントに明示されていないので、やや「驚き最小の法則」に抵触するかもしれません。パスには違いないので、トリッキーな設定になりますがソースツリー以外のファイルも指定できます。
      1.     - put: src-git
      2.       params:
      3.         repository: src-git
      4.         tag: tag-ver/version  # OK
      5.         only_tag: true
      6.         annotate: annotate.txt              # OK: expected.
      7.         #annotate: src-git/annotate.txt     # NG!
      8.         #annotate: ../src-git/annotate.txt  # OK
      9.         #annotate: tag-ver/version          # NG!
      10.         #annotate: ../tag-ver/version       # OK
  • info.pngFix annotate file path【追記】やはり不自然な仕様ということでいつの間にか修正されていました。最新版(おそらく3.9.0以降)では以下の設定で動作します。
    1. サンプルタスク(抜粋)
      1.     - put: src-git
      2.       params:
      3.         repository: src-git
      4.         tag: tag-ver/version  # OK
      5.         only_tag: true
      6.         annotate: tag-ver/version  # OK!!

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-04-28 (土) 12:36:51 (83d)