ercan.cloud

AWSのエージェント認証: OIDCイン、アクセスキーアウト

Tue, 21 Jul 2026 01:00:00 +0200

AWS上で、またはAWSに対して動くエージェントは、長期の認証情報を一切持つべきではない。 IAMユーザーも、シークレットマネージャーに置いたアクセスキーも、共有の「agents」サービスアカウントも駄目だ。AWSが提供する本格的な認証経路、インスタンスプロファイル、IRSA、EKS Pod Identity、OIDCフェデレーション、IAM Roles Anywhere、AgentCore Identityは、どれも同じことをするために存在する: 検証可能なアイデンティティの証明を、自動的に失効する一時認証情報と交換することだ。エージェントプラットフォームをこのルールから始めれば、難問の大半はひとりでに解ける。

昨日、姉妹サイトでこの問題のプロトコル層について書いた: SEP-1046がMCPエージェントに本物のクライアントクレデンシャルの仕組みを与えるという話で、署名付きJWTアサーションが共有シークレットを置き換える。本稿はその一段下の層だ。エージェントの対象がAWSそのものである場合、あるいはエージェントがAWS上で動いて他のすべてに到達する必要がある場合、そのアイデンティティは実際どういう形になるのか。答えはほぼすべてのケースで、SEP-1046が選んだのと同じ形をしている: 短命の署名付きトークンを入れると、短命の認証情報が出てくる。AWSはこのパターンを何年も大規模に運用してきた。静的キーでそれに逆らうのをやめればいいだけだ。

すべての土台にある一つのパターン: OIDCフェデレーション

製品名を剥がせば、AWSのエージェント認証は一つのメカニズムだ。アイデンティティプロバイダーがワークロードについてのJWTに署名する。そのプロバイダーのissuer URLをIAMにOIDCアイデンティティプロバイダーとして登録すると、IAMは/.well-known/openid-configurationのディスカバリードキュメント経由でプロバイダーのjwks_uriから公開鍵を取得する。ワークロードはトークンをsts:AssumeRoleWithWebIdentityに提示し、1時間以内に失効するロール認証情報を得る。ロールの信頼ポリシーは、トークンのaudとsubクレームへの条件で、誰を入れるかを固定する。

プラットフォームチームなら誰もが知っている実例がGitHub Actionsだ: ランナーはsubクレームにリポジトリとブランチをエンコードしたOIDCトークンを受け取り、ロールの信頼ポリシーはrepo:my-org/my-repo:ref:refs/heads/mainにマッチし、リポジトリシークレットにアクセスキーは一切置かれない。これはCIの小技ではない。エージェントを含む、あらゆる無人ワークロードの雛形だ。署名付きでaudienceに束縛され、数分で失効するアサーションが保存済みシークレットを置き換える。これはまさにMCP層でprivate_key_jwtがやっていることで、業界が二つの方向から同じ答えに収束したときは、たいていその答えが正しいというサインだ。

エージェントがどこで動くかがメカニズムを決める

フェデレーションを自前で組むことはめったにない。ランタイムに合ったパッケージングを選ぶ:

EC2またはECS上: インスタンスプロファイルまたはタスクロール。SDKのクレデンシャルチェーンが自動的に拾うので、エージェント側で設定するものはない。ここでエージェントフレームワークがアクセスキーを要求するなら、それはフレームワークの悪臭であって、AWSの要件ではない。
EKS上: 選択肢は二つ。IRSA (IAM Roles for Service Accounts)が古い方だ: クラスターがOIDC issuerを公開し、それをIAMに登録して、ServiceAccountにロールARNをアノテーションする。EKS Pod Identityが新しい方だ: クラスターごとのOIDCプロバイダー登録は不要で、ノード上のエージェントアドオンが認証情報を交換し、ロールの信頼ポリシーはクラスターごとのissuer URLではなくpods.eks.amazonaws.comを一度だけ指定する。クラスターを多数運用しているならPod Identityは実際の手間を減らす。単一クラスターならどちらでもいい。どちらも行き着く先は同じだ: エージェントワークロードごとに一つのIAMロール、Podにキーなし。
AWS外でIdPあり: 上記のとおりの素のOIDCフェデレーション。データセンターのワークロードも、別のクラウドも、SaaSのランナーも、自前のアイデンティティプロバイダーに認証してフェデレーションで入ってくる。GitHub Actionsパターンの一般化だ。
AWS外でIdPなし: IAM Roles Anywhere。信頼アンカーとして登録したCA (AWS Private CAまたは自前のPKI)が発行したX.509証明書をワークロードが提示し、プロファイル経由で一時的なロール認証情報と交換する。正直な注意点: 証明書のライフサイクル管理、発行、ローテーション、失効を抱え込むことになる。すでにPKIを運用していないなら、アイデンティティプロバイダーを立てる方が運用負荷はたいてい軽い。

AgentCore Identity: その上に載るエージェント向けの層

IAMが答えるのは「このワークロードはどうやってAWSを呼ぶか」だ。エージェントにはあと二つ問題がある: 誰がエージェント自体を呼べるのか、そしてエージェントがユーザーの代理でAWS外のサービス、Slack、GitHub、Googleにどう到達するのか。Amazon Bedrock AgentCore Identityがカバーするのはこの部分で、AgentCoreを使わない場合でも理解する価値がある。ロールの先にエージェントのアイデンティティへ何が必要かを、AWS自身が書き下したものだからだ。

エージェントのワークロードアイデンティティ。 各エージェントは共有プリンシパルではなく、自分専用のディレクトリエントリを持つ。IAMロールと同じ、ワークロードごとに一つのアイデンティティというルールを一段上に適用したものだ。
インバウンド認証。 呼び出し側は素のSigV4 (通常どおりのIAM)か、JWTオーソライザー経由でエージェントに到達する: ディスカバリーURLと許可するaudienceを設定すると、Cognito、Okta、Entra IDのトークンがエージェントの入口を守る。AgentCore Gatewayはツールエンドポイント向けにも同じCUSTOM_JWTオーソライザーを公開しており、前回の記事で発行の話をしたトークンを、AWS上のMCP的なゲートウェイはこうやって検証する。
アウトバウンド認証。 トークンボールトがサードパーティサービス向けのOAuthグラントを保持する。サービス間は2-legged、ユーザーが一度同意し、その同意に基づいてエージェントが後から代理で動く場合は3-leggedだ。これは代理実行パターンで、同意が環境変数に貼り付けたリフレッシュトークンではなく、サーバー側に保存される。
料金の補足。 AgentCore RuntimeまたはGateway経由なら追加費用はゼロ。単体利用では、成功したOAuthトークンまたはAPIキーのリクエストごとに課金される。どちらにせよ安い。高くつくのはいつだって、これで回避できるインシデントの方だ。

この上のプロトコル層も動き続けている。MCP仕様リポジトリのauthキューには、ゲートウェイが1年以内に出会うことになる提案が並んでいる。混在認証サーバー向けのツールメタデータのsecuritySchemes(SEP-1488)、セッション途中でOAuthフローを起動する標準化されたツールエラー(SEP-1489)、リモートサーバーの認証方式の事前宣言(SEP-2742)。AWSでMCPゲートウェイを運用しているなら、EKSのリリースノートを見るのと同じ目でこのラベルを見ておくべきだ。

監査で実際に問われるのはアトリビューション

一時認証情報は盗難の問題を解決するが、それだけでは「どのエージェントがやったのか」は解決しない。三つの習慣がその穴を塞ぐ。エージェントごとに一つのロール。これでCloudTrailのロールセッションが最初からワークロードを名指しする。ロール引き受け時のsts:SourceIdentityの設定。これでエージェントを起動した人間またはシステムが、ロールチェーンをまたいでも下流のすべてのログ行に残る。そしてセッションポリシーで広いロールを目の前のタスクに絞り込む。これでプロンプトインジェクションを受けた、あるいは単に間違えたエージェントの爆発半径は、ロールの権限ではなくタスクの権限になる。常設の権限は読み取り専用に保ち、すべての変更操作にゲートを置くこと。この主張は何度も書いてきたので、常連の読者なら暗唱できるはずだ。

Agent Toolkit for AWS: ドキュメントに新しい読者がやってきた

Mon, 20 Jul 2026 09:30:00 +0200

AWSは今週、コンソールに新しいカードを追加しました: Agent Toolkit for AWSです。無料で一般提供されており、Claude Code、Codex、Cursor、Kiroで動作します。セットアップ用のプロンプトを1つ渡すだけで、コーディングエージェントはAWS API向けのMCPサーバー、よくあるタスク向けの厳選されたスキル、そしてIAMガードレールを手に入れます。ツールキット自体も有用ですが、それが認めている事実の方が大きいのです: AWSドキュメントの主な読者は、もはや人間ではありません。

箱の中身

3つのレイヤーがあり、それぞれ独立して動作します:

AWS MCP Server。エージェントがmcp-proxy-for-aws経由で到達するホスト型エンドポイント(aws-mcp.us-east-1.api.aws)です。エージェントにAWS APIへのアクセス、サンドボックス化されたスクリプト実行、リアルタイムのドキュメント検索を提供します。認証情報が必要なのはAPI呼び出しだけで、ドキュメント検索は認証なしで動作します。
プラグイン。aws-coreはサービス選定、CDKとCloudFormation、サーバーレス、コンテナ、ストレージ、オブザーバビリティ、請求をカバーします。aws-agentsはBedrockとAgentCoreのスキルを追加し、aws-data-analyticsとaws-agents-for-devsecopsはそれぞれの領域を受け持ちます。Claude Codeなら公式プラグインマーケットプレイスから/plugin install一発でインストールできます。
スキル。npx skills add aws/agent-toolkit-for-aws/skillsでインストールする、厳選されたタスク手順です。オンデマンドで読み込まれ、エージェントは現在のタスクに合致するものだけを取り込むため、使うまでコストはかかりません。

認証は新しいブラウザベースのaws loginフローで行い、aws sts get-caller-identityで検証します。ターミナル中心で作業しているなら、aws configure agent-toolkitがAWS CLI経由で同じ構成を組み上げてくれます。

セットアップはスクリプトではなくプロンプト

ここに立ち止まる価値のあるディテールがあります。コンソールはシェルスクリプトを渡してきません。エージェントに貼り付けるための一文を渡してくるのです:

Set up Agent Toolkit for AWS by following instructions:
https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md

このURLの先にあるのはMarkdownファイルです。エージェントがそれを読み、OSを検出し、AWS CLIがなければインストールし、aws loginを実行し、MCPサーバーを設定し、スキルをインストールします。この文書は機械向けのランブックとして構成されています: 番号付きの手順、エラーハンドリングの表、各段階の後の検証コマンド。AWSは、想定読者があなたではないインストールガイドを書いたのです。あなたの仕事は権限プロンプトを承認することだけです。

注目すべきパターンはここです。インストール手順はかつて、コピーするためのコードブロックを添えた人間向けの散文でした。これは、人間が一度流し読みするだけの散文を添えた、エージェント向けのコードです。

もう誰もドキュメントを読まない、エージェントを除いて

白状します。長年、私の週末の読み物は推理小説でもフィクションでもなく、AWSドキュメントでした: サービスクォータ、APIのエッジケース、誰も話題にしないストレージクラスの変更履歴。その読書が頭の中の索引を作り、私を速くしてくれました。答えがどこにあるかを知っていることが、仕事の大半だったからです。

その索引は今やコモディティです。ドキュメント検索を備えたエージェントは、私が2年前に暗記したページではなく現行のページを読み、しかも数秒で読み終えます。ツールキットはこれを公式なものにしました: AWSは今や、自社ドキュメントを機械に供給する専用パイプラインを維持し、「最新のドキュメントと検証済みの手順」を目玉機能として掲げています。ドキュメントチームの最重要顧客は、種が変わったのです。

コモディティにならないのは判断力です。どのサービスが適切か、変更のブラストラディウスはどこまで及ぶか、エージェントの計画があなたのアカウントの現実に触れても生き残るか。AWS自身の売り文句にガードレールという言葉が入っている理由はそこにあります: 有効な認証情報を持つエージェントは他と変わらない1つのプリンシパルであり、他と同じく最小権限が適用されるべきです。この点について、実務上の注意を2つ:

プロキシのバージョンを固定しましょう(mcp-proxy-for-aws@1.6.3のような形式)。AWS自身のREADMEもサプライチェーンリスク対策として推奨しており、これは正しい判断です。
エージェントのロールはデフォルトで読み取り専用にスコープし、変更を伴う経路はすべて個別にゲートしましょう。ツールキットのIAMガードレールは助けになりますが、ポリシーを書くのは依然としてあなたです。

まとめ

AWS開発のエージェント時代は、基調講演とともに到来したのではありません。セットアッププロンプトを差し出す、コンソールの小さなカードとして到来しました。AWSは今や、どのプロジェクトでも最初の協働者はエージェントだと想定し、その読者のために作られたドキュメント、手順、権限境界を出荷しています。私の週末にも、ようやく探偵小説の居場所ができるかもしれません。ドキュメントは良い手に委ねられました。そして、何を作るか、エージェントに何を触らせるかを決めるという面白い仕事は、そもそも索引化できない部分だったのです。

次に読む

IaC First: Why We Never Touch the AWS Console in Production: 同じ方向への進化です。コンソールは読み取り専用の窓になり、すべての変更はコードを経由します。
Agents on Call, Part 4. Tools and the Gateway: MCP, Allowlists, Read-Only Default(ercan.ai): エージェントの最小権限を、既製品を入れるのではなく自分で組むとどうなるかを扱っています。

FinOps: 次の25億ドルのAWS請求書が届く前にTerraformで予算アラートを

Fri, 17 Jul 2026 18:00:00 +0200

7月17日、AWS Cost Explorer は推定請求額として数百万ドル、数十億ドル、一部のスクリーンショットでは数兆ドルという数字を表示した。数字は誤りで、実際に課金された人はおらず、AWS は1日以内にデータを修正した。ここで覚えておく価値があるのは、最初に異変に気づいたのが請求アラートを設定していた人たちだった、という点だ。本記事では Terraform の aws_budgets_budget を使った予算アラート設定の基礎を、単純な月次コストアラートから使用量ベースの予算、Savings Plan の利用率トラッキングまで順に解説する。

あの朝 LinkedIn や X を開いた人は、みな同じフィードを目にした。一部の国家予算より桁数の多い AWS 請求見積もりのスクリーンショットだ。前月の支払いが 0.19 ドルだったユーザーには約 25 億ドルの見積もりが表示され、最大 2.5 兆ドルという数字を投稿した人もいた。

何が起きたのか

太平洋時間の午前1時33分、AWS は Health Dashboard に、Cost Explorer が "reflecting inaccurate estimated billing data"(不正確な推定請求データを表示している)と投稿した。根本原因は AWS の言葉を借りれば "an issue with unit pricing within the estimated billing computation subsystem"(推定請求計算サブシステム内の単価に関する問題)だった。要点は次のとおり。

数字は推定値であり、実際の使用量や請求額ではなかった。
課金された顧客はおらず、顧客側の対応も不要だった。
AWS がデータをバックフィルし、7月18日には数字は正常に戻った。

興味深いのはここからだ。多くの人はこのバグを請求しきい値超過のメールで知った。アラートを設定していたアカウントは数分以内に異常を検知した。設定していなかったアカウントはソーシャルメディアで知るか、あるいは気づかないままだった。

今回は誤報だった。しかし、消し忘れた NAT Gateway、リトライループに陥った Lambda、漏洩したアクセスキーが生む請求は紛れもなく本物だ。だからこそ今週は請求アラートを整備する良い機会であり、コンソールのクリックではなくコードでやるべきだ。

なぜコンソールではなく IaC なのか

コンソールで作ったアラートは、ひとつのアカウントと誰かひとりの記憶の中にしか存在しない。Terraform なら次のようになる。

バージョン管理下に置かれる。誰がいつ何を変えたかが見える。
新しいアカウントができたら、同じモジュールを適用して標準を維持すればよい。
しきい値の変更は、レビューを通るプルリクエストになる。

実際の作業を担うリソースは、AWS Budgets をラップした aws_budgets_budget だ。

誰もテストしない前提をテストする

Wed, 15 Jul 2026 09:00:00 +0200

このシリーズの2つの荷重を支える前提は、いずれも今日、マネージドサービスで、午後の内にテストできる。AWS Fault Injection Serviceには "AZ Availability: Power Interruption" という名のシナリオが付いており、1つのアベイラビリティゾーン内のタグ付けされたすべてのインスタンスを停止し、それを置き換えようとするAuto ScalingグループにInsufficientInstanceCapacityエラーを送り込み、EBSボリュームのIOを一時停止し、サブネットのトラフィックを遮断し、その後障害を解除して停止したものを再起動する。第3回のコントロールプレーンの前提には既製の障害はないが、その正直な近似は1つのJSONファイルと1つのIAM拒否に収まる。どちらもほとんど誰も走らせない。その理由はツールではない。理由は、テストは失敗しうるが前提は失敗しえない、ということだ。

これは Nothing Fails Alone の第4回、最後の1つだ。第1回は5月のus-east-1インシデントを取り上げ、クォーラムがその内側で死ぬ一方でゾーン境界が持ちこたえるのを示した。第2回は3月のme-central-1のイベントを取り上げ、1つの原因が18時間の間隔をおいて、あらゆる分離保証を越えて2つのゾーンに届くのを示した。第3回は2つの提供者にまたがる3つのコントロールプレーンのインシデントを取り上げ、復旧計画がそれが走る層と共に死ぬのを示した。シリーズの背骨を2文で。あなたが買う可用性は、提供者が約束したものの境界で終わり、その線の上にあるすべてはあなたが所有するアーキテクチャだ。所有していて一度も動かさないものはアーキテクチャではない。それはあなたの名前が付いた前提だ。この回はそれを動かし、そしてシリーズを採点する。

AZ訓練は棚から取り出せる

FISのシナリオライブラリのAZ Availability: Power Interruptionは、1つのゾーンを失う際の記録された症状を誘発する公開された実験テンプレートで、その公開JSONは7つの障害タイプにまたがる8つのアクションを持つ(インスタンスの停止は2度現れる。1度はスタンドアロンインスタンス用、もう1度はAuto Scalingグループ自身のもの用だ)。ターゲットゾーン内のタグ付けされた稼働インスタンスは停止され、設定された継続時間の後に再起動される。タグ付けされたAuto Scalingグループからの起動リクエストは、その間InsufficientInstanceCapacityを受け取り、あなたが名指しした任意のIAMロールの容量呼び出しも同様だ。というのも、シナリオページによれば、実際の電源中断の間 "EC2 API calls made by the Auto Scaling control plane to recover lost capacity in the AZ will fail" からだ。EBSボリュームのIOは一時停止される。サブネットのトラフィックは、拒否ルールで満たされた複製ネットワークACLに差し替えることで拒否される。ゾーン内にライターを持つRDSクラスターはフェイルオーバーされ、ElastiCacheレプリケーショングループはそのゾーンの電源を中断される。それは5月のインシデントがuse1-az4にしたことのほとんどだ。Coinbaseを一晩ダウンさせた障害は、いまやライブラリの一項目だ。

それが何でないかについて正確になろう。インスタンスは正面玄関、StopInstances APIを通じて停止される。電源切断ではなく秩序あるシャットダウンなので、クラッシュ整合性については何もテストされない。Fargateタスクはカバーされない。2つの読み取り可能なスタンバイを持つRDS Multi-AZクラスターはサポートされない。1つのドリフトの注記。シナリオページは復旧アクションaws:arc:start-zonal-autoshiftを記述しているが、それ自身のJSONスナップショットには含まれていない。コンソールのライブラリは最新のリビジョンを持ち、ラボは公開JSONに従う。

ラボはシリーズリポジトリの04-game-dayで、シリーズの読み取り専用ルールを2度目にして最後に破る。--injectはあなたのクレデンシャルが届くどのアカウントに対しても実際の実験を開始するので、サンドボックスに、第3回のラボスタックに向けて、本番の近くには決して置かず、属するべきだ。

名前、ID、そして空で出荷される停止条件

第2回はゾーン名とゾーンIDについて騒ぎ立てたが、ゲームデーはその騒ぎが報われる場所だ。インシデントレポートはIDで話す。5月のレポートはuse1-az4と言い、3月の更新はmec1-az2、次いでmec1-az3と言った。あなたのアカウントは名前、AWSがアカウントごとにランダム化するエイリアスで話す。そしてツールは、大部分において、名前を要求する。インスタンスとサブネットのターゲットはPlacement.AvailabilityZoneでフィルタリングし、それはあなたのアカウントローカルの名前にマッチし、公開シナリオはEBS、RDS、ElastiCacheのターゲットパラメータも名前で埋める。ちょうど2つのアクションが物理IDを受け付ける。容量不足のペア、aws:ec2:api-insufficient-instance-capacity-errorとaws:ec2:asg-insufficient-instance-capacity-errorで、そのavailabilityZoneIdentifiersパラメータは名前だけでなくゾーンIDも取ると記述されている。そこでさえ、公開シナリオはそのフィールドを名前、us-east-1aで埋めている。

したがってゲームデーは、第2回がラボを提供した翻訳の問題から始まる。ランナーはそれを一度、冒頭で解決する。run.pyが受け付ける唯一のゾーンフラグは--az-id、物理ゾーン、インシデントレポートが名指しするものだ。それはDescribeAvailabilityZonesを通じてアカウントローカルの名前を解決し、両方を表示し、各プレースホルダーをその消費者が要求する形で埋める。あなたはインシデントレポートが与えるであろう名前の下で障害をリハーサルし、そのリハーサルは、あなたのアカウントがたまたま話す方言で自身を設定する。

ランナーが継承を拒む2つ目のものはより静かだ。公開シナリオの停止条件ブロックは、そのままこう見える。

"stopConditions": [
 {
 "source": "aws:cloudwatch:alarm",
 "value": ""
 }
]

中身が何もないガードレールの形であり、ページの制限事項セクションは停止条件はあなたが追加するものだと言っている。防御可能なデフォルトだ。AWSはあなたの定常状態を知りえないのだから。だが仕込まれたものでもある。JSONはきれいに貼り付けられ、空文字列は欠落した安全システムには見えないからだ。ラボの立場。run.pyは--alarm-arnが与えられない場合、何かを作成する前に終了する。意味のある停止条件のない実験はテストではなく、賭けだからだ。定常状態は障害の前にコミットする数であり、そうでなければゲームデーは失敗しえず、失敗しえないゲームデーはあなたに何も教えられない。

合格がどう見えるか、測って

第3回の2パススタックに対して実験を走らせ、その2ゾーンの一方を落とす。

python3 run.py experiments/az-power-interruption.json \
 --az-id euw1-az1 \
 --fis-role-arn arn:aws:iam::111111111111:role/fis-game-day \
 --alarm-arn arn:aws:cloudwatch:eu-west-1:111111111111:alarm:game-day-abort \
 --target-group-arn ... \
 --inject

--injectなしでは同じコマンドはドライランだ。解決されたテンプレートを表示し、何も開始しない。それを付けると、ランナーは実験を作成して開始し、その後終端状態までポーリングし、各アクションのステータスをログに記録し、測定としてターゲットグループの健全カウントをサンプリングする。そのタイムラインが成果物だ。以下に続くのは合格の形であって、私が得た結果ではない。それを勝ち取れる本番形のアカウントを私は持っていないからだ。パスB、静的に安定なものは、生き残ったゾーンがすでに負荷を担うので、障害後の要件である2つの健全なターゲットを決して下回らない。パスAは半分に落ち、障害の継続時間ずっとそこにとどまる。そのインスタンスを停止したのと同じ実験が、その置き換え起動にInsufficientInstanceCapacityを送り込んでいるからだ。第3回の測定スクリプトはパスAの復旧を協力的なコントロールプレーンに対して計測した。ゲームデーは非協力的なものに対して同じパスを示し、その2つの数の差こそが、あなたのDR計画が置いていた前提の大きさだ。

クラウドでクラウドをチェックする: M365 Security ポスチャスキャン 101

Fri, 03 Jul 2026 13:35:00 +0200

あなたのMicrosoft 365テナントはクラウドインフラだ。Entra ID、Exchange Online、SharePoint、Teamsにまたがる何百ものセキュリティ関連設定があり、管理されていないAWSアカウントとまったく同じようにドリフトする。管理者がインシデント対応中に設定を変えて、戻し忘れる。Microsoftがサービス更新でデフォルトを変える。2四半期前に終わったパイロットのために、ベンダーがゲストアクセスを持ったままになっている。そして誰もレビューしない。テナントは「ITのもの」であって「インフラのもの」ではないからだ。ポスチャスキャンは地味だが効く処方箋だ。テナントの実際の設定を公開されたセキュリティベースラインと継続的に比較し、ギャップを報告する。そして2026年にそのスキャナーを動かす現実的な方法はSaaSであり、つまりクラウドでクラウドをチェックすることになる。この記事はその101で、例としてAether365を使う。最初に明かしておくと、Aether365は私のプロダクトだ。

始める前にひとつの原則: read-onlyがデフォルトである。個別の明示的な同意なしに、テナントへの書き込み権限が付与されることはない。

テナントを本番アカウントとして扱う

誰かが設定監査もドリフト検知も変更履歴もなしに本番AWSを運用していたら、あなたはそれを怠慢と呼ぶだろう。ほとんどの組織はMicrosoft 365をまさにそのやり方で運用している。IDプロバイダー、すべてのメール、大半のファイルをそこに置いたままで、だ。テナントは、あなたが運用する他のすべてのもののIDプレーンだ。そこにあるConditional Accessの設定ミスは、攻撃者にとって公開S3バケットよりも価値がある。

インフラの考え方はそのまま移植できる。必要なのは、宣言されたベースライン、現実とベースラインの定期的な比較、そして両者が乖離したときのアラートだ。AWSの世界ならConfigルールやSecurity Hubスタンダードに手を伸ばすところだ。Microsoft 365における相当物がポスチャベンチマークになる。

知っておくべき3つのベンチマーク

重要なことの大半は3つのベースラインでカバーでき、まともなスキャナーは必ず少なくとも1つにマッピングされている。

CIS Microsoft 365 Foundations Benchmark: 最も広範なもので、MFAの強制からメールボックス監査、共有ポリシーまで、スイート全体にわたる800以上のチェックを持つ。「何に対して監査したのか?」に対するデフォルトの答え。
EIDSCA (Entra ID Security Configuration Analyzer): Entra IDだけに焦点を当てたもの。誰が認証し、同意し、アプリケーションを登録できるかを決める設定群だ。表面積は小さく、爆発半径は最大。
CISA ScuBA (Secure Cloud Business Applications): 米連邦政府のM365向けベースライン。より厳格で主張が強い。政府の外でも「堅い標的ならどうするか」のリファレンスとして有用だ。

ベンチマーク同士は重複するが、それで構わない。IDコントロールでの重複はコンセンサスがどこにあるかを教えてくれるし、コンセンサスのある検出結果こそ最初に直すべきものだ。

スクリプトかSaaSか: 本当のトレードオフ

これらのチェックを自分で走らせることはもちろんできる。Graph APIはすぐそこにあるし、Maesterのようなコミュニティツールが多くをラップしてくれるし、1テナントに対する定期的なPowerShell実行なら週末プロジェクトで済む。チェックが実際に何をしているかを学ぶには、私はこのアプローチが好きだ。

これがスケールしなくなるのは3つの軸だ。メンテナンス: ベンチマークはバージョンアップし、Graphのエンドポイントは変わり、スクリプト集はいつの間にかあなたが所有するプロダクトになる。履歴: ある時点のスクリプトは今日の状態を教えてくれるが、ポスチャの問いはトレンドの問いだ。このコントロールはいつ後退し、その前後で何が変わったのか。テナンシー: 複数テナントを管理し始めた瞬間、たとえば30社の顧客を抱えるMSPなら、テナントごとのスクリプトとクレデンシャルこそがリスクになる。

SaaSスキャナーはこのトレードを反転させる。読み取り専用のMicrosoft Graph同意を与えると、日次、週次、月次のスケジュールでコンプライアンススキャンとエクスポージャースキャンを走らせ、履歴を保持してくれる。精査すべきは同意モデルだ。外部サービスを自分のIDプレーンに接続することになるからだ。読み取り専用がデフォルトであるべきで、それを超えるものは、拒否できる別個の明示的な同意であるべきだ。このひとつの性質こそが、規制対象のEUテナントにとって、クラウドでクラウドをチェックすることを受け入れ可能にする。

Aether365がカバーする範囲

Aether365はそのスキャナーに対する私の回答だ。中核は、上記3つのベンチマークすべてに対するコンプライアンススキャンとエクスポージャースキャンで、テナントごとにスケジュールできる。加えてMSP向けのマルチテナント管理、Teamsとメールの通知、そしてAIアシスタントにスキャン結果を照会させたい場合のREST APIと組み込みのMCPサーバーが付く。EU拠点でGDPRに準拠しており、サインアップ時にデータリージョンを選択でき、スキャンデータがモデルの学習に使われることは決してない。

2つの機能は、テナントを内側から見る視点の先に踏み出している。External Attack Surfaceはテナントが外に何を晒しているかをチェックする。M365のメールを実質的に支えるSPF、DKIM、DMARCレコード、90日前警告付きの証明書期限、宙に浮いたDNSとサブドメイン乗っ取りリスク、開いたままのレガシー認証エンドポイント、公開されたSharePointとOneDriveの共有だ。そしてAI PilotはオプトインかつProとEnterprise限定で、検出結果を具体的なMicrosoft Graphの修正に変換し、何かが適用される前に項目ごとに承認させる。検証済みの監査証跡付きだ。読み取り専用がデフォルトのままで、書き込み経路は望む場合にだけ有効化する別個のMicrosoft同意になっている。1テナント月次スキャンのFreeティアがあり、最初のCISスコアを見るにはそれで十分だ。そしてその最初のスコアが、たいてい動機になる。

要点

この101はシンプルだ。あなたのMicrosoft 365テナントはクラウドアカウントと同じポスチャの規律に値するし、測定に使うベンチマークはすでに存在する。運用上の問いは、スキャナーを自分で動かすか、読み取り専用でスケジュール実行するSaaSに同意するかだけだ。スクリプトはコントロールを教えてくれる。サービスは時間を通してあなたを正直に保つ。どちらにせよ、避けるべき失敗モードは現在のデフォルト、つまり誰も何もチェックしていない状態だ。

次に読む

AWS Multi-party Approval for Organizations。同じ承認ゲートの考え方を、AWSの特権操作に適用した話。
Setting up DKIM for Google Workspace using Terraform and Route 53。メール認証のDNSレコードがアタックサーフェススキャンに含まれるに値する理由について。

同じプラットフォームのAI側、つまり修復に承認ゲートが必要な理由と、AI生成レポートが実際に何のためにあるのかについては、ercan.aiのM365 Security 101: AI Pilot and Business Impact Reportsを読んでほしい。クラウド、セキュリティポスチャ、プラットフォーム業務のコンサルティング、あるいは挨拶だけでも、ercanermis.comからどうぞ。

修正は障害と運命を共にする

Wed, 01 Jul 2026 09:00:00 +0200

あらゆる復旧計画は、1つ目より静かな2つ目の前提を抱えている。1つ目は、インフラの一部がイベントを生き延びるという前提だ。このシリーズの第1回と第2回はそれを試した。2つ目は、イベントが来たとき、まだ修正をデプロイできるという前提だ。APIが応答し、コンソールが読み込まれ、パイプラインがロールを引き受けられ、Auto Scalingグループが置き換えを起動できる、という前提だ。2023年6月13日、Lambdaのコンピュート容量を管理するサブシステムの潜在的な欠陥が、us-east-1で関数呼び出しを劣化させ、その後の4時間のうち一部の間、そのリージョンのAWS Management Consoleはエラーページを配信し、STSは上昇したエラー率を返した。その日、ほとんどの顧客のインフラは何も壊れなかった。壊れたのは、彼らがそれを直すために使ったであろう層だった。コントロールプレーンがブラストラジアスの内側にあるとき、修復の経路は障害ドメインの内側にある。

これは Nothing Fails Alone の第3回だ。第1回は5月のus-east-1インシデントを取り上げ、顧客のアーキテクチャがその内側で失敗する一方でゾーン境界が持ちこたえるのを示した。第2回は3月のme-central-1のイベントを取り上げ、境界が何に対して設計されているか、施設の障害、そして何に対してではないか、1つの原因が2つのゾーンに届くこと、を示した。両方の回は、AWSが両方のインシデントの最中に公開したほぼ同じ但し書きの近くで終わった。"longer than usual provisioning times"、だ。第1回は、この回があなたの復旧計画が他の全員の復旧計画と何を共有しているかについての話になると約束した。その答えがこれだ。共有しているのはコントロールプレーンだ。あなたのフェイルオーバーは、そのリージョンの他のあらゆるフェイルオーバーと同じリージョナルAPIを呼ぶ。提供者によって運用され、あなたがそれを必要とさせるのと同じイベントによって劣化する。その依存関係は、あなたがレプリカに向けるのと同じ精査に値する。

2023年6月: 修正は、失敗したまさにそのものを必要とした

そのメカニズムは、AWSが2023年6月13日についてポストイベントサマリーを公開して以来、公の記録に残っている。正確に読む価値がある。コントロールプレーンが失敗する一方でその下のインフラが動き続けた、最もきれいに記録された事例だからだ。午前10時1分(PDT)、us-east-1のLambda Frontendフリートは通常の日次トラフィックに対してスケールし始めた。午前11時49分、それはAWSの言葉で言えば "a capacity threshold that had previously never been reached within a single cell" を越え、それが "triggered a latent software defect" した。実行環境は割り当てられたが決して使われず、"responsible for managing the underlying compute capacity" するサブシステムは機能する置き換えをプロビジョニングできず、そのリージョンのLambda呼び出しは失敗し始めた。

そして依存グラフがその仕事をした。サマリーはAmazon STS、AWS Management Console、Amazon EKS、Amazon Connect、Amazon EventBridgeを、"as a result of the degraded Lambda function invocations" 劣化したものとして列挙している。STSは午前11時49分から午後2時10分(PDT)まで、"with three distinct periods of impact" 上昇したエラー率を返した。us-east-1のコンソールは午前11時48分から午後2時2分まで、"AWS Management Console is currently unavailable" ページか "504 Time-out" のいずれかを配信した。フェデレーションサインインも劣化した。"Existing IAM sessions were not impacted, but new sign-in federation via SAML was degraded." 完全復旧は午後3時37分(PDT)、影響が始まってから3時間48分後に来た。

AWS Lambda MicroVMs: serverless にステートフルで隔離されたサンドボックスが加わる

Tue, 23 Jun 2026 02:00:00 +0200

AWS Lambda MicroVMs は、仮想マシンレベルの隔離、snapshot からのほぼ即時の起動、そして中断と再開が可能なステートフル実行をもたらす、新しい serverless コンピュートプリミティブです。これは Firecracker 上で動作します。Firecracker は、すでに月間 15 兆回を超える Lambda 呼び出しを支えている軽量仮想化技術です。要約すると、Lambda は各セッションに専用で隔離された長寿命のサンドボックスを割り当てる能力を獲得し、しかもそれを自分で仮想化を管理することなく実現します。

自分のアプリケーションが書いていないコードを安全に実行しようとしたことがあるなら、つまりマルチテナントのコード実行、インタラクティブなノートブック、脆弱性スキャナーなどを扱ったことがあるなら、これがなぜ重要なのかすでにわかっているはずです。これまでの正直な答えは「コンテナや VM を立ち上げ、オーケストレーション、隔離、ライフサイクルの配管を自分で作り込む」というものでした。MicroVMs はそれを 1 回の API 呼び出しに集約します。

実際に何が新しいのか

通常の Lambda 関数はステートレスで短命、イベント駆動です。その用途では卓越しています。一方で、数分から数時間にわたって生き続け、メモリ内に状態を保持し、信頼できないコードをカーネルレベルで隔離する必要があるセッションには、間違ったツールです。MicroVMs は同じサービス内にある別のプリミティブで、まさにそのギャップを狙ったものです。AWS は、これを今日まで単一の AWS コンピュートサービスでは同時に提供されていなかった 3 つの機能として位置づけています。

1. VM レベルの隔離

各セッションは専用の MicroVM 内で動作し、ユーザー間でカーネルもリソースも共有しません。それが Firecracker の保証です。あるテナントの信頼できないコードはそのテナント自身の環境に封じ込められ、他の環境やホストへの経路はありません。コンテナはカーネルを共有しますが、MicroVM は共有しません。自分が書いていないコードを実行する場合、その境界こそがすべての要点です。

2. snapshot による高速起動と再開

モデルはイメージを作ってから起動する方式です。Dockerfile と Amazon S3 上のコードアーティファクトから MicroVM Image をビルドします。Lambda は Dockerfile を実行し、アプリケーションを初期化し、実行中のメモリとディスクの状態の Firecracker snapshot を取得します。そのイメージから起動されるすべての MicroVM は、コールドブートする代わりに事前初期化された snapshot から再開します。数ギガバイトに及ぶインタラクティブなセッションでも、ライブに感じられるほど高速に戻ってきます。これは SnapStart のアイデアを論理的な極限まで進めたものです。プロセスを起動しているのではなく、実行中のプロセスを復元しているのです。

3. ステートフルで中断可能な実行

実行中の MicroVM は、セッションをまたいでメモリ、ディスク、プロセスを保持します。アイドル状態になると状態を保ったまま中断でき、トラフィックが戻ると再開できます。インストール済みのパッケージ、ロード済みのデータ、作業中のファイルはすべてそのまま残ります。MicroVMs は合計で最大 8 時間のランタイムをサポートし、設定可能なアイドル時間の経過後に自動的に中断します。これが従来のステートレス serverless の前提を、良い意味で崩す部分です。

電話番号なし、アカウントなし: GoogleのQRウォールとGDPR

Thu, 18 Jun 2026 01:30:00 +0200

今日Googleアカウントを作ろうとすると、名前を一文字も入力する前に壁にぶつかるかもしれない。画面には「アカウントを作成する前にいくつかの情報を確認してください」と表示され、QRコードが現れ、スマートフォンのカメラでスキャンするよう求められる。クリックするリンクもなく、メールでの代替手段もなく、「スキップ」する経路もない。動作するカメラ付きのスマートフォンがなければ、アカウントは作れない。それがこのやり取りのすべてであり、立ち止まって見る価値がある。なぜなら、これは電話を静かにウェブ利用の前提条件に変えてしまうからだ。

私はオランダで、EU圏内に住んでいる。あの画面の言い回し(「Googleはあなたのデバイスまたは電話番号に関するいくつかの情報を確認する必要があります」)は、セキュリティ機能というよりも、不正対策を装った強制的な身元情報の収集のように読める。本稿は、その区別がなぜ重要なのか、そしてそれがGDPRとどこで衝突するのかについてだ。

画面が実際に要求していること

このプロンプトを文字どおりに読んでみよう。アカウントを作成するために、あなたは次のことを求められている。

QRコードをスキャンできるカメラ付きのスマートフォンを所有していること。
そのフローを電話側に引き渡し、開始したデバイスを離れ、Googleが事前に提示しない手順を完了すること。
新しいアカウントを電話番号と結びつけること。EUの大半では、電話番号はSIMレベルで検証済みの政府発行の身元情報と結びついている。
同じファネルの後半で、生年月日やその他の個人情報を提供すること。

これらのいずれも、メールアカウントが機能するための技術的な要件ではない。受信箱があなたの誕生日や端末のモデル、通信事業者を知る必要はない。これらは収集に関する判断であって、エンジニアリング上の制約ではない。そして、収集に関する判断として評価されるべきものだ。

「不正対策」がここで多くを担いすぎている

その正当化はボット対策だ。「コンピュータープログラムやボットによる不正利用の防止」。これは現実の問題であり、アカウント作成にレート制限をかけることは正当だ。しかし、この制御の形に注目してほしい。これは、人間なら解けてスクリプトには解けないパズルを解くよう求めているのではない。電話を提示することを求めているのだ。検証されているのは「あなたは人間か」ではなく、「フィンガープリントを取って相関付けできるデバイスと番号を出せるか」だ。

これらは異なる目標だ。前者は不正対策に見合っている。後者は身元の紐付けであり、サインアップ時に電話番号がいったん付与されると、それが収集された目的の範囲内にとどまることはまれだ。「セキュリティのために」追加された番号は、広告ターゲティング、アカウント復旧のソーシャルグラフ、サービス横断の相関付けへと流れていく長い歴史を持つ。セキュリティチームはこれを機能のなし崩し的拡大(function creep)と呼ぶ。GDPRはこれを目的制限の問題と呼ぶ。

これがGDPRとどこで衝突するか

私は、ある裁判所がこの特定のフローを違法と判断したと主張しているわけではない。データ保護当局(DPA)が実際に検討するであろう原則を指し示しているのだ。なぜなら、それらは「これをスキャンするか、立ち去るか」とは相性が悪いからだ。

データ最小化、第5条(1)(c)

個人データは、その目的に対して「十分かつ関連性があり、必要な範囲に限定」されていなければならない。ここでの目的はメールアカウントの作成だ。電話番号と生年月日は受信箱を運用するために必要ではない。つまり、なぜそれらを収集するのかを示す責任は管理者側にあり、拒否を正当化する責任は利用者側にはない。

自由に与えられた同意、第4条(11)および第7条(4)

同意は、自由に与えられた場合にのみ有効だ。規則は明示的に、サービスがそのサービスに必要でない処理への同意を条件としていないかを考慮しなければならないと述べている。「電話番号がなければアカウントはない」は、条件付けの教科書的な定義そのものだ。データ共有以外の唯一の選択肢がサービスから完全に排除されることである場合、その「選択」はほとんど意味を持たない。

比例性と必要性

同意ではなく正当な利益を根拠とする場合でも、その処理は必要性とバランステストを通過しなければならない。サインアップのごく一部を占めるにすぎないボットを排除するために、所有していないかもしれないハードウェアをすべての見込み利用者に強制することは、CAPTCHA、メール確認、行動シグナルがすでに存在し、いずれもカメラを必要としない以上、最も侵襲性の低い選択肢とは言いがたい。

誰も設計で考慮しない排除

プライバシーの問題の下に、もっと静かな問題がある。QRとカメラのゲートは、特定の利用者を前提としている。新しめのスマートフォンを所有し、コードを物理的に見てスキャンでき、アカウント作成フローを端末に移すことに抵抗がない人だ。その前提は、デスクトップだけを使う人、視覚障害のある人、フィーチャーフォンを使う人、意図的にデバイスを最小限に保つ人、そして個人の電話をすべてのログインに組み込みたくないだけの人を排除する。

「電話を使えばいい」は中立的なデフォルトではない。それは、Googleの不正対策のコストを利用者に、スマートフォンを当然のものとして持っていない利用者にも押し付ける設計上の判断だ。アクセシビリティとデータ保護はここで同じ方向を指している。これほど中心的なサービスには、特定のハードウェアの所有を必要としない経路があるべきだ。

EUが実際にできること

これに異議を唱えるためのGDPRの仕組みはすでに存在する。新しい法律は必要なく、必要なのは上記の原則の執行だ。

サインアップ時の電話番号と生年月日をデフォルトで不要なものとして扱い、管理者が必要性を主張するのではなく証明するよう求めること。
第7条(4)の条件付けの論理に基づき、スマートフォンや番号を必要としない真の代替経路をアカウント作成に義務付けること。
目的を精査すること: 不正対策のために収集された番号が後に広告や相関付けに使われた場合、それはサインアップ画面の文言がどうであれ、目的制限違反だ。

EDPBの協調した見解、あるいは断固とした一つのDPAだけで、設計のやり直しを迫るには十分だ。私たちはまさにこのパターンをクッキーウォールで見てきた。規制当局は最終的に「同意するか、立ち去るか」は本当の同意ではないと判断した。ハードウェアの壁は、カメラがくっついた同じ議論だ。

今日あなたにできること

上記のどれも、実際にアカウントが必要な5分間の助けにはならない。だから実践的には次のとおりだ。

自分が管理するアカウントについては、電話を要求しないプロバイダーを使うこと。複数のEU拠点のメールプロバイダーは、番号を必須ではなく任意として扱っている。
身元と利便性を分けておくこと。 どうしてもどこかに番号を付ける必要があるなら、銀行や政府の身元情報を支える番号を使い回さないこと。
自分の権利を行使すること。 Subject Access Request(開示請求)、そして適切な場合には自国のDPAへの苦情申し立ては、象徴的なものではない。それらは上記の原則を圧力に変える仕組みだ。

要点

アカウント作成時のQRと電話の壁はセキュリティとして売り込まれているが、それが実際に守るデータはあなたのものであり、参加の代償として差し出される。EUではその代償に法的な枠組みがある。データは最小化されなければならず、同意は自由でなければならず、サービスは機能するために必要としない情報の提供を、自らの条件として静かに設定することはできない。「これをスキャンしろ、さもなければアカウントは持てない」は、その三つすべてに表面上から反している。規制当局がそう声に出して言うかどうかは、この時点では、法律の問題というより意志の問題だ。

次はこれを読む

AWS Organizationsのマルチパーティ承認。身元と承認の制御が、権力を収集するためではなく抑制するために設計されたとき、どう見えるかについて。
SSHが量子コンピューターについて警告してくる理由。セキュリティ警告を額面どおり受け取ることと、それが実際に何を守っているのかを読むことについて。

AIアシスタントが、渡された身元と同意のデータをどう扱うかについて考えているなら、ercan.aiのフィールドノートがそれを扱っている。クラウド、セキュリティ、コンプライアンス型のプラットフォーム業務に関するコンサルティングは、ercanermis.comから始めてほしい。

2つのゾーン、18時間、1つの原因

Wed, 17 Jun 2026 09:00:00 +0200

3月1日、AWSのme-central-1リージョンのアベイラビリティゾーンmec1-az2が、AWSが "objects that struck the data center, creating sparks and fire" と表現するものに見舞われた。約18時間後、2つ目のゾーンmec1-az3も電源を失った。3つ目のmec1-az1は終始稼働し続けた。3つのうち2つのゾーンが障害を受けたことで、S3とDynamoDBがリージョン全体で失敗し始め、AWSの顧客への助言は、Health Dashboard上の自らの言葉で、"enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe" というものだった。アベイラビリティゾーンの独立性は、電源障害、冷却障害、ネットワーク障害に対して設計されている。3月、それは一度も設計対象とされてこなかった原因に出会い、その原因は設計など気にかけなかった。

これは Nothing Fails Alone の第2回だ。第1回は5月のus-east-1インシデントを検討し、ゾーン境界は持ちこたえたと論じた。実際そうだった。1つのデータホールでの冷却障害は、設計通りに1つのゾーンの内側にとどまり、その後の障害は顧客が構築したものだった。その論は正しく、特定の問いに答えていた。AZ分離は、それが設計対象とする障害モードを封じ込めるのか、という問いだ。3月のme-central-1のイベントは別の問いを投げかける。それは第1回が書かれる前に起きており、当時は戦時の特殊ケース、通常のアーキテクチャには何の教訓もない戦争行為の脚注として片付けるのは容易だった。一般的な形を見えるようにしたのは5月のインシデントだ。第1回はゾーン境界が守るものについての話であり、この回はそれが守れないもの、つまり複数のゾーンに届くあらゆる原因についての話だ。そうした原因は平時にも存在する。戦争はそのデモンストレーションを2日間に圧縮しただけだ。

me-central-1で実際に何が起きたか

このイベントは3月1日午前4時51分(PST)、"issues with AWS services in the ME-CENTRAL-1 Region" の調査としてAWS Health Dashboard上で始まり、すぐに単一のアベイラビリティゾーンmec1-az2での "localized power issue" へと絞り込まれた。ダッシュボードのログは異例なほど率直で、午前9時41分(PST)には電源が落ちた理由をこう説明した。"At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire." 翌日AWSは原因を名指しした。The Registerが同日報じた更新でだ。中東の紛争の一部としてのドローン攻撃だった。"In the UAE, two of our facilities were directly struck" であり、その攻撃は "caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage" だった。

AWS Organizations の Multi-party approval

Sat, 13 Jun 2026 01:00:00 +0300

Multi-party approval は AWS Organizations の機能で、あらかじめ定義した高リスク操作の集合を、指名された複数の人間による定足数が帯域外で承認するまでブロックする。たとえ有効なものであっても、単一の認証情報セットだけでは引き金を引けなくなる。リクエスト元が操作を開始し、別の approval team が専用ポータルでそれをレビューし、チームの approval threshold が満たされて初めて操作が実行される。

これは「四つの目」の原則を、Runbook や Slack メッセージではなく API レイヤーで強制するものだ。「2 人が承認しなければならないというポリシーがある」という状態と、「プラットフォームが 2 人の承認なしには物理的に処理を拒否する」という状態の間にある隙間を埋める。

実体は何か

Multi-party approval (MPA) は AWS Organizations の内側に位置し、人間の ID については IAM Identity Center に依存する。あなたは approval team、つまり ID ソースから引き出した承認者の集合を定義し、そこに approval threshold、すなわち protected operation を実行できるようになる前に「はい」と言わなければならない最小人数を割り当てる。

次に、特定の操作を protected としてマークする。その時点以降、protected operation を呼び出した者は即座に結果を得られない。得られるのは保留中のリクエストだ。MPA はチームの全承認者にメールを送り、各承認者が approval portal を開いてリクエストをレビューし、承認または拒否する。threshold に達すると、元の呼び出し元の操作が実行を許可される。承認は事後通知ではなく、ゲートそのものだ。

用語

Approval team: IAM Identity Center ユーザーに裏打ちされた、名前付きの承認者グループ。
Approval threshold: 何人の承認者が承認しなければならないか。threshold が 2 の 3 人チームなら、そのうち任意の 2 人が操作のブロックを解除する。
Protected operation: ゲートの背後に置いた具体的なアクション。
Approval portal: 承認者がレビューし応答する帯域外のサーフェス。リクエストを行ったコンソールセッションとは意図的に分離されている。

フローの動作

プロセスは 3 ステップで、その間の分離こそが本質だ。

AZの分離は持ちこたえた。あなたのアーキテクチャは違った。

Wed, 03 Jun 2026 09:00:00 +0200

5月7日の夜、us-east-1のあるアベイラビリティゾーンの1つのデータホールで冷却が停止し、ラックが電源を失った。そしてAWSのブラストラジアスはドキュメントが約束する通りに機能した。被害はuse1-az4の内側にとどまったのだ。他のすべてのゾーンは配信を続けた。その夜にダウンした企業は、自分自身のアーキテクチャの内側でダウンした。そのことを異例なほど正確に把握できるのは、Coinbaseが月曜日にポストモーテムを公開し、自らの言葉でそう述べているからだ。同社の表現によれば、取引はプラットフォームのゾーン境界が正しく機能したイベントの最中に "unavailable or degraded for roughly eight hours, with full recovery of all systems taking another twelve" だった。

これは Nothing Fails Alone の第1回だ。このシリーズは、クラウドプロバイダーから買う可用性と、その上に実際に構築する可用性との間のギャップについて扱う。各回は実在するインシデントを1つ取り上げ、それが試すアーキテクチャ上の主張を抽出し、あなた自身のアカウントに対して走らせられる小さなラボを提供する。ラボは付属リポジトリ、GitHub上のnothing-fails-aloneに置かれており、そのすべてが読み取り専用だ。

use1-az4で実際に何が起きたか

AWS Health Dashboardの最初のインシデントレポートには5月7日午後5時25分(PDT)のタイムスタンプが押されていた。解決済みのイベントはその後ダッシュボードから消えているため、以下の文言は当時The Registerが引用したものだ。us-east-1のuse1-az4アベイラビリティゾーンでの問題、というものだった。続報はそのメカニズムを率直に述べていた。"EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event." 午後6時47分(PDT)までにAWSは温度を通常レベルに戻す作業を進めていると述べ、そのゾーンにある影響を受けたEC2インスタンスとEBSボリュームに依存する他のサービスも障害を受けうると警告した。

Coinbaseのポストモーテムは物理的な原因を補完している。1つのデータホール内で複数のチラーユニットが同時に故障し、冷却の喪失が該当ラックのサーマルセーフティシャットダウンを引き起こした。"loss of power during the thermal event" が実務上意味するのはこれだ。ラックは破壊されたのではない。冷却なしにコンピュートを動かせば破壊されてしまうため、意図的に電源を落とされたのだ。それらのラック上のEC2インスタンスとEBSボリュームは、1つの建物、1つのゾーンの中で、まとめてオフラインになった。

復旧は段階的で、段階的であることに正直だった。その夜の午後10時11分(PDT)、AWSは追加の冷却容量がオンラインになり一部のラックが復旧したと報告し、残りは "in a controlled and safe manner" 復旧させるとした。冷却容量が事故前のレベルに戻ったのは5月8日午後1時50分(PDT)、最初のレポートからおよそ20時間後で、インスタンスの復旧は冷却の回復に遅れて続いた。AZイベントを15分の瞬断だと考えているなら、認識を修正してほしい。物理法則がそうであるように、サーマルイベントは時間単位で測られ、ラックは一斉にではなく1ラックずつ戻ってくる。

起きなかったこと

us-east-1の他のアベイラビリティゾーンは健全なままだった。これはこのインシデントの中で、実際よりもっと注目されるべき部分だ。なぜならAWSが実際に約束していたのはこの部分だからだ。アベイラビリティゾーンは独立した電源と冷却を持つ物理的に分離された施設であり、5月7日にその独立性は実際の施設障害によって試され、持ちこたえた。障害ドメインは1つのデータホールで、ブラストラジアスは1つのゾーンの内側にとどまった。

正直な但し書きがちょうど1つあり、それはこのシリーズの後半で効いてくるため引用する価値がある。AWSは被災したゾーンからトラフィックを移し、顧客にワークロードを他のus-east-1ゾーンへ移すよう助言し、そしてこう認めた。"Customers may experience longer than usual provisioning times." もちろんそうなる。ゾーンが死ぬと、そのリージョンで正しく構築されたマルチAZアーキテクチャがすべて、生き残ったゾーンで一斉に容量を補充し始める。ゾーン境界は持ちこたえたが、生き残ったゾーンは共有プールであり、大量フェイルオーバーはそのプールに対するサンダリングハードだ。この但し書きを覚えておいてほしい。このシリーズの第3回は、あなたの復旧計画が他の全員の復旧計画と何を共有しているかについての話だ。

現在

Mon, 25 May 2026 10:00:00 +0200

(最終更新: 2026年5月)

執筆

クラウド、AWS、プラットフォームエンジニアリングに関するフィールドノートをこのサイトで公開しています。AIと応用MLについては ercan.ai を、AI関連の短いニュースは news.ercan.ai を運営中。月間AWSニュースダイジェスト awsmonthly.cloud を構築中です（まだローンチ前）。

コンサルティング

少数のコンサルティング案件を受けています。プラットフォームエンジニアリングアドバイザリー、AWSコスト最適化（Savings Plansを買うだけではない本物の最適化）、大規模EKSとTerraform、暫定プラットフォームリード、移行とモダナイゼーション。常に1〜2件のみ進行。扱っている課題が重なる場合は LinkedIn までご連絡ください。

開発

マルチリージョンEKSパターン、大規模Terraformモジュール構成、AWSコスト可観測性ダッシュボードを改良しています。UptimeCoachは20リージョンにわたって動作する生きたリファレンスアーキテクチャです。

コミュニティ

Claude Community NLのロッテルダム支部運営者です。初回ミートアップを日程調整中です。

対応可否

2026年6月よりコンサルティング案件を受付中。最適な連絡手段: LinkedIn。

次に読む

コンサルティング & アドバイザリー
このサイトの最新記事

Consulting & Advisory

Sun, 24 May 2026 10:00:00 +0200

Mainen, shousuu no konsaruteingu keiyaku wo hikiuketeimasu, soshite kokoro kara tanoshindeimasu. Chiimu, sutakku, seiyaku no tayousei ga purattofoomu no kanshiki wo surudoku tamochimasu. Kuraianto no shigoto ga koko no kiji wo yashinai, kiji ga keiyaku wo yashinaimasu.

Saabisu

Purattofoomu enjiniaringu adobaizarii. Chiimu ga “tada Terraform de nantoka” de wa tsuujinaku naru chiiten ni tasshiteimasu. Modyuuru no kyoukai, joutai no shoyuuken, CI/CD sekkei, saishou token no IAM, soshite purattofoomu wo seihin ni kaeru unyou moderu.
AWS kosuto saitekika. Hontou no saitekika. Reikii kara gyoushuu no rebyuu, tokutei waakuroodo made tsuiseki. Hotondo no keiyaku de apurikeeshon koodo ni furezu ni 30-50% no sakugen. “Seebingu Puran wo kaou” yori fukai.
EKS oyobi kontena purattofoomu aakitekucha. Kurasutaa sekkei, noodoguruupu no saijingu, IAM for Service Accounts, jissai ni sukeeru suru nettowaaku, dorama no nai kontorooru pureen no appugureedo senryaku.
Soshiki sukeeru no Terraform to Terragrunt. Modyuuru no kyoukai, joutai no shoyuuken, dorifuto kenshutsu, rebyuu jidouka. Fukuri wo harau taikutsu na infura.
Igyou to kindaika. Regashii kara AWS e, monorisu kara saabisu e, maruchi akounto no hodoki. Doko ga itamudoku, dou junjo wo tsukeru ka wo shitteiru kurai ni wa yarimashita.

Watashi no hatarakikata

Purojekuto beesu. Igyou, purattofoomu saisekkei, mata wa kosuto mondai wo okangae nara, watashi ga chiimu to tomo ni shigoto wo shi, seika wo watashimasu.

概要

Sat, 23 May 2026 10:00:00 +0200

Ercan Ermisです。オランダを拠点とするシニアクラウドプラットフォームエンジニアです。クラウド、AWS、EKS、Terraform、可観測性、そしてシステムが午前3時に稼働し続けるかどうかを決めるプラットフォームエンジニアリングの判断について書いています。

ここに至るまで

人生で最初のコンピュータは、Floppy AとFloppy Bという5.25インチのフロッピードライブを2基搭載したAmstradでした。1986年に父が事業のために買ったものです。本当の意味で恋に落ちたのは1998年、小学4年生のときでした。学校のコンピュータ室にあったWindows 95のマシンの1台に、先生がLinuxをインストールして「これはLinuxといって、フリーソフトウェアだよ」と言ったのです。そして黒い画面にPac-Manが現れた瞬間、私はもう抜け出せませんでした。

なぜこれは動くのか。実際にはどうやって動いているのか。他に何ができるのか。どうすれば違うやり方でやらせられるのか。30年以上経った今も、私はこの4つの問いを繰り返し、キーボードの前に座り続けています。コンピュータの前で過ごす時間は、今も昔も私が最も心地よく、最も穏やかでいられる場所です。このサイトのプラットフォームエンジニアリングの仕事は、その問いのループを数十年回し続けた結果として生まれたものです。

このサイトの投稿は、スライドではなく実際のプロダクションシステムから来ています。BMW Bankでの24時間365日の可用性要件を伴うバンキングリスク計算。16年前のオンプレミスベッティングプラットフォームをダウンタイムゼロ、データ損失ゼロでAWSに移行した話。Miniclipを通じた獲得規模のマルチプレイヤーモバイルゲーム。唯一のエンジニアとしてエンドツーエンドで担当したライブストリーミングインジェストパイプライン。それぞれの経験が傷跡を残し、その傷跡が投稿になります。

私の働き方

Platform Engineering、SRE、DevOpsは私にとって1つの仕事であり、3つではありません。ターゲットアーキテクチャを設計し、それをプロビジョニングするTerraformを書き、その上にデプロイするCI/CDを構築し、その結果に対してポケベルを持ち続けます。別々の役割への分割は組織図に過ぎず、実際の仕事は1つのループです。私はそのループの中から書いています。

バイアスは以下に向かっています：

チームごとの特注インフラではなく、再利用可能なモジュールと舗装された道。
後付けではなく、最小権限IAM、KMS、ネットワーク分離をデフォルトに。
レイテンシやエラー率と同じダッシュボードでのコスト意識。
正直な失敗モード分析。「大丈夫だろう」はSLOではありません。

ここで見つかるもの

ほとんどの投稿は3つのカテゴリのいずれかに該当します：

プロダクション環境のAWSとEKS。 クラスタの運用、ノードグループのサイジング、実際にスケールするIAMパターン、ネットワーキングの落とし穴、トラブルのないコントロールプレーンのアップグレード。
組織規模でのTerraformとTerragrunt。 モジュール境界、状態所有権、ドリフト、レビュー自動化、複利を生む退屈なインフラ。
可観測性と信頼性。 Prometheus、Grafana、CloudWatch、構造化ログ、作成者以外の誰かが実際に従えるランブック。

私が想定している読者は、既にAWS CLIを知っていて、既にどこかでKubernetesを運用していて、私が遭遇した明らかでない部分、トレードオフ、失敗モードを知りたいエンジニアです。

資格とコミュニティ

AWS Certified Solutions Architect, Associate。
2022年からAWS Community Builder。
Claude Community NLのロッテルダムチャプターオーガナイザー。初回ロッテルダムイベントは近日開催予定です。meetup.com/claude-rotterdamをフォローしてください。
Izmir Yazilim Agi創設者（1,239名のメンバー、57回のイベント）。
AI関連の執筆とニュース: ercan.aiは長文形式、news.ercan.aiは短文形式の速報。

UptimeCoach、20のAWSリージョンにまたがってプロビジョニングされた個人SaaSラボで、動作するマルチリージョンリファレンスです。

コンサルティングとアドバイザリー

毎年少数のコンサルティング案件を引き受けており、心から楽しんでいます。チーム、スタック、制約の多様性が、私自身のプラットフォーム感覚を鋭く保ちます。クライアントのために行う仕事は、このサイトの執筆に直接フィードバックされ、その逆もまた然りです。

チームとの協働方法：

プラットフォームエンジニアリングアドバイザリー。 「ただのTerraformと祈り」では機能しなくなる地点にチームが差し掛かっています。モジュール境界、状態所有権、CI/CD設計、最小権限IAM、そしてプラットフォームをコストセンターではなく製品に変える運用モデルについて支援します。
AWSコスト最適化。 「Savings Plansを買って終わり」ではない、本物の最適化。請求書を1行ずつ精査し、無駄を特定のワークロードまで追跡し、再構築します。ほとんどの案件で、アプリケーションコードに一切触れることなく30〜50%を見つけ出します。
暫定プラットフォームリード。 リード不在、または重要な成長段階を迎えているチーム。一定期間参加し、技術的方向性を設定し、Paved Roadを構築し、長期的なリードの採用または昇進を支援します。
移行とモダナイゼーション。 レガシーをAWSにリフト、モノリスをサービスに分解、またはマルチアカウントの混乱を整理。どの部分が痛むか、そして痛まないように順序付ける方法を知るのに十分な経験があります。

私がコンサルティングを行う領域の全体像：AWS、クラウドアーキテクチャ、CI/CDパイプライン、Linux、GitHubおよびGitLabツーリング、TerraformとTerragrunt、KubernetesとEKS、可観測性、コスト最適化、移行、そしてそれら全体を支えるプラットフォームエンジニアリングの運用モデル。プロダクションのクラウドアカウントやビルドパイプラインで動いているものなら、すべて対象範囲です。

小規模で集中的な案件。一度に1つか2つ。取り組んでいることが、私がここで書いている種類のことに似ているなら、LinkedInでご連絡ください。問題とチームの規模についての短いメッセージだけで始められます。

次に読む

このサイトの最新投稿、プロダクションから直接。
AIと応用MLの記事はercan.aiにあります。
ハブと連絡先の詳細: ercanermis.com。

ローカルDynamoDBが成長した: ExtendDBのハンズオンレビュー

Thu, 21 May 2026 17:42:29 +0300

DynamoDB Localは2013年以来、AWS DynamoDBのラップトップ代替として使われてきた。Java JARで、インメモリまたはSQLiteファイルに対して動作し、ほぼすべてのリクエスト形状を受け入れ、実際の認証はなく、Streamsもかなり緩く扱う。ユニットテストには十分だ。しかしコードがPutItemとGetItemを超えたことをする瞬間から割れ始める。

ExtendDB v0.1.0が出荷された。AWSエンジニアによってRustで書かれたDynamoDBワイヤープロトコルのクリーンルーム実装で、PostgreSQLをバックエンドとし、Apache 2.0ライセンスだ。売り文句は「DynamoDB Local、ただし真剣に受け止められる」というものだ。この記事は、それが通用するかどうかを単一のMacで並行ラボとして実行したハンズオンレビューだ。

ExtendDBの正体

ExtendDBはDynamoDBのフォークではない。DynamoDBのソースコードは含まれていない。それはDynamoDBのワイヤープロトコル（AWS SDKが使用するJSON-1.0 X-Amz-Targetディスパッチ）を話すため、既存のboto3やAWS CLIクライアントはフラグ変更だけでExtendDBエンドポイントに向けられ、変更なしで動作する。

内部では小さく集中したRustワークスペースだ:

flowchart LR
 bin[extenddb<br/>CLI + daemon] --> server[extenddb-server<br/>HTTP + console]
 server --> engine[extenddb-engine<br/>DynamoDB op handlers]
 server --> auth[extenddb-auth<br/>SigV4 + IAM policy]
 engine --> core[extenddb-core<br/>types, expressions]
 engine --> storage[extenddb-storage<br/>trait definitions]
 storage --> pg[extenddb-storage-postgres<br/>PostgreSQL backend]

extenddb-storageクレートは単なるトレイト定義だ。extenddb-storage-postgresが現時点で唯一の実装だ。異なるバックエンド（sqlite、foundationdb、何でも）は主にトレイトを実装することになる。

Verdict（評決）

DynamoDB Localを回避するテストコードを書いたことがあり（認証をモックアウト、Streamsのアサーションをスキップ、TTLをスタブ）、実際のサービスが異なる動作をするのではないかと静かに心配していたなら、ExtendDBは興味深い。認証、Streams、TTL、マルチアカウント分離、永続性を真剣に受け止めた初めてのローカルDynamoDB代替であり、ストレージレイヤーはpsqlでアクセスできるプレーンなPostgreSQLだ。

現実的な認証とストリームセマンティクスを必要とするCIパイプライン、オンプレミスやエアギャップデプロイメント、「DynamoDB Localでは動くのに...」で時間を失ってきた開発チームにとって、v0.1.0はすでに有用なツールだ。実際のサービスとのバイト完全なワイヤー互換性に依存するものについては、最初に自分でパスすること。

リンク:

リポジトリ: https://github.com/ExtendDB/extenddb
リリース: https://github.com/ExtendDB/extenddb/releases/tag/v0.1.0
はじめに: https://github.com/ExtendDB/extenddb/blob/v0.1.0/docs/getting-started.md
動作の違い: https://github.com/ExtendDB/extenddb/blob/v0.1.0/docs/differences-from-dynamodb.md
DynamoDB Local Dockerイメージ: https://hub.docker.com/r/amazon/dynamodb-local
AWS DynamoDB Localドキュメント: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html
DynamoDB TTLストリームuserIdentity仕様: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/time-to-live-ttl-streams.html

参考資料

日曜の深夜にCloudflareの隠れたバグを見つけた方法（curlの喜び）

Sun, 10 May 2026 00:44:28 +0300

ちょっとした週末プロジェクトのはずだった。あの手のやつだ。「出力用VMを立ち上げて、トラフィックをルーティングして、コーヒーをすすって、昼までに終わらせる」というやつだ。読者よ、昼までには終わらなかった。

セットアップ

いくつかの開発環境用に小さなアクセス層を構築していた。Cloudflare Zero Trustを前に置いた出力用VM、2つの特定の開発ドメイン用のホスト名ベースのルーティング、そしてソースIPをチェックするAWS WAFを反対側に配置するものだ。「チームに安全なアクセスを提供し、パブリックインターネットに公開しない」というごく標準的な構成だ。

TLS復号を有効にする必要がある部分に当たるまではすべて順調だった。これはCloudflareのゲートウェイがトラフィックを実際に検査し、単なるIPではなくホスト名に基づいてルーティングできるようにする魔法だ。これがないと、美しいホスト名ルールはただそこに座っているだけで何もしてくれない。

チュートリアルの迷路

Cloudflareの公式ラーニングパスに従った。3つの異なるブログ記事に従った。本当にチャンネル登録してほしそうな声の人のYouTubeチュートリアルにも従った。みんな同じことを言っていた:

Zero Trust > Settings > Network > Firewall > TLS decryption に移動してスイッチを入れる。

そこでそこに行った。スイッチを入れた。すると画面の上部に赤いバナーが表示された。そこにはただこう書かれていた:

TLS設定の構成中にエラーが発生しました。

それだけだった。コードなし。ヒントなし。「詳細はこちら」のリンクもなし。ただ「何かがうまくいかなかった、がんばって」という雰囲気だけ。

もう一度試した。同じエラー。更新した。同じエラー。Firefoxで試した。同じエラー。キャッシュをクリアした。同じエラー。コーヒーを淹れようかと考えた。コーヒーを淹れた。同じエラー。

探偵作業

ここで私の大好きなツールの出番だ。UIが何が問題かを教えてくれないときは、ネットワークタブとcurlが教えてくれる。デベロッパーツールを開き、トグルが送信しているリクエストを監視し、curlとしてコピーしてローカルで実行した:

{
 "result": null,
 "success": false,
 "errors": [
 {
 "code": 2211,
 "message": "TLS decryption cannot be enabled without a certificate. Please disable TLS encryption or configure a certificate using the 'certificate' setting."
 }
 ],
 "messages": []
}

そこにあった。明確で、役に立ち、行動可能なエラーメッセージ。UIに表示されていれば、私の人生の約90分を節約できたはずのメッセージだ。代わりにそれはJSONレスポンスの中に隠れ、APIと画面の間のどこかで飲み込まれていた。

メッセージは基本的に「まず証明書が必要だ、このポテト野郎」と言っていた。（要約です。）

本当の修正方法

インターネット上の誰も言及していないように見えることがある: 証明書管理が移動している。

私が読んだすべてのガイドは古い場所を指していた。実際の現在の場所は完全に別のセクションに埋もれている。具体的には:

Zero Trust > Traffic policies > Traffic settings > Certificates (上部のタブ)

Networkではない。Firewallではない。Traffic policies > Traffic settingsだ。

SSHが量子コンピュータについて警告している理由（とその修正方法）

Fri, 17 Apr 2026 13:12:28 +0300

サーバーにSSH接続すると次の表示が出る:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

怖い話だ。分解してみよう。

脅威: Store Now, Decrypt Later（SNDL）

今日のSSH暗号化は数学的に強力で、古典的コンピュータでは解読に数百万年かかる。しかし量子コンピュータは異なるルールで動作する。Shorのアルゴリズムを実行する十分に強力な量子コンピュータは、今日の公開鍵暗号の多くを保護する数学を数百万年ではなく数時間で破ることができる。

不安な部分: これができるほど強力な量子コンピュータはまだ存在しない。ではなぜ今心配するのか？なぜなら敵対者、特に国家レベルは、量子ハードウェアが成熟した後に復号する計画ですでに暗号化トラフィックを記録しているからだ。これがSNDL攻撃だ。これはSFではない。NSA、CISA、NISTはすべて、今すぐにポスト量子暗号への移行に関するガイダンスを発行している。

古典的 vs ポスト量子鍵交換

古典的（量子コンピュータに脆弱）

diffie-hellman-group1-sha1（回避）、diffie-hellman-group14-sha1（回避）、curve25519-sha256（最良の古典的オプション）など。上記すべてはShorのアルゴリズムを実行する量子コンピュータによって破られる。

ポスト量子（量子コンピュータに対して安全）

sntrup761x25519-sha512@openssh.com（OpenSSH 8.5+）: NTRU Prime + X25519のハイブリッド
mlkem768x25519-sha256（OpenSSH 9.9+）: ゴールドスタンダード。ML-KEM-768 + X25519（NIST FIPS 203標準化）

両方ともハイブリッドアルゴリズムで、ポスト量子アルゴリズムを古典的アルゴリズムの上に重ねる。PQアルゴリズムに欠陥があればX25519が保護し、量子コンピュータが攻撃すればPQ層が保護する。両方の長所を得られる。

修正方法

Step 1: /etc/ssh/sshd_configを編集する。
OpenSSH 9.9+の場合: KexAlgorithms mlkem768x25519-sha256,...
OpenSSH 8.5-9.8の場合: KexAlgorithms sntrup761x25519-sha512@openssh.com,...
古典的アルゴリズムはフォールバックとして保持すること。

Step 2: 検証して再起動: sudo sshd -tの後にsudo systemctl restart sshd

IaCファースト: 本番環境でAWSコンソールを決して触らない理由

Thu, 16 Apr 2026 19:02:42 +0300

「本番環境でAWSコンソールを決して触らない」というのは極端なルールに聞こえる。そうではない。これはクラウドネイティブチームにおいて最も重要な運用規律であり、これに違反したコストは静かに蓄積され、やがて大きなインシデントを引き起こす。

この記事ではその理由と、実際のチームでIaCファースト開発を強制する方法を説明する。

状態ドリフト問題

Terraform（およびOpenTofu）は、どのようなインフラストラクチャが存在するかを表す状態ファイルを維持する。applyを実行すると、Terraformは状態ファイルと設定を比較し、現実を設定に合わせるための最小限の変更セットを作成する。

AWSコンソールでクリックしてリソースを作成・変更すると、状態ファイルを変更せずに現実を変更していることになる。

すると: 次のplanでドリフトが表示される。Terraformは「存在すべきでない」リソース（設定にないため）を破棄または再作成しようとする。

あるいはさらに悪いことに: Terraformの状態にはリソースが設定Aで存在するとあるが、コンソールで設定Bに変更された。設定ミスがあるにもかかわらずplanは「変更なし」と表示する。

または: 誰かがコンソールでリソースを追加し、それが動作し、他のリソースから依存されるようになり、その後applyが実行されて状態にないため削除される。

コンソールは真実のソースではない。あなたのIaCがそうだ。コンソールは嘘だ。

インポートワークフロー: 「すでに存在する」への正しい対応

リソースがAWSに存在するがTerraform設定にない場合（誰かがコンソールで作成、CLIで手動作成、または別のツールから移行されたもの）、正しい対応はインポートすることだ:

既存のリソースをTerraform状態にインポートする

./deploy.sh --infra --import aws_s3_bucket.service existing-bucket-name
./deploy.sh --infra --import aws_dynamodb_table.service_files serviceFiles
./deploy.sh --infra --import aws_lambda_function.service_api myapp-service-api

インポート後、planを実行する:
./deploy.sh --infra

planはAWSに存在するものと設定が言っていることの差分を表示する。予期しない変更が表示されなくなるまで設定を修正する。それからapplyして状態ファイルを同期させる。

コンソールからリソースを削除してTerraformで再作成してはいけない。これはデータを破壊し、依存関係を壊す。インポート → 調整 → apply。

唯一の正当なコンソール使用

コンソールが適切なのは:

読み取り専用の探索。CloudWatchログ、CloudWatchメトリクス、Lambda呼び出し履歴、DynamoDB項目の検査。
即時インポートを伴う緊急操作。本番がダウンしていて修正にコンソールの変更が必要な場合、変更を行う。ただし文書化し、同じ作業セッション内でTerraformにインポートする。

以上だ。リソースを作成、変更、削除するすべてのものはIaCに属する。

デプロイスクリプトを唯一のエントリポイントに

ホスト上で直接実行される生のterraform applyやtofu applyコマンドは、チームの標準デプロイワークフロー（バリデーション、lint、planレビュー）をバイパスするため危険だ。すべてのTerraform操作をラップするデプロイスクリプトを作成する:

#!/bin/bash
# deploy.sh - the only way to interact with infrastructure
case “$1” in
–infra)
case “$2” in
–apply) run_apply ;;
–plan) run_plan ;;
–validate) run_validate ;;
–tflint) run_tflint ;;
–import) run_import “$3” “$4” ;;
*) run_plan ;; # default: plan only (safe)
esac
;;
esac

Google Pixel 9 XL Proを6階のバルコニーから通りに落とした

Sun, 01 Feb 2026 02:14:25 +0300

重力 1 – Google Pixel 9 Pro XL 0

今夜、友達の家に行った。素晴らしい会話、良い笑い、物理法則への意識ゼロ。家に着いたのは午前2時、自信が高く握力が低い危険な時間だった。

いつものように、寝る前に素敵なバルコニーに出て新鮮な空気を吸った。電話を手に持って。
最初はメッセージの返信をしていた。普通の生活のこと。とても安全。とても制御されている。

それから顔を上げた。月が素晴らしかった。「うん、これは写真に値する」と思うような夜の一つだった。

だから握りをわずかに調整し、電話をカメラモードに切り替え、少し身を乗り出した...

そしてその正確な瞬間に、重力が私を思い出した。

私は静かに言った:

「ああ...ここから電話を落としたらどうなるかずっと気になっていた。」

好奇心はすぐに答えられた。真夜中に。コンクリートで。

Google Pixel 9 XL Proは重力よりも強い

軽い不信感を抱きながら階下に走っていると、非現実的なことに気付いた:

Sony WH-1000XM6ヘッドフォンがまだBluetoothで接続されていた。

音はまだ再生されていた。電話はまだ生きていた。まるで跳ね返って「終わった？」と言ったかのように。

拾い上げた。

画面: 生きている
デッドピクセルなし
傷だけ
ベゼルが割れた
背面ガラスがモダンアートに粉砕
カメラカバーが劇的に飛び出した

カメラ？動く。
フレックスケーブル？まだ忠実。

これは机からでもポケットからでもなく、6階から落ちたのだ。

Samsung時代: Android 1.5からGalaxy S21 Ultraまで

はっきりさせよう: 私はAndroidに慣れていないわけではない。

2009年のAndroid 1.5（Cupcake）から、伝説のSamsung GT-I7500でSamsung Androidフォンを使ってきた。

それ以来、経験してきたもの:

Android 1.5 Cupcake
2.1 Eclair
2.3 Gingerbread
4.x Ice Cream Sandwich & Jelly Bean
5.x Lollipop
6 Marshmallow
7 Nougat
8 Oreo
9 Pie
10
11
12
Samsung Galaxy S21 Ultraまで

これは一部の人が持つメールアドレスの数よりも多いAndroidバージョンだ。

AWS S3の新機能: 移動なしの再暗号化

Fri, 30 Jan 2026 11:51:05 +0300

UpdateObjectEncryption APIのリリースは、大規模なデータセキュリティ管理における大きな転換点となる。従来、S3オブジェクトの暗号化を変更することは「物理的な」操作であり、ビットを移動する必要があった。今やそれは「論理的な」メタデータ操作となった。

技術詳細: 移動なしの再暗号化

この更新の背後にある「魔法」はエンベロープ暗号化にある。従来のCopyObjectワークフローでは、S3は古い鍵で実際のデータを復号し、新しい鍵で再暗号化して、事実上新しいファイルを作成する必要があった。

UpdateObjectEncryption APIでは、S3は基盤となるデータブロックに触れない。代わりに、データキー（DK）のみとやり取りする。

S3はオブジェクトのメタデータに保存されている暗号化されたデータキーを取得する。
古いマスターキーを使用してそのデータキーを復号する。
同じデータキーを新しいKMSマスターキーで直ちに再暗号化する。
オブジェクトのメタデータが新しい暗号化データキーでアトミックに更新される。

データ自体（暗号文）は同一のままなので、ETag（データのハッシュ）と作成日はまったく変わらない。

長所と短所

長所

データのゼロレイテンシ: データが移動されないため、ファイルサイズに関係なく（1KBから5TBまで）操作はミリ秒で完了する。
ストレージ整合性: Last-Modified日付、ETag、Version IDが保持される。これはキャッシュ検証にETagを使用するアプリケーションにとって重要だ。
アーカイブ対応: Glacierオブジェクトを事前に「復元」することなく暗号化をアップグレードできる。コールドストレージに置いたままでよい。
コスト効率: コピーに関連するデータ取得料金（GET）とデータ転送料金を回避できる。API呼び出し（PUT価格）の支払いのみで済む。
Intelligent-Tieringの安全性: S3 Intelligent-TieringのオブジェクトがFrequent Accessティアに「リセット」されることがなく、コスト最適化の進行状況が保持される。

短所

KMSのみ: SSE-KMSへの更新のみ可能。SSE-CやDSSE-KMSはサポートしない。
「非暗号化」は非サポート: ソースオブジェクトは必ず既に暗号化されている必要がある（SSE-S3またはSSE-KMS）。稀なレガシー「プレーンテキスト」オブジェクトの場合、このAPIは失敗する。
Object Lockの壁: オブジェクトがリーガルホールドまたは保持モードにある場合、ロックが解除されるまで暗号化を更新できない。
KMS ARNの要件: KMSキーエイリアスは使用できず、完全なAmazon Resource Name（ARN）を提供する必要がある。

比較: `UpdateObjectEncryption` vs. `CopyObject`

機能	UpdateObjectEncryption（新）	CopyObject（レガシー）
データ移動	なし（メタデータ更新のみ）	完全なデータコピー
オブジェクトメタデータ	保持（ETag、作成日）	リセット（新しいETag、新しい日付）
Glacierサポート	アーカイブ中でも動作	最初に「復元」が必要
スループット	高い（アトミック/即時）	オブジェクトサイズ/帯域幅に制限される
コスト	PUTリクエストのみ（$0.005/1k）	GET + PUT + データ取得料金
Object Lock	ブロックされる	新しいバージョンを作成（バージョニング有効時）

判断ガイド: どちらを選ぶべきか？

1. `UpdateObjectEncryption`を使用するケース:

状況: コンプライアンス監査。規制要件を満たすために、AWS管理キー（SSE-S3）からカスタマー管理キー（SSE-KMS）に切り替える必要がある。
状況: アーカイブデータ。復元の膨大なコストをかけずに暗号化アップグレードが必要なGlacier Deep Archive内のペタバイト級のデータがある。
状況: 巨大オブジェクト。コピー操作に数時間かかりタイムアウトのリスクがある5TBのオブジェクトがある。
状況: ETag依存。アプリケーションロジックが同期/キャッシングのためにETagの不変性に依存している。

2. `CopyObject`を使用するケース:

状況: 暗号化されていないソース。全く暗号化されていない非常に古いオブジェクトを扱っている。
状況: クロスリージョン/アカウント。暗号化を変更しながらデータを別のバケットやリージョンに移動する必要がある。
状況: SSE-C要件。新しいAPIがサポートしていないカスタマー提供キー（SSE-C）を使用する必要がある。
状況: ロックされたオブジェクト。永続的にロックされたオブジェクト（コンプライアンスモード）の暗号化を更新する必要がある。この場合、新しいコピー/バージョンが唯一の手段となる。

大規模環境での注意点: 数百万のオブジェクトを扱う場合、このAPIをループで呼び出してはいけない。S3 Batch Operationsを使用すること。AWSはこの新しいAPIをBatchコンソールに直接統合しており、数クリックでバケット全体に対して「再暗号化」ジョブを実行できる。

ノイズなしでドナルド・トランプを追跡するためにTrumpDailyを作った

Thu, 22 Jan 2026 23:11:48 +0300

率直に言って、トランプを追跡するのは疲れる。彼はBBC、Guardian、NPR、Al Jazeera、Babylon Beeまでもの見出しを支配している。毎日10以上のサイトをチェック？お断りだ。だからTrump Dailyを作った！すべてを1つのクリーンなインターフェースに集約するセルフホストのRSSアグリゲーターだ。https://trumpdaily.siteが誕生した！

正直なところ、これはここ数年で数ヶ月間で一番楽しかったコーディングだった。

技術スタック（あるいは: なぜ退屈な技術を選んだか）

バックエンド: Python/Flask（そう、大好きだ！）
データベース: PostgreSQL
キャッシュ: Redis（文字通りすべてに）
タスク: Celery（バックグラウンドRSS取得）
フロントエンド: Vanilla JS（Reactなし、異論は受け付ける）
デプロイ: Docker Compose（1コマンドで完了）

全体で約1,000行のPythonと400行のJavaScript。ローカルで実行。トラッキングなし（Google Analyticsのみ）。クラウド費用なし。無駄なし。

仕組み

RSSフィード → Celery → キーワード → PostgreSQL → Flask API → ブラウザ
 ↓
 (Funny? Political? Serious?)

5分ごとに、Celeryがフィードを取得し、キーワードマッチングを使用して記事をカテゴリ分けする:

"investigation" + "indictment" = Serious
"ridiculous" + "bizarre" = Funny
"tariff" + "trade war" = Economic

シンプルな正規表現、約85%の精度。ML不要。

なぜこれが途方もなく楽しかったのか

1. 実際に動作する
埃をかぶるほとんどのサイドプロジェクトとは異なり、毎朝これを使っている。本当に必要なものを作るのは感覚が違う。

2. Vanilla JSは解放的
webpackなし。babelなし。500MBのnode_modulesなし。瞬時にロードされるたった400行のJavaScript。フロントエンドはクライアントサイドで500以上の記事を苦もなくフィルタリングする。

3. Docker Composeは魔法
1つのdocker compose up -dで5つのサービス（nginx、flask、postgres、redis、celery）が起動する。設定地獄ゼロ。

4. Pythonは仕事を成し遂げる
週末プロジェクト→3日で動作するプロトタイプ。エコシステム（feedparser、SQLAlchemy、Celery）がただ動く。ライブラリのバグゼロ。

SpotifyのInstagram共有フローが無料のビルボードになった時

Tue, 09 Dec 2025 01:11:36 +0300

今週初め、Fusun Onal - Ah Nerede（2004年リリース）をInstagram Storiesで共有しようとした。

Spotifyからシェア、Instagramへ。誰もが何千回もやっていることだ。

しかしアルバムカバーの代わりに、Instagramは全く関係ない人のInstagramプロフィールのスクリーンショットを開いた。私のものでもSpotifyのものでもない。本質的に他人の無料広告だ。

そしてそれはグリッチのようには見えなかった。注入されたように見えた。

不審なアプリはない。デバイスの侵害もない。唯一普通でなかったのは、Spotifyが生成する「共有画像」がすり替えられていたことだ。

これは些細な奇妙さに聞こえるかもしれないが、そうではない。信頼されたクロスプラットフォームのメディアパイプラインが脆弱である可能性を示すシグナルだ。

どうしてこれが起こり得るのか？

Spotifyが共有アセットをどのように構成し、Instagramがサードパーティメディアをどのように取り込むかに基づいて、最も現実的な経路は以下の通り。操作されたメディアエンドポイントを介した共有アセットの注入、レガシートラックのメタデータポイズニング、古いコンテンツパイプラインの悪用などが考えられる。

なぜこれがセキュリティ問題なのか（単なる面白いグリッチではない）

侵害された共有フローは攻撃者に即時のリーチ、ゼロ摩擦の配信、信頼された配置、完璧な増幅を提供する。フィッシング画像やQRコードなどにエスカレーションすれば、ソーシャルエンジニアリングの金鉱になる。

技術的内訳

Spotifyのフロー: ユーザーが共有をタップ → Spotifyがプレビューアセットを生成/取得 → 構造化されたインテント+画像をInstagramに送信 → Instagramがストーリーテンプレートにインポート。ステップ2が侵害されれば、下流のすべてが悪意のあるアセットを継承する。InstagramはSpotifyが送信するメディアを信頼しており、「この画像は本当にこのトラックを表しているのか？」という検証メカニズムがない。その信頼こそが脆弱性全体だ。

最も可能性の高い弱点: 異常または不正なメタデータと共に保存された古いカタログエントリで、Spotifyの新しいパイプラインが依然として尊重しているもの。social_share_image_url = https://attackercdn.com/injected.jpgのようなものだ。

緩和策: 厳格なソース検証、レガシーアセットの再生成、メタデータのサニタイズ、共有アセット整合性トークンなどが考えられる。

モダンなソーシャル機能は、何年も誰も監査していないレガシーメタデータの上に構築されている。そして誰かが単一のトラックのメタデータでグローバル音楽プラットフォームの共有パイプラインをハイジャックできるなら、私たちにはバグではなく攻撃対象領域がある。

参考資料

AWS Monthly (Nov '25): ステートフルサーバーレス革命

Sun, 30 Nov 2025 20:21:43 +0300

11月とre:Invent 2025はサーバーレスの「聖杯」をもたらした。AWS Lambda Durable Functionsだ。

この機能は「ステートフルサーバーレス」をLambdaランタイムに直接導入する。新しいwithDurableExecutionラッパーを使用することで、1年間持続する長時間実行ワークフローを記述できるようになった。関数がcontext.wait()呼び出しに到達すると、コンピュートは中断され、課金も停止する。イベントまたは人間の承認が再開するまで。

これは事実上、多くの複雑なStep Functionsのユースケースを、純粋でテスト可能なコードに置き換える。さらにGraviton5も登場した。Graviton4より25%高速で、Nitro Isolation Engineを搭載する。このエンジンは形式検証を使用してワークロード分離の数学的証明を提供する。

11月は「サーバーレス」と「インフラストラクチャ」の境界線が公式に消滅したことを証明した。今や全ては単なる「インテント」だ。

クラウドがくしゃみをすると、世界が風邪をひく - us-east-1メルトダウンからの教訓

Mon, 20 Oct 2025 10:05:41 +0300

今日、再びインターネットの半分がダークになった。世界的な電力障害やサイバー攻撃のせいではなく、単一のAWSリージョンであるus-east-1（N. Virginia）が悪い日を過ごしたからだ。

Perplexityがダウンした。Amazon自身もつまずいた。Substack、Signal、Fortnite、その他無数のサービスが虚空に消えた。企業が顧客に「ダウンしています！」と伝えるために使うStatuspage.ioのようなサービスでさえ、自身のステータスページを更新できなかった。彼らも同じ壊れたバックボーンに依存しているからだ。これは皮肉の定義である。

そして単一障害点の世界の定義でもある。

「グローバル」クラウドの幻想

私たちはインターネットが分散化され、どこにでもあり、回復力があり、止められないものだと思いたがる。しかしバージニアのデータセンターがくしゃみをすると、ヨーロッパ、アジア、アフリカが肺炎になる。
それは実際には、「グローバル」ウェブが一握りの米国クラウドリージョン、中でもインターネットのバックボーンサービスの多くを静かに動かしているAWS us-east-1を通過しているからだ。

考えてみれば馬鹿げている: 数十億人のデジタルライフが、一つの企業によって維持される一つの国の一つの物理的な場所にかかっているのだ。グローバリゼーションは皮肉にも想像しうる最も回復力のないシステム、すべてが集中化され相互接続され少数のメガプロバイダーに完全に依存するシステムを作り出した。

目覚めの呼び声

今日のAWS障害は単なる運用上の小さな乱れではなく、目覚めの呼び声だ。

クラウドは空ではないということを思い出させるものだ。それは単に他人のコンピュータであり、バージニアの建物の中に座っていて、壊れるハードウェア、誤動作するDNS、ミスをする人間の上で動いているのだ。真にグローバルで回復力のあるインターネットが欲しいなら、独占企業を崇拝するのをやめ、独立性を再構築し始める必要がある。
なぜなら、クラウドがくしゃみをしたとき、私たち全員が息を止めなければならないべきではないからだ。

少しの皮肉と多くの不満、そして回復力のあるアーキテクチャへの深い愛情を込めて書かれた。
- Ercan Ermis

この記事で予告したフォローアップを公開した。The Fix Shares Fate With the Outageでは、同じ障害が復旧に使うはずのツールまで巻き込んだ理由を扱う。

AWS Monthly (Sep '25): Vega OS & eBPFオブザーバビリティ

Tue, 30 Sep 2025 20:16:41 +0300

9月、AWSはVega OSをリリースした。Vegaはエッジと高性能UIレンダリング（React Nativeコア搭載）に最適化された、Linuxベースの特化型OSだ。超軽量でミリ秒単位の起動を実現し、次世代スマートデバイスに最適だ。

オブザーバビリティ面では、eBPF（Extended Berkeley Packet Filter）を使用した自動検出機能を備えたCloudWatch Application Map 2.0が登場した。これにより、計装コードを一行も書くことなく、計装されていないレガシーサービスやサードパーティAPI呼び出しを含むサービス全体のトポロジーをAWSがマッピングできる。

ドキュメントが現実に追いついていない「スパゲッティ」アーキテクチャを抱えているなら、このツールは環境内のすべてのパケットフローを数学的に正確なマップとして提供する。9月は「シャドーIT」の完全な透明性をついに手に入れた月だった。

AWS Monthly (Aug '25): ビッグデータ、ゼロ努力

Sun, 31 Aug 2025 20:14:51 +0300

8月は「データ重力」がテーマだった。Amazon Auroraのストレージ上限が256 TiBに引き上げられ、99.9%の企業にとって「シャーディング」の議論が事実上終了した。

しかし、真の主役はZero-ETL統合の拡張だった。AWSはAuroraからOpenSearchへ、そしてRDSからRedshiftへのシームレスでほぼリアルタイムのレプリケーションを可能にした。データベースの内部トランザクションログを活用することで、AWSはソースデータベースのコンピュートに影響を与えることなく、分析エンジンにデータをレプリケートする。

データエンジニアにとって、これは単純な同期タスクのための脆弱なPython/Glue ETLパイプラインの終焉を意味する。DynamoDBにも「属性ベースのアクセス制御」（ABAC）が導入され、複雑なIAMポリシーではなくタグを通じて権限を管理できるようになった。

8月は、データの未来が「データを移動すること」ではなく、「データがある場所でそのままアクセス可能にすること」にあることを証明した。

AWS Monthly (July '25): 正気の限界でのKubernetes

Thu, 31 Jul 2025 20:13:00 +0300

7月はEKS（Elastic Kubernetes Service）コミュニティにとって画期的な月だった。AWSはEKSが10万ノードクラスタをサポートするようになったと発表した。

10万ノードは我々のほとんどにとってオーバーキルかもしれないが、その規模でKubernetesコントロールプレーンを安定させるために必要な技術的最適化は、全員に恩恵をもたらす。スケジューラは高速化され、ETCDのパフォーマンスはより回復力が増した。

しかし真のゲームチェンジャーはEKS Auto Modeだった。これはKubernetesの「No-Ops」進化だ。Node GroupsやKarpenterさえ管理する必要がなくなる。AWSがワーカープレーンを完全に管理し、Podの要件に基づいてリアルタイムで最適なインスタンスタイプを選択する。

「運用コスト」を理由にKubernetesを避けてきたなら、7月はそのコストが大幅に削減された月だ。真にサーバーレスなK8s体験にこれまでで最も近づいたと言える。

AWS Monthly (May '25): ウォールームの終焉

Sat, 31 May 2025 20:00:00 +0300

5月に登場したCloudWatch Investigationsは、オンコール当番を根本的に変えた。手動でのログ相関の代わりに、このサービスはAIを使って自動根本原因分析（RCA）を実行する。

アラームがトリガーされると、Investigationsは自動的にエラーを追跡する。メトリクスのスパイクを同時発生イベント（特定のGitコミット、Terraform apply、RDSパラメータ変更など）と相関させる。「500エラー」を示すダッシュボードではなく、次のようなレポートが届く: 「サービスAのレイテンシスパイクは、サービスBの設定変更によってRDSでコネクションリークが発生したことが原因です。」

CloudWatch RUM Session Replayと組み合わせることで、クラッシュに至るまでのユーザーの操作を視覚的に再現できるようになった。これは事実上、インフラストラクチャの「タイムマシン」だ。インシデント発生時にまだ手動でログを掘っているなら、5月があなたに週末を取り戻してくれた。

PythonとBoto3を使ったAWS CloudWatchロググループのタグ付け自動化

Wed, 16 Apr 2025 08:01:03 +0300

AWS CloudWatchロググループのタグ管理は、運用の可視性、コスト管理、効果的なリソース整理に不可欠だ。ロググループの手動タグ付けは、特に多数のロググループを扱う場合に面倒になりがちだ。この記事では、PythonとAWS SDK for Python（Boto3）を使用してこのタスクを自動化する簡単な方法を解説する。

CloudWatchロググループのタグ付け自動化の重要性

自動化が保証するもの:

AWSリソース全体での一貫したタグ付け
手動作業とヒューマンエラーの削減
コストと使用量の正確な追跡能力の向上

前提条件

Python 3がインストール済み
適切な権限でAWS CLIが設定済み
Boto3（pip install boto3）
IAM権限:
- logs:DescribeLogGroups
- logs:ListTagsLogGroup
- logs:TagLogGroup

CloudWatchロググループのタグ付け用Pythonスクリプト

以下は、現在タグのないAWS CloudWatchロググループに特定のタグを自動的に適用するPythonスクリプトだ。

Pythonスクリプト

import boto3
AWS_REGION = ‘us-east-1’ # 自分のリージョンに置き換える
適用するタグ
TAGS_TO_APPLY = {
‘deployed_via’: ‘manual’,
’env_name’: ‘development’,
‘projectid’: ‘ID-12345’,
}
def tag_cloudwatch_log_groups():
logs_client = boto3.client(’logs’, region_name=AWS_REGION)
paginator = logs_client.get_paginator('describe_log_groups')
for page in paginator.paginate():
 for log_group in page&#91;'logGroups']:
 log_group_name = log_group&#91;'logGroupName']
 existing_tags = logs_client.list_tags_log_group(logGroupName=log_group_name).get('tags', {})

 if not existing_tags:
 print(f"Adding tags to log group '{log_group_name}'")
 logs_client.tag_log_group(
 logGroupName=log_group_name,
 tags=TAGS_TO_APPLY
 )
 else:
 print(f"Log group '{log_group_name}' already has tags. Skipping.")

if name == ‘main’:
tag_cloudwatch_log_groups()

PythonとBoto3を使ったAWS ECRタグ付けの自動化

Tue, 15 Apr 2025 09:03:02 +0300

AWSリソースの適切なタグ付けは、効率的なリソース管理、コスト配分、監査に不可欠だ。多数のAWS Elastic Container Registry（ECR）リポジトリがある場合、手動でのタグ付けは退屈でエラーが発生しやすい。この記事ではシンプルで効果的なソリューションを提供する。PythonとAWS SDK for Python（Boto3）を使用したECRリポジトリのタグ付けの自動化だ。

タグ付けを自動化する理由

タグ付けの自動化は時間を節約し、一貫性を確保し、コストのかかるミスを防ぐ。タグは特定のプロジェクト、環境、コストセンターに関連するリソースを追跡するのに役立つ。

前提条件

Python 3がインストール済み
AWS CLIがインストール・設定済み
Boto3ライブラリがインストール済み（pip install boto3）
IAM権限:
- ecr:DescribeRepositories
- ecr:ListTagsForResource
- ecr:TagResource

Pythonを使ったAWS ECRリポジトリのタグ付け

以下は、Boto3を使用してすべてのECRリポジトリのうち現在タグのないものに事前定義されたタグを追加する簡単なPythonスクリプトだ。

Pythonスクリプト

import boto3
AWS_REGION = ’eu-central-1’ # 自分のリージョンに置き換える
タグを定義する
TAGS_TO_APPLY = [
{‘Key’: ‘provisioned’, ‘Value’: ‘manual’},
{‘Key’: ’environment’, ‘Value’: ‘dev’},
{‘Key’: ‘project’, ‘Value’: ‘Project_Name’},
]
def tag_ecr_repositories():
ecr_client = boto3.client(’ecr’, region_name=AWS_REGION)
paginator = ecr_client.get_paginator('describe_repositories')
for page in paginator.paginate():
 for repo in page&#91;'repositories']:
 repo_arn = repo&#91;'repositoryArn']
 repo_name = repo&#91;'repositoryName']

 existing_tags = ecr_client.list_tags_for_resource(resourceArn=repo_arn).get('tags', &#91;])

 if not existing_tags:
 print(f"Adding tags to repository '{repo_name}'")
 ecr_client.tag_resource(resourceArn=repo_arn, tags=TAGS_TO_APPLY)
 else:
 print(f"Repository '{repo_name}' already has tags. Skipping.")

if name == ‘main’:
tag_ecr_repositories()

Bashを使ったECRイメージクリーンアップの自動化

Fri, 11 Apr 2025 12:40:42 +0300

Amazon ECR（Elastic Container Registry）でのコンテナイメージの管理は、レジストリをクリーンでコスト効率の高い状態に保つために重要だ。時間が経つにつれて、未使用や非推奨のイメージが蓄積され、ストレージコストの増加や運用オーバーヘッドにつながる可能性がある。よくあるシナリオの一つは、特定のタグ付けパターンに従うイメージの削除だ。ここでは「9.x.x」形式（xは1桁以上の数字）のバージョンでタグ付けされたイメージが対象となる。

この記事では、ECRイメージのクリーンアップを自動化するために設計されたBashスクリプトを紹介する。このスクリプトはdry-runとapplyの2つのメインモードを提供し、ニーズに基づいて削除をシミュレートまたは実行できる。

スクリプト概要

このBashスクリプトはAWS CLIとjq（軽量で柔軟なコマンドラインJSONプロセッサ）を活用して以下を行う:

全ECRリポジトリの一覧表示:
アカウント内のすべての利用可能なECRリポジトリをAWSにクエリする。
イメージとタグの取得:
各リポジトリについて、イメージの詳細（イメージダイジェストとタグを含む）を一覧表示する。
タグフィルタリングの適用:
正規表現（^9\.[0-9]+\.[0-9]+$）を使用して、「9.x.x」形式（例: "9.0.1" や "9.12.3"）に一致するタグを持つイメージを見つける。
動作モード:
- Dry Run（--dry-run）: スクリプトは削除されるイメージを一覧表示するだけで、リスクなくどのイメージが削除対象になるかを確認する機会を提供する。
- Apply（--apply）: 特定されたイメージを実際にリポジトリから削除する。
使用方法の情報:
有効な引数なしでスクリプトが実行された場合、利用可能なオプションを説明するヘルプメッセージを出力する。

主な機能

1. 自動リポジトリ検出

機能:
スクリプトは手動入力やリポジトリ名のハードコーディングを必要とせず、利用可能なすべてのECRリポジトリを動的に取得する。
利点:
これにより、追加設定なしでアカウントのリポジトリリストの変更に対応でき、スクリプトのスケーラビリティと適応性が確保される。

2. 正規表現による柔軟なタグフィルタリング

機能:
9.で始まり、ピリオドで区切られたさらに2つの数字グループが続くバージョンタグに正規表現でマッチさせる。
利点:
正規表現ベースのアプローチにより、どのイメージをターゲットにすべきかを正確に制御できる。命名規則を維持し、特定の古くなった、または非推奨のバージョニングパターンに適合するイメージをクリーンアップできる。

3. デュアルモード動作（Dry-Run vs. Apply）

機能:
スクリプトはコマンドライン引数を受け取り、削除をシミュレートするか（--dry-run）、実際に実行するか（--apply）を選択する。
利点:
このデュアルモードアプローチは、破壊的なアクションを実行する前に影響を確認できる安全性を提供する。本番に近い環境で最初にスクリプトをテストする必要がある管理者にとって価値ある機能だ。

4. 堅牢なエラーハンドリングとストリクトモード

機能:
スクリプトはBashのset -euo pipefailを使用して厳格なエラーチェックを強制する。この設定により、エラー発生時、未設定変数の参照時、パイプライン内のいずれかのコマンドが失敗した場合にスクリプトの実行が停止する。
利点:
不完全な操作や予測不可能なスクリプト動作のリスクを最小化し、より信頼性の高い実行環境を促進する。

5. 明確な使用方法のドキュメント

機能:
誤った引数または引数なしで実行された場合、明確な使用方法の指示と各モードの説明を含むヘルプメッセージを表示する。
利点:
ユーザーエラーの削減に役立ち、スクリプトの操作方法を明確にする。経験の浅いユーザーにとってもアクセスしやすくなる。

長所と短所

長所

安全性と予測可能性:
dry-runモードの搭載により、管理者は削除を実行する前に変更をプレビューでき、偶発的なデータ損失のリスクを軽減する。
自動検出:
全リポジトリの自動クエリにより管理が簡素化され、包括的なクリーンアップが保証される。
正規表現ベースのフィルタリング:
タグフィルタリングのための堅牢な正規表現により、バージョンパターンに基づいて特定のイメージを簡単にターゲットできる。
シンプルさと拡張性:
Bashで記述されているため、スクリプトは理解も修正も簡単だ。そのストレートな構造により、追加ニーズに合わせたさらなるカスタマイズが容易になる。
堅牢なエラーハンドリング:
スクリプトのエラーハンドリングメカニズム（set -euo pipefailの使用）は、予期しないエラーで実行を停止することで信頼性を高める。

短所

AWS CLIとjqへの依存:
スクリプトはAWS CLIとjqの両方が正しくインストール・設定されている必要がある。これらのツールがプリインストールされていない環境では、追加のセットアップが必要だ。
限定的な正規表現の柔軟性:
現在の正規表現は「9.x.x」バージョンにマッチするよう特別に調整されている。バージョニングスキームが変更された場合、それに応じて正規表現を調整する必要があり、更新しない限りスクリプトの柔軟性は低くなる。
過剰削除の可能性:
イメージが複数の値でタグ付けされており、そのうちの1つが正規表現に一致する場合、削除コマンドはそのイメージに対して実行される。本番環境で削除モードを使用する際は特に注意が必要だ。
ロールバックメカニズムがない:
一度イメージが削除されると（--applyモード）、復旧は簡単ではない。管理者は偶発的な削除に備えてバックアップやバージョン管理の手段を用意しておく必要がある。
冗長なログ出力:
スクリプトは処理された各イメージについてメッセージを表示するため、イメージ数が多い環境では圧倒される可能性がある。より簡潔なログアプローチに改善できる可能性がある。

ベストプラクティスと推奨事項

まずステージング環境でテストする:
常に--dry-runモードでステージング環境でスクリプトを実行し、ターゲットイメージを正しく特定できることを確認する。
バックアップを実装する:
変更をロールバックする必要があるリスクに備えて、イメージが適切にバックアップまたはバージョン管理されていることを確認する。
ログを監視する:
このスクリプトを定期的に（cron経由などで）実行する予定がある場合、出力ログをファイルにリダイレクトし、ログローテーションを実装することを検討する。
定期的な更新:
ECRの使用状況やイメージタグ付け戦略が変更されるたびに、スクリプトをレビューしてテストする。
必要に応じて正規表現を微調整する:
バージョニングシステムが進化したり、新しいタグ付け規則を導入したりした場合は、正規表現パターンを調整する。

スクリプト

#!/bin/bash
# This script processes all ECR repositories and their images, checks for image tags matching the pattern "9.x.x"
# (where x represents one or more digits), and then either lists (dry run) or deletes (apply) those images.
#
# Usage:
# ./cleanup_ecr.sh --dry-run # Lists images that would be deleted without performing deletion.
# ./cleanup_ecr.sh --apply # Deletes images with tags matching "9.x.x".
# ./cleanup_ecr.sh # Displays this help message.
set -euo pipefail



BashスクリプトでECRリポジトリを更新する
Tue, 08 Apr 2025 10:05:29 +0300
以下はAWS CLIを使用してすべてのAmazon ECRリポジトリを取得し、各リポジトリのイメージタグの変更可能性をMUTABLEに設定するBashスクリプトの例だ。スクリプトを実行する前に、AWS CLIがインストールされ適切な権限で設定されていることを確認すること。
#!/bin/bash
repositories=$(aws ecr describe-repositories --query "repositories[].repositoryName" --output text)
if [ -z "$repositories" ]; then
 echo "No ECR repositories found."
 exit 1
fi
for repo in $repositories; do
 echo "Setting image tag mutability to MUTABLE for repository: $repo"
 aws ecr put-image-tag-mutability --repository-name "$repo" --image-tag-mutability MUTABLE | tee
 if [ $? -eq 0 ]; then
 echo "Successfully updated $repo"
 else
 echo "Failed to update $repo"
 fi
done
このスクリプトは、すべてのリポジトリがイメージタグに関して変更可能であることを保証するプロセスを自動化し、将来の更新やタグ付けの変更を可能にする。必要なIAM権限: describe-repositoriesおよびput-image-tag-mutability。


CI/CDパイプラインと開発フローにおいて自動テストが不可欠な理由
Sun, 06 Apr 2025 06:44:11 +0300
誰もが経験したことのあるシナリオについて話そう: 新しい機能を完成させ、マージしようとワクワクしていると、本番でローカル環境ではキャッチできなかった何かが壊れる。これは避けたい悪夢のような話だ。ここで自動テストが、特にCI/CDパイプラインの中で真価を発揮する。
1. バグの早期発見
パイプラインにテストがある最大の利点の一つは、問題を早期にキャッチできることだ。多くの場合本番に到達する前に。コードをメインブランチにマージしてからバグを発見するのを待つと、何かがおかしいと気付くまでに数時間（または数日）かかる可能性がある。プッシュやプルリクエストごとにトリガーされる自動テストは、何かが脱線した場合に即座に知らせてくれる。
2. デプロイへの自信
堅牢な自動テストスイートがあれば、はるかに自信を持ってデプロイできる。本番にプッシュするたびに指を交差させる代わりに、テストスイートに頼って根本的に壊れているかどうかを知ることができる。これは複数の開発者が同じコードベースに変更をマージしている大規模チームにとって特に重要だ。
3. リグレッション防止
すべてのコード変更には、以前動作していたものを壊す可能性がある。E2Eテストは最初から最後まで実際のユーザーインタラクションを模倣するため、リグレッションをキャッチするのに特に優れている。またテストはアプリケーションの機能に関する生きたドキュメントと考えることができる。
4-5. 合理化された開発フロー、スケーラビリティと保守性
自動化は大惨事を防ぐだけでなく、関係者全員の生活を楽にする。タイトなフィードバックループ、環境間の一貫性、容易なオンボーディング、将来を見据えたアプリケーションなどが実現される。
結論
テストは単にチェックを入れるボックスではない。信頼性が高くスケーラブルで保守可能なアプリケーションの基盤だ。CI/CDパイプラインに自動テストを統合することで、バグを早期にキャッチし、リグレッションを防ぎ、より効果的にコラボレーションし、自信を持ってデプロイできる。CI/CDパイプライン内の自動テストは単なるベストプラクティスではなく、現代のソフトウェアチームにとって実質的に超能力だ。


AWS Monthly (April '25): AIの発熱を冷ます
Mon, 31 Mar 2025 19:59:00 +0300
4月、AWSはデータセンターエンジニアリングの舞台裏を垣間見せてくれた。最新のAIクラスタの熱出力に対応するため、Direct-to-Chip液冷が発表された。
これは単なるハードウェアの好奇心ではない。パフォーマンスの観点から、液冷はラックあたり3倍のコンピュート密度を可能にする。TrainiumやInferentiaのようなカスタムシリコンが、空冷環境でしばしば発生するサーマルスロットリングなしに、長時間のトレーニングジョブでピーククロック速度を維持できるようになる。
EC2 UltraClusters 2.0も発表され、Elastic Fabric Adapter（EFA）経由のノンブロッキング ペタビット級ネットワーキングをサポートする。数兆パラメータのモデルを分散トレーニングしている場合、ノード間の通信ボトルネックは事実上解消された。
4月は「クラウド」が最終的に物理法則に制限されること、そしてAWSがAIに追いつくために文字通りインターネットの配管を再設計していることを思い出させてくれた。


AWS Monthly (Mar '25): 近接性のパワープレイ
Mon, 31 Mar 2025 19:51:00 +0300
3月はクラウドの物理的基盤についての月だった。AWSは1000億ドルのグローバル投資を発表し、我々にとっては20以上の新しいLocal Zonesが稼働開始したことを意味した。
技術的には、これによりほぼすべての主要テクノロジーハブに「1桁ミリ秒のレイテンシ」がもたらされる。AR/VRバックエンド、産業用IoT、サブミリ秒のテレメトリシステムを構築している場合、「シリコンまでの距離」が短縮されたことになる。「中央リージョン」からより分散化された「エッジファースト」アーキテクチャへの移行が見られる。
ネットワーキング面では、VPC Latticeが重要なアップデートを受けた。Cross Account Trust Labelsだ。これにより、脆弱なIPレンジや複雑なピアリングではなく、論理的なメタデータに基づいてサービス間通信ポリシーを定義できるようになる。マルチアカウントガバナンスにとって大きな勝利だ。
最近VPC Latticeを見ていないなら、このアップデートにより、Istioの運用オーバーヘッドなしにエンタープライズスケールのネットワーキングのための「サービスメッシュ」として選ばれる存在になった。


この強力なBashスクリプトでAWS ECR管理を効率化する
Thu, 27 Mar 2025 06:32:10 +0300
AWS ECR（Elastic Container Registry）でのコンテナリポジトリの管理は、特にインフラストラクチャが成長するにつれてすぐに困難なタスクになりうる。この記事では、ECRリポジトリにライフサイクルポリシーを適用するプロセスを自動化するよう設計された便利なBashスクリプトを詳しく見ていく。このスクリプトはリポジトリ管理を簡素化するだけでなく、最新のイメージのみを保持することを保証し、ストレージコストの節約とレジストリの整理に役立つ。
スクリプトの機能
エラーハンドリング: いずれかのコマンドが非ゼロステータスを返した場合に即座に終了するよう設定されている
カラーコード出力: ANSIカラーコードでメッセージを強調表示
Dry-Runモード: ポリシーを実際に適用せずにアクションをシミュレートする--dry-runオプション
AWS CLI統合: AWS CLIを使用してリポジトリ名を取得し、各リポジトリを反復処理
ライフサイクルポリシーは各リポジトリで最新3つのイメージのみを保持するよう設定される。このスクリプトの実装により、ルーティンタスクが自動化され、コスト管理が改善され、安全なテストのためのDry-Runモードが提供される。


AWS Monthly (Jan '25): 6MBの壁を打ち破る
Fri, 31 Jan 2025 08:36:00 +0300
2025年の幕開けは、サーバーレスコミュニティで最も古い「ボトルネック」の不満の一つに対処することから始まった。長年、同期Lambda呼び出しの6MBペイロード制限は、データ量の多い処理に対してS3の署名付きURLや非同期パターンを使った複雑な回避策を強いていた。
1月、AWSは正式にLambdaレスポンスストリーミング機能を200MBに引き上げた。技術的には、これはデータ出力の扱い方における大きな転換だ。response-streamコンテンツタイプを実装することで、関数から巨大なペイロード、高解像度メディア、巨大なJSONブロブ、リアルタイムAI文字起こしを直接クライアントにプッシュできるようになった。これによりTime to First Byte（TTFB）が大幅に短縮される。クライアントは200MBのバッファ全体が閉じるのを待つのではなく、データが生成され次第受信を開始するからだ。
ストレージ面では、S3の高性能シングルAZ版であるS3 Express One Zoneがパフォーマンスプロファイルの更新を受けた。小さなオブジェクトのGETで約15%のレイテンシ削減が見られた。高頻度取引アプリやリアルタイムゲームのリーダーボードを運用している場合、この更新は事実上「データまでの距離」を短縮したことになる。
エンジニアリングTips: 大規模レポートにまだ古いInvoke APIを使っているなら、ストリーミングに移行すべきだ。フロントエンドのロジックが簡素化され、「中間」S3バケットの必要がなくなる。


TerraformとAWS Route 53を使ったGoogle Workspace（Gmail）のDKIM設定
Wed, 02 Oct 2024 05:54:17 +0300
DKIM（DomainKeys Identified Mail）はメールスプーフィングを防止する重要なメール認証技術だ。DKIMを使用すると、秘密鍵でメールヘッダーにデジタル署名し、受信者はDNSレコードに保存された公開鍵を使用してこの署名を検証する。この記事では、Terraformを使用してAWS Route 53でDNS管理を行いながら、Google WorkspaceのDKIMを設定する方法を詳しく見ていく。
1. DKIMプロセスの概要
Google Workspaceが秘密鍵で送信メールヘッダーに署名する。ドメイン所有者が公開鍵をDNSレコードとして設定する。
受信者のメールサーバーがDNSから公開鍵を取得して署名を検証し、メールが転送中に改ざんされていないことを確認する。

2. Terraformブロックの内訳
ローカル変数でDKIMレコードを定義し、aws_route53_recordリソースでDKIM TXTレコードを作成する。255文字制限に対応するためreplace()関数で文字列を分割する。Terraformを使う利点: 自動DNS管理、再現性、Infrastructure as Code。
手順
Google管理コンソールでDKIMキーを生成する
Terraform設定を適用する（terraform init/plan/apply）
Google WorkspaceでDKIM署名を有効にする
DKIMバリデーターでセットアップを検証する
結論
Terraformを使用してGoogle WorkspaceとAWS Route 53のDKIMレコードを管理することで、メール認証設定の構成と維持のプロセスが合理化される。Happy Terraforming!
参考資料

DKIMCore’s DKIM validator



AWS Site-to-Site VPNモニタリングの自動化
Tue, 01 Oct 2024 06:49:31 +0300
今日のペースが速く相互接続された世界では、オンプレミス環境とクラウドインフラストラクチャ間の安全で信頼性の高い通信が極めて重要だ。多くの企業にとって、AWS Site-to-Site VPNはデータセンターをAWSに接続するブリッジとして機能し、プライベートな暗号化通信チャネルを実現する。しかしVPNトンネルがダウンしたらどうなるのか？適切な可視性や通知システムがなければ、ダウンタイムは簡単に見逃され、最終的にサービス障害や顧客の不満につながる。
だからこそ私はAWS Site-to-Site VPN Monitoring Scriptを作成した。VPN接続の監視を自動化し、問題が発生した場合に即座にチームに通知するツールだ。このガイドでは、このスクリプトがどのように動作し、なぜAWS VPN接続の管理におけるゲームチェンジャーなのかを解説する。
このAWS VPN監視スクリプトを作成した理由
クラウドインフラストラクチャの管理は困難を伴うことがあり、VPNトンネルが警告なくダウンすると、重要な運用が中断される可能性がある。私はこれを身をもって経験し、その結果、VPNトンネルをリアルタイムで監視するシンプルで自動化されたソリューションの必要性を認識した。AWSはネットワークセキュリティのための強力なツールを提供しているが、手の込んだ監視システムを構築しない限り、VPNトンネルがダウンしたときに自動的に通知してくれるわけではない。
このギャップがAWS Site-to-Site VPN Monitoring Scriptの作成につながった。AWS Lambda、DynamoDB、Slack/Discord通知を統合することで、このスクリプトはVPNトンネルのステータスを常に把握できるようにする。その結果、手動チェックや気付かれないダウンタイムの心配は不要になる。
AWS VPN監視自動化の主な利点
1. リアルタイム通知
VPNトンネルがダウンしたとき、一秒一秒が重要だ。このスクリプトはSlackまたはDiscordを通じてリアルタイム通知を提供し、即座に行動を起こせるようにする。その結果、この迅速な対応が長時間の停止リスクを最小化し、ビジネスを円滑に運営し続ける。
2. 履歴ステータスのログ記録
このスクリプトは通知するだけでなく、VPNトンネルのステータスをDynamoDBに記録する。これにより履歴データを確認し、ネットワークの信頼性に関するインサイトを時間の経過とともに得ることができる。例えば、トンネルがいつダウンし、どれくらいの時間だったかを確認したい場合、ログがカバーしてくれる。
3. 完全自動化と信頼性
AWS Lambda関数として実行されることで、この監視ソリューションは手動追跡の必要性を排除する。さらに、スクリプトはVPNトンネルのステータスを定期的にチェックし、問題があれば自動的に報告する。このハンズオフのアプローチにより時間と労力の両方を節約し、プロセス全体をより効率的にする。
4. 簡単なデバッグ
トラブルシューティングが必要か？スクリプトには環境変数で有効にできるデバッグモードが含まれており、問題の特定やセットアップ中により詳細な情報を収集しやすくなる。さらに、予期せぬ事態が発生した際のプロセスを簡素化する。
VPNトンネル監視が重要な理由
多くの組織にとって、AWS Site-to-Site VPN接続はオンプレミスデータセンターとAWSサービス間の安全な通信に不可欠だ。これらのVPNトンネルは、データレプリケーションやハイブリッドクラウドアプリケーションなどの重要な運用のバックボーンであることが多い。したがって、VPNトンネルがダウンした場合の結果は深刻になりうる。
VPNトンネル監視を無視すべきでない理由は以下の通りだ:
1. ダウンタイムはコストだ
VPNトンネルがダウンしている毎分が、収益の損失、ワークフローの遅延、顧客の不満につながりうる。VPNトンネルをプロアクティブに監視することで、問題が発生した時点でアラートを受け取り、長時間の停止を防ぐことができる。つまり、損失を最小化するために迅速に行動できるのだ。
2. セキュリティとコンプライアンスのリスク
監視されていない壊れたVPNトンネルは、機密データをリスクにさらす可能性がある。金融やヘルスケアのような業界では、コンプライアンス規制が信頼性の高い安全な通信を要求する。したがって、監視は安全なトンネルが侵害された場合に即座にアラートを受け取れるようにし、コンプライアンスの維持とデータ保護に役立つ。
3. シームレスな運用
ハイブリッドクラウド環境を運用する組織にとって、サイト間VPN接続は円滑な運用を維持するために重要だ。データの同期であれ分散アプリケーションの実行であれ、稼働中のVPNトンネルはすべてを中断なく動かし続ける鍵である。その結果、これらの接続を監視することで中断のない運用が確保される。
AWS Site-to-Site VPN Monitoring Scriptの仕組み
このスクリプトはAWS EC2 DescribeVpnConnections APIを活用して、VPNトンネルに関するリアルタイムのステータス情報を取得する。トンネルがダウンすると、SlackまたはDiscordチャネルにアラートが送信される。さらに、VPNトンネルのステータスをDynamoDBに記録し、後でトラブルシューティングや監査目的で参照できる記録を提供する。
スクリプトの動作の内訳:
VPNトンネルの監視: 2つのトンネル（Tunnel 1とTunnel 2）のステータスを定期的にチェックする。
通知の送信: どちらかのトンネルがダウンした場合、SlackまたはDiscord経由でアラートを送信する。
トンネルステータスのログ記録: ステータス情報をDynamoDBテーブルに保存し、履歴参照用にする。

AWS VPN監視を始める方法
VPN監視の自動化を始めたいか？完全なプロジェクトと詳細なセットアップ手順はGitHubリポジトリで簡単に見つけられる: 👉 AWS Site-to-Site VPN Monitoring GitHub Repo


Dockerイメージの最適化: イメージサイズとビルド時間を削減するためのヒント
Fri, 27 Sep 2024 08:39:25 +0300
Docker愛好家の皆さん、こんにちは！Dockerイメージは時に肥大化し、ビルドが遅くなり、コンテナが必要以上に重くなることがある。今日はDockerイメージの最適化について深く掘り下げる。パフォーマンスを犠牲にすることなく、かさばったイメージを縮小しビルド時間を短縮する方法を学ぶ。始めよう！
Dockerイメージサイズが重要な理由
より速いビルド: 小さなイメージはビルドが速く、チームのイテレーションサイクルが短縮される。
攻撃対象の削減: より少ないレイヤーと依存関係を持つリーンなイメージは、脆弱性のリスクを下げる。
より低いデプロイコスト: スリムなイメージはホストへのプル時の帯域幅使用が少なく、時間とコストを節約する。
ストレージの効率的な使用: レジストリ（Docker Hub、AWS ECRなど）は容量を占有しないことで感謝するだろう。

最適化のトップヒント
1. 最小限のベースイメージから始める
公式のnode、python、ubuntuイメージは素晴らしいが、必要以上のものがロードされていることが多い。alpineのような最小限のイメージを選ぼう。例えば、nodeの代わりにnode:alpineを使う。Alpineを使えば数百メガバイト縮小できる！
2. マルチステージビルドを使用する
マルチステージビルドは、ビルド環境（大きくなりがち）を最終的なランタイム環境（リーンであるべき）から分離できる。
# Step 1: Build Stage
FROM golang:1.19-alpine AS build
WORKDIR /app
COPY . .
RUN go build -o myapp
Step 2: Final Stage
FROM alpine:latest
WORKDIR /app
COPY –from=build /app/myapp .
CMD ["./myapp"]

3. レイヤー数を最小化する
Dockerfileの各コマンドが新しいレイヤーを作成する。可能な限りコマンドを結合してレイヤー数を減らそう:
RUN apt-get update && apt-get install -y curl git
4. 後片付けをする
パッケージのインストールやファイルのダウンロードのたびに、後片付けをしよう:
RUN apt-get update && \
 apt-get install -y curl git && \
 rm -rf /var/lib/apt/lists/*
5. .dockerignoreを効果的に使う
Dockerの.gitignore相当である.dockerignoreファイルは、ローカル開発ファイル、node_modules、テストフォルダなどの不要なファイルをイメージコンテキストから除外できる。


シンプルなBashスクリプトとSlackアラートでEC2ディスク容量を監視する
Sun, 22 Sep 2024 15:25:41 +0300
はじめに
クラウドインフラストラクチャの環境では、EC2インスタンスの健全性とリソースの監視が不可欠だ。システム管理者にとって一般的な課題の一つは、ディスク容量が不足しないようにすることだ。これはパフォーマンス低下やサービス停止につながる可能性がある。AWSはCloudWatchのような堅牢な監視ツールを提供しているが、特に小規模であまり複雑でないセットアップでは追加コストと複雑さが発生する可能性がある。
この記事では、EC2インスタンス上でcronジョブとして実行されるBashスクリプトを使用したシンプルでコスト効率の高いソリューションを探る。このスクリプトはインスタンスのディスク使用量をチェックし、定義されたしきい値を超えた場合にSlackチャネルにアラートを送信する。この方法は最小限のセットアップで済み、外部監視ツールも不要で、コストを低く抑えられる。
Bashスクリプトソリューション
以下がBashスクリプトとSlack webhookを使用したソリューションだ。スクリプトはルートボリューム（/）のディスク使用量をチェックし、使用量が定義されたしきい値を超えた場合にSlackチャネルにアラートを送信する。また、影響を受けたインスタンスを迅速に特定できるよう、EC2インスタンスのホスト名、プライベートIP、パブリックIPの情報も含まれている。
#!/bin/bash
THRESHOLD=85
SLACK_WEBHOOK_URL=“https://hooks.slack.com/services/your/webhook/url"
hostname=$(curl -s http://169.254.169.254/latest/meta-data/local-hostname)
public_ip=$(curl -s http://169.254.169.254/latest/meta-data/public-ipv4)
private_ip=$(curl -s http://169.254.169.254/latest/meta-data/local-ipv4)
disk_usage=$(df -h / | grep -v Filesystem | awk ‘{print $5}’ | sed ’s/%//’)
if [ “$disk_usage” -ge “$THRESHOLD” ]; then
message=“Disk usage on EC2 instance ‘${hostname}’ is at ${disk_usage}%.
\nPrivate IP: ${private_ip}
\nPublic IP: ${public_ip}.
\nPlease extend disk space!”
payload=”{’text’: ‘$message’}"
curl -X POST -H ‘Content-type: application/json’ –data “$payload” $SLACK_WEBHOOK_URL
fi



Dockerコンテナのセキュリティ確保: コンテナセキュリティのベストプラクティス
Fri, 20 Sep 2024 15:19:47 +0300
コンテナ化について話すとき、Dockerが最初に思い浮かぶツールであることが多い。しかし大きな力には大きな責任が伴う。Dockerがプロセスを合理化できるのと同じくらい、セキュリティは常に最優先であるべきだ。脆弱なコンテナはシステム全体を危険にさらす可能性がある。Dockerコンテナをセキュアにするベストプラクティスを見ていこう。
1. Docker Engineを最新に保つ
基本的に聞こえるが、これが見落とされる頻度に驚くだろう。Dockerは定期的にアップデートをリリースし、脆弱性にパッチを当てセキュリティ機能を導入している。
2. 軽量ベースイメージで攻撃対象を最小化する
イメージが大きければ大きいほどリスクも大きい。alpineやscratchのような最小限のベースイメージを使い、アプリケーションの実行に必要なものだけを追加する。
3. マルチステージビルドを使用する
マルチステージビルドによりビルド環境を最終イメージから分離できる。最終Dockerイメージに必要なものだけを含める。
4. ユーザー権限を設定する
デフォルトではDockerコンテナはrootとして実行される。大きな問題だ！rootとして実行すると、コンテナが悪用された場合に攻撃者に不必要な権限を与えてしまう。常に非rootユーザーとしてコンテナプロセスを実行する。
5. コンテナのケイパビリティを制限する
コンテナはその仕事をするのに完全な権限を必要としない。--cap-dropフラグを使って不要な権限を削除する: docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myapp
6. イメージの脆弱性をスキャンする
Trivy、Clair、Anchoreなどのツールを使ってイメージを定期的にスキャンする。
7. Docker Content Trustを有効にする
DCTはプルするイメージの整合性と信頼性を保証する: export DOCKER_CONTENT_TRUST=1
8. 読み取り専用ファイルシステムを使用する
アプリケーションがファイルシステムに書き込む必要がない場合は読み取り専用にする。docker run --read-only myapp
9-12. ネットワーク露出の制限、ログと監視の有効化、シークレット管理ツールの使用、依存関係の定期的な更新
まとめると、Dockerコンテナのセキュリティ確保は「設定したら忘れる」タイプのタスクではない。継続的な監視、定期的な更新、セキュリティファーストの考え方を必要とする継続的なプロセスだ。これらのベストプラクティスに従うことで、Dockerが提供するすべての利点を活かしながら脆弱性のリスクを劇的に減らすことができる。


Dockerfileのマスタリング: 効率的でスケーラブルなコンテナビルドの書き方
Wed, 11 Sep 2024 08:04:25 +0300
Dockerはアプリケーションの開発、パッケージング、出荷の方法に革命をもたらした。このコンテナ魔法の中心にあるのがDockerfile、Dockerイメージを構築するための設計図だ。Dockerをマスターしたいなら、効率的でスケーラブルなDockerfileの書き方を知る必要がある。最適化され、リーンで保守可能なコンテナイメージを保証するDockerfileを作成するためのベストプラクティスを深く掘り下げよう。
1. 適切なベースイメージから始める
ベースイメージの選択はコンテナの基盤を設定する。ベースが小さいほど、結果のイメージは軽くなる。ここでの2つの主な戦略は:
Alpine Linux: 超軽量イメージ（~5 MB）。最小サイズが重要なマイクロサービスやアプリケーションに最適。ただし、Alpineはglibcの代わりにmuslを使用するため、一部のライブラリで調整が必要な場合がある。
公式言語イメージ: 言語固有のアプリケーション（Node.js、Python、Golang）では、公式イメージが必要な依存関係で事前設定されていることが多く、時間を節約できる。肥大化したイメージを避けるためにスリムバージョン（python:3.9-slimなど）を選ぼう。

例:
FROM python:3.9-slim
2. マルチステージビルドを使用する
マルチステージビルドはDockerイメージを軽量でクリーンに保つためのゲームチェンジャーだ。Dockerfileで複数のFROM文を使用し、最初の数ステージでアプリケーションをビルドし、最終ステージが必要なアーティファクトだけをコピーする。
このアプローチはビルド時の依存関係を排除し、最終イメージサイズを劇的に削減する。
例:
# Build stage
FROM golang:1.17 as builder
WORKDIR /app
COPY . .
RUN go build -o myapp
Production stage
FROM alpine:latest
WORKDIR /app
COPY –from=builder /app/myapp .
CMD ["./myapp"]

この例では、最終イメージにはコンパイルされたGoバイナリとAlpineベースイメージのみが含まれ、Go SDKもソースファイルもない。必要最小限だけだ！

3. .dockerignoreを活用する
.gitignoreと同様に、.dockerignoreは不要なファイルやディレクトリがイメージに追加されるのを除外するのに役立つ。例えば、なぜ.gitディレクトリやローカル環境設定、一時ファイルをイメージに含める必要があるだろうか？
これはパフォーマンスとセキュリティの両方にとって簡単な勝利だ。
例 .dockerignore ファイル:
.git
node_modules
*.log
.env
4. レイヤー作成を最小化する
Dockerfileの各行は新しいレイヤーを作成する。Dockerはこれらのレイヤーをキャッシュするが、レイヤーが多すぎるとパフォーマンス低下や大きなイメージサイズにつながる可能性がある。関連するコマンドを単一のRUN命令にグループ化しよう。
Before:
RUN apt-get update
RUN apt-get install -y python3
RUN pip3 install -r requirements.txt
After:


GitLabからGitHubへのGPG署名付きコミットによるGitリポジトリ移行
Mon, 02 Sep 2024 05:34:58 +0300
以下は、GitLabからGitHubへのGPG署名付きコミットによるGitリポジトリ移行に関する包括的なガイドだ:

GitLabからGitHubへのGPG署名付きコミットによるGitリポジトリ移行
はじめに
今日のDevOps主導の世界では、Gitのようなバージョン管理システムはソフトウェア開発のバックボーンだ。GitLabとGitHubはGitリポジトリを管理するための最も人気のあるプラットフォームの2つだ。
リポジトリを移行する際にコードの整合性と信頼性を維持する重要な側面は、すべてのコミットがGPG署名されていることを確認することだ。このガイドでは、すべてのコミットをGitHub用の新しいGPGキーで再署名しながら、GitLabリポジトリをGitHubに移行するためのステップバイステップのプロセスを提供する。
なぜGitLabからGitHubに移行するのか？
より広いエコシステム: GitHubにはより大きなコミュニティ、広範なサードパーティ統合、GitHub Actionsによる強力なCI/CDワークフローがある。
GitHub SponsorsとDiscussions: プロジェクトをマネタイズしたい場合やコミュニティディスカッションのプラットフォームが必要な場合。
プロジェクトの露出: GitHubがより人気があるため、プロジェクトをそこでホストすることで可視性が向上する可能性がある。
個人の好みや組織の方針: ポリシー変更やプラットフォームへの慣れのために移行が必要な場合がある。
ステップバイステップガイド
ここでは主要な移行手順の概要を示す。詳細な手順としては、リポジトリをbareとしてクローンし、GitHubをリモートとして追加し、git filter-repoを使用してすべてのコミットをGitHubのGPGキーで再署名し、git push --force --tags github mainでプッシュする。各コミットにGitHub上で「Verified」バッジが表示されるはずだ。
結論
GitLabからGitHubへのGPG署名付きコミットを保持したGitリポジトリの移行には、細部への注意が必要だ。このガイドで提供された情報により、プロセス全体を通じてGPG署名付きコミットの整合性を維持しながら、GitLabからGitHubへのスムーズで安全な移行を実行する準備が整ったはずだ。
このアプローチはクリーンな履歴を維持するだけでなく、GitHubでのGPG署名付きコミットのセキュリティ上の利点も活用する。

この記事は、このトピックに関する包括的なガイドを探している技術オーディエンス向けに、移行を成功させるために必要なすべての詳細を提供するはずだ。
参考資料

GitHub’s documentation on GPG keys



0.0.0.0/0を使わずにプライベートサブネットからAWSサービスにアクセスする方法
Sat, 24 Aug 2024 14:56:44 +0300
AWS（Amazon Web Services）を扱う際、インフラストラクチャのセキュリティは最重要である。最も一般的なセキュリティプラクティスの一つは、グローバルな全IPアドレスを表す 0.0.0.0/0 の使用を避けてプライベートサブネットへのアクセスを制限することだ。これによりセキュリティは向上するが、アプリケーションやサービスが様々なAWSサービスと通信する必要がある場合に課題も生じる。この記事では、リソースをパブリックインターネットに公開することなくプライベートサブネットからAWSサービスに安全にアクセスする方法を解説する。
このガイドでは、これを実現するための様々な方法を探り、特定のAWSサービスを掘り下げ、これらの戦略を実装するための実践的な例を提供する。経験豊富なAWSユーザーでも、始めたばかりでも、このガイドはクラウドインフラストラクチャのセキュリティと機能性を向上させる知識を身につけさせてくれるだろう。
0.0.0.0/0 を避けるべき理由
IPアドレス 0.0.0.0/0 は「すべての場所」の省略表現である。セキュリティグループやネットワークアクセス制御で使用されると、世界中のあらゆるIPアドレスからのアクセスを許可する。これが必要なシナリオもあるが、リソースを潜在的な攻撃にさらすため一般的にリスクが高いと見なされる。特定のIPレンジにアクセスを制限することで、インフラストラクチャの攻撃対象領域を大幅に削減できる。
0.0.0.0/0 を使わずにAWSサービスにアクセスする戦略
1. VPCエンドポイントの使用
AWS VPC（Virtual Private Cloud）エンドポイントを使用すると、インターネットゲートウェイ、NATデバイス、VPN接続、AWS Direct Connectを必要とせずに、VPCをサポート対象のAWSサービスにプライベートに接続できる。VPCとAWSサービス間のトラフィックはAmazonネットワークの外に出ないため、セキュリティとパフォーマンスが向上する。
VPCエンドポイントには2種類ある:
インターフェースエンドポイント: AWS PrivateLinkによって提供され、EC2、KMS、CloudWatchなどのサービスにアクセスするために使用される。サブネット内にプライベートIPアドレスを持つElastic Network Interfaceを作成し、AWSサービスとの通信を可能にする。
ゲートウェイエンドポイント: Amazon S3とDynamoDBにアクセスするために使用される。ルートテーブル内のルートのターゲットとして機能し、指定されたサービスへのトラフィックをエンドポイントに転送する。

サービス例:
Amazon S3
Amazon DynamoDB
Amazon EC2
AWS Systems Manager
Amazon SNS
Amazon SQS

2. NATゲートウェイ
NAT（Network Address Translation）ゲートウェイは、プライベートサブネット内のインスタンスがインターネットや他のAWSサービスに接続することを許可する一方で、インターネットからそれらのインスタンスへの接続開始を防ぐマネージドサービスである。インターネットゲートウェイとは異なり、NATゲートウェイはインターネットからのインバウンドトラフィックを許可しないため、プライベートサブネットからパブリックAWSサービスにアクセスするためのより安全な選択肢となる。
NATゲートウェイは単一のアベイラビリティゾーン内で高可用性を持ち、トラフィック需要に合わせてスケールできる。NATゲートウェイをデプロイする際は、パブリックサブネットに設置し、プライベートサブネットのルートテーブルをインターネット向けトラフィックにNATゲートウェイを使用するよう設定することが推奨される。
サービス例:
Amazon EC2
Amazon RDS
Amazon Redshift
AWS Lambda
Amazon ElastiCache

3. AWS Transit Gateway
AWS Transit Gatewayを使用すると、VPC、オンプレミスネットワーク、AWSサービスを中央ハブを通じて接続できる。これは拡張性の高いクラウドルーターとして機能し、ネットワークアーキテクチャを簡素化し、リソース間の安全でスケーラブルかつ管理された接続を確保する。
Transit Gatewayは、直接のインターネット接続を必要とせずに、VPCとオンプレミスネットワーク間でトラフィックをルーティングできる。これは、複数のVPCやリージョンが安全に通信する必要がある大規模アーキテクチャで特に有用だ。
サービス例:
Amazon VPC
AWS Direct Connect
AWS Site-to-Site VPN
Amazon S3（VPCエンドポイント経由）
Amazon DynamoDB（VPCエンドポイント経由）

4. AWS Direct Connect
AWS Direct Connectは、自社施設からAWSへの専用ネットワーク接続を提供する。インターネットを完全にバイパスし、プライベートサブネットをAWSサービスに安全かつ信頼性の高い方法で接続する。Direct Connectは、オンプレミスリソースがAWSサービスと安全に通信する必要があるハイブリッドクラウドアーキテクチャでよく使用される。


AWSリージョン、アベイラビリティゾーン、VPCの理解: 包括的ガイド
Wed, 21 Aug 2024 19:17:28 +0300
はじめに
今日のクラウドコンピューティング環境において、Amazon Web Services（AWS）はあらゆる規模の組織に幅広いサービスを提供するリーダーとしての地位を確立している。その中核機能にはAWSリージョン、アベイラビリティゾーン（AZ）、Virtual Private Cloud（VPC）があり、これらはAWSインフラストラクチャの基盤を形成する。これらの概念を理解することは、スケーラブルで信頼性が高く安全なクラウドソリューションを設計しようとするすべての人にとって重要だ。
AWSリージョンとは？
AWSリージョンはAWSがデータセンターを持つ地理的位置だ。現在世界中で30以上のリージョンが提供されている。適切なリージョンの選択は、コンプライアンス、データ主権、レイテンシ、コストにとって重要だ。リージョン選択時に考慮すべき要素: ユーザーとの地理的近接性、コンプライアンス要件、サービス可用性、コスト。
アベイラビリティゾーン: AWS信頼性の構成要素
AZはリージョン内の分離されたデータセンターだ。複数AZにリソースをデプロイすることで高可用性と耐障害性が実現される。ベストプラクティス: リソースの分散、ロードバランサーの活用、マルチAZデータベースの利用。
VPCの理解: AWS内のプライベートクラウド
VPCはAWSクラウド内の論理的に分離されたネットワークだ。主要コンポーネント: サブネット（パブリック/プライベート）、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、セキュリティグループとネットワークACL。VPCの利点: 分離とセキュリティ、カスタマイズ、スケーラビリティ、コスト効率。
結論
AWSリージョン、AZ、VPCはAWSクラウドインフラストラクチャの基本コンポーネントだ。これらの概念を効果的に活用する方法を理解することは、スケーラブルで信頼性が高く安全なアプリケーションを設計するために不可欠だ。


AWS Network Load Balancerでのヘッダー変更テクニック
Mon, 10 Jun 2024 23:25:29 +0300
AWS Network Load Balancer（NLB）は、単一または複数のアベイラビリティゾーン内のAmazon EC2インスタンスなどの複数のターゲットに受信アプリケーショントラフィックを分散する強力なツールだ。高いスループットと低レイテンシを提供し、超低レイテンシを維持しながら毎秒数百万のリクエストを処理するよう設計されている。しかし、NLBの制限の一つはHTTPヘッダーを直接変更できないことだ。この記事では、この制限を回避するための様々なテクニックを探り、AWS環境でこれらのソリューションを実装するための完全な例を提供する。
AWS Network Load Balancerの紹介
AWS Network Load Balancerは接続レベル（レイヤー4）で動作し、IPプロトコルデータに基づいて接続をターゲットにルーティングする。NLBは極端なパフォーマンスと低レイテンシを必要とするアプリケーションに理想的で、ゲーム、金融取引、動画ストリーミングなどのリアルタイムアプリケーションに適している。
NLBの主な機能:
静的IP: 各NLBには、動作するアベイラビリティゾーン（AZ）ごとに1つの静的IPが割り当てられる。
Elastic IP: NLBに1つ以上のElastic IPアドレスを関連付けることができる。
TLS終端: NLBはTLS終端をオフロードしてアプリケーションサーバーのCPU負荷を最小化できる。
クロスゾーンロードバランシング: 有効な全AZの全ターゲットにトラフィックを均等に分散する。
ターゲットヘルスモニタリング: ターゲットのヘルスを自動的にチェックし、正常なターゲットにのみトラフィックをルーティングする。

ヘッダー変更の必要性
HTTPヘッダーの変更は、以下のような様々なユースケースで不可欠であることが多い:
セキュリティヘッダーの追加（Content-Security-Policyなど）
ログ記録やトラッキング用のカスタムヘッダーの注入
バックエンド処理のためのUser-Agentヘッダーの変更
ヘッダーに基づくセキュリティポリシーの実装

NLBのレイヤー4動作を考慮すると、直接のヘッダー変更は不可能だ。しかし、AWS Lambda、Amazon API Gateway、Application Load Balancer（ALB）を使用してこれを実現できる。
ソリューション1: AWS LambdaとAmazon API Gatewayの使用
Step 1: AWS Lambda関数の作成
まず、受信リクエストのヘッダーを変更するLambda関数を作成する。
AWS Lambdaコンソールに移動する
新しいLambda関数を作成する:「一から作成」を選択
関数名を入力（例: ModifyHeadersFunction）
ランタイムを選択（例: Python 3.8）
基本的なLambda権限を持つ実行ロールを作成


Lambda関数コードを記述する:


def lambda_handler(event, context):
 # Log the incoming event
 print("Received event: " + json.dumps(event, indent=2))
# Modify the headers
event&#91;'headers']&#91;'X-Custom-Header'] = 'CustomHeaderValue'

return {
 'statusCode': 200,
 'headers': {
 'Content-Type': 'application/json'
 },
 'body': json.dumps({
 'message': 'Header modified successfully',
 'input': event
 })
}</code></pre>

関数をデプロイする。

Step 2: Amazon API Gatewayの作成
次に、リクエストをLambda関数にルーティングするAPI Gatewayを作成する。


単一のTerragruntファイルで複数のTerraformモジュールを呼び出す方法
Tue, 07 May 2024 20:15:35 +0300
Terragruntでは、子設定と組み合わせてterraformブロックを使用することで、単一のTerragrunt設定ファイルから複数のTerraformモジュールを呼び出すことができる。これは通常、各モジュールが独自のTerragruntファイルで参照されるが、親Terragruntファイルを使用して中央管理されるようにTerragrunt設定を階層化して整理することで実現される。
基本的な構成の概要は以下の通り:
親Terragruntファイルを作成する: このファイルはリソースを直接デプロイせず、共通設定の構成とモジュールデプロイメントのオーケストレーションに使用される。
各モジュールの子Terragruntファイルを作成する: 各モジュールには、Terraformモジュールのソースと必要な入力を指定する独自のTerragrunt設定ファイルがある。

構成例
ディレクトリ構成の例は以下の通り:
/terraform-live
|-- terragrunt.hcl # 親設定
|-- network
| |-- terragrunt.hcl # network用モジュール設定
|-- app
| |-- terragrunt.hcl # app用モジュール設定
親 Terragrunt.hcl
# /terraform-live/terragrunt.hcl
remote_state {
 backend = "s3"
 config = {
 bucket = "my-terraform-state"
 key = "${path_relative_to_include()}/terraform.tfstate"
 region = "us-west-1"
 encrypt = true
 dynamodb_table = "my-lock-table"
 }
}
すべての子設定を含める
include {
path = find_in_parent_folders()
}

子 Terragrunt.hcl（例: Network用）
# /terraform-live/network/terragrunt.hcl
terraform {
 source = "git::https://example.com/network-module.git?ref=v1.0"
}
networkモジュール固有の入力
inputs = {
vpc_id = “vpc-123456”
}



Gitフックを活用したコミットメッセージ標準の強制: クロスプラットフォーム開発チームのためのガイド
Wed, 03 Apr 2024 14:33:40 +0300
ソフトウェア開発の世界では、クリーンで追跡可能なコミット履歴を維持することは単なる整理整頓の問題ではなく、効率的なチームワークとプロジェクト管理の基盤である。コミットメッセージはログブックや日記として機能し、各変更の理由と内容についての洞察を提供する。この重要性は、変更の追跡とその目的の理解が複雑になりうる多人数開発プロジェクトにおいて増大する。
このガイドでは、様々なオペレーティングシステム間でSemVerやConventional Commitsなどのコミットメッセージ標準を強制するソリューションとしてGitフックを紹介する。Mac、Linux、Windowsでこれらのチェックを実装し、開発環境に関係なくチームの貢献が一貫していることを確保する方法を探る。
Gitフックとは？
Gitフックは、コミット、プッシュ、マージ操作など、Gitライフサイクルのイベントの前後に自動的に実行されるスクリプトだ。手動の監視なしにプロジェクトのルールとワークフローを自動化し強制するための強力なツールである。
環境のセットアップ
Gitフックの実装には、Gitワークフローの特定の段階でトリガーされるスクリプトの作成が含まれる。これらのスクリプトは様々なスクリプト言語で記述できるが、シンプルさとクロスプラットフォーム互換性のために、LinuxとMacではシェルスクリプト、WindowsではバッチスクリプトまたはPowerShellに焦点を当てる。
LinuxとMacの場合:
フックディレクトリを見つける: リポジトリの.git/hooksに移動する。このディレクトリには変更または置換可能なサンプルスクリプトが含まれている。
commit-msgフックを作成する: このフックはコミットメッセージが確定される前に検査することを可能にする。commit-msg.sampleをcommit-msgにリネームし、チェックを含めるように編集する。

Windowsの場合:
WindowsユーザーはGit BashまたはWindows Subsystem for Linux（WSL）を利用してシェルスクリプトを実行でき、LinuxやMacと同様のプロセスになる。あるいは、PowerShellスクリプトも使用できるが、異なるセットアップアプローチが必要だ。
コミットメッセージ標準の強制
コミットメッセージルール:
SemVerとConventional Commits: コミットメッセージはタイプ（feat、fixなど）で始まり、オプションでスコープが続き、変更の簡潔な説明で終わる。例: feat(database): Add user authentication mechanism。
最小単語数: コミットメッセージは記述の明確さを確保するために少なくとも10単語を含まなければならない。

フックの実装:
#!/bin/sh
message=$(cat $1)
word_count=$(echo $message | wc -w)
if ! echo “$message” | grep -qE “^(feat|fix|docs|style|refactor|perf|test|chore)((\S+))?: .{10,}$”; then
echo “Commit message does not follow Conventional Commits standards.”
exit 1
fi
if [ “$word_count” -lt 10 ]; then
echo “Commit message must be at least 10 words.”
exit 1
fi



Let's EncryptとCLI.iniでSSLを簡素化する: DevOpsガイド
Mon, 25 Mar 2024 12:29:07 +0300
インターネットの広大な広がりの中で、セキュリティは単なる贅沢品ではなく、必要性だ。ウェブ開発者やシステム管理者にとって、ウェブトラフィックが暗号化されていることを確認することはユーザーデータを保護する基本的な側面だ。Let's Encryptは無料で自動化されたオープンな認証局（CA）であり、ウェブサイトのセキュリティ確保方法に革命をもたらした。このガイドは、cli.ini設定ファイルの力に焦点を当て、Let's Encrypt使用の複雑さを解きほぐすことを目指す。
Let's Encrypt入門
Let's EncryptはウェブサイトのHTTPS（SSL/TLS）を有効にするデジタル証明書を無料で提供するサービスだ。他の認証局と異なるのはそのシンプルさと自動化だ。数個のコマンドで、手動でCSRを生成したり適切な証明書を提供するようサーバーを設定したりすることなく、証明書を取得・更新できる。
CertbotとCLI.iniの役割
Certbotは最も人気のあるLet's Encryptクライアントだ。cli.iniファイルを使用すると、設定ファイルでCertbotオプションを指定でき、インフラストラクチャ全体での証明書管理の自動化と標準化が容易になる。メール連絡先、webrootパス、セキュリティポリシーなどの設定を事前定義できる。
基本的な設定オプション
email = user@example.com
agree-tos = True
non-interactive = True
セキュリティとパフォーマンス
rsa-key-size = 2048
key-type = ecdsa
must-staple = True
ドメインとWebroot設定
authenticator = webroot
domains = example.com,www.example.com
webroot-path = /var/www/html
フック: サービス管理の自動化
Certbotは証明書更新の前後にスクリプトを実行でき、サービスの再起動や設定変更を自動化できる。
pre-hook = systemctl stop nginx
post-hook = systemctl start nginx


TCP vs. UDP: 開発者とDevOpsとしてプロトコルをナビゲートする
Tue, 05 Mar 2024 19:06:53 +0300
今日はインターネットの2つの基本プロトコル、TCP（Transmission Control Protocol）とUDP（User Datagram Protocol）の魅力的な探求に乗り出す。TCPとUDPのニュアンスを理解することは、アプリケーション設計からネットワークトラブルシューティングまですべてに影響するため、開発者とDevOpsプロフェッショナルの両方にとって重要だ。
TCPとUDPの理解
TCP: データが正確に順序通りに配信されることを保証する几帳面な配達人のようなもの。データを転送する前に接続を確立し、データが宛先に届いたことを確認し、必要に応じて再送する。信頼性が最重要な場合の選択肢だ。
UDP: 絵葉書サービスのようなもの。速くてシンプルだが配達を保証しない。接続を確立したり受信者が受け取ったことを確認したりせずにメッセージ（データグラム）を送信する。速度が重要で、いくつかのパケット損失や順序の乱れが許容できる場合に理想的だ。
主な違い
接続 vs. コネクションレス: TCPは3ウェイハンドシェイクで接続を確立。UDPはコネクションレス。
信頼性: TCPはシーケンス番号、確認応答、再送信などのメカニズムを提供。UDPはそのような保証を提供しない。
順序: TCPはデータパケットの順序を維持。UDPは順序を保証しない。
フロー制御: TCPはフロー制御と輻輳制御を実装。UDPにはこれらのメカニズムがない。
オーバーヘッド: TCPは接続確立、エラーチェック、フロー制御機能によりオーバーヘッドが高い。UDPは最小限のヘッダーでハンドシェイク手順がない。
結論
ネットワーク通信の複雑なダンスにおいて、TCPとUDPはそれぞれの強みと特性を持つ極めて重要な役割を果たす。開発者およびDevOpsプロフェッショナルとして、これらのプロトコルを理解することで、堅牢で効率的かつ応答性の高いアプリケーションとインフラストラクチャを設計できる。金融取引システムの揺るぎない信頼性を確保する場合でも、リアルタイムストリーミングの限界を押し広げる場合でも、TCPとUDPの把握は情報に基づいた意思決定を可能にする。


AWS VPC IPバージョン: IPv4 vs. IPv6
Sat, 03 Feb 2024 18:59:00 +0300
クラウドの先駆者の皆さん、こんにちは！今日はAWS VPCの領域を通じて、IPv4とIPv6の興味深い比較に焦点を当てた啓発的な旅に出る。洗練されたクラウドアーキテクチャを構築している方も、インターネットプロトコルの微妙な動きを理解したい方も、正しい場所に来ている。さあ、AWS VPCにおけるIPv4とIPv6の謎を解き明かし、インサイト、例、詳細な説明を提供しよう。
AWS VPC入門
AWS Virtual Private Cloud（VPC）はクラウドの中のサンドボックスであり、定義した仮想ネットワーク内でAWSリソースを起動できる論理的に分離されたAWSクラウドのセクションを提供する。ネットワーク設定に対する柔軟性と制御は驚異的で、IPアドレス範囲の選択、サブネットの作成、ルートテーブルとネットワークゲートウェイの設定が可能だ。
AWS VPCにおけるIPv4
IPv4は何十年もの間インターネットのバックボーンであり、数十億のユニークなアドレスを提供してきた。しかし、インターネットと接続デバイスの急速な拡大により、このプールはほぼ枯渇している。AWS VPC内では、IPv4アドレスはCIDR（Classless Inter-Domain Routing）ブロック表記で表現される。例えば、典型的なIPv4 CIDRブロックは192.168.0.0/16のようになり、65,536個のIPアドレスを表す。
AWS VPCにおけるIPv6
IPv6の登場だ。事実上無制限のIPアドレスを提供する驚異的な容量を持つ。インターネットの将来性を保証するよう設計されたIPv6は、IPアドレスがすぐに枯渇しないことを保証する。AWS VPCでは、IPv6アドレスはより複雑な表記で表現される。例えば2001:db8:1234:1a00::/56のように、16進数の性質とより大きなアドレス空間を反映している。
AWS VPCにおけるIPv4とIPv6の比較
では、AWS VPCのコンテキストにおいてIPv4とIPv6がどのように比較されるのか、詳細を見ていこう。
アドレス空間
IPv4: 32ビットのアドレス空間を提供し、約42.9億のユニークアドレスに相当する。デバイスが溢れる世界では、この数はもはや十分ではない。
IPv6: 128ビットで、IPv6は事実上無限に見えるアドレスプールを誇り、340澗（36個のゼロ！）に達する。

アドレス割り当てと割り振り
IPv4: IPv4アドレスを手動で割り当てるか、AWSに自動的に割り当てさせることができる。しかし、多数のIPv4アドレスの管理は煩雑になりうる。
IPv6: AWSがVPCとサブネットにIPv6 CIDRブロックを自動的に割り当て、アドレス割り振りを合理化し、複雑な管理の必要性を排除する。

通信プロトコル
IPv4: パブリックインターネット通信にNAT（Network Address Translation）が必要で、ネットワークアーキテクチャを複雑にし、潜在的にボトルネックを導入する。
IPv6: NATなしのエンドツーエンド通信用に設計され、IPv6はルーティングを簡素化し、必須のIPsecサポートを通じてセキュリティを強化する。

セキュリティ
IPv4: セキュリティのためにNATに大きく依存しており、誤った安心感を生み出し、真のエンドツーエンド暗号化の必要性を覆い隠す可能性がある。
IPv6: IPsecを組み込んでおり、データストリーム内の各IPパケットを認証・暗号化することでインターネットプロトコル通信を保護するプロトコルスイートだ。

AWS VPCの機能と互換性
AWS VPCのIPv4とIPv6の両方が、セキュリティグループ、ネットワークACL、ルートテーブルなどの機能をサポートしている。ただし、すべてのAWSサービスがIPv6をサポートしているわけではなく、互換性と将来性を確保するためにデュアルスタック（IPv4とIPv6）構成でVPCを設計する必要がある。
実践的なシナリオと例
シナリオ1: 公開ウェブサイトのホスティング
AWS環境でウェブサイトをホスティングしているとする。IPv4では通常、インスタンスにElastic IP（静的IPv4アドレス）を割り当てる。対照的に、IPv6ではインスタンスが直接のグローバルにユニークなIPv6アドレスを持てるため、アクセシビリティが向上し、レイテンシが低減する可能性がある。
シナリオ2: インターネットへの接続
IPv4 VPCでは、プライベートサブネットのインスタンスがインターネットアクセスのためにNATゲートウェイを必要とし、これがボトルネックになりうる。IPv6では、パブリックIPv6アドレスがあれば、インスタンスはNATなしでインターネットに直接接続でき、ネットワークアーキテクチャが簡素化される。
シナリオ3: グローバルアプリケーションの実行
アプリケーションが世界中のユーザーにサービスを提供する必要がある場合、IPv6はその広大なアドレス空間で輝き、すべてのユーザーとデバイスがユニークなIPを持てることを保証する。このグローバルな到達可能性により、IPv6は国際的なアプリケーションに本質的に優れている。
結論: IPv6で未来を受け入れる
旅の結論として、IPv4が私たちによく奉仕してきた一方で、未来はIPv6にあることは明らかだ。その広大なアドレス空間、強化されたセキュリティ機能、合理化された通信プロトコルにより、IPv6はAWS VPC以降の将来のネットワーキングの要として位置づけられる。
IPv6への移行は困難に思えるかもしれないが、AWSはこの移行をシームレスで価値あるものにするためのツールとリソースを提供している。AWS VPC内でIPv6を理解し活用することで、堅牢でスケーラブルかつ将来性のあるクラウドアーキテクチャを設計する十分な準備が整うだろう。
以上、AWS VPCのIPv4とIPv6の世界への包括的なダイブをお届けした。別れを告げるにあたり、IPv6を受け入れることは単にテクノロジーに遅れずについていくことではなく、イノベーションの舞台を整え、明日の機会にインフラストラクチャが準備できていることを保証することだと覚えておいてほしい。


AWS S3 CORS設定: 詳細解説
Fri, 05 Jan 2024 18:56:43 +0300
クラウドエンスージアストの皆さん、こんにちは！今日はAWS S3 CORS設定の世界に飛び込む。最初は難しく感じるかもしれないが、理解すれば非常にやりがいのあるトピックだ。経験豊富なAWSベテランでも、始めたばかりでも、S3のCORS設定をマスターすることでウェブアプリケーションの機能性とセキュリティを大幅に向上できる。
CORSとは？
Cross-Origin Resource Sharing（CORS）は、バケット内のリソースがアプリケーションがホストされているドメインとは異なるドメインからどのようにアクセスできるかを指定できるセキュリティ機能だ。Amazon S3のコンテキストでは、バケット内のファイルが他のウェブサイトとどのように共有されるかを制御する。
なぜCORSが必要なのか？
example.comでホストされているウェブアプリケーションが、S3バケットmyawesomebucket.s3.amazonaws.comからいくつかのアセットを取得する必要があると想像してほしい。適切なCORS設定がないと、ブラウザは同一オリジンポリシーによりこれらのリクエストをブロックする。これは、あるオリジンのドキュメントやスクリプトが別のオリジンのリソースとどのように相互作用できるかを制限する重要なセキュリティメカニズムだ。
S3でのCORS設定
では、実際に手を動かしてS3バケットのCORSを設定しよう。AWSはこのプロセスをユーザーフレンドリーにしており、AWS Management Console、AWS CLI、SDKから実行できる。アクセシビリティの観点からManagement Consoleの方法に焦点を当てる:
AWS Management Consoleにサインインする: S3サービスのページに移動する。
バケットを選択する: CORSを設定したいバケットをクリックする。
CORS設定を見つける: 「アクセス許可」タブをクリックし、「クロスオリジンリソース共有（CORS）」セクションを見つける。
CORS設定を編集する: 「編集」ボタンをクリックすると、CORSルールを定義できるJSONエディタが表示される。
ルールを定義する: ここで、どのオリジンがリソースにアクセスできるか、どのHTTPメソッドが許可されるか、その他の詳細を指定する。例:

[
 {
 "AllowedHeaders": ["*"],
 "AllowedMethods": ["GET", "POST"],
 "AllowedOrigins": ["https://example.com"],
 "ExposeHeaders": [],
 "MaxAgeSeconds": 3000
 }
]
このルールはhttps://example.comからのGETとPOSTリクエストの両方を許可し、すべてのヘッダーを受け入れ、ヘッダーを公開せず、キャッシュの有効期間を3000秒に設定する。
設定を保存する: 希望するルールを設定したら、「変更を保存」をクリックする。
CORS設定要素の説明
AllowedOrigins: バケットへのリクエストが許可されるオリジンを指定する。すべてのオリジンに対して ["*"] を使用する。
AllowedMethods: 使用可能なHTTPメソッドをリストする（GET、PUT、POST、DELETE、HEAD）。
AllowedHeaders: プリフライトOPTIONSリクエストで許可されるヘッダーを示す。
ExposeHeaders: クライアントアプリケーションのスクリプトからアクセス可能なヘッダーを指定する。
MaxAgeSeconds: プリフライトリクエストの結果をキャッシュできる期間を定義する。

使用例
公開CDN
公開ウェブサイトのCDNとしてS3バケットを使用する場合の設定:
[
 {
 "AllowedOrigins": ["*"],
 "AllowedMethods": ["GET"],
 "MaxAgeSeconds": 86400
 }
]
この設定では、すべてのドメインがGETリクエストでバケットからリソースを取得でき、長いキャッシュ期間が設定される。


AWSにおけるリージョンとアベイラビリティゾーンの重要性
Fri, 15 Dec 2023 19:12:11 +0300
今日は、Amazon Web Services（AWS）で堅牢で回復力があり効率的なアプリケーションを設計する上で極めて重要な側面である、AWSリージョンとアベイラビリティゾーン（AZ）の理解と活用に飛び込む。この記事は、これらの主要な概念を解明するだけでなく、人気のあるInfrastructure-as-CodeツールであるTerraformを使用したベストプラクティスと実践的な例を案内する。開発者、DevOpsエンジニア、クラウドアーキテクトのいずれであっても、AWSのこれらの側面を習得することでアプリケーションのパフォーマンスと信頼性を大幅に向上させることができる。
AWSリージョンとアベイラビリティゾーンの解明
AWSのグローバルインフラストラクチャの中心にあるのはリージョンとアベイラビリティゾーンだ。これらの要素は高可用性、低レイテンシ、規制要件への準拠を達成するための基盤である。
AWSリージョン
AWSリージョンは世界中の異なる地理的位置であり、それぞれが複数の分離されたアベイラビリティゾーンをホストしている。各リージョンは独立したエンティティであり、あるリージョンの障害が別のリージョンに影響を与えないことを保証する。企業にとって、適切なリージョンを選択することはレイテンシの最小化、データ主権法の遵守、コスト最適化にとって重要だ。
AWSアベイラビリティゾーン
各AWSリージョンは複数のアベイラビリティゾーンで構成され、それらは低レイテンシリンクで相互接続された個別の分離されたデータセンターだ。単一リージョン内で複数のAZを利用することで、高可用性と耐障害性のあるアプリケーションを構築できる。AWSはAZが他のAZの障害から隔離されていることを保証しているからだ。
主要概念とベストプラクティス
AWS環境を設計する際、リージョンとAZを理解し戦略的にデプロイすることが最も重要だ。以下の方法がある:
リージョン選択: レイテンシを減らすためにユーザーに最も近いリージョンを選択する。データレジデンシー要件とリージョン間の価格差を考慮する。
マルチAZデプロイメント: 重要なアプリケーションでは、高可用性を確保するためにリージョン内の複数のAZにデプロイする。この戦略はアプリケーションをデータセンター障害から保護する。
リージョン間のデータレプリケーション: グローバルアプリケーションやディザスタリカバリの目的で、リージョン間でデータをレプリケートする。これにより地域的な障害が発生した場合でも事業継続性が確保される。
リージョン対応サービス: 一部のAWSサービスはリージョンスコープであり、他はグローバルだ。使用する各サービスのスコープを理解して環境を正しく設計する。
監視とコンプライアンス: AWS CloudTrailとAWS Configを使用して、リージョンとAZ全体でのアーキテクチャのベストプラクティスを監視し準拠を確保する。

Terraformの例: ベストプラクティスの実装
では、コードでリソースとインフラストラクチャトポロジーの両方を定義できるInfrastructure-as-CodeソフトウェアツールであるTerraformを使用して、これらの概念を実装する方法を実践してみよう。
例1: 高可用性のためのマルチAZデプロイメント
provider "aws" {
 region = "us-east-1"
}
resource “aws_vpc” “main” {
cidr_block = “10.0.0.0/16”
}
resource “aws_subnet” “primary” {
vpc_id = aws_vpc.main.id
cidr_block = “10.0.1.0/24”
availability_zone = “us-east-1a”
}
resource “aws_subnet” “secondary” {
vpc_id = aws_vpc.main.id
cidr_block = “10.0.2.0/24”
availability_zone = “us-east-1b”
}
resource “aws_rds_instance” “app_db” {
engine = “mysql”
instance_class = “db.m4.large”
allocated_storage = 100
db_subnet_group_name = aws_db_subnet_group.app.name
multi_az = true
}


Bash Forループの力: スクリプティングタスクの効率化
Sat, 02 Dec 2023 17:30:03 +0300
スクリプティングと自動化の世界では、BashはUnixおよびLinuxシステムで多用途で広く使用されているシェルとして際立っている。その多くの機能の中で、forループは反復的なタスクを効率的に自動化する基本的な構成要素だ。このブログ記事では、Bash forループの複雑さ、構文、使用方法、実践的なアプリケーションについて掘り下げる。経験豊富な開発者でも初心者でも、Bashのforループを理解することはスクリプティング能力を大幅に向上させるスキルだ。
Forループの基本
基本構文: for variable in list do ... done
伝統的なForループ
for (( i=0; i<10; i++ ))
do
 echo $i
done
リストの反復
for color in red green blue
do
 echo "Color: $color"
done
コマンド出力の反復
for file in $(ls)
do
 echo "File: $file"
done
実践的な応用
システム管理（ファイルのバッチ処理、ユーザーアカウント管理、システム監視）、データ処理（ファイル形式変換、データ抽出）、ウェブ開発（ビルドプロセス自動化、テスト、デプロイ）に有用。ベストプラクティス: 読みやすさを保つ、過剰使用を避ける、段階的にテストする。
結論
Bash forループはスクリプティングの武器庫における強力なツールだ。構文と応用を理解し、ベストプラクティスを遵守することで、その可能性を最大限に活用しスクリプティングタスクを効率化できる。


AWS VPC設計: サブネット、AZ、デュアルスタックIPの統合
Wed, 01 Nov 2023 19:31:04 +0300
クラウドアーキテクトとネットワークに精通したプロフェッショナルの皆さん、ようこそ！今日は、AWSにおけるVirtual Private Cloud（VPC）の設計について、サブネット、アベイラビリティゾーン（AZ）、IPv4とIPv6のデュアルスタック構成を緻密に織り交ぜながら探求する。組織が堅牢でスケーラブルかつ将来性のあるネットワークアーキテクチャを追求する中で、これらのコンポーネントの相互作用を理解することは極めて重要だ。では、AWS VPC設計の複雑さを解きほぐし、自信と先見性をもってネットワークを設計する知識を身につけよう。
AWS VPC設計の基礎
VPCとサブネットの理解
その核心として、AWS VPCは仮想ネットワークを定義・制御できるクラウドの分離されたセクションだ。この環境内で、サブネットはVPCのIPアドレス範囲を分割する区画として機能し、IPアドレスを効率的に割り当て、機能的またはセキュリティ上のニーズに基づいてリソースを整理できる。
アベイラビリティゾーンの活用
アベイラビリティゾーン（AZ）は、リージョン内の他のAZの障害から隔離されるように設計された独立したロケーションであり、強化された耐障害性と安定性を提供する。VPCを設計する際、高可用性と回復力のために複数のAZにサブネットを分散することが重要だ。
デュアルスタックIPv4とIPv6の採用
インターネットは、IPv6の広大なアドレス空間と改善されたネットワーク効率により、IPv4からIPv6へ移行している。AWSはデュアルスタックアーキテクチャをサポートしており、リソースが両方のIPバージョンで同時に動作できるようにし、インフラストラクチャの将来性を確保する。
設計前の考慮事項
VPC設計に飛び込む前に、基礎を固めることが不可欠だ:
要件を理解する: トラフィックフロー、データレジデンシー、コンプライアンスなどの側面を考慮し、アプリケーションのアーキテクチャ上のニーズを特定する。
IPアドレス計画: 現在と将来の成長に十分なアドレスを確保し、他のネットワークとの重複を避けながら、必要なIP空間を計算する。
リージョンとAZの選択: 最適なレイテンシのためにユーザーに最も近いリージョンを選択し、高可用性のために複数のAZの活用を計画する。
IPv6の考慮: IPv6はアドレス空間が大きく階層構造を持つため、異なるサブネット化とアドレッシング戦略が必要であることを認識する。

AWS VPCの設計
では、サブネット、AZ、デュアルスタックIPを統合した堅牢なVPC設計を作成する手順を見ていこう:
Step 1: VPCを作成する
選択したリージョン内にVPCを作成し、IPv4 CIDRブロックを指定することから始める。AWSはIPv6 CIDRブロックの関連付けも促し、最初からデュアルスタック構成を有効にする。
Step 2: サブネットを分割する
VPCの各運用セグメント（パブリック、プライベート、データベース層など）のサブネットを異なるAZにまたがって作成する。VPC全体のIP割り当てを尊重しながら、各サブネットにIPv4とIPv6のCIDRブロックを割り当てる。サブネット内のリソースがIPv6アドレスを割り当てられるように、IPv6アドレスの自動割り当てを有効にすることを忘れずに。
Step 3: ルートテーブルを設定する
サブネット間のトラフィックフローを制御するためのルートテーブルを定義し、IPv4とIPv6の両方のトラフィックに正しいルートを確保する。通常、内部（VPC内）と外部（インターネット向け）のトラフィックには別々のルートが必要になる。
Step 4: ネットワークACLとセキュリティグループを実装する
ネットワークアクセス制御リスト（NACL）とセキュリティグループを定義してセキュリティを強化する。NACLはサブネットレベルでステートレスなフィルタリングを提供し、セキュリティグループはインスタンスレベルでステートフルなフィルタリングを提供する。
Step 5: NATゲートウェイ/インスタンス（IPv4）とEgress-Only Internet Gateway（IPv6）をデプロイする
プライベートサブネットのインターネットアクセスを有効にするには、IPv4にはNATデバイスを、IPv6にはEgress-Only Internet Gatewayを使用する。NATデバイスをパブリックサブネットに配置し、アウトバウンドインターネットアクセスのための適切なルート設定を確保する。
Step 6: 接続性とコンプライアンスをテストする
VPCがセットアップされたら、IPv4とIPv6の両方の接続性をテストし、リソースが期待通りに通信し、設計仕様に準拠していることを検証する。
デュアルスタックネットワーキングの卓越性を達成する
デュアルスタック機能を備えた設計により、AWSリソースが両方のIPバージョンでアクセス可能になり、すべてのクライアントに対応し、ネットワークの将来性を確保できる。成功を確保するための重要なポイントは以下の通り:
監視と最適化: 定期的にVPC設定をレビューし、パフォーマンスを監視し、変化するニーズに適応するためにルートとIP割り当てを最適化する。
情報を常に最新に: AWSの機能とベストプラクティスを把握し、新しい進歩を統合してVPC設計を継続的に強化する。
スケーラビリティを考慮する: 常にスケーラビリティを念頭に設計し、サブネットの容易な拡張や追加サービスの統合を可能にする。

結論
サブネット、AZ、デュアルスタックIP構成を統合したAWS VPCの設計を習得することは、回復力があり将来性のあるクラウドインフラストラクチャを展開するための強固な基盤を築く。これらの要素を系統的に計画し実装することで、高可用性、効率的なルーティング、AWSリソースのスケーラビリティを確保し、アプリケーションを最適なパフォーマンスと信頼性のために位置づけることができる。
これらの原則を受け入れ、ネットワークアーキテクチャがクラウドの卓越性のモデルへと進化するのを見守ろう。今日の需要と明日の機会に応える準備が整っている。

このガイドが自信とビジョンを持ってAWS VPCを設計する力を与えることを願っている。完璧なAWSネットワークアーキテクチャの構築に関する洞察や質問があれば、ぜひ以下のコメントで共有してほしい。Happy designing!


スマートウォッチを買うべき7つの理由
Tue, 31 Oct 2023 19:16:43 +0300
スマートウォッチを着けている人をかなりの数見かけたことがあるだろう。このトレンドを見て、一体何がそんなに良いのかと首をかしげているかもしれない。
スマートウォッチの製造でそれなりに知られているブランドは複数あるが、（当然ながら）Appleがおそらくトップだろう。
好奇心であれ周囲の圧力であれ、自分もスマートウォッチを買おうかと考えているかもしれない。そしてもしそうなら、その決断を正当化する理由はかなりある。スマートウォッチは見た目以上のものを提供しており、この記事ではまさにそれをカバーする。
ファッションステートメント
最初にこれを片付けよう。スマートウォッチはロレックスや他の腕時計ほど目立つものではないが、ファッションアクセサリーとしての側面は依然として存在する。
むしろ、スマートウォッチは持ち主のモダンな物の見方や、テクノロジーがその人の生活でどれほど重要な役割を果たしているかを表現する。
さらに、複数のブランドやモデルから選べることも助けになる。特定の時計にあまり惹かれなければ、気に入るものを見つけるまで市場をより深くリサーチすればいい。
エンターテイメント
スマートウォッチにはコンピュータのような他のデバイスほどのストレージはない。また、他の機器からファイルを転送するのもそれほど簡単ではない。例えば、iPhoneからMacにAirDropするのは比較的簡単だが、持っているスマートウォッチによっては問題が生じるかもしれない。
とはいえ、この欠点はガジェットをエンターテイメント面で最大限に活用できないという意味ではない。
テクノロジーは急速に進歩しており、スマートウォッチで利用できる多種多様なアプリケーションを見つけても驚くには当たらない。音楽やポッドキャストを聴いたり、動画やその他のメディアを視聴したり、スマートウォッチに直接保存されたちょっとしたエンターテイメントにアクセスしたりすることは、十分実用的な選択肢だ。
ゲーミングもますます勢いを増しているアイデアであることも注目に値する。一部のメーカーは、ゲーミング専用のスマートウォッチを開発しようとしている。
安全性
スマートウォッチにはGPSトラッカーが内蔵されており、自分だけでなく他の人にとってもセーフティネットとして機能する。子供に着けさせておけば、何かあったときにGPSで居場所を特定できる。
当然ながら、そういった問題は避けたいし考えたくもないが、いつ何が起きるかは確信できず、必要なときに頼れるアクセサリーを持つことの価値は過小評価されがちだ。
通知
スマートフォンやノートパソコンから離れているときに、重要なメッセージや電話を見逃さないようにしたいか？スマートウォッチを他のデバイスと同期することで、スマートウォッチ上で直接通知を受け取れるようになり、仕事や個人的な問題に関連する潜在的なトラブルを回避しやすくなる。
バッテリー消費
スマートウォッチと他のデバイスの同期に関連して、スマートフォンのバッテリー問題も少なくなることが期待できる。
スマートウォッチが一部のプロセスを肩代わりすることでモバイルデバイスの負荷が軽減されれば、スマートフォンをそれほど頻繁に充電する必要がなくなる。
もちろん、この特定の利点はそれほど大きなことには思えないかもしれないが、それでもスマートウォッチを支持するもう一つのポイントだ。
健康モニター
健康状態を継続的に追跡できる。健康意識は、人々がスマートウォッチに投資する最も一般的な理由であることが多い。
ストレスレベル、心拍数、睡眠パターン、その他の重要なデータは、スマートウォッチと身体を「接続」することでアクセス可能になる。何か問題が起きればすぐにアラートを受け取り、健康上の危険を軽減・排除するために必要な措置を取ることができる。
旅行
スマートウォッチを手首に着けていれば、旅行がより便利になる。ガジェットは小さいので、荷物の中でストレージスペースを取る心配はない。しかし一番良いのは、旅行に必要な多くの便利なものにアクセスできることだ。
行き先を教えてくれるGPS、マップシステム、訪れたいお店のレビュー、さらには自分の言語を理解しない見知らぬ人とコミュニケーションを取るための翻訳サービスまでも。
まとめ
以上を総括すると、スマートウォッチがなぜこれほど人気なのかはかなり明確になったはずだ。この記事で挙げた利点は、まだスマートウォッチの購入を迷っている人の考えを変えるだろう。
そして、新しく改良されたスマートウォッチのバージョンが毎年どれほど速くリリースされているかを考えれば、未来はさらに明るく、後々このデバイスを手に入れる理由はさらに増えるかもしれない。
参考資料

Airdrop from iPhone to Mac
Syncing your smartwatch



UbuntuでSSHを有効にする方法: ステップバイステップガイド
Thu, 19 Oct 2023 18:15:00 +0300
はじめに
Secure Shell（SSH）はシステム管理者、開発者、ITプロフェッショナルにとって不可欠なツールだ。リモートサーバーに安全にアクセスする方法を提供し、システムをリモートで管理するための貴重なリソースとなる。最も人気のあるLinuxディストリビューションの一つであるUbuntuのユーザーにとって、SSHのセットアップはシステムの使いやすさとセキュリティを大幅に向上させることができる。このブログ記事では、UbuntuでSSHを有効にするプロセスを案内し、シームレスで安全なリモートアクセス体験を確保する。
SSHとは？
SSH（Secure Shell）は、安全なデータ通信、リモートシェルサービス、コマンド実行を可能にするネットワークプロトコルだ。システム管理者がリモートでシステムやアプリケーションを管理するために広く使用されている。SSHは送信データを暗号化し、機密情報が不正アクセスから保護されることを保証する。
UbuntuでSSHを有効にする理由
UbuntuでSSHを有効にすると、Ubuntuマシンへの安全なリモートアクセスが可能になる。これはサーバーの管理、タスクの自動化、安全でないネットワーク上でのファイルの安全な転送に特に有用だ。
UbuntuでSSHを有効にするステップバイステップガイド
Ubuntuシステムを更新する 新しいソフトウェアをインストールする前に、システムを更新するのが良い習慣だ。ターミナルを開き、以下のコマンドを実行する:

sudo apt update
sudo apt upgrade
これにより、システムのすべてのパッケージが最新になる。
OpenSSHサーバーをインストールする UbuntuはオープンソースのSSHツールであるOpenSSHを使用する。インストールするには以下を実行する:

sudo apt install openssh-server
インストールが完了すると、SSHサービスが自動的に起動する。
SSHサービスのステータスを確認する SSHサーバーが実行中かどうかを確認するには以下を使用する:

sudo systemctl status ssh
サービスがアクティブで実行中であることを示すステータスが表示されるはずだ。
SSHを設定する（オプション） SSHのデフォルト設定は一般的にほとんどのユーザーにとって十分だ。しかし、/etc/ssh/sshd_configにある設定ファイルに変更を加えることができる。一般的な設定には、デフォルトSSHポートの変更、rootログインの無効化、ユーザーアクセスの制限などがある。変更を加えた後はSSHサービスを再起動することを忘れずに:

sudo systemctl restart ssh
ファイアウォール設定を調整する ファイアウォールが有効な場合、SSHトラフィックを許可する必要がある。UbuntuのデフォルトのUFWファイアウォールの場合:

sudo ufw allow ssh
これにより、デフォルトのSSHポートであるポート22のトラフィックが許可される。
SSH経由でUbuntuシステムに接続する 別のコンピュータからUbuntuマシンに接続するには、SSHコマンドを使用する:

ssh username@your_server_ip
usernameをUbuntuシステムのユーザーアカウントに、your_server_ipをマシンのIPアドレスに置き換える。

SSH接続のセキュリティ強化
強力なパスワードを使用する: システム上のすべてのユーザーアカウントに強力でユニークなパスワードを設定する。
rootログインを無効にする: 直接のrootログインを無効にすることはセキュリティのベストプラクティスだ。管理タスクにはsudoを設定する。
デフォルトのSSHポートを変更する: デフォルトポート（22）を非標準ポートに変更することで、自動攻撃のリスクを減らすことができる。
SSHキー認証を使用する: セキュリティを強化するために、パスワードベースの認証ではなくSSHキーベースの認証を設定する。

結論
UbuntuでSSHを有効にすることは、システムの安全なリモート管理の可能性の世界を開く簡単なプロセスだ。このガイドで概説した手順に従うことで、UbuntuでのSSHセットアップが安全で効率的であることを保証できる。不正アクセスから保護するために、SSH接続を保護するベストプラクティスに従うことを忘れずに。
GUIでSSHを使用できますか？ はい、SSHはX11セッションの転送に使用でき、GUIアプリケーションをリモートで使用できます。
 
 SSH経由でファイルを転送するには？ scpやrsyncなどのツールを使用して、SSH経由で安全にファイルを転送できます。
 
 SSH経由で接続できない場合の対処法は？ ファイアウォール設定を確認し、SSHサービスが実行中であることを確認し、ネットワーク接続を検証してください。
 
 SSHをインターネットに公開しても安全ですか？ SSHは安全ですが、サービスをインターネットに公開するとリスクが増加します。強力なパスワードやSSHキーを使用し、追加のセキュリティとしてVPNの設定を検討してください。
 
 
UbuntuでSSHを理解して実装することで、高いレベルのセキュリティを維持しながらシステムの機能を強化できる。Happy SSHing!


Vim: 効率的な編集のための必須要素のマスタリング
Mon, 25 Sep 2023 17:53:44 +0300
はじめに
テキスト編集の世界では、Vimは効率性と速度を優先する強力でキーボード中心のエディタとして際立っている。Unix環境に由来するVim（Vi Improved）は、急な学習曲線を越えた後の高い生産性で知られている。この記事では、コピー、元に戻す、やり直し、単語間のジャンプなどのコアVimコマンドを掘り下げる。
基本的なVimコマンド
Vimを開く: ターミナルでvimと入力するだけ
ファイルを開く: vim filename
保存: Escを押して:w
終了: Escを押して:q。保存して終了は:wq
ナビゲーション
カーソル移動: h, j, k, lで左、下、上、右。単語ジャンプ: wで前方の単語の先頭へ、eで単語の末尾へ、bで後方の単語の先頭へ。
編集
挿入モード: iで入力、Escでコマンドモードに戻る。コピー: yyで行をコピー。貼り付け: pでカーソルの後に貼り付け。元に戻す/やり直し: uで元に戻し、Ctrl-rでやり直し。
検索と置換
検索: /に続けて検索語とEnter。nとNで検索結果を移動。置換: :%s/old/new/gですべての'old'を'new'に置換。
結論
Vimは初心者には難しいという評判があるかもしれないが、一度コツをつかめば強力なツールだ。コピー、元に戻す、やり直し、単語間のジャンプの基本コマンドを理解することが素晴らしいスタートだ。Vimをマスターする鍵は忍耐と練習であることを忘れないでほしい。時間とともに、Vimが編集プロセスを大幅に高速化できることに気付くだろう。


CAA DNSレコードの理解: 何を、なぜ、どのように？
Mon, 25 Sep 2023 13:27:12 +0300
デジタル世界はセキュリティと信頼の上に成り立っている。この信頼の基盤的側面の一つがSSL/TLS証明書であり、HTTPSのバックボーンだ。インターネットが成熟するにつれて、証明書発行プロセスを改善する必要性も高まる。そこで登場するのがCAA（Certificate Authority Authorization）DNSレコードだ。
CAA DNSレコードとは？
CAA（Certificate Authority Authorization）は、ドメイン所有者が自分のドメインに対してどの認証局（CA）が証明書を発行できるかを指定できるDNSレコードの一種だ。本質的に、CAAレコードはドメイン所有者に誰がドメインの証明書を発行できるかできないかについて発言権を与える。例: example.com. CAA 0 issue "letsencrypt.org" これはLet's Encryptのみがexample.comの証明書を発行できることを意味する。
CAA DNSレコードが必要な理由
セキュリティ強化: CAAレコードはドメインが誤って不正な証明書を発行されるのを防ぐのに役立つ。
制御: ドメイン所有者にSSL/TLS証明書に対するより大きな制御を与える。
監査証跡: CAがCAAレコードにリストされていないドメインの証明書を要求された場合、CAはそのリクエストを文書化しドメイン所有者に通知する。
長所と短所
長所: 不正証明書の防止、柔軟性（サブドメインごとに設定可能）、すべてのCAがCAAチェックを義務付けられているため互換性あり。短所: CA変更時のメンテナンス、伝播遅延、誤設定の可能性。
実践例: AWS ACMとCloudFlare
ercanermis.comおよび*.ercanermis.comのSSL証明書をAWS ACM経由で作成しようとする場合、既存のCAAレコードがACM（amazon.com）をリストしていなければ問題が発生する可能性がある。解決策: AWS ACM用のCAAレコードを追加し、ワイルドカードサブドメインもカバーすること。
結論
CAAレコードはウェブサイトの整合性とセキュリティを維持するためのドメイン所有者の武器庫における貴重なツールだ。デジタル環境が進化するにつれて、CAAのようなツールは安全で信頼できるインターネットの確保においてさらに不可欠になるだろう。ドメイン所有者なら、ドメインのCAAレコードの設定を検討する時期かもしれない。


AWS VPCマスタリング: 仮想プライベートクラウドルーティング入門
Sun, 13 Aug 2023 12:03:24 +0300
クラウドコンピューティングの世界はかつてないほどアクセスしやすく多様になっている。組織がクラウドに移行する中で、AWS（Amazon Web Services）は頼りになるソリューションとして際立っており、特にVPC（Virtual Private Cloud）サービスがそうだ。この入門では、AWS VPCルーティングを深く掘り下げ、そのコアコンセプトと、最適化された安全なクラウド環境にそれらがどのように貢献するかを解明する。
AWS VPCとは？
その核心として、AWS VPCはAmazon Web Servicesクラウドのカスタマイズ可能で分離されたセクションであり、ユーザーは仮想ネットワーク内でAWSリソースを起動できる。AWSクラウドのプライベートな一片と考えてほしい。IPアドレス範囲、サブネット、ルートテーブル、ネットワークゲートウェイを制御できる。
VPCルーティングが重要な理由
VPCルーティングは、VPC内部の異なるサブネット間、および他のネットワークやインターネットへのトラフィックの流れを決定する上で極めて重要な役割を果たす。ルーティングの習得は、リソース間の安全で効率的かつ信頼性の高い通信を保証する。
AWS VPCルーティングのコアコンセプト:
ルートテーブル: ネットワークトラフィックがどこに向けられるかを決定するルーターとして機能する。VPC内の各サブネットはルートテーブルに関連付けられている必要がある。
サブネット: 分離されたリソースのグループを配置できるVPCのIPアドレス範囲の区画。インターネットゲートウェイ: VPCがインターネットと通信できるようにする。VPC内のリソース（EC2インスタンスなど）がインターネットに直接アクセスする必要がある場合に不可欠だ。
NATデバイス: Network Address Translationデバイス（NAT GatewayまたはNAT Instance）は、プライベートサブネット内のインスタンスがインターネットへのアウトバウンドトラフィックを開始できるようにする。
VPC Peering: 2つのVPC間の接続で、あたかも同じネットワーク内にいるかのように相互にトラフィックを流せるようにする。
VPCルーティングを始める:
VPCを設計する: 飛び込む前に、必要なIPアドレス数と将来のスケーラビリティを考慮してVPCのCIDRブロックを計画する。
サブネットを設定する: アーキテクチャのニーズに基づいてパブリックサブネットとプライベートサブネットを設計する。パブリックサブネットはインターネットゲートウェイ経由でインターネットに直接アクセスできるが、プライベートサブネットはできない。
ルートテーブルを設定する: トラフィックの流れを定義するルートルールを作成する。例えば、テーブルのルートはすべてのトラフィック（0.0.0.0/0）をインターネットゲートウェイに向けることができる。
NATデバイスを統合する: プライベートサブネットでは、NATデバイスが更新などのタスクのためにインスタンスがインターネットと通信するのを助ける。監視と最適化: AWSはVPC Flow Logsなどのツールを提供しており、トラフィックの監視に役立つ。これはネットワークの最適化とセキュリティ確保に不可欠だ。
結論として
AWS VPCルーティングの習得は、AWSエコシステムに飛び込むすべての人にとって基本的だ。VPCの力はその柔軟性にあり、特定のニーズに合わせた仮想ネットワーキング環境を設計できる。VPCルーティングの原則に慣れるにつれて、堅牢でスケーラブルかつ安全なクラウドアーキテクチャを設計する能力が高まるだろう。
このAWS VPCルーティング入門が役立ったなら、共有してほしい。クラウドコンピューティングの世界へのより深い掘り下げをお楽しみに！


新しいAWSパブリックIPv4アドレス課金とPublic IP Insightsの理解
Sun, 30 Jul 2023 18:57:40 +0300
皆さんこんにちは、
Amazon Web Services（AWS）からの重要な更新情報を共有したい。AWSは2024年2月1日より、パブリックIPv4アドレスに対する新しい課金を発表した。この変更により、サービスにアタッチされているかどうかに関わらず、すべてのパブリックIPv4アドレスに対してIPあたり1時間あたり$0.005の料金が発生する。
なぜ新しい課金なのか？
IPv4アドレスはますます不足しているリソースになっている。過去5年間で単一のパブリックIPv4アドレスの取得コストは300%以上上昇した。この新しい料金はAWS自身のコストを反映し、ユーザーがパブリックIPv4アドレスの使用により倹約的になることを促すものだ。
影響を受けるのは誰か？
この変更はAmazon EC2、Amazon RDSデータベースインスタンス、Amazon EKSノードなど、パブリックIPv4アドレスを割り当ててアタッチできるすべてのAWSサービスに適用される。全AWSリージョンで適用される。AWS無料利用枠には、最初の12ヶ月間、月間750時間のパブリックIPv4アドレス使用が含まれる。
Public IP Insightsの紹介
AWSはパブリックIPv4アドレスの使用状況の監視、分析、監査を容易にするため、Amazon VPC IP Address Managerの新機能であるPublic IP Insightsを無料で提供する。


Dockerマルチステージビルド: 詳細ガイド
Sat, 29 Jul 2023 09:09:39 +0300
はじめに
Dockerはアプリケーションの開発、パッケージング、デプロイの方法に革命をもたらした。開発から本番まで一貫した環境を提供し、「自分のマシンでは動くのに」問題を軽減する。Dockerが導入した最も強力な機能の一つがマルチステージビルドだ。この機能は、通常の面倒さなしにリーンで効率的なコンテナを作成するのに役立つ。このブログ記事では、Dockerマルチステージビルド、その利点、ベストプラクティスについて掘り下げる。概念を説明するためのDockerfileの例も提供する。
Dockerマルチステージビルドとは？
Dockerマルチステージビルドは、Dockerfileで複数のFROM文を使用できる機能だ。各FROM文は異なるベースイメージを使用でき、ビルドの新しいステージを開始する。あるステージから別のステージにアーティファクトを選択的にコピーし、最終イメージに不要なものをすべて残すことができる。これにより、ビルドとパッケージングのプロセスを異なるステージに分離することで、より小さく効率的なイメージを作成できる。
なぜDockerマルチステージビルドを使うのか？
マルチステージビルドが導入される前は、リーンなDockerイメージの作成は少し面倒だった。アプリケーションのビルド用と実行用に別々のDockerfileを作成するか、本番イメージに不要なツールをインストールする必要があった。マルチステージビルドは、1つのDockerfileで効率的なイメージを作成できるようにすることでこれらの問題を解決する。Dockerマルチステージビルドを使用すべき理由は以下の通り:
イメージサイズの縮小: ビルドステージから最終イメージに必要なファイルのみをコピーすることで、Dockerイメージのサイズを大幅に削減できる。小さいイメージはレジストリからのプッシュとプルが速く、ディスク容量も少なくて済む。
関心の分離: マルチステージビルドでは、ビルド時の依存関係をランタイムの依存関係から分離できる。これによりDockerfileが読みやすく保守しやすくなる。
セキュリティ: 小さいイメージは攻撃対象領域が小さい。不要なツールやファイルを除外することで、セキュリティ脆弱性の可能性を減らす。

ベストプラクティス
特定のベースイメージを使用する: 各ステージでは、そのステージに必要なものだけを含む最も特化したベースイメージを使用する。例えば、Node.jsアプリケーションを含むビルドステージにはNode.jsイメージを使用し、軽量な最終ステージにはAlpineイメージを使用する。
レイヤー作成を最適化する: Dockerはレイヤーでイメージをビルドする。ビルドを高速化しイメージを小さくするには、&&を使用してコマンドを結合し、レイヤー数を最小限に抑える。
後片付けをする: ビルドステージでは、使い終わった不要なファイルやアーティファクトをクリーンアップする。これによりビルドキャッシュが小さくなり高速化される。

Dockerfileの例
以下はNode.jsアプリケーションのマルチステージビルドを示すDockerfileの例だ:
Dockerfile
—- Base Node —-
FROM node:14 AS base
WORKDIR /usr/src/app
COPY package*.json ./
—- Dependencies —-
FROM base AS dependencies
RUN npm install
—- Test —-
run linters, setup and tests
FROM dependencies AS test
COPY . .
RUN npm run test
—- Build —-
FROM dependencies AS build
COPY . .
RUN npm run build


Docker Runコマンドのマスタリング: 包括的ガイド
Sat, 29 Jul 2023 09:02:20 +0300
現代のソフトウェア開発におけるDockerの使用は広く普及しており、それには正当な理由がある。Dockerは開発者がアプリケーションのデプロイを簡素化する軽量でポータブルなソフトウェアコンテナを構築するのを助ける。Dockerのコマンドラインインターフェース（CLI）で最も強力なコマンドの一つがdocker runコマンドだ。しかし、その膨大なオプション数は初心者にとって少し威圧的になりうる。このブログ記事では、docker runコマンドを解明し、その機能を活用してDockerコンテナを効果的に実行する方法を説明する。始めよう！
Docker Runコマンド
最も基本的なレベルでは、docker runコマンドはDockerイメージから新しいコンテナを作成して起動する。しかし、このコマンドはアプリケーションのニーズに応じてコンテナをカスタマイズするための多数のオプションを提供する。コマンド構造は以下の通り:
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
では、最も一般的に使用されるオプションのいくつかをより深く掘り下げよう:
Name (--name)
Dockerコンテナにカスタム名を割り当てることは、特に複数のコンテナを扱っているときに非常に便利だ。--nameフラグを使ってDockerコンテナの名前を指定できる:
docker run -d --name my_container ubuntu
Port Mapping (-p or --publish)
-pまたは--publishフラグを使って、Dockerコンテナ内のネットワークポートをホストマシンのポートにマッピングできる。この機能はネットワーク経由でアクセス可能である必要があるサービスをデプロイする際に不可欠だ:
docker run -d -p 8080:80 ubuntu
Volume Mounting (-v or --volume)
Dockerコンテナが生成・使用するデータを永続化したり、ホストからコンテナにデータを提供したりするために、Dockerはボリュームを提供する。-vまたは--volumeフラグを使ってボリュームをマウントできる:
docker run -d -v /path/on/host:/path/in/container ubuntu
Environment Variables (-e or --env)
Dockerコンテナ内のプロセスが使用できる環境変数を設定できる。これらの変数はアプリケーションに設定を提供する良い方法だ:
docker run -d -e "ENV_VAR=value" ubuntu
Link (--link)
--linkオプションはコンテナがお互いを発見し、あるコンテナから別のコンテナに情報を安全に転送することを可能にする。
docker run -d --link database:db ubuntu
Memory (-m or --memory)
コンテナのメモリ使用量を制限することは、Dockerホスト上のリソース管理に重要だ。-mまたは--memoryフラグでコンテナのメモリ使用量を制限できる:


MySQL 8: エラー1819の理解と修正
Fri, 14 Jul 2023 15:25:56 +0300
MySQLの初心者として、「ERROR 1819 (HY000): Your password does not satisfy the current policy requirements」というエラーメッセージに遭遇するかもしれない。このエラーはバグではなく、ユーザーが強力なパスワードを設定することを保証するMySQLの組み込みセキュリティ機能だ。このチュートリアルでは、このエラーを理解し修正する方法を案内する。
エラーのトリガーは？
MySQLのrootユーザーのパスワードを設定する際、VALIDATE PASSWORDコンポーネントの有効化を促される場合がある。有効化されていると、このコンポーネントは提供されたパスワードの強度をチェックする。パスワードが弱いと判断されると、エラー1819に遭遇する。
例えば、次のような弱いパスワードでユーザーを作成しようとすると:
mysql> create user 'ostechnix'@'localhost' identified by 'mypassword';

次のエラーが表示される:
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

パスワード検証ポリシーの理解
MySQLはVALIDATE PASSWORDプラグインが有効な場合、3つのレベルのパスワード検証ポリシーを強制する:
LOW: パスワードは最低8文字以上。
MEDIUM: パスワードは最低8文字以上で、数字、大文字小文字混在、特殊文字を含む必要がある。
STRONG: パスワードは最低8文字以上で、数字、大文字小文字混在、特殊文字、辞書ファイルを含む必要がある。

現在のポリシーレベルを確認するには:
mysql> SHOW VARIABLES LIKE 'validate_password%';

エラーの修正方法
エラー1819を修正する主な方法は2つある:
1. ポリシーを満たすようパスワードを変更する
現在のパスワード検証ポリシーを満たすパスワードを設定する。例えば、ポリシーがMediumに設定されている場合、数字、小文字、大文字、特殊文字を含む'Password123#@!'のようなパスワードを設定できる。
2. パスワード検証ポリシーを変更する
パスワード検証ポリシーをより低いレベルに変更する:
mysql> SET GLOBAL validate_password.policy=LOW;
MEDIUMレベルに戻すには:
mysql> SET GLOBAL validate_password.policy=MEDIUM;
結論
このチュートリアルでは、一般的なMySQLエラー1819とその修正方法をカバーした。より良いセキュリティのために常に強力なパスワードを使用することを推奨する。Happy learning!


GitHub Clone HelperでCtrl+CとCtrl+Vパーティー！
Sat, 24 Jun 2023 23:53:09 +0300
キーボード戦士とターミナルささやき人の皆さん、こんにちは！
GitHubの無限のリポジトリの海で迷子になり、たくさんのリポジトリをクローンしなければならないことに気付いたことはないだろうか？手順はみんな知っている: クローンURLをコピーし、ターミナルを開き、「git clone」とタイプし、URLを貼り付け、Enterを押す。簡単そうに聞こえるだろう？でも50回目は？100回目は？1000回目は？！考えるだけで指がつりそうだ！
タイピングの良いセッションは誰もが好きだが（リズミカルなカチカチ音は妙に心地よい）、毎回毎回URLの前に「git clone」とタイプするのは？そこが限界だ。まるで全てのコマンドの前に「Simon says」と言わなければならないようなものだ。サイモン、分かったよ、君がボスだ！
そこで登場するのがGitHub Clone Helperだ！この気の利いた小さな拡張機能は、必要だと知らなかったスーパーヒーローだ。颯爽と現れて、我々の「git clone」の悩みに終止符を打つ。文章を完成させてくれる素晴らしい相棒のようなものだが、今回はコマンドを完成させてくれる。これを欲しがらない人がいるだろうか？
GitHub Clone Helperは普通の拡張機能ではない。GitHub上のクローンURLの前に自動的に「git clone」を追加する、勤勉で勤勉な小さなエルフだ。そして表示するだけでなく、本気だ。クローンURLをコピーすると、実際には「git clone」コマンド全体をコピーしている。あなたがいつも望んでいたCtrl+CとCtrl+Vのパーティーだ！
次にGitHubをブラウズしていてクローンしたいリポジトリを見つけたときは、GitHub Clone Helperという友達がいることを思い出してほしい。それはあなたの「git clone」の日々が過去のものになることを確実にするためにそこにある。少なくともタイピングの部分は！
そして、部屋の中の大きな象を忘れてはいけない - プライバシーだ。GitHub Clone Helperは真の友達だ。あなたのプライバシーを尊重し、噂話をせず（読む: サーバーとの不必要な通信なし）、あなたのクッキージャーにこっそり手を突っ込んだりしない（読む: 個人データの収集や共有なし）。それはすべてローカルライフについてであり、あなたのお気に入りの職人ベーカリーのように。
もしあなたが私のような怠惰な賢い開発者なら、すべてのURLの前に「git clone」とタイプしなくてもよいことにある種の美しさがあることに同意するだろう。それは数秒を節約することだけではなく、私たちの生活を少し楽に、もう少し自動化されて、もっとずっと楽しくすることなのだ。
GitHub Clone Helperを使えば、「git clone」が過去のものとなる世界に向けて一歩を踏み出している。コード、コーヒー、そしてたまに睡眠という、エキサイティングなものに集中できる世界だ。
GitHub Clone Helper列車に乗り込んで、「git clone」を歴史にしよう！シュッシュッ、開発者の仲間たち！
これらの拡張機能のリンクは以下で確認できる:
GitHub: https://github.com/flightlesstux/github-clone-helper 
Google Chrome Webstore: https://chrome.google.com/webstore/detail/kfabhahlbkfegapejbcigihbgjnpdobm 
Mozilla Firefox Add-ons: https://addons.mozilla.org/en-US/firefox/addon/github-clone-helper/
フィードバックとスターをお待ちしています！

Happy coding! セミコロンの力がともにあらんことを！
参考資料

https://github.com/flightlesstux/github-clone-helper
https://chrome.google.com/webstore/detail/kfabhahlbkfegapejbcigihbgjnpdobm
https://addons.mozilla.org/en-US/firefox/addon/github-clone-helper/



謎の解明: LinuxにおけるIPアドレス取得の解読
Thu, 11 May 2023 12:10:57 +0300
LinuxでIPアドレスを取得する方法を理解するのは、特に初心者にとって少し難しいことがある。良いニュースは？見かけほど複雑ではないということだ！シンプルに説明しよう。
ifconfigコマンドの理解
ifconfigはLinuxでネットワークインターフェースを設定するために使用される最も古いツールの一つだ。export LOCAL_IP=$(ifconfig | grep "inet " | grep -Fv 127.0.0.1 | awk '{print $2}')でローカルIPを取得できる。
ipコマンドの探索
ipコマンドはifconfigを置き換えることを意図した新しいツールだ。export LOCAL_IP=$(ip route get 1 | awk '{print $NF;exit}')でIPを取得できる。
ifconfigとipの比較
年齢とサポート: ifconfigはより古く、多くの新しいディストリビューションで非推奨になりつつある。
機能: ipはより広範な機能を提供し、ルーティングテーブルなども管理する。
出力: ipはより詳細で正確な出力を提供する。
複数アドレスの処理: ifconfigは単一インターフェースに複数のIPアドレスが割り当てられている場合に苦労することがある。
両方ともIPアドレスを取得できるが、ipはより強力で多用途なツールだ。これらのコマンドを習得することでLinuxシステムのより良い制御が可能になり、ネットワーク問題のトラブルシューティングがより効率的になる。Happy networking!


AWS Well-Architected Framework: クラウドサクセスの鍵
Wed, 26 Apr 2023 00:42:29 +0300
なぜ重要なのか、なぜ必要なのか、クラウドジャーニーにおける重要な役割
クラウドはビジネスの運営方法に革命をもたらし、Amazon Web Services（AWS）はクラウドコンピューティングの先頭に立ち続けてきた。AWSは企業がクラウドで信頼性が高く効率的で安全なアプリケーションを構築・維持するのを支援するためにWell-Architected Frameworkを導入した。このブログ記事では、このフレームワークの重要性、それを使用する必要がある理由、クラウドジャーニーで果たす重要な役割を探る。
AWS Well-Architected Frameworkとは？
AWS Well-Architected Frameworkは、AWSクラウド上で高性能で回復力があり安全なアプリケーションを構築・維持するためのベストプラクティス、設計原則、アーキテクチャ推奨のセットだ。アーキテクチャにおける潜在的なトレードオフを理解し、アプリケーションのパフォーマンス、コスト、セキュリティを最適化する情報に基づいた意思決定を支援するよう設計されている。
重要な理由
最適なアプリケーションパフォーマンス: ユーザーの要求を満たしシームレスな体験を提供するようアプリケーションが設計されていることを保証する。
コスト効率: インフラストラクチャのコスト効率の高い意思決定を支援し、クラウド投資を最大限に活用できる。
セキュリティとコンプライアンス: 堅牢なセキュリティ対策の実装に関するガイダンスを提供する。
スケーラビリティと回復力: ビジネスの成長に合わせてシームレスにスケールするアプリケーションの設計を支援する。
結論
AWS Well-Architected Frameworkは、クラウドで成功するアプリケーションを構築・維持しようとするあらゆるビジネスにとって貴重なツールだ。そのガイダンスとベストプラクティスに従うことで、アプリケーションを最適化できる。


Telnetムービー - インターネット映画ストリーミングの黎明期へのノスタルジックな眼差し
Mon, 24 Apr 2023 22:07:02 +0300
Netflix、Hulu、Amazon Prime Videoがコンテンツ消費の方法を変革するずっと以前、オンラインで映画を観るための魅力的でほとんど知られていない方法があった。それがTelnetムービーだ。Telnetプロトコルで転送されるこれらのテキストベースの映画は、インターネットストリーミングの進化におけるステッピングストーンだった。このブログ記事では、Telnetムービーの歴史、発明者、コンセプトの背後にある動機、関連する最初のフォーラム投稿やメールについて掘り下げる。
歴史
Telnetは「Teletype Network」の略で、リモートコンピュータ間の通信に使用されるアプリケーションプロトコルだ。1969年に現代のインターネットの前身であるARPANETの一部として開発された。Telnetはユーザーがリモートシステムにアクセスし管理することを可能にし、初期のインターネット通信に不可欠なツールとなった。
1990年代初頭にインターネットがよりアクセスしやすくなると、ユーザーはオンラインでマルチメディアコンテンツを共有する方法を模索した。この探求がTelnetムービーの誕生につながった。これらのテキストベースのアニメーションは映画のASCIIアート表現であり、1フレームずつ丹念にテキスト文字の行に変換されたものだ。これらのテキストベースの映画はTelnetプロトコルで転送され、ユーザーはコンピュータ端末でリアルタイムに「ストリーミング」することができた。
発明と動機
Telnetムービーのコンセプトは、プログラマーでASCIIアート愛好家のSimon Jansenによるものだ。1997年、Jansenは情熱的なプロジェクトに取り組み始めた。1977年のStar Wars映画全体をASCIIフォーマットに変換するというものだ。Jansenが映画の各フレームを手動でASCIIアートに変換したため、膨大な献身が必要だった。「Star Wars ASCIIMATION」と名付けられたこのプロジェクトはインターネットセンセーションとなり、Telnetムービーの可能性を示した。
Telnetムービーの背後にある動機は、インターネットの可能性の限界を押し広げ、現状に挑戦することだった。当時、高速インターネットはまだ贅沢品で、動画コンテンツのストリーミングはほぼ不可能だった。低帯域幅要件のTelnetムービーは、テクノロジーがまだ追いついていない時代にマルチメディアコンテンツを体験するユニークな方法を提供した。
Telnetムービーのリスト
Star Wars ASCIIMATION (1997) - 最初のTelnetムービー
The Matrix (2000)
Jurassic Park (2001)
Pulp Fiction (2002)
2001: A Space Odyssey (2003)
telnet telehack.comでアクセスできる。lolcatをインストールしてtelnet telehack.com | lolcatのように実行すれば映画やその他の出力をカラー化できる！: )
Telnetムービーはインターネットストリーミングの歴史における重要なマイルストーンを表している。Simon Jansenのような先駆者によって示された創造性と決意は、今日我々が享受しているストリーミング革命の基盤を築いた。次に最新のブロックバスターをストリーミングで映画ナイトを楽しむときは、ここに至るまでの旅路を少しの間振り返ってみてほしい。この記事を書くきっかけをくれたGizemのツイートに感謝する！
hayırlı olsun ya internet bağlatmışım ama yine de çok güzel <3 pic.twitter.com/dW7EIZN7j6
— gizem (@gizemnkorkmaz) April 24, 2023
 
参考資料

pic.twitter.com/dW7EIZN7j6
April 24, 2023



AWS Lambdaでメタデータを削除してメディアファイルを保護する
Thu, 20 Apr 2023 15:36:52 +0300
今日のデジタル世界では、画像や動画にはメディアファイルについて驚くほど多くの情報を明らかにするメタデータが含まれていることが多い。画像のEXIFデータなどのメタデータには、位置情報やデバイス情報などの機密詳細が含まれる可能性がある。ユーザープライバシーを保護しセキュリティを強化するために、様々な業界の企業はメディアファイルからこのメタデータを削除することで利益を得られる。このブログ記事では、S3バケットにアップロードされた画像や動画から自動的にメタデータを削除するシンプルなAWS Lambdaスクリプトを紹介する。
恩恵を受ける業界:
ソーシャルメディアプラットフォーム: 毎日膨大な数のメディアアップロードを処理する。画像や動画からメタデータを削除することでユーザープライバシーをより適切に保護し、意図しない情報漏洩のリスクを最小化できる。
Eコマース: 製品画像やレビューなどのユーザー生成コンテンツを表示することが多い。メタデータを除去することで顧客の個人情報が不注意に露出されないことを保証する。
ヘルスケア: 医療処置からの画像や動画を含む機密性の高い患者情報を扱う。プライバシー規制を遵守し患者の機密性を保護するために不可欠だ。
ニュースとメディア: ジャーナリストやメディア組織はソースや場所に関する機密情報を含む可能性のある画像や動画を公開する。メタデータの除去はこの情報を保護し報道の整合性を維持するのに役立つ。
教育: 講義動画、研究画像、学生プレゼンテーションなどの様々なメディアファイルをホスト・共有する。メタデータを削除することで学生、教員、研究対象者に関する個人情報が保護される。

Lambdaスクリプトコード（Python、boto3、PIL、moviepy使用）とGitHubリポジトリ: https://github.com/flightlesstux/EXIF-Metadata-Remover
結論
提供したAWS Lambdaスクリプトは、S3バケットにアップロードされた画像や動画からメタデータを簡単に削除し、幅広い業界でプライバシーとセキュリティを強化する。このソリューションを実装することで、ユーザー情報を保護し、潜在的なリスクを軽減し、データ保護規制への準拠を確保できる。
参考資料

official guide
https://github.com/flightlesstux/EXIF-Metadata-Remover



NginxでのCORS: セキュリティ強化のための設定ガイド
Wed, 19 Apr 2023 21:21:10 +0300
Cross-Origin Resource Sharing（CORS）は、ウェブサーバーとブラウザ間の安全な通信を実現するための重要なメカニズムだ。ウェブアプリケーションが異なるドメインからリソースをリクエストする方法を提供することで、CORSは同一オリジンポリシー（SOP）の制限を克服するのに役立つ。SOPは、アプリケーションを配信しているドメインとは異なるドメインのデータにウェブアプリケーションがアクセスすることを制限するものだ。
このブログ記事では、CORSの重要性、その仕組み、そして異なるシナリオに応じたNginxでの設定方法を探る。また、allow-origin、allow-methods、allow-headers、expose-headersなどの主要なCORS概念についても掘り下げる。
CORSの重要性
CORSはモダンなウェブアプリケーションに不可欠だ。異なるドメインのサーバーとクライアント間の通信を可能にするからだ。これにより、アプリケーションは様々なドメインでホストされているデータやサービスに安全にアクセスしながら、ユーザーデータの整合性を維持することが保証される。
NginxでのCORS設定
Nginxは人気のあるウェブサーバーであり、CORSをサポートするよう簡単に設定できる。このセクションでは、NginxサーバーでCORSを有効にするための2つの異なる設定例を提供する。1つ目の設定は単一ドメイン用で、2つ目は複数のドメインとサブドメインをカバーする。
設定例1: 単一ドメイン（domain.com）
単一ドメインでCORSを有効にするには、Nginx設定ファイルのサーバーブロックに以下を追加する:
location / {
 add_header 'Access-Control-Allow-Origin' 'https://domain.com';
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
 add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
 add_header 'Access-Control-Expose-Headers' 'Content-Length';
}

設定例2: 複数ドメインとサブドメイン（domain.com, domain1.com, domain2.com, domain3.com, およびサブドメイン）
複数のドメインとサブドメインでCORSを有効にするには、Nginxサーバーブロックで以下の設定を使用する:
location / {
 if ($http_origin ~* (https?://(?:.+\.)?(domain\.com|domain1\.com|domain2\.com|domain3\.com)$)) {
 add_header 'Access-Control-Allow-Origin' '$http_origin';
 }
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
 add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
 add_header 'Access-Control-Expose-Headers' 'Content-Length';
}

CORSの概念
Access-Control-Allow-Origin: このヘッダーは、どのオリジンがサーバー上のリソースにアクセスを許可されるかを指定する。例では、単一ドメインを設定するか、正規表現を使用して複数のドメインとサブドメインにマッチさせている。
Access-Control-Allow-Methods: このヘッダーは、クライアントがサーバーにリクエストを行う際に使用できる許可されたHTTPメソッド（GET、POST、OPTIONSなど）を定義する。
Access-Control-Allow-Headers: このヘッダーは、クライアントがリクエストに含めることができる許可されたHTTPヘッダーをリストする。一般的なヘッダーには"Content-Type"や"Authorization"が含まれる。
Access-Control-Expose-Headers: このヘッダーは、サーバーがクライアントに公開するヘッダーを指定する。例では"Content-Length"ヘッダーを公開している。

結論
CORSはモダンなウェブアプリケーションにとって重要なセキュリティメカニズムだ。NginxでCORSを理解し実装することで、ウェブアプリケーションが異なるドメイン間で安全にリソースにアクセスできることを保証できる。このガイドにより、単一または複数のドメインとサブドメインに対してNginxでCORSを設定できるようになり、allow-origin、allow-methods、allow-headers、expose-headersなどの主要なCORS概念の重要性も理解できたはずだ。NginxサーバーがCORS準拠であることを確保することで、ウェブアプリケーションのセキュリティと機能性が向上し、より良いユーザーエクスペリエンスと様々なプラットフォーム間での互換性の向上がもたらされる。


S3 Directory ListingでS3バケットオブジェクトを簡単にリスト表示する
Tue, 18 Apr 2023 15:35:21 +0300
退屈でプレーンなS3バケットのディレクトリリストにうんざりしていないか？もっとユーザーフレンドリーで魅力的にする方法があればと思うことはないか？もう探す必要はない！S3-Directory-Listingを紹介しよう。S3バケットのディレクトリリストを、素敵なUIと検索機能を備えたファンシーでモダンなファイルとフォルダのリストに変えるシンプルで使いやすいJSスクリプトとHTMLの組み合わせだ。
まず最初に、使用方法について話そう。S3-Directory-Listingを使用するには、リポジトリをクローンするか、dark-mode.css、s3.js、index.htmlの内容をS3バケットにコピーするだけでよい。それからapp.jsのbucketName変数をバケット名で更新し、S3バケット設定を構成する。ブラウザでindex.htmlファイルにアクセスすれば、できあがり！ファンシーなS3ディレクトリリストが手に入る。こんなにシンプルなのだ！
しかし、S3バケットの設定は？この魔法を機能させるには、S3バケット設定を適切に構成する必要がある。まず、S3バケットが公開アクセス可能であること、または少なくともディレクトリリストを共有したいユーザーにアクセス可能であることを確認する。次に、オブジェクトへのパブリック読み取りアクセスを許可するバケットポリシーを設定する。以下のポリシーを使用し、<your-bucket-name>を実際のバケット名に置き換える:
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "S3DirectoryListing",
 "Effect": "Allow",
 "Principal": "*",
 "Action": [
 "s3:GetObject",
 "s3:ListBucket"
 ],
 "Resource": [
 "arn:aws:s3:::<your-bucket-name>/*",
 "arn:aws:s3:::<your-bucket-name>"
 ]
 }
 ]
}

S3-Directory-Listingは使いやすいだけでなく、高度にカスタマイズ可能だ。特定のニーズや好みに合わせてスクリプトとHTMLを調整できる。問題が発生したり質問がある場合は、GitHubリポジトリにアクセスして作成者に知らせることができる。連絡を楽しみにしている！
ダークモードでも使える！デモはこちら: https://s3-directory-listing.s3.amazonaws.com/index.html

よくドキュメント化されたREADMEとソースコードはGitHubリポジトリにある: https://github.com/flightlesstux/S3-Directory-Listing
Happy listing!
参考資料

GitHub repo
https://s3-directory-listing.s3.amazonaws.com/index.html



Composer GuardianでComposerパッケージを最新に保つ: なぜそれが重要なのか
Sat, 15 Apr 2023 19:09:12 +0300
PHP開発者として、PHPの依存関係マネージャーであるComposerにすでに精通している可能性が高い。パッケージの管理、更新の合理化、プロジェクトの円滑な実行を確保するための不可欠なツールだ。Composerを使用する上で重要な側面の一つは、パッケージを最新の状態に保つことだ。このブログ記事では、Composerパッケージを最新に保つことの重要性と、オープンソーススクリプトであるComposer Guardianがその達成にどのように役立つかについて議論する。
なぜComposerパッケージを最新に保つべきか？
セキュリティ: 古いパッケージは、新しいバージョンで対処された脆弱性を含む可能性があるため、アプリケーションをセキュリティリスクにさらす。パッケージを最新に保つことで、ハッカーの標的になるリスクを最小化する。
パフォーマンス: 新しいバージョンのパッケージには、より高速で効率的なアプリケーションにつながるパフォーマンス改善や最適化が含まれていることが多い。最新の状態を保つことで、最も効率的なバージョンのパッケージを使用していることが保証される。
互換性: PHPや他のパッケージが進化するにつれて、互換性の問題が発生する可能性がある。定期的にパッケージを更新することで、非推奨機能に関連する競合や問題に遭遇するリスクを最小化する。
バグ修正: パッケージの更新には、アプリケーションで経験しているかもしれない問題を解決できるバグ修正が含まれていることが多い。最新の状態を保つことで、潜在的な問題を回避し、よりスムーズな開発プロセスを確保できる。
新機能: 更新されたパッケージは、アプリケーションに利益をもたらす新機能を導入することが多い。パッケージを最新に保つことで、これらの機能を活用し、プロジェクト内で革新を続けることができる。

Composer Guardianの紹介
提供されるComposer Guardianと呼ばれるスクリプトは、パッケージ更新を把握し続けるのを助けるよう設計されている。composer.jsonファイルを読み取り、更新をチェックし、どのパッケージを更新する必要があるかを詳細に示すレポートを生成する。
主な機能:
composer.jsonファイルにリストされている各パッケージの最新安定版を取得する
特定のプレフィックス（'ext-'など）または除外パッケージ（'php'など）をスキップする
パッケージ名、現在のバージョン、最新バージョンを含むテーブルを表示する
オプションでwebhook URLを使用してSlackチャネルにレポートを送信する

使用方法:
Composer Guardianを使用するには、GitHubリポジトリをクローンし、適切なコマンドラインオプションまたは環境変数でスクリプトを実行するだけだ。例えば:
python/python3 composer_guardian.py --composer-file-path /path/to/composer.json --slack-webhook-url https://hooks.slack.com/services/...

または、環境変数を使用する:
export COMPOSER_FILE_PATH=/path/to/composer.json
export SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
python/python3 composer_guardian.py

チェックを自動化する: スケジュール実行のCI/CD
スクリプトを手で実行するやり方は、忘れたその週まででしか機能しない。このチェックは、誰も覚えていなくてもスケジュールで動いてこそ意味がある。Composer Guardianは更新があると非ゼロの終了コードで終わるため、どのCIシステムでも古い依存関係を正式な結果として扱える。レポートするか、パイプラインを失敗させるかだ。
GitHub Actionsなら、週次のcronと手動トリガーで十分だ。以下をPHPプロジェクトの.github/workflows/composer-guardian.ymlとしてコピーし、Slackのwebhook URLをSLACK_WEBHOOK_URLという名前のリポジトリsecretに追加する:
name: Composer Guardian
on:
schedule:
- cron: “0 9 * * 1” # every Monday at 09:00 UTC
workflow_dispatch: {}
jobs:
check-dependencies:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3


AWSのCarrier Gatewayとは？
Fri, 24 Feb 2023 20:19:15 +0300
Amazon Web Services（AWS）は、シームレスで安全なクラウドコンピューティング体験をユーザーに提供するために多くのサービスを提供している。そのうちの一つがCarrier Gatewayで、顧客ネットワークをAWSに接続するための簡素化され集中化されたソリューションを提供するよう設計されている。
AWSのCarrier Gatewayとは？
Carrier Gatewayは、AWS顧客がオンプレミスのデータセンターまたはネットワークとAWS上のVirtual Private Cloud（VPC）の間に直接かつプライベートな接続を確立できるサービスだ。ユーザーがネットワークトポロジーをAWSに拡張し、オンプレミスインフラストラクチャとAWSの間に安全で高帯域幅の接続を提供する。
Carrier Gatewayは複数のAWSリージョンに接続するための単一のゲートウェイを提供するため、各リージョンに複数のVPN接続を作成する必要がなくなる。これにより顧客はネットワークインフラストラクチャの管理が容易になり、運用の複雑さが軽減される。
Carrier Gatewayの利点
セキュリティ強化: 業界標準の暗号化と認証プロトコルを使用してデータのプライバシーとセキュリティを確保する。
高性能: 顧客ネットワークとAWS間の高帯域幅接続を提供し、データ転送の高速化とレイテンシの低減を実現する。
簡素化されたネットワーク管理: 顧客ネットワークをAWSに接続するための集中化ソリューションを提供する。
コスト効率: 高価な専用線やMPLS回線の必要性を排除し、接続コストを大幅に削減する。
結論
AWSのCarrier Gatewayは、顧客ネットワークをAWSに接続するための安全で高帯域幅、コスト効率の高いソリューションを提供する強力なサービスだ。オンプレミスインフラストラクチャのAWSへの接続を検討しているなら、Carrier Gatewayは優れた選択肢だ。


Terraformを使ったAWS EC2インスタンスへの安全なアクセスのためのSSHキー作成
Wed, 15 Feb 2023 09:11:24 +0300
クラウドインフラストラクチャを扱う際、セキュリティは最も重要だ。セキュリティの重要な側面の一つはクラウドリソースへのアクセス制御であり、これはAWS EC2インスタンスを扱う際に特に重要だ。SSHキーはEC2インスタンスへのアクセスを保護する一つの方法であり、Terraformを使えばこれらのキーの作成と管理が簡単になる。
SSHキーはEC2インスタンスへの安全なアクセスに使用され、公開鍵と秘密鍵の2つの部分で構成される。公開鍵はEC2インスタンスにアップロードされ、秘密鍵はインスタンスの認証に使用される。秘密鍵は安全に保管し、誰とも共有すべきではない。
Terraformはコードとしてのインフラストラクチャを管理するための強力なツールであり、AWS EC2インスタンスへの安全なアクセスのためのSSHキーの作成と管理に使用できる。その方法は以下の通りだ。
まず、SSHキーペアを作成する。これはローカルマシンでssh-keygenコマンドを使って行える。4096ビットの鍵サイズでRSAキーペアを生成するには、以下のコマンドを実行する:
ssh-keygen -t rsa -b 4096

これにより、ホームディレクトリの.sshディレクトリに公開鍵と秘密鍵が生成される。公開鍵は.pub拡張子を持ち、EC2インスタンスにアップロードされるべきものだ。
次に、SSHキーを管理するためのTerraformモジュールを作成する。モジュールには以下のコードを含める必要がある:
resource "aws_key_pair" "ssh_key" {
 key_name = "ssh_key"
 public_key = file("~/.ssh/id_rsa.pub")
}

これは"ssh_key"という名前のAWSキーペアリソースを作成し、ローカルマシンから公開鍵をAWSにアップロードする。file()関数はローカルマシンの公開鍵ファイルの内容を読み取るために使用される。
次のステップは、EC2インスタンスリソースでSSHキーを参照することだ。これはaws_instanceリソースのkey_nameパラメータで行える:
resource "aws_instance" "example" {
 ami = "ami-0c55b159cbfafe1f0"
 instance_type = "t2.micro"
 key_name = aws_key_pair.ssh_key.key_name
// other instance configuration
}

これは指定されたAMIとインスタンスタイプでEC2インスタンスを作成し、key_nameパラメータを使用してSSHキーをインスタンスに関連付ける。aws_key_pair.ssh_key.key_nameの値は、前のステップで作成されたキーペアリソースの名前への参照だ。
最後に、terraform initでTerraformモジュールを初期化し、terraform applyで変更を適用する。TerraformはSSHキーペアリソースと、関連付けられたSSHキーを持つEC2インスタンスリソースを作成する。
このセットアップにより、先ほど生成した秘密鍵を使ってEC2インスタンスに安全にアクセスできるようになる。これを行うには、ローカルマシンでsshコマンドを使用する:
ssh -i ~/.ssh/id_rsa ec2-user@<instance_public_ip>

これにより、秘密鍵とデフォルトユーザーec2-userを使用してEC2インスタンスに接続する。<instance_public_ip>をEC2インスタンスのパブリックIPアドレスに置き換えること。
まとめると、AWS EC2インスタンスへの安全なアクセスにSSHキーを使用することは、クラウドインフラストラクチャセキュリティの重要な部分だ。Terraformを使えば、コードとしてのインフラストラクチャの一部としてこれらのキーを作成・管理することが簡単になる。この記事で概説した手順に従うことで、EC2インスタンスへの安全なアクセスを確保し、クラウドインフラストラクチャを保護できる。


AWSのEgress-Onlyインターネットゲートウェイとは？
Tue, 31 Jan 2023 06:48:25 +0300
Amazon Web Services（AWS）はあらゆる規模のビジネスに様々なインフラストラクチャサービスを提供する主要なクラウドコンピューティングプラットフォームの一つだ。AWSの重要なコンポーネントの一つがVirtual Private Cloud（VPC）で、ユーザーは論理的に分離された仮想ネットワーク内でリソースを分離できる。VPC内でEgress-Onlyインターネットゲートウェイは、VPCからインターネットへのアウトバウンドトラフィックを可能にする不可欠なコンポーネントだ。
Egress-Onlyインターネットゲートウェイは、水平スケーリングされ冗長で高可用なVPCコンポーネントであり、VPC内のインスタンスからインターネットへのアウトバウンド専用トラフィックの安全な方法を提供する。ステートフルゲートウェイとして動作し、VPC内のインスタンスから開始されたネットワーク接続を追跡し、対応する戻りトラフィックが自動的にVPCに戻ることを許可する。
主な利点は、VPC内のインスタンスがインターネットにアクセスするための安全で信頼性の高い方法を提供することだ。例えば、Amazon S3やAmazon EC2などのパブリックAWSサービスへのアクセスや、パブリックウェブサイトへのアクセスを許可するために使用できる。また、インターネットからVPC内のインスタンスへのすべての受信トラフィックをブロックし、送信トラフィックのみを許可するため、インスタンスのセキュリティも強化する。
結論
Egress-Onlyインターネットゲートウェイは、VPC内のインスタンスがインターネットにアクセスするための安全で信頼性の高い方法を提供するAWS Virtual Private Cloud（VPC）の不可欠なコンポーネントだ。VPCからのアウトバウンドインターネットトラフィックを完全に制御でき、セキュリティを強化し、運用オーバーヘッドを削減する。Egress-Onlyインターネットゲートウェイを使用することで、基盤となるインフラストラクチャの管理を心配することなく、パブリックAWSサービスやインターネットに安全にアクセスできる。
参考資料

www.google.com



AWSのインターネットゲートウェイとは？
Wed, 11 Jan 2023 14:50:24 +0300
Amazon Web Services（AWS）インターネットゲートウェイは、水平スケーリングされ冗長で高可用なVPCコンポーネントであり、VPC内のインスタンスとインターネット間の通信を可能にする。したがって、VPCとインターネットの間のブリッジとして機能する。
VPCを作成してもインターネットゲートウェイは自動的には作成されない。VPC内のインスタンスがインターネットと通信する前に、手動でインターネットゲートウェイを作成してVPCにアタッチする必要がある。インターネットゲートウェイがVPCにアタッチされると、インターネットトラフィックをインスタンスにルーティングできるようになる。
インターネットゲートウェイは水平スケーラブルで、通過するリクエスト数に応じて自動的に容量を調整する。また冗長性があり、1つのインターネットゲートウェイが故障しても別のものが引き継ぎ、サービスの中断がないことを保証する。
インターネットゲートウェイを作成するには、AWS Management ConsoleにログインしVPCダッシュボードに移動して、「インターネットゲートウェイ」メニューから新しいものを作成する。作成したら、VPCのルートテーブルでインターネットトラフィック（0.0.0.0/0）をインターネットゲートウェイに向けるルートを作成する必要がある。これはインターネットトラフィックの「デフォルトルート」と呼ばれることが多い。
結論
要約すると、AWSインターネットゲートウェイは水平スケーリングされ冗長で高可用なVPCコンポーネントであり、VPC内のインスタンスとインターネット間の通信を可能にする。また、インバウンドおよびアウトバウンドトラフィックを制御するセキュリティグループやネットワークアクセスコントロールリストなどのセキュリティ機能や、VPNまたはDirect Connect経由でオンプレミスリソースに接続する方法も提供する。


AWS VPCのルートテーブルとは？
Tue, 03 Jan 2023 09:03:38 +0300
Amazon Web Services（AWS）のルートテーブルは、Virtual Private Cloud（VPC）内でトラフィックがどのように転送されるかを決定するために使用される。ルートテーブルには、どのネットワークトラフィックがどのネットワークインターフェースに向けられるかを指定するルートと呼ばれる一連のルールが含まれている。
VPC内の各サブネットはルートテーブルに関連付けられている必要があり、サブネットは一度に1つのルートテーブルにのみ関連付けられるが、1つのルートテーブルは複数のサブネットに関連付けることができる。ルートは宛先とターゲットで構成される。宛先はトラフィックが送信されるIPレンジで、ターゲットはトラフィックの送信先となるネットワークインターフェースだ。
ルートテーブルには2種類のルートがある:
ローカルルート: VPC内のトラフィックに適用される。すべてのVPCにはサブネット間のトラフィックを許可するデフォルトのローカルルートがある。
インターネットゲートウェイルート: インターネットへのトラフィックに適用される。すべてのVPCにはVPCとインターネット間のトラフィックを許可するデフォルトのインターネットゲートウェイルートがある。
デフォルトのルートテーブルに加えて、カスタムルートテーブルも作成できる。ルートテーブルの設定時の考慮事項: インターネットにアクセスする必要があるサブネットにはインターネットゲートウェイルートがあることを確認、VPC内で相互に通信する必要があるサブネットにはローカルルートがあることを確認、デフォルトルートテーブルが適切に設定されていることを確認、固有のルーティング要件がある特定のサブネット用のカスタムルートテーブルの作成を検討する。
結論
要約すると、AWSのルートテーブルはVPC内のトラフィックのルーティングを制御するために使用される。ルートテーブルを適切に設定することは、VPC内でトラフィックが正しく向けられ、アプリケーションのパフォーマンスを維持するために重要だ。


AWS VPCのサブネットとは？
Sat, 10 Dec 2022 09:05:25 +0300
Amazon Web Services（AWS）Virtual Private Cloud（VPC）は、ユーザーがクラウド上で独自の仮想ネットワークを作成・管理できるクラウドコンピューティングサービスだ。これにより、VPCのサブネット化のカスタマイズを含め、ネットワークとリソースを完全に制御できる。
AWS VPCのサブネットは、VPCを複数の論理ネットワークに分割するために使用される。これによりユーザーはリソースを分離し、それらのリソースへのアクセスを制御できる。サブネットはパブリックまたはプライベートにでき、パブリックサブネットはインターネットにアクセスでき、プライベートサブネットはアクセスできない。
AWS VPCでのサブネット作成は簡単で、AWS Management Consoleから行える。サブネット作成時の重要な考慮事項:
CIDRブロック: サブネットで使用できるIPアドレスの範囲を指定する。CIDRブロックはVPCのCIDRブロック範囲内である必要がある。
アベイラビリティゾーン: 複数のAZにサブネットを作成することで高可用性と冗長性が提供される。
サブネット化は、開発、ステージング、本番などの異なる環境にVPCをセグメント化するのにも役立つ。パブリックサブネットにNATゲートウェイを作成してプライベートサブネットのインターネットアクセスを有効にすることもできる。また、VPC Peeringを使用して2つのVPCを接続し、リソースを共有することも可能だ。
結論
AWS VPCのサブネットは、クラウド内の仮想ネットワークをカスタマイズ・制御する能力を提供する。サブネット化によりVPCを複数の論理ネットワークにセグメント化し、リソースを分離してアクセスを制御できる。高可用性や冗長性、VPC間の接続などの利点も提供する。全体として、AWS VPCでサブネットを使用することで、クラウドベースのネットワークの柔軟性と機能性が大幅に向上する。


AWS VPCとは？
Wed, 07 Dec 2022 05:56:09 +0300
AWS VPCとは？
Amazon Web Services（AWS）Virtual Private Cloud（VPC）は、ユーザーがAWSクラウド内で独自の仮想プライベートネットワーク（VPN）を作成・管理できるサービスだ。これにより、ユーザーは自身のIPアドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、独自のネットワーク環境を完全に制御できる。
VPCを使用する主な利点の一つは、インターネットや他のAWSサービスに安全に接続できることだ。VPCを使用すると、ウェブサーバー用のパブリック向けサブネットとデータベース用のプライベート向けサブネットを作成でき、機密データのセキュリティと分離が向上する。
VPCではまた、ネットワークアクセスをより細かく制御できる。セキュリティグループとネットワークACLを使用して、サブネットおよびネットワークインターフェースレベルでインバウンドおよびアウトバウンドトラフィックを制御できる。特定のIPアドレスや範囲、ポート、プロトコルへのアクセスを制限する詳細なルールを作成できる。
さらに、VPCではAWS PrivateLinkを使用でき、インターネットゲートウェイやVPN接続を必要とせずにAWSネットワーク経由でサービスに安全にアクセスできる。VPC Flow Logsでネットワークインターフェースとの間のIPトラフィック情報をキャプチャでき、ネットワーク問題の監視とトラブルシューティングに役立つ。また、オンプレミスネットワークへのVPN接続を作成できる。
結論
AWS VPCはユーザーにAWSクラウド内で高度にカスタマイズ可能で安全なネットワーク環境を提供する。VPCを使用することで、インターネットや他のAWSサービスに簡単に接続し、ネットワークアクセスを制御し、他のAWSサービスと統合できる。これにより、クラウド環境に対するより大きな柔軟性と制御が可能になり、AWSクラウドで複雑な多層アプリケーションを構築・デプロイできる。


nginxがプロキシのDNSをキャッシュするのを防ぐ
Mon, 22 Aug 2022 12:17:44 +0300
皆さんこんにちは、

nginxをプロキシやリバースプロキシとして使用している場合、nginxはDNS情報をキャッシュする。そしてnginxの背後でAWS Application Load Balancerを使用している場合、AWSは常にCNAMEを提供しロードバランサーのIPアドレスを頻繁に変更するため、nginxはAWS Application Load Balancerにリクエストを送信するために時々再起動やDNSフラッシュが必要になることがある。
nginxでDNSをフラッシュするオプションはなく、唯一のオプションはnginxを再起動することだが、常に再起動で問題を解決できるわけではない : ) 以下のnginx設定を使用してこのDNSキャッシング問題を修正できる。
server {
 listen 80;
 server_name proxy-request.ercanermis.net;
include /etc/nginx/default.d/*.conf;
set $proxydestination “backend.ercanermis.com”;
proxy_pass https://$proxydestination;
proxy_http_version 1.1;
proxy_set_header Host proxy-request.ercanermis.net;
proxy_redirect off;
proxy_cache_bypass 1;
proxy_no_cache 1;
resolver 8.8.8.8 valid=5s;
}
}

質問があれば、お気軽にコメントしてください。ありがとう！


AWSでのPHPアプリケーションのスケーリング
Wed, 10 Aug 2022 05:18:09 +0300
AWS上で高可用、高性能、安全なPHPアプリケーションを実行する方法を理解できる。
Amazon Route 53はDNSを解決してエンドユーザーのリクエストをルーティングする。
Amazon CloudFrontはグローバルなポイントオブプレゼンスを活用してコンテンツをキャッシュし配信を加速する。CloudFrontはSSL終端も処理し、SSL証明書を自動的に作成・更新するAmazon Certificate Managerと統合する。
AWS WAFはCloudFrontおよびApplication Load Balancerと統合し、OWASPトップ10のアプリケーション脆弱性を緩和する。
Application Load BalancerはHTTP/Sリクエストをプライベートサブネットで実行されているEC2インスタンスにルーティングする。
Amazon Linux 2 AMIにはPHPやAWS SDK for PHPなどの必要なバイナリが含まれる。
Amazon Linux 2 AMIにインストールされたAmazon CloudWatch Agentがアプリケーションログ、追加のホストレベルメトリクス、カスタムビジネスメトリクスをストリーミングする。
Amazon EC2 Auto ScalingがCPUやメモリなどのメトリクスに基づいてインスタンスの起動を管理する。コスト最適化のためにAmazon Gravitonインスタンスを使用する。
Systems Manager Session Managerを使用して、AWSコンソール上のウェブベースのセッションでEC2インスタンスに接続する。SSHポートのキーペアを開く必要はない。
データベース認証情報はAWS Secrets Managerに安全に保存される。PHP用AWS SDKを使用して、アプリケーションコードがIAMロールを通じてSecrets Managerに保存された認証情報を取得する。
アプリケーションコードは、使い慣れたGit CLIを使用してAWS CodeCommitに安全に保存される。
AWS CodePipelineがCI/CDを実装し、新しいEC2インスタンスの起動時にトリガーされるAWS CodeDeployフックを使用してコードデプロイメントをオーケストレーションする。
Amazon ElastiCache for Redisがセッションデータをキャッシュする。
Amazon Aurora Multi-AZが高可用性を実現する。アプリケーションは障害時に自動的にフェイルオーバーを処理するDNSエンドポイント経由で接続する。Auroraリーダーエンドポイントが読み取り操作を処理し、Auroraライターインスタンスの負荷をオフロードする。
Amazon Elastic File System（Amazon EFS）がAuto Scalingグループとウェブコンテンツを保存・共有する。


CLIでS3バケットを作成しポリシーを設定する
Sun, 17 Jul 2022 12:09:37 +0300
CLIコマンドを使うのが本当に好きで、それが私の日常だ。今日は「AWSでS3バケットを作成する方法」と「CLIでS3バケットポリシーを設定する方法」を説明する。始めよう...
まず、AWS_ACCESS_KEYとAWS_SECRET_ACCESS_KEYを設定する必要がある。つまり、事前にaws configureコマンドを実行する必要がある。それができれば先に進める。
まずS3バケットを確認する
最初に、どのバケットがあるかを確認する必要がある。aws s3 lsコマンドを実行すると、既存のバケットが返される。
➜ ~ aws s3 ls
2021-04-26 11:01:32 ercanermis
2021-05-20 19:14:04 ercanermis-aws-ssm-logs
2021-04-26 11:01:43 ercanermis-com
2021-04-26 11:02:08 www-ercanermis-com
S3バケットを作成する
S3バケット作成コマンドもシンプルで簡単だ。aws s3 mbだ。実行して再度バケットを一覧表示しよう。
➜ ~ aws s3 mb s3://hello-this-is-new-bucket
make_bucket: hello-this-is-new-bucket
確認のため、再度すべての既存バケットを一覧表示する。
➜ ~ aws s3 ls
2021-04-26 11:01:32 ercanermis
2021-05-20 19:14:04 ercanermis-aws-ssm-logs
2021-04-26 11:01:43 ercanermis-com
2022-07-17 14:23:29 hello-this-is-new-bucket
2021-04-26 11:02:08 www-ercanermis-com
はい、新しく作成したバケットが表示されている。バケット名はhello-this-is-new-bucketだ。
S3バケットのバケットポリシーを確認する
前のステップでバケットを作成したが、バケットポリシーはどうだろう？まず、既存のポリシーがあるかどうかを確認する必要がある。以下が例だ:
➜ ~ aws s3api get-bucket-policy --bucket hello-this-is-new-bucket
An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist



AWS Route53でLet's Encrypt SSLを発行する
Sat, 16 Jul 2022 04:47:34 +0300
こんにちは、

この記事では、AWS Route53サービスを使ってLet's Encrypt SSLを発行する方法を紹介する。学び始めよう。
Let's Encryptとは？
Let's EncryptはInternet Security Research Group（ISRG）が運営する非営利の証明機関で、Transport Layer Security暗号化のためのX.509証明書を無料で提供している。つまり、プロジェクトやアプリ用に無料のSSL証明書を取得でき、そのSSL証明書は90日間有効だ。自動更新のために何らかの自動化を行う必要がある。
AWS Route53とは？
Amazon Route 53はスケーラブルで高可用なドメインネームシステムサービスだ。2010年12月5日にリリースされ、Amazon.comのクラウドコンピューティングプラットフォームであるAmazon Web Servicesの一部である。新しいドメインを登録したり、既存のドメインを移管したり、単にドメインのDNS管理システムを使用したりできる。
この記事では、Google Domainsで登録した自分のドメインの一つを使用し、DNS管理システムだけを使うことにした。念のため、ドメインタイプはRoute53のパブリックホストゾーンである必要がある。私のドメインは"ermis.email"だ。私のドメインのNSレコードを自由にチェックしてほしい : )
なぜLet's Encrypt SSLの発行にRoute 53を使うのか？
Let's Encryptから新しいSSL証明書をリクエストすると、certbotがLet's Encryptサーバーにリクエストを送信するが、暗号化証明書を取得するためにAWSの外にHTTP（安全でない）リクエストを送受信したくない : ) それは少し奇妙で、セキュリティ上の問題を引き起こす可能性があると思う。

あるいは、単にSSL証明書が必要で、nginxやapache、その他の種類のウェブサーバーサービスにSSL証明書を直接バインドしたくない場合もある。そして、この方法の方がより便利で速く、何らかの自動化も可能だ...
IAMポリシー
AWS内で直接SSLを発行するためにAWS EC2を使用することにした。まず、Route53にアクセスするためのIAMポリシーを作成する必要がある。EC2にはElastic IPがあり、IAMポリシーをより安全にし、Route53リソースへのアクセスを制限する。このポリシーはIAMロールとして使用できず、特定のプロファイル名"certbot-route53"でaws-cli操作用に設定する。以下がIAMポリシーの例だ:
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "CertbotRoute53",
 "Effect": "Allow",
 "Action": [
 "route53:GetChange",
 "route53:ListHostedZones"
 ],
 "Resource": "*",
 "Condition": {
 "IpAddress": {
 "aws:SourceIp": "3.92.136.59/32"
 }
 }
 },
 {
 "Sid": "CertbotRoute531",
 "Effect": "Allow",
 "Action": "route53:ChangeResourceRecordSets",
 "Resource": "arn:aws:route53:::hostedzone/Z01859902ZBFBUXJ0AV3J",
 "Condition": {
 "IpAddress": {
 "aws:SourceIp": "3.92.136.59/32"
 }
 }
 }
 ]
}
メールサーバーのDNS名は"hermes.ermis.email"で、AレコードはSimple Routingで3.65.142.23を指している。"hermes.ermis.email"用のLet's Encrypt SSLをリクエストする。ドメインのTLDがcom/net/orgではないので少し違って見えるかもしれないが問題ない。ただのドメインとDNSだ : )


AWS Application Load BalancerでLet's Encrypt SSLを自動化する
Sat, 02 Jul 2022 18:09:07 +0300
ほとんどの場合、AWS Certificate Manager（ACM）以外に必要なものはないが、顧客のドメインをALBでホストしていて、顧客からSSL証明書を取得する手段がない場合など、いくつかのケースでは回避策が必要になる。この記事では、AWS Application Load BalancerでLet's Encrypt SSLを発行し、それを自動化する方法を解説する。
Let's EncryptにSSL証明書をリクエストする際、LEにはweb-challenge、route53などの検証方法がある。このシナリオでは、ドメインのDNS管理が自分の手にないため、web-challengeを使用することにした。私はアプリケーションをホストしているだけで、SSLを発行する必要がある。
web-challengeでSSLをリクエストする場合、Let's Encryptは https://domain.com/.well-known/acme-challenge パスをチェックして確認・検証を行う。これはどういう意味か？つまり、Let's Encryptがポート80でドメインにリクエストを送信し、検証を行うということだ。うーん、Load Balancerの設定にいくつか調整が必要で、acme-challengeリクエストを特別にリダイレクトするための別のTarget Groupが必要になる。
Step 1: 新しいEC2を起動し、新しいTarget Groupを作成する
リポジトリをクローンする
簡単な管理と全ドメインで同じ方法で標準を維持するために、bashスクリプトを書いた。GitHubリポジトリをチェックするか、/opt/パス配下のacme-challange-serverにリポジトリをクローンしてほしい。
Tip: # git clone https://github.com/flightlesstux/alble.git
nginx、Let's Encryptをインストールして設定する
/.well-known/acme-challenge/* リクエストを受け取ると、nginxがインストールされたEC2がすべてのacme-challengeリクエストを処理し、SSLを発行する。
nginxをインストールし、/.well-known/acme-challenge/ 用に設定する
amazon-linux-extras install nginx1 コマンドでnginxを簡単にインストールできる。インストール後、nginxのルート設定ファイルに新しいlocationブロックを追加する。ルート設定ファイルは /etc/nginx/nginx.conf にある。
 location /.well-known/acme-challenge {
 root /opt/alble/certbot-challange;
 }
server_name の値は全ドメインに対して _; にする必要がある。静的なDNS名は設定できない。
nginxモジュール付きでCertbotをインストールする
まず、epelリポジトリからcertbotをインストールする。最初にepelをインストールする必要がある。epelのインストールには amazon-linux-extras install -y epel コマンドを使い、その後 yum install -y nginx certbot python2-certbot-nginx jq dig コマンドを実行して前提条件をカバーする。
acme-challengeサーバー用のIAMロールポリシー
このacme-challengeサーバーには、Let's Encrypt SSLでACMとALBの操作にアクセスするためのIAMロールがある。IAMポリシーは以下の通り。


Bitbucket PipelinesでS3とCloudFrontにウェブサイトをデプロイする
Thu, 23 Jun 2022 11:44:00 +0300
BitbucketはAtlassian製品であり、Gitベースのコードストアと、Jiraを使用するコラボレーションチーム向けに最適化されたCI/CDツールだ。Bitbucketでコードを変更し、リビジョンと履歴を保持する場合、デプロイメントのための自動化も必要になる。

CI/CDはすべての自動化のためのもので、Continuous Integration（継続的インテグレーション）とContinuous Delivery（継続的デリバリー）を意味する。この記事では、CIとCDを同時に使用する。

「Bitbucketの使い方」は省略し、世界中に配信するためにCloudFrontを使用しているAWS S3への継続的デプロイメントのためのBitbucket Pipelinesについて紹介する。
静的ホスティングがサポートされたS3バケットを作成したら、ローカルフォルダからS3バケットにsyncする必要がある。通常、ローカルフォルダをS3バケットに100%同期するにはaws s3 sync LOCAL_FOLDER/ s3://STATIC_HOSTING_ENABLED_BUCKET_NAME --deleteコマンドを実行する。
配信にCloudFrontを使用している場合、ウェブサイトにアクセスすると古いコンテンツが表示される。その理由は、CloudFrontがすべてのエッジロケーションですべてのコンテンツをキャッシュし、エッジロケーションからコンテンツを配信しているからだ。新しいコンテンツのために「キャッシュを無効化」し、エッジロケーションで再キャッシュする必要がある。
S3とCloudFrontに使用するIAMポリシー
最大限のセキュリティのために、IAMポリシーには最大限の制限と最小限の許可を設定するのが本当に好きだ。以下のポリシーを確認できる:
S3バケットIAMポリシー
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "S3BucketPolicy",
 "Effect": "Allow",
 "Action": [
 "s3:PutObject",
 "s3:GetObject",
 "s3:ListBucket",
 "s3:DeleteObject"
 ],
 "Resource": [
 "arn:aws:s3:::BUCKET_NAME",
 "arn:aws:s3:::BUCKET_NAME/*"
 ],
 "Condition": {
 "ForAnyValue:IpAddress": {
 "aws:SourceIp": [
 "34.199.54.113/32",
 "34.232.25.90/32",
 "34.232.119.183/32",
 "34.236.25.177/32",
 "35.171.175.212/32",
 "52.54.90.98/32",
 "52.202.195.162/32",
 "52.203.14.55/32",
 "52.204.96.37/32",
 "34.218.156.209/32",
 "34.218.168.212/32",
 "52.41.219.63/32",
 "35.155.178.254/32",
 "35.160.177.10/32",
 "34.216.18.129/32",
 "3.216.235.48/32",
 "34.231.96.243/32",
 "44.199.3.254/32",
 "174.129.205.191/32",
 "44.199.127.226/32",
 "44.199.45.64/32",
 "3.221.151.112/32",
 "52.205.184.192/32",
 "52.72.137.240/32"
 ]
 }
 }
 }
 ]
}
デプロイメントはBitbucket Pipelinesで実行され、これらのIPアドレスはBitbucket PipelinesのアウトバウンドIP用だ。リファレンスはこちら: https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/ 


指定されたIPでAWSアカウントを保護する
Thu, 16 Jun 2022 13:18:15 +0300
セキュリティは常に重要であり、クラウドで何かを行う前の第一のことだ。私は5年以上IP制限ポリシーを使用しており、このトリックを共有したい。2つの異なる方法がある。

ISPから静的IPを取得するか、VPNのIPアドレスも使用できる。
IPポリシーの利点は？
答えはシンプルだ。指定されたIPを使用していなければ、誰もクラウド内のリソースにアクセスできない。
IAMポリシーに特定のIPアドレスがない状態でログインした場合の例を以下に示す。ユーザーはログインできるが、リソースや情報については何も見ることができない。


特定のIPアドレスでログインした場合の例。すべて正常に見え、ユーザーはリソースやその他の情報を確認できる。

IPが一致した場合にアクセスを許可する
リソースへのアクセス権限を付与したい場合のIAM IPポリシーは以下の通り:
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "AllowAccessIfIPsMatch",
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*",
 "Condition": {
 "ForAnyValue:IpAddress": {
 "aws:SourceIp": [
 "1.2.3.4/32",
 "5.6.7.8/32"
 ]
 }
 }
 }
 ]
}
IPが一致しない場合にアクセスを拒否する
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "DenyAccessIfIPsDontMatch",
 "Effect": "Deny",
 "Action": "*",
 "Resource": "*",
 "Condition": {
 "NotIpAddress": {
 "aws:SourceIp": [
 "1.2.3.4/32",
 "5.6.7.8/32"
 ]
 }
 }
 }
 ]
}
このIAMポリシーはaws-cliリクエストやすべてのAWS APIコールにも影響する。AllowまたはDenyポリシーは同じ（逆もまた然り！）で、両方を同時に使用する必要はない。AWSアカウントを保護する方法が複数あることを知らせたかっただけだ。

注意: このIAMポリシーはIP制限のロジックについて伝えているに過ぎない。本番環境のアカウントでこのIAMポリシーを使用する前によく考えてほしい。すべてのAWSリソースへのAdministratorAccessを許可するものだからだ！

IAM IPポリシーを適用する前に、Amazon Web Servicesアカウントをセキュアにする方法についての以前のブログ記事をチェックするといいかもしれない。

読んでくれてありがとう！


AWS CLI v1とv2の違い
Thu, 09 Jun 2022 23:35:00 +0300
v1を使用している場合、aws-cliがCLIコマンドを実行できないことがある。aws cliがv1の場合はアップデートを推奨する。この記事では、どのような状況でAWS CLI v2を使用すべきかを学ぶ。

AWS CLI v1はPython言語で書かれており、v1では最初にPythonをインストールする必要があるが、v2では組み込みで提供され、Pythonインタプリタは不要だ。
Auto Prompt機能は素晴らしい！AWS CLI v2は、awsコマンドを実行する際にコマンド、パラメータ、リソースをプロンプトで表示できる。
設定をインポートできる！AWS CLI v2にはaws configure importオプションが付属しており、AWS Management Consoleから生成された.csv認証情報をインポートできる。.csvファイルはIAMユーザー名と一致するプロファイル名でインポートされる。例: aws configure import。
高レベルS3コマンドのメタデータサポート: --copy-props引数を使用して、高レベルS3コマンドの追加メタデータサポートを設定できる。
AWS_REGION: は間違いなく命の恩人だ！SDK互換の変数で、環境上のAWS_DEFAULT_REGION変数を上書きする。AWS CLIでのみ利用可能だ。
ddb putおよびddb selectコマンドがDynamoDB操作用にAWS CLI v2で利用可能になった。DynamoDBにアイテムを投入し、DynamoDBテーブルやインデックスを検索できる。
YAMLサポート: 以前はAWS CLI v1はJSONのみを使用していたが、v2ではストリーム形式とyamlに対してより動的になった。
aws configure list-profiles: 1つのコマンドですべてのaws cliプロファイルを一覧表示できる。
Dockerサポート: これはAWS CLI v2をもうインストールする必要がないことを意味する。Dockerコンテナを実行してaws cliコマンドを簡単に実行できるだけだ。心配なくCI/CDに直接組み込める。
aws logs tail: CloudWatch Logsグループに対して、aws logs tailコマンドでログをテールできる。デフォルトでは、このコマンドは過去10分間のすべてのCloudWatch Logsストリームからログを返す。
シングルサインオン: エンタープライズユーザーであれば、おそらくSSOを使用してAWSコンソールにログインしているだろう。AWS CLI v2はサインインリクエストにIdPをサポートするようになった。例えば、Active DirectoryやGoogle Cloud SSOサービスを使用している場合、AWS CLI v2経由でも使用できる。
クライアントサイドページャープログラム: AWS CLI v2は出力にクライアントサイドのページャープログラムの使用を提供する。デフォルトではこの機能はオンになっており、すべての出力をOSのデフォルトページャープログラムを通じて返す。
ウィザード: これは本当に興味深い機能だと思う。configure、dynamodb、events、iam、lambdaのいくつかでウィザードを使用できる。GitHubの例を参照: https://github.com/aws/aws-cli/tree/v2/awscli/customizations/wizard/wizards 

この記事が役立つことを願っている。




CentOS 7 DockerでのSSL CA問題と解決策
Tue, 08 Mar 2022 08:19:26 +0300
MacBookPro M1でCentOS 7のDockerイメージを触っていると、HTTPS接続を必要とするサーバーに接続できないようだった。

例えば、yum -y updateコマンドを実行するとcurl: (77) Problem with the SSL CA cert (path? access rights?)が返ってくる。私のca-certificatesは問題ないので、OSのバグのようだ。

curlでGETコマンドを送信してみたが、うまくいかないようだ。wgetもHTTPS接続で動作しない。オンラインで調査したところ、これは実際のバグだとわかった。詳細: https://bugs.centos.org/view.php?id=16282
解決策
$ touch "/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned"
そう、これだけだ。TCP接続を安全に実行するためにこのファイルが必要なだけだ。解決後の結果では、curlでHTTPSが正常に動作するようになる。
今のところM1マシンでのみ再現されるのも謎だ。しかし当面は原因を特定できたので、目標に到達できればそれでいいだろう？
参考資料

https://bugs.centos.org/view.php?id=16282



私は何を持っているか？
Tue, 20 Jul 2021 15:02:36 +0300
まずは、晴れたイズミールからこんにちは。今日は火曜日だが休みの日のように感じる。情熱的な人々と働くコミュニティのために技術記事を書く必要があるのはわかっている。準備中だから約束する... タイトルは「Cloud: Using NAT on Private Subnets」だ。この記事ではサーバーレスNATサービスと自己管理型EC2 NATサービスを比較する。とにかく始めよう...

仕事用: Apple MacBookPro M1、16GiGメモリ、256GB SSD。OS: 常に最新。現在はmacOS Big Sur Version 11.4


個人用: Dell XPS 13、4Kタッチスクリーン。8GiGメモリ、256GB NVMeディスク。OS情報: Manjaro Linux with KDE（最新）



その他の用途: Intel NUC Kit NUC8i7HVK。本当に素晴らしいハードウェア。製品ページで詳細を確認できる。32GiGメモリ、2 x 512 GB RAID 0 NVMeディスク。Windows 10 Enterpriseと本当に恋に落ちた。


2017年からSamsung UE28E590、4K 4msモニターを使用している。ピボットではなく、Dell P2719H 27" 5ms FHDをSSHセッション用のピボットとして使っていたが、そのモニターは前職の所有物で退職時に返却した。


会社からApple Magic Mouse 2とApple Wireless Keyboardが支給され、今はそれらを使っている。それで十分だ。



インターネットプロバイダーはturk.netで、コスト効率の高いプランを持つ本当に素晴らしいプロバイダーだ。自宅（WFH）でVDSL2インターネット技術を使用し、100mbpsダウンロードと8mbpsアップロード速度が出ている。このモンスターをIPSec VPN経由でAWSクラウドやGoogle Cloud Platformに接続するよう設定できる。必要に応じていくつかのサービスをテストして使用している。デバイスはJuniper SRX-110HA v2。古いけど良いものだ...
Xiaomi 4A Routerを5GHzモードで使用中。TVだけが直接ケーブルでローカルネットワークに接続。その他のモバイルデバイスはWi-Fi経由で接続。
Samsung UE50RU7400UXTK（2019）を使用。50"で自分には十分。主にYouTubeを見てSpotifyを聴いている。プラットフォームはTizenでOSも最新バージョン。AirPlay2機能は本当に命の恩人だ。数クリックでMBPに接続できる。
CLIOpsとSSHセッション用に再びピボットモニターを使う予定。Dell P2418D、2K解像度。
来週、この素晴らしいキットを注文し、Apple Magic Mouse 2とApple Keyboardセットから切り替える。




正式にAWS Community Builderになりました！
Sat, 15 May 2021 09:20:41 +0300
毎日AWSを使っている。自分を教育することに本当にオープンで、AWSはその方向で助けてくれている。クライアントチーム、バックエンドチーム、時にはデータチームなどの部門向けにルーティンタスクを自動化しており、ほとんどの場合、ニーズはその組織に固有のものだ。だから自分で、またはチームと共に構築し、進むにつれて製品やツールの知識を向上させるべきだ。
知識を共有すれば、人々の日々と時間を節約できる。ほとんどの場合、人々は同じことで行き詰まっている。問題を解決したなら、なぜ解決策を共有しないのか？結局のところ、あなたはもうそれを必要としていないのだから。これがオープンソースコミュニティとAWSコミュニティに対する私の主なモチベーションだ。
AWSコミュニティもオープンソースだ。例えば、AWS Command Line Interface DocumentationページはGitHubでホストされており、何か間違いがあれば貢献できる。これはオープンソースであることを意味する。
また、クラウド自動化のためにTerraformを書くのが本当に好きで、モジュール、プロバイダー、ツールの予期しない動作に問題を見つけたら、GitHubのIssueタブをチェックしている。例えばhttps://github.com/hashicorp/terraform-provider-aws/issuesだ。その感覚は素晴らしい。
今日ここに立っているなら、主な理由はオープンソースコミュニティだ。機会があるたびにLinuxサーバーでオープンソースプロジェクトを実行し、クラスタを作成し、HAシナリオ、回復力のあるシステム、イミュータブルインフラストラクチャなどを理解しようとしている。かつてはオンデマンドで、カーネル側で何か間違ったことをすると、ほとんどの場合サーバーは再起動後に起動しなかった！: ) その後、何時間も費やすが、最終的には知識を得る。クラウド時代では、オートスケーリングインフラストラクチャ（ec2、docker、サーバーレスなど）をロードバランサー付きで作成し、AWSで城のように簡単かつ超高速にセキュアにできる！そのようなインフラストラクチャは指から数クリックの距離にある...

ツールを使うなら、そのツールの使い方を知るべきだ。始める前に知識を得るべきだが、クラウド側では始める前に知る必要はない。AWSで自分だけのプレイグラウンドを作成し、学習を始めることができる。
今朝、AWS Community Builderプログラムについて@JasonDunnからメールを受け取った。このプログラムにいつ応募したか覚えていないが、メールをチェックしたところ、2021年3月頃にJasonとのやり取りを見つけた。応募は2021年3月31日の太平洋時間（GMT -7）深夜までだったので、3月のはずだ。本当に感謝している！
一緒に最先端を作り出そう！
参考資料

AWS Command Line Interface Documentation
GitHub
https://github.com/hashicorp/terraform-provider-aws/issues
@JasonDunn



Terraformを使ったジオロケーションルーティング付きHA nginxのAWS ECSへのデプロイ
Wed, 12 May 2021 12:56:20 +0300
今日は、Deploy nginx docker to AWS ECS with Terraform Automationプロジェクトをシングルリージョンからマルチリージョンサポートにリファクタリングしたい。今回は、すべてのTerraformソースコードをGitLabアカウントにプッシュした。

更新されたプロジェクトは、アイルランドとN.Virginiaリージョンにすべてのインフラストラクチャを作成する。
これで、Route53が提供するジオロケーションベースのルートポリシーが使えるようになった。
ジオロケーションベースのルートポリシーとは？
このプロジェクトでは、北米大陸からのリクエストはNorth Virginiaのインフラストラクチャで処理される。

欧州大陸からのリクエストは、アイルランドのインフラストラクチャで処理される。

デフォルトのリージョンも設定されており、アイルランドのインフラストラクチャで処理される。
ボーナス
このプロジェクトは私にとって本当に楽しいものだ。PoCにAWSで$1.17（税込）を費やした。リポジトリリンクはこちら: https://gitlab.com/flightlesstux/nginx-app-aws-ecs 
パイプラインもチェックするのを忘れずに: https://gitlab.com/flightlesstux/nginx-app-aws-ecs/-/pipelines/301488894 !
参考資料

https://gitlab.com/flightlesstux/nginx-app-aws-ecs
https://gitlab.com/flightlesstux/nginx-app-aws-ecs/-/pipelines/301488894



Terraform自動化を使ったnginx DockerのAWS ECSへのデプロイ
Tue, 11 May 2021 07:40:23 +0300
昨夜、AWS ECSサービスで遊びたくなった。すべてを同時にデプロイするためのTerraformコードを書いた。Terraformは、異なるVPCでECSを実行し、他のリソースから分離するためのすべてのリソースを作成する。

このプロジェクトではnginx:alpine Dockerイメージを使用したが、必要に応じてTerraformを修正・変更して自分のニーズに合わせて実装できる。
AWS ECSとは？
Amazon Elastic Container Service（Amazon ECS）は、フルマネージドのコンテナオーケストレーションサービスだ。顧客はECSのセキュリティ、信頼性、スケーラビリティの高さから、最も機密性が高くミッションクリティカルなアプリケーションを実行するためにECSを使用している。
ECSがコンテナの実行に最適な選択肢である理由はいくつかある。第一に、コンテナ向けサーバーレスコンピュートであるAWS Fargateを使用してECSクラスタを実行することを選択できる。Fargateはサーバーのプロビジョニングと管理の必要性を取り除き、アプリケーションごとにリソースを指定して支払い、設計によるアプリケーション分離を通じてセキュリティを向上させる。第二に、ECSはAmazon SageMaker、AWS Batch、Amazon Lex、Amazon.comのレコメンデーションエンジンなどのサービスを支えるためにAmazon内部で広範に使用されており、ECSがセキュリティ、信頼性、可用性について広範にテストされていることを保証する。
さらに、ECSは主要なAmazonサービスの基盤となっているため、Amazon Route 53、Secrets Manager、AWS Identity and Access Management（IAM）、Amazon CloudWatchなどの他のサービスとネイティブに統合でき、コンテナのデプロイとスケーリングに使い慣れた体験を提供する。ECSはまた、他のAWSサービスと迅速に統合して新しい機能をECSにもたらすことができる。例えば、ECSはアプリケーションがAmazon EC2とAWS Fargateをスポットとオンデマンドの価格オプションで組み合わせて使用する柔軟性を可能にする。ECSはまた、サービスメッシュであるAWS App Meshと統合し、アプリケーションに豊富な可観測性、トラフィック制御、セキュリティ機能をもたらす。ECSはローンチ以来急速に成長しており、現在EC2がインスタンスを起動するよりも1時間あたり5倍多くのコンテナを起動している。
リポジトリ
リポジトリはhttps://github.com/flightlesstux/aws-ecs-nginx-appで確認でき、必要に応じてコードを使用してデプロイを行ったり、ECSがどのように動作するかを理解したりできる。
参考資料

AWS Fargate
https://github.com/flightlesstux/aws-ecs-nginx-app



LinuxサーバーにNode Exporterをインストールする方法
Mon, 10 May 2021 09:18:09 +0300
Node Exporterは、設定可能なメトリクスコレクターを備えたサーバーレベルおよびOSレベルのメトリクス用のPrometheusエクスポーターだ。RAM、ディスク容量、CPU使用率などの様々なサーバーリソースの測定に役立つ。Node Exporterは、監視用のすべてのLinuxサーバー関連のメトリクスと統計を収集する優れたソリューションだ。
始める前に
Prometheusサーバー
Node Exporterのインストール後、メトリクスをPrometheusサーバーに送信する必要がある。
Sudo権限
SSHでrootとしてサーバーにアクセスするか、SSHログインユーザーがsudoでのroot権限を持っている必要がある。
Node Exporterのインストール手順
 ディレクトリを作成する インストール用に/opt/node-exporterパスを使用することを好む。これを使ってもよい。

 
ユーザーを追加する シンプルなコマンドでユーザーを追加できる。:
adduser -r -d /opt/node-exporter node-exporter -s /sbin/nologin

 
バイナリをダウンロードする https://github.com/prometheus/node_exporter/releasesページからバイナリをダウンロードし、ファイルを直接/opt/node-exporterパスに展開する。

 
所有者とグループの権限を変更する node_exporterバイナリを実行するためのユーザー権限を設定する必要がある。
chown -R node-exporter:node-exporter /opt/node-exporter

 
systemdサービスファイルを作成する このサービスのステータスをsystemdで管理する必要がある。systemdサービスファイルを作成する時だ。ファイルパスは/etc/systemd/system/node-exporter.serviceにする。そこに以下のすべての設定を貼り付けることができる。

[Unit]
Description=Prometheus exporter for machine metrics
Documentation=https://github.com/flightlesstux/node_exporter

[Service]
Restart=always
User=node-exporter
Group=node-exporter
ExecStart=/opt/node-exporter/node_exporter
ExecReload=/bin/kill -HUP $MAINPID
TimeoutStopSec=20s
SendSIGKILL=no

[Install]
WantedBy=multi-user.target

 
node-exporterを起動する systemctl start node-exporterコマンドでnode-exporterサービスを起動する準備ができた。
 
これで、http://IP_ADDRESS:9100/metrics URL経由でサーバーのメトリクスを確認できる。ページにアクセスできない場合は、TCP 9100を許可するようにファイアウォールやセキュリティグループの設定を確認する必要がある。
ボーナス
Node Exporterのインストールに必要な手順がわかった。このインストールを自動化したので、自由に使ってほしい。sh <(curl https://raw.githubusercontent.com/flightlesstux/node_exporter/master/installer.sh)コマンドを実行するだけで、数秒でnode-exporterがインストールされる。
GitHubリポジトリ: https://github.com/flightlesstux/node_exporter
参考資料

https://github.com/prometheus/node_exporter/releases
https://github.com/flightlesstux/node_exporter



M1 MacBookProでのFortiClient問題と解決策
Wed, 05 May 2021 06:36:38 +0300
仕事をしてリソースに安全にアクセスするためにFortiClient経由でVPNに接続する必要がある。2021年3月に会社で働き始めたとき、M1 MacBookProが支給された。M1 MacBookProは新しいCPUアーキテクチャを搭載しているため、他のものとは異なる。以前AppleはIntelベースのCPUを使用していたが、現在はARMベースのCPUでmacOSを実行することを決定し、今のところM1と呼ばれている。

多くのソフトウェアがARMと互換性がない。「このコンポーネントはお使いのCPUと互換性がありません」といった問題に時々遭遇する。

FortiClient v6.4.3.1325経由でVPNに接続すると、接続されているように見えるが、インターネット速度が極端に遅くなる。通常、100MB/秒のインターネット速度がある。同僚に「VPNやVPN速度に問題はないか？」と尋ねたところ、「いいえ！」と言われた。彼らは私より少し古いIntelベースのCPUを搭載したMacBookProを使用しており、Intelベースのバージョンは問題なく安定しているので、これは普通の状況だと思った。
根本原因を見つけるためにデバッグを開始し、VPNに接続する前にルーティングテーブルをチェックした。
➜ ~ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.31.1 UGScg en0
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#14 UCS en0 !
192.168.31 link#14 UCS en0 !
192.168.31.1/32 link#14 UCS en0 !
192.168.31.1 ec:41:18:ec:c6:bc UHLWIir en0 1189
192.168.31.147/32 link#14 UCS en0 !
192.168.31.147 a0:78:17:87:b4:88 UHLWI lo0
192.168.31.171 b8:bc:5b:6:28:18 UHLWI en0 1165
192.168.31.255 ff:ff:ff:ff:ff:ff UHLWbI en0 !
224.0.0/4 link#14 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0
255.255.255.255/32 link#14 UCS en0 !



Terraformを使ったIPsec Site-to-Site VPNでAWSとGCPを接続する
Tue, 04 May 2021 20:49:25 +0300
今日は、自分のニーズに合わせて別のIaaC（Infrastructure as Code）を書いた。Amazon Web Services（AWS）とGoogle Cloud Platform（GCP）の間に安全なVPN接続（IPsec）を作成できる。
これで何ができるか？
AWS上でのカスタマーゲートウェイの作成。AWS上での仮想プライベートゲートウェイの作成。AWS上でのSite-to-Site VPN接続の作成。AWS上でのVPN接続アクセス用セキュリティグループの作成。GCP上でのVPN接続用外部IPアドレスの作成。GCP上でのVPN接続用ファイアウォールルールの管理と作成。GCP上でのルートルールの作成。
要件
Compute Engine APIを有効にする（無効な場合）。
サービスアカウントを作成する（Editorロールまたは任意のロールを付与）し、キーファイルをエクスポートする。
Terraformの状態を保持するCloud Google Storageバケットを作成する。必要に応じて、サービスアカウントをバケットのメンバーとして追加するか、Terraformの状態を保持するS3バケットを作成する。
AWS側のIAM権限を確認する。
使用方法
 リポジトリをクローンする git clone git@github.com:flightlesstux/aws-to-gcp-vpn-w-terraform.git

 
Google SDKがインストールされていなくてもGoogle Platformに認証する。CI/CDパイプラインに本当に便利だ！既にgcloud auth loginなどでGoogle Cloud Platformプロジェクトにログインしている場合は、このステップをスキップできる。 export GOOGLE_APPLICATION_CREDENTIALS="service-account-key.json"

 
プロジェクトIDもTerraform経由で宣言されるが、値をエクスポートしないと以下のようなエラーが発生する可能性がある。 export GOOGLE_PROJECT="0123456789012"

│ Error: project: required field is not set
│
│ with google_compute_instance_group_manager.this,
│ on group_manager.tf line 1, in resource "google_compute_instance_group_manager" "this":
│ 1: resource "google_compute_instance_group_manager" "this" {


 
AWSリージョンにリソースを作成するためにAWS Access Key IDとSecret Access Keyをエクスポートする。 AWS_ACCESS_KEY_ID=AKIA1SFAESADASFASR5D
AWS_SECRET_ACCESS_KEY=Aasdfiajfar1O9DFASDAA3rasdas02304adsq9re

 
変数を設定する variables.tfの値を編集する

 
Stateバケットの設定 state.tfファイルでTerraform stateバケットを設定する。AWS S3またはGoogle Cloud Storageを使用できる。

 
初期化する terraform init

 
デプロイ！ terraform apply または terraform apply -auto-approve




TerraformでGoogle Cloud Platformを簡単に自動化する
Fri, 30 Apr 2021 08:51:51 +0300
昔々、Google Cloud Platformを学んでいたとき、ワークフローとデプロイメントをTerraformで自動化したくなり、インフラストラクチャを簡単かつ迅速に管理するためにこのIaaC（Infrastructure as Code）を書いた。
これで何ができるか？
SSL付きの安全なロードバランサーを作成し、HTTPリクエストを301リダイレクトコードでHTTPSに変換する。
インスタンステンプレートを作成し、ネットワーク、サブネット、スタートアップスクリプトに関するすべてを設定する。
インスタンスグループを作成し管理する。インスタンスグループのCPUがある値より多いか少ない場合、インスタンスグループマネージャーが自動的にVMをスケールアップまたはスケールダウンする。
VMインスタンスはプライベートIPで実行され、プロジェクト全体のSSHアクセスはデフォルトで許可されていない。ロードバランサーのヘルスチェック用のファイアウォールルールを管理する。
要件
Compute Engine APIを有効にする（無効な場合）。
Editorロール（または任意のロール）でサービスアカウントを作成し、キーファイルをエクスポートする。
Terraformの状態を保持するためにCloud Google Storageバケットを作成する。必要に応じて、サービスアカウントをバケットのメンバーとして追加できる。
Compute Engineイメージを作成する。Debian 10ベースのVMを作成し、sudo apt install -y nginxでnginxをインストールしてこのTerraformコードをテストできる。VMをイメージに変換する前にsudo systemctl enable nginxコマンドを忘れずに。
使用方法
手順は以下の通り...
 リポジトリをクローンする 
git clone git@github.com:flightlesstux/gcp-instance-group-and-loadbalancer-w-terraform.git

 
Google SDKがインストールされていなくてもGoogle Platformで認証する。CI/CDパイプラインに本当に便利だ！既にgcloud auth loginなどでGoogle Cloud Platformプロジェクトにログインしている場合は、このステップをスキップできる。 
export GOOGLE_APPLICATION_CREDENTIALS=service-account-key.json

 
プロジェクトIDもTerraform経由で宣言されるが、値をエクスポートしないと以下のようなエラーが発生する可能性がある。 
export GOOGLE_PROJECT="0123456789012"

│ Error: project: required field is not set
│


 
 
変数の値を編集する 
variables.tfファイル

 
SSL証明書の設定 
certsフォルダの下にSSL証明書とキーファイルを貼り付ける。ロードバランサーは安全である必要がある！


 
 
本番環境のバージョンをこの変数で簡単に追跡できる。また、インスタンスグループはローリングアップデートを行うために新しいバージョンが必要だ。 
export TF_VAR_deploy_version=v1

 
初期化する 
terraform init

 
デプロイしよう 
terraform apply または terraform apply -auto-approve


 
リポジトリアドレス
https://github.com/flightlesstux/gcp-instance-group-and-loadbalancer-w-terraform

この記事が役立つことを願っている。
参考資料

Enable Compute Engine API
Create Service account
Create Cloud Google Storage Bucket
Create Compute Engine Image
github.com/flightlesstux/gcp-instance-group-and-loadbalancer-w-terraform#usage
https://github.com/flightlesstux/gcp-instance-group-and-loadbalancer-w-terraform



Amazon Web Servicesアカウントをセキュアにする方法
Sat, 24 Apr 2021 14:27:03 +0300
セキュリティファースト、セキュリティは非常に重要だからだ！Amazon Web Servicesアカウントを作成すると、そのアカウントはルートと呼ばれる。ルートレベルのアカウントはクラウド環境で実行されているすべてのリソースへの完全なアクセス権を持っており、リソースの管理にルートアカウントを使用しないことを強く推奨する。
AWSアカウントを安全に保つために何をすべきか？
 ルートアカウントに多要素認証を設定する 以前に2ステップ認証や2要素認証について聞いたことがあるかもしれない。Amazonのエコシステムでは、この追加のセキュリティレイヤーをMFAと呼ぶ。このアカウントのルートユーザーには多要素認証（MFA）が有効になっていない。このアカウントのセキュリティを向上させるためにMFAを有効にする。
 
パスワードポリシーを設定する パスワードポリシーは、IAMユーザーのパスワードに対して複雑さの要件と必須のローテーション期間を定義する一連のルールだ。

設定できるもの:
- 最小パスワード長の強制
- ラテンアルファベット（A-Z）の大文字を少なくとも1文字要求
- ラテンアルファベット（a-z）の小文字を少なくとも1文字要求
- 数字を少なくとも1文字要求
- 英数字以外の文字を少なくとも1文字要求（! @ # $ % ^ & * ( ) _ + - = [ ] { } | '）
- パスワードの有効期限を有効にする
- パスワードの有効期限切れは管理者によるリセットが必要
- ユーザーが自分のパスワードを変更することを許可
- パスワードの再利用を防止
 
不要なリージョンを無効化する アカウント設定では、Amazon Web Servicesで特にすべてのリージョンが実行されている。例えば、ロンドンリージョン（eu-west-2）でサービスを実行する予定がある場合、実際には他のリージョンは不要であり、必ず他のリージョンを無効化すべきだ。グローバルエンドポイントとUS East（N. Virginia）リージョンは無効化できない。すべてのAmazon Web Services認証サービス（ログインやその他のサービス認証など）はグローバルエンドポイントで実行されており、一部のサービスはNorth Virginiaリージョン（us-east-1）でのみ実行されている。そのため無効化できないのだ。
 
ポリシーを作成する ポリシーは、ユーザー、グループ、ロールに割り当てることができるAWS権限を定義する。ビジュアルエディタやJSONを使用してポリシーを作成・編集できる。

ポリシー作成ページで特定のサービスとリソースに対する特定のアクションを設定できる。
 
IAMロールを作成する IAMロールは、信頼するエンティティに権限を付与する安全な方法だ。エンティティの例には以下が含まれる:
- 別のアカウントのIAMユーザー
- AWSリソースに対してアクションを実行する必要があるEC2インスタンス上で実行されているアプリケーションコード
- 機能を提供するためにアカウント内のリソースに作用する必要があるAWSサービス
- SAMLとのIDフェデレーションを使用する企業ディレクトリのユーザー
- IAMロールは短時間有効なキーを発行し、アクセスを付与するより安全な方法となる。
 
ユーザーグループで部門を分離する IAMユーザーは、AWSと対話するために使用する人やアプリケーションを表すためにAWSで作成するエンティティだ。ユーザーは最大10のグループに所属できる。このユーザーグループに最大10のポリシーをアタッチできる。このグループのすべてのユーザーは、選択されたポリシーで定義された権限を持つ。
 
ベストプラクティスを適用する 
最小権限アクセスを付与する: 最小権限の原則を確立することで、アイデンティティが特定のタスクを遂行するために必要な最小限の機能セットのみを実行できるようにし、使いやすさと効率性のバランスを取る。

AWS Organizationsを使用する: AWSリソースをスケールするにつれて環境を中央管理・統制する。新しいAWSアカウントを簡単に作成し、アカウントをグループ化してワークフローを整理し、ガバナンスのためにアカウントやグループにポリシーを適用する。

IDフェデレーションを有効にする: 好みのIDソースから複数のサービスにわたってユーザーとアクセスを管理する。AWS Single Sign-Onを使用して複数のAWSアカウントへのアクセスを中央管理し、割り当てられたすべてのアカウントへのシングルサインオンアクセスをユーザーに提供する。

MFAを有効にする: 追加のセキュリティのために、すべてのユーザーに多要素認証（MFA）を要求することを推奨する。

認証情報を定期的にローテーションする: 自分のパスワードとアクセスキーを定期的に変更し、アカウント内のすべてのユーザーも同様に行うことを確認する。

IAM Access Analyzerを有効にする: IAM Access Analyzerを有効にして、パブリック、クロスアカウント、クロス組織のアクセスを分析する。

すべてのセキュリティベストプラクティスについてさらに学ぶ。
 
この記事がAmazon Web Serviceアカウントを安全に使用するのに役立つことを願っている！


UGREEN USBイーサネットアダプターをmacOSにインストールする
Sun, 18 Apr 2021 14:39:34 +0300
2019年、Dell XPS13をイーサネットケーブルでJuniper SRX-110に接続する必要があったが、Dellにはイーサネットポートがなかった。AmazonからUGREEN USBイーサネットアダプターを購入することにした。

このイーサネットアダプターはドライバーフリーで、WindowsとLinuxでは完璧に動作する。今日、同じUSBアダプターを使ってApple MacBookPro Siliconをインターネットに接続する必要があったが、macOSはこれを好まない。macOSにはドライバーが必要で、一部の追加ハードウェアにはカーネルの制限があることを知っている。

kextファイルはmacOSに不可欠なドライバーだ。"Kext"はKernel Extensionの略で、kextファイルはコンピュータの起動時にロードされる追加コードを提供することで、Mac OS Xのカーネル（OSの中核部分）を「拡張」する。

kextなしでSystem Integrity設定を無効にする必要がある。Macをリカバリーモードで起動し、ターミナルに移動して以下のコマンドを実行した。
$ csrutil enable --without kext
csrutilコマンドの後、管理者アクセス権を持つユーザー名とパスワードを入力し、Apple Siliconを再起動した。

次はmacOS Big Surにチップセットドライバーをインストールする時だ。システムレポートでチップセット名を確認したところ、AX88179だった。

いくつか検索した後、チップセットのサポートページを見つけ、https://www.asix.com.tw/en/product/USBEthernet/Super-Speed_USB_Ethernet/AX88179からドライバーをダウンロードした。
これで、MacBookProもUGREEN USBイーサネットアダプター経由で直接インターネットに接続できるようになった！

UGREENブランドのUSBイーサネット製品をチェックできる。この記事があなたの助けにもなることを願っている...
参考資料

https://www.asix.com.tw/en/product/USBEthernet/Super-Speed_USB_Ethernet/AX88179
UGREEN branded USB Ethernet Products



Google Cloud PlatformのApp Engineでnginxを使った301 HTTPSリダイレクト
Thu, 15 Apr 2021 07:06:42 +0300
最近、Google Cloud PlatformのApp Engineで遊び始めた。DockerでPHPを実行するためにカスタムランタイムを持つフレキシブル環境を使用している。App EngineはHTTPとHTTPSの両方でコンテンツを配信する。Web UI経由でHTTPを無効にしたり、HTTPトラフィックをHTTPSに簡単にリダイレクトしたりできるか確認したが、残念ながら現時点では不可能だ。そう、正しく聞こえたと思う。基本的な機能がサポートされていないのだ！

ドキュメントをチェックし、app.yamlファイルで301リダイレクトを設定しようとした:
handlers:
- url: /.*
 script: auto
 secure: always
 redirect_http_response_code: 301

新しいバージョンをデプロイしたが、App EngineはまだHTTPで配信しており、安全でない接続をリクエストしてもHTTPSにリダイレクトされなかった。
今回はnginxにチャンスを与えることにした。nginx-app.confファイルを開き、以下のように記述した:

server_name _;
if ($http_x_forwarded_proto = “http”) {
return 301 https://$host$request_uri;
}

そして出来上がり！完璧に動作した。このプロセスをどのように試し理解したかは以下で確認できる。
➜ ~ curl -I http://ercan-ermis.ew.r.appspot.com/
HTTP/1.1 301 Moved Permanently
Date: Thu, 15 Apr 2021 07:03:34 GMT
Content-Type: text/html
Content-Length: 178
Server: nginx
Location: https://ercan-ermis.ew.r.appspot.com/
Via: 1.1 google
参考資料

https://cloud.google.com/appengine/docs/standard/php7/application-security



TerraformでAWS Load Balancerに2つの異なるTarget Groupを設定する
Mon, 05 Apr 2021 11:18:19 +0300
先週、TerraformでInfrastructure as Codeを書いた。AWS Application Load Balancerのパブリックインターフェースから2つの異なるターゲットグループにトラフィックを転送する必要があった。HashiCorp言語（HCL）は難しくないが、ドキュメントには多くのトピックが欠けており、Terraformには文書化されていないポイントもある。

検索してみたが、「TerraformでAWSで複数のターゲットグループを使用する」というテーマについて多くの質問や課題があるのを確認した。提案された解決策を読んだが役に立たなかった。その後、リソースとして"aws_lb_listener"を使うことにした。最終的に自分のケースに対する解決策を見つけた。詳細は以下の通り。

resource "aws_lb" "awsalb" {
 name = "my-aws-loadbalancer"
 internal = false
 load_balancer_type = "application"
 security_groups = [aws_security_group.lb.id]
 subnets = data.aws_subnet_ids.subnets.ids
 enable_deletion_protection = false
 tags = { Name = "My AWS ALB Load Balancer" }
}
resource “aws_lb_target_group” “origin” {
name = “Origin-Group”
port = 5080
protocol = “HTTP”
vpc_id = data.aws_vpc.default.id
stickiness { type = “lb_cookie” }
}
resource “aws_lb_target_group” “edge” {
name = “Edge-Group”
port = 5080
protocol = “HTTP”
vpc_id = data.aws_vpc.default.id
stickiness { type = “lb_cookie” }
}


Amazon Web ServicesでEC2 Linuxのディスクを再起動せずに拡張する
Mon, 08 Feb 2021 15:08:26 +0300
何らかの理由で、EC2 Linuxサーバーを再起動せずに安全に拡張する必要がある場合がある。この記事では、AWSでEC2 Linuxディスクを拡張する方法を学ぶ。

この例では、ディスクサイズを80GiBから120GiBに拡張する手順を紹介する。
Step 1: ボリュームを変更する

AWSコンソールにログインし、EC2のボリューム（ディスク）を見つける。左ペインのElastic Block Store > Volumesにある。ボリュームを右クリックし、「Modify Volume」オプションを選択する。下の画像のようになる。適切なサイズを選び、Modifyボタンをクリックする。


Step 2: ディスクサイズを確認する

まず、コマンドを実行する前にサーバーでrootまたはsudoになる必要がある。最初にディスクサイズを確認する。ボリューム変更前のサイズが表示されるはずだ。この例では80GiBのはずだ。
[root@server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.8G 0 7.8G 0% /dev
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 7.8G 416K 7.8G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/nvme0n1p1 80G 51G 30G 64% /
tmpfs 1.6G 0 1.6G 0% /run/user/0
はい、ディスク全体のサイズは80GiBと表示されている。正しい。次にブロックデバイスのリストを確認しよう。コマンド出力は/dev/nvme0n1デバイスに新しいディスクサイズを表示するはずだ。
[root@server ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 120G 0 disk
├─nvme0n1p1 259:1 0 80G 0 part /
└─nvme0n1p128 259:2 0 1M 0 part
はい！nvme0n1p1は80GiBだが、nvme0n1は120GiBと表示されている。つまり、nvme0n1p1パーティションを80GiBから120GiBに拡張できるということだ。


AWS RDS（MariaDB）で新しい権限ユーザーを作成する
Sat, 30 Jan 2021 23:01:56 +0300
今日は、MariaDBを使ったAWS RDSで遊んでみた。通常、AWSはAWS RDSにアクセスするためのユーザーを1つだけ作成する。ここでは、MariaDBを使用したAWS RDSで新しい権限ユーザーを作成する手順を紹介する。
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, BINLOG MONITOR, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'YOUR-MYSQL-USERNAME'@'CLIENT-IP-OR-DNS-NAME' IDENTIFIED BY 'CLEAR-TEST-PASSWORD' WITH GRANT OPTION;
Query OK, 0 rows affected (0.009 sec)

このコマンドは、すべての権限オプション付きでMariaDB用のRDSユーザーが正常に作成され、パスワードが設定されたことを意味する。素晴らしい。しかし、この権限を完全に保存する必要がある。そのために以下のコードを実行すること。
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.009 sec)

以上だ！
P.S. RDSインスタンスがパブリックでインターネット経由でアクセスする必要がある場合は、RDSインスタンスのセキュリティグループを忘れずに設定すること。


Amazon Web ServicesでのCloudFrontを使ったAmazon S3 CORS設定
Tue, 29 Sep 2020 08:27:16 +0300
Amazon S3からCloudFront（CDN）経由で静的コンテンツを配信している場合、フォントや画像、その他の静的コンテンツをユーザーに配信する際におそらくエラーが発生するだろう。実際のところ、複雑な話ではない。この問題はAmazon S3バケットのCORS設定で修正できる。
Amazon S3 CORSとは？
Cross Origin Resource Sharing（別名CORS）。CORS仕様は、プライマリコンテンツを提供したドメイン以外のドメインにリクエストを行うウェブアプリケーションを構築する能力を提供する。
Step 1: AWS Webコンソールでバケットの権限設定を開く
https://s3.console.aws.amazon.com にアクセスし、認証情報でS3コンソールにサインインして、CloudFrontに接続されているバケットを選択する。
Step 2: CORS設定を適用する
「アクセス許可」タブに「CORS設定」セクションがある。このセクションを選択し、以下のコードを適用する:
<CORSConfiguration>
 <CORSRule>
 <AllowedOrigin>https://YOURWEBSITEADDRESS.com</AllowedOrigin>
 <AllowedMethod>PUT</AllowedMethod>
 <AllowedMethod>POST</AllowedMethod>
 <AllowedHeader>*</AllowedHeader>
 </CORSRule>
 <CORSRule>
 <AllowedOrigin>*</AllowedOrigin>
 <AllowedMethod>GET</AllowedMethod>
 </CORSRule>
</CORSConfiguration>
貼り付けた後、<AllowedOrigin></AllowedOrigin>を自分のウェブサイトアドレスに変更し、「保存」ボタンをクリックする。
結論
おめでとう！CORS設定が正常に完了し、Amazon S3バケットにあるコンテンツをユーザーが閲覧できるようになった。
参考資料

https://s3.console.aws.amazon.com



Dockerで動くGitLabのバックアップを毎日取得する
Wed, 16 Sep 2020 15:27:44 +0300
GitLabをDockerで使っている（コンテナ化が大好きだからだ）。必要に応じてGitLab環境をどこにでも移動でき、Dockerを使うとより弾力的に感じられる。

GitLabのバックアップは本当に重要だ。すべてのソースコード、おそらくWikiも保持しており、重要なレベルでサービスを運用しているならバックアップが第一だ。

Docker runコマンドを確認する
バックアップ取得のコマンドは: docker exec gitlab gitlab-rake gitlab:backup:create DIRECTORY=gitlab
トリガーコマンドだけでは不十分で、/srv/gitlab/config/パスにあるgitlab.rbとgitlab-secrets.jsonファイルのバックアップも取得する必要がある。
最終: バックアップを自動化しよう
/opt/gitlab-backup.shにある完全なBashスクリプトが、バックアップを作成し、設定ファイルをコピーし、AWS S3に同期してサーバー上のバックアップファイルを削除する。.shファイルを作成した後、crontabを使って/opt/gitlab-backup.shの実行をトリガーできる。


CentOS、Ubuntu、macOSで大きなファイルを簡単に見つける
Sat, 18 Jul 2020 13:08:30 +0300
時には、誰もがシステム内の大きなファイルをチェックする必要がある。私がよく使う便利なコマンドをいくつか紹介する。Linuxで大きなファイルを簡単に見つけよう。

最初のパターンはこちら:
find /home/ercan/ -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
システム内でファイルサイズが250MBを超える場合:
sudo find /home/ercan/ -type f -size +250000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
結果はこちら:
/home/ercan/.local/share/Steam/steamapps/common/Counter-Strike: 631M
/home/ercan/.local/share/Steam/steamapps/common/Counter-Strike: 248M
/home/ercan/.local/share/Steam/steamapps/common/Counter-Strike: 251M
/home/ercan/.local/share/Steam/steamapps/common/Counter-Strike: 464M
/home/ercan/.local/share/Steam/steamapps/common/Counter-Strike: 306M
/home/ercan/Downloads/CentOS-7-x86_64-Minimal-2003.iso: 1.1G
/home/ercan/VirtualBox: 13G


CentOSまたはAmazon Linux 2で「Error: rpmdb open failed」を修正する
Mon, 20 Apr 2020 11:49:37 +0300
昨日、Amazon Web Servicesクラウドで動作するAmazon Linux 2上でいくつかのサービスをテストし始めた。何らかの理由でパッケージマネージャのyumが壊れており、yumデータベースを更新しようとしたところ、rpmdb open failedに関するエラーが発生した。以下がそのエラーだ。CentOS 7またはyumをパッケージマネージャとして使用する別のLinuxディストリビューションを実行している場合も、読み続けることができる。
error: rpmdb: BDB0113 Thread/process 18275/140171317404864 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 - (-30973)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:
Error: rpmdb open failed
すべてのrpmデータベースパッケージを/tmpディレクトリに移動することにした。
sudo mv /var/lib/rpm/__db* /tmp
この移動の後、yumは完全にクリーンになるはずだ。"yum clean all"を実行してyumデータベースをクリーンにする。
sudo yum clean all
クリーニングプロセスの後、yumはクリーニングが完了したと表示した。
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Repository elastic-7.x is listed more than once in the configuration
Bad id for repo: root@ip-11-12-30-149 yum.repos.d, byte = @ 4
Cleaning repos: amzn2-core amzn2extra-epel elastic-7.x epel treasuredata
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned data from disabled or removed repos
指を交差させて、最新バージョンのパッケージでyumデータベースを更新しようと試みた。そのために"sudo yum update"コマンドを実行する。


エラー: サービスの起動/停止時のみ「No space left on the device」が発生する問題
Sun, 01 Mar 2020 07:46:00 +0300
Amazon SSM Agentを使ってEC2インスタンスに安全に接続している。Amazon SSM Agentはaws.amazon.comのウェブコンソールからEC2インスタンスコンソールに接続することもできる。これが私の好みの方法だ。

数日前、Amazon SSM Agent経由でEC2に接続しようとしたところ応答がなく、その後通常の方法、つまりSSHで接続することにした。

もちろん、まず最初にAmazon SSM Agentを再起動しようとしたところ、以下の表示が出た:
[root@i-0cd9514c60d532e78 ~] systemctl restart amazon-ssm-agent.service
Error: No space left on device
ディスク状態に関するこのエラーメッセージは予想外だった。ディスク使用量を確認してみることにした:
[root@i-0cd9514c60d532e78 ~] df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 960M 0 960M 0% /dev
tmpfs 978M 0 978M 0% /dev/shm
tmpfs 978M 420K 978M 1% /run
tmpfs 978M 0 978M 0% /sys/fs/cgroup
/dev/nvme0n1p1 8.0G 2.6G 5.5G 32% /
tmpfs 196M 0 196M 0% /run/user/1000
おっと！このエラーメッセージはディスク使用量に関するものではないようだが、確認する必要がある。今度はinodeをチェックする:
[root@i-0cd9514c60d532e78 ~] df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 245750 304 245446 1% /dev
tmpfs 250254 2 250252 1% /dev/shm
tmpfs 250254 388 249866 1% /run
tmpfs 250254 16 250238 1% /sys/fs/cgroup
/dev/nvme0n1p1 4193216 67672 4125544 2% /
tmpfs 250254 1 250253 1% /run/user/1000
inodeでもないことが確認できたのでさらに調査したところ、この同じ問題について既知のバグレポートが存在することがわかった。systemctlの"start"、"stop"、"reload"アクションで「No space left on device」エラーが表示されるが、"enable"、"disable"、"kill"アクションでは発生しないというものだ。バグレポートによると、このエラーはinotifyの"max_user_watches"制限の結果として発生する。inotifyには変更を監視できるファイルとディレクトリの数に制限がある。エラーを解消するには、"/proc/sys/fs/inotify/max_user_watches"の値を増やして、より多くのファイルとディレクトリを追加して変更監視できるようにする必要がある。


Juniper SRX110H-VA VDSL2設定ステップバイステップ
Sun, 09 Feb 2020 06:48:00 +0300
昨夜、Kenan Bilgicと電話で話していて、「Juniper SRX-110H-VAが欲しい」と伝えた。するとKenanは「すでにJuniper SRX-110H-VAを持っているから、住所を送ってくれれば発送できるよ」と言ってくれた。
インターネットプロバイダーとしてTurkNetを使っている。近所では本当に安くて速いインターネットプロバイダーだ。接続タイプはVDSL2で、Amazon Web Services（AWS）経由でVPN接続を行う必要がある。
ルーターが届いた！
新しいルーターデバイスに本当に興奮している。RJ13経由で銅線電話ケーブルに接続する前に設定する必要がある。ルーターを基本設定し、設定をGitHubリポジトリにプッシュした。
JUNOS 12.1X46-D86ソフトウェアバージョンを使用した。このバージョンはJuniper SRX110H-VAでサポートされている最新バージョンだ。
始める前に
 vLAN ID（重要） 各ISPは接続に独自のvLAN IDを使用している。トルコでは、ISPはvlan-id35を使用している。
 
ユーザー名 ISPが提供する接続用のユーザー名を知っておく必要がある。
 
パスワード ユーザー名と同様だが、今度はパスワードだ。これもISPが提供する。
 
ターミナルケーブル SRX110H-VAのSSHサービスが無効になっている場合、設定をロードするためにターミナルケーブルが必要だ。持っていなければインターネットで購入できる。
 
GitHubリポジトリで詳細を確認できる。リンクはこちら: https://github.com/flightlesstux/juniper-srx-config/tree/master/srx110h-va
手順を終えると、Juniperがインターネットに接続された！やった！
root@juniper-srx110> show interfaces pp0.0 extensive | no-more
 Logical interface pp0.0 (Index 81) (SNMP ifIndex 534) (Generation 146)
 Flags: Point-To-Point SNMP-Traps 0x0 Encapsulation: PPPoE
 PPPoE:
 State: SessionUp, Session ID: 1,
 Session AC name: TT-35-IZMIR-ERC-SSR-01, Remote MAC address: ac:60:b6:5f:b7:bc,
 Configured AC name: None, Service name: TurkNet VDSL2,
 Auto-reconnect timeout: 5 seconds, Idle timeout: Never,
 Underlying interface: pt-1/0/0.0 (Index 80)
 ...

以前、私とKenanは同じ会社で働いていて、お互いを本当に好きだった。Kenanの親切に本当に感謝している！


Dockerコンテナのログローテーションを有効にする
Fri, 29 Nov 2019 17:17:00 +0300
システムにDockerをインストールして使用する際、Docker内で実行中のコンテナは、バックグラウンドで気付かないうちに大量のログを生成する可能性がある。
Dockerサービスは通常logrotateをサポートしているが、このサポートはデフォルトではオフになっている。ある日突然ディスクが一杯になったら、私が言っていることがよくわかるだろう。: )
サーバーにDockerサービスを初めてインストールし、コンテナを初めて実行する場合は、以下の手順に従うことができる。
Dockerサービスが停止状態のとき、まずDockerサービスがlogrotate操作に必要とするファイルをテキストエディタで開く。私のお気に入りはvimで、vimを使った。nano、picoなどの他のエディタを選んでもよい。
sudo vim /etc/docker/daemon.json
次に、このファイルに以下の行を追加して保存し、ファイルを閉じる。
{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3"
 }
 }
Dockerサービスを再起動するのを忘れずに。
sudo systemctl restart docker
これで、Dockerサービスは"/var/lib/docker/containers/CONTAINERID/"パスの下でログのローテーションを開始した。


ターミナルでwgetを使って特定の拡張子のファイルを簡単にダウンロードする
Fri, 22 Nov 2019 16:37:00 +0300
ディレクトリやフォルダに複数の拡張子のファイルが存在することがある。例えば、.jpg、.png、.gif、.mp3、.mp4などだ。そのソースからgifファイルだけを特���的にダウンロードしたいが、方法がわからない？心配しないで、正しい場所に来ている。

wgetはGNUライセンス（つまり無料）の小さなソフトウェアで、LinuxおよびmacOSオペレーティングシステムにデフォルトで搭載されている。

先日、FTPディレクトリにある同じ.mp4と.webmの動画をダウンロードしたかったが、.mp4ファイルか.webmファイルのどちらかをダウンロードする必要があった。100個の.mp4ファイルのサイズが10GBであるのに対し、同じ内容の100個の.webmファイルはわずか6GBだった。ディスク容量を大幅に節約したかったので、.webmファイルをダウンロードすることにした。

そのために以下のコマンドを実行し、画面を見守り始めた。
wget -r -A .webm http://videos.example.com/u/source/
見ての通り、これだけだ！このアドレスから.mp4ファイルをダウンロードしたい場合は、今度はこのコマンドを実行すればよい:
wget -r -A .mp4 http://videos.example.com/u/source/
このコマンドはhttpの代わりにhttpsやftpもサポートしている。つまり、接続プロトコルとしてhttp://、https://、ftp://を使用できる。
結論
この記事では、wgetを使って特定の拡張子のファイルを再帰的にダウンロードする方法を学んだ。うまくいったことを願っている。このコマンドはCentOS、Ubuntu、Amazon Linux、macOS、その他多くのLinuxディストリビューションで使用できる。


Linuxで特定のファイルの正確なサイズをターミナルで調べる
Fri, 15 Nov 2019 19:00:00 +0300
ある日、使用しているmacOS、Linux、サーバーに複数の拡張子のファイルが多数存在することがあり、これらのファイルのサイズが気になったり、特定の調査のために該当する拡張子のファイルサイズを確認したい場合がある。
先日、作業していたサーバーには*.webmと*.mp4の両方のファイル拡張子があり、サーバーのディスクをアップグレードするか、同じ動画の.mp4拡張子のものを削除する必要があった。
これを行うには複数の方法がある。ここでは3つの異なる最も頻繁に使用されるコマンドのみを説明する。
例えば、現在いるディレクトリに隠しフォルダがない場合、そのディレクトリ内の.jpgファイルのサイズを最もシンプルな方法で以下のコマンドで知ることができる。

まず、ディレクトリに存在するjpgファイルを一覧表示して確認したいので、以下のコマンドを実行して出力を表示する。MacのDocumentsフォルダに何があるか確認してみよう。
➜ Documents ls -la | grep jpg
-rw-r--r--@ 1 ercanermis staff 1607683 Feb 26 10:14 wallpaper-for-vertical-monitor.jpg
-rw-r--r--@ 1 ercanermis staff 242165 Aug 19 2019 10155854826986546_245396163509039923.jpg
-rw-r--r--@ 1 ercanermis staff 272199 Feb 26 10:00 C2014_Q2.jpg
では、これらのjpgファイルのサイズは？その質問への答えには以下のコマンドで十分だ。
➜ Documents du -ch *.jpg
1.5M	wallpaper-for-vertical-monitor.jpg
240K	10155854826986546_245396163509039923.jpg
268K	C2014_Q2.jpg
2.0M	total
これらのファイルの合計サイズが重要な場合は、以下のようにする:
➜ Documents du -ch *.jpg | grep total
2.0M	total
Documentsフォルダに本当に3つのjpgファイルしかないのか？
そうは思えないので、中身を確認することにした。隠しファイルやフォルダがあるかもしれないからだ。すべてのjpgファイルのサイズをより深く調べてみよう。
➜ Documents find . -type f -name '*.jpg' -exec du -ch {} + | grep total
4.6M	total
ふむ。今度は合計4.6Mと表示されている。先ほどは"du -ch *.jpg | grep total"コマンドの出力が2.0Mだった。どうして可能なのか？隠しファイルや隠しフォルダがあるからだ。確認してみよう。


CentOS 7またはCentOS 8でSELinuxを無効にする
Fri, 08 Nov 2019 19:00:00 +0300
このチュートリアルでは、CentOSサーバーでSELinux（Security-Enhanced Linux）を無効にする方法を紹介する。CentOSのバージョンは7または8である必要がある。バージョンは問わない。
SELinuxとは？
SELinuxはカーネルが直接制御するセキュリティメカニズムだ。管理者とユーザーがSELinuxポリシーに基づいてアクセス制御をより詳細に制御できるようにする。
SELinuxには3つの異なる動作モードがある。以下がそれだ:
Enforcing: SELinuxポリシーとポリシールールに基づいてアクセスを許可する。
Permissive: SELinuxはEnforcingモードで実行されていた場合に拒否されたであろうアクションをログに記録するのみ。
Disabled: メッセージはログに記録されず、サーバー上でSELinuxポリシーは有効になっていない。ほとんどの場合、cPanelやPleskなどのウェブコントロールパネルを使用する際にDisabledモードが使われる。
前提条件
rootユーザーまたはsudo権限を持つユーザーのみがSELinuxモードを更新できる。
SELinuxモードの確認
"sestatus"コマンドでSELinuxの状態を確認できる。出力にはSELinuxが有効で、モードがEnforcingに設定されていることが表示される。
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 31

SELinuxを無効にする
モードをPermissiveに変更することを強く推奨する。アプリケーションによってはSELinuxを好まず、Disabledモードを要求する場合がある。
SELinuxモードをEnforcingからDisabledに恒久的に変更するには、まずviやnanoなどのテキストエディタを使用する。
/etc/selinux/configファイルを開き、以下のように6行目のSELINUX値をdisabledに変更する:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected. 
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
これでファイルを保存してテキストエディタを終了できる。サーバーを再起動する時だ:


Hello Blog!
Sun, 03 Nov 2019 22:24:00 +0300
ノートを取ったり、nginx、phpMyAdmin、MySQL、PHP-FPMなどのLinuxサーバーやLinuxソフトウェアに関する技術情報を共有するために、何度自分用のブログを立ち上げたかわからないが、定期的にブログ記事を書くことに成功したことは一度もない。
私のブログアドレスには私の名前と姓が含まれている。だから、私の名前はもうお分かりだと思う : )
私はMasomoでLinuxシステムアドミニストレーターとして働いているが、素晴らしいチームと共に主にDevOpsの仕事をしている。
毎日オフィスで問題を解決し、世界中で完璧で問題のないモバイルゲームを作るために様々な技術を使っている。それがHead Ball 2モバイルゲームだ。
MasomoのHead Ball 2


頭の中では、将来の記事のカテゴリは以下の通りだ。
aws（Amazon Web Services）
DevOpsツールとDevOps文化
Docker
Kubernetes
Linuxサーバー（CentOS、Debian、Ubuntu）
最後に、このブログでは自分の経験とノウハウについて書きたい。今回は成功して、このブログを最新の状態に保てることを願っている。
最後に、このブログの次回の内容に興味があれば、右側のニュースレターエリアでメール購読を自由に作成してほしい。訪問ありがとう。
参考資料

Masomo
apps.apple.com/ro/app/head-ball-2/id1193933380
play.google.com/store/apps/details?id=com.masomo.headball2