モヒカンメモ

髪色が定期的に変わることに定評のある(比較的)若者Webエンジニアの備忘録

CircleCIでdockerを使うときはバージョン指定を忘れないこと

学び

CircleCI上でdockerを動かすとデフォルトではバージョン17.09っていう化石エンジンで動いてしまうので気をつけるべし。

背景

とあるOSSアプリ のCIをCircleCIでしようと思って悪戦苦闘していたら、こういうリプを貰った。

「そんなバナナw 今は2019年だぜJK?w」と思って確認したら、本当だったw

f:id:pinkumohikan:20190321233825p:plain

ログ: https://circleci.com/gh/pinkumohikan/sunfish/21

新しいdocker engineを使う

積極的に新しいバージョンを使っていきましょうね、ということで

circleci.com

を参考に、こんな感じでバージョンを指定する。

f:id:pinkumohikan:20190321234645p:plain

すると、指定したバージョンでdocker engineが動くことが確認できた。

f:id:pinkumohikan:20190321234722p:plain

ログ: https://circleci.com/gh/pinkumohikan/sunfish/24

めでたし、めでたし。

ちなみに

指定可能なdocker engineのバージョンはここから選べる。

download.docker.com

Docker for Macが路頭に迷わないようにたくさんメモリを食べられるようにする

こんにちは。

軽量でポータブルな開発&実行環境としてDockerが人気ですね。 僕は数年前までは開発環境にはもっぱらVagrantを使っていたのですが、最近は仕事でもプライベートでもDockerしか使ってないです。

f:id:pinkumohikan:20190209144001p:plain

Dockerは単純に捨てやすい開発環境という使い方もできるし、うまいこと作ると設定ファイルを差し替えたらすぐ本番で動かせるぞ、という使い方も出来ます。後者だと 12 factor appで言う 開発/本番一致 がしっかり出来て最高ですね。

さて、Dockerにはメモリ使用量の制限設定があり、それがネックになって開発中のプログラムの動きが鈍くなったり応答しなくなったことがあったので、誰かの役にたてばいいなと思ってメモリ使用量の増やし方をメモります。

1. Docker for Macへのメモリ使用量を確認する

まずは現状確認をしましょう。

Docker for MacのPreferencesを開きます。

f:id:pinkumohikan:20190209142106p:plain

f:id:pinkumohikan:20190209142123p:plain

次にAdvancedのタブを開き、Memoryの量を確認します。

f:id:pinkumohikan:20190209142158p:plain

メモリ使用量制限は2GBのようです。

2. 制限に引っかかっていることを確認する

プログラムの動きが鈍いのが本当にメモリ使用量制限のせいであるかを確認しましょう。

アクティビティモニタのメモリタブを開きます。

f:id:pinkumohikan:20190209142526p:plain

1.9Gぐらい使っているようですね。メモリ使用量制限の値が2GBだったので数字だけ見ると若干の余裕はありますが、瞬間的に引っかかって縮退した可能性が高そうです。

3. メモリ使用量制限の値を引き上げる

Docker for MacのPreferencesに戻って、2GBとなっていたところを引き上げます。いくらに引き上げるかは総メモリ量と他にどのぐらい同時作業するかによりますが、僕の場合はメモリ16GBマシンで同時に使うのはSlackとIntelliJぐらいなのでガツッと8GBにしました。

一度しか設定できないものではないので、これでもしほかが逼迫したら引き下げればいいよねぐらいの楽観です。

f:id:pinkumohikan:20190209142901p:plain

Apply & Restart を押して、dockerデーモンが上がってきたらdone。

4. プログラムがスムーズに動くようになったか確認する

すむーーーずになりました。

たまに起きていた動きがめちゃ遅になったり応答しなくなったりすることはなくなりました。やっぱりメモリやったんやな!

あとあと見たらdocker-composeでdb含む環境一式を立ち上げてバリバリ動いている状態だと4.7Gぐらいメモリ食ってたので、8GBっていう割り当ては妥当だった模様。

f:id:pinkumohikan:20190209143449p:plain

30日間brew cleanupしてなかったらbrew upgradeのついでに実行されるようになっていた

僕は仕事でもプライベートでも開発環境としてMacBookを使っているのですが、毎朝 brew upgrade コマンドを叩いています。今日は何が上がったかな?を確かめるのが日課です。これをせずにbrew installをした日にはたくさんのupgradeが走ってめちゃめちゃ待たされますからね・・・。

で、昨日おもむろに brew upgrade を叩いたら、やけに長いログが...。

$ brew upgrade
...
==> Upgrading 1 outdated package:
typescript 3.2.4 -> 3.3.1
==> Upgrading typescript
==> Downloading https://homebrew.bintray.com/bottles/typescript-3.3.1.high_sierr
######################################################################## 100.0%
==> Pouring typescript-3.3.1.high_sierra.bottle.tar.gz
🍺  /usr/local/Cellar/typescript/3.3.1: 86 files, 41.0MB
==> `brew cleanup` has not been run in 30 days, running now...
ずらずらずら.....

_人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人_

> brew cleanup has not been run in 30 days, running now... <

 ̄YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY^ ̄

どうやら、30日間brew cleanupしてなかったらbrew upgradeをトリガーに実行されるようになったらしい。

brewはinstallやupgradeするたびに以前のバージョンをキャッシュしておいてくれます。そのお蔭で「アッ、バージョンアップしたら動かない...!」というときにコマンド一つでバージョンを戻すことができます。

brew cleanup は、そのキャッシュを削除するコマンドです。ずっと前のバージョンを残していると使わない割にディスク食いますからね。

へーおもしろい変更だなと思って調べてみたら、この仕様になったのは brew v1.9.0 からっぽい。

github.com

このissueで自動的に brew cleanup を実行すべきでは?という議論がなされての結果らしい。

github.com

PRとしてはこれかな

github.com

HOMEBREW_NO_INSTALL_CLEANUPという環境変数でオプトアウトもできるらしい。

travis encrypt-fileに気をつけろ!2回コマンド叩くと復号に失敗する!?

なんか釣りっぽいタイトルになってしまいましたが、そんな意図はありませんw

CI/CDツールとして良くTravis CIを使っています。CDの際などにアプリ設定やDB接続情報と言った機微情報を扱うとき、travis-cliの travis encrypt-file というコマンドを使うとTravis CIだけが複合可能な形で暗号化することができ、とても便利です。

github.com

ですが、その travis encrypt-file というコマンドにはトラップが有って、最近そのトラップを盛大に踏み抜いて爆死したので注意喚起とワークアラウンドをまとめます。

f:id:pinkumohikan:20190124201752p:plain
やっちまったらすぐ共有!

“travis encrypt-file” を同じディレクトリで2回叩くと、以前暗号化したものが復号できなくなる

これは仕様らしいです。

例:

  1. travis encrypt-file aaa.json叩く -> aaa.json.encが出来る -> aaa.json.encは復号可能
  2. travis encrypt-file bbb.json叩く -> bbb.json.encが出来る -> aaa.json.encは復号できない、 bbb.json.encは復号可能

qiita.com

ところで、travis encrypt-fileで複数ファイルを暗号化すると、最後に暗号化したファイルしか復号できません。このことはTravis CIのマニュアルにも記載があり、必要ファイルをtarに固めて1ファイルにするというワークアラウンドが紹介されています。

本当にドキュメントにもしれっと書かれていた。 まあでもドキュメントって細部まではあんまり読みませんよね。

docs.travis-ci.com

The Command Line Client overrides encrypted entries if you use it to encrypt multiple files. If you need to encrypt multiple files, first create an archive of sensitive files, then decrypt and expand it during the build.

元issueはこれっぽい

github.com

ワークアラウンド1: tarで固めて1個だけ travis encrypt-file する

まずは公式に乗っている正攻法から。

手順:

  1. 必要なアレコレをtarで固める
  2. travis encrypt-file コマンドを叩く
  3. .encファイルをcommit
  4. before_install hookとかで復号
  5. tarを展開
  6. 必要な場所に配置して使う

この方法のデメリットは、tarで固めるべきファイルが何かを誰でも分かる状態にするのが難しいこと。

自分だけが暗号化するならあまり問題にはならないかもですが、誰か別の人が暗号化しうるなら気にすべき。一度暗号化したものはTravisCIしか復号できないので、何がtarに入っているべきかをtarで固める人は知っていないといけない。必要なファイルが1個2個ぐらいならREADMEとかに書くでどうにかなりそうだけど、5個とか6個とかになってくると手動では抜け漏れが起きそう。

ワークアラウンド2: ディレクトリユニークであれば良いことを利用したハック

下記記事の 1つのディレクトリで1つのファイルしか使えない? で知った、ディレクトリユニークであれば復号できるという振る舞いを利用したハック。

rcmdnk.com

手順:

  1. ランダムな名前のディレクトリをつくる
  2. 今回暗号化したいファイルをそのディレクトリへコピー
  3. そのディレクトリで travis encrypt-file コマンドを叩く
  4. .encファイルをcommit
  5. before_install hookとかで復号
  6. 必要な場所に配置して使う

この方法のメリットは、暗号化する人はそのとき暗号化したいファイルのことだけ気にすれば良くなること。

この方法のデメリットは、もしディレクトリ名がかぶったら先に暗号化したものが復号できなくなること。

個人的な一押しは、ディレクトリユニークを利用したハック

名前がかぶったらダメっていうのはそれはハッシュにおける衝突と似たような問題なので、ディレクトリ名を長く複雑にすればリスクとしては低減できそう。仕組みさえ用意できれば、都度必要なファイルを全部用意するよりも楽そう。

そして、ここに便利Makefileを用意しました。

encrypt: FILE_NAME=
encrypt:
    test -n "$(FILE_NAME)" && ls $(FILE_NAME) >/dev/null
    $(eval TEMP_DIR=$(shell mktemp -d tmp-XXXXXXXXXX))
    cp $(FILE_NAME) $(TEMP_DIR)
    cd $(TEMP_DIR) && travis encrypt-file $(FILE_NAME)
    cp $(TEMP_DIR)/*.enc .
    rm -rf $(TEMP_DIR)

使い方は $ make encrypt FILE_NAME=sensitive-data.json みたいな感じ。これをTravis CI用のファイルをまとめているディレクトリにボンっと置いて使っています。

やっていることは、ランダムな名前で一時ディレクトリを作り、そこに指定されたファイルをコピーしてtravis encrypt-fileコマンドを叩き、作られた.encファイルをコピーしたのち一時ディレクトリを削除する、といったことです。

実行例はこんな感じ

$ make encrypt FILE_NAME=sensitive-data.json
test -n "sensitive-data.json" && ls sensitive-data.json >/dev/null
cp sensitive-data.json tmp-1pBHxolDaS
cd tmp-1pBHxolDaS && travis encrypt-file sensitive-data.json
encrypting sensitive-data.json for pinkumohikan/some-repository
storing result as sensitive-data.json.enc
storing secure env variables for decryption

Please add the following to your build script (before_install stage in your .travis.yml, for instance):

    openssl aes-256-cbc -K $encrypted_xxx_key -iv $encrypted_xxx_iv -in sensitive-data.json.enc -out sensitive-data.json -d

Pro Tip: You can add it automatically by running with --add.

Make sure to add sensitive-data.json.enc to the git repository.
Make sure not to add sensitive-data.json to the git repository.
Commit all changes to your .travis.yml.
cp tmp-1pBHxolDaS/*.enc .
rm -rf tmp-1pBHxolDaS

ちなみに、travis encrypt-fileコマンドを叩くときのディレクトリがgitリポジトリ外だと「このリポジトリどこやねん?」って聞かれてうざいので注意。

MySQLにパスワードポリシーで怒られるときの回避策

MySQL5.7.8以降で、ゆるいパスワードでユーザを作成しようとした際に下記のようなエラーで怒られる

mysql> create user "user_name"@"localhost" identified by "some_weak_password";
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.8 (2015-08-03, Release Candidate)

5.7.8以降では validate_password プラグインがデフォルトでインストールされるようになっており、その影響で脆弱なパスワードはプラグインによって怒られるようになっている

現状確認

MySQL :: MySQL 5.7 Reference Manual :: 6.4.3 The Password Validation Plugin

mysql> show global variables like '%validate%';
+--------------------------------------+--------+
| Variable_name                        | Value  |
+--------------------------------------+--------+
| validate_password.check_user_name    | ON     |
| validate_password.dictionary_file    |        |
| validate_password.length             | 8      |
| validate_password.mixed_case_count   | 1      |
| validate_password.number_count       | 1      |
| validate_password.policy             | MEDIUM |
| validate_password.special_char_count | 1      |
+--------------------------------------+--------+
7 rows in set (0.01 sec)

ドキュメントと上記設定を見る限り、デフォルトでは

  • パスワード長 8文字以上
  • 大文字小文字 1文字以上
  • 数字 1文字以上
  • 記号 1文字以上

でないと怒られるらしい

2020/07/04 追記

prefixが validate_password. ではなく validate_password_ の場合もあるらしい。自分の環境ではドットとアンスコどちらが正しいかは上記コマンドで確認できるので、実行前に確認してほしい。

回避策

1. validate_password.policyをLOWに下げる

MySQL :: MySQL 5.7 Reference Manual :: 6.4.3.2 Password Validation Plugin Options and Variables

によると validate_password.policyMEDIUM のときは、長さ、数字、大文字小文字、記号の4項目で制約がかかるが、 LOW にすると長さのみの制約になるようだ

オンラインで実行する場合のクエリ

mysql> set global validate_password.policy = "LOW";
Query OK, 0 rows affected (0.00 sec)

2. 各種制約文字数を下げる

*_count 系の設定値を変更することで、最低文字数の条件を緩和することができる

例えば「記号は必須にしたくないなー」というときは validate_password.special_char_count0 にしてやれば、パスワードに記号が含まれていなくてもエラーにはならなくなる

オンラインで実行する場合のクエリ

mysql> set global validate_password.special_char_count = 0;
Query OK, 0 rows affected (0.01 sec)

注意

文中で紹介したオンラインで実行する場合のクエリを実行してもDBサーバが再起動するとデフォルトに戻るので、永久的な設定としたい場合は my.cnf の mysqld ディレクティブとかに設定を書いておく必要がある

おまけ

参考にした資料、記事等

yoku0825.blogspot.com

MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.8 (2015-08-03, Release Candidate)

MySQL :: MySQL 5.7 Reference Manual :: 6.4.3 The Password Validation Plugin

MySQL :: MySQL 5.7 Reference Manual :: 6.4.3.2 Password Validation Plugin Options and Variables

ワイルドカード証明書はサブドメインでなくても利用できるのかどうかを調べた

背景

*.pinkumohikan.com 用のワイルドカード証明書が pinkumohikan.com ドメインでも使えるのかどうかが気になった。

これまでは pinkumohikan.com はドメインの階層(深さ)が違うので使えないと考えていたが、あるとき pinkumohikan.com でも使えるという話を聞いて気になったので調べた。

ワイルドカード証明書とは?

1枚あればサブドメインでSSLを運用できるSSLサーバ証明書。

ワイルドカードSSLサーバ証明書とは、同一のドメイン配下にある複数の異なるサブドメイン(FQDN)を1枚のSSLサーバ証明書でまとめて保護できるタイプのSSLサーバ証明書です。サブドメインごとに証明書を複数取得する負荷や証明書コストを抑えることができます。

www.geotrust.co.jp

*.pinkumohikan.com 用のワイルドカード証明書を用意すれば、下記のようなドメインを1枚の証明書でSSL運用できる。

  • www.pinkumohikan.com
  • api.pinkumohikan.com
  • cdn.pinkumohikan.com

余談: ワイルドカード証明書を使う理由

証明書の管理は地味に面倒だ。秘密鍵と証明書(場合によっては中間証明書も)を消失しないように、かつそれでいて関係のない開発者には見えないように保管しつづける必要がある。また、証明書には有効期限があるので、いつまでに更新するべきかも気にする必要がある。

当然、証明書が増えるとその分管理コストが増える。証明書の有効期限がバラバラだったら?証明書の更新手続きや差し替えなどを頻繁にやるのは面倒だ。

なので、可能な限り利用する証明書は少なくしたい。そういうときにワイルドカード証明書がとても便利なのだ。

調べた結果

*.pinkumohikan.com 用のワイルドカード証明書が pinkumohikan.com ドメインでも使えるかどうかの技術的な回答は、digicertの資料に答えがあった。

dc.cybertrust.co.jp

従来のワイルドカード証明書では「support.example.com」のように「*」で指定した階層と同じ階層の FQDN でしか利用できませんでした。 DigiCert のワイルドカード証明書はコモンネームと同じドメインであれば、Subject Alternative Names(サブジェクトの別名)を使用して、コモンネームと異なる階層の FQDN を追加可能なため、「example.com」というドメイン名そのものや、「support.mail.example.com」のような別の階層の FQDN も 1 枚で利用可能です。

技術的に一言でいうと、Common Nameが *.pinkumohikan.com となっているだけだと pinkumohikan.com は階層が違うので使えないが、 Subject Alternative Names というプロパティで pinkumohikan.com が明記されている場合は利用可能ということだ。

SANs (Subject Alternative Names)

www.geotrust.co.jp

ようは、証明書のプロパティで「このドメインでも使っていい」という情報を持たせられるらしい。

f:id:pinkumohikan:20181027214643p:plain

Google Chromeの証明書ビューアでは「サブジェクト代替名」と表現されていた。

f:id:pinkumohikan:20181027214745p:plain

Let's Encryptで発行したこのワイルドカード証明書は pinkumohikan.com ドメインでは使え無さそうだ。

結論

*.pinkumohikan.com 用のワイルドカード証明書が pinkumohikan.com ドメインでも使えるかどうかは、発行元が証明書発行時にSANsプロパティに pinkumohikan.com ドメインを明記するかどうか次第である。

Makefileを使ってcomposerをスマートにダウンロードする

やりたいこと

  • composerをダウンロードしたい
  • 繰り返し実行できるように、composerが既にDL済みのときは何もしたくない (毎回DLするのは無駄なのでやりたくない)

f:id:pinkumohikan:20181015132436p:plain

やりたいことを叶えるMakefile

.PHONY: setup
setup: composer.phar
    # ここにアプリケーションをセットアップするためのアレコレを書く。composer installとか。

composer.phar:
    curl -sSfL -o composer-setup.php https://getcomposer.org/installer
    php composer-setup.php --filename=composer.phar
    rm composer-setup.php

実行例

# 最初はcomposer.pharが無いので、ダウンロードが走る
$ make setup
curl -sSfL -o composer-setup.php https://getcomposer.org/installer
php composer-setup.php --filename=composer.phar
All settings correct for using Composer
Downloading...

Composer (version 1.7.2) successfully installed to: /Users/pinkumohikan/products/jinsoku/composer.phar
Use it: php composer.phar

rm composer-setup.php

# composer.pharが使える状態になる
$ ./composer.phar | head -n 7
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 1.7.2 2018-08-16 16:57:12

# 既にcomposer.pharがあるので、composerのダウンロードは走らない
$ make setup
make: Nothing to be done for `setup'.

Makefileを解説

.PHONY: setup

.PHONY にターゲット名を羅列しておくと同名のファイル/ディレクトリが存在してもターゲットを実行する。逆にいうと、ここに composer.phar を書くと、 make setup を実行すると毎回ダウンロードが走るようになる。

setup: composer.phar

アプリケーションを使える状態にするためのアレコレを書くターゲット。

  • 依存モジュールのインストール
  • コンフィグファイルをテンプレからコピーしておく

など。依存ファイルとして composer.phar を指定しているので、 composer.phar が無ければ先に make composer.phar が実行される。

composer.phar:

composerを composer.phar としてダウンロードする処理を書いている。 .PHONY に指定していないので composer.phar というファイルが無かったら一度だけ実行される。

Introduction - Composer を参考にした。

IntelliJに "ext-json is missing in composer.json" って怒られる理由

PHPプラグインを有効にしている JetBrains IntelliJ を使って、PHP拡張を利用したとある実装をしたとき下記のような警告が出た

ext-json is missing in composer.json

f:id:pinkumohikan:20181012200158p:plain

「ext-jsonって確か組み込みのJSON読み書きモジュールだよなー。足りないはずはないし、なんで警告でるねん!」と思って調べたことをまとめておく

ext-json

ext-jsonは json_encode()json_decode() などを提供する、PHPでJSONを扱うための拡張モジュール

PHP: JSON - Manual

ドキュメントに記載の通り、PHP 5.2以降はデフォルト組み込みとなっているので追加インストールをせずとも利用可能になっている

なぜ警告が出るのか

「エラー調査の基本はグーグル先生に聞く!」

シンプルに ext-json is missing in composer.json というエラーメッセージでググったところ、JetBrainsのドンピシャ記事がヒットした

f:id:pinkumohikan:20181012200723p:plain

PhpStorm 2018.2 EAP 182.3458.35 | The PhpStorm Blog

記事によると、

The inspection detects the usages of functions, constants, and classes from PHP extensions that are not listed in composer.json.

とある通り、新機能としてPHP拡張由来の定数や関数などに依存しているとき composer.json にその依存が明示されていることを検査するらしい

この仕様の根拠としては、Composerの下記の考え方によるものらしい

getcomposer.org

Note: It is important to list PHP extensions your project requires. Not all PHP installations are created equal: some may miss extensions you may consider as standard (such as ext-mysqli which is not installed by default in Fedora/CentOS minimal installation systems). Failure to list required PHP extensions may lead to a bad user experience: Composer will install your package without any errors but it will then fail at run-time. The composer show --platform command lists all PHP extensions available on your system. You may use it to help you compile the list of extensions you use and require. Alternatively you may use third party tools to analyze your project for the list of extensions used.

ざっくり意訳すると

  • 依存しているものを明確にすることって大事だよね
  • PHPと一言で言っても実行環境 (configure option) によって利用可能な拡張モジュールが違うこともあるよね
    • アプリを動かすぞ!って段になって「○○モジュール足りないよ!」ってランタイムエラーになったらキレそうだよね
  • そこんところ、composer.jsonに書いといてくれればアプリの実行前に「これ足りないよ」って警告してあげられるよ

実際、composer.jsonに必要な依存を明記しておくと composer install したときに必要なPHP拡張が入ってなければ「○○が足りへんで!」みたいに怒ってくれるので実行環境を正しく構築出来ているかの確認はやりやすくなる

組み込みPHP拡張も明示しろっていうのは最初は面倒だなとは思うけど、「このPHP拡張はPHP いくつ以降だと組み込みなんだっけ?」とか考えるのも面倒なので "一律全部明記すべし" っていう仕様のほうがシンプルだと言えそう

まとめ

  • Composerは、組み込みを含むすべてのPHP拡張を composer.json で明示するべきと考えている
  • composer.json で明示されたPHP拡張は composer install コマンド実行時に検査され、拡張がインストールされていなければエラーを出してくれる
  • 上述のComposerの考え方に従いって JetBrains PhpStorm 2018.2 EAP build (182.3458.35) 以降、PHP拡張を利用しているのに composer.json で明示されていない場合に警告が表示される

ブログをSSL対応させましたッ

時代はフルSSLなので追従しました

staff.hatenablog.com

SSL化してURL Schemeが変わるとソーシャルブックマークが(はてなブックマーク以外は)リセットされるし、Google Search ConsoleやAnalyticsの設定変更なども必要になってvery 面倒なので腰が重く、着手できていませんでした

が、最近Webエンジニアの知人に「え?まだSSL対応させてないの?」と煽られたのでこの度SSL対応させました(白目)

時代的にも、問答無用でフルSSLがスタンダードですしね

SSL対応手順

下記の通りですんなり行けました

help.hatenablog.com

短時間のダウンタイムが発生

SSL対応の操作を行った直後から5秒程度は、SSL証明書エラーで閲覧できない状態になりました

技術的には、blog.hatenablog.com用の証明書が使われていて、 invalid common name とchomeさんお怒りw

まあでも、ダウンタイム5秒程度なら個人用ブログなら「えいや」で変更できるレベルだと思います

証明書はLet's Encrypt

個人的にもLet's Encryptには大変お世話になっています

f:id:pinkumohikan:20181007050909p:plain

f:id:pinkumohikan:20181007051008p:plain

はてなブログぐらいの規模で1サイトごとに証明書発行しているとLet's Encryptのrate limitに掛かりそうですが、どういう回避方法を取っているんでしょうか。

わたし、気になります。

LumenでCache DriverにRedisを使う

Laravelベースなマイクロフレーム LumenでキャッシュドライバとしてRedisを使おうとしていくつかハマったのでメモ (改めて公式ドキュメントみたら大体書いてたw)。

f:id:pinkumohikan:20180928214447p:plain

必要なこと

  1. Redisを使えるようにする
    • Redisサーバの用意 (割愛)
    • .envREDIS_ 系環境変数を設定
  2. パッケージの追加
    • composer require predis/predis
    • composer require illuminate/redis
  3. RedisServiceProviderの登録
    • bootstrap/app.php$app->register(Illuminate\Redis\RedisServiceProvider::class); を記述
  4. Cacheファサードを使えるようにする
    • bootstrap/app.php 内の $app->withFacades() のコメントアウトを解除
  5. Cache driverを redis へ変える
    • .envCACHE_DRIVER=redis を設定

動作確認

Lumenだとデフォルトではtinkerが使えないので php artisan cache:clear コマンドで代用する。

手順

  1. .envREDIS_HOST を適当に書き換えてコマンドを叩いてエラーがでることを確認
    • Cache driverがRedisになっていることの確認
  2. ↑を正規の情報に戻した上で、コマンドを叩いてみてエラーが出ないことを確認
    • Redisへの疎通とAuthが通っていること (あるいはno-passwordであること) の確認

しっかりやるなら、キャッシュをsetしてgetするようなエンドポイントを用意して、http経由で叩くのが良さそう。

おまけ

参考にした資料