OpenShift PipelineでSonarQubeによるソースコードスキャンのタスクを追加する

はじめに

• 本記事では以下の流れを説明します。
  • 既にOpenShiftのクラスタ内にDeployされているSonarQubeと、アプリケーションのソースコードが格納されているGitHubのリポジトリを接続する
  • Soner-Scanタスク（SonerQubeによるソースコードスキャンを行うタスク）をTekton (OpenShift Pipelines)に追加する

この記事を書いた理由

• 何気に今からやろうとしている事を一から解説してくれている情報が無かったので、今後同じことをやる人の参考にしようと思ったから。
• あと自分の備忘録

事前準備①：

• OpenShift上に既存のPipelineがDeployされている。
• 今回利用するサンプルアプリをSource to Image（S2I）にてDeployした際に自動的に作られるPipelineをカスタマイズする格好で、SonarQubeによるソースコード解析Taskを追加してみます。

ご参考：S2IによるアプリケーションDeploy時にPipelineを自動で生成する方法

• 適当なNameSpaceにおいて「+追加」 -> 「Gitからのインポート」と進みます
• GitリポジトリのClone URLをコピペします
  
  • log-testというNode.jsのアプリを作ったのですが、これでやっていきます。
  • 文字列を入力してSubmitをクリックすると、標準出力に文字列をログとして出すだけのなんてこと無いアプリでして、作り方は殆どChatGPTに聞きました。
• S2IのPipelineを生成するのは超簡単です。ここにチェックを入れて「作成」をクリックするだけです。
  
• 「表示パイプラインの可視化」を押すと簡単なTaskの構成順序を見れます。
  
  • fechrepository：ソースコード一式をリポジトリからClone（ダウンロード）してくる
  • build：コンテナイメージをBuildをする
  • deploy：コンテナとしてDeployする
• 作成するとこんな感じで「パイプライン」が作成されます。
  
• ちなみに、この手法でアプリケーションをDployすると、同じNameSpaceにel-event-listener-hogehogeというDeploymentがApplyされます。
  
• こいつは何か？ということなのですが、EventListenerはGitリポジトリからのWebhook通知を受け、それを元にTektonに対して「Gitリポジトリの中身更新されたっぽいんで、Pipelineブン回してもらっていいすかね？」っていう指示を飛ばすPodになります。
  
• ちゃちゃっとGitHubのリポジトリのWebhook機能を設定してみます。
• 任意のリポジトリの「Setteings」タブをクリックしてください
  
• 「Setteings」メニュー左側の「Webhook」をクリックしてください
  
• 「Add Webhook」をクリックしてください
  
• 最低限、以下の様にパラメータを設定してみます。
  • Payload URL: EventListenerのRoute(URL)を入れる。このURLにWebhookを飛ばしてくれます。
  • Content type: application/jsonを選択してください。
    
• 「Add Webhook」をクリックしてWebhook連携が完了します。

事前準備②： OpenShiftにSonarQubeをDeployする

• 既に公開済みのこちらの記事をご参照ください。
• 以下はSonarQubeのコンソール画面にログインができたあとからの流れで説明します。

SonerQubeとGitHubを接続する

• 基本的にはSonarQubeの公式サイトを参考にして、Step1,2,3と進めていけば大丈夫です。
• 要所だけかいつまんで見ていきます。

GitHub Appを作成して、自身のOrgにinstallする

• インテグレーションの為のGitHub Appsを作成します。
• GitHub Appを作成すると、以下の様なパラメータが払い出されます。
  • GitHub App ID
  • Client ID
  • Client Secret: 今作ったGitHub Appのページで生成します
  • Private Key: 同じく、今作ったGitHub Appのページ(一番下までスクロール)で生成します
• こちらに従って、自身のOrg（もしOrgに所属しない場合は自身のアカウントIDがそれにあたります）にAppをInstallしましょう。

SonarQubeにGitHub Appのパラメータを入力する

• SonarQubeに初めてログインした場合、Project作成画面に居ると思います。
• 今回はImport from GitHubから、各種パラメータを入力しましょう
  
• GitHub App作成時に生成される種々のパラメータを入力してください
  
• 連携がうまくいくと、リポジトリ選択画面が出ますので、連携したいリポジトリ（＝アプリケーション）をImportします
  • GitHub Appをご自身のOrg（あるいはアカウント）にInstallしていない場合、エラー出ますので、こちらに従って忘れずにInstallしてください。
• 私は log-testのリポジトリを指定しました。ご自身のスキャンしたいソースコード格納先をご指定ください。
  
• Importできると、Analysis Methodの画面に行きます。
• ここで、各種のCIツールと連携することになるのですが、Tekton (OpenShift Pipelines)はデフォルト選択肢に無いので、Other CIを選んでください。
  
• ここまででGitHubの特定のリポジトリと、OpenShiftにDeployしたSonarQubeとの連携までできました。
• いよいよここからはPipelineのTaskにSonarQubeによるソースコード解析をTaskとして追加する作業に進みます

Pipelineにソースコード解析をTaskとして追加する

• ちょっと頭の整理をします
  • 完了: こちらの記事に従いSonarQubeをOpenShiftにDeployした
  • 完了: GitHub Appを介してSonarQubeとGitHubを連携した
  • これから: SonarQubeによるソースコード解析Taskを作成する
  • これから: Tekton(OpenShift Pipeline）に当該Taskを追加する
• もうちょいです。頑張りましょう！

SonarQube側でToken生成する

• 前の画面でOther CIをクリックすると、Token生成画面に遷移します
  
• ここでTokenの情報を設定してGenerateをクリックしてください。
• Tokenの破棄期間（Expireタイム)はご自由にどうぞ！
  
• Continueを押す
  
• アプリケーションのフレームワーク選択画面が出てきますので、該当するものを選択してください。
• 今回はNode.jsのアプリケーションですので、Otherを選択しました
  
• するとSONAR_TOKENとかいうパラメータが生成されます。
• こいつがTektonがSonarQubeのProjectにアクセスするために必要な認証情報になるわけです。
• 他にも色々スニペットが生成されているのですが、一旦無視でOkです。

Tekton (OpenShift Pipeline)のPipelineにTaskを追加する

• SonarQubeの画面は閉じずに、OpenShiftのコンソールに戻りましょう
  
• こちらはトポロジーの画面なのですが、一旦わかりやすいように、SonarQubeがDeployされているNameSpaceと同じ所に、log-testアプリもDeployしちゃいました。
• もちろん、アプリケーションは別にNameSpaceを作ってDeployしておいてもOKです。
• このlog-testアプリのPipelineはこんな感じです。
  
• このPipelineにSonarQubeによるソースコード解析Taskを追加しましょう！
• Pipeline詳細画面の右上「アクション」 -> 「パイプラインの編集」へ進みます。
  
• ソースコード解析のTaskですから、PipelineのWorkspace（※）にソースコードをCloneしてきた直後、つまりfechrepositoryとbuildの間にTaskとして追加する必要がありますね。
  • (※)Pipelineを実行中のみPersistentVolumeがマウントされて立ち上がる作業スペース。ここで一旦ソースコードや設定ファイルなどを作成したり、スクリプト実行をしたりしてTaskが実行される
    
• この辺にマウスオーバーすると+ボタンが出るんで、クリック。
• 「Taskの追加」をクリックすると、Task検索画面が出てくるので、sonarと入れるとsonar-scannerというTaskが出てきます。
  • こちらはTektonHubにて公開されているSonarQubeによるソースコード解析Taskです。
  • 「みんなこういうTask要るやろ？」というのはだいたいTektonHubに公開されています。
• ここでver1.0かver2.0を選択してInstallしてください。
  • Ver3.0移行はSonarQubeのSaaS版との連携に必要なパラメータ指定が必要なのですが、今回はSelf-Install版を使っているので、1.0か2.0でやってください。
  • 私は一旦2.0のほうでやっていきます
    
• Taskが追加されました。ここからパラメータを追加していきます。
  
• なお、デフォルトのパラメータについて説明します

デフォルトのパラメータ

• SONAR_HOST_URL: http://”アプリ名”.”NameSpace名”.svc.cluster.local:9000
  • こいつはCluster内からのアクセス先URLを指定します。
  • TektonはOpenShiftのClusterの中に居ますので、インターネットからのアクセス先URL（＝RouteのURL）ではなく、ホスト名指定でも良いわけです。
  • ホスト名はServiceリソースの画面で見れます
    
  • Service名をクリックして、
    
  • 頭にhttp://を付けて、ExposeしているPort番号（=9000番）をくっつければOK
  • つまり私の場合は http://docker-sonarqube.sonarqube.svc.cluster.local:9000 となります。繰り返しますが、こちらのURLはインターネットからはアクセスできません。
• SONAR_PROJECT_KEY: SonarQubeの画面で確認可能
  

デフォルトのパラメータを入力してTaskをRunしてみる

• 結論から言うとエラーが起きます。
• まぁまずはやってみましょう。
• TektonのPipeline編集画面に戻ってください。デフォルトのパラメータ入力欄に値を入力します。
  • SONAR_HOST_URL:上述の通り
  • SONAR_PROJECT_KEY:上述の通り
  • source: スキャンするべきソースコードをCloneしてきたWorkspace名を指定します。既に「workspace」という名前のそれがあるので選択します。
  • sonar-settings: SonarQubeによるスキャン実行TaskがPodとして起動する為に必要な設定情報です。Taskの中で自動生成されます。こちらも「workspace」を設定しておいてOKです。
    
• 「保存」をクリックします。
• 右上の「アクション」 -> 「開始」をクリックします。
  
• ここまでの操作でPipeline実行の為に必要なパラメータが設定されているはずですので、「開始」をクリックします。
  
• 当初想定通り、SonarQube-ScannerTaskでエラーが起きます。
  
• 「ログ」からエラーメッセージを見てみます。要は「認証できません」ということらしいです。
  
• そうです！SONAR_TOKENを設定していませんね！
• Sonar-ScannerTaskの.yamlファイルを修正して、SONAR_TOKENパラメータを設定しましょう。

Sonar-ScannerにSONAR_TOKEN情報を設定できるようにする

• Pipeline詳細画面に戻って、sonarqube-scannerTaskをクリックします。
  
• 「YAML」タブに遷移し、以下の様に追記します。

spec.params

- default: ''
  description: Token information
  name: SONAR_TOKEN
  type: string

spec.steps

echo "sonar.token=$(params.SONAR_TOKEN)" >> sonar-project.properties

• 「保存」を押してYamlファイルの編集を反映しましょう。
• 再びPipeline編集画面に戻ってください
  
• 「sonarqube-scanner」Taskをクリックすると、SONAR_TOKEN欄が増えています！
  
• SonarQubeの画面で確認できるSONAR_TOKENの値をコピペして、「保存」をクリックしてください。
  
• もう一回Pipeline実行を開始してください。
  
• 無事Pipeline実行が成功しました！
  
• SonarQubeのProject画面を確認するとスキャン結果を確認できます。
  

最後に

• これでSonarQubeによるソースコードスキャンTaskが追加できました。