地形|对模块使用“ depends_on”时处于“应用”阶段的循环依赖

时间：2018-09-16 11:34:21

标签： module terraform cyclic-dependency

在模块上使用> Task :support:cas-server-support-duo-core:compileJava FAILED FAILURE: Build failed with an exception. * What went wrong: Could not resolve all files for configuration ':support:cas-server-support-duo-core:compileClasspath'. > Could not resolve net.unicon.iam:duo-client:0.2.2. Required by: project :support:cas-server-support-duo-core > Could not resolve net.unicon.iam:duo-client:0.2.2. > Could not get resource 'https://jcenter.bintray.com/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > Could not GET 'https://jcenter.bintray.com/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target > Could not resolve net.unicon.iam:duo-client:0.2.2. > Could not get resource 'https://dl.bintray.com/uniconiam/maven/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > Could not GET 'https://dl.bintray.com/uniconiam/maven/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target > Could not resolve net.unicon.iam:duo-client:0.2.2. > Could not get resource 'https://jcenter.bintray.com/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > Could not GET 'https://jcenter.bintray.com/net/unicon/iam/duo-client/0.2.2/duo-client-0.2.2.pom'. > sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 时，我在terraform apply阶段遇到循环依赖问题。

我遇到的错误是：

depends_on

* Cycle: aws_appautoscaling_policy.queue_depth_based_scale_out_policy, module.my_module.aws_ecs_task_definition.task_definition (destroy), aws_appautoscaling_policy.queue_depth_based_scale_in_policy阶段看起来很好，在plan阶段没有错误。

我试图使用下面的命令来确定图中的循环，

plan

terraform graph -draw-cycles -module-depth=0 -type=plan | dot -Tsvg > graph-plan.svg 图中没有显示周期。 然后，尝试使用{p> 

plan

遗憾的是，此命令无法在图形中显示周期。

幸运的是，我可以使用以下命令在apply阶段图中查看周期，

terraform graph -draw-cycles -module-depth=0 -type=apply  | dot -Tsvg > graph-apply.svg

我的图中的循环看起来像这样，

Graph showing cycle in apply stage

尽管如此，我仍然无法在图形中找出此循环的原因。

此外，似乎问题特别在于在模块上添加apply。 由于我的模块中已经有很少的terraform plan -out tfplan terraform graph -draw-cycles -module-depth=0 tfplan | dot -Tsvg > graph-apply.svg 了，它确实取决于depends_on，而后者取决于aws_appautoscaling_policy，因此最终取决于aws_appautoscaling_target但aws_ecs_service可以完成此工作很好。

有些aws_ecs_task_definition与特定的应用程序特别相关，因此我将它们分别添加（而不是作为模块的一部分），但是由于仅在将服务注册为可扩展目标后才可以添加自动扩展策略，因此我在模块上添加了apply，因为aws_appautoscaling_policy是在模块中定义的。

这是我的模块代码段，

depends_on

这是模块的用法

aws_appautoscaling_target

管道中遵循的步骤是：

resource "aws_ecs_task_definition" "task_definition" {
  family                = "${var.service_name}"
  container_definitions = "${var.container_definitions}"
  task_role_arn         = "${aws_iam_role.task_role.arn}"
  lifecycle {
    create_before_destroy = true
  }
}
resource "aws_ecs_service" "service" {
  name                               = "${var.service_name}"
  cluster                            = "${data.aws_ecs_cluster.ecs_cluster.arn}"
  task_definition                    = "${aws_ecs_task_definition.task_definition.arn}"
  deployment_minimum_healthy_percent = 50
  deployment_maximum_percent         = 100
  lifecycle {
    ignore_changes = ["desired_count"]
  }
}
resource "aws_appautoscaling_target" "ecs_target" {
  max_capacity       = "${var.max_scalabe_capacity}"
  min_capacity       = "${var.min_scalabe_capacity}"
  resource_id        = "service/${var.ecs_cluster_name}/${aws_ecs_service.service.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}
resource "aws_appautoscaling_policy" "cpu_based_scale_in_policy" {
  name               = "${var.service_name}-${var.env}-cpu-based-scale-in-policy"
  policy_type        = "StepScaling"
  resource_id        = "service/${var.ecs_cluster_name}/${var.service_name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
  step_scaling_policy_configuration {
    adjustment_type         = "ChangeInCapacity"
    cooldown                = "${var.scale_in_cooldown_period}"
    metric_aggregation_type = "Average"
    step_adjustment {
      metric_interval_upper_bound = "${var.scale_in_step_adjustment_upper_bound}"
      scaling_adjustment          = "${var.scale_in_step_adjustment_scaling_adjustment}"
    }
  }
  depends_on = ["aws_appautoscaling_target.ecs_target"]
}

很乐意了解这个周期背后的原因吗？

要强调的另一点是，当我们仅module "my_module" { source = "GIT_URL_FOR_MODULE" VARIABLES_AS_NEEDED_BY_MODULE } resource "aws_appautoscaling_policy" "queue_depth_based_scale_in_policy" { name = "${local.service_name}-${local.env}-queue-scale-in-policy-new" policy_type = "StepScaling" resource_id = "service/${local.ecs_cluster_name}/${local.service_name}" scalable_dimension = "ecs:service:DesiredCount" service_namespace = "ecs" step_scaling_policy_configuration { adjustment_type = "ChangeInCapacity" cooldown = "${local.queue_scale_in_cooldown_period}" metric_aggregation_type = "Average" step_adjustment { metric_interval_upper_bound = "${local.queue_scale_in_step_adjustment_upper_bound}" scaling_adjustment = "${local.queue_scale_in_step_adjustment_scaling_adjustment}" } } depends_on = ["module.my_module"] } 并从头开始重新创建时，terraform get -update=true terraform init terraform taint -allow-missing -module=${MODULE_NAME} aws_ecs_task_definition.task_definition terraform plan -out tfplan -input=false terraform apply -input=false tfplan 就成功了。仅当我terraform apply执行任务定义并在扩展策略中进行了一些更新（位于模块外部）时，才会观察到该周期。

注意：在我的管道中，我确实污染了以前的任务定义，以确保立即使用新的任务定义启动服务，否则，将不会立即使用新的任务定义来推出任务。

1 个答案:

答案 0 :(得分：0)

我设法摆脱了循环依赖。 这是使用的方法，

我没有依赖整个模块，而是在模块中添加了aws_appautoscaling_target的输出。 然后，我只是在缩放策略中使用此输出，以确保创建了隐式依赖性。

这是示例代码，

模块

resource "aws_ecs_task_definition" "task_definition" {
  family                = "${var.service_name}"
  container_definitions = "${var.container_definitions}"
  task_role_arn         = "${aws_iam_role.task_role.arn}"
  lifecycle {
    create_before_destroy = true
  }
}
resource "aws_ecs_service" "service" {
  name                               = "${var.service_name}"
  cluster                            = "${data.aws_ecs_cluster.ecs_cluster.arn}"
  task_definition                    = "${aws_ecs_task_definition.task_definition.arn}"
  deployment_minimum_healthy_percent = 50
  deployment_maximum_percent         = 100
  lifecycle {
    ignore_changes = ["desired_count"]
  }
}
resource "aws_appautoscaling_target" "ecs_target" {
  max_capacity       = "${var.max_scalabe_capacity}"
  min_capacity       = "${var.min_scalabe_capacity}"
  resource_id        = "service/${var.ecs_cluster_name}/${aws_ecs_service.service.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}
resource "aws_appautoscaling_policy" "cpu_based_scale_in_policy" {
  name               = "${var.service_name}-${var.env}-cpu-based-scale-in-policy"
  policy_type        = "StepScaling"
  resource_id        = "service/${var.ecs_cluster_name}/${var.service_name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
  step_scaling_policy_configuration {
    adjustment_type         = "ChangeInCapacity"
    cooldown                = "${var.scale_in_cooldown_period}"
    metric_aggregation_type = "Average"
    step_adjustment {
      metric_interval_upper_bound = "${var.scale_in_step_adjustment_upper_bound}"
      scaling_adjustment          = "${var.scale_in_step_adjustment_scaling_adjustment}"
    }
  }
  depends_on = ["aws_appautoscaling_target.ecs_target"]
}
output "scalable_target_id" {
  value = "${aws_appautoscaling_target.ecs_target.id}"
}

请注意模块中添加的输出代码块。 这是模块的用法，在扩展策略名称中消耗模块的输出。

module "my_module" {
  source = "GIT_URL_FOR_MODULE"
  VARIABLES_AS_NEEDED_BY_MODULE
}
resource "aws_appautoscaling_policy" "queue_depth_based_scale_in_policy" {
  name               = "${local.service_name}-${local.env}-queue-scale-in-policy-new-${module.my_module.scalable_target_id}"
  policy_type        = "StepScaling"
  resource_id        = "service/${local.ecs_cluster_name}/${local.service_name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
  step_scaling_policy_configuration {
    adjustment_type         = "ChangeInCapacity"
    cooldown                = "${local.queue_scale_in_cooldown_period}"
    metric_aggregation_type = "Average"
    step_adjustment {
      metric_interval_upper_bound = "${local.queue_scale_in_step_adjustment_upper_bound}"
      scaling_adjustment          = "${local.queue_scale_in_step_adjustment_scaling_adjustment}"
    }
  }      
}

尽管如此，我仍然无法弄清楚为什么循环首先出现。

相关问题
最新问题