ksaito blog

carrierwaveとfog-googleでGCSに静的ファイルをアップロードしたり、ローカルと本番でどう切り替えていくかについて、試してみたことを書き連ねていきます。 ※特に目新しいことはしておらず、既に出回っている記事以上のことは書いていないと思います ローカルストレージでcarrierwaveを試してみる carrierwaveのREADME の手順に沿って、環境構築していきます。 uploaderクラスをこれで生成します。 1 bin/rails g uploader Avatar Userテーブルにnameとavatarを保存するカラムを用意します。 1 2 bin/rails g model User name:string avatar:string bin/rails db:migrate 次に公式に従って以下を定義します。 1 2 3 class User < ApplicationRecord mount_uploader :avatar, AvatarUploader end ここまで公式の手順に従ってやってきました。 これでuserテーブルにavatarのパスを保存できる準備が整います。 rails consoleで試してみます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 bin/rails c u = User.new u.name = 'tanaka' file = File.open('/Users/tanaka/Desktop/hoge.png') u.avatar = file u.save! u.avatar => #<AvatarUploader:0x00000001105974d0 @cache_id=nil, @cache_storage=#<CarrierWave::Storage::File:0x00000001106db170 @cache_called=nil, @uploader=#<AvatarUploader:0x00000001105974d0 ...>>, @deduplication_index=nil, @file= #<CarrierWave::SanitizedFile:0x00000001102dadc8 @content=nil, @content_type=nil, @declared_content_type=nil, @file="/Users/tanaka/work/project/examples/carrierwave-cdn-gcs-signedurl/public/uploads/user/avatar/1/hoge.png", @original_filename=nil>, @filename="hoge.png", @identifier="hoge.png", @model=#<User:0x000000010f1af698 id: 1, name: "tanaka", avatar: "hoge.png", created_at: Sun, 26 Nov 2023 03:16:54.005319000 UTC +00:00, updated_at: Sun, 26 Nov 2023 03:16:54.005319000 UTC +00:00>, @mounted_as=:avatar, @original_filename=nil, @staged=false, @storage=#<CarrierWave::Storage::File:0x0000000110678688 @cache_called=nil, @uploader=#<AvatarUploader:0x00000001105974d0 ...>>, @versions={}> u.avatar.url => "/uploads/user/avatar/1/hoge.png" u.avatar.curent_path => "/Users/tanaka/work/project/examples/carrierwave-cdn-gcs-signedurl/public/uploads/user/avatar/1/hoge.png" こんな感じでavatar.{url,current_path}でpathを引っ張ってくることができます。 ...

GoogleCloudLoadBalancing（以下、GCLB）のurl-mapを指定して、バックエンドバケットにルーティングするときに地味にハマったエラーとその解消法について書きます。 環境 1 2 3 4 5 6 7 GoogleCloud # terraformで構築するため一応バージョンのせておく terraform --version v1.3.5 hashicorp/google v4.74.0 結論 GCLBを経由してGCSのオブジェクト参照するときは、オブジェクトのpathとurl-mapで指定するpathは一致させる必要があります。 解説 今回使用するterraformのコードの一部です。他にもgcsなどのリソースも作ってますが、解説する内容とは関係ないので省略してます。 デフォルトのルートとは別にpaths = ["/test/*"]でバックエンドバケットにルーティングするように設定されています。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 resource "google_compute_url_map" "default" { name = "${local.project}-${local.prefix}" default_service = google_compute_backend_bucket.backend_bucket.id host_rule { hosts = ["*"] path_matcher = "path-matcher-2" } path_matcher { name = "path-matcher-2" default_service = google_compute_backend_bucket.backend_bucket.id path_rule { paths = ["/test/*"] service = google_compute_backend_bucket.backend_bucket.id } } } 上記のコードで構築した、GCLBの設定は以下のようになっています。 ...

Railsのmigrationのバージョン管理がどうやって行われていて、エラーが発生したときにどう対処すればいいか、調べてみたのでまとめていきます。 すでにRailsに関する記事はweb上に山程あって、この記事に目新しい内容は書かれないですが個人の学習記録として残してます。 新しい技術をちゃんとキャッチアップするには、アウトプットが重要なので。 環境 1 2 3 ruby 3.0.6 rails 7.0.6 postgres 15 バージョン管理について railsのmigrationファイルは、/app/db/migrate/に<日時create_model.rb>のような形式でファイルが作られます。 bin/rails db:migrateを実行したときに、どこまでマイグレーションが実行されているかの管理をデータベースのschema_migrationsのほうで記録して、管理しています。 ですので、schema_migrationsに記録されているバージョンと db/migrate/ に存在するmigrationファイルの整合性が合わなくなると、マイグレーションコマンドを実行するときに予期せぬエラーが発生します。 試してみる 以下のコマンドでモデル（必要ないけど）とマイグレーションファイルを作ります。 1 bin/rails g model user そうすると、 20230806103311_create_users.rbが生成されます。 この状態で実行すると、dbのschema_versionsに以下のようにバージョンが記録されます。 1 2 3 version ---------------- 20230806103311 この状態でマイグレーションファイルを削除するなりして、 bin/rails db:rollbackを実行すると、 1 2 3 4 5 6 7 rails aborted! ActiveRecord::UnknownMigrationVersionError: No migration with version number 20230806103311. Tasks: TOP => db:rollback (See full trace by running task with --trace) マイグレーションバージョンに記録されたファイルがありませんとエラーを吐きます。 ...