2017-04-12 2 views
2

테스트 할 때와 cloudwatch 규칙을 통해 수동으로 cron 작업을 만들 때 잘 작동하는 AWS 람다를 만들었습니다.신뢰할 수있는 Cloudwatch 규칙이 ​​실패한 호출을보고합니다.

메트릭을 호출 (실패하지 않음)로보고하고 실행에 대한 세부 정보를 기록합니다.

그런 다음 수동으로 생성 한 클라우드 워치 규칙을 제거하여 책임감있게 만들 것을 결정했습니다.

- name: Create lambda service. 
    lambda: 
     name: "{{ item.name }}" 
     state: present 
     zip_file: "{{ item.zip_file }}" 
     runtime: 'python2.7' 
     role: 'arn:aws:iam::12345678901:role/lambda_ecr_delete' 
     handler: 'main.handler' 
     region: 'eu-west-2' 
     environment_variables: "{{ item.env_vars }}" 
    with_items: 
     - name: lamda_ecr_cleaner 
     zip_file: assets/scripts/ecr-cleaner.zip 
     env_vars: 
      'DRYRUN': '0' 
      'IMAGES_TO_KEEP': '20' 
      'REGION': 'eu-west-2' 
    register: new_lambda 

    - name: Schedule a cloudwatch event. 
    cloudwatchevent_rule: 
     name: ecr_delete 
     schedule_expression: "rate(1 day)" 
     description: Delete old images in ecr repo. 
     targets: 
     - id: ecr_delete 
      arn: "{{ item.configuration.function_arn }}" 
    with_items: "{{ new_lambda.results }}" 

거의 동일한 cloudwatch 규칙을 생성합니다. 수동으로 생성 된 것으로 볼 수있는 유일한 차이점은 대상에 있습니다. 람다 버전/별칭은 버전으로 설정되어있는 동안 수동으로 생성 될 때 기본값으로 설정되고, 가능한 버전으로 생성되면 해당 버전 번호가 사용됩니다.

무언가로 만든 cloudwatch 규칙은 실패한 호출 만 있습니다.

이유가 무엇인가요? 로그가 보이지 않습니다. 해당 버전을 cloudwatchevent_rule 모듈과 함께 Default로 설정할 수있는 방법이 있습니까?

+0

이것을 해결 했습니까? 비슷한 문제가 발생했습니다. 가능한 창조는 성공하지만 사건은 실패합니다. 편집하고 이벤트 규칙 (변경 없음)을 저장하면 작업을 시작합니다 ... – apines

+0

아니요. 해결책을 찾지 못했습니다. 제발 찾으면 알려주세요. – Bastian

답변

4

너무 많은 시간, 동일한 오류 및 동일한 혼동 (실패한 인보 케이션에 대한 로그가없는 이유는 무엇입니까?)을 해결하기 위해 "솔루션"을 공유하려고합니다. " 누군가에게 도움을주고, 다른 사람들이 디버깅하고 궁극적 인 해결책을 찾도록 도울 것입니다.

참고 : 수동으로 규칙 목표를 작성하여 함수를 호출 가지고 있기 때문에주의 하시고,이 모든 AWS 계정이 람다 함수

실행이 허용 될 수 있습니다, 당신이 CloudWatch에서의 람다에 호출 권한을 추가 가정 그러나 이벤트가 cli/api에 의해 만들어지고 AWS 대시 보드/콘솔에 의해 만들어지는 경우 소스 계정 ID가 다른 것처럼 보입니다.

원본 계정의 조건을 주체 " events.amazonaws.com "을 사용하면 모든 AWS 계정이 람다를 실행하지 못하도록 막을 수 있습니다 (귀하의 책임하에 !).

그래서, 당신의 람다 정책은 다음과 같습니다 경우 :

{ 
    "Sid": "<sid>", 
    "Effect": "Allow", 
    "Principal": { 
     "Service": "events.amazonaws.com" 
    }, 
    "Action": "lambda:InvokeFunction",, 
    "Condition": { 
     "StringEquals": { 
      "AWS:SourceAccount": "<account-id>" 
     } 
    }, 
    "Resource": "arn:aws:lambda:<region>:<account-id>:function:<lambda-function>" 
} 

는 "상태"필드

{ 
    "Sid": "sid", 
    "Effect": "Allow", 
    "Principal": { 
     "Service": "events.amazonaws.com" 
    }, 
    "Action": "lambda:InvokeFunction",, 
    "Resource": "arn:aws:lambda:<region>:<account-id>:function:<lambda-function>" 
} 

그리고 "어쩌면"당신을 위해 작동을 제거합니다.

cli/api ... 이벤트가 생성 될 때 cloudwatch 이벤트 소유자/작성자 데이터로 인해 이상하게 보입니다. 아마도 버그일까요? 확실하지 않다. 나는 그것에 대해 계속 연구 할 것입니다.

+0

놀라운. 그걸로 몇 시간을 잃어 버렸습니다. 우리는 람다 함수에 대해 다양한 유형의 트리거를 생성 해 왔으며 AWS : SourceAccount를 포함하여 모든 함수가 작동했습니다. 이벤트가 다른 것 같습니다. 나는 그들이 다른 계정에서 비롯된 것 같아요. 스케줄러 자체는 자체 AWS 계정에서 실행되지 않을 수 있습니다. –

+0

정확히. AWS : SourceAccount 조건을 포함하여 람다 함수에 대해 S3 트리거를 작성했지만 대시 보드를 실행하면 aws-cli로 작성된 CloudWatch 이벤트가 작동하지 않습니다.나는 이벤트 소유자가 api에 의해 만들어 질 때 올바르게 정의되지 않았다고 생각한다. – ProtheanTom