タグ

ブックマーク / zenn.dev (1,016)

  • 自分が管理する全 OSS の Issue や Pull Request を 1 つの GitHub Project に集約

    2024-07-24 追記: 記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu

    自分が管理する全 OSS の Issue や Pull Request を 1 つの GitHub Project に集約
  • 巷の Terraform Module に違和感を感じたので納得できるものを作ってみた【AWS VPC編】

    今日は最近 Terraform Module に感じていた使いにくさの理由と、その克服方法について AWS VPC を構築しながら整理していきます。 世間で使われる Terraform Module に対する違和感 早速ですが、巷で使われている Terraform Module に対して感じた違和感を挙げていこうと思います。 具体例があるとよりわかりやすいかと思いますので、 terraform-aws-modules/vpc/aws を例に取りながら見ていこうと思います。

    巷の Terraform Module に違和感を感じたので納得できるものを作ってみた【AWS VPC編】
  • RFC 9116 から読み解く正しい security.txt の書き方

    security.txt は非常にシンプルな text/plain ファイルであり、既成のものをコピペして .well-known/security.txt として配置するだけであれば、ものの数分で対応できることでしょう。 また、自動で作成してくれる Web アプリも公式で用意されています。 ですが、例えば「Preferred-Languages に優先順位はあるの?」、「攻撃者によって security.txt が改ざんされたらどうなるの?」といったことは気にならないでしょうか。 私はとても気になります。 というわけで、早速 RFC9116 を読んでいきましょう。 tl;dr はこちら Abstract Section 1 は割愛すると書きましたが、概要にだけは最初に触れておきます。security.txt は第三者であるセキュリティリサーチャーのために書かれたものであり、この RFC

    RFC 9116 から読み解く正しい security.txt の書き方
  • エンジニアを10年以上やって視力2.0を保つ秘訣

    前書き エンジニアを始めて14年、独立して9年経つ。 この仕事を始めた時に「さすがに眼が悪くなるかな」と思ったが、40過ぎていまだに裸眼1.5/2.0だ。(昨年はどっちも2.0。) ↓今年の検査結果(右列が昨年) これはなんなら、始めた時より眼が良くなっている。(始めたころは1.2/1.5だった。) 先日知人のエンジニアと話していると、彼は200人規模のエンジニアを抱える会社でリーダーをしているが「メガネをしてないエンジニアなんて会った事ない」と驚かれた。 実はそこに秘訣があるのでシェアしたい。 ちなみにはこの方法で片目だけだが0.9 → 1.2になった。 結論 「平行法を覚えろ」 これに尽きる。 遺伝の影響か ちなみに自分の親族・家族は実は須らく眼が悪い。 逸話的にも、若くして眼鏡を掛けていた父が、母をお見合いで最初に見た時に、「こいつも眼鏡掛けてる。」「もし子どもが出来ても全員目が悪

    エンジニアを10年以上やって視力2.0を保つ秘訣
  • AWS RDS/Auroraでモニタリング&チューニングを始めるための資料11選

    これはなに ども、レバテック開発部のもりたです。 もりたはデータベースが好きなんですが、最近は特にAWS RDS/Auroraでのモニタリングとパフォーマンスチューニングについて興味があります。ただ、これらのうちモニタリングは扱っている話題が若干ローレベルであまりピンとこず、またチューニングもどこから手をつければいいのかわかりませんでした。 この記事では、もりたがモニタリング&チューニングを学習する上で役に立った書籍やWeb上の資料をロードマップ形式で紹介していきます。対象読者はDBのモニタリングとチューニングをやりたいけどどこから手をつければいいか分かんないなとなっている人、ゴールはそんな人がモニタリング&チューニングの第一歩を踏み出せることです。 スコープ 今回扱うもの、扱わないものは以下の通りです。 扱う モニタリング&チューニングの概要 モニタリングの前提知識 チューニングの前提知

    AWS RDS/Auroraでモニタリング&チューニングを始めるための資料11選
  • Terramateを使えばIaCは豊かになれるのか?

    序論 先日LinkedInで面白そうなIaCツールを紹介してもらいました。 マネージドサービス版はまだクローズドベータで一般利用できませんでしたが、GitHubにCLI版がオープンソースとして公開されておりました。 一見、Terraformの実行を代行するTerragrunt[1]のようなラッパーツールかと思いましたが、Terramateは単なるラッパーツールではなくオーケストレーションツールとしてIaC開発を楽にしてくれるさまざまな機能が提供されていましたので、Terramateを使ったIaC開発について紹介いたします。 対象読者 複数のIaCツールの管理に苦労している人 (後述のハンズオンのため)Terraformの基礎知識がある人 Terramateについて 創業者のブログを見ると2022年5月にリリースされた比較的新しいGo製の開発ツールのようです。 ドキュメントではTerrama

    Terramateを使えばIaCは豊かになれるのか?
  • Terramateで始めるIaC CI/CDパイプライン

    序論 先日IaCをオーケストレーションしてくれるツール、Terramateについて紹介しました。 この時はクイックスタートということでnullリソースを使ってTerramateの動作確認程度のハンズオンを実施しました。 今回は複数のStateファイルで分割され、CI/CDパイプラインの処理に時間がかかるようになったTerraformリソースをTerramateを活用して、変更差分があった場所のみ検知してapplyを実行するCI/CDパイプラインの構築について紹介いたします。 対象読者 Terramateを使ったCI/CDパイプラインの構築に興味がある人 Terraform(OpenTofu)の基礎知識がある人 GitHub Actionsの基礎知識がある人 IaC(Terraform)導入後の課題についておさらい Terramateの概要については私の記事や家ドキュメントを読んでもらえま

    Terramateで始めるIaC CI/CDパイプライン
  • tfcmtのいい感じのテンプレート

    それぞれが折りたたまれていてコメント全体がコンパクト リソースの数が増えてもコメントが縦へ長くなることはありません。 開けばこのように表示されます。 危険な操作(削除・更新)があったときにわかりやすい 削除や更新があった場合は画像のようにその部分だけは折りたたまず表示してくれます。 日語なので読みやすい(日人にとって) いい感じのコメントにするための tfcmt.yml 基的に公式ドキュメントのDefault Configurationを日語化して上記の修正を加えただけです。 なので、もとの英語表記がいいとか、特定の機能だけ取り込みたい、という方は以下と公式のDefault Configurationでdiffを取ると特定の機能だけ取り込みやすいと思います。 embedded_var_names: [] templates: plan_title: "## {{if eq .Exi

    tfcmtのいい感じのテンプレート
  • GitHub Actionsの脅威検知ツール tracee-action を触ってみる

    はじめに こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で番環境での利用は想定されていない点にご注意ください。 This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities. tracee-action tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです

    GitHub Actionsの脅威検知ツール tracee-action を触ってみる
  • 多店舗展開するジムの会員入退室管理を材料費数万円で実現し、24時間営業にした話

    ジムの会員管理システムを作った僕に「エニタイムフィットネスみたいなことがしたい」とジムを家族経営するお客さんから相談された。 「えっ!?会員管理を作ったついでにエニタイムフィットネスみたいな仕組みをやりたい!?予算は無い!?不正防止のため、入退室時の写真も撮りたい?!ログもとりたい!?」 さすが筋トレに明け暮れてるオーナーさんの要望はマッチョだと思った。 普通にやれば電子錠の仕組みや工事やらで一店舗あたり数百万から一千万掛かるような仕組みだろう。 そんな予算無いみたいだし、既存の店舗をそんな大々的に工事もできない。そもそも自分にそんな工事の知識もない。 結果Raspberrypiを使い、それを一店舗予算10万円代で実現、会員カードを他店舗と共有した24時間営業にできた。 その詳しい技術的な内訳を共有する。 (なお執筆時点では2024年だが、これ自体は5年前、2019年の仕事である。) 前提

    多店舗展開するジムの会員入退室管理を材料費数万円で実現し、24時間営業にした話
  • ログラスのTerraform構成とリファクタリングツールの紹介

    この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 47週目の記事です! 1年間連続達成まで 残り 6 週 となりました! はじめに ログラスのクラウド基盤でエンジニアをやっているゲイン🐰です。 ログラスではAWS上でアプリケーションを動かすためにIaCとしてTerraformを採用しています。 我々のTerraformの構成を紹介するとともに、現状の課題とリファクタリングの事例を共有できれば幸いです。 ログラスのTerraform構成 ざっくりログラスのアプリケーションにまつわるTerraform構成は以下のようになっています。 基的にはterraform/usecaseディレクトリ配下にmoduleとして定義されています。 中身は比較的にベタでリソースが書かれており、それらをterraform/envディレクトリの各ディレクトリ内で呼

    ログラスのTerraform構成とリファクタリングツールの紹介
  • terraform importで数年やってきたがImport blockの良さに気づきました

    こんにちは。イオンスマートテクノロジー株式会社(AST)でSREチームの林 aka もりはやです。 Terraformを一定以上扱ってきた方であれば terraform import コマンドを苦労しながら実行した経験があるのではないでしょうか。私自身も5年以上Terraformを扱う中で何度も terraform import を行ってきました。 一般的に terraform import では以下を行います。 実態に合わせてコードを整える 実態を指定するコマンドを組み立てる ステートファイルに取り込む 差分が出たら地道にコードを整えて terraform plan を実行する 4を繰り返して"No changes"となるまでチューニングする これらの作業はTerraform初見では難しく、個人的にTerraform中級者への登竜門として terraform import が試金石のひと

    terraform importで数年やってきたがImport blockの良さに気づきました
  • Fluent Bit の低レイヤーに飛び込んでみて、わかったこと

    こんにちは! シェルフィー株式会社で SRE を担当している石田です。 弊社では、番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ(Fluent Bit)を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa

    Fluent Bit の低レイヤーに飛び込んでみて、わかったこと
  • AWS VPC接続方法によるレイテンシ(VPC Peering vs TGW)

    TL;DR VPC間を接続した際のレイテンシはTGW > VPC Peering TGWでVPC間を接続すると、VPC PeeringでVPC間を接続した場合と比較して、レイテンシが10倍以上!! はじめに いきなりですが、皆さんは以下のような2つのVPC間を接続する際、どの様な方法で接続するでしょうか?(オレンジ矢印部分) 前提や要件により様々な接続方法が考えられますが、AWS公式:Amazon VPC-to-Amazon VPC connectivity optionsには、VPC間を接続する際の選択肢については以下5つが挙げられています。 VPC Peering Transit Gateway(TGW) AWS PrivateLink Software VPN Software VPN-to-AWS Site-to-Site VPN AWS公式ドキュメントには選択肢として記載されてい

    AWS VPC接続方法によるレイテンシ(VPC Peering vs TGW)
  • マイクロサービス間通信における認証認可およびアクセス制御

    はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで

    マイクロサービス間通信における認証認可およびアクセス制御
  • [提案]テーブル名はもう全部単数形にしようや

    こんにちは、データベース愛好家のみなさん!今日は、データベース設計で永遠の議論となっている「テーブル名、単数形 vs 複数形問題」について、徹底的に掘り下げていきます。私は単数形派です!でも、なぜそうなのか、一緒に深掘りしていきましょう。 イントロダクション:我らが主人公、単数形くん みなさん、こんな経験ありませんか? You: テーブル名って、users? user? どっちがいいんだろう... 先輩: いや、絶対usersだよ!Rails使ってるし。 You: でも、user_idって書くときは単数形だよね? 先輩: あ、そうだね...でもやっぱりテーブルは複数形! You: (心の中で)なんかモヤモヤする... 実は、この「モヤモヤ」には理由があるんです。今日はその理由を解き明かし、単数形テーブル名の魅力をお伝えします。準備はいいですか?Let's dive in! 言語の壁を突破せ

    [提案]テーブル名はもう全部単数形にしようや
  • サイバーセキュリティチーム立ち上げにあたり考えたこと

    前回のブログ冒頭で記載した通り、弊社では今年からサイバーセキュリティチームを立ち上げました。今回はチーム立ち上げにあたって考えたことを共有します。 目指す姿〈Vision〉 目についた課題に対処するだけでは中長期的な成長は望めません。チームとして目指すべき到達点、Visionが抽象的なレベルでもあると、活動の軸になりますし、チームとして自分たちが前進していることを実感できると思います。 では、どういったVisionがよいか。当チームでは、『The Sliding Scale of Cyber Security』[1]を採用しました。このモデルではサイバーセキュリティの防御態勢を大きく5段階で表現しており、チームとして目指すべき姿を認識するうえで良いモデルだなと感じています。当社では少しだけ表現を変え[2]、下の絵のようにしました。 このうち、Offenceは事業会社としてはNGですので、そ

    サイバーセキュリティチーム立ち上げにあたり考えたこと
  • Webサービス公開前のチェックリスト

    個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

    Webサービス公開前のチェックリスト
  • 暗号化に対応した次世代dotenvツールdotenvxを使う

    特に一番最後の暗号化サポートは非常に嬉しい進化です。dotenv単体で環境変数を運用すると、秘匿情報が含まれたdotenvファイル自体の管理に困ることや、デプロイする際にどうやって環境変数を提供するかが課題になることがありました。 現代ではクラウドプラットフォーム上にシークレットマネージャーのような仕組みが用意され、そこで中央管理するというのが一般的になっているかと思います。ただ、それだと変数のバージョン管理やレビューの仕組みを別途用意しないといけなかったりと完全ではありません(個人的主観です)。 dotenvファイル自体が暗号化され、Gitでバージョン管理でき、そのままデプロイして環境変数を適用できたら運用の手間が一気に減ります。

    暗号化に対応した次世代dotenvツールdotenvxを使う
  • 順序性の担保とスループットはトレードオフだという話

    この記事について AWS SQSからメッセージを受けとって処理するLambdaを書いているときに、 標準キューだから順序保証されてないな、じゃあ順序バラバラできても捌けるように処理を書かないと! → ... → あれ???意外とこれ難しくない??? と思った経験、皆さんにもあるのではないでしょうか。 この記事では、筆者が上記のような壁にぶつかったときに「順序を保つってなんでそんなに難しいんだろう?」「保てないならどうやってそれに耐えうるようにすればいいんだろう?」と色々考察した結果を書いていきたいと思います。 使用する環境・バージョン 2024/6/22時点で提供されている機能に基づき考察 読者に要求する前提知識 AWSのSQS, SNS, Kinesis Data Streamがどういうサービスなのかは既知という前提のもとで書きました 順序セマンティクスとは 順序セマンティクスとは「イベ

    順序性の担保とスループットはトレードオフだという話