Terraform-provider-aws: Obter erro ao atualizar regras de entrada incorporadas SG com descrição
Oi,
Estou usando o terraform v0.10.8 e o provedor aws 1.1.0 e recebo o seguinte erro ao atualizar as regras de ingresso do grupo de segurança adicionando o campo de descrição.
Consigo atualizar o SG, mas preciso remover todas as regras manualmente. Em seguida, o terraform funciona e atualiza o SG. Quando tento atualizar o SG novamente, o erro acontece.
Este erro não ocorre se o SG não possuir nenhuma regra com campo de descrição.
terraform linha de comando
$ terraform apply -target
=== saída de terraform
Erro: Erro ao aplicar plano:
1 erro (s) ocorreu:
aws_security_group.client-demo-sg-devops: ocorreu 1 erro (s):
aws_security_group. * *: Erro ao revogar as regras de ingresso do grupo de segurança: InvalidPermission.NotFound: A regra especificada não existe neste grupo de segurança.
código de status: 400, id de solicitação: 2bfe24f7-a980-4bbc-a58d-54e5935f57a6
O Terraform não faz rollback automaticamente em caso de erros.
Em vez disso, seu arquivo de estado do Terraform foi parcialmente atualizado com
quaisquer recursos concluídos com sucesso. Por favor, resolva o erro
acima e aplique novamente para alterar gradativamente sua infraestrutura.
takeda-joao
Todos 39 comentários
Esquisito.
Fiz mais alterações, e há um SG que está bem atualizado, com descrição incluída.
Este segundo SG tem o mesmo número de regras de ingresso daquele que obtém o erro e não comete erros quando atualizado.
Fazendo mais testes.
takeda-joao
em 26 out. 2017
Parece que está relacionado ao comprimento do conteúdo do campo de descrição.
Se o comprimento do conteúdo do campo de descrição de todas as regras de ingresso no SG for o mesmo, o erro não ocorre.
takeda-joao
em 26 out. 2017
Potencialmente relacionado? # 1959
bflad
em 26 out. 2017
Não, não é o comprimento.
takeda-joao
em 26 out. 2017
Sim, # 1959 pode estar relacionado.
A partir da segunda execução do terraform aplique, sem alterações, e obtendo erro, notei que está comparando regras com a última regra do grupo de segurança.
Obrigado,
takeda-joao
em 26 out. 2017
@ takeda-joao boa pegada
jaymecd
em 1 nov. 2017
Mesmo problema experimentado aqui.
colin-lyman
em 7 nov. 2017
Acabei de testar o AWS Provider 1.2 e o problema ainda persiste.
colin-lyman
em 7 nov. 2017
Alguma atualização sobre este problema? Eu também estou enfrentando esse problema na minha implementação.
SmaranNA
em 7 dez. 2017
foi corrigido em # 1959 e lançado como parte da v1.3.1
jaymecd
em 7 dez. 2017
Mesmo problema aqui. Aguardando v1.3.1 para testar.
hugohenley
em 7 dez. 2017
Eu acredito que esse problema ainda existe. Eu criei novos grupos de segurança com o terraform e quando eu executo novamente aplico, o terraform reclama
* module.webui.aws_security_group.web: 1 error(s) occurred:
* aws_security_group.web: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in this security group.
status code: 400, request id: 20c88505-d009-42ba-bc30-c0444cef2e94
configurando o sinalizador de rastreamento e observando a chamada do aws, o terraform está passando a descrição errada para o aws:
Action=RevokeSecurityGroupIngress&GroupId=sg-b25012c7&IpPermissions.1.FromPort=3389&IpPermissions.1.IpProtocol=tcp&IpPermissions.1.IpRanges.1.CidrIp=172.16.0.0%2F16&IpPermissions.1.IpRanges.1.Description=RDP&IpPermissions.1.ToPort=3389&Version=2016-11-15
terraform está tentando remover a regra para CIDR 172.16.0.0/16 e descrição RDP , mas a descrição para esse bloco CIDR é na verdade RDP de espaços de trabalho . Existe uma regra para um bloco CIDR separado cuja descrição é RDP
Aqui está um snippet do meu grupo de segurança:
ingress {
description = "RDP"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
}
ingress {
description = "RDP from Workspaces"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["${var.workspaces_cidr_blocks}"]
}
A partir da saída terraform plan , vejo que o terraform pensa que precisa excluir a regra para RDP e criar uma regra para RDP para espaços de trabalho , mas não precisa.
ingress.1615219479.cidr_blocks.#: "1" => "0"
ingress.1615219479.cidr_blocks.0: "172.16.0.0/16" => ""
ingress.1615219479.description: "RDP" => ""
ingress.1615219479.from_port: "3389" => "0"
ingress.1615219479.ipv6_cidr_blocks.#: "0" => "0"
ingress.1615219479.protocol: "tcp" => ""
ingress.1615219479.security_groups.#: "0" => "0"
ingress.1615219479.self: "false" => "false"
ingress.1615219479.to_port: "3389" => "0"
ingress.2147368551.cidr_blocks.#: "0" => "1"
ingress.2147368551.cidr_blocks.0: "" => "172.16.0.0/16"
ingress.2147368551.description: "" => "RDP from Workspaces"
ingress.2147368551.from_port: "" => "3389"
ingress.2147368551.ipv6_cidr_blocks.#: "0" => "0"
ingress.2147368551.protocol: "" => "tcp"
ingress.2147368551.security_groups.#: "0" => "0"
ingress.2147368551.self: "" => "false"
ingress.2147368551.to_port: "" => "3389"
Versão do Terraform:
`` `
Terraform v0.11.1
- provider.aws v1.5.0
- provider.template v1.0.0
- provider.terraform v1.0.2
reznet
em 8 dez. 2017
O problema persiste.
Também estou usando o provider.aws v1.5.0 e torna impossível executar a aplicação a menos que você remova o campo de descrição manualmente (e dos estados do terreno).
takeda-joao
em 8 dez. 2017
Também estou vendo esse problema. Se eu prosseguir e excluir a descrição no console e excluir o campo de descrição no estado tf, o terraform apply será executado. Mas se eu tentar executar a aplicação novamente sem alterar nada, ele falhará.
tsiang
em 13 dez. 2017
@reznet tnx para feedback, confirmado.
Este problema existe apenas ao usar ingress {} ou egress {} blocos de recursos aws_security_group incorporados.
A declaração separada do grupo e das regras funciona conforme o esperado e é a maneira mais preferida de fazê-lo.
resource "aws_security_group" "test" {
name = "test-rules"
description = "test"
}
resource "aws_security_group_rule" "test_rule1" {
type = "ingress"
description = "RDP"
from_port = "3389"
to_port = "3389"
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
security_group_id = "${aws_security_group.test.id}"
}
resource "aws_security_group_rule" "test_rule2" {
type = "ingress"
description = "RDP from Workspaces"
from_port = "3389"
to_port = "3389"
protocol = "tcp"
cidr_blocks = ["170.0.0.0/8"]
security_group_id = "${aws_security_group.test.id}"
}
Podemos mencionar embedded blocks no título do problema? para torná-lo mais concreto?
@radeksimko wdyt?
jaymecd
em 14 dez. 2017
Mesmo problema aqui.
karimodm
em 10 jan. 2018
Vendo isso também.
tf v.0.11.2
aws.provider 1.2.0, mas foi corrigido com aws-provider 1.6.0
MooreDerek
em 11 jan. 2018
A origem do problema foi encontrada - sua estrutura de dados retornada por resourceAwsSecurityGroupIPPermGather ()
Considere o seguinte recurso TF:
resource "aws_security_group" "test" {
name = "test"
ingress {
description = "RDP 11111"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["1.1.1.1/32"]
}
ingress {
description = "RDP 22222"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["2.2.2.2/32"]
}
}
Comparação de estruturas locais / remotas (recolhidas)
LOCAL:
[]interface {}{
map[string]interface {}{
"protocol":"tcp",
"ipv6_cidr_blocks":[]interface {}{},
"self":false,
"description":"RDP 11111",
"from_port":3389,
"cidr_blocks":[]interface {}{"1.1.1.1/32"},
"security_groups":*Set(map[string]interface {}(nil)),
"to_port":3389
},
map[string]interface {}{
"self":false,
"description":"RDP 22222",
"to_port":3389,
"protocol":"tcp",
"security_groups":*Set(map[string]interface {}(nil)),
"from_port":3389,
"cidr_blocks":[]interface {}{"2.2.2.2/32"},
"ipv6_cidr_blocks":[]interface {}{}
}
}
CONTROLO REMOTO:
[]map[string]interface {}{
map[string]interface {}{
"description":"RDP 22222",
"from_port":3389,
"to_port":3389,
"protocol":"tcp",
"cidr_blocks":[]string{"1.1.1.1/32", "2.2.2.2/32"}
}
}
Portanto, a estrutura remota tem apenas 1 item com description de cidr_blocks desanexado, é por isso que ela não pôde ser mapeada corretamente para a estrutura local.
Vou trabalhar na correção nos próximos dias.
jaymecd
em 11 jan. 2018
Qual é a melhor solução para isso, entretanto?
kenske
em 12 jan. 2018
@kenske , use o aws_security_group_rule dedicado
jaymecd
em 13 jan. 2018
É um pouco mais complexo do que pensei antes. @radeksimko @Ninir preciso do seu conselho.
Estrutura de dados de cidr_blocks , ipv6_cidr_blocks , prefix_list_ids & security_groups blocos de resource_aws_security_group.go devem ser atualizados de []string para []map[string]string para manter a descrição junto com o valor do bloco ou para a fatia do novo tipo interno (eu prefiro este):
type sgItem struct {
Value string
Description string
}
wdyt? Tnx
jaymecd
em 16 jan. 2018
alguma atualização?
red97gst
em 31 jan. 2018
@kenske Eu @jaymecd, pois usamos o Terraform para garantir que as regras SG correspondam exatamente ao que está na definição. Não acho que isso seja possível com aws_security_group_rule ou, se for, não consegui encontrar uma maneira de limpar as regras que alguém adicionou manualmente por meio do console / API da AWS.
Eu precisava habilitar a depuração / rastreamento para descobrir exatamente o que estava sendo chamado (e falhando) por meio de RevokeSecurityGroupIngress, então eu defini manualmente a descrição dessas regras na AWS para que da próxima vez que terraform apply tentasse removê-las, ter sucesso. Depois disso, e sem campos de descrição concorrentes, cada terraform plan daquele ponto em diante estava limpo.
ScottSorrentino
em 2 fev. 2018
@ScottSorrentino Foi meio doloroso, mas segui a sugestão de @jaymecd e funcionou. Funcionou até mesmo para o cenário que você está sugerindo, eliminando regras que foram adicionadas manualmente.
kenske
em 2 fev. 2018
Como o caso de negócios para regras inline parece estar faltando, aqui está ele em detalhes.
As declarações de estilo embutido são uma forma de dizer apenas essas regras , enquanto o estilo de recurso separado diz pelo menos essas regras . Do ponto de vista da conformidade, apenas essas regras são um mecanismo de aplicação de políticas , onde pelo menos essas regras apenas garantem que a funcionalidade aprovada esteja presente. Isso tem impactos muito grandes quando chega a hora de uma auditoria.
Quando os auditores nos perguntam:
Descreva como suas regras de firewall são aplicadas por meio do controle de alterações.
O uso do estilo inline nos permite evitar ter que construir um sistema complicado de ingestão de eventos CloudTrail e correlação com nosso sistema de solicitação de mudança para mostrar que apenas as mudanças aprovadas são implementadas e que o desvio de mudança é detectado e alarmado, se não totalmente evitado . Em vez disso, podemos fornecer o log de confirmação para nosso repositório terraform. Os auditores entendem os fluxos de aprovação de git-repos e merge-request. Eles disseram, em essência:
Oh! Como o Puppet, mas para definições de grupo de segurança!
E isso torna todo o processo muito mais fácil . Este é um dos maiores valores agregados que o Terraform oferece em nossa infraestrutura.
sysadmin1139
em 15 mar. 2018
Acabei de abordar esse problema hoje também.
No entanto, no meu caso, onde tenho uma regra como a abaixo
resource "aws_security_group_rule" "DEFAULT_DO_NOT_USE-1" {
type = "ingress"
from_port = 0
to_port = 0
protocol = "-1"
self = "true"
description = "Allow all incoming traffic from withing this security group"
security_group_id = "${aws_security_group.DEFAULT_DO_NOT_USE.id}"
}
Não posso usar aws_security_group_rule como sugerido acima por @jaymecd, pois
Alguma outra solução?
piersf
em 27 mar. 2018
Oi de novo,
Depois de muito brincar com isso, concluí que o problema é ao usar o campo description para uma regra de entrada ou saída e aplicá-lo novamente após a primeira vez. Abaixo, escrevo os passos que me levaram a essa conclusão.
Eu tenho a declaração de recurso abaixo (observe que description está comentado, exceto na primeira entrada):
resource "aws_security_group" "bastion_priv_SG-master" {
name = "bastion_priv_SG-master"
description = "Security group for bastion host"
vpc_id = "${aws_vpc.us_n_virg_VPC-master-10_100_0_0-16.id}"
# incoming
ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["xx.xx.xx.xx/32"]
description = "Allow all incoming traffic from xx.xx.xx.xx/32"
}
ingress {
from_port = 0
to_port = 0
protocol = "-1"
self = "true"
#description = "Allow all incoming traffic from within this SG"
}
ingress {
from_port = 9100
to_port = 9100
protocol = "tcp"
security_groups = ["${data.aws_security_group.app_priv_SG_QAMonitor.id}"]
#description = "Allow all incoming traffic from app_priv_SG_QAMonitor SG"
}
# outgoing
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
#description = "Allow all outgoing traffic from this SG to the Internet"
}
tags {
Name = "bastion_priv_SG-master"
}
}
Aplicar isso na primeira vez funciona bem e vejo as mudanças esperadas no grupo de segurança. Estranhamente, terraform exclui e recria a primeira regra de ingresso. Mas se aplica com sucesso. Abaixo está o resultado da ação aplicar:
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ aws_security_group.bastion_priv_SG-master
ingress.1242592041.cidr_blocks.#: "1" => "0"
ingress.1242592041.cidr_blocks.0: "xx.xx.xx.xx/32" => ""
ingress.1242592041.description: "" => ""
ingress.1242592041.from_port: "0" => "0"
ingress.1242592041.ipv6_cidr_blocks.#: "0" => "0"
ingress.1242592041.protocol: "-1" => ""
ingress.1242592041.security_groups.#: "0" => "0"
ingress.1242592041.self: "false" => "false"
ingress.1242592041.to_port: "0" => "0"
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.502957524.cidr_blocks.#: "0" => "1"
ingress.502957524.cidr_blocks.0: "" => "xx.xx.xx.xx/32"
ingress.502957524.description: "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "" => "false"
ingress.502957524.to_port: "" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "0" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "-1" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "true" => "true"
ingress.753360330.to_port: "0" => "0"
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
ingress.1242592041.cidr_blocks.#: "1" => "0"
ingress.1242592041.cidr_blocks.0: "xx.xx.xx.xx/32" => ""
ingress.1242592041.description: "" => ""
ingress.1242592041.from_port: "0" => "0"
ingress.1242592041.ipv6_cidr_blocks.#: "0" => "0"
ingress.1242592041.protocol: "-1" => ""
ingress.1242592041.security_groups.#: "0" => "0"
ingress.1242592041.self: "false" => "false"
ingress.1242592041.to_port: "0" => "0"
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.502957524.cidr_blocks.#: "0" => "1"
ingress.502957524.cidr_blocks.0: "" => "xx.xx.xx.xx/32"
ingress.502957524.description: "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "" => "false"
ingress.502957524.to_port: "" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "0" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "-1" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "true" => "true"
ingress.753360330.to_port: "0" => "0"
aws_security_group.bastion_priv_SG-master: Modifications complete after 2s (ID: sg-4183373a)
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
Agora, se eu aplicar novamente sem alterar nada nos recursos, ele falhará:
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ aws_security_group.bastion_priv_SG-master
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.2396394866.cidr_blocks.#: "0" => "0"
ingress.2396394866.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
ingress.2396394866.from_port: "0" => "0"
ingress.2396394866.ipv6_cidr_blocks.#: "0" => "0"
ingress.2396394866.protocol: "-1" => ""
ingress.2396394866.security_groups.#: "0" => "0"
ingress.2396394866.self: "true" => "false"
ingress.2396394866.to_port: "0" => "0"
ingress.502957524.cidr_blocks.#: "1" => "1"
ingress.502957524.cidr_blocks.0: "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
ingress.502957524.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "0" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "-1" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "false" => "false"
ingress.502957524.to_port: "0" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "" => "true"
ingress.753360330.to_port: "" => "0"
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.2396394866.cidr_blocks.#: "0" => "0"
ingress.2396394866.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
ingress.2396394866.from_port: "0" => "0"
ingress.2396394866.ipv6_cidr_blocks.#: "0" => "0"
ingress.2396394866.protocol: "-1" => ""
ingress.2396394866.security_groups.#: "0" => "0"
ingress.2396394866.self: "true" => "false"
ingress.2396394866.to_port: "0" => "0"
ingress.502957524.cidr_blocks.#: "1" => "1"
ingress.502957524.cidr_blocks.0: "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
ingress.502957524.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "0" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "-1" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "false" => "false"
ingress.502957524.to_port: "0" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "" => "true"
ingress.753360330.to_port: "" => "0"
Error: Error applying plan:
1 error(s) occurred:
* aws_security_group.bastion_priv_SG-master: 1 error(s) occurred:
* aws_security_group.bastion_priv_SG-master: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in th
status code: 400, request id: 98d8fa95-0aa2-40b8-851d-0a10bb25572b
Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
Onde está o problema ..?
No resultado da segunda ação de aplicação acima, observe a regra de ingresso com o número 2396394866
O Terraform, de alguma forma e de algum lugar, vê uma regra de entrada que tenta excluir e que não existe em nenhum lugar no meu arquivo de estado ou no meu grupo de segurança na AWS. E é por isso que ele reclama que a regra de entrada do grupo de segurança não existe.
Por que e como o Terraform está vendo algo que não existe no .tf ou no arquivo de estado é a questão.
E como se isso não bastasse, não posso sair dessa situação mesmo se eu comentar a descrição da regra de ingresso. Ele ainda falhará com o mesmo erro. E eu suspeito que seja porque o arquivo de estado agora está em um estado inconsistente, uma vez que não faz rollback.
Tenho que excluir manualmente o recurso de grupo de segurança do arquivo de estado, fazer uma atualização, importá-lo de volta e criar uma por uma as regras de entrada e saída sem a descrição.
Realmente não posso dizer onde está o bug aqui, mas sugiro a qualquer pessoa que não forneça uma descrição para as regras de entrada e saída aninhadas, se você não quiser entrar nessa situação.
Estou executando o Terraform v0.11.5
Obrigado,
piersf
em 28 mar. 2018
Peguei isso esta noite. Mesmo que eu comentei a descrição, ele ainda acionou o bug. Somente após excluir completamente a linha as coisas começaram a funcionar como esperado.
Terraform v0.11.5
+ provider.aws v1.13.0
shanemeyers
em 30 mar. 2018
Bug reintroduzido novamente em
`` `
Terraform v0.11.5
Provedor "aws" (1.13.0)
rajbettaswamy
em 4 abr. 2018
O bug foi realmente corrigido? Ainda estou vendo isso também, embora não consiga descobrir como atualizar meu provedor AWS (estou no 1.6 e executando terraform init não faz nada para mudar isso).
ibrahima
em 12 abr. 2018
@ibrahima ainda não viu nenhuma atualização sobre o bug.
Quanto à versão fornecida, tente excluir o arquivo semelhante a .terraform/plugins/linux_amd64/terraform-provider-aws_v1.14.1_x4 que é o que eu tenho e execute init novamente. Isso atualizará a versão do provedor.
piersf
em 12 abr. 2018
Ok, na verdade descobri isso depois de postar o comentário (meio contra-intuitivo, porque a mensagem terraform init diz que instalou a versão mais recente, mas tudo bem). E agora estou tendo mais bugs em vez de menos :(
ibrahima
em 12 abr. 2018
Para atualizar o provedor, você executa terraform init -upgrade .
junkangli
em 12 abr. 2018
Experimentando isso também.
Terraform v0.11.5
+ provider.archive v1.0.3
+ provider.aws v1.11.0
russellsherman
em 12 abr. 2018
Só queria observar que isso também acontece para o recurso aws_default_security_group , onde usar recursos aws_security_group_rule não é uma opção
pmacdougall
em 24 abr. 2018
Eu enfrento um problema semelhante ao atualizar as regras do grupo de segurança, não tem nada a ver com a descrição, parece que o arquivo de estado tf fica fora de sincronia com as regras do grupo de segurança no momento da aplicação, ele primeiro remove / modifica a regra de segurança e depois tenta para adicionar novas propriedades.
$ terraform -version
Terraform v0.11.7
- provider.aws v1.16.0
- provider.null v1.0.0
- provider.random v1.2.0
- provider.template v1.0.0
reza
em 26 abr. 2018
Isso ainda está presente, eu excluí manualmente todas as descrições no aws e executei novamente o script do terraform.
Caspain
em 8 mai. 2018
@Caspain Eu também tive o mesmo problema hoje. Excluir descrições e aplicar novamente funcionou bem
carlosescura
em 9 mai. 2018
Oi pessoal 👋 Desculpe, este é um problema antigo com o provedor AWS. A correção para isso deve estar contida em # 4416, que será lançado com a v1.19.0 do provedor AWS, provavelmente no meio da próxima semana.
Grite para @loivis (e @svanharmelen que enviou um PR anterior, provavelmente correto, que eu devo ter revisado e fundido antes: # 3628)
Visto que havia tantos problemas em torno desse bug, irei bloquear esse problema (entre todos os outros) para encorajar qualquer problema / discussão remanescente a ser totalmente descrito em novos problemas para consolidação. Obrigado pela sua compreensão.
bflad
em 10 mai. 2018
Questões relacionadas
hashibot
·
3Comentários
modax
·
3Comentários
hashibot
·
3Comentários
hashibot
·
3Comentários
ccslamstack
·
3Comentários
Comentários muito úteis
Peguei isso esta noite. Mesmo que eu comentei a descrição, ele ainda acionou o bug. Somente após excluir completamente a linha as coisas começaram a funcionar como esperado.
Terraform v0.11.5
+ provider.aws v1.13.0