kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

最近のかせいさんの情報収集方法 2021年版

この記事はLCL Advent Calendar 2021 - 18日目です。

qiita.com

こんにちは、 id:kasei_san です。

皆さん、技術情報の情報収集どうしてますか?

昔はLiveDoorReaderとか、はてなブックマークとかで集めれば割と良かったのですが、RSSがオワコンになり、はてなブックマークも(個人的には)ノイズが多くて使いづらくなってしまい、どうしたものかと考えています。

今回は、かせいさんの試行錯誤中の情報収集方法を晒して「みんなどうしてる?」という意見を伺いたくて、記事を書いてみました。

なので、「自分はこうしてるよ!」とか「こうしたらどう?」とかあったら、コメントなりはてブなり、引用RTなりで何かフィードバックいただけると嬉しいです。

それではどうぞ

概要

だいたいこんな感じで、AWSやRuby/Railsをメインに情報を収集しています。後でそれぞれの詳細について解説しますね

  • なんやかんやでRSS
  • twitter
  • ruby-jpのSlackワークスペース
  • オハヨーAWS

なんやかんやでRSS

なんやかんやでまだ生き続けているRSSも購読しています。

重要度が低いものは、feedly で暇な時にチェックして、 重要度が高いものは、slackの自分の分報チャンネルに出るようにしています

slack に出るようにしているRSS

feedly で見ているRSS

twitter

速報性ではなんやかんやここが一番ですね。 自分のやっている分野の本を書いたり、アウトプットを良くしている人、AWSの中の人などを 350人ほどフォローして います。 AWS障害とか、最近だとLog4Shellみたいな大きなできごとがあると、話題が何度も上がってくるので、見落としが無いのが良いですね。

仕方ないですね!

ruby-jpのSlackワークスペース

ruby-jp.github.io

こちらも速報性は高いです。Ruby以外にも、AWSの障害やセキュリティインシデントなども話題になるので、Rubyのwebエンジニアやっていて必要なニュースは割とここでキャッチアップできます。あと、Rubyで開発している企業blogの更新を通知してくれるチャンネルもあるので、ここでの情報キャッチアップもなかなか良いです。(弊社LCLも参加しています!)

オハヨーAWS

twitter.com

AWSの中の人などがやっている、毎朝平日9時に開かれる twitter スペースです。前日に更新された内容を30分ですごい勢いでキャッチアップしてくれるのを仕事をしながら聞いています。各サービスについてどういう場合に使うものなのかとか、マイナーなサービスの場合、これはどういうものなのかも解説してくれるので、単に更新を見るよりも理解しやすくて、助かっています。

まとめ

現状はだいたいこんな感じで、Ruby/Rails/AWSの情報を集めています。収集先が多すぎても見なくなってしまいますし、少なすぎてもキャッチアップしきれないのでなかなかバランスが難しいですね。RSS以降の世代の人はどんな風に情報収集しているのか気になっています。ぜひ「自分はこうしているよ」とかありましたら教えていただければ幸いです。

それでは!

Access-Control-Allow-Origin の値を動的に設定するときには、Vary 'Origin' も設定する必要があるよって話

http セキュリティ Nginx

これの続き

blog.kasei-san.com

Access-Control-Allow-Origin の値を動的に設定する必要があるパターン

複数のオリジンからクロスドメインのリクエストを受けるサーバが Access-Control-Allow-Origin を返す場合、オリジンごとに異なる値を動的に返す必要がある。

  • 参考: Nginxの場合のこんな感じの設定を書く

gist.github.com

その場合、CDNが問題になる

途中にCDNが挟まってる場合、Access-Control-Allow-Originが、最初に来たオリジンのままで固定されてしまう。

これにより、Access-Control-Allow-Originの値と異なるオリジンからのリクエストがすべて、CORSエラーになってしまう。

その対策

レスポンスヘッダに Vary 'Origin' を追加する。

Vary とは?

キャッシュ時にURL以外に、キーとなるリクエストヘッダの値を決める設定。 例えば Vary : Accept-Language とすると、同じURLでも、言語ごとにキャッシュされるようになる。

んで、Vary 'Origin' の場合、Origin がキーになる。 Origin は、クロスドメインのリクエストを投げた場合に、元々のドメインが格納されるリクエストヘッダ。

そうすれば、複数オリジンからのリクエストごとに、異なる Access-Control-Allow-Origin を返すレスポンスをそれぞれキャッシュできる。

参考

developer.mozilla.org

developer.mozilla.org

developer.mozilla.org

Access-Control-Allow-Origin の値が ("*" ワイルドカードではなく) 具体的なオリジンであるレスポンスをサーバーが送信する場合、レスポンスには Vary レスポンスヘッダーに Origin という値を設定して、 Origin リクエストヘッダーの値によって値が変わることをブラウザーに対して示してください。

2021/09/30 から、OpenSSL1.0.x でLet'sEncryptの証明書を使っているところと接続できなくなる問題とEC2での対策方法

OpenSSL AWS

現象

$ echo|openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org
Verify return code: 20 (unable to get local issuer certificate)
  • OpenSSLを使っている、curl やRuby なども影響を受ける

原因

  • Let'sEncryptの証明書チェーンは、R3 --> ISRG Root X1 --> DST Root CA X3 となっている
  • この、DST Root CA X3 が 2021/09/30 に期限切れとなった
  • トラストストアには、ISRG Root X1 と DST Root CA X3 が入っているが OpenSSL 1.0.x では、 証明書チェーンの中に「トラストストアにあるが期限切れ」の証明書があると検証が失敗扱いになる という挙動がある

歴史的経緯

Let'sEncrypt がルート証明書を DST Root CA X3 から ISRG Root X1 に変更しようとする流れ

  • もともとの Let'sEncrypt のルート証明書は、DST Root CA X3
  • Let'sEncrypt は、ルート証明書を ISRG Root X1 に変えようとしていた
  • しかし、古いクライアントでは、トラストストアに、ISRG Root X1 が無いため、中間証明書を DST Root CA X3 と ISRG Root X1 のクロスサイン証明書にしていた(これにより、どちらかがトラストストアにあれば検証が通る)
  • その後、2021/09/30 に DST Root CA X3 の期限が切れるため、ルート証明書を ISRG Root X1 だけにする動きが始まる

Android7.1 問題と苦肉の策

  • しかし、Android7.1以前のバージョンにはISRGのルート証明書が入っていないため、ルート証明書を切り替えると、Android7.1以前でLet'sEncryptの証明書が使えなくなるという問題が判明
  • で、Let'sEncryptは苦肉の策として、以下のようにルート証明書を変更するとアナウンス
R3 --> ISRG Root X1 --> DST Root CA X3
  • ルート証明書の上にルート証明書をチェーンするという荒業
  • これをすると、Android7.1以前では、ISRGがトラストストアにないため、DSTまで遡る。ここで、2021/09/30 以降は、DSTの有効期限が切れてしまうが... Android7.1では、証明書の有効期限チェックを行わない ため、問題が解決すると... 解決...?
  • ISRGをトラストストアにもつ、他のクライアントではDSTまで遡らないため、特に問題はないはずだったが...

OpenSSL 1.0.x では Android互換チェーン の検証に失敗する

  • しかし、OpenSSL 1.0.x では、上記の「Android互換チェーン」については検証が失敗扱いとなる。これは、OpenSSL1.0.xで、信頼チェーンの間に無効な証明書があって、さらにそれがトラストストアに登録済だと、検証が失敗するという挙動(仕様?)のため

👇 Let'sEncrypt による、OpenSSL 1.0.x では Android互換チェーン の検証に失敗する件の記事

community.letsencrypt.org

  • OpenSSL 1.1.0 では修正済みで、1.0.x はたくさんの脆弱性があるので、さっさとバージョンをあげようとアナウンスしている

対策

OpenSSL公式は、トラストストアにて、期限切れのDSTのルート証明書を削除するようにと、アナウンスしている

https://t.co/bL7HmxKqcr?amp=1 www.openssl.org

AWS(EC2)では、ルート証明書のyumパッケージである ca-certificates にて、上記の対応を済ませたバージョンを配布しているので、yum update ca-certificates すれば解決する

aws.amazon.com

AWSでは、さらにこちらで手動対策方法もアナウンスしている

aws.amazon.com

参考

songmu.jp

songmu.jp

www.walbrix.co.jp

今更CentOS6でRubyを検証するDocker環境がほしい時みる記事

CentOS Ruby Docker

どうしても古いままの環境をいじらざるを得ない時ありますよね...

Dockerfile

FROM centos:6

RUN \
  sed -i -e "s/^mirrorlist=http:\/\/mirrorlist.centos.org/#mirrorlist=http:\/\/mirrorlist.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo &&\
  sed -i -e "s/^#baseurl=http:\/\/mirror.centos.org/baseurl=http:\/\/vault.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo

RUN yum -y install \
  git \
  bzip2 \
  gcc \
  openssl-devel \
  readline-devel \
  zlib-devel

RUN git clone https://github.com/rbenv/rbenv.git ~/.rbenv
RUN git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
RUN echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
RUN echo 'eval "$(rbenv init - bash)"' >> ~/.bash_profile
RUN \
  source ~/.bash_profile && \
  rbenv install 2.7.4 && \
  rbenv local 2.7.4

RUN yum -y install wget

ポイント

  • CentOS6のサポートが終わってしまったため、リポジトリがもう無い。そのため、古いリポジトリを残してくれている vault.centos.org をリポジトリの参照先にする
  • 中に入った後、source ~/.bash_profile する必要がある。これどうすれば省略できますかね

Rails7のフロントエンドの方向性について理解したことをメモ

Rails

ざっくりまとめ

  • Rails7は、StimulusとTurboのHotwireを標準のjsとしているが、jsまわりのトレンドとは方向が異なる
  • Railsでリッチなフロントエンドをバリバリやるのは難しく、そのあたりの不満がフロントエンド側から表出している
  • Railsは(最初から)、小さいチームによるフルスタック開発のためのフレームワークと表明しており、リッチなフロントエンドをバリバリやることは目指していない

ソース

techfeed.io

👆 DHHによる、「Rails 7は、2021年以降のJavaScriptに対する3つの素晴らしい答えを出すだろう」 の翻訳記事

Railsは当初からフルスタックである。
Rails 7では、JavaScriptに3つの明確な選択肢が用意されている
Hotwireとimport mapsを使ったデフォルトの道。
人気のあるJavaScriptバンドラーの1つとの薄い統合を使った代替の道。
そして最後にフロントエンド用の別のリポジトリを使った厳格なAPIの道。
最後に、Railsを単にAPIとして使用するという選択肢もある。
それを利用するSPAは、まったく別のプロジェクトとリポジトリに置いておく。
Railsは長い間、--apiでこの道をサポートしてきて、これからもそうしていく。
小中規模のチームにはお勧めできない方法だが、フロントエンドとバックエンドの間に高い壁を設けてSPAを作ることに専念している大規模な組織の中にいる場合は、意味のある方法かもしれない。

　

　

kenzoblog.vercel.app

StimulusやHotwireなども少し学習で触りましたが、それなりに学習コストがかかるので、Rails7の上でDHHが推しているJavaScriptの書き方でやっていくと、「Railsの上ではJavaScriptが書ける」みたいな状態になりそうに思います。

DHHの推奨するRailsでのjsに特化しちゃうとキャリアが狭まりそうだよねというのはすごく分かる

　

　

blog.unasuke.com

View層においてJavaScriptのFrameworkもしくはコードの比重が増えていくとともに、バックエンドまで一気通貫で同じ言語を使用できればいいのにという思想からか、加えてRailsとモダンフロントエンドとの相性がよくないからか、Railsの出番は今後減っていくだろうという意見に対しての賛同が増えてきているのを感じている。

今のトレンドである(と思われる)リッチなUXを提供するには、Railsは無用なものになってしまうのでは? という危機感の記事

　

　

zenn.dev

Rails のフロントエンド周りは限界
Rails は文化的にパフォーマンスに対する指向を持たない
ActiveRecord の賞味期限は Rails と同じ
型による大規模化への伸びしろの有無が決定的な差になってきた

　

　

okuramasafumi.hatenablog.jp

👆 Railsはスケールしない個人開発レベルのプロジェクトで強みが活かせるというお話

スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークがRails
そこ(個人開発の場)では「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。
Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。

ぼんやりした感想

  • Railsは、SPAみたいなバリバリのjsではなく、ページの一部をちょっと動的に動かせれば(ほとんどのユースケースで)十分では? というスタンスっぽい
  • そういう意味では、一般ユーザをメインにする最近のwebサイトよりは、業務システムみたいなものの方がRails向きなのかもしれない
  • この辺の方針は理解できるし、個人や数人で全部やる系のシステムではそれで良さそう
  • ただし、StimulusとTurboのHotwireが、フロントエンドとしてのキャリアパスとしてひらけているの? といったら疑問が残るので、バリバリフロントやりたい! って人には向いてなさそう
  • フロントと、バックエンドでチームが明確に分かれてしまっている会社の場合、APIサーバとして使えば良いけど、Railsの良さは活かせないよ? というのがDHHのスタンス
  • そういう場合、Rails以外を選ぶのも良いのかもしれない
  • はてブで指摘があったけど、RailsとDockerとの相性の悪さはめっちゃ理解できる。 bundle install が手間ですよね...

フルスタックRailsを選んだ場合のチームビルドについて

  • 別にチームのキャリアパスとして、フロントエンドとバックエンドが別れてしまっている場合、フルスタックRailsを選択するのは、スピードが得られる代わりにフロントエンド側に多大な負担をかけるよなぁという気持ち
  • フルスタックRailsという選択肢が現状では、フロントエンドのキャリアを閉ざしてしまうので、福利厚生としてよろしくない
  • フルスタックRailsやるんなら、サーバサイドがキャリアの主軸で、フロントもちょこちょこいじれます! って人が良いんだろうなぁ...

自分はどうしましょう

  • なんやかんやで、Railsはまだ残り続けると思うので、それらをメンテナンスするスキルはしばらく腐らなそう。Railsやgemのバージョンアップとか。そのへんは磨き続ける
  • Rails以外のAPIを提供のトレンドを知っておきたい
  • 転職してからインフラに軸足が移りつつあるので、今の所焦燥感は無い
  • フロント側もうすこし勉強しないとな...

MacOSをスリープした時にgoogleアカウントからログアウトする方法

bash Mac

方法

sleepwatcher という、sleep & wakeup 時に任意のコマンドを実行するアプリを使います

また、google アカウントは、 https://accounts.google.com/Logout にアクセスすると、ログアウトできるので、スリープ時に、デフォルトブラウザで、これにアクセスさせます

sleepwatcher のインストール & 自動起動設定

brew install sleepwatcher
brew services start sleepwatcher

スリープ時に実行するスクリプトの作成

sleepwatcher は、スリープ時に ~/.sleep を実行してくれます

cat <<EOS > ~/.sleep
#!/bin/sh
open https://accounts.google.com/Logout
EOS

実行権限も忘れずに

chmod +x ~/.sleep

以上で、スリープ時にgoogleアカウントからログアウトできます

免責事項

sleepwatcher はだいぶ長いこと更新されていないので、使用は自己責任で

経緯

退勤時にgoogleアカウントからのログアウトする会社ルールができたので作ってみました

Terraform Cloud にある state を mv する方法

Terraform

流れ

  • state ファイルをローカルに持ってくる
  • backend をローカルに変更
  • terraform state mv を実行
  • terraform state push を実行
  • backend を Terraform Cloud に戻す(この時に、state を overwrite する)

state ファイルをローカルに持ってくる

terraform state pull > tmp.tfstate

backend をローカルに変更

cat << EOF > override.tf
terraform {
  backend "local" {
  }
}
EOF
$ terraform init -reconfigure
Initializing modules...

Initializing the backend...

Successfully configured the backend "local"! Terraform will automatically
use this backend unless the backend configuration changes.

terraform state mv を実行

terraform state mv -state=tmp.tfstate ...

変更されたことを確認

terraform state list -state=tmp.tfstate | grep ...

terraform state push を実行

terraform state push tmp.tfstate

backend を Terraform Cloud に戻す(この時に、state を overwrite する)

rm override.tf
$ terraform init -reconfigure
Initializing modules...

Initializing the backend...
Acquiring state lock. This may take a few moments...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "remote" backend. An existing non-empty state already exists in
  the new backend. The two states have been saved to temporary files that will be
  removed after responding to this query.

  Previous (type "local"): /var/folders/12/02rv601d4kv6gmbxrzg4hzzh0000gn/T/terraform229570062/1-local.tfstate
  New      (type "remote"): /var/folders/12/02rv601d4kv6gmbxrzg4hzzh0000gn/T/terraform229570062/2-remote.tfstate

  Do you want to overwrite the state in the new backend with the previous state?
  Enter "yes" to copy and "no" to start with the existing state in the newly
  configured "remote" backend.

既存の状態を新しいバックエンドにコピーするか? と聞かれるので「yes」と回答する

リモートのstateでも、変更が維持されていることを確認

terraform state list | grep ...