Запуск Terraform AWS & EMR: проблема уничтожения VPC

Question

У меня есть проект Terraform, в котором используются VPC, корзины, лямбды и базы данных. Один из моих лямбда-серверов создает кластер EMR, используя библиотеку Python boto3.

s3 = boto3.client('s3')
session = boto3.session.Session()
client = session.client('emr', region_name=os.environ['region'])
job_id = client.run_job_flow(
            Name=os.environ['emr_name'],
            LogUri=os.environ['log_dir'],
            Instances={
                'MasterInstanceType': os.environ['master_instance'],
                'SlaveInstanceType': os.environ['slave_instance'],
                'InstanceCount': int(os.environ['slave_instances_count']),
                'Ec2SubnetId': os.environ['ec2_subnet_id']
            },
            ReleaseLabel='emr-5.13.0',
            Applications = [
                {'Name': 'Hadoop'},
                {'Name': 'Hive'},
                {'Name': 'Spark'}
            ],
            Steps=[
              my steps...
            ],
            BootstrapActions=[
                 ...
            ],
            ServiceRole='EMR_DefaultRole',
            JobFlowRole='EMR_EC2_DefaultRole',
            VisibleToAllUsers=True
        )

Все работает хорошо, я доволен.

Но когда я иду на terraform destroy команда не удаляет созданный VPC Terraform (не работает по таймауту).

Я думаю, это связано с двумя группами безопасности, созданными для запуска EMR. Terraform не знает о них и, следовательно, не может удалить VPC, потому что 2 SG находятся в этом VPC.

Взглянув на веб-консоль AWS, я вижу 2 SG:

sg-xxxxxxx
ElasticMapReduce-slave
eouti-vpc
Slave group for Elastic MapReduce created on <date>

sg-xxxxxxx
ElasticMapReduce-master
eouti-vpc
Master group for Elastic MapReduce created on <date>

Как я могу решить это? Должна ли Terraform создавать эти SG? Что бы вы посоветовали?

ура

Answer 1

При создании Terraform, который взаимодействует с другими компонентами (например, с помощью прямых вызовов API или другого запускающего Terraform совместного использования информации с terraform_remote_state), вы должны знать о зависимостях между различными компонентами. Это искусство определения места разделения, очень похожее на написание других типов программного обеспечения.

В документации для run_job_flow(**kwargs) выглядит, что вы можете передать несколько типов групп безопасности:

'EmrManagedMasterSecurityGroup': 'string',
'EmrManagedSlaveSecurityGroup': 'string',
'ServiceAccessSecurityGroup': 'string',
'AdditionalMasterSecurityGroups': [
    'string',
],
'AdditionalSlaveSecurityGroups': [
    'string',
]

Я не уверен, как эти группы безопасности создаются для вас сейчас (в документах не упоминается создание временных групп безопасности, и странно, что если бы они это сделали, их потом оставили бы без дела), но это логично сделать все ваши сети в Terraform, а затем вывести эти идентификаторы для использования вашей лямбда. Это метод, упомянутый krishna_mee2004.

Мне это нравится, потому что он инкапсулирует сетевую инфраструктуру в одном месте (Terraform) и имеет четкие входы / выходы для кода, который использует этот ресурс (ваш run_job_flow Lambda).

Кажется, что нет необходимости создавать временные группы безопасности, но если бы вы это сделали, я бы создал / уничтожил их в ботах вокруг вашего существующего кода. Это зависит от того, считаете ли вы, что группы безопасности являются частью сетевой инфраструктуры или частью работы. Это должно указывать, где вы их создаете / уничтожаете.