パッケージマネージャからインストールしたLet's Encrypt（Certbot）で証明書の更新をCronで実行する必要はない

まとめ

  • 各Linuxのディストリビューションのパッケージマネージャー（aptとかyumとか）からインストールするとすでに更新処理(certbot renew)はCronで自動化されているため、自前で設定する必要はありません。
  • ただし、HTTPサーバによってはreloadかrestartをしないと証明書の内容が更新されないので、それは自前で行う必要がある。

もうちょっとだけ詳しく

  • 各ディストリビューションでどのバージョンから自動更新処理はがついていることが下記URLにも記載されている。こちらを参照しよう。

certbot.eff.org

  • どこで実行されているかわからんときや、自分の環境では自動化されているかどうかを確認したい場合は、/etc/crontab だったり、 systemctl list-timers でチェックしてみましょう。

実際に利用しているUbuntu18.04では、下記内容がCronにしれっと登録されていた。

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
  • このCronを読んで貰えればわかるけど、証明書の更新はしてくれるが証明書を利用しているHTTPサーバのReloadやRestartはされないので、証明書の再読み込みに必要であればそれは自前で行う必要がある。

思うところ

  • 最近からそうなったんだろなーとは思ったけど、これで理由が理解できた。
  • 殆どの利用ケースではパッケージマネージャ経由でCertbotはインストールしているだろうし、よくわからない人はパッケージマネージャ経由で入れておけという感じです。
  • 思考停止状態でとりあえずでコピペ設定するのはやめよう。設定するならHTTPサーバのReloadだけで十分だし、都合が悪いので自前で叩く場合は、既存のCron設定は止めよう。

なるほどUnixプロセス - Rubyで学ぶUnixの基礎

元々興味があった本で、GW中に読むかーというので、結構短めの本だったのだけど、 ゲームをしながら（Borderlands）読んでいたので、3日位かかった。（なので実質3〜4時間くらいかなぁ。）

tatsu-zine.com

目次では20章あるけどほとんどの章が2−3ページなので、長ったらしい前置きもなくてとても読みやすいし、 写経するコードも基本めちゃくちゃ短いのでホントにサクサク読み進めながら試すことができる。

ファイルディスクリプタ、ゾンビプロセス、コピーオンライト、Preforkなどなど、Unixやプロセスを扱う上で基本的な知識や、 UnicornとResqueがプロセスの観点でどう動いているかの簡単な解説も載っていて、本のタイトル通り、なるほどとなるような内容でした。 とりあえずこれ読んでおくだけでもUnixのプロセスについてよくわかっていない状態から、少しは分かるようになるところまではステップアップできると思っています。

細かい話でいうと、Railsのデプロイタスクでよく使う、 UnicornのGraceful Restart（そもそもなんのシグナルで再起動になるかわかってますか？？そもそもシグナルって？？）で、新しく追加・更新した環境変数が反映されないーみたいなトラブルとか仕様みたいなのがあるけど、 これはこの本を読了した際にどうしてなのかをちゃんと説明することができるようになっていると思う。 （なんか知らんけど Capistranoで stop -> start したらなんか反映されたみたいなのはダサいですよ。）

正直、このボリューム（ページ数という意味）で書籍としては正直少し割高感があると思うんですが、 内容がそれに見合っていると思うのと、ページ数が少ないのは簡潔に説明できている証明であると思うので、買うのを躊躇する理由が金額なら躊躇しないで絶対に買ったほうがいいと思います。

iOSアプリ開発デザインパターン入門を読んだ

会社で電子書籍をシュッと買ってもらえたので、ちょくちょく読んでいたのですが、 GW中に残りを読了したので感想をササッとまとめて書いておきました。

iOSアプリ開発デザインパターン入門 (技術の泉シリーズ（NextPublishing）)

iOSアプリ開発デザインパターン入門 (技術の泉シリーズ（NextPublishing）)

  • デザインパターンというと、この本の中ではオブジェクト指向・プロトコル指向・MVC・MVVMについて説明しているのでたしかにそれらはデザインパターンかもしれないけど、一般認知されているデザインパターンってJavaのGoFデザインパターン本をイメージする人は多いと思うので、ちゃんと目次を見て買いましょうという感じでした。僕はわかってて買ったのでとくに問題がないのでした。

    • デザインパターンではなく、iOS初心者が中級者になるための手引き的な本…？ というのが個人の感想です。（元々別タイトルで出してたけど、商業出版する際にタイトルが変わったのだろうか）

  • 肝心の内容ですが、前述の通り、オブジェクト指向についてのおさらい、プロトコル指向について、Viewや非Storyboard利用時のなどのTipsを中心に割いている章、iOSのMVCのサンプルコードを実践に近い感じで実装する章。MVVMのサンプルコードを「外部ライブラリ依存なし」書いていく。という感じでした。

    • MVCの章が一番良かった。
      • 初心者から中級者の過渡期の中で不安になるのが、「とりあえずMVCで書けると思うけど、行数も多いし、これで正解なんだろうか？」だと思っていて、この章のコードはその点において、不安点を解消する良いお手本、正解コードのひとつと思った。
    • 次のMVVMもとてもわかり易かった。
      • 「ReactiveXX」とか「RxSwift」が「ほぼ必須」な感じがする昨今、これらのライブラリをなしにして説明をしているのが大変良かった。
      • MVVMよりもReactiveXXとかRxの概念説明のほうがとにかく大変そう。

  • 不満点をあげるとするなら、この本だけではないけど、MVCとかMVVMを説明している本でよくあることだとは思うのだけど、MVCとMVVMで同じケースを実装して比較してほしいところがそうではなかった（MVCはタスク管理アプリでMVVMはGitHubクライアントアプリ）ので、単純な比較にならないんじゃないかと思ってて、そこはちょっと不思議に感じている。

    • 両方同じユースケースで実装して、MVCだとこの辺辛いので、MVVMにしようね。とかそういった切り口がないなぁと。
    • DDDとか設計論全般的にそうだけど、少なくとも自分は、成功しているコードや設計だけを見せられても正直なところ実感がないというのがあります。アンチパターン集みたいなのがわかりやすくて好きです。

  • iOS初心者 -> 中級者入門くらいへ向けての本って全然ないと思っていて（Swiftならあるんですよ。）、ちょうどいい感じにこの本が刺さったので大変良かった。似たようなターゲットの本だったり、もっと上級者というか深くダイブしたい人向けの本が技術書典をきっかけにどんどん生まれてくればいいなぁという感じでした。

【WIP】TLS終端サーバーを冗長化するために考えること

TLS終端サーバーのロードバランシングについて

すいません。完全に知識不足でDNSラウンドロビン以外で、冗長化できないとおもっていました。 普通にL4ロードバランサで冗長化できましたね。はい。

説明する前にロードバランサについておさらい

解決策

  • DNSにはL4ロードバランサのIPを指定する。
  • L4ロードバランサからTLS終端サーバー群へロードバランシングしてくれる。

はい、これだけですね。 よくよく考えれば当たり前のことだと思いました。

もちろん当たり前なのですが、SSL証明書をTLS終端サーバー群に対してインストールしておくことが必須になります。

完全に勘違いしていたこと

  • DNSに設定するのはTLS終端サーバーのものを直接指定しなければ行けないと思いこんでた。
    • L7がTCP終端しているのをそもそも理解していなかったことと、L4がTCP終端しないでそのままパケットを流すことを理解していなかった。
      • DNSで設定したロードバランサ上でもうSSL証明書を解決できないと行けないものだとばかり思っていた。
      • L4がそのまま処理を流すのであればDNSが知っているべき宛先としてはL4のロードバランサで問題ない。
      • TLS終端を実際に行う部分でSSL証明書を解決できれば実はOKなのだ。（ここでTCP終端しているわけだから。）

冗長化したTLS終端サーバーの証明書関連の課題

  • とにかく難しいと思っている。（ここから本題感ある。）
    • というか難しいからハードへのリスク承知でSPOFにした記憶
      • そしたら運良く（悪く？）障害を引いた…
      • そもそもクラウドの場合、冗長化しないとSLA保証されない場合があるしねぇ…
  • TLS終端サーバーがすべてのアクセスの起点になっているので、TLS終端サーバーで粗相があるとすべてのアクセスに対して問題が発生してしまうから難しい。

証明書の読み込み

冗長化するし、設定したSSL証明書をどうやってサーバー間で共有するかも課題。 アプリケーションサーバーなんかよりも考えることも多くて大変。

これはいくつか対応策はあるけど、できればインフラ専任エンジニアがいないので、なるべく普遍的な技術スタックでやりたい。。。

シンプルに証明書部分だけをNFSでマウント

  • 必ずこの部分がボトルネックになるので却下。
  • そもそも弊社でSPOFだったTLS終端サーバーに対して、冗長化を少し考え始めたのは、ディスク（インスタンスに対してという意味）破損があったからなので…

ngx_mrubyで証明書を動的読み込み

TLS終端サーバーを自前運用しない

  • AWSだとALB、AzureだとApplication Gateway使えってやつですね。
  • 本当に特別な事情がない限りこれが安心安全。
    • AWSとかAzure自体が駄目だったら、言い方は悪いけど、クラウドベンダーのせいにできる。
    • それで怒られるような規模なら専任にインフラエンジニアいるでしょ。
  • ただし弊社案件では、独自ドメインの証明書を使いたいのと、設定する証明書に上限は設けられないので使えない。
    • 使えるなら絶対に使っている。
    • ALBやApplication Gatewayは1つにつき証明書が20〜25だったと思う。
      • 足らんわっ・・・ まるで・・・

Let’s Encryptでの証明書の取得・更新について

弊社では独自ドメインの証明書をLet’s Encryptを使って取得しているのでそっちの都合で「証明書の取得や更新」について色々考えてみました。

これもさっきのはてなとペパボの記事でLet’s Encryptでの証明書を取得する事例について紹介されているので、 それを見て自分でどう思ったかを簡単にまとめておく。

  • speakerdeck.com
  • speakerdeck.com

  • tech.pepabo.com

  • 独自ドメインのSSL証明書をLet’s Encryptでやる場合、TLS終端サーバーとは疎結合な仕組みにしておくと幸せになれると思った。

    • 例えば、TLS終端サーバー「にだけ」SSL証明書を保存しないようにする。

      • RDBにも保存しておくといいし、念のためにS3にも入れておきましょうなど。
        • しかしこれを実現するためには「SSL証明書取得システム」が必要になる。というかないと厳しい。
        • 「SSL証明書取得システム」はお手軽にシュッと作れるものではないと思ってて、実装コストもまぁまぁ高いと思う。
        • 弊社用途だと、レンタルサーバー屋さんでも大手ブログサービスでもないのでそこまで爆発的に増えることはしばらくないと思うんだけども…

    • TLS終端サーバーの責務は「証明書を名前解決して後続に処理をルーティングさせる」ことだけに集中させるべき。

      • 責務が多いと、ngx_mrubyの処理が多くなって来るし、証明書を取得するのは初回だけ、更新も3ヶ月に1回なので。
      • 更にいうと、サイトによってはEV証明書使いたいので、Let’sEncryptを使いたくないケースも想定されるので、あんまりべったりしているとあとから大変になる。
      • 更新方法を素朴に「TLS終端サーバーでCronを回す」のはお手軽だけど更新漏れに気づけない場合があるし、気づくための実装がとにかく大変。
        • なので上記のようにサービス分割しておくと、実装も楽になるともう。

まとめ

  • TLS終端サーバーの冗長化、とにかく大変そう…😇
  • 弱小スタートアップがサクッと作れるようなスタックがほしい。。。

iOSアプリ（Swift）再入門雑記

業務でiOSアプリ、今どきReactNativeじゃないの？？ なんて思われるわけなんですが、ともかく業務でSwiftでアプリを試しに作ってみるのを初めて1週間が立ちました。 諸先輩方これからどうぞよろしくお願いします。 なにかデカい新しいことを仕事で始めるのはRailsとRubyに入門して以来約3〜4年ぶりくらいで新鮮な気持ちなので、 入門したての新鮮な気持ちを懐かしむために箇条書きで適当に感想書いておこうかなと思っています。

言語など

  • 今までのバックグラウンドが大体動的な言語がほとんどなので、型が便利だと思う半面、書いているときはちょっと面倒さを感じる。
    • Rubyに比べてコードは冗長なんだけど、最初にザクザク書いていけばIDEなのであとから補完されていくので、トータル書いてる時間がすごく増えたとかはないと思う。
    • 型推論が便利

  • 今はSwiftが持っているポテンシャルの10％くらいしか引き出せていないので、Swiftという言語にちゃんと入門する必要がある。

  • やっぱりUIKitとかのドキュメントがわかりにくくて、UITableViewControllerでいつも必要になる三種の神器（Cell個数指定、Cellの中身定義、Cell選択時のコールバック）をいつも忘れてググってQiita見て満足しちゃっている。

    • 翻訳しながらでもいいので、公式ドキュメントの方をちゃんと読んだほうがいいよな。。。という気持ちになってる。
    • しかしまぁ、情報量はRailsに負けないくらい多い。（きっとRails以上だよね。）
  • Storyboardにまだまだ慣れない感じはする。ただ、4年前にやったときよりも理解はできているので手応えは感じる。

ライブラリなどの雑感

  • CocoaPods使ってる。
  • JSのときの学びだけど、あんまりUIデザインにべったり依存する部分のライブラリは入れないようにしている。
  • QiitaでよくUIColorのhexを再実装したりしているけど、そういうことはしないでちゃんとライブラリから探してみるようにしている。

アーキテクチャ

  • 今の所ソロプレイの予定なので、アーキテクチャはどうしようか悩み中。
  • MVPかMVCか。
  • サーバーサイド開発（特にRails）と違ってレールがないので、自分でレールを作る必要がある。
  • 実際に4画面くらい書いた感想は、多分何も工夫しないで実装していくとViewControllerのコードが膨れ上がって死ぬな、これは。。。という気持ちになってる。
  • まず、アーキテクチャよりもSwift自体の気持ちになってコードを書く必要があるかも。それで適切な責務のMVCでも十分イケる可能性もある。
  • ただ、画面遷移を管理するRouterがほしいなという気持ちになってる。
    • たんにUIView -> UIViewへの移り変わりでなく、WebViewの特定のURL -> ネイティブアプリ起動 みたいなことをやりたかったりするので、ライブラリ導入前に捨てる実装前提で、簡易的なRouter書いてみようかなと思っています。
  • 画面遷移しても共有したいObject（ログイン済みユーザーの情報等）があったりするので、雑にXXXXManagerってSingleton作って使ったりしてしまったので、多分勉強が足りないと思っている。
    • せめてデータフローは1方向にしたいな…
  • アーキテクチャを選定するにはアプリケーションコードを全然書いていないので、どんどんプライベートでもアプリ作ったりコードを書いたりしないとヤバイ…と思ってる。
  • これは読んだ。いい本だと思うけど理解が浅い気がしていて、あと半月したらもう1週する peaks.cc

テスト

  • まだ数画面なので書いていない。
  • アーキテクチャをちゃんと決めてから出ないと、どうテスト書くかみたいな戦略が未熟な故作戦が立てれない。

Firebase

  • とにかくモバイル開発に必要な周辺ツールがほぼココに揃っていて便利。最高。
  • とりあえずAnalyticsとかCrashlyticsとかPerformance Monitoringとか突っ込んでおいた。

まとめ

  • ここから半月から約1ヶ月間、プライベートでも含めてコードを書きまくってインプットしていかないとちゃんと書ける気がしないんで、ちゃんと頑張っていこう。。。