はじめに
CI/CD を中心としたソフトウェア開発環境は、いまでは一般的となっています。そのなかで、アーティファクト（バイナリなどの生成物）の管理機能を中核に据えた JFrog というプロダクトがあります。
具体的には JFrog は、以下のプロダクトを含むプラットフォーム製品です。
JFrog は一部機能をのぞき有償の製品ですが、今回 SaaS 版のトライアルする機会があったため、下記のワークショップを実行してみました。
In this workshop you will learn about the JFrog Platform and how to leverage JFrog Pipelines, Artifactory and Xray for managing your Software Development Lifecycle (SDLC) and bring DevOps to the cloud on AWS.
（このワークショップでは、JFrog プラットフォームについて学び JFrog Pipelines、Artifactory、Xray を活用して、AWS 上でソフトウェア開発ライフサイクル（SDLC）を管理し DevOps を実現する方法を学びます。）
ただ、このワークショップが作られたのが少し前 *1のようで、現在の環境だとそのままでは動かないところもありました *2。幸い少しの修正で動作させることはできたので、ブログにして残しておくことにしました。
もし、
「JFrog 聞いたことあるけどよく知らない、使ってみたい」
という方がおられましたら、この記事を参考に是非試してみて下さい！
前提
今回の目的は、以下の JFrog 製品の機能や表示を確認することでした：
- JFrog Artifactory（アーティファクト管理）
- JFrog Xray（アーティファクトに対するセキュリティスキャン）
「実行した」といいましたが、このワークショップはセルフホスト版が前提となっていたり、ハンズオンセミナーを念頭においたものかコマンドラインの実行環境に Cloud9 を使うなど、今回のトライアルには合わないところもありました。
今回その部分はばっさり省略していますがご了承ください。
- JFrog は AWS SaaS 版を使う。既にアカウントはある前提
- ワークショップを実施する AWS アカウントと、そのアカウント内で Administrator 権限をもつ IAM ユーザー/ロールも既にある前提
- 今回は JFrog のトライアルが主であるため、手順は 3. までが対象
- 途中 git コマンドの実行手順があるが、Cloud9 は使わずローカル環境（Mac）で実行
- AWS リージョンは東京（
ap-northeast-1）を選択
また、JFrog の WebUI が新しくなっていて、若干手順とことなるところがありました。
とはいえそんなに戸惑うほどの変化ではなかったのですが、気になる場合は旧 UI に戻して実行すると良さそうです。 *3
では、以下順に説明していきます。
DevOps Modernization Workshop
ここで、以下のワークショップの手順を進めるための準備をしておきましょう。
以下のアカウントにログインしておきます。もしない場合は作っておきましょう。
- ワークショップ用 AWS アカウント
- GitHub アカウント
また、git が使える環境（ターミナルなど）も用意しておいてください。
上の GitHub アカウントに接続出来るよう SSH 鍵なども設定しておきます。
1. Introduction
ここは導入というか、「DevOps とは」「JFrog とは」みたいな説明となります。一般的な情報も含むので、興味があれば、で良いと思いますが、 1.5 JFrog Platform for DevOps in the Cloud は JFrog 製品群の位置づけの説明なので、JFrog をまだよく知らないという方はご一読いただくといいと思います。
（ JFrog Platform for DevOps in the Cloud :: On Your Own Setup より引用）
目次はこんな感じです：
- 1.1 DevOps in the Cloud
- 1.2 Continuous Integration and Delivery
- 1.3 Binary Repository Management
- 1.4 DevSecOps
- 1.5 JFrog Platform for DevOps in the Cloud
- 1.6 Workshop Setup
2. Self-Guided Setup
実際に JFrog ワークショップを進めるための準備段階です。
今回の場合は 2.1〜2.7 までスキップして構わないと思いますが、どんなことをやっているかは簡単にコメントをつけておくので、興味があれば眺めてみて下さい。
- 2.1 Self-paced: Create an AWS account
- ワークショップ用に AWS アカウントをひとつ新設
AdministratorAccess権限をもつ IAM ユーザーを作成
- 2.2 Set up your Cloud9 IDE
- 2.3 Create an IAM role for your workspace
- 2.4 Attach the IAM role to your Workspace
- 2.5 Update IAM settings for your Workspace
- 2.2〜2.5 まで、コマンド（AWS CLI, git）を実行したりコードを修正したりする環境の用意
- 2.6 Get a Free JFrog Platform Instance from AWS Marketplace
- AWS マーケットプレイス から JFrog のフリートライアル環境を起動
- 2.7 AWS Credit Request
- ワークショップ用に使えるクレジットの申請
というわけで、
ここからが実際に手を動かす手順となります！
2.8 Set Up Pipelines
まず、JFrog で「Pipeline」機能を使えるようにします（アクティベート）。
クリックするとバックグラウンドでアクティベーションが始まりますが、そのあと権限まわりでおかしな（使えるはずなのに使えない旨の）メッセージが出ることもあったので、その場合は一度ログアウトしてからログインし直すと良いと思いました。
2.9 Set Up Docker Repositories
- 4.で Create をクリックした後、Docker CLI から使う場合などのインストラクションの画面が表示されますが、ひととおり眺めたら Done で閉じて大丈夫です
- 5.で Add Repositories とありますが、ここが Create Repository と表記が変わっています
- 7.で
workshop-docker-prod-localを記入するところは、 Name ではなく Repository Key です
なおここで、手順にないのですが、一番したにある Enable Indexing In Xray のスイッチを ON にしておきましょう。後の手順で *4、ここが ON である前提で話が進むようです。 *5
- 7.はもうひとつ、Save & FinishではなくCreate Local Repositoryとなったようです
- 10.は、フレーム内をそこそこスクロールしないと表示されないので、見つからない場合でも慌てないでスクロールしてみてください
2.10 Set Up Xray Security
- 2.ですが、もしかしたら初期状態で既に何かひとつポリシーが存在するかも知れません *6。その場合は Create a Policy ではなく New Policy をクリックします
- 5.Rule では Type が選べるようになっているかも知れませんが、デフォルトの Vulnerabilities のままで大丈夫です
2.11 Workshop Next Steps
ここは次からのステップの説明なので、眺めておくだけで良さそうです。
具体的には以下の流れになります：
- GitHub 上のワークショップ用リポジトリを fork、手元に clone
- JFrog Pipeline と JFrog Artifactory、GitHub、AWS を連携
- コードを修正、GitHub 上に push
- JFrog Pipeline のソースとして件のリポジトリを指定
- Build スタート
- アーティファクトが JFrog 上に保存され、Xray でスキャンできることを確認する
3. JFrog Platform with Docker Compose & ECS
では実際に進めていきます。
このセクションで、前述したような「今のバージョンの JFrog の仕様に合わせる」作業が発生します。実際に必要になったところで詳しく説明します。
3.1 Download the Code
こちらを fork し、ローカルに clone しておきます。
fork は master ブランチだけで大丈夫でした。
3.2 Set up our JFrog Pipelines Integrations
画像が出力されていませんがこちらですｗ
（ Set up our JFrog Pipelines Integrations :: On Your Own Setup より引用）
ここ （1.〜7.）では、JFrog Pipeline と JFrog Artifactory を連携（Integration）します。
JFrog の製品同士で連携、というのも少し変な気がしますが、Pipeline も Artifactory も他の CI/CD ツールと組み合わせたりすることを想定したツールなので、ここで明示的に連携設定をする設計思想なのかなと思います。
続いて （8.〜13.）GitHub との連携に入ります。 ここで GitHub アクセストークンが必要になるので作成します。以下の URL から作成画面を開いて、必要な権限をつけて作成して下さい。
必要な権限はこちらです。
- repo (all)
- admin:repo_hook (read, write)
- admin:public_key (read, write)
名前はなんでもいいですが、分かりやすい名前がいいですね。
ちなみに、いまであれば Fine-grained personal access token のほうが細かく制御ができて好ましいのだと思います。
ですがここでは、手順通り classic を使ってます。 *7
アクセストークン設定後、 Test connection をクリックし、問題がなければ Create してください。
最後に （14.〜21.）、AWS との連携を作成します。
ここは普通に AdministratorAccess 権限をもつ IAM ユーザーのアクセスキー/シークレットキーを作成しているだけですので、CLI が苦手な方は AWS マネジメントコンソールから作って貰って大丈夫です。というかぼくは面倒だったのでそうしました。
注意
もしこのキーが何らかの理由で漏洩した場合、重大なセキュリティインシデントに繋がる可能性がありますので、扱いには十分注意してください。
ワークショップが終わったら速やかにキーの無効化、あるいは削除を推奨します。
もしこのキーが何らかの理由で漏洩した場合、重大なセキュリティインシデントに繋がる可能性がありますので、扱いには十分注意してください。
ワークショップが終わったら速やかにキーの無効化、あるいは削除を推奨します。
ちなみに AdministratorAccess 権限が必要なのは、このあと CloudFormation（CFn）経由で IAM ロールを作成する必要があるためです。
ここで残念なお知らせなのですが。。
今回、時間的な制約もあって、この CFn が完全に動くところまで確認ができていません。ですが今回の目的は JFrog Artifactory/Xray の確認なので、Artifactory 上にアーティファクトが残れば OK としました。何卒ご了承ください。
そしてその観点でいえば、ここで権限上の不足があったとしても、なかったとしても、結局 CFn は作成失敗することになります。あえて危険の少ない権限（例えば PowerUserAccessなど）を設定することもアリだと思います。
3.3 Update our Pipeline
手順 3. で、clone してきた git リポジトリ内の values.yaml を修正します。
修正箇所は 3 ヶ所です。
Artifactory:
server: <your server> #change to your servername
intName: artifactory_integration
devRepo: workshop-docker-local
prodRepo: workshop-docker-prod-local
GitHub:
path: <github username>/aws-ecs-docker-compose-workshop #change to your github username
gitProvider: github_integration
AWS:
intName: aws_integration
region: us-west-2
app:
dockerImageName: <your server>/workshop-docker/ecs-docker-compose-workshop-app #change to your servername
dockerFileLocation: workshop-app
buildName: ecs-docker-compose-workshop-app2 ヶ所ある<your server>には同じ値がはいります。ここは現在使用中の JFrog のサーバ名が入ります。
SaaS 版をお使いなら、おそらく classmethod.jfrog.io のような FQDN になっているかと思います。ご自身の環境をご確認下さい。
<github username>のところは、手順 3.1 で使っている GitHub のアカウント名になります。
ぼくの環境であれば cm-watanabeseigo がはいります。こちらも御自身の環境をご確認下さい。
なお 11 行目にはデプロイ先の AWS リージョン名がはいります。このままだとオレゴンになりますが、お好みで東京（ap-northeast-1）などに書き換えてもいいでしょう。お好みです。
このまま手順 4.〜5. で、 add & commit & push までしてしまいましょう。
その下には
We are now ready to add your CI/CD pipeline and execute!
と書いてあるのです が！
追加作業：現バージョン仕様への適合
前述したとおり「そのままでは動かないところ」の修正を、ここでやっておきます。
具体的には以下のポイントです：
- Pipeline source の YAML 配置
- AWS リージョンの設定
以下順に見ていきます。
1. pipelines source の YAML 配置
このあと手順 3.4 で、 Pipeline source を作成するための YAML を指定する設定があります。
しかしここが、ワークショップのドキュメントと UI が異なって（入力欄がなくなって）いました。
以下のドキュメントを参照すると、JFrog Pipeline のバージョンが上がったことで指定方法が変わったことが分かります。
そこで、該当の YAML ファイルである pipelines.yml と values.yml を .jfrog-pipelines ディレクトリの下に移動してやります。
該当ディレクトリも今は存在していないので、作成して下さい。
% mkdir .jfrog-pipelines
% git mv pipelines.yml values.yml .jfrog-pipelines/
% git commit -m 'WORKAROUND: to fit the current version of jfrog'2. AWS リージョンの設定
values.yml には AWS リージョンを指定するパラメータがあるのですが、いまのままだとこれがうまく反映されず、CFn で作成されるリソースは全て us-east-1 になってしまいます。
.jfrog-pipelines/pipelines.ymlの該当箇所（ECS をデプロイしているところ）に 1 行、環境変数 AWS_DEFAULT_REGION を設定し export する行を追加してあげることで、うまく指定したリージョンで CFn を動かす事に成功しました。 *8
diff --git a/.jfrog-pipelines/pipelines.yml b/.jfrog-pipelines/pipelines.yml
index 361c12b..7b14a03 100644
--- a/.jfrog-pipelines/pipelines.yml
+++ b/.jfrog-pipelines/pipelines.yml
@@ -103,6 +103,7 @@ pipelines:
- chmod +x ./aws-iam-authenticator
- mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$PATH:$HOME/bin
- aws configure set default.region {{ .Values.AWS.region }}
+ - export AWS_DEFAULT_REGION={{ .Values.AWS.region }}
- docker login -u $int_{{ .Values.Artifactory.intName }}_user -p $int_{{ .Values.Artifactory.intName }}_apikey {{ .Values.Artifactory.server }}
- export AWS_ACCESS_KEY_ID=$int_{{ .Values.AWS.intName }}_accessKeyId
- export AWS_SECRET_ACCESS_KEY=$int_{{ .Values.AWS.intName }}_secretAccessKey該当箇所を修正したら commit しておきましょう。
% git add .jfrog-pipelines/pipelines.yml
% git commit -m 'WORKAROUND: to reflect AWS region setting correctly in ecs_deploy'前述の修正とあわせて、忘れずに GitHub に push しておきます。
% git push origin master今度こそ準備が完了しました！
3.4 Build, Publish and Deploy to ECS
まず手順 1.〜8. で、JFrog Pipeline で Pipeline source を作成していきます。
Pipeline source に指定するパラメータが増えていたので、そこを押さえていきます。
Protocol Type
デフォルトは SSH でしたが、せっかくアクセストークンを設定したので HTTPS にしました。
Name
一覧したときに分かりやすい名前を指定すると良さそうです。ここでは適当に workshop2306としました。
Folder Name
手順 7. で指定すべき Pipeline Config File Filter がなくなりこれに変更されていました。つまり、前述の YAML ファイルの配置場所変更はこれへの対処となります。
ここでは .jfrog-pipeline ディレクトリ（フォルダ）が置いてある場所を示せば良いため、「 . 」とだけ入力します。
あとはワークショップの手順通りで埋められるかと思います。
入力が終わったら Create Source をクリックして下さい。
手順 8. 以降では、実際にパイプラインを動かし、JFrog の画面や AWS 上でどのような動きがあるかを見ることができます。
また、手元の Git リポジトリで何かしら修正して push したら Pipeline が動き出す、という CI/CD の体験も（当然ながら）できるので、CI/CD 環境に縁のなかった方がもしいたら体験してみて下さい。
3.5 View Results in JFrog
ここまでの手順で、JFrog Artifactory の Package には Docker Image が出来て保存されているかと思います。
Xray の UI も少し変わっているところがありますが、概ねカンでなんとかなる範囲と思うので、いろいろと触ってみてください。
まとめ
JFrog をつかった CI/CD 環境を構築し、ひととおり Artifactory や Xray、Pipelines の機能を触ることができました。
昨今では Log4j の問題を思い出すまでもなく、OSS サプライチェーンにおけるセキュリティが感心を集めています。JFrog Artifactory と Xray を活用することで、ソフトウェア開発ライフサイクル（SDLC）において生成されるアーティファクトを安全に保つことが出来るようになります。
また当然、アーティファクトレジストリを外部依存しないことで、可用性や動作速度を自身のコントロール下に置くことが可能です。
今回は CI/CD パイプラインを JFrog Pipelines で作成しましたが、Artifactory は当然 Jenkins や CircleCI などの CI ツールと連携することが可能です。また AWS 上にホストする場合、 AWS PrivateLink 経由でアクセスするようなことも可能です。
このあとも検証期間が許す限り、いろいろ試してみたいと思います。
1
