タグ

2022年8月9日のブックマーク (5件)

  • Amazon S3のイベント通知は「稀に失われる」から「少なくとも1回配信」になっていました | DevelopersIO

    こんにちは。サービス部の武田です。Amazon S3 イベント通知は、以前は「稀に失われる」と書かれていましたが現在は「少なくとも1回配信」となっています。ドキュメントの更新履歴を追ってみました。 こんにちは。サービス部の武田です。 AWSではサービスのアップデートなどによって、それまでの常識やベストプラクティスは日々変化します。Amazon S3には イベント通知 という機能があり、オブジェクト作成や削除などをトリガーとして、Lambda関数などを実行できます。 さてこのイベント通知ですが、「たまに抜けることがある」という仕様上の注意がかつて存在しており、頭を抱えた開発者も多いのではないでしょうか。とはいえそれが常識でした。「かつて」と書いたように、実は現在の仕様ではその部分は削除され、代わりに At least once(少なくとも1回配信) となっています。 最近まで知らなかったので

    Amazon S3のイベント通知は「稀に失われる」から「少なくとも1回配信」になっていました | DevelopersIO
  • TerraformモノレポCIのセキュア化 | メルカリエンジニアリング

    記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud PlatformGCP)であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と

    TerraformモノレポCIのセキュア化 | メルカリエンジニアリング
  • 「リーダーの作法」マネジメントに限らず、エンジニアとして仕事の作法について書かれた良書

    2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍

    「リーダーの作法」マネジメントに限らず、エンジニアとして仕事の作法について書かれた良書
  • 高い車に乗って安い車を煽る - ・x・ぼくののうみそ

    高い車が安い車を煽る。これまで何度となく見てきた光景である。昔関越道でスズキのアルトがBMWを追い越し車線でガンガンに煽っているのを見たときには大層アツい気持ちになったものであるが、基的に我々安き車にのりし者は高級車にじゃまだじゃまだと煽られへこへこと頭を下げて道を譲る運命。安きは虐げられる。公道では身分制が未だにまかり通っているのだから。 日だけでなくここアメリカでもやはり高い車は安い車を煽っている。高い車は高圧的で独善的な運転をしがち。たった一度行っただけだが中国の広州でもそうだった。今のところ3か国だが人種のるつぼアメリカをるつぼだけに仮に100か国とカウントした場合、調査N数としてはそれなりであるからこれは万国共通と言っても過言ではない。 俺も高い車には煽られる側、高い車に乗ったことがないので分からないが、高い車に乗ると何か優越感のようなものが高まり、目の間に現れた安い車を煽り

    高い車に乗って安い車を煽る - ・x・ぼくののうみそ
  • Docker/Kubernetes で PID 1 問題を回避する

    はじめにPID 1 問題というのは、コンテナを実行した際にアプリケーションのプロセスが PID 1(プロセス番号が1番)で実行されることで、コンテナに対して SIGTERM などのシグナルを送信してもコンテナ内のプロセスが正常に終了しないというものです。ここでは2020年3月現在でこの PID 1 問題を回避する方法を DockerKubernetes のそれぞれで紹介します。 TL;DRアプリケーションが「明示的にシグナルをハンドリングするようにする」、または「PID 1 で実行されないようにする」の2つの回避策があるアプリケーションプロセスが PID 1 で実行されないようにする場合、Docker では Tini のような軽量 init を使う、もしくは Docker 1.13 以上の場合は docker run の --init オプションを使うで問題を回避できるKuberne

    Docker/Kubernetes で PID 1 問題を回避する