GCPのIAMを使う上で理解しておくこと - Carpe Diem
背景 IAMはアクセス制御をする上で非常に重要な仕組みですが、一方で複雑になりがちです。 間違った理解のままだと必要以上の権限を与えてしまい、事故の原因となるので押さえておくべき点をいくつかまとめてみます。 リソース階層 GCPのIAMにはリソース階層があり、それぞれの階層を意識した上でIAMポリシーを設定する必要があります。 ref: リソース階層を使用したアクセス制御 | IAM のドキュメント | Google Cloud リソース階層は４つのレベルがあります。 組織レベル フォルダレベル プロジェクトレベル リソースレベル（一部のサービスのみ） IAMポリシーは階層構造になっていて、最終的にリソースで有効なポリシーは、そのリソースに設定されたポリシーとその上位レベルから継承されたポリシーの和となります。 このような考え方はReBAC(Relationship-Based A
継続的プロファイリング - Carpe Diem
背景 過去にいくつかpprofの使い方を紹介しましたが、実際に運用する上では以下の課題があります。 何かしら問題が発生して初めてプロファイリング開始するという後手になりがち 問題の再現が難しく、再び発生するまで様子見という流れになりがち プロファイリングしたことがないメンバーにとってオペレーションコストが高い バージョン比較ができない これらの課題を解決するために、継続的プロファイリング（Continuous Profiling）を導入します。 環境 Go v1.15.2 継続的プロファイリングとは 継続的にpprofのようなプロファイリングを行い、可視化も含め実運用で効果的に活用できるようにすることです。 各パブリッククラウドや監視サービスがすでにサービスとして提供しているので、自前で構築しなくてもそれらを利用できます。 ソリューション 各社が継続的プロファイリングのサポートをしています
Go でサーバレスポンスの内容を表示 - Carpe Diem
概要 開発中にサーバレスポンスの内容を表示したい時があると思いますが クライアントが受け取ったレスポンス サーバが送ったレスポンス のそれぞれをログなどで表示する方法を紹介します。 環境 go 1.14.3 クライアントが受け取ったレスポンスを表示 クライアントでは受け取ったレスポンスはio.ReadCloserです。 なので一度読み込むと以降は読み込めなくなるのでそこだけ注意が必要です。 io.Reader系で実処理ではreadする処理がほぼ必ず入るので、io.TeeReader を使うと良いです。 ref: Goのioパッケージのメソッドを図示 - Carpe Diem io.TeeReaderはreadすると同時にio.Writerの方にストリームデータが流れるので、これをPrintすれば良いです。 今回は標準エラー出力に出します。 コード type Foo struct { Nam
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
