CodeZine(コードジン)

特集ページ一覧

コンテナベースの開発をセキュアにパイプライン化するにはどうすべき? そのベストプラクティスを学ぶ【デブサミ2020】

【13-B-5】Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/03/10 12:00

目次

「鉄板のパイプライン」を作るために考えるべきこと

 品質保証の観点で言えば、テストをパスしてステージングに進み、そして最終的に本番環境へとデプロイされるイメージは完全に同一であってほしい。それを実現するためにはプロモートのパイプラインにおいて、イメージをフィルタリングする「ゲート」を設け、各ステップをパスしていないイメージは次のステップに進ませない仕組みを用意しておく必要がある。

 その手段としてはDockerfile内での「LABEL」コマンドを用いたイメージへのタグ付けや「Docker Hub Repositories」の利用などが考えられるという。LABELによるタグ付けは運用さえ確実に行われれば、かなり有効な方法と言える。しかし、LABELによる属性はあくまで単なるテキストであり、それによるチェックの仕組みだけで十分かどうかは、また別の問題になる。

 一方でDocker Hub Repositoriesを利用した場合はパーミッションベースでイメージをコントロールでき、より信頼性は向上する。しかしここでも、ひとつの問題が発生する。Docker Hub Repositoriesでは、Gitのプロジェクトに対応する形でレジストリを管理している。つまり、そのままの状態では「開発」「テスト」「ステージング」「プロダクション」といった品質管理のステップに対応したイメージコントロールはできないのだ。ステップごとに別にプロジェクトにする方法は考えられるが、その場合、パイプライン全体を見渡したイメージ管理が煩雑になるほか、プロモート自体にも手間が掛かってしまう。

 では、同じホスト上で各ステップに対応した複数のレジストリを同時に管理するためにはどうしたらよいのだろう。Sadogursky氏は「少しチート的なやり方だが」と前置きした上で「Virtual Hosts/Ports」の機能を使い、アクセスするポートによって、各ステップを振り分けるというやり方を紹介した。docker tagにおいてはリポジトリのプッシュにあたって、プッシュ先のホストをポート込みで指定することができる。このポート名をステップごとに変えることで同一ホスト上に複数のレジストリを持たせ、仮想的な論理構造を実現するというわけだ。

Virtual Hosts/Portsを使って単一のホスト上で複数のレジストリによる論理構造をつくる
Virtual Hosts/Portsを使って単一のホスト上で複数のレジストリによる論理構造をつくる

 この方法は複数のレジストリを1つのホスト上で管理し、ステップごとに利用可能なイメージをコントロールするための最もスマートなやり方になり得るが、実際にやろうとすると「ステップごとにDockerのレジストリをプルして、タグを変更してプッシュする」という作業が必要になるため、やはり手間は膨大になる。つまり、その運用を自動化するための仕組みを同時に取り入れる必要がある。

 Sadogursky氏が所属する「JFrog」ではCI/CDの現場において、この手法を使ったパイプラインを容易に実現するための「JFrog Container Registry」と呼ばれるツールを提供している。このツールは、オンプレミスでの利用は無料。クラウド版も、制限内(2GB/月以下のストレージと5GB/月以下のデータ転送量)であれば、登録から1年間は無料で利用できるという。

 このツールを使うとエンドユーザーはツールが用意した仮想的なプロキシを経由してDocker Hub RepositoriesやGitHubなどにアクセスする形になる。同一ホスト上に複数設置したレジストリへのアクセスはJFrog Container Registryによって振り分けられるため、ユーザー側からは特に意識する必要がなくなる。「Virtual Hosts/Ports」を活用したパイプラインの構築にあたって、必須の機能を提供するという。

 JFrog Container Registryでは同時にコンテナイメージ内部の依存関係の管理も可能になる。パイプライン上のDockerイメージにカスタムメタデータを付加し、そのイメージがどの時点の環境に基づいているかを可視化することができる。自分たちが作る成果物に関連して各モジュールにどのような依存関係があるのかをしっかり把握、管理した上でコンテナを扱うことができるようになるという。

 「各モジュールのアップデートには脆弱性対応など、相応の理由がある。しかし、開発者としては自分が必要なタイミングで、それを適用した環境に移りたいと考えるはずだ。JFrog Container Registryを利用すると意図しない最新版によるイメージのビルドを避け、その適用を自らコントロールできるようになる」(Sadogursky氏)

 Sadogursky氏は「鉄板のパイプライン」を構築するためのポイントとして「環境ごとにレジストリを分ける」「すべてのイメージに容易にアクセスできる環境にしておく」「プロモーションを迅速に行えるようにしておく」「『最新版』のメリットを、その内容を理解した上で享受できる環境を作る」という4項目を挙げ、セッションを締めくくった。

お問い合わせ

 JFrog Japan



  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2020】セッションレポート

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5