Merge pull request #1608 from future-architect/feature

Terraform コードハイライト改良

Author: ma91n

scripts/register_hljs_terraform.js

@@ -5,6 +5,7 @@ const hljs = require('highlight.js');
 const registerTerraform = require('highlightjs-terraform/terraform');
 registerTerraform(hljs);
 
+// hexo filterで用いるヘルパー関数
 const terraformFilter = (data) => {
   if (data.layout !== 'post' && data.layout !== 'page') {
     return;
@@ -18,6 +19,9 @@ const terraformFilter = (data) => {
     // 'hljs-' プレフィックスを全て除去
     const codeWithoutPrefix = highlighted.value.replace(/hljs-/g, '');
 
+    // 空行を <span class="line"></span><br> に置換し、marked 側で <p> を差し込まれるのを防ぐ
+    const escapedHTML = codeWithoutPrefix.split('\n\n').join('\n<span class="line"></span>\n');
+
     const captionText = meta.trim();
     let finalHtml = '';
 
@@ -29,7 +33,7 @@ const terraformFilter = (data) => {
       finalHtml += `<figcaption><span>${captionText}</span></figcaption>`;
     }
 
-    finalHtml += `<table><tbody><tr><td class="code"><pre>${codeWithoutPrefix}</pre></td></tr></tbody></table></figure>`;
+    finalHtml += `<table><tbody><tr><td class="code"><pre>${escapedHTML}</pre></td></tr></tbody></table></figure>`;
 
     // 元のインデントを維持して返す
     return indent + finalHtml;

source/_posts/2024/20240312a_Terraform連載2024_hclwriteを用いたtfコード生成入門.md

@@ -24,7 +24,7 @@ Terraformファイルをコード生成するため、hclwriteというGoパッ
 
 ある複数のリソースをセットで定義する設計開発ルールがあったとします。AWSの例ですが、以下のようにDynamoDBとその監視をCloudwatch Metricsを用いてセットで行いたいとします。
 
-```sh
+```tf
 # DynamoDB
 resource "aws_dynamodb_table" "myproduct_read" {
   name         = "${terraform.workspace}-myproduct-read"
@@ -159,7 +159,7 @@ Blockとはなにかですが、 `resource`、`module`、`locals` のようなTe
 
 次のようなファイルがあるとします。
 
-```sh dynamodb_table.tf
+```tf dynamodb_table.tf
 resource "aws_dynamodb_table" "myproduct_read" {
   name         = "${terraform.workspace}-myproduct-read"
   billing_mode = "PAY_PER_REQUEST"

source/_posts/2024/20240313a_terraformにおける変数の制御について.md

@@ -50,7 +50,7 @@ Terraformには型による制約の他に、下記3種類の変数の制御方
 
 このブロックの`condition`の内容で真偽を判定し、偽の場合`error_message`で指定のエラーメッセージを出力できます。
 
-```sh
+```tf
 resource "aws_instance" "example" {
   ami           = "ami-020283e959651b381"
   instance_type = "t2.micro"
@@ -102,7 +102,7 @@ variable "ebs_encryption" {
 
 `lifecycle`ブロック内に`precondition`ブロックを作成し、`condition`の条件で真偽を判定し、偽の場合に`error_message`に記載されているメッセージを出力できます。
 
-```sh
+```tf
 data "aws_ec2_instance_type" "example" {
   instance_type = "c5.xlarge"
 }
@@ -150,7 +150,7 @@ resource "aws_instance" "example" {
 
 例としてオートスケーリンググループを作成する際、AZが２つ以上あるかどうかをチェックしたい場合を考えます。書き方は`precondition`と同様で、`postcondition`ブロックの`condition`でAZの数が1よりも大きくない場合に指定のエラーメッセージを出力するようにします。
 
-```sh
+```tf
 resource "aws_launch_configuration" "example" {
   image_id      = "ami-020283e959651b381"
   instance_type = "t2.micro"
@@ -252,7 +252,7 @@ Plan: 2 to add, 0 to change, 0 to destroy.
 
 インスタンスタイプの選定で`precondition`を使いましたが、`precondition`→`postcondition`と単純に置き換えてみたらどうなるでしょうか？
 
-```sh
+```tf
 data "aws_ec2_instance_type" "example" {
   instance_type = "c5.xlarge"
 }

source/_posts/2024/20240315a_サービスの多国展開を支えるTerraform構成.md

@@ -46,7 +46,7 @@ IaCを利用してインフラを構成することで、構築忘れや設定
 
 以下のように環境、リージョン[^1]をそれぞれディレクトリ分けして管理します。
 
-```
+```sh
 envs
 ├── modules
 │   └── ...
@@ -89,7 +89,7 @@ data "google_project" "my_project" {
 
 以下のように環境をそれぞれディレクトリ分けして管理します。
 
-```
+```sh
 envs
 ├── modules
 │   └── ...
@@ -149,7 +149,7 @@ Terraform Workspaceは機能として存在するものの、開発環境を区
 ちょっとした亜種ですが、Workspace名をそのまま変数として持ってきてリソースに適用することも可能です。
 **※この場合は、Workspace名に`asia-northeast1`や`australia-southeast1`を使う必要があります。**
 
-```sh storage_bucket.tf
+```tf storage_bucket.tf
 resource "google_storage_bucket" "bucket" {
 ...
   location      = terraform.workspace
@@ -160,7 +160,7 @@ resource "google_storage_bucket" "bucket" {
 
 以下のようなディレクトリ構成で管理します。
 
-```
+```sh
 envs
 ├── modules
 │   └── ...
@@ -196,7 +196,7 @@ usage () {
   cat <<"EOM"
 Options:
   -h: Show this help
-  -c: city: Specify region's city name 
+  -c: city: Specify region's city name
   -e: environment: Specify enviroment
 EOM
   exit 1

source/_posts/2024/20240318a_cfn-guardを使ってTerraformをポリシーチェックしようとした話.md

@@ -66,7 +66,7 @@ Terraformのポリシーチェックとしては、過去にFuture技術ブロ
 
 下記のようにS3バケットを作成するHCLファイルがあったとしましょう。
 
-```sh
+```tf
 # provider等は省略します
 resource "aws_s3_bucket" "my_bucket" {
   bucket = "my-bucket"
@@ -167,8 +167,8 @@ rule aws_s3_bucket_rule when %aws_s3_bucket_resources !empty {
   %aws_s3_bucket_resources.values.bucket == /^test-.*/
 
   # "env" タグが必ず含まれること
-  let required_tags = %aws_s3_bucket_resources.values.tags_all[ 
-      Key == 'env' ] 
+  let required_tags = %aws_s3_bucket_resources.values.tags_all[
+      Key == 'env' ]
   %required_tags[*] {
       Value IN ['dev', 'stg', 'prod', 'demo']
       <<Tag must have a permitted value>>

source/_posts/2024/20240321a_Terraform連載2024_テストとモックを使ってみる.md

@@ -75,14 +75,14 @@ S3 バケットを作成し、そのS3 バケット名が期待する名前な
 コードは、以下です。
 `backend.tf` を省略していますが、よしなにお願いします。
 
-```sh local.tf
+```tf local.tf
 locals {
   project_name  = "sample"
   region        = "ap-northeast-1"
 }
 ```
 
-```sh s3_bucket.tf
+```tf s3_bucket.tf
 resource "aws_s3_bucket" "test001" {
   bucket = "${terraform.workspace}-${local.project_name}-test001"
   tags = {
@@ -92,7 +92,7 @@ resource "aws_s3_bucket" "test001" {
 }
 ```
 
-```sh versions.tf
+```tf versions.tf
 terraform {
   required_version = "~> 1.7.5"
   required_providers {
@@ -112,7 +112,7 @@ provider "aws" {
 conditionに記述したS3 バケット名と実際のS3 バケット名を比較して問題ないかをチェックしています。
 仮に期待していない値の場合は、`error_message`の値が出力されます。
 
-```sh s3_bucket.tftest.hcl
+```hcl s3_bucket.tftest.hcl
 run "test" {
   assert {
     condition     = aws_s3_bucket.test.bucket == "${terraform.workspace}-${local.project_name}-test"
@@ -181,7 +181,7 @@ terraform test -test-directory=hoge
 
 今回は、`apply`を実行したのですが、`plan`を実行したいときは、以下のように`command`　指定します。
 
-```sh s3_bucket.tftest.hcl
+```tf s3_bucket.tftest.hcl
 run "test" {
   command = plan
   assert {
@@ -225,7 +225,7 @@ sample.tftest.hcl... in progress
 `terraform test` をベースに作成しているため差分のみを記載します。
 以下にモック用のプロバイダを指定します。
 
-```sh mocked_providers.tftest.hcl
+```tf mocked_providers.tftest.hcl
 mock_provider "aws" {
   alias = "fake"
 }
@@ -239,7 +239,7 @@ run "use_mocked_provider" {
 
 `versions.tf`のprovider 定義を削除します。
 
-```sh versions.tf
+```tf versions.tf
 terraform {
   required_version = "~> 1.7.5"
   required_providers {
@@ -272,7 +272,7 @@ Success! 2 passed, 0 failed.
 
 もしモックと`terraform test`のように実際のリソースに対してテストを行いたい場合は、以下のプロバイダ指定で行うことができます。
 
-```sh mocked_providers.tftest.hcl
+```tf mocked_providers.tftest.hcl
 provider "aws" {}
 
 mock_provider "aws" {

source/_posts/2024/20240325a_Azure環境Terraform実行におけるリソースプロバイダーについて.md

@@ -30,7 +30,7 @@ Azure環境でTerraformを利用する際、裏で動いているリソースプ
 見やすいように改行等追加しています。
 
 ```shell
-Original Error: Cannot register providers: 
+Original Error: Cannot register providers:
 Microsoft.ServiceBus,
 Microsoft.DBforPostgreSQL,
 (中略)...
@@ -86,7 +86,7 @@ AzureにおけるTerraformプロバイダーとしては下記が用意されて
 
 あるいは環境変数`ARM_SKIP_PROVIDER_REGISTRATION`を設定することも可能とのことです。
 
-```sh terraform
+```tf terraform
 provider "azurerm" {
   skip_provider_registration = true
   features {}

source/_posts/2024/20240327a_手動運用しているCloudflareをTerraformでInfrastructure_as_Codeする.md

@@ -9,7 +9,7 @@ tag:
 category:
   - Infrastructure
 thumbnail: /images/20240327a/thumbnail.png
-author: 大岩潤矢 
+author: 大岩潤矢
 lede: "Cloudflareで管理しているドメインのDNS設定や、Cloudflare Pages等のサービスの設定を、Terraform管理に移行した際の手順等を、備忘録がてら記載します。"
 ---
 ## はじめに
@@ -176,9 +176,9 @@ Terraformのバージョン情報やプロパイダの設定、tfstateの配置
 - Pages: `global/pages/プロジェクト名.tfstate`
 - Workers: `global/workers/プロジェクト名.tfstate`
 
-```sh setup.tf
+```tf setup.tf
 terraform {
-  // terraformのバージョン設定
+  # terraformのバージョン設定
   required_version = "~> 1.7.5"
 
   // cloudflareプロバイダを利用
@@ -189,7 +189,7 @@ terraform {
     }
   }
 
-  // tfstateの保存先の設定。R2 Storageを使用する
+  # tfstateの保存先の設定。R2 Storageを使用する
   backend "s3" {
     endpoints = {
       s3 = "https://<アカウントID>.r2.cloudflarestorage.com"
@@ -223,7 +223,7 @@ https://future-architect.github.io/articles/20230502a/
 まずは現在の設定をTerraformの記述に落とし込んでくれる `generate` コマンドを試します。
 
 ```bash
-cf-terraforming generate --resource-type "cloudflare_record" --zone "ゾーンID" 
+cf-terraforming generate --resource-type "cloudflare_record" --zone "ゾーンID"
 ```
 
 - `--resource-type` オプションで取得したいリソースを指定します。今回はDNS設定を取得してみるので、 `cloudflare_record` を指定します。
@@ -233,13 +233,13 @@ cf-terraforming generate --resource-type "cloudflare_record" --zone "ゾーンID
 実行してみたところ、以下のエラーが出ました。
 
 ```sh
-FATA[0000] --account and --zone are mutually exclusive, support for both is deprecated 
+FATA[0000] --account and --zone are mutually exclusive, support for both is deprecated
 ```
 
 どうやら先程セットした環境変数 `CLOUDFLARE_ACCOUNT_ID` がセットされていると正常に動いてくれなさそうなので、一旦 `unset CLOUDFLARE_ACCOUNT_ID` コマンドで環境変数を外しておきます。
 
 ```sh
-% cf-terraforming generate --resource-type "cloudflare_record" --zone "ゾーンID" 
+% cf-terraforming generate --resource-type "cloudflare_record" --zone "ゾーンID"
 resource "cloudflare_record" "terraform_managed_resource_xxxxxxxxxxx" {
   name    = "920oj.net"
   proxied = true
@@ -269,14 +269,14 @@ resource "cloudflare_record" "terraform_managed_resource_yyyyyyyyyyy" {
 
 また、zone_idやルートドメイン名は何度か記述することになるので、local変数に定義しておくとミスが減ります。
 
-```sh local.tf
+```tf local.tf
 locals {
   zone_id = "ゾーンID"
   root_domain = "920oj.net"
 }
 ```
 
-```sh record.tf
+```tf record.tf
 resource "cloudflare_record" "cname_root" {
   name    = local.root_domain
   proxied = true
@@ -297,23 +297,23 @@ importするためのコマンドはcf-terraformingを利用して出力でき
 
 まずはcf-terraformingを利用してコマンドを出力してみましょう。
 
-```
+```sh
  % cf-terraforming import --resource-type "cloudflare_record" --zone "ゾーンID"
 terraform import cloudflare_record.terraform_managed_resource_xxxxxxxxxx ゾーンID/xxxxxxxxxx
 terraform import cloudflare_record.terraform_managed_resource_yyyyyyyyyy ゾーンID/yyyyyyyyyy
 ```
 
 出力されたコマンドをもとに、リソース名を変更した上で、シェルスクリプトファイルとして保存します。
 
-```bash import.sh
+```sh import.sh
 terraform import cloudflare_record.terraform_managed_resource_cname_root ゾーンID/xxxxxxxxxx
 terraform import cloudflare_record.terraform_managed_resource_mx_root ゾーンID/yyyyyyyyyy
 ```
 
 これを実行してみましょう。 Import successful! と表示されれば、インポート完了です。
 
 ```sh
- % ./import.sh                  
+ % ./import.sh
 cloudflare_record.cname_root: Importing from ID "ゾーンID/xxxxxxxxxx"...
 cloudflare_record.cname_root: Import prepared!
   Prepared cloudflare_record for import
@@ -362,7 +362,7 @@ Cloudflare Pagesは、 `cloudflare_pages_domain` リソースと `cloudflarepage
 
 `cloudflare_pages_project` のインポートでは、 `to` にはimportする対象のリソース名を、 `id` には `<アカウントID>/<プロジェクト名>` を記載します。
 
-```sh import.tf
+```tf import.tf
 # cloudflare_pages_domain のインポート
 import {
   to = cloudflare_pages_domain.domain-920oj-net  # 対象のリソース名
@@ -427,15 +427,15 @@ Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.
 
 内容が正しいか確認するのと、コメントを消したり、local変数に置き換えたりして体裁を整えましょう。また、ファイルもリソースごとに分けておきましょう。
 
-```sh pages_domain.tf
+```tf pages_domain.tf
 resource "cloudflare_pages_domain" "domain-920oj-net" {
   account_id   = local.account_id
   domain       = "920oj.net"
   project_name = "920oj-net"
 }
 ```
 
-```sh generate.tf
+```tf generate.tf
 resource "cloudflare_pages_project" "project-920oj-net" {
   account_id        = local.account_id
   name              = local.project_name