メインコンテンツまでスキップ

· 約2分

特定ディレクトリ配下のコミットのみを抽出して別のGitリポジトリとして管理し直す方法について説明する。

手順

  1. フィルターを使用して履歴を抽出

    • git filter-repo を使って、特定ディレクトリのみの履歴を抽出する。これは git filter-branch の推奨代替ツール。
    • 事前に git filter-repo をインストールしておく。
    pip install git-filter-repo
  2. 一時的なクローンの作成

    • 元のリポジトリをクローンする。
    git clone --no-local --no-hardlinks <元のリポジトリのパス> temp-repo
    cd temp-repo
  3. フィルタリング実行

    • git filter-repo を使用して特定ディレクトリ配下の履歴のみを抽出する。
    git filter-repo --subdirectory-filter subdir
  4. 新しいリポジトリの作成

    • 抽出した履歴を新しいリポジトリに移行する。
    cd ..
    git clone temp-repo new-repo
    cd new-repo
  5. 不要なリポジトリの削除

    • 一時的に作成したリポジトリを削除する。
    cd ..
    rm -rf temp-repo

補足

  • subdir は新しいリポジトリのルートディレクトリになる。
  • git filter-repo を使用する場合、Python 3.5以降が必要。
  • 元のリポジトリをそのまま残したい場合は、クローンを使用するが、元のリポジトリを直接操作しても構わない。

この手順に従えば、特定ディレクトリ配下のコミットのみを新しいリポジトリとして抽出して管理することができる。

· 約3分

メソッドのエラー処理の方法には、戻り値で成功と失敗を表現する方法と例外をraiseする方法の2つがあり、どちらを選択するかは状況に応じて異なる。 以下にそれぞれのアプローチの特徴を示す。

戻り値で成功と失敗を表現する

  • 適用ケース: エラーが頻繁に発生する可能性がある場合や、エラーが予想される正常な動作の一部である場合。例えば、ユーザーの入力の検証など。
  • 利点: 呼び出し側でエラーの状態を簡単にチェックでき、コードの読みやすさが向上する。また、例外処理のオーバーヘッドがない。
  • 欠点: エラーが無視されやすく、エラー処理が行われないリスクがある。

例外をraiseする

  • 適用ケース: エラーが予期せぬもので、プログラムの正常な流れとは考えられない場合。例えば、データベース接続の失敗やファイルの読み込みエラーなど。
  • 利点: エラーが無視されにくく、エラー処理が強制される。また、例外処理により、エラー処理を分離しやすくなる。
  • 欠点: 例外処理にはオーバーヘッドがあり、パフォーマンスに影響を与えることがある。また、過度に例外を使用するとコードが複雑になる可能性がある。

どちらを選択するべきか

どちらのアプローチを採用するかは、以下の点を考慮して決定する。

  • エラーの頻度と性質: エラーが頻繁に発生し、処理の正常な一部である場合は戻り値を使用する。エラーが予期せぬものであれば例外を使用する。
  • コードの可読性と保守性: 例外を使用するとエラー処理を分離しやすくなりますが、コードが複雑になる可能性もある。
  • パフォーマンスの要件: 高いパフォーマンスが必要な場合は、例外処理のオーバーヘッドを考慮する必要がある。

最終的な選択は、これらの要素を総合的に考慮して行う必要がある。 また、プロジェクトのコーディング規約やチームの合意も重要な要素。

参考

· 約2分

概要

  • Infrastructure as Code
  • インフラの構成をコードで管理すること

メリット

  • インフラの構成をコードで管理することで、変更履歴を管理できる
  • コードレビューを通じて、インフラの構成をチェックできる
  • コードを実行することで、インフラの構成を再現できる
  • コードを実行することで、インフラの構成を破棄できる
  • コードを実行することで、インフラの構成を更新できる
  • コードを実行することで、インフラの構成を複製できる
  • コードを実行することで、インフラの構成を移行できる
  • コードを実行することで、インフラの構成をテストできる
  • コードを実行することで、インフラの構成を検証できる
  • コードを実行することで、インフラの構成を監視できる
  • コードを実行することで、インフラの構成をドキュメント化できる
  • コードを実行することで、インフラの構成を可視化できる
  • コードを実行することで、インフラの構成を比較できる
  • コードを実行することで、インフラの構成を分析できる
  • ・・・

参考:https://speakerdeck.com/oracle4engineer/best-practice-of-iac

気が向いたらまとめていく

· 約1分

docusaurus.config.js

  plugins: [
[
'@docusaurus/plugin-content-docs',
{
id: 'docs-seo-words',
path: 'docs-seo-words',
routeBasePath: 'seo-words',
sidebarPath: require.resolve('./sidebars.js'),
},
],
],

doc-seo-words/index.md

---
sidebar_position: 1
---

# SEO用語集TOP

リスタートしないとエラーなるかも

· 約3分

docker run --init コマンドは、Dockerコンテナ内で init プロセスを起動するためのオプションです。通常、Dockerコンテナ内で複数のプロセスを実行することは推奨されていません。しかし、一部の場合、コンテナ内で複数のプロセスを管理する必要があることがあります。この際に --init オプションを使用することができます。

init プロセスは、コンテナ内のプロセスを管理し、シグナルの転送やプロセスの終了を適切に処理する役割を果たします。特に、Dockerコンテナはデフォルトで init プロセスを起動せず、コンテナ内の最初のプロセスがコンテナのPID 1(プロセスID 1)になります。これは、通常のLinuxプロセスとは異なり、シグナルのハンドリングなどの面で問題が発生する可能性があります。

--init オプションを使用すると、Dockerコンテナ内で init プロセスが起動され、他のプロセスは init プロセスの子プロセスとして実行されます。これにより、プロセスの管理がより適切に行われ、シグナルの正確な伝達やプロセスの終了が確実に行われます。

以下は --init オプションを使用してコンテナを実行する例です:

docker run --init -d my-container-image

このコマンドは、my-container-image というDockerイメージを使用してコンテナをバックグラウンドで実行し、--init オプションを指定して init プロセスを有効にします。

--init オプションは、コンテナ内で複数のプロセスを安全かつ適切に実行する際に便利ですが、通常の単一プロセスのコンテナでは必要ありません。必要な場合にのみ使用することをお勧めします。

まとめ

  • docker run --init は、Dockerコンテナ内で init プロセスを起動するオプションです。
  • init プロセスは、コンテナ内のプロセスを管理し、シグナルの転送やプロセスの終了を適切に処理します。
  • コンテナ内で複数のプロセスを安全に実行する際に使用され、プロセス管理を向上させます。
  • 通常の単一プロセスのコンテナでは必要ありません。必要な場合にのみ使用します。

· 約1分

GAS

取得

API

const res = UrlFetchApp.fetch('https://example.com');
status = res.getResponseCode();
const json = JSON.parse(res.getContentText());

保存

Spreadsheet

複数行を追加

const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('シート名');

sheet
.getRange(sheet.getLastRow() + 1, 1, values.length, values[0].length)
.setValues(values);

Python

取得

HTML:requests

def download_html(url, file_path):
res = requests.get(url)
html = res.text
os.makedirs(os.path.dirname(file_path), exist_ok=True)
with open(file_path, 'w') as f:
f.write(html)
return html

def get_html(url, force_download=False):
file_path = f"html/{convert_url_to_filename(url)}.html"

if os.path.isfile(file_path) and not force_download:
with open(file_path, 'r') as f:
html = f.read()
else:
html = download_html(url, file_path)

return html

def convert_url_to_filename(url):
return re.sub(r'/', '_', url)

requests

import requests

res = requests.get('https://example.com')
status = res.status_code
json = res.json()

保存

csv

import csv
with open(f'hoge.csv', 'w', newline='', encoding='utf-8') as f:
writer = csv.writer(f)
writer.writerow([
'id', # id
'name', # プロジェクト名
])
writer.writerows(dataList)

· 約7分

ignore_changes とは?

ignore_changes は、特定の属性の変更をTerraformが気にしないようにする設定です。これを使うことで、ある属性を手動で変更してもTerraformはそれを無視します。

ignore_changes がない場合とある場合の挙動の違い

ignore_changes がある場合とない場合の挙動の違いを説明します。

ignore_changes がない場合の挙動:

  1. Terraformを実行してリソースを作成
    例えば、AWSのインスタンスを作成するコードを実行します。

    resource "aws_instance" "example" {
    ami = "ami-12345678"
    instance_type = "t2.micro"

    tags = {
    Name = "MyInstance"
    }
    }
  2. 手動でリソースの属性を変更
    この後、AWSの管理コンソールからインスタンスのNameタグを"MyNewInstance"に変更します。

  3. 再度Terraformを実行
    もう一度Terraformのplanapplyを実行すると、Nameタグが"MyInstance"と"MyNewInstance"の間に差異があると検知します。Terraformはこの差異を修正しようとします。すなわち、Nameタグを再び"MyInstance"に戻そうとします。


ignore_changes がある場合の挙動:

  1. Terraformを実行してリソースを作成
    今度はignore_changes を使用して同じリソースを作成します。

    resource "aws_instance" "example" {
    ami = "ami-12345678"
    instance_type = "t2.micro"

    tags = {
    Name = "MyInstance"
    }

    lifecycle {
    ignore_changes = [tags["Name"]]
    }
    }
  2. 手動でリソースの属性を変更
    同様に、AWSの管理コンソールからインスタンスのNameタグを"MyNewInstance"に変更します。

  3. 再度Terraformを実行
    もう一度Terraformのplanapplyを実行しても、今回はNameタグについての変更は無視されます。したがって、TerraformはNameタグの"MyNewInstance"をそのままにして、変更しようとしません。

補足:ignore_changes がある場合でも、stateファイルにはリアルタイムのリソースの状態が保存される

Terraformのignore_changesが設定されている場合でも、Terraformはリアルタイムのリソースの状態をterraform.tfstate(stateファイル)に反映します。ignore_changesplanapplyの際の挙動を制御するものであり、実際のリソースの状態の記録には影響しません。

具体的な動作を詳しく説明します:

  1. ignore_changesが設定されたリソースを作成: 最初に、ignore_changesが設定されたリソースをterraform applyで作成します。この操作後、stateファイルにはそのリソースの最初の状態が保存されます。

  2. リソースを手動で変更: 次に、外部の手段(例えば、クラウドのコンソール)でリソースを手動で変更します。

  3. Terraformのrefreshまたはapplyを実行: この操作を行うと、Terraformはクラウドプロバイダから最新のリソースの状態を取得し、stateファイルを更新します。この時点で、stateファイルには手動で変更されたリソースの状態が反映されます。

  4. 変更の検知: terraform planを実行すると、通常はTerraformがコードとstateファイルの差異を報告します。しかし、ignore_changesが設定されている属性については、この差異は報告されません。それにも関わらず、stateファイル自体には実際のリソースの状態が正確に記録されています。

ignore_changesの挙動を以下の図で説明します。

ignore_changesが設定されていない場合

ignore_changesが設定されている場合

簡単にまとめると、

  • ignore_changesは、Terraformがplanapplyの際に特定の属性の変更を無視するようにするものです。
  • しかし、stateファイルには常にリアルタイムのリソースの状態が保存されます。
  • そのため、手動で変更した後、Terraformの操作でstateファイルを更新すると、その手動変更がstateファイルに反映されますが、その変更はplanapplyで無視されます。

参考:https://dev.classmethod.jp/articles/note-about-terraform-ignore-changes/

まとめ

  • ignore_changes がない場合:Terraformは手動での変更を検知し、それを修正しようとします。
  • ignore_changes がある場合:指定した属性についての変更はTerraformによって無視されます。したがって、手動での変更が維持されます。

この機能は、特定の属性の手動変更を許容したい場合や、外部のプロセスによって頻繁に変更される属性をTerraformの管理外に置きたい場合に有用です。

· 約13分

Amazon EC2 Auto Scaling Group (ASG) と Application Load Balancer (ALB) を組み合わせて使用する場合、以下の手順で設定を行います。

  1. Application Load Balancer (ALB) の作成:

    • AWS Management Console にログインし、EC2 ダッシュボードから「Load Balancers」を選択。
    • 「Create Load Balancer」をクリックし、Application Load Balancer を選択。
    • 必要な情報を入力して ALB を作成。
  2. Target Group の作成:

    • ALB 作成時に、Target Group を作成するか、後から手動で作成することができます。
    • Target Group では、ALB がトラフィックを転送する EC2 インスタンスを指定します。
  3. Auto Scaling Group (ASG) の作成:

    • EC2 ダッシュボードから「Auto Scaling Groups」を選択して「Create Auto Scaling group」をクリック。
    • Launch Configuration または Launch Template を選択または作成。
    • ASG の詳細を設定。ここで、先ほど作成した Target Group を指定します。
  4. ASG に ALB の Target Group を関連付ける:

    • ASG の作成または編集時に、[Advanced settings] セクションで、先ほど作成した Target Group を選択。
  5. ALB のリスナールールの設定:

    • 必要に応じて、ALB のリスナールールを設定して、特定の URL パスやホストヘッダーに基づいてトラフィックを異なる Target Group にルーティングします。
  6. ヘルスチェックの設定:

    • ALB と ASG のヘルスチェックを適切に設定することで、正常でないインスタンスを自動的に取り除くことができます。
  7. セキュリティグループの設定:

    • ALB と EC2 インスタンスの両方に対して適切なセキュリティグループを設定します。
  8. DNS と ALB の関連付け:

    • 必要に応じて、ドメイン名を ALB の DNS 名にマッピングします。

以上で、ALB は受信したトラフィックを ASG 内のインスタンスに均等に分散して転送できるようになります。ASG は、インスタンスのヘルスチェックに基づいて、新しいインスタンスの起動や不健康なインスタンスの終了を自動的に行います。

Terraformで実装

1. ALB の作成

今回は、内部向けのApplication Load Balancer (ALB) をTerraformで作成するための基本的なコードを以下に示します。

provider "aws" {
region = "us-west-2" # 例としてus-west-2リージョンを使用しています。適切なリージョンに変更してください。
}

resource "aws_security_group" "alb_sg" {
name = "alb-sg"
description = "Security group for the internal ALB"

# 以下はHTTPアクセスを許可する例です。必要に応じて変更してください。
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["10.0.0.0/16"] # VPCのCIDR範囲を指定してください。
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}

resource "aws_lb" "internal_alb" {
name = "my-internal-alb"
internal = true
load_balancer_type = "application"
security_groups = [aws_security_group.alb_sg.id]

enable_deletion_protection = false

enable_cross_zone_load_balancing = true

subnets = [
# ここに使用するサブネットのIDをリストとして指定してください。
# "subnet-0123456789abcdef0",
# "subnet-0123456789abcdef1",
# ...
]

tags = {
Name = "my-internal-alb"
}
}

resource "aws_lb_listener" "front_end" {
load_balancer_arn = aws_lb.internal_alb.arn
port = "80"
protocol = "HTTP"

default_action {
type = "fixed-response"
fixed_response {
content_type = "text/plain"
message_body = "Hello, World"
status_code = "200"
}
}
}

上記のコードは、内部向けのALBを作成するための基本的なTerraformコードです。必要に応じて、セキュリティグループの設定やサブネットのID、リスナーの設定などを変更してください。

2. Target Group の作成

ALBのTarget GroupをTerraformで作成する方法を以下に示します。

provider "aws" {
region = "us-west-2" # 例としてus-west-2リージョンを使用しています。適切なリージョンに変更してください。
}

resource "aws_lb_target_group" "alb_target_group" {
name = "my-alb-target-group"
port = 80
protocol = "HTTP"
vpc_id = "vpc-0123456789abcdef0" # 適切なVPCのIDに変更してください。

health_check {
enabled = true
interval = 30
path = "/"
port = "traffic-port"
timeout = 5
healthy_threshold = 3
unhealthy_threshold = 3
protocol = "HTTP"
matcher = "200-399"
}

tags = {
Name = "my-alb-target-group"
}
}

上記のコードは、ALBのTarget Groupを作成するための基本的なTerraformコードです。必要に応じて、ヘルスチェックの設定やVPCのIDなどを変更してください。

このTarget Groupを使用して、EC2インスタンスや他のリソースを登録することで、ALBがトラフィックを転送する先として機能します。

3. ASG の作成

Auto Scaling Group (ASG) をTerraformで作成する方法を以下に示します。

まず、Launch Configurationを作成し、その後でAuto Scaling Groupを作成します。以下はその基本的なTerraformコードです。

provider "aws" {
region = "us-west-2" # 例としてus-west-2リージョンを使用しています。適切なリージョンに変更してください。
}

resource "aws_launch_configuration" "asg_config" {
name_prefix = "my-asg-config-"
image_id = "ami-0123456789abcdef0" # 適切なAMI IDに変更してください。
instance_type = "t2.micro"
security_groups = ["sg-0123456789abcdef0"] # 適切なセキュリティグループIDに変更してください。

# 必要に応じて他の設定を追加してください。

lifecycle {
create_before_destroy = true
}
}

resource "aws_autoscaling_group" "asg" {
name = "my-asg"
launch_configuration = aws_launch_configuration.asg_config.name
min_size = 1
max_size = 3
desired_capacity = 2
vpc_zone_identifier = ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"] # 適切なサブネットIDに変更してください。

target_group_arns = ["arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-alb-target-group/abcdef0123456"] # 先ほど作成したTarget GroupのARNに変更してください。

tags = {
Name = "my-asg"
}
}

上記のコードは、Launch ConfigurationとAuto Scaling Groupを作成するための基本的なTerraformコードです。必要に応じて、AMI ID、セキュリティグループID、サブネットID、Target GroupのARNなどを変更してください。

4. ALB と ASG の関連付け

4番の「ASG に ALB の Target Group を関連付ける」に関して、3番の手順で提供したTerraformコード内で既に実施しています。具体的には、aws_autoscaling_group リソースの中で target_group_arns 属性を使用して、ASGにTarget Groupを関連付けています。

以下はその部分を再掲します:

resource "aws_autoscaling_group" "asg" {
...
target_group_arns = ["arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-alb-target-group/abcdef0123456"] # 先ほど作成したTarget GroupのARNに変更してください。
...
}

この target_group_arns 属性により、ASGのインスタンスが起動または終了する際に、ALBのTarget Groupに自動的に登録または登録解除されます。

5. ALB のリスナールールの設定

5番の手順「ALB のリスナールールの設定」に関して、1番の手順で提供したTerraformコードの中で部分的に実施しています。具体的には、aws_lb_listener リソースを使用して、デフォルトのリスナールールを設定しています。

しかし、特定のURLパスやホストヘッダーに基づいてトラフィックを異なるTarget Groupにルーティングするような詳細なリスナールールの設定はまだ行っていません。

以下は、特定のURLパス(例:/api)に基づいてトラフィックを異なるTarget Groupにルーティングするリスナールールを追加するTerraformコードの例です:

resource "aws_lb_listener_rule" "api_path_rule" {
listener_arn = aws_lb_listener.front_end.arn

action {
type = "forward"
target_group_arn = aws_lb_target_group.api_target_group.arn
}

condition {
path_pattern {
values = ["/api*"]
}
}
}

resource "aws_lb_target_group" "api_target_group" {
name = "api-target-group"
port = 80
protocol = "HTTP"
vpc_id = "vpc-0123456789abcdef0" # 適切なVPCのIDに変更してください。

health_check {
enabled = true
interval = 30
path = "/api/health"
port = "traffic-port"
timeout = 5
healthy_threshold = 3
unhealthy_threshold = 3
protocol = "HTTP"
matcher = "200-399"
}

tags = {
Name = "api-target-group"
}
}

上記のコードでは、/api パスにアクセスがあった場合、api_target_group というTarget Groupにトラフィックをルーティングするリスナールールを設定しています。

このようにして、異なるURLパスやホストヘッダーに基づいてトラフィックを異なるTarget Groupにルーティングするリスナールールを設定することができます。必要に応じて、上記のコードを変更・追加してください。

6. ヘルスチェックの設定

6番の手順「ヘルスチェックの設定」に関して、2番の手順で提供したTerraformコードの中で既に実施しています。具体的には、aws_lb_target_group リソース内で health_check 属性を使用して、ヘルスチェックの設定を行っています。

以下はその部分を再掲します:

resource "aws_lb_target_group" "alb_target_group" {
...
health_check {
enabled = true
interval = 30
path = "/"
port = "traffic-port"
timeout = 5
healthy_threshold = 3
unhealthy_threshold = 3
protocol = "HTTP"
matcher = "200-399"
}
...
}

上記のコードでは、ヘルスチェックの設定を行っており、特定のパス(/)に対してHTTPリクエストを行い、ステータスコードが200から399の範囲内であればインスタンスを健康と判断しています。必要に応じて、上記のヘルスチェックの設定を変更してください。

7. セキュリティグループの設定

7番の手順「セキュリティグループの設定」に関して、1番の手順で提供したTerraformコードの中で既に実施しています。具体的には、aws_security_group リソースを使用して、ALBのセキュリティグループを設定しています。

以下はその部分を再掲します:

resource "aws_security_group" "alb_sg" {
name = "alb-sg"
description = "Security group for the internal ALB"

# 以下はHTTPアクセスを許可する例です。必要に応じて変更してください。
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["10.0.0.0/16"] # VPCのCIDR範囲を指定してください。
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}

上記のコードでは、セキュリティグループを作成し、HTTPアクセスを許可する設定を行っています。

ただし、EC2インスタンスや他のリソースに関するセキュリティグループの設定も必要であれば、それに関するTerraformコードを追加する必要があります。

8. DNS と ALB の関連付け

8番の手順「DNS と ALB の関連付け」に関して、ALBのDNS名を使用してRoute 53や他のDNSサービスでドメイン名をマッピングする設定を行います。

以下は、AWSのRoute 53を使用して、特定のドメイン名(例:myapp.example.com)をALBのDNS名にマッピングするTerraformコードの例です:

resource "aws_route53_zone" "example" {
name = "example.com"
}

resource "aws_route53_record" "alb_record" {
zone_id = aws_route53_zone.example.zone_id
name = "myapp.example.com"
type = "A"

alias {
name = aws_lb.internal_alb.dns_name
zone_id = aws_lb.internal_alb.zone_id
evaluate_target_health = false
}
}

上記のコードでは、まずexample.comというドメインのRoute 53ホストゾーンを作成し、その後でmyapp.example.comというサブドメインをALBのDNS名にマッピングするAレコード(エイリアスレコード)を作成しています。

このコードを適用する前に、example.comのドメインがRoute 53で管理されていること、および、そのドメインのネームサーバー設定が正しく行われていることを確認してください。

· 約1分

ケース:GitHubActionsでDockerイメージをECRにプッシュする

TODO:別ページにまとめるなどしたい

  • AWSへのアクセスにはOIDCでIAMユーザーを使う
  • Actionsでは、docker/build-push-action周りを使ってDockerイメージをECRにプッシュする(その他のactionsは適宜調整してね)

参考

· 約3分

ignore_changes は、Terraform のリソースブロック内で使用される属性で、指定されたリソースの特定の属性またはブロックに対する変更を無視するために使用されます。これは、Terraform が既存のリソースを変更しようとする場合に役立ちますが、特定の属性の変更を許可したくない場合に使用されます。

以下は、ignore_changes の基本的な使い方を示す例です。

resource "aws_instance" "example" {
ami = "ami-12345678"
instance_type = "t2.micro"

lifecycle {
ignore_changes = [ami, instance_type]
}
}

この例では、amiinstance_type の属性に対する変更は Terraform によって無視されます。この意味は、AWSコンソールや別のツールを使用してこれらの属性を手動で変更した場合、次回の terraform planterraform apply の実行時に Terraform がこれらの変更を検出または適用しないことを意味します。

ブロック全体を無視する場合もあります。たとえば、以下のように tags ブロック全体を無視することもできます。

resource "aws_instance" "example" {
ami = "ami-12345678"
instance_type = "t2.micro"
tags = {
Name = "example-instance"
}

lifecycle {
ignore_changes = [tags]
}
}

ignore_changes を使用する際の注意点:

  1. 無視する属性やブロックを過度に使用すると、インフラストラクチャの管理が複雑になる可能性があります。最小限に抑え、使用する際の理由をドキュメント化することがおすすめです。
  2. ignore_changes は、特定の状況や一時的な変更を管理する際に役立つツールですが、恒常的に使用することは避けるよう努めてください。

最後に、ignore_changes の使い方や挙動に関する詳細な情報や例については、公式のTerraformドキュメントを参照するとよいでしょう。