![](/images/20231016a/cloudflare_nagano.png)
イベントリンク: https://cfm-cts.connpass.com/event/295067/
こんにちは。TIGの伊藤です。
10/14に開催されたCloudflare Meetup Naganoに登壇したので発表内容のサマリとイベントのレポートです。
当日のセッション内容
当日のセッション内容は以下のスライドになります。
https://github.com/kaedemalu/cf-teraform-handson
Cloudflare R2でTerraformのStateを管理する方法
今回の登壇では、CloudflareのR2でTerraformのStateを管理できるのか、を調べたので、これを登壇ネタとしました。
TerraformのStateは一般的にはクラウドプロバイダーが提供するストレージサービスで管理します。例えばAWSであればS3、Google CloudであればGCSのようなものです。
この時に、S3にホストさせるのであればいかのようなブロックを書いてBackendの設定を行います。
terraform { |
もし、Cloudflareの管理はCloudflareのみで行いたい思いが出てきた時は、ストレージサービスであるR2をBackendとする場合、以下のように書けるとおよそ想像できます(サポートされている前提ですが)。
terraform { |
ただ、R2を直接的にBackendとして指定することは現時点では対応していない状態です。が、リクエストはTerraform側に出ています。
https://github.com/hashicorp/terraform/issues/33847
そこで目をつけたのが、S3 API compatibilityに記載されている、R2とS3の互換性です。R2ではS3の一定のAPIを担保しており、aws
コマンドでR2を操作できます。そのため同様にTerraformでも、backend
ブロックでS3を宣言していても実態はR2を見せることができるのではないかと思って今回のネタにしました。
R2でState管理を実際に行う
R2のバケットや、クレデンシャルの作成については登壇資料でもある程度触れているので、記事では実際に遭遇したエラーの解消過程を書いていきます。
S3に互換性のあるAPIを利用するということで、TerraformからはS3を使っているように見せることが必要になります。そのため、利用するBackendタイプはs3
を使います。
まずは単純にR2バケット名を指定してterraform init
コマンドを実行しました。
terraform { |
# エラー1 |
error validating provider credentials
ということでクレデンシャルのバリデーションに失敗しているようです。これはまず回避するために、skip_credentials_validation = true
を追加して再度コマンド実行しました。
terraform { |
# エラー2 |
S3としてTerraformに対して見せることはできているようですが、The AWS Access Key Id you provided does not exist in our records.
とエラーが返ってきて、AWSで発行するアクセスキーIDではないと怒られました。Cloudflareから発行するアクセスキーIDとAWSのそれとは異なるので、このエラーに対しても納得できます。
このエラーをよく考えてみると、上記の書き方ではS3エンドポイントのBackendを使うので、デフォルトではhttps://s3.us-east-1.amazonaws.com
を見に行っていることが考えられました。R2ではhttps://<CLOUDFLARE_ACCOUNT_ID>.r2.cloudflarestorage.com
をエンドポイントとしているので、endpoint
パラメータでエンドポイントを上書きしました。。この状態でterraform init
コマンドを実行することで、無事、R2をS3と見せかけた状態で成功しました。
terraform { |
これで、無事R2でState管理をできるようになり、リソース作成を行うと、実際にStateファイル(default.state
)が配置されたり、更新されることがわかりました。そのため、現在のS3互換のAPIサポート状況でも問題なく利用できることがわかりました。
ほかの登壇内容
Cloudflare 亀田さんのセッション
当日のハンズオン資料:Cloudflare AI Gateway を試してみた
今回はイベント当時ベータ版であるAI Gatewayを経由して、Cloudflare WorkersからOpenAI(Chat GPT)にリクエストを実行するハンズオンでした。今回はOpenAIでしたが、プロキシするサービスはこれ以外にも複数選択することが可能で、これはマルチクラウドで使うことが考えられるCloudflareならではと感じたサービスでした。
ハンズオンを通して、Workersの手軽さはもちろん、デプロイに利用するWranglerも含めてしっかり整っていることを感じました。また、ハンズオンの時間が少々余ったので、ほかのハンズオン資料として、Cloudflare Workers AI のハンズオン手順も試してみました。これはCloudflareのエッジポイントに配置されているGPUをWorkersで利用し、推論などを行うハンズオンでした。そのため、
- ほかのサービスを利用する場合:AI Gateway
- Cloudflare上で完結させる場合:Workers AI
と感じました。Clouflare内で構築済みのモデルを利用して私自身もいくつか質問を投げてみましたが、現状は英語での質問がそれなりの精度になる一方日本語については文章の組み立てなどに課題がありそうでした。
Cloudflare Pages入門してみた
Cloudflare Pagesの話ではありましたが、モダンフロントエンド、Webフレームワークの話として参考になりました。私自身、Next.jsを最近触っていることもあり、機能としてフルに生かすために、やほかのフレームワークとの比較がなんとなくイメージつくLTでした。
Cloudflare WorkersでOpenAIのLINE Chatbotを作ってみた
LTのネタとして昨今話題になっているOpenAIについて取り上げていましたが、作成の動機がお子さんにAIに触れる機会を作りたい、という親心に心を打たれました。肝心のLINE Chatbotについても半日くらいで作れたようで、開発体験の良さなどのメリット、いまいちなポイントなども知れました。フレームワークについてもhonoを利用されていたので、以下のリポジトリ試してみようと思います。
https://github.com/koda-masaru/chat-bot
Cloudflare Zero Trustを設定して使ってもらってみた
こちらは、前回のCloudflare Meetup Nagano Vol.1に参加して、Cloudflareに興味を持ったことから実際に仕事でZero Trustを導入した話でした。
仕事で開発されているシステムのデモ環境への接続のスピード、セキュリティの担保をするためにZero Trustを導入して、導入前でもできていたポイントはもちろん、課題とされていた接続スピードについても解消されているということで、Cloudflareのサービス群の導入に対するフットワークの軽さ・導入コストの低さを改めて感じました。
まとめ
前回に引き続きVol.2も参加し、かつ今回は登壇の機会をいただけたので、調べても出てこなかったことをネタにして形にできました。
また、イベントの開催地が私の地元である長野であるということもあり、地元のコミュニティに関われたことがとても嬉しかったので、今後もなんらかの形で関われればと考えています。
余談)地方勉強会参加のススメ
今回、長野のイベントに参加するきっかけは帰省しながら参加できることにつきますが、これに限らず地方で開催される勉強会も改めて足をのばすと良いなと思いました。普段足を伸ばすきっかけがない土地でも、技術やイベントに誘われて参加しつつ、近隣の観光やその土地の料理を味わえるのも地方勉強会ならではの良さだと考えています。今回は懇親会で長野の日本酒をたくさん楽しめました。
![](/images/20231016a/IMG_3553.jpg)
参考
- 技術ブログのほかのClouflare記事
- イベント当日のハッシュタグ #CloudflareUG_mmj
- Togetter