Ошибка отправки команды SSM в экземпляр EC2

Я пытаюсь использовать boto3 для запуска ssh-команд на экземплярах EC2. Я читал это руководство: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-remote-commands.html и я сделал все, что они там написали, но я продолжаю получать сообщение об ошибке:

>>>import boto3
>>> ec2 = boto3.client('ssm')
>>> a = ec2.send_command(InstanceIds=['i-0d5e16f6'], DocumentName='AWS-RunShellScript', Comment='abcdabcd', Parameters={"commands":["ifconfig"]})

выход:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/botocore/client.py", line 253, in _api_call
  return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python2.7/dist-packages/botocore/client.py", line 543, in _make_api_call
  raise error_class(parsed_response, operation_name)
  botocore.errorfactory.InvalidInstanceId: An error occurred (InvalidInstanceId) when calling the SendCommand operation:

Если я пытаюсь отправить команду с awscli, я получаю ту же проблему:

aws ssm send-command --instance-ids "i-0d5e16f6" --document-name "AWS-RunShellScript" --comment "IP config" --parameters commands=ifconfig --output text

An error occurred (InvalidInstanceId) when calling the SendCommand operation:

кто-нибудь знает, как его решить?

8
amazon-web-services instances python ssm

2 ответов

Это может произойти, когда у вас нет агент SSM установлен на экземпляре, к которому вы пытаетесь получить доступ. Для списка экземпляров, в которых можно запускать команды SSM, выполните:

aws ssm describe-instance-information --output text

оттуда, вы можете получить идентификатор экземпляра, а затем запустить с этим экземпляром.

8

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

принятый ответ aws ssm describe-instance-information проверяет экземпляры, которые оба доступны, в допустимом состоянии и имеют установленный агент SSM, так что охватывает несколько шагов устранения неполадок в одной строке (nice ;) ).

если вы используете boto3 то же самое может быть достигнуто с:

ssm.client.describe_instance_information()

Я не уверен, проверяет ли он разрешения, но предполагать так. Если ваши instance_id отсутствует в списке, вы можете обеспечить правильные разрешения, следуя шаг за шагом здесь.

однако, есть еще одна причина (последнее, но не менее как это не очевидно):

недавно созданные экземпляры занимают некоторое время, чтобы появиться в describe_instance_information список.

Это даже после ожидания для экземпляра для завершения пост-создания. Так пример выполнения:

    # Key names are the same as the keyword arguments required by boto
    params = {
            'ImageId': image_id_to_use,
            'InstanceType': instance_type_to_launch,
            'MinCount': 1,
            'MaxCount': 1,
            'UserData': user_data_script,
            'SecurityGroups': ['your groups'],
            'KeyName': 'yourkeyname',
          }

    # Run the instance and wait for it to start
    reservation = ec2.client.run_instances(**params)
    instance = ec2.resource.Instance(reservation['Instances'][0]['InstanceId'])
    instance.wait_until_running()

    # Also wait status checks to complete
    waiter = ec2.client.get_waiter('instance_status_ok')
    waiter.wait(InstanceIds=[instance.id])

    # Apply the IAM roles required (this instance will need access to, e.g., S3)
    response = ec2.client.associate_iam_instance_profile(
        IamInstanceProfile={
            'Arn': 'your_arn',
            'Name': 'ApplicableRoleEGAdministratorAccess'
        },
        InstanceId=instance.id
    )

    print('Instance id just created:', instance.id)
    print('Instances in the SSM instances list right now:')
    print(ssm.client.describe_instance_information()['InstanceInformationList'])

будет осветить эту проблему (если это конечно было для меня).

этой мая из-за времени, необходимого для выполнения сценария UserData (см. это сообщение SO для обсуждения, возможно, связанного с ожиданием завершения пользовательских данных), но я не могу сказать (без больших усилий, чем я готов принять!) будь то это, или просто время, присущее AWS для обновления своей базы данных сервисов.

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

3