SSL証明書の購入の仕方/2枚目

  • このエントリーをはてなブックマークに追加

1枚目はRapidSSLを買いました。あっちは仕事用で購入したものですが、それとは別に素振りとして個人開発のドメインでも購入したのでした。

前回はKEYとCSRをopensslコマンドで作成しましたが、GoGetSSLではオンラインで生成できます。今回はこのサイトにアカウントを作って購入しました。

それにしても、代理店経由すると割引が凄いので原価が凄い安いんだろうなーと思います。代理店ビジネスって美味しい??

購入するのは、GGSSL Wildcard SSL Certificateです。1年で55㌦。Paypalで支払いました。

購入すると、 Incomplete の状態になるので、そこからウィザード形式でポチポチと情報を入力していきます。また、Online CSR Generatorを使うと、KEYとCSRがメールで送られてきます。あとはいつもの通り、メール認証かドメイン認証を通して完了です。今回もメール認証にしました。

AWSのWorkMailだとお金がかかるので、ValueDomain(Xrea)のWebメールを使いました。このドメインはCloudDNSで管理しているので、MXレコードでXreaのサーバのIPアドレスを指定し、XreaのWebメールアカウントを作ります。(admin@example.com)。
これでメールを受信できます。楽ちん。

もろもろ設定が完了するとこんな感じになります。
証明書がメールで届くので(もしくはここからダウンロードできます)これをGAEで使う場合はそのまま貼り付けます。
SSL証明書/中間証明書/クロスルート証明書が繋がった状態でメールが来ました。

1つ注意点としては、このサイトのOnline CSR Generatorを使ってKEYを生成した場合、GAEに喰わせるときは、以下のコマンドを通したものを貼り付ける必要があります。でないと、「選択した秘密鍵は有効ではないようです。」と怒られてしまいます。

openssl rsa -in example.com.key -out example.com.nopass.key

SSL証明書の購入の仕方

  • このエントリーをはてなブックマークに追加

ワイルドカード証明書を2ドメイン分、別々の場所で購入したのでその手順をメモ。Let’s Encryptは2018年の2月末に提供されるので、これを待っていたのですが急遽必要になってしまったのです。

それぞれ引数に-sha256を入れないとsha1で作られてしまったので指定しました。Macの場合、opensslの設定ファイル(/System/Library/OpenSSL/openssl.cnf)でデフォルトのMDがsha1になっているからです。

grep default_md /System/Library/OpenSSL/openssl.cnf
default_md = sha1 # which md to use.

秘密鍵の作成

暗号化無しで作成。暗号化する場合は-des3を指定します。

openssl genrsa -out example.com.key 2048 -sha256

確認

openssl rsa -noout -text -in example.com.key

証明書署名要求(CSR)の作成

openssl req -new -sha256 -key example.com.key -out example.com.csr

引数で諸々指定すると入力をすっ飛ばせますが、手で入力。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Shibuya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany, Inc.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:*.example.com
Email Address []:admin@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

確認

openssl req -noout -text -in example.com.csr

サイトで購入

これらのファイルを元にこちらのサイトで1枚目を購入。RapidSSLで16800円。1時間以内で発行されました。
ドメインの所有を確認するためにメール認証やファイル認証、ドメイン認証があるようですが、今回はメール認証でadmin@example.comにVerify的なメールが来ました。メール中のリンクをポチッとすると証明書が送られてきます。

メールを受け取るために、AWSのWorkMailを使いました。1ユーザー(メールアカウント)あたり4㌦です。

これをGAEに設定します。

AppEngine -> 設定 -> SSL証明書 -> 新しい証明書をアップロード

注意点としてGAEの場合は、中間証明書も一緒に貼り付ける必要があります。これをやらないと、x509: certificate signed by unknown authority と怒られてしまいます。ブラウザから見ると一見アクセスできているように見えるのが怖いところです。

SSL Checkerで調べましょう。

失敗しているとこのように見えます。

クロスルート証明書も入れたいので、実際には 証明書 中間証明書 クロスルート証明書 の順番で書きます。

もしKEYを暗号化している場合は、こんな感じでパスワードを解除してから貼り付ける必要がありました。

openssl rsa -in example.com.key -out example.com.nopass.key

ドメインにMappingするとこんな感じになります。

参考

コミュニティの一生

  • このエントリーをはてなブックマークに追加

コミュニティの一生という言葉があります。

【コミュニティの一生】
面白い人が面白いことをする

面白いから凡人が集まってくる

住み着いた凡人が居場所を守るために主張し始める

面白い人が見切りをつけて居なくなる

残った凡人が面白くないことをする

面白くないので皆居なくなる

最近はこれを感じる事が多いです。

モチベーションの源泉

私が会社で働くモチベーションの源泉は何だろうと考える事があります。会社はレバレッジをかけて物事を進める場所であり、個人で出来ない事を実現する場所であり、そこでしか出来ない事を求めます。他でも出来るのであれば、別に今に拘る必要はないですね。

とある会社に入ったとき、周りに居た人は自分には持ち合わせていない能力を持っており、皆が自立的に動き、それぞれがプロフェッショナルな仕事をしていました。時が経ち、学生でも書かないような成果物を連日のようにレビューし、定期的にポーリングしなければならず、Giveされる事が当然だという意識が蔓延すると、心も体も消耗していきます。
テックカンパニーではない普通の会社になってしまったのだなと感じます。

一般的な知識の不足が多い状態では話が通じないばかりか、困難な事をクリアしてもそれがどれだけ凄いことなのかを理解して貰えず、幸せを感じる事はできなくなります。質の低い仕事の対応に追われ、シニア人材の戦力を割く毎日が続くと、優秀な人や自立的に動くエンジニアは次々と去って行き、益々魅力の無い環境になってしまいます。

Twitterを見ていると勘違いしそうになるけど、Productionコードが書ける人や一定以上のエンジニアリングが出来る人、上手に仕事を進められる人ってそんなに少ないのかしら。

消耗しすぎて外の人といっぱい話したい。

スクワットチャレンジ再開します

  • このエントリーをはてなブックマークに追加

スクワットチャレンジ再開します。

膝を痛めていたのですが治ったので運動再開。

このアプリを使います。

Runtastic スクワット回数カウント
https://itunes.apple.com/jp/app/id570183002?mt=8

とブログで宣言する事で自分を追い込む。

細かい事を気にする人だなと思った時に振り返る

  • このエントリーをはてなブックマークに追加

誰かに何かをお願いしたとき、「あいつは細かいところを気にするやつだな」と思うときがあると思います。

しかしそれはその人にとって普通のクォリティなのです。普段の仕事でそれくらいの事は凄い短い時間で考え抜いて答えを出していることが殆どです。

では何故細かい所を聞くかと言うと、それは前提となる情報が全然共有されていなかったり、足りていなかったりするからです。当人にとっては当たり前な材料が提供されないので、細かい所を聞かないといけない事になっているのです。それが無いと普段のクォリティにならないのです。

何かを天秤にかけるにも、情報が圧倒的に足りていないので判断ができないのです。

ふと冷静になって、なぜこんな事を聞くのだろうという考えを巡らせれば、相手の普段のクォリティに達する仕事の仕方をしていないと気が付く事もあります。

リハビリ終わりました

  • このエントリーをはてなブックマークに追加

前回、こちらの記事で膝を壊した事を書きましたが、その後のリハビリも終わりました。

いきなりランニングを再開するとまた壊しちゃうのが怖いので、ウォーキングとプールにしようかなと思います。

Jexerとかどうだろう。

Elasticache(Redis)の性能劣化 続報

  • このエントリーをはてなブックマークに追加

Meltdown, Spectreについて、前回の記事 にて、Elasticache(Redis)の性能が劣化した事を書きました。

そして先ほど、AWSのサイトにて次の記事が公開されました。

プロセッサの投機的実行に関する調査の公開について

その中に、

Intel のマイクロコードの修正により、一部のお客様のインスタンスとアプリケーションがクラッシュする問題を確認し、個別に対処させていただいております。当該事象への対処のため、それらの問題が見られる AWS の基盤に対し、マイクロコードの一部の修正を無効化いたしました。全てのインスタンスは引き続き既知の脅威からは保護されております。無効化された Intel のマイクロコードは CVE-2017-5715 による理論的な脅威に対して付加的な保護を提供するものでした。今後、Intel から修正されたマイクロコードが提供され次第、(現在取り組んでいるいくつかのパフォーマンス最適化とともに)これらの付加的な保護を再度適用いたします。

とあります。

Elasticache(Redis)の性能変化を見てみる

次の画像はCPU Usageのグラフです。

緑の線が最初のライブパッチ適用、青が前日、赤が当日。なので時系列的には、緑→青→赤となります。青の線が途中で急に下がっています。マイクロコードを適用したであろう時間帯と合っています。

他のRedisも似たように下がっています。

というわけで、もとの性能に戻りました😊

USB-C 充電アダプタを買いました

  • このエントリーをはてなブックマークに追加

これを友人からオススメされたので買いました。
ケーブルもAnkerのものを。他のケーブルは壊れやすいのですがAnkerのケーブルは全然壊れなくて良いですね。

Nintendo SwitchもUSB-Cなので色々と統一していきたい。寝室に1つ充電用のものを設置しました(`・ω・´)
ついでにモバイルバッテリーも、今使っているものが10年くらい前のものだったので新しく買いました。

dockerコンテナの中からホストとUDP通信する方法

  • このエントリーをはてなブックマークに追加

HostにDatadogが起動していて、Dockerコンテナの中からmetricsを飛ばすためにdogstatdと通信したい。でも、全然出来なくてなんでやねんと思ってたんですが、それは/udpを付けるの忘れていたというオチでした。

--net hostを付けて回避しちゃってましたが、-p 8125:8125/udpで良かった。

それでも、bashで/dev/udp/127.0.0.1/8125に書いても飛ばなかったような気もするけど..
うーん..

ポストモーテム アンチパターン

  • このエントリーをはてなブックマークに追加

先日、友人と飲んだときにポストモーテムの話になって、その時聞いた愚痴が、「あれ..この状況知っているぞ。どこも同じ感じなんだな」と思いを巡らせました。

その時に聞いた愚痴の要約は次の通りである。

  • 以前にも指摘している内容で障害を発生させている
  • 改善策が、基本的に精神論である(レビューを頑張る。もっときちんとチェックする等。)

この前読んだ記事でも似たような事が書かれていて、共感してしまいました。
「ちゃんと考えられない人」につけるクスリはあるのか。

ポストモーテムとは

ポストモーテムとは端的に言えば振り返りである。
レトロスペクティブという場合もあるようですが、ゲーム業界ではポストモーテムと言うことが多い気がしますし、SRE本でもIncidentの振り返りをポストモーテムと言ってます。

とあるオンラインゲームのProjectでは大規模パッチを1年に1回、大型パッチを3ヶ月、小規模な更新は1ヶ月や都度という頻度でリリースしており、大型パッチのリリースに合わせてポストモーテムを開催する事が多かったです。今の会社ではIncidentが発生した時のみポストモーテムをやっていますが、クォーター単位や大きな機能をリリースした単位で行うのが理想だと私は思います。

振り返りをしないとどうなるのか

Incidentの振り返りであれば同じ障害を何度も起こしますし、別の場所で同様のIncidentを発生させます。

Projectの振り返りであれば、スケジュールを毎回守らない人はずっと守らないままですし、何が原因でスケジュールが遅れるのか、見積もりが甘いのであればそれが精緻化される事は無くずっと同じ精度のままです。だらだらやる人はずっとだらだらやりますし、実力が足りない人はずっと実力が足りないまま進行します。
また、悪い点だけではなく良かった点も振り返らないので、そういった内容がチームで共有されずに、チームのボトムラインが上がりません。

アンチパターン

ポストモーテムではやってはいけない事が幾つかあります。ポストモーテムは、良かった点、良くなかった点を洗い出し、次同じ事が発生しないようにする、もしくは発生した時にきちんと対応できるように準備しておくための振り返りです。

今まで体験したもの、伝聞したもので良くないなと思ったものを列挙してみます。

  • そもそも振り返りをやらない(論外ですね)
  • 形だけの開催
  • 人の叱責
    • 何回も同じ事を繰り返していたら叱責する気持ちも分かるけど、それは別の場所でやってください。
  • 良くなかった点を一切議論せずに、次どうやって戦うかの話しかしていない
  • 表面的な要因を根本原因として分析してしまっている(クリティカルシンキングしましょう)
  • 改善策が根本対策ではなく、ただの精神論
  • 本質的に改善しないといけない項目を、しょうがないで片付ける
  • 1ヶ月後や長期連休の後に行う
    • とっくに忘れていて、どうでもよいマインドになっている
  • 解決策のTaskをいつまで経ってもやらない
    • そして次のポストモーテムで同じ事を列挙している

どうやって身につけるか

私はあまりビジネス書を読まないのですが、幸運にも若いときに在籍していたゲーム会社で周りの人に非常に恵まれていたため、よくあるビジネス書に書かれているような事を体現している人がそれなりに居ました。そのため、自然とそれを吸収する事で様々な考えが身に付いた気がします。

またProject兼任が多すぎて上司が片手では数えられないくらいだったので、多種多様な考えが身についたと思います。(そういう考え方の一部を社内Qiitaに公開していますが、あるタイミングでこのBlogにも転載します)

上記で挙げた記事にもありますが、何がきっかけになるかは人それぞれ。大きな障害を起こしても変わらない人は変わらないです。きっかけを与えてもそれがトリガーになるのかどうかは人それぞれなので、目くじら立てずに適度にスルーしていかないと、どんどん空しい気持ちに襲われるだけである。