Platform Engineering

Terraform→OpenTofu移行実践ガイド: 既存IaCを止めずに移行するエンタープライズ手順 Terraformのライセンス変更以降、OpenTofuへ移行したいという相談は確実に増えています。とはいえ現場の本音は「理屈は分かるが、stateが壊れたら終わる」「本番を止めずに移行できるのか不安」です。 結論から言うと、移行は十分可能です。ただし「CLIを置き換えるだけ」で済むケースは限定的で、実際は providerバージョン整合・state lock・CI/CD・運用Runbook までまとめて整える必要があります。 本記事では、既にTerraformを本番運用しているチーム向けに、OpenTofuへ段階移行する実践手順をまとめます。 1. 移行方針を先に決める 最初に決めるべきは「一気に切り替えるか」「ワークスペース単位で段階移行するか」です。実務では次の方針が安全です。 低リスク環境（dev/sandbox）から先行 本番は最終フェーズで移行 旧TerraformとOpenTofuを一定期間並行運用 ロールバック手順を文書化してから実施 この順序を守るだけで、移行事故の大半を避けられます。 2. 互換性の棚卸し（最重要） まずは現状のIaC資産を棚卸しします。 Terraformバージョン（例: 1.5.x / 1.6.x） 使用provider（AWS/Azure/GCP/Kubernetes等） backend（S3 + DynamoDB lock、Terraform Cloud、GCSなど） moduleの参照方式（registry / git / local） CI実行環境（GitHub Actions, GitLab CI, Jenkins） 2.1 依存を固定化してから移行する .terraform.lock.hcl を必ずコミットし、providerを固定します。移行時にproviderまで同時更新すると、差分原因の切り分けが困難になります。 1 2 3 4 5 6 7 8 9 terraform { required_version = ">= 1.6.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 5.40" } } } 移行フェーズでは「ツール差分」と「provider差分」を分離してください。 ...

Kyvernoで始めるKubernetes Admission Policy実践: 事故を減らすポリシー設計プレイブック Kubernetes運用で一番つらい事故は、クラスタが壊れるよりも「本来防げたはずのミスがそのまま本番へ入る」ことです。たとえば、latest タグのイメージが本番に入り再現不能になる、resources 未設定でノードが詰まる、privileged コンテナが混入する。これらは人の注意力だけに依存すると必ず再発します。 そこで有効なのが Admission Policy（入場制御）です。本記事では Kyverno を使って、現場で本当に運用できるポリシー群を段階導入する手順をまとめます。単なる「denyの例」ではなく、監査→警告→強制の移行、例外管理、CI連携まで含めて解説します。 1. なぜKyvernoなのか OPA Gatekeeper も強力ですが、Kyvernoは以下の特徴があり、初期導入が比較的スムーズです。 YAML中心で書ける（Rego学習コストを後回しにしやすい） validate / mutate / generate / verifyImages を一貫して扱える PolicyReportにより違反可視化がしやすい Pod SecurityやSupply Chain対策との相性が良い 「まずルールを回し始める」目的なら、Kyvernoは現実的な選択肢です。 2. 先に決めるべき設計原則 導入前に、以下だけは先に決めておきます。 導入フェーズ: Audit → Enforce を基本にする 責任分界: プラットフォームチームが共通ポリシー、各チームがアプリ固有例外 例外の期限: 永久例外は禁止。期限付きで必ず棚卸し 観測性: 違反数・対象Namespace・上位違反ルールをダッシュボード化 この原則なしにルールだけ増やすと、運用が破綻します。 3. 最小導入手順（30〜60分） 3.1 Kyvernoのインストール 1 2 3 4 5 6 7 8 9 helm repo add kyverno https://kyverno.github.io/kyverno/ helm repo update helm upgrade --install kyverno kyverno/kyverno \ -n kyverno --create-namespace \ --set admissionController.replicas=2 \ --set backgroundController.replicas=2 \ --set cleanupController.replicas=1 \ --set reportsController.replicas=1 本番では可用性のため、admission/backgroundは最低2レプリカ推奨です。 ...

Kubernetesキャパシティ設計実践：HPA/VPA/Cluster Autoscalerを衝突させない運用術 Kubernetes は「自動でスケールするから安心」と思われがちですが、実運用では逆です。HPA、VPA、Cluster Autoscaler（CA）の設定が噛み合わないと、スケールアウトと再スケジューリングが衝突し、レイテンシ悪化やコスト増大を引き起こします。 本記事では、3つのオートスケーリング機構を同時運用する際の設計ポイントを、障害対応目線で整理します。 1. 役割分担を明確にする まず前提として、各コンポーネントの責務を固定します。 HPA: Pod 数を短期的に増減 VPA: Pod あたりの requests/limits を中長期で最適化 CA: ノード数を増減 この役割分担が曖昧だと、同じ問題を複数レイヤーで同時に解こうとして不安定化します。特に Web/API ワークロードでは、HPA を主軸、VPA は recommendation 中心で始めるのが安全です。 2. requests/limits が崩れていると全て失敗する HPA の CPU 指標は requests 基準で計算されます。requests が不正確だと、HPA の判断もズレます。最初にやるべきは次です。 過去 2 週間の実使用量を可視化 p95 使用量を requests の初期値に設定 limits は requests の 1.5〜2 倍で開始 極端に低い requests は「見かけの高負荷」を作り、不要スケールを誘発します。逆に高すぎる requests は CA の過剰増設を招きます。 3. HPA 指標選定の実践 CPU だけで運用すると、I/O 待ちや外部 API 待ちのボトルネックを見逃します。推奨は複合指標です。 CPU Utilization（基本） メモリ使用率（リーク監視） RPS あたりレイテンシ（SLO 接続） Queue 長（非同期処理） autoscaling/v2 では複数メトリクスを扱えるため、最初から設計しておくと後で楽です。 ...

GitHub Actions再利用ワークフロー運用設計：属人化を防ぎつつ開発速度を上げる実践ガイド 複数リポジトリを運用していると、ほぼ同じ CI 設定を各リポジトリにコピーし続ける状態になりがちです。最初は早く見えますが、半年後には「どこに正解があるのかわからない」状態になります。セキュリティパッチを当てたいだけなのに 20 リポジトリを横断修正し、1つだけ取りこぼして監査で指摘される、というのは珍しくありません。 この問題に効くのが GitHub Actions の workflow_call を使った再利用ワークフローです。ただし、単に共通化するだけでは逆に運用事故が増えることがあります。重要なのは、共通化の粒度、権限境界、変更リリース方法を最初に設計することです。 本記事では、実運用で詰まりやすいポイントを中心に、導入から定着までを具体的に解説します。 1. 再利用ワークフローの基本方針 まず押さえるべき方針は次の 3 つです。 再利用ワークフローは「プラットフォーム製品」として扱う 呼び出し側（各アプリ repo）は薄く保つ 破壊的変更はバージョンを切って段階移行する 「共通化＝1ファイルに全部詰め込む」ではありません。lint, test, build, deploy を1個にまとめると、対象外プロジェクトまで影響します。まずは小さく分割し、必要なものだけ組み合わせられる構造にします。 2. 推奨ディレクトリ構成 共通ワークフローを専用 repo に分離しておくと、監査や変更履歴の管理が容易になります。 1 2 3 4 5 6 7 8 9 org-ci-workflows/ .github/workflows/ ci-node.yml ci-python.yml security-scan.yml release-tag.yml docs/ onboarding.md migration-checklist.md 呼び出し側は以下のように最小化します。 ...