【Docker】Rails圧倒的環境構築
どうもてぃ。
新年初の記事ですが、昨年Docker Advent Calendarに参戦した記事の簡易版を書きたいと思います。
理由としては、Advent Calendarの内容はボリューミーすぎて、伝えたいことがまばらになってしまったためです。
今回はさくっといきます。
やりたいこと
スクリプト流したら環境構築完了
詳しい内容は以下のQiita記事へGo
Repository
やることは README.md に全て書いてある。
Let's try
$ git clone https://github.com/motty93/docker-rails-postgresql.git $ cd docker-rails-postgresql/ $ sudo chmod 755 init.sh $ ./init.sh
これでRailsサーバーが立ち上がります。
自動で0.0.0.0:3000 のブラウザが開くはず。
おわり
めっちゃ簡単。
init.sh の中身をみればだいたい何をやっているかわかるかとおもいます（ほとんどコマンドを羅列してるだけ）。
興味あれば是非リポジトリクローンして使ってください。
今後、rails6系のバージョンにも対応する予定ですので、是非Star押していただけると励みになります！
では今年もよろしくお願い致します。
【Vim】バージョン8へアプデするとエラーが出る
どうもてぃです。
最近フロント力を強化するためにReactを毎日少しずつ継続してやってます。
vimでやる場合にインデントが揃わなかったり、中括弧で警告っぽい表示になったりと、結構不便に感じることが多かったので、今回vim-prettierを導入することにしました。
その前準備として、vim8にバージョン上げたところ、突然エラーに陥ってしまったので解決策を備忘録として書いておきます。
環境
vim8へアプデ
ubuntuでアプデする方法は結構簡単でした。
$ sudo add-apt-repository ppa:jonathonf/vim $ sudo apt update $ sudo apt install vim
上記で問題なくいけるはず。
どんなファイルを開いてもエラー
vim8 function <SNR>63_append[6] ~~~~~~~neomru~~~~ やら E892 文字列を浮動少数点数として扱っています と毎回出てくる。
流石に鬱陶しい。
いろいろ調べて見てたら、issueが上がってましたね。
neomru.vimのバージョンチェックを修正しないといけないっぽい。
issue通りに修正
対象のプラグインを修正します。
僕は .vim をホームディレクトリに作っているので以下の手順で修正します。
$ cd .vim/dein/repos/github.com/Shougo/neomru.vim/autoload/ $ vim neomru.vim
vimで開いてノーマルモードで /str2float と入力すると対象の修正箇所まで飛べると思います。
あとはissueの通りに修正を入れたらエラーが出ないようになります。
終わり
Docker Advent Calendar 2019 - Qiita
Docker Advent Calendar 18日目に参戦予定です。
どうぞよろしく。
【Rails】heroku containerをリリース時にアプリがクラッシュする
どうもてぃです。
一ヶ月ほど前に僕もパパになり、可愛い娘の寝顔を見ながら出勤する毎日を過ごしております。
天使すぎてホント癒やされる。
それはさておき、今回はherokuへコンテナデプロイした際に少しハマったので、同じ現象に悩まれてる方へ向けて記事を書きたいと思います。
heroku container
今回始めてheroku containerを使用してみたんですが、めちゃくちゃ簡単でした。
プロジェクトをDockerで作成しているなら是非やってみてください。
ただ、気をつけていないとハマる部分は割とあります。
以下デプロイ手順参考。
個人的にherokuとgoogleはリファレンスが最強だと思ってます。
そんなに難しい英語も書いてないですしね。
はまった現象
heroku containerのデプロイ時に気をつけないといけないのが、デプロイしたいコンテナ以外のコンテナが動いている場合は壊すか止めるかしないとアプリケーションクラッシュの原因になることです。
僕は開発が終わったら毎回コンテナを潰してるので、 docker ps -a で出てきたものは全て削除してます。
総削除は以下のコマンド。
$ docker rm `docker ps -a -q`
最近はdockerのCUIも増えてきてるのでそれを使うのも有りかもですね。
ちょーっと重いですがvimライクに操作できるので以下を使ってます。
コンテナ削除後、デプロイ手順を踏んで普通にデプロイ。
$ heroku container:push web $ heroku container:release web
大抵はこれで上手く行きますが、アプリケーションを開いたところクラッシュしてました。
以下がログ（heroku logs --tail）
2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0` 2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed 2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid. 2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma 2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production 2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options 2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting 2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1 2019-09-04T01:35:33.527454+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/robots.txt" host=line-bot.herokuapp.com request_id=f2475bec-d670-4f3b-9395-407e57a997c5 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:35:34.134860+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=d61341cf-9cc6-4290-9ece-55689779e7ef fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:22.870909+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=9deb4679-3509-4dbd-bd45-3722609ec387 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:25.542657+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=72fa644f-8a98-4e96-a20b-82e01de4b659 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:28.998503+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=dd9d8c5e-7f57-4adf-816a-e68782ca8b83 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:29.463016+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=line-bot.herokuapp.com request_id=b0201b8e-efad-41f6-890c-42c4726c3922 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
マイグレーションもやったし、DBもインスタンスも有料化してるし。。。
もしかしたらなんかエラーが出てるのにそのままデプロイしちゃったかも？とおもってローカルで確認してみたけどそんなこと全く無い。。。
原因不明でした。
よくあるエラーと同じだった
今回の問題はDockerじゃなくてもローカルでも起きる問題が、Dockerコンテナをデプロイしたがゆえに発生した問題でもありました。
どういうことかというと、ローカルで普通に開発している場合（Dockerの有無にかかわらず）、Railsサーバーを落とした際に何かの不具合で tmp/pids/server.pid が残っていると Process exited with status 1 が発生して起動できないことがあります。
これがまさに今回の原因で、コンテナをデプロイする際に、ローカルプロジェクトに tmp/pids/server.pid が残っていると一緒にherokuへデプロイされちゃうと。
エラーメッセージがまさにそれを物語っていて
2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0` 2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed 2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid. 2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma 2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production 2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options 2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting 2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1
A server is already running. Check /myapp/tmp/pids/server.pid. で、デプロイはできているけど、processが既にあるんすわ〜ってherokuが認識してしまっていたということですね。
解決策
とても簡単で
$ rm tmp/pids/server.pid
$ heroku container:push web
$ heroku container:release web
これで解決です。
はまるところはあるんですが、一度出来てしまえばcontainerデプロイの便利さはやめられないです。
【レビュー】ロウヤの170度リクライニングオフィスチェアを購入した
どうもてぃです。
このたび、リモートワークが増える可能性があるということで、作業環境の整備をするはじめの一歩として椅子を購入しました。
願わくばハーマンミラーのアーロンチェアを買いたかったんですが、如何せん高い。
でも、アーロンチェアは会社で使っていてちょっとだけ不満もあったので、その不満を満たすべく自分の要望にあった椅子を探し求めた結果、今回の椅子に決めました。
以前使っていた椅子
実家にいた時に買ったのがこれ。
結果から言うと安物買いの銭失いでした。なんでこんなにレビューが良いのか謎なんですよねぇ。
このタイプ（ハイバックっていうのかしら？）の椅子、僕には全く合わなかったです。
主な理由としては、背もたれ。一息するとき、フーッと、もたれかかっても、身体にフィットしないというか背中全体を支えてくれない。
あと、もたれたときに背もたれが後頭部の高さまであるので、髪の毛にワックスをつけてると気になって安易に背中をつけられない、リラックスできないんです。
挙句の果てには半年で接続部分がもげてしまい、背もたれを外さないといけない始末。
現在は無様な姿と成り果て、粗大ごみとして出す機会を毎回失っているので、仕方なくギター用の椅子として使用しています。
今回購入した椅子
こちらです。
今見たらクソたけぇ。
楽天のスーパーセールで安くなっていたのですが、セール時に買い損ね残念に思っていたところ、公式を見たらたまたまスーパーセールよりも安くなっており衝動的にポチりました。
セール時には17000円くらいで購入できたのはラッキーでしたね。
使用し始めて３ヶ月ほど経過したので、良い点・悪い点を書いていこうと思います。
良い点
その１：組み立てが割と簡単
パーツがいちいちデカイのが難点ですが、デカイ分組み立ては結構簡単でした。
所要時間15〜20分ほど。
レビューで３０分ほどかかると書いてたので、想定内に収まってよかったです。
その２：身体にフィットする
フィットします。前の子よりも断然いいです。
メッシュを購入して、高反発なのにフィットする。すばらC。
僕は身長180cmと割と大きめで、ハイバック式が嫌いという性質をもっていますが、リクライニングを調整すると背筋も伸びて頭も後ろにつかないし身体が包まれる感じがするのはマジで神です。
マジで神。
その３：腰が痛くならない
これも前述の通り、身体にフィットするので腰が痛くなりません。
僕の弱点は腰なので、これを満たせているはかなり大きいです。
つーか、椅子で腰悪くするって本末転倒だわ。
その４：リクライニング最高
仕事中に詰まったりちょっと休憩するときに、フルリクライニングできるのはマジで良い。
レビューにはありましたが、「この椅子に座ると眠くなる」はあながち間違ってないかも。
ただ、僕は仕事用に使ってるのでいまのところその兆候はないです。
フットレストもあって寝心地も割といい。でも、寝る用途として買ったわけではないので気をつけないとですね。
悪い点
その１：デカい
良い点でも上げてますが、デカいです。
僕は男性なので問題ないですが、女性だと一人で組み立てるのに苦労しそう。
あと、引っ越しの時割と面倒臭いかもしれないですねぇ。。。
その時はもっと稼いで、売り払ってアーロンチェア買おうかな。
その２：油臭い
新品あるあるなのかな？
到着してダンボールを開いた時に油臭く、組立後も一週間ほど油臭かったです。
組み立てるときにも思いましたが、接続部の部品（フットレストや足）に結構油がついてました。
仕方ないんですけどね。。。組み立て時にはちゃんと軍手をした方がいいです。
組立て終わった後にアルコール除菌シートで拭いてまわっても一週間前後は臭いが残ったので要注意です。
その３：各部品の品質が良くない
セール時の在庫処分的な商品だからかなーと思ったりしました。
品質については以下
- 座る部品のメッシュがちょっと破けてた
- ネジが合わず回すのに結構力が必要だった
- 左右で接続部の位置が違ったりする
- フットレストを出し入れするとき、何かに引っかかったりしてコツがいる
いまのところ気になるのはこれくらい。
上３つは時間も経ったのでもう気にしていないです。
ただ、フットレストは困りますね。毎回スムーズに出てこない。
しかも、出し入れの音がうるさい。
さらに、金属部分を触ると油が手に付く。
そんな頻繁にリクライニングして寝転がるわけではないので、いまのところ目をつむってます。
次買う椅子では必ず見るように気をつけたいです。。。
その４：フットレストうるさい
前述通りです。
出し入れがうるさいので、これは品質の問題。。。
次買う椅子では以下略
総評
以上、良い点・悪い点あげてみました。
前の椅子がひどすぎたのもあり、最低限要件が満たされている今回の椅子には総じて今のところ満足してます。
いや、その椅子はマジカスだよ、こっちのが絶対おすすめだよって人がいたら是非とも教えてください。
その時はあなたのアフィリンクを踏ませてください。お願いします。
【PostgreSQL】CloudSQLからエクスポートしたダンプデータをインポートする
どうもてぃ。
最近エンジニア用のアカウントを作成しました。
写真チャラいです。
それはさておき、本番環境と同じデータをローカルに反映させたかったので、DBサーバーのCloudSQLからダンプデータを落としてローカルにインポートしました。
その時の流れを書きたいと思います。
プロジェクトはRailsです。
CloudSQLからCloudStorageへ
使用しているDBデータをCloudStorageへ落とします。
ここに手順を書いてもいいですが、googleのドキュメントのわかりやすさには勝てそうにないのでそちらを参考にしてください。
以下参考。
ローカルへインポート
CloudStorageから上記手順で落としたダンプデータをダウンロードします。
その後、psqlコマンドでDB名を指定してインポートします。
この際、先にDBを作って準備しておく必要があります。要注意。
$ bundle exec rails db:create $ psql DB名 < ~/Downloads/Cloud_SQL_Export_2019~~~~~~~~~
ダウンロードしたダンプデータの保存先は基本Downloadsになっているはず。
違う場合はダウンロードしたパスを指定して上げてください。
ダンプデータのファイル名は上のように、 Cloud_SQL_Export_日付 になっているかと思うので、正しく指定してあげてください。
PG::ConnectionBad - fe_sendauth: no password supplied
準備が整ったと思ったので、サーバーを起動して画面確認したところ上記エラー。
単に database.yml でパスワード設定してないだけでした。
おろかなり。
PG::InsufficientPrivilege - ERROR: permission denied for relation schema_migrations
パスワードを設定して、サーバー起動後画面を表示するとこのエラー。
使用しているユーザーがDBスキーマに対して権限を持ってないとのこと。
以下で解決。
postgres=> \c <database_name> # 権限を付与するDB名 database_name=> grant all on all tables in schema public to <user_name> # user_nameは付与するユーザー名
\z で確認するとちゃんと付与されてるっぽかった。
マイグレーションを実行
$ bundle exec rails db:migrate ・ ・ ・ StandardError: An error has occurred, this and all later migrations canceled: PG::InsufficientPrivilege: ERROR: must be owner of relation <table_name>
まだ解決できない。。。
もっかい権限が付与されてるか確認してみると…特定のテーブルだけ権限が変更できてて、他は全く変更できてなかった。
\z じゃなくて、\d の方が見やすかった。だまされた。
なのでテーブルごとに権限を変更した。
postgres=> \c <database_name> # user_nameは付与するユーザー、old_user_nameは現在付与されているユーザー database_name=> select 'alter table ' || schemaname || '.' || tablename || ' owner to <user_name>;' from pg_tables where tableowner = '<old_user_name>'; # 上で出てきたものをコピーして貼り付け実行する
すべてuser_nameをownerへ変更できた。
解決
マイグレーションがやっと通りました。
CloudSQLから落としたデータをインポートするとこんなにハマるとは思ってなかった。
今後同じようなことが出てくると思うので備忘録として、また同じような作業をする人へ向けて書きました。
なにかわからないことがあればコメントよろしくお願いします。
【vim】color pickerを使えるようにする
どうもてぃです。
VSCodeやAtomでは標準で装備されてるcolor pickerですが、vimにはもちろんついてないです。
調べてみたら、普通にあったので導入してみました。
環境
- Ubuntu 16.04.5 LTS(elementary OS 0.4.1 Loki)
vCoolor.vim
こちらですね。
僕は dein.vim をつかってパッケージ管理しているので、
" color picker call dein#add('KabbAmine/vCoolor.vim')
を追加するだけ。
github上のREADMEにオプションが書いてあるので、必要であれば追記してください。
注意
上記URLの説明にある通り、
- LinuxだとZenityもしくはYad
- Windowsだと colorpicker-windows-commandlineのプラグイン
- OSXだとruby scriptを使ったシステムのcolor picker
が呼び出されます。
Macの方は気にしなくていいですが、Linux & Windowsの方は気をつけてください。
完成
ノーマルモードで :VCoolor と入力するとcolor pickerが呼び出されます。
呼び出すのを楽にしたいので後でキーマッピングしたいと思います。
では。
【Rails】helperで環境変数を使いたい場合
どうもてぃです。
備忘録として残しておきます。
環境変数を設定し、クライアント側で表示するものを変えたいとPMから要望が合ったので、その要件を満たすために実装しました。
実装したとはいっても、そんな大したことはやっていないですが。
実行環境
helperでは環境変数を読み込んでいない
まず前提として、helperでは環境変数は読み込めていないです。
今回、gemの dotenv-rails を使っていますが、設定していた環境変数をhelperやviewで呼び出したのですが、 nil が返ってきました。
module UsersHelper def display_user current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true' # => ENV['IS_USER_DISPLAY_DEFAULT']がnilで返ってくる end end
こんな感じ。
.env ファイルに IS_USER_DISPLAY_DEFAULT を設定している状態です。
解決策
至って簡単。
helperのメソッド内で読み込み直せば良い。
module UsersHelper def display_user Dotenv.overload current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true' end end
Dotenv.load では環境変数を変更した際に再読み込みされないようなので、 Dotenv.overloadで対応。
これで面倒なクライアントさんの要件を満たすことが出来ました。
めでたしめでたし。
