タグ

2020年5月27日のブックマーク (9件)

  • AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!

    はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント(ルートユーザー)の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ

    AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
    suu-g
    suu-g 2020/05/27
  • コンテナ仮想、その裏側 〜user namespaceとrootlessコンテナ〜 - Retrieva TECH BLOG

    レトリバのCTO 武井です。 やあ (´・ω・`) うん、「また」コンテナの記事なんだ。済まない。 技術ブログの開設と新セミナー運用の開始にあたって、「前に話した内容をブログにしつつ、新しい差分をセミナーにすれば、一回の調べ物でどっちのネタもできて一石二鳥じゃないか」と思っていたのですが、 前のセミナーが情報詰め込みすぎでブログの文量がとんでもないことになって、 → それが前提条件になってしまっているのでセミナー資料の文量も膨れ上がって、 → 差分だけと思っていたUser名前空間も思った以上のボリュームで、 → やっと一息かと思ったら、フォローアップ記事が残っていることを思い出すなど ←いまここ 一石二鳥作戦のはずが、どうしてこうなった……。 計画大事。 そんなわけで、今回は4/17にお話ししました「コンテナ仮想、その裏側 〜user namespaceとrootlessコンテナ〜」という

    コンテナ仮想、その裏側 〜user namespaceとrootlessコンテナ〜 - Retrieva TECH BLOG
  • SECCON Beginners CTF 2020の監視・オペレーションを支える技術 - ポン酢ブログ(β)

    LifeMemoryTeamの@atponsです。今回のSECCON Beginners CTF 2020はお楽しみいただけたでしょうか。自分は運営やインフラ整備をしておりました。 今回は、自分が担当していた監視、オペレーション部分の構築回りについて書いておきます。 死活監視 バッジ 今回参加者のみなさんには、このようなバッジを問題に付与して提供しておりました。これによって、問い合わせのオペレーションを削減することを目標に、昨年も取り組んでおりました。バッジでは、そのタスク(問題からフラグを取れたかどうか、サービスに疎通できるかどうか)の成功可否を表示していました。 また、最後にタスクを実行した時間を表示できるようにしていました。このバッジ生成は完全に自作したものです。詳細は死活監視の部分で書きます。 タスクランナー 定期的に実行してその状態を知りたい、という要望にはCI/CDツールを応用

    SECCON Beginners CTF 2020の監視・オペレーションを支える技術 - ポン酢ブログ(β)
  • package.json やロックファイルによるパッケージの依存関係の管理 - 30歳からのプログラミング

    この記事では、npm installやnpm ciを実行したときにどのようにパッケージがインストールされるのか、依存パッケージにバージョンのコンフリクトが発生した際にどのように処理されるのか、などを見ていく。必要に応じて Yarn での挙動にも触れる。 動作確認に使った npm のバージョンは6.14.5。Yarn は1.22.4。 特に npm はバージョンによって動作が大きく異なるので、注意する。 package-lock.json によるバージョンの固定 package.jsonだけではインストールするパッケージのバージョンを固定できず、package-lock.json(Yarn の場合はyarn.lock)によってバージョンを固定する。 多くの人が知っている話ではあるが、重要な機能なので改めて触れておく。 package.jsonのdependenciesやdevDependen

    package.json やロックファイルによるパッケージの依存関係の管理 - 30歳からのプログラミング
  • オブザーバビリティ(可観測性)とは何か?を学べる「Distributed Systems Observability」を読んだ - kakakakakku blog

    2019年頃から「オブザーバビリティ (Observability)」もしくは「可観測性」という言葉をよく聞くようになった(記事では「オブザーバビリティ」という表記に統一する).「マイクロサービス」と同じように「バズワード」の側面があり「オブザーバビリティとは何か?」という質問に対して様々な回答が考えられると思う. 今回は「オブザーバビリティ」の理解を深めるために「Distributed Systems Observability」を読んだ.書は O'Reilly Media で読むこともできるけど,Humio のサイトから無料でダウンロードすることもできる(メールアドレス登録は必要).著者は Cindy Sridharan となり,肩書は「Distributed Systems Engineer」と書いてあった. www.humio.com 目次 書には「オブザーバビリティ」をテー

    オブザーバビリティ(可観測性)とは何か?を学べる「Distributed Systems Observability」を読んだ - kakakakakku blog
  • eBPFを用いたトレーシングについて

    2020/5/25(月)、さくらの夕べ Tech Night #1 Onlineでの発表ですRead less

    eBPFを用いたトレーシングについて
    suu-g
    suu-g 2020/05/27
  • Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita

    はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと(テクニカルライティングとも言います)は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

    Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
  • 夕会, Discord, ワーキングアグリーメント - フルリモートワークになって以降チームに取り入れたもの - だいくしー(@daiksy)のはてなブログ

    チーム全員フルリモートワークになって間も無く2ヶ月になろうとしている。 この傾向そのものは今後段階的に弱まっていくだろうが、リモートワークの取り組みは以前よりも促進されていくのだろう。 元々自分のチームは新しい取り組みに前向きなチームで、いろいろなチャレンジをこれまでにもやってきたが、この2ヶ月はさらにハイペースで様々なチャレンジを行ってきた。この2ヶ月を振り返って、その取り組みを書いておこうと思う。 夕会を新しく導入 チームではこれまで、昼の休み時間明けにデイリースクラムを担う昼会をやっていたが、これに就業時間直前の30分の夕会を取り入れた。 任意参加で、雑談をするための会。毎日時間になるとSlackにチャンネルにGoogle MeetのURLが流れてくる。 オフィスワークがゼロになり、これまでオフィスに集っているメンバー同士の雑談がなくなったことを補うのが目的。 ただ、これまでにも同様

    夕会, Discord, ワーキングアグリーメント - フルリモートワークになって以降チームに取り入れたもの - だいくしー(@daiksy)のはてなブログ
    suu-g
    suu-g 2020/05/27
    ワーキングアグリーメントの視点はなかったのでメモ
  • cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成

    cmd.exe の引数の扱いがあまりにもカオスだったのでちょっと頑張って調べてみた。 来ならここは公式の資料に当たるのが正しいアプローチだと思うけど、どうしても公式の資料が見つからなかったので、色々試して推測してみることに。 断片的な資料は見付けたけど、完全じゃない。一応URL貼っておく。Windows Server 2003 のヘルプだけど、恐らくそんなに変わらないと思う。 コマンド シェルの概要 コマンド リダイレクト演算子を使用する なので、以下で述べる内容は間違いを含む可能性があります。というか正確さは一切保証されないのであしからず。 検証方法 以下のような引数をただ表示するだけの簡単な C のプログラムを用意した。仮に args.exe とでもしておく。 #include <stdio.h> int main(int argc, char const* argv[]) { in

    cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成