『Effective DevOps』読んだ: DevOpsという文化の作り方
✕✕即時性: コミュニケーションがどれだけ早く成立するかオーディエンスへの浸透度 : オーディエンスにメッセージを届けるためにどれくらい効果的か負担: そのコミュニケーションに参加するための必要な時間と労力コンテキスト: 特定のコミュニケーション方法で必要とされるコンテキストがどれくらいあるか構成の緻密さ: 伝えたいことがどれくらい緻密に構成されていなければいけないか優れたリーダーの条件周囲から最良のものを引き出す 自分自身や少数の「ロックスター」だけを重視してはならない。周りにいるすべてのひとたちから裁量のものを引き出せ優秀な組織とそうでない組織の違いはこの能力の有無で出るメンバー個人のビジョンと企業やチームのビジョンを一致させるように支援する規範たれ リーダーは自分が期待している行動の規範となるべきまわりのひとはリーダーの悪い行動も真似ることがあるので気をつけろクソの傘たれ 上層部から
trivyとGithub Actionsを使用しTerraform設定ファイルのセキュリティスキャンを実行する仕組みを作りました - コネヒト開発者ブログ
この記事はコネヒトアドベントカレンダー21日目の記事です。 コネヒト Advent Calendar 2023って？ コネヒトのエンジニアやデザイナーやPdMがお送りするアドベント カレンダーです。 コネヒトは「家族像」というテーマを取りまく様々な課題の解決を 目指す会社で、 ママの一歩を支えるアプリ「ママリ」などを 運営しています。 adventar.org はじめに コネヒトのプラットフォームグループでインフラ関連を担当している@yosshiです。 今年の7月に入社してから早いもので半年が経ちました。時が経つのは本当に早いですね。 今回のブログでは、セキュリティスキャンツールであるtrivyを使って、自動的にIaC (Infrastructure as Code)スキャンを実行する仕組みを構築した話をしたいと思います。 弊社ではインフラ構成をTerraform利用して管理するようにして
ベストなCDK for Terraform(CDKTF)のディレクトリ構成を探る
最近関わっているプロジェクトでは、大きなアプリケーションのリアーキテクチャを行っています。 そこではフルスクラッチでインフラの構成を書き直す機会がありました。 そのプロジェクトは社内では比較的複雑な構成になっていて、リアーキテクチャにあたっては、アプリケーション特有の事情により、考慮すべきポイントや難度が高いところがたくさんありました。 具体的には、複数のマイクロサービス間の協調性や独立性とそれに付随する認証/認可、クライアント証明書(mTLS認証)の管理、歴史的経緯による複雑性を正すためのawsアカウント移行などなど。 それらは別の機会で語る(or 同僚の誰かが語ってくれることに期待したい)として、この記事ではインフラをフルスクラッチで書き直すにあたって選択したCDKTFについて、紆余曲折を経つつも最終的に採用したディレクトリ構成について書きたいと思います。 タイトルには「ベストな」とあ
GitHub ActionsでZennの下書きをClaudeにレビューしてもらう
はじめに GitHub ActionsとClaude APIを組み合わせて、Zennの下書きをChatGPTライクなAIモデルであるClaudeにレビューしてもらう仕組みを作ってみたので紹介します。 記事を書くときにPull Requestを作る 僕は普段Zennのリポジトリでは特にレビューしてもらったりということがないのですべてmainブランチで運用していましたが、PRでレビューしてもらうにあたって Pull Request を作るように変更しました。 mainブランチに比べてPR作ったりが面倒なので以下のスクリプトで記事の作成・PRを作成します。 #!/usr/bin/env bash set -eux # 記事名と記事slugを対話形式で入力させる read -p "記事名を入力してください: " title read -p "記事slugを入力してください: " slug # 記事
Trivyによるクラウドインフラ設定のセキュリティ検査【インターン参加記】 | PSYENCE:MEDIA
2023年10月23日 (月) から 12月8日 (金) にかけてRECRUIT Internship for Engineers, Data Specialists 2023に参加させていただいた櫛引淳之介です。インターン期間中は『スタディサプリENGLISH』のSREチームに配属され、社内ツール用インフラの構築や、インフラ開発環境のセキュリティに関するタスクに取り組みました。今回は、メインのタスクとして取り組んだインフラのセキュリティ検査ツールの導入について紹介します。 はじめに パブリッククラウドの設定不備は、セキュリティインシデントの原因となります。手作業による確認では見逃しが発生する可能性があるため、設定不備の検知自動化を進める動きがあります。 『スタディサプリENGLISH』ではインフラとしてAWSを使用しており、その設定にはソースコードによってインフラ構成を管理できるIaCツ
プラットフォームエンジニアリングとはモダンな標準化のこと - arclamp
マイクロサービスによって起きた「標準化、死すべき」の揺り戻しとして、イマドキの標準化を実現するのがプラットフォームエンジニアリングなんだろうな、と思っています。JJUG CCC 2023 Fallで「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」という講演をするにあたり、今更ながらプラットフォームエンジニアリングについて整理をしてみました。 クラウドさえあればOpsチームはいらない？ DevOps Topologiesに記載されているDevOps Anti-Typesでは、以下の8つのアンチタイプが記載されています。 A: Dev and Ops Silos B: DevOps Team Silo C: Dev Don't Need Ops D: DevOps as Tools Team E: Rebranded SysAdmin F: Ops Embedd
outage reportを書くときに気をつけていること - その手の平は尻もつかめるさ
そうは言っても障害は起きるものです．で，障害が起きて，終息したあとの振り返りとして社内向けにoutage report (障害報告書的な？) のようなものを書くと思うのですが，本記事ではそのときに気をつけていることについて書きたいと思います。 outage reportの目的 そもそもですが，outage reportを書く目的としては以下のような物があるのかなと思っています。 A: 障害が起きたという事実に関する周知 障害についてお客様からお問い合わせが来たりした時に正しい情報を届けられるようにするため B: 根本原因の洗い出し 再発防止のため C: 障害検知フローの確認 障害に対する初動までにかかる時間を短くするため D: トポロジの形成 知見の醸成 似たような問題が起きたときに，outage reportに書いてある対処法を逆引き的に利用できるようにするため outage repor
バッチ処理のSLOをどう設計するか
TechBrew in 東京 〜バッチ処理 最適化の取り組み〜 https://findy.connpass.com/event/312637/
CodePipeline V2のQUEUEモードをCDKで作って検証してみた
概要 CodePipeline V2が発表されて以降、色々な機能が追加されていっていますが、特にQUEUEモードというものが気になり、検証してみた、という記事になります。 検証してみようと思った日の夜にCDKでQUEUEモード(ExecutionMode)がリリースされてとても嬉しかったです。 CodePipeline V2とは 2023/10：CodePipeline V2が発表 この時点では主に以下の点がアナウンス 入力パラメータをパイプライン実行に動的に渡すことができる V1とV2では料金体系が異なる 2024/02：トリガーフィルターと新しいパイプライン実行モードをサポートすることを発表 トリガーフィルター 特定のディレクトに更新があった場合に実行する等の機能 新しいパイプライン実行モード Parallel Queued CDKでも光の速さで対応される AWS CDK v2.128
TerraformのStateやModuleに関する設計 - tom-256.log
概要 名前付け 抽象度 インフラアーキテクチャ図 チーム 認証情報 変更(デプロイ)のライフサイクル DRYの誤用 コードの検索性 モジュール間の依存 アプリケーションレイヤーとの違い まとめ 概要 TerraformのStateやModuleに関する設計に関する考慮点をざっくり書く 名前付け ユビキタス言語とディレクトリ名や変数名を合わせて認知不可を下げる リソース名でなく役割・機能ベースのディレクトリ名にして認知不可を下げる プロダクトのコードネームはユビキタス言語なのでディレクトリ名にしても問題ない ModuleやStateのREADME.mdを書く https://github.com/terraform-docs/terraform-docs を使う うまく説明が書けない場合は設計に問題がある可能性がある チームメンバーが利用できるように考慮する いつどのようなときに使えばいいか
IaC 提供の難しさ: API で宣言的な管理を実現できるか？という視点 - Diary of a Perpetual Student
Mackerel は Terraform Provider を提供していて、監視ルールや通知チャンネル、ダッシュボードなどの設定が Terraform で記述・管理できるようになっています。 今回は Terraform Provider 提供者の目線から、サービスを IaC で管理できるように対応する難しさを紹介します。 公開 API で宣言的な管理を実現できるか？ Mackerel の Terraform Provider は、内部的に公開 API を呼ぶことで設定の管理を実現しています。よって、公開 API を新たに増やしたり改修したりする場合には、IaC による宣言的な構成・設定管理を API を使って行えるかどうかを気にする必要があります。 具体例: ホワイトリストと、ホワイトリストに自動で追加するフラグの両方を IaC で管理する 例として、やや抽象的な表現にはなってしまいますが
Infrastructure from Code (IfC) ツールまとめ - maybe daily dev notes
昨今Infrastructure from Code (IfC)という概念をよく耳にします。先日もAWSのGregor Hohpeが関連する記事を書いていました。 architectelevator.com この記事では、Infrastructure from Codeとはなにか簡単に紹介し、具体的にどのようなツールがあるか網羅的にまとめます。 Infrastructure from Codeとはなにか Infrastructure from Code (IfC) とは、その名の通り、Infrastructure as Code (IaC) に関連する概念です。IaCとの根本的な違いは、IaCは開発者がインフラを明示的に意識して構成を記述するのに対し、IfCでは開発者がインフラをできるだけ意識しないよう抽象化を試みていることです。これにより、差別化に繋がらない重労働ができる限り排除された高
CDKTFでconfig-driven importを試してみる | DevelopersIO
CDKTF 0.19でconfig-driven importがサポートされたので、試してみました。 CDKTF 0.19 adds support for config-driven import and refactoring config-driven importとは Terraform 1.5で追加された機能です。 従来からTerraformでは、terraform importコマンドで既存リソースをTerraformの構成管理下に置くことができました。 しかし、このコマンドはリソースを1つずつインポートする必要がある・結果をプレビューすることができない等制限もありました。 config-driven importでは、importブロックを利用することで上記の制限をなくし、インポート操作をコードで定義できるようになりました。 import { # ID of the clou
terraform importしてplan差分がない=環境が再現できているといつから錯覚していた？ - Qiita
はじめに 先日、Terraform v1.5.0がリリースされました v1.5の目玉はなんと言っても import ブロックと terraform plan -generate-config-out によるtfファイルの生成ですよね〜。これで既存のリソースもimportし放題だと巷で話題です。 ところで、Terraformの特徴として、「インフラをコード化することで環境が再現できる」などと一般的に謳われています。また、Terraformには「既存リソースをimportする機能」があります。別にそれぞれ単独では間違ってはないのですが、これらを組み合わせて、「既存リソースをimportしてplan差分が出なければ元の環境を再現できる」と言えるのでしょうか？ 残念ながら現実にはそうとも言い切れません。なんとなく経験上わかってる人もいるとは思いますが、意外と気づいてない人も多そうな気がしたので、ち
Google Cloud のマネージド Terraform、 Infrastructure Manager 登場！
こんにちは。クラウドエースの阿部です。 今回はひっそりと一般提供されていた Infrastructure Manager について紹介したいと思います。 Infrastructure Manager とは Infrastructure Manager (以降、Infra Manager と表記) は、 Google Cloud におけるリソースのデプロイや管理を IaC で自動化するためのマネージドサービスです。 内部では Terraform と Cloud Build を使用してリソースの管理を行っています。 Infra Manager の特徴 特徴としては以下の通りです。 GitHub 等と連携した CD (継続的デリバリ) の構築を簡単に実装できます。Cloud Build で同じ事をやる場合は、 cloudbuild.yaml で CI/CD パイプライン設定が必要です。また、ロー
Terraformの状態を可視化するツール、「Pluralith」を試す
Pluralithとは？ プラリスと読むみたいです。 Terraformの状態(state)を可視化するツールです。 こんな感じの図が自動で作成できたり、 コストやリソースの変更を可視化することができます。 GitHub ドキュメント 紹介動画 特徴 pluralith graphを実行するだけで構成図を自動作成可能 CIツールに組み込むことで、ドキュメント・構成図の作成を自動化 最新の変更をハイライトして見やすくする コストの可視化ができる(infracostが必要) リポジトリのREADMEを参照のこと 使ってみる Getting Startedに沿って使ってみましょう。 ※今回はRun Locallyで試しています。 インストール Download CLI手順に従います。 $ pluralith version _ |_)| _ _ |._|_|_ | ||_|| (_||| | |
Terraformのplan結果をChatGPTに説明してもらう機能をCI/CDに組み込んでみた！ - Qiita
背景 インフラエンジニア 「このterraformコードのPR、レビューお願いします。」 インフラエンジニア 「変更点はplan結果↓を見てください。」 An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create ~ update in-place - destroy -/+ destroy and then create replacement Terraform will perform the following actions: # aws_instance.example1 will be created + resource "aws_instance" "example1" { + ami
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
綱渡りバッチ脱出大作戦
Terraform 1.7 から import ブロックで for_each が使えるようになった
Terraform 1.6 で追加されそうな terraform test コマンドを試してみる
