search

sacloud / terraform-provider-sakuracloud

Terraform provider for SakuraCloud
https://docs.usacloud.jp/terraform
Apache License 2.0
71 stars 23 forks source link

[調査依頼]VPCルーターが意図せず再生成 #479

Closed yamatosi closed 5 years ago

yamatosi commented 5 years ago

お世話になっております。 大変恐縮なのですが、弊社環境で以下の不具合が発生し、原因調査にご協力をお願いできないでしょうか。

昨日、7/18 14:11(日本時間)頃に追加でサーバーリソースを作成したところ、VPCルーターが再生成されました。 原因がわからないのですが、既存仕様や直近の修正などで思い当たることはございますでしょうか。

なお、当該リージョンで、7/12までは同一作業を行ってもVPCルーターが再生成されるようなことはありませんでした。

以下補足情報となります。 使用バージョン：sacloud/terraform:1.11.4 →provider.sakuracloudについては、versionを指定をしていません。

yamamoto-febc commented 5 years ago

@yamatosi

こちらは以下のような状況ということでしょうか？

この場合、再作成される際はterraform apply時のログに以下のような赤文字のメッセージの表示が残っているかと思います。

スクリーンショット 2019-07-19 13 26 22

何が原因で再作成されたのかを追うためにはこの辺りのログを追うと良いかと思います。

yamatosi commented 5 years ago

@yamamoto-febc ご回答ありがとうございます。

弊社環境では、moduleで各設定を読み込んでおりまして、VPC設定が以下 network となりまして、 Destroy&Creatingの処理が予期せず走りました。

random_string.shared: Refreshing state... (ID: none)
random_string.password: Refreshing state... (ID: none)
sakuracloud_ssh_key_gen.rancher-private-key: Refreshing state...
sakuracloud_switch.switch: Refreshing state... (ID: 113101116179)
sakuracloud_ssh_key.key: Refreshing state... (ID: 113101116178)
sakuracloud_internet.router: Refreshing state... (ID: 113101116177)
sakuracloud_vpc_router.vpc-router: Refreshing state... (ID: 113101116184)
sakuracloud_vpc_router_interface.eth1: Refreshing state... (ID: interface-1823518848)
sakuracloud_vpc_router_user.user: Refreshing state... (ID: 1694519003)
sakuracloud_vpc_router_l2tp.l2tp: Refreshing state... (ID: 3980149413)
module.network.sakuracloud_vpc_router_l2tp.l2tp: Destroying... (ID: 3980149413)
module.network.sakuracloud_vpc_router_user.user: Destroying... (ID: 1694519003)
module.network.sakuracloud_internet.router: Creating...
yamamoto-febc commented 5 years ago

再作成時の詳細が出力されていないので、おそらく--auto-approveオプションをつけてterraform applyを実行されているのだと思います。

となるとログから原因を探るのが難しいため、再作成が走る要因を一つづつ潰していく方向になろうかと思います。

原因として考えられるのは、

などがあります。

お手元に何かヒントになりそうな情報は残っていないでしょうか？

yamatosi commented 5 years ago

ご回答ありがとうございます。

はい、 -auto-approve を付与しております。

VPCルータリソースがtaintされていた

こちらは確認します。

terraform apply時のリフレッシュ処理時にVPCルータの情報を参照するためのAPI(GET/appliance/:id)から404が返された (コントロールパネル上でVPCルータを削除してしまっていたなど)

の可能性は低いと考えます。

実行時の環境の変化などでVPCルータの以下フィールドの値が変更された plan switch_id vip ipaddress1 ipaddress2 vrid zone

こちらも変更はしておりません。 ネットワークで変更した可能性があるとすると、スイッチの帯域のみでございます。

お手元に何かヒントになりそうな情報は残っていないでしょうか？

残念ながら、残っておりません。

yamamoto-febc commented 5 years ago

スイッチ+ルータの帯域変更を行った場合、ルータ(sakuracloud_internet)リソースのIDが変更されます。 もしかして帯域変更をTerraform以外(コンパネなど)から行われていないでしょうか？

その場合、terraform apply時のリフレッシュ処理でスイッチ+ルータ(sakuracloud_internet)が参照できず、新たに作成しようとします。その際にVPCルータがスイッチ+ルータに依存していた場合は再作成が行われます。

yamatosi commented 5 years ago

もしかして帯域変更をTerraform以外(コンパネなど)から行われていないでしょうか？

ここ数日、帯域を変更する必要があり、頻繁に試しておりました。 該当時間帯に実施していたか確認します。

yamatosi commented 5 years ago

こちら再作成される旨、確認出来ました。 因みにですが、再作成されないようにすることは可能でしょうか。

弊社環境において、サーバリソースについては以下のようにディスクイメージのアーカイブIDを固定にしております。

  lifecycle {
    ignore_changes = ["source_archive_id"]
  }
yamamoto-febc commented 5 years ago

ルータの帯域変更に伴う再作成を防ぐ方法はいくつかあります。

方法1: 帯域変更をTerraformのみで行う

sakuracloudプロバイダーはルータの帯域変更(とそれに伴うリソースのID変更)に対応しています。 なのでこの方法がもっとも安全と思います。

方法2: 帯域変更後にterraform import / 方法3: ステートの手動変更

再作成の原因はterraform apply時のリフレッシュ処理で帯域変更後のルータの情報がID変更により参照できなくなることが原因です。 これはID変更をTerraform外で行うことでTerraformが新IDを認知できず、ステートに保持している旧IDでルータを参照しようとすることから来ています。

なので、ルータのIDが変更されたことをTerraformのステートに反映すれば再作成を回避できます。

ステートの反映にはterraform importを実行する、または方法3のステートの手動変更などの方法があります。

インポートの場合は以下のように実施します。

$ terraform refresh # 最新の情報を反映(ID変更前のルータ情報はステートから削除される)
$ terraform import sakuracloud_internet.router <現在のルータのID>

方法3はステートをどこに保存しているか、バックエンドの設定はどうなっているかで実施方法が変わります。 バックエンドがローカルの場合はterraform.tfstateファイルを手動で編集といった形です。

運用上問題がなければ方法1を、そうでない場合は方法2がオススメです。

yamatosi commented 5 years ago

ご回答ありがとうございます。 検討させていただきます。 一旦、本件はクローズさせていただきます。