気づいたらMongoDBも4.2になっていました。
以前に
DockerでMongoDBのレプリカセットを構築 - Carpe Diem
でレプリケーションを、
でシャーディングを構築しましたが、設定項目が代わっていたりしたので復習がてらdocker上で構築検証しました。
大まかな流れは変わらないため、↑の記事を読んでおくとスムーズに進められます。
| 種類 | レプリカ名 | 台数 |
|---|---|---|
| config | configRepl | 3 |
| mongod shard | shardRepl_1 | 3 |
| mongod shard | shardRepl_2 | 3 |
| mongod shard | shardRepl_3 | 3 |
| mongos | - | 1 |
の計13台です。
続きを読むAbemaTVの合同誌にHashiCorp Vaultについて執筆しました。
基本的にはこの技術ブログで紹介した内容を体系的にして、最新バージョンで改めて動作確認した感じにしています。
初めてHashiCorp Vaultを使う人にとって読みやすくなっていると思います。逆にすでにここの記事を読んでいた人には物足りないと思います(^_^;)
僕以外にも12人もの執筆者が各々の内容で執筆しており、かなりボリュームがある本だと思います。
当日は見本誌もありますので、是非手にとって内容をチェックしてみてください。
以前
こちらの記事で、アプリケーション内でのレイヤ間のエラーハンドリングについてまとめました。
ではマイクロサービス間でそのエラーコードを伝播していくのはどうすれば良いのか、というのが今回の主題です。
gRPCはレスポンスコードを持っています。
しかしこれだけでは下記のようなケースをハンドリングできません。
このような詳細なエラーをクライアントに伝えられない場合、クライアントは抽象的なエラー文言しかユーザに出せず、結果としてユーザは問題を解決することができなくなります。
続きを読むHashiCorp VaultにはCubbyhole Response Wrappingという仕組みが用意されています。
これによってトークンや秘密情報の受け渡し時の漏洩リスクを最小限にします。
人やマシンにトークンを渡す場合、
などの問題点を考慮する必要があります。
また仮に漏洩した場合に
ということを検知する仕組みが必要になります。
Cubbyhole Response Wrappingはそれらを解決する手段です。
HashiCorp VaultにはDynamic Secretsという期限の付いた認証情報を動的に生成してパブリッククラウドやDBへのアクセスをセキュアに保つ仕組みが用意されています。
秘密情報とその周辺の認証を一元化し、適切な暗号化・Auditなどをしっかりしたとしても以下の課題が残っています。
ref: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets
Dynamic Secretsはそれを解決するための手段です。