Kubernetes Operator：リリースプロセスを自動化する

Snykは、お客様がセキュリティをCI/CDパイプラインに組み込めるよう支援しているため、自動化について考える機会が多くあります。自社ソフトウェアをリリースする際にも、テストとリリースに関するベストプラクティスを常に取り入れるよう努めています。

このブログでは、Kubernetes Operatorのリリースプロセスについて説明し、複数のリポジトリへのリリースデプロイを自動化した方法をご紹介します。

Kubernetes Operatorとは？

Operatorとは、「...Kubernetesアプリケーションをパッケージ化、デプロイ、管理するための方法..」です。Operatorは基本的に、アプリケーションのライフサイクルに関する操作をコードにカプセル化し、KubernetesのネイティブAPIを使って制御できるようにします。

Kubernetes Operatorが重要な理由

Operatorパターンを使うと、Kubernetes APIを利用して、アプリケーションの実行後も制御できます。アプリケーションに単なる起動や停止以上の処理が必要な場合も、他のKubernetesリソースを管理するときと同じ宣言型の方法で、実行中に制御できます。

アプリケーションのリリース自動化とは？

ユーザーがソフトウェアを利用できるオンラインカタログが増えるにつれ、リリースしたソフトウェアを配布するプロセスは非常に複雑になることがあります。成果物をさまざまなリポジトリに配布するために多くの手順を踏む必要があったり、アプリケーションをさまざまな方法で利用できるよう、異なる種類のメタデータを提供したりする場合があります。各リリースをエラーなく配布し、新しいバージョンを公開後すぐにユーザーが利用できるようにするには、これらのプロセスを自動化することが不可欠です。

詳しく見ていきましょう

数か月前、コンテナスキャンを担当するチームが、Snyk ControllerをネイティブのKubernetesクラスターとOpenShiftクラスターの両方に簡単にデプロイできるようにするOperator、Snyk Operatorをリリースしました。

Snyk Controllerは、ユーザーのクラスターにデプロイされ、クラスター内で実行中のコンテナイメージをスキャンするSnykのアプリケーションです。この優れたツールについてはこちら、イメージやアプリケーションの脆弱性を検出する方法についてはこちらをご覧ください。

Kubernetes向けのOperatorを構築する方法はさまざまです。最も一般的な方法の1つが、CoreOSで生まれ、現在はCNCFプロジェクトとなっているOperator Frameworkです。Operator開発用のSDKを提供するだけでなく、コミュニティが開発したOperatorのリポジトリも提供しています。

Snyk Operatorはこのフレームワークを使って構築されており、リリースのたびにアップストリームのリポジトリに配布しています。Operatorの新しいバージョンをリリースする際には、多くの手順を完了する必要があり、手作業ではミスが発生しやすくなります。

まず、Snyk Controllerのリリースプロセスと、その中にOperatorのビルドをどのように組み込むかを確認しましょう。

コントリビューターの誰かがSnyk Controllerリポジトリへのプルリクエストをマージすると、継続的インテグレーションと継続的デプロイのパイプラインが開始されます。Operatorとそのイメージをビルドし、単体テスト、システムテスト、すべての統合テストを実行して、さまざまな環境でOperatorをテストします。

テストが必要な環境は多岐にわたり、OpenShiftのさまざまなバージョンや、アップストリームKubernetesの異なるバージョンが含まれます。これらすべての環境で、Operator Frameworkの一部であるOperator Lifecycle Managerを使用してテストします。これはKubernetesを拡張し、クラスター内のOperatorとその依存関係を宣言型の方法でインストール、管理、アップグレードできるようにするものです。

Snyk Operatorのリリースをテストしたら、最終版を配布する必要があります。現在、Snyk OperatorはOperator Hubでリリースしており、Operator Lifecycle Managerを実行する任意のKubernetesクラスターにインストールできます。また、OpenShiftカタログにもリリースしています。

このリリースプロセスでは、2つの別々のプルリクエストが必要です。手作業で行うと大きな負担になります。1つはSnyk Operatorをcommunity-operatorsフォルダーに追加するもの、もう1つはupstream-community-operatorsフォルダーに追加するものです。前者によってSnyk OperatorがOperatorHub.ioでリリースされ、後者によってOpenShiftカタログでリリースされます。

こうした手順の負担をなくすため、両方のリポジトリへのリリースプロセスを完全に自動化し、CircleCIパイプラインですべてをスクリプト化しました。

まず、必要なファイルをすべてsnyk-operatorフォルダーにコピーし、アプリケーションのバージョンを最新のものに置き換えます。operator-sdkツールをダウンロードして、Snyk Operatorのイメージをビルドします。完了したら、イメージをDocker Hubの公開レジストリsにプッシュします。

出典：GitHub

このイメージを使ってパイプラインで統合テストを実行し、OpenShiftのバージョン3.xおよび4.xのクラスターと、OLMを備えたKubernetesクラスターで正常に動作するものをリリースできるか確認します。ここでは、統合テストを実行するための工夫をしています。OperatorのイメージをQuayレジストリにプッシュし、operator-source.yamlを作成してから、install.yamlを適用してクラスターにインストールします。

ここでは、ユーザーがUIからOperatorをインストールするときと同じプロセスを再現することを目指しています。ブラックボックスとして捉え、ユーザーがUIで「インストール」をクリックしたときにOpenShiftが実行する手順に沿って進めます。

出典：GitHub

出典：GitHub

出典：GitHub

最後に、すべてのテストに合格したら、Snyk Operatorのリリースに進みます。そのためには追加のメタデータを作成する必要があります。これにより、ClusterServiceVersionとCustomerResource Definitionsが追加され、Operator HubのSnyk Controllerページに情報が表示され、Operator Lifecycle Managerとの連携が可能になります。OLMを使うと、ユーザーはOperatorをサブスクライブできます。これにより、インストールと更新を1つの手順にまとめられます。

このメタデータは頻繁に変更されないため、テンプレートを使ってバージョンを最新のSnyk Operatorのバージョンに合わせて変更するだけで済みます。

出典：GitHub

これらの手順がすべて完了したら、最後にコミットを作成します。1つは新しいOperatorメタデータをcommunity-operatorsフォルダーに追加するもの、もう1つはupstream-community-operators.フォルダーに追加するものです。それぞれのコミットについて、指定されたメッセージを記載したプルリクエストをcommunity operatorsリポジトリに作成します。

出典：GitHub

自動作成されたプルリクエストの例はこちらとこちらでご覧いただけます。

プルリクエストが作成されると、OperatorHubとOpenShiftで自動テストが実行され、最終的には各リポジトリのメンテナーが新しいバージョンをマージします。

まとめ

Operatorのリリースプロセスを完全に自動化することで、エンジニアリングチームの時間とリソースを大幅に節約し、ソフトウェアの新しいバージョンをできるだけ迅速かつ効率的に提供し続けることができます。

Snyk ControllerはSnykのスキャン機能をKubernetesクラスターに統合し、実行中のワークロードをインポートしてテストできるようにします。また、関連するイメージや設定に含まれる脆弱性を特定し、ワークロードのセキュリティを低下させる要因を検出できます。詳しくはこちらをご覧ください。無料アカウントに登録して、Snykをぜひご利用ください。