0.この記事の結論 pcasteran/terraform-graph-beautifier: Terraform graph beautifier が個人的にはおすすめ！やはり、Terraform にビルトインされた terraform graph を input 値としているせいか、安定している印象を受けた。 im2nguyen/rover: Interactive Terraform visualization. State and configuration explorer. もとくにビジュアル面でよかった。ただし、Docker で扱う場合、Docker ホスト側の Terraform のバージョンによってはうまく動かないことがあったので、2番目におすすめとしたい。 1.この記事を書こうと思った背景 terraform graph という Terraform のリソース可視化ツールがある。これは Terraform にビルトインされたコマンドのひとつであり、Terraform で表現するインフラリソースの可視化ツールのひとつである。 詳細な使い方は以下の Terraform のドキュメントを参照してほしい。 Command: graph | Terraform by HashiCorp そんな terraform graph だが、リソースが多いと見にくいという欠点がある。そこで、表題のとおり、terraform graph よりビジュアライズな Terraform のインフラリソース可視化ツールを探すことにした。 1-1.可視化する Terarform のサンプルコード 今回、可視化する Terarform のサンプルコードは、以下の「7.サンプルコード」で書いているものとする。 7.サンプルコード | 複数の AWS Lambda のエラーを CloudWatch Alarms で検知できるように Terraform で定義する | gkzz.dev ...

1.この記事を書こうと思った背景 複数の AWS Lambda に CloudWatch Alarms で監視しよう！ということがあったので、 Terraform で以下のように dimensions で監視したい Lambda を列挙するだけだろ！と思いきや、ダメだった。 apply すると、最後に書いた FunctionName のみがCloudWatch Alarms に適用されてしまった。(以下の場合、my_lambda_function2 ) resource "aws_cloudwatch_metric_alarm" "this" { metric_name = "Errors" namespace = "AWS/Lambda" dimensions = { "FunctionName" = "my_lambda_function1", "FunctionName" = "my_lambda_function2" } #略 } ※ FunctionName に * をつけても「*_lambda_function」などとベタ書きとして認識されてしまってダメ。正規表現っぽく指定することは出来なかった。 dimensions = { "FunctionName" = "*_lambda_function", } さて、じゃあどうしようか？と調べたことを書き留めておく。 なお、上記の dimensions は以下を参考に指定した。 Choose a dimension. By Function Name (FunctionName) – View aggregate metrics for all versions and aliases of a function. ...

1.この記事の立ち位置 自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ 2-1.Step と Job と Workflow の違いの一行まとめ Step < Job < Workflow 2-2.Step と Job と Workflow の違いの三行まとめ Step はGitHub Actions Workflow の最小単位であり、run や uses で指定するもの Job はコンテナや VM のことを指し、runs-on で指定するものであり、ひとつないしは複数の Step を抱えている Workflow はひとつ以上の Job を束ねている これらについて端的にまとめた図が公式ドキュメントで掲載されているのでそちらもぜひ。 Understanding GitHub Actions - GitHub Docs 2-3.Step と Job と Workflow それぞれの分け方・分割の基準 Step を分けるときは、run 、 uses 、 name が異なるとき 以下のように書けば、ひとつの Step に複数のコマンドを始めとする処理を書くことができる - name: Install Dependencies run: | npm ci npm run build - name: Run test run: npm run test Job を分けるときは runs-on が異なるときや、needs で Job 単位で実行制御をしたいとき cf.4-1.Job をまたいで Step の実行を制御したり出力結果を参照したい Workflow を分けるときは、トリガーが違うとき e.g. push , pull_request , workflow_dispatch cf. Events that trigger workflows - GitHub Docs 3.Step の実行制御や Step の参照方法 以下のような成功するときもあれば失敗するときもある、不安定な Step があるとしよう。そして、このような不安定な Step の結果に応じて後続の Step を実行するかしないか決めたいとする。 ...

1.この記事を書こうと思った背景 Helmwave なるものを Twitter で見かけた。 Helmwave の README.md にはこのように書かれている。 Helmwave is helm3-native tool for deploy your Helm Charts. HelmWave is like docker-compose for helm. Helmwave は、Helm チャートを展開するための helm3 ネイティブツールです。 HelmWave は docker-compose のようなものです helm 用に作成します。 出所：helmwave/helmwave: 🌊 Helmwave is true release manager (邦訳は Google 翻訳より) よさそうなので、公式ドキュメントの Getting Started などを参考に Helmwave に入門する。 2.前提 2-1.ところで、Helm とは？ ぼくは、Helm 及び Helm Charts の理解も浅いのでこの場で深めておく。まず、Helm については公式ドキュメント にこのように書かれている。 The package manager for Kubernetes. Helm is the best way to find, share, and use software built for Kubernetes. ...

1.この記事を書こうと思った背景 Amazon EKS 上で作成した Namespace を kubetcl delete namespace <namespace> と削除しようとしても削除できないことがあった。(ここで削除したい Namespace は argocd) $ kubectl get ns argocd NAME STATUS AGE argocd Terminating 50m $ kubectl get namespace argocd -o json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "creationTimestamp": "2022-05-06T15:36:43Z", "deletionTimestamp": "2022-05-06T16:15:02Z", "labels": { "kubernetes.io/metadata.name": "argocd" }, "name": "argocd", "resourceVersion": "16545", "uid": "7e29177f-2c2c-4583-b027-49946160bf2b" }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "conditions": [ { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All resources successfully discovered", "reason": "ResourcesDiscovered", "status": "False", "type": "NamespaceDeletionDiscoveryFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All legacy kube types successfully parsed", "reason": "ParsedGroupVersions", "status": "False", "type": "NamespaceDeletionGroupVersionParsingFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All content successfully deleted, may be waiting on finalization", "reason": "ContentDeleted", "status": "False", "type": "NamespaceDeletionContentFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "Some resources are remaining: applications.argoproj.io has 1 resource instances", "reason": "SomeResourcesRemain", "status": "True", "type": "NamespaceContentRemaining" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "Some content in the namespace has finalizers remaining: resources-finalizer.argocd.argoproj.io in 1 resource instances", "reason": "SomeFinalizersRemain", "status": "True", "type": "NamespaceFinalizersRemaining" } ], "phase": "Terminating" } } 2.原因の推測 直接的な原因としては、Kubernetes の公式ドキュメントに書かれている、finalizers can block the deletion of dependent object という点だろう。 ...