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

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

　CI/CDの実践にあたって、今や標準的なテクノロジーとなっている「Docker」ベースのコンテナ技術。しかし、そのコンテナイメージを開発、テスト、ステージング、本番といった各ステップへ安全かつ確実にプロモートできる仕組みをいかに構築するかというのは担当者にとって悩ましい問題となっているのではないだろうか。JFrogでHead of Developer Advocacyを務めるBaruch Sadogursky氏がコンテナイメージ・プロモーションにおける課題や解決に向けたベストプラクティスとともに、その実践を効率的に行うためのツールを紹介した。

• 講演資料：Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法

JFrog　Head of Developer Advocacy　Baruch Sadogursky氏

「Dockerは気に入っているけど、信用していない」人が多い理由

　Sadogursky氏は冒頭、聴衆に対して「Dockerを知っているか？」と問いかけ、CI/CD環境の構築にあたり「Docker」が極めてポピュラーかつ標準的なツールとなっていることを改めて強調した。

　「今、多くの方が手を挙げたことからも分かるとおり、今やDockerはCI/CDにおいて、なくてはならない技術のひとつになっている。しかし『Dockerについて知っている』人ほど、同時に『Dockerをあまり信用していない』と言う傾向がある。それはなぜなのだろうか」（Sadogursky氏）

　Dockerには「docker buildという、とてもパワフルなコマンドがある」とSadogursky氏は言う。このコマンドを利用することで、DockerはDockerfileを参照し、イメージをビルドする。そのイメージが必要な要件を満たせば次のステップへ移り、そのステップで再度docker buildにより新しいイメージをビルドする、というようなCI/CDのパイプラインを構築しているケースも多いのではないだろうか。

「docker build」に依存したCI/CDのパイプライン構築はパワフルだが不都合も生みがち

　しかし、Sadogursky氏は「docker buildはパワフルで簡単であるが故に、手を抜くと面倒な状況が発生する」と指摘した。例えば、DockerfileにおいてOSやミドルウェア、言語環境などのバージョンを明示的に指定していなければ、Dockerは常に「最新」のバージョンを利用してイメージを作成しようとする。Dockerfileの内容は一緒であっても、テスト環境と本番環境とで内容の違うイメージがビルドされてしまう可能性が生まれてしまうわけだ。原則としては一度テストをパスしたら、その時と完全に同じイメージをベースにプロモートを進めたい。そうしなければバージョン依存による予想外の不具合などが発生した場合の検証に膨大な手間がかかるためだ。

　この問題を避けるための方法はいくつか考えられる。まずはDockerfileで各コンポーネントのバージョン番号を明示的に指定するというやり方だ。しかし、この方法では十分ではないとSadogursky氏は言う。OSやミドルウェアなどには日々、セキュリティパッチが当てられており、表記上のメジャーバージョン、マイナーバージョンが同じでも実際の内容が異なっているケースが多くあるためだ。

　次に考えられるのは利用するソフトウェアのチェックサムを利用するという方法だ。チェックサムは符号化された文字列による誤り検出手法として広く用いられており、チェックサムが同じであれば内容も基本的に同一であると考えられる。しかし、Sadogursky氏は「この方法はバージョン番号を指定するよりもかなりいいが、それでも完璧ではない」とする。まず、長いランダムな文字列として表現されるチェックサムでのバージョン指定はユーザーにとって非常に分かりにくいという点。合わせて、OSのように手元のDockerfile内でチェックサムを明示してインストールできるコンポーネントであればいいが、シェルコマンドからインストールするような言語やミドルウェアについては、そこからさらに依存関係のある多数のモジュールが枝分かれしているため「まったく状態が同じバージョン」を指定することが現実的にはできないという問題がある。Dockerfile内で外部のシェルコマンドファイルなどを呼び出してビルドに利用している場合にも、そのすべてをトレースし、イメージの同一性を維持していくのは極めて手間の掛かる作業になる。

　「Dockerが外部のさまざまなテクノロジーをコンテナ化する仕組みである以上、マイクロサービスを迅速に開発、展開するにあたってはイメージ内部の依存関係をしっかりと可視化し、コントロールしながらプロモートしていく必要がある。Dockerfileだけに頼った仕組みを不用意に使っていると、そこに問題が発生しやすくなる。Dockerを好んで使っている人でも『Dockerは信用できない』と感じてしまう理由はそこにある」（Sadogursky氏）