Kubernetes入門(32) インフラやセキュリティ関連も。多様化するKubernetesネイティブな開発ツールに求められる機能

システム開発において、開発者の責務は変化し、守備範囲も広くなってきています。これに伴って開発者が利用するツールに求められる機能に関しても、変化や広がりが見られます。今回は、この辺りについてご紹介しましょう。

「開発者が実施すべき責務」の広がり

早速ですが、従来のエンジニアとKubernetesエンジニアにはどういったギャップがあるかを会話形式で見てみましょう。

従来型エンジニア：開発と言えば、Eclipseを使ってJava開発だね。MavenやGradleは使っているけど、基盤周りはインフラエンジニアに任せているよ。
Kubernetesネイティブエンジニア：業務開発者もコンテナ定義ファイルやk8sのマニフェストを開発者が書く必要があります。Build/Ship/Runそれぞれのフェーズで必要な機能が異なりますね。
従来型エンジニア：セキュリティ観点の開発ガイドラインによるセキュリティを確保するのには限界があるから、セキュリティ要件を担保するのは結局システムテスト工程にならざるを得ないな。
Kubernetesネイティブエンジニア：最近はシフトレフトがやりやすくなってきています。実装する段階からツール活用によるセキュリティチェックが可能です。

このように、開発者がインフラ周りの実装を意識したり、セキュリティに関するツールを活用したりと、従来の開発スタイルが変化してきています。

従来の開発スタイルとKubernetesネイティブな開発スタイルの比較

前節の内容について、従来の開発スタイルとの比較の観点からもう少し踏み込んで理解していきましょう。

まず、従来の開発スタイルはどのようなものだったでしょうか? EclipseでJavaのコーディングをし、Mavenのビルドスクリプトを書き、ホストOS(ローカル)のTomcatやPostgreSQL環境にEclipse経由でデプロイしてデバッグ。10～15年前のWeb3層のオンプレミスの開発環境はこのようなスタイルでした。

一方、Kubernetesネイティブな開発スタイルになると、上記に加えてDockerfileやマニフェストなど、ソフトウエアエンジニアがカバーすべき範囲も広くなります。実際、IaC(Infrastructure as Code)の考え方が進展しつつあり、従来あまりバージョン管理されることが多くなかったインフラの定義についても、gitリポジトリで管理されることが当たり前になってきました。これにより、開発ツールがカバーすべき範囲や責務も広がってきます。

分類	コーディング対象	動作環境	求められるスキルレイヤ(≒ツールがカバーすべきレイヤ)
従来	Javaなどアプリケーション中心(Maven含む)	Tomcat/PostgreSQL	アプリケーションレイヤ
Kubernetesネイティブ	上記に加えてDockerfileやマニフェスト	上記に加えてDocker/k8s	上記に加えて一部インフラレイヤ

そんな中、KustomizeやSkaffold、Telepresence、TrivyといったKubernetesネイティブな開発を支える開発支援ツールが次々と登場してきました。

ただ、「どういった機能をどのツールで賄えば良いかわからない」という方や、「これまでのIDE/開発環境で十分」と高をくくっている方もいらっしゃると思います。セキュリティの視点から言っても、イメージスキャンのようなツールで実装工程の比較的早い段階から検知できることを知らずに、セキュリティリスクを放置してしまっている方もいらっしゃるかもしれません。

そこで今回は、Kubernetesネイティブ開発に求められる開発ツールの機能を体系的に紹介します。ご自身にとって快適な新しい開発環境を作るための参考にしていただければ幸いです。

Kubernetesネイティブな開発ツールに求められる機能

前節までで、開発者の「責務」をご理解いただきました。本節は開発ツールに求められる「機能」にフォーカスを当てていきます。

Kubernetesネイティブな開発ツールに求められる機能はいったい何があるのでしょうか? 開発ツールと言えば、まずはエディタやデバッガなどが挙げられます。加えて、セキュリティの観点の機能として、イメージに含まれる脆弱なソフトウエアのスキャンやマニフェストへの秘匿情報の埋め込みチェックなど、さまざまなものが考えられます。

では、こういった機能を何の軸で理解していけば良いのでしょうか?

ここでは、DevSecOpsの考えに則って以下の構成で紹介します^※。