bootcamp
bootcamp copied to clipboard
fjordllc
プレビュー用にユーザーアイコンを表示する際に、ユーザー名を使用する
Issue
- #7003
概要
前提
テキストエリアで:@username:と記述するとメンションされたユーザーのアバターが表示される。
この時user_icon_urlsというapiを使用してアバターのアタッチされた全ユーザーのアバター画像URLを取得し、表示するべきユーザーのログインネームで取り出すという処理をしている。
本PRではサーバー負荷削減を目的として、user_icon_urlを使わないよう修正する。
変更内容
- アバターの保存先をログインネームから特定できる形にし、
user_icon_urlsを使わずにアバターを取得できるように変更した - Google Cloud Storage上の既存のアバターファイルのパスを変更するためのrakeタスクを追加した
- 不要になった
user_icon_urls関連のファイルとコードを削除した
変更確認方法
先に確認いただきたいことの要点をまとめておきます
- ローカルにファイルを保存する環境でアバターを正しく表示できること
- Google Cloud Storage上のアバター画像ファイルをiconディレクトリ配下に移動できること
- Google Cloud Storageにファイルを保存する環境でアバターを正しく表示できること
事前準備（ローカル環境）
-
feature/use_user_name_for_get_iconをローカルに取り込む -
rails db:resetする -
foreman start -f Procfile.devでサーバーを立ち上げる
ローカル環境での確認
- ID:
komagataでログインする -
http://localhost:3000/reports/newにアクセスする - 日報の内容に
:@komagata:と入力し、プレビュー欄にアバターが表示されることを確認する - 日報の内容に
:@kimura:と入力し、プレビュー欄にデフォルトのアバターが表示されることを確認する
事前準備(ファイルのパス変更)
- Google Coud Platformアカウントを作成し、Google Cloud Storageでバケットを作成する
- クレデンシャルファイル（サービスアカウントキー）を発行し、
bootcamp/に置く (https://cloud.google.com/iam/docs/keys-create-delete?hl=ja#creating を参考にしてください) -
config/storage.ymlのlocalを以下に書き換える
local:
service: GCS
project: "自分のプロジェクトID"
credentials: <%= Rails.root.join("クレデンシャルファイル名") %>
bucket: "自分のバケット名"
public: true
-
lib/tasks/bootcamp.rakeの60~63行目を以下に書き換える
project_id: "自分のプロジェクトID",
credentials: Rails.root.join("クレデンシャルファイル名")
)
bucket_name = "自分のバケット名"
-
lib/bootcamp/setup.rbの35行目を以下に書き換える
user.avatar.attach(io: File.open(path), filename: user.login_name) if File.exist?(path)
-
app/models/user.rbの605行目を以下に書き換える
return
- サーバーを停止し、
rails db:resetする
ファイルパス変更確認
- Google Cloud Storageのコンソールページでファイルが保存されていること、iconディレクトリが存在しないことを確認する
-
rails bootcamp:oneshot:change_icons_filepathを実行する - Google Cloud Storageのコンソールページでiconディレクトリにリネームされたファイルが移動していることを確認する
事前準備(Google Cloud Storage環境)
-
config/webpack/development.jsの2行目を削除し、以下を追記する
process.env.GCS_BUCKET = "自分のバケット名"
process.env.ICON_DIRECTORY = `https://storage.googleapis.com/${process.env.GCS_BUCKET}/icon/`
-
foreman start -f Procfile.devでサーバーを立ち上げる
Google Cloud Storage環境での確認
-
http://localhost:3000/reports/newにアクセスする - 日報の内容に
:@komagata:と入力し、プレビュー欄にアバターが表示されることを確認する - 日報の内容に
:@kimura:と入力し、プレビュー欄にデフォルトのアバターが表示されることを確認する
Screenshot
画面の変更はありません
@rira100000000 レビュー依頼ありがとうございます！ 来週中には対応できると思いますが、大丈夫でしょうか？ お急ぎであれば他の方にお願いしていただけると助かりますm(__)m よろしくお願いいたします！
@rira100000000 おつかれさまです。 こちら今週中にレビュー予定とお伝えしていましたが、現在抱えているissueの対応に追われていて余裕がなく、 大変申し訳ないのですが、他の方にお願いしてもらってもよろしいでしょうか？ お待たせしてしまってからになってしまい申し訳ありませんm(__)m
@rira100000000 お疲れさまです！レビュー承知しました👍 少しお時間いただいてしまうかもしれませんが、数日中にお返事できるよう頑張ります！
@SuzukaHori 確認ありがとうございました！
@komagata チームメンバーのApproveをいただいたのでレビューをお願いいたします。
@komagata 確認ありがとうございます。
アップする時にS3上のファイル名をユーザー名にするなどで対応できないでしょうか？
今のコードで既にS3上のファイル名はユーザー名になっている認識です。
Cloud Runのコンテナ数も表示してしまう
ここの部分よくわからなかったのですが、本番環境だと何かセキュリティ的に良くない情報が表示されてしまうのでしょうか？
今回の実装ではdev環境とproduction環境では画像の読み込み方が異なります。 production環境ではGCPのURL+ファイル名から直接読み込むのでrailsのプロセス（avatar_controller）は間にいない認識です。
dev環境ではローカルに動的に保存したファイルを読み込むため、コントローラーでファイルを取得する必要があるという認識です。
@rira100000000
今のコードで既にS3上のファイル名はユーザー名になっている認識です。
なるほどです〜。takeタスクがあることを見逃していました。すみません。
Cloud Runのコンテナ数も表示してしまう
すみません、下記の間違いです。
Cloud Runのコンテナ数も消費してしまう
@komagata お疲れ様です。 修正が完了しましたので、再度確認をお願いします。
提示いただいたリンクのように、keyメソッドをオーバーライドするという実装も試してみたのですが、アタッチの対象がavatarなのかprofile_imageなのかをkeyメソッド内で判断する必要があります。
editの場合はblob.attachments.first.nameからavatarのような文字列を取得できるので問題ないのですが、createの場合attachmentsがまだ作られていないため空になります。
そうなるとcreate時にアタッチ対象を識別するのが難しいためこの方法は使えないと判断しました。
実際の運用ではcreate時にprofile_imageはアタッチされないようなので、createの場合はアタッチされるのはavatarで確定、という方針であればkeyのオーバーライド方式でも実装できますが、今後ユーザー登録時にattachしたいものが増えた際を考えると避けるべきかと考えています。
修正内容ですが、修正前はavatarを再アタッチし、そのタイミングでキー（ファイル名）を指定していたのですが、今回はafter_commitを使い、blobのkeyを指定することで実現しています。 同じkeyのファイルが既に存在しているとエラーとなるので、既存のblobが同一のキーで存在する場合、削除する処理が入っています。
@rira100000000 実装ありがとうございます。
一つまえのコメントではまだ方針が決定していないので、できれば自分の中だけで完結せず、実装の方針が決まった時点で相談してほしいです。 こういったことはスクラムの中で一度ではなかったので、これから新人として入社してから仕事を進めるなかで問題になっちゃう点かもしれないので気を付けてやってみるとよいかもしれません。
こちら僕の方で引き継がせていただきます～。