Kubernetesを前提としたCI/CDパイプラインの具体例と、本番運用に必要なものコンテナベースのCI/CD本番事例大解剖(3)(1/2 ページ)

Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートテクノロジーズの事例を基に解説する連載。今回は、インフラエンジニア視点からKubernetesを前提としたCI/CDの具体例について解説します。

» 2019年09月03日 05時00分 公開
[宮地克弥リクルートテクノロジーズ]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 本連載「コンテナベースのCI/CD本番事例大解剖」では、リクルートテクノロジーズが取り組んだ事例を基に、Kubernetes、コンテナ技術を活用したCI/CD(継続的インテグレーション/継続的デリバリー)基盤におけるサービス開発について解説します。第1~3回では、「Kubernetes、Dockerをコア技術に据えてサービスを構築した際に、開発、保守運用においてどのような影響があったのか」について、インフラアーキテクト、アプリエンジニア、インフラエンジニアそれぞれの視点から紹介します。

 連載第2回の前回はアプリ開発者の視点から紹介しました。今回は、インフラエンジニア視点から、Kubernetesを前提としたCI/CDの具体例について解説します。

Kubernetesを前提とした開発について

 Kubernetesを利用する上で最も重要な準備の一つとして、CI/CD環境があります。Kubernetesにアプリケーションをデプロイするには、最低でも下記の手順を踏む必要があります。

  1. Dockerイメージのビルド
  2. 「Deployment」「ConfigMap」などのmanifestの組み立て(コンテナのimage tagや、「dev」「stg」「prod」など各環境に向けた変更)
  3. 各環境に合わせたconfigのデプロイ

 これらを毎回手動で行うのは、現実的ではありません。そこで、これらの作業を自動化するために、CD環境が必要になります。

 今回のプロジェクトではCI/CDツールとして「Concourse CI」を選択しました。選定した理由、他ツールとの比較に関しては連載第1回で解説しています。

Concourse CI

 Concourse CIはPivotal社によるオープンソースソフトウェア(OSS)のCI/CDツールです。yamlを使ってパイプラインを記述し、コンテナベースで各タスクが実行されます。

 基本的な機能に関しては、こちらのチュートリアルにまとまっているため、本連載では割愛します。ここでは、Kubernetes(コンテナ環境)で利用する上で最低限必要なCI/CDのフローと、連載第2回の「パイプラインの高速化」の項で解説したパイプラインを組むための具体的な方法を紹介します。

パイプラインの具体例

 上記のパイプライン模式図を基にConcourse CI上へデプロイすると、下記サンプルのように表示されます。

パイプラインのサンプル

  1. groups:
  2. - name: test
  3. jobs:
  4. - build-image
  5. - unit-test
  6. - lint
  7. - success-notify
  8. resource_types:
  9. - name: kubernetes
  10. type: docker-image
  11. source:
  12. repository: zlabjp/kubernetes-resource
  13. tag: "1.12"
  14. - name: slack-notification
  15. type: docker-image
  16. source:
  17. repository: cfcommunity/slack-notification-resource
  18. tag: latest
  19. - name: slack-alert
  20. type: docker-image
  21. source:
  22. repository: arbourd/concourse-slack-alert-resource
  23. - name: pull-request
  24. type: docker-image
  25. source:
  26. repository: teliaoss/github-pr-resource
  27. tag: latest
  28. resources:
  29. - name: repository
  30. type: pull-request
  31. source:
  32. repository: ((repository))
  33. access_token: ((access-token))
  34. - name: app-docker-image-base
  35. type: docker-image
  36. source:
  37. repository: asia.gcr.io/example-project/app/base
  38. username: _json_key
  39. password: ((gcp-service-account))
  40. - name: app-docker-image
  41. type: docker-image
  42. source:
  43. repository: asia.gcr.io/example-project/app
  44. username: _json_key
  45. password: ((gcp-service-account))
  46. - name: notify
  47. type: slack-alert
  48. source:
  49. url: ((slack-webhook))
  50. - name: deploy-notify
  51. type: slack-notification
  52. source:
  53. url: ((slack-webhook))
  54. jobs:
  55. - name: build-image
  56. plan:
  57. - get: repository
  58. trigger: true
  59. version: every
  60. - put: app-docker-image-base
  61. params:
  62. cache_from:
  63. - api-docker-image-base
  64. cache: true
  65. additional_tags: repository/.git/ORIG_HEAD
  66. build: repository
  67. dockerfile: repository/app/Dockerfile
  68. target_name: base
  69. on_failure:
  70. ## 失敗時の通知
  71. - put: app-docker-image
  72. get_params:
  73. skip_download: true
  74. params:
  75. cache_from:
  76. - app-docker-image-base
  77. cache: true
  78. additional_tags: repository/.git/ORIG_HEAD
  79. build: repository
  80. dockerfile: repository/app/Dockerfile
  81. target_name: app
  82. on_failure:
  83. ## 失敗時の通知
  84. - name: unit-test
  85. plan:
  86. - aggregate:
  87. - get: repository
  88. trigger: true
  89. passed:
  90. - build-image
  91. - get: app-docker-image
  92. - task: unit-test
  93. image: app-docker-image
  94. # unit-testの実行
  95. on_failure:
  96. ## 失敗時の通知
  97. on_success:
  98. ## 成功時の通知
  99. - name: lint
  100. plan:
  101. - aggregate:
  102. - get: repository
  103. trigger: true
  104. passed:
  105. - build-image
  106. - get: app-docker-image
  107. - task: lint
  108. image: app-docker-image
  109. ## lintの実行
  110. on_failure:
  111. ## 失敗時の通知
  112. on_success:
  113. ## 成功時の通知
  114. - name: success-notify
  115. plan:
  116. - get: repository
  117. trigger: true
  118. passed:
  119. - lint
  120. - unit-test
  121. - task: notify-msg
  122. ## 成功時の通知

パイプラインの構成

 Concourse CIのパイプラインは大きく以下の3つの定義に分かれています。

  • resource_types:
    パイプラインで利用したいresourceを定義する
  • resources:
    ジョブで利用するために、resourceの詳細を定義する
  • jobs:
    実行されるジョブを定義する

 このパイプライン全体の流れの概略は、下記のようになります。

  1. 各種resource_typesの定義
  2. resourcesの設定
  3. 各ジョブの実行
    1. アプリケーションのイメージのビルド
    2. unit-testの実行、lintの実行
    3. 成功の通知
       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

Coding Edge 鬮ォ�ェ陋滂ソス�ス�コ闕オ譁溷クキ�ケ譎「�ス�ウ驛「�ァ�ス�ュ驛「譎「�ス�ウ驛「�ァ�ス�ー

髫エ蟷「�ス�ャ髫エ魃会スス�・髫エ蟶キ�」�ッ闖ォ�」

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。