OCIサービスを利用したWebサイト作成その3 ハードコーディングの設定はダメ (2021/07/29)

7月 28, 2021

OCIサービスを利用したWebサイト作成その3 ハードコーディングの設定はダメ (2021/07/29)

https://www.ateam-oracle.com/post/creating-a-web-site-using-oci-services-part-3-hard-coding-configuration-is-bad-mkay

これは、ウェブサイトをホストするためにOCIサービスを悪用する私の「n」パートシリーズのパート3です。もし、パート1と2を読んでいない場合は、最初のパートに戻り、そこから始めるのがベストでしょう。

パート2 では、私は 2つの大きな間違いを犯したと述べました。バケットを "demosite" ではなく "demo" と名付け、バケット名をコードにハードコーディングしてしまったのです。

では、どのようにこれを修正すればよいのでしょうか？

つまり、コードを編集してバケツの名前を変更すればいいのです。しかし、これでは将来的にバケット名を再び変更することは容易ではありませんし、コードを再利用できるようにすることもできません。そこで、もしこの問題を解決するのであれば、正しい方法で行うのがよいでしょう。

ステップ 1: 既存のコンテンツを新しいバケットにコピー

私たちのデモサイトはいくつかのファイルだけなので、手作業でコピーすればいいのです。しかし、それのどこに楽しみがあるのでしょうか？

代わりに、OCI CLIを使用して、他のUnixコマンドのカップルを一緒に文字列にしてみましょう...

コピー＆ペーストする場合

oci os object list --bucket-name demo --all | jq '.data[].name' | awk '{print "oci os object copy --bucket-name demo --destination-bucket demosite --source-object-name",$1}' | sh

もちろん、あなたの環境に合わせてバケット名を更新する必要があります。

そのコマンドラインは

バケット内のすべてのオブジェクトをリストアップ
jqを使用して名前だけを取得
OCIにコピーコマンドを送信するためのコマンドラインをそれぞれ構築
最後にそれらをすべてshにポンピングして実行

この方法は他にもあり、OCI Python SDK のサンプルにある object_storage_bulk_copy.py スクリプトもその一つです。しかし、もしあなたがOCI CLIとJQをインストールしているなら、これはとても簡単です。

技術的には、コピーは非同期なので、発生するのに時間がかかるかもしれないと言うことになっています。しかし、コンソールに戻って、コピー先のバケットを見る頃には、おそらく既にコピーされていることでしょう。

ステップ 2：コンフィギュレーション設定をアプリケーションに移動

Fnのアプリケーションと個々のFunctionsは、Configurationの設定を関連付けることができます。これらの設定はキーと値のペアで、前者の場合、アプリケーション内のすべてのFunctionに送信されます。後者の場合、設定は1つのFunctionにのみ適用されます。

OCIコンソールから、あるいはOCIまたはFn CLIから、コンフィギュレーション設定を確認し、更新することができます。

この場合、設定をアプリケーションに関連付けましょう(理由は後で説明します)。コンソールからアプリケーションに移動し、新しい設定を追加します。キーは "bucketname" で、値にはバケットの名前を指定します（私の場合は、古いバケットを使用する場合は "demo" 、新しいバケットを使用する場合は "demosite" とします）。

ステップ 3: 設定を読み取るためのコードの更新

Python Function では、Configuration のキーは os 環境で Function に送られます。それでも、Fnでは、将来的に変更された場合に備えて、InvokeContextのConfigフィールドを使用して、これらの設定にアクセスすることを推奨しています。

私のコードは現在このようになっています。

bucket_name = "demo"

それをこう変えればいいんです。

bucket_name = ctx.Config().get("bucketname")

そして、その一方で、もう一つのコードの塊が私たちを見つめているのです。

config = {
    # replace with the region you are using
    "region": "ca-toronto-1"
}

もしバケット名をこのコードから設定に移すのであれば、これもやっておいたほうがいいでしょう。

このファンクションの冒頭で、それを保持するための変数を宣言します。

# we are going to use the Resource Principal signer to sign out requests to Object Store:
signer = oci.auth.signers.get_resource_principals_signer()

# by default use the same region as I'm running in
region = region = signer.region
if "region" in ctx.Config():
    # but allow a config setting to override that
    region = ctx.Config().get("region")

そして、その後

config = {
    "region": region
}

もしこれが分かりにくければ、後ほど私の個人的なgit repoにあるプロジェクトにリンクします。

ここでいくつか面白いことに気がつくと思います。ひとつは、Signer からリージョンを取得していることです。そして、"region" という名前の設定を探しています。こうすることで、デフォルトの動作が最も理にかなったものになります。コードが実行されているのと同じリージョンを使いますが、設定によって誰かがそれを上書きできるようになります。

ステップ 4: コードの再デプロイとテスト

fn deployを再実行し、新しいコードをOCIにプッシュしてください。

次に、ウェブサイトをロードします。

あなたがすべてを正しく行った場合、何も変わっていないでしょう。

次は何でしょう？

ここまで来たら、ありがとうございます

このシリーズの最初の投稿で、私はこのように言いました。

しかし、ファンクションを使ってビジネスロジックを追加するという、実に賢い方法もあるのです。また、フルマネージドサービスを利用しているので、アプリサーバーやロードバランサー、コンピュートインスタンスなど、複雑な運用を心配する必要はありません。

そして、これが次の課題です。これからいくつかのビジネスロジックを統合していきます。具体的には、静的サイトの一部を保護し、ユーザーがOpenID Connect経由でサインインするようにするつもりです。

このブログを検索

Oracle Cloud Infrastructure Blog(翻訳)