Node-red용 커스텀 모듈 수동 등록하기

최근 Node-red로 이런 저런 flow를 만들어 보면서 프로젝트를 진행 중입니다.

node-red가 가진 장점은 부가 모듈 (흔히 node-red-contrib으로 시작하는)을 런타임에 npm 리파지토리로부터 설치해서 사용할 수 있다는 것입니다.

Node-RED Library 페이지를 보면 node-red에서 사용할 수 있는 다양한 모듈들을 검색해 볼 수 있습니다.

Node-red의 Twitter 노드를 이용하여 특정 해쉬태그가 포함된 트윗을 가져오는 flow를 만들었는데

가져온 트윗의 내용을 file로 저장하고 그 파일을 spark로 분석하려는 목적이었습니다.

그런데 단일 파일에 모든 트윗 내용을 저장하면 파일 크기 문제도 있고 날짜 별로 트윗을 구분하기 힘들어서
(아직 검증안된 프로세스여서 다른 저장소없이 우선 그냥 파일로 저장하려고 했습니다)

daily rotate log 모듈이 필요했는데 없더군요.

node-red는 node-red용 부가 모듈을 직접 제작하여 연결할 수 있고 그에 대한 가이드 문서를 제공하고 있습니다.

처음 부가 모듈을 제작하는 것이 때문에 가장 유사한 모듈(node-red-contrib-advance-logger)을 찾아서 fork해서 약간 수정하였고 NPM 리파지토리에 publish하였습니다. (그러고보니 첫 번째 npm publish네요)

문제는 NPM 리파지토리에 public 모듈로 배포만하면 node-red UI에서 바로 검색이 될 줄 알았는데 아니더군요
(나중에 알았지만 관련 내용을 github에 gist 형태로 작성해서 node-red 사이트에서 추가할 수 있도록 연결해 줘야 하는 듯 합니다)

결국 제가 만든 모듈이 있다고 node-red 서버에 수동으로 알려줘야 하는데

node-red의 REST API를 이용해서 제가 만든 모듈이 검색되도록 할 수 있었습니다.

node-red의 REST API Admin API중에 /nodes endpoint로 아래와 같은 내용으로 POST 요청을 하면 node-red 서버에서 모듈을 인식합니다. (예 : http://localhost:9000/nodes)
(GET으로 요청하면 설치된 모듈의 목록을 가져옵니다.)

{
"module": "node-red-contrib-rotate-logger"
}

AWS 람다 함수 관리 툴 – APEX (6)

dry-run으로 미리보기

Apex는 어떤 오퍼레이션에서도 --dry-run 플래그를 통해 AWS 반영없이 미리 결과를 확인해 볼 수 있습니다.

Notation

Dry run은 아래 심볼을 사용하여 리소스의 미래 상태를 표현합니다.

  • + 리소스는 생성될 것입니다.
  • - 리소스는 삭제될 것입니다.
  • ~ 리소스는 업데이트 될 것입니다.

예제

예를 들어 여러분이 foo, bar 함수를 작성했고, 아직 한 번도 배포한 적이 없다면 아래와 같은 응답을 보게 될 것입니다. 아래 아웃풋은 AWS에 전송되는 최종 요청을 나타냅니다. 충돌을 방지하기 위해 함수의 이름에 prefix를 붙이고 current 릴리즈 앨리어스를 유지하기 위해 추가 앨리어스를 붙이는 내용을 볼 수 있습니다.

$ apex deploy --dry-run

  + function testing_bar
    handler: _apex_index.handle
    runtime: nodejs
    memory: 128
    timeout: 5

  + alias testing_bar
    alias: current
    version: 1

  + function testing_foo
    memory: 128
    timeout: 5
    handler: _apex_index.handle
    runtime: nodejs

  + alias testing_foo
    alias: current
    version: 1

apex deploy foo 명령어를 실행한 후 apex deploy --dry-run 명령어를 실행했다면 아래와 같이 bar 함수만 디플로이된다는 내용을 확인할 수 있습니다.

Apex는 함수의 hash 값이 배포된 함수와 동일하면 배포하지 않습니다.

$ apex deploy --dry-run

  + function testing_bar
    runtime: nodejs
    memory: 128
    timeout: 5
    handler: index.handle

  + alias testing_bar
    alias: current
    version: 1

유사한 방법으로 설정이 변경된 부분을 미리 확인하는데도 사용할 수 있습니다.

$ apex deploy --dry-run

  ~ alias testing_foo
    alias: current
    version: $LATEST

  ~ config testing_foo
    memory: 128 -> 512
    timeout: 5 -> 10

아래는 함수 delete에 대한 preview입니다.

$ apex delete --dry-run -f

  - function testing_bar

  - function testing_foo

환경 변수

Apex는 KMS를 통해 암호화된 새로운 네이티브 AWS Lambda 환경 변수를 지원합니다. 이러한 변수를 설정하는 방법은 여러가지가 있는데 살펴보도록 합시다

-set 플래그

-s, --set 플래그는 함수 런타임에 노출되는 환경 변수를 설정하는데 사용됩니다. 예를 들어 node.js 환경에서의 process.env.NAME이나 go 언어에서의 os.Getenv("NAME")같은 값들을 말합니다. 이 플래그는 여러 번 설정할 수 있습니다.

예를 들어 여러분이 Loggly 로그 수집기를 사용하고 수집기 사용을 위해 API 토큰을 설정해야 한다면 아래와 같이 설정할 수 있습니다.

$ apex deploy -s LOGGLY_TOKEN=token log-collector

-env-file 플래그

-E, --env-file 플래그를 사용하여 여러 환경 변수를 담고 있는 JSON 파일을 반영할 수 있습니다.

$ apex deploy --env-file /path/to/env.json
// Sample env.json
{
  "LOGGLY_TOKEN": "12314212213123"
}

설정 파일 (project.json 혹은 function.json)

project.json 혹은 function.json 파일에 환경 변수를 설정하는 것도 가능합니다.

하지만 설정값은 반드시 string 타입이어야 합니다.

{
  "environment": {
    "LOGGLY_TOKEN": "12314212213123"
  }
}

우선 순위

적용 우선 순위는 아래와 같습니다.

  1. -s, --set 플래그
  2. -E, --env-file 플래그
  3. project.json 혹은 function.json 파일에 설정된 환경 변수 값

파일 무시(omitting)하기

부가적으로 .apexignore 파일을 프로젝트 루트나 특정 함수 디렉토리에 배치할 수 있으며 gitignore 파일과 동일한 패턴을 사용하여 파일을 무시할 수 있습니다. 기본적으로 .apexignore, function.json 파일은 무시됩니다.

무시된다 == 람다 함수 패키징 과정에서 포함되지 않는다

( 나머지 내용은 딱히 중요하지 않아서 번역하진 않겠습니다 ^^)

AWS 람다 함수 관리 툴 – APEX (5)

부끄러운 번역이지만 AWS 주간 소식 모음에 APEX 글이 링크되었습니다 🙂

로그 확인

Apex는 함수의 출력 로그를 보기 위해 CloudWatch Logs와 연동됩니다. apex logs에 함수의 이름이 지정되지 않으면 기본적으로 모든 함수의 로그가 표시됩니다. 로그 히스토리의 시간 범위를 지정할 수도 있고 (기본값: 5분) 아래와 같이 결과를 필터링할 수도 있습니다.

예제

최근 5분간 모든 함수의 로그 확인하기

$ apex logs

uppercase, lowercase 함수의 로그 확인하기

$ apex logs uppsercase lowercase

모든 함수의 로그를 추적(follow)하기 (tail처럼 보기)

$ apex logs -f

특정 함수의 로그 추적하기

$ apex logs -f foo

최근 1시간의 로그 보기

$ apex logs --since 1h
$ apex logs -s 1h

auth로 시작하는 모든 함수의 로그 보기

$ apex logs auth*

성능 지표(Metrics) 보기

apex metrics 명령어는 주어진 시간 동안의 함수의 실행 횟수, 총 실행 시간, 스로틀링, 에러에 대한 지표를 표시합니다.

예제

최근 24시간 동안의 모든 함수에 대한 성능 지표 보기

$ apex metrics

uppercase
  invocations: 1242
  duration: 65234ms
  throttles: 0
  error: 0

lowercase
  invocations: 1420
  duration: 65234ms
  throttles: 0
  error: 5

최근 15분동안의 지표보기

$ apex metrics --since 15m

uppercase
  invocations: 16
  duration: 4212ms
  throttles: 0
  error: 0

lowercase
  invocations: 23
  duration: 5200ms
  throttles: 0
  error: 5

인프라스트럭처 관리하기

Apex는 인프라스트럭쳐 관리를 위해 Terraform과 연동합니다. Apex는 현재 람다 함수에 대한 관리 기능만을 제공하고 있기 때문에 Lambda resource 같은 추가적인 자원을 Terraform이나 Cloudformation을 이용하여 관리하고 싶을 수 있습니다.

인프라스트럭쳐 관리

apex infra 명령어는 terraform 명령어에 대한 wrapper 입니다. Apex는 다수의 변수를 제공하고 복수의 Terraform 환경을 구성하는데 도움을 줍니다.

./infrastructure 디렉토리에 prodstage같은 환경이 존재한다면 아래와 같을 것입니다.

infrastructure/
├── prod
│   └── main.tf
├── stage
│   └── main.tf

예를 들어 apex infra --env prod plan 명령어는 아래 명령어와 동일한 일을 수행하면서 Apex에 설정된 여러 정보들을 여러가지 -var 플래그를 통해 전달해줍니다.

$ cd infrastructure/prod && terraform plan

환경에 대한 이름은 --env 플래그에 설정하거나 설정하지 않는다면 project.json에 설정된 defaultEnvironment 값이 사용됩니다.

Terraform 변수

현재 Terraform에 공개된 변수는 다음과 같습니다.

  • aws_region : us-west-2와 같은 AWS의 리전 명
  • apex_environment : prodstage같은 환경 명
  • apex_function_role : 람다 롤의 ARN
  • apex_function_arns : 모든 람다 함수의 ARN 매핑 정보
  • apex_function_names : 모든 람다 함수의 이름 매핑 정보

참고 사항

  • current라는 앨리어스가 참조되었다는 것을 지정하기 위해서는 ${apex_function_myfunction}:current를 명시적으로 할당해야 합니다.
  • apex_function_name 변수는 apex deploy를 통해 최소 1번은 배포되어야 참조할 수 있습니다.

AWS 람다 함수 관리 툴 – APEX (4)

함수 빌드하기

Apex는 배포를 위해 Zip 파일을 생성합니다. 그러나 가끔은 디버그를 위해서 zip 파일 내부에 어떤 내용들이 포함되어 있는지 확인하는 것이 유용할 수 있습니다. apex build 명령은 zip 파일을 생성하고 그 과정을 표준 출력 (STDOUT)으로 보냅니다.

예제

함수를 빌드해서 out.zip로 만들기

$ apex build foo > out.zip

이전 버전으로 되돌리기

함수의 버전을 이전 버전 혹은 특정 버전으로 되돌릴 수 있습니다.

예제

바로 이전 버전으로 되돌리기

$ apex rollback foo

특정 버전으로 되돌리기

$ apex rollback foo 5

--dry-run 플래그로 롤백 미리 보기

$ apex rollback --dry-run lowercase

~ alias testing_lowercase
 alias: current
 version: 2

$ apex rollback --dry-run uppercase 1

~ alias testing_uppercase
 version: 1
 alias: current

버전에 앨리어스 지정하기

aliax 명령어로 하나 혹은 그 이상의 함수 버전에 앨리어스를 설정할 수 있습니다.

예제

모든 함수의 앨리어스를 prod로 설정

$ apex alias prod

api_로 시작하는 이름을 가진 모든 함수의 앨리어스를 prod로 설정

$ apex alias prod api_*

버전이 5인 모든 함수의 앨리어스를 prod로 설정

$ apex alias -v 5 prod

특정 함수의 앨리어스를 stage로 설정

$ apex alias stage myfunction

특정 함수의 버전 10의 앨리어스를 stage로 설정

$ apex alias -v 10 stage myfunction

앨리어스가 dev인 특정 함수의 앨리어스를 stage로 변경 (dev에서 stage로 승격)

$ apex alias stage dev myfunction

함수 훅 (Function hooks)

Apex는 함수의 생명 주기에 맞춰 shell command가 실행될 수 있게 hook 개념을 지원합니다. 예를 들어 이런 hook은 배포하기 전에 문법 체크 (lint)나 테스트를 실행하도록 할 수 있으며 Babel, CoffeeScript 등의 트랜스 파일에도 연결될 수 있습니다.

Hook은 project.json 파일에 설정하며 Hook은 함수 디렉토리에서 실행됩니다. 만약 hook의 실행 결과 응답 코드가 0보다 크면 Apex는 실행을 중단하고 에러를 표시할 것입니다.

Hook 지원

  • build -> zip 파일로 함수를 빌드하기 전에 실행 (바이너리로 컴파일하거나 소스 코드의 트랜스폼에 이용)
  • deploy -> 함수가 배포되기 전에 실행 (테스트, lint 등에 이용)
  • clean -> 함수가 배포되고 난 후에 실행된다 (빌드 결과물 정리 등에 이용)

예제

아래 예제는 Apex 내부적으로 Golang 지원을 위해 설정된 hook의 내용입니다.

{
    "hooks": {
        "build": "GOOS=linux GOARCH=amd64 go build -o main main.go",
        "clean": "rm -f main"
    }
}

AWS 람다 함수 관리 툴 – APEX (3)

함수 배포하기

하나 혹은 그 이상의 함수를 배포하기 위해서 필요한 것은 apex deploy 명령어가 전부입니다. Apex의

배포는 멱등성(idempotent)을 갖습니다. 각 함수에 대한 빌드 결과가 생성되면 Apex는 Checksum을 확인하고 이미 배포된 함수와 비교해서 동일하면 배포하지 않습니다.

배포가 끝난 후 Apex는 기존 함수의 오래된 버전을 체크해서 몇 개(retainedVersion에 설정된 수만큼)만 남기고 삭제합니다.

특정 함수만 배포하고 싶다면 apex deploy 뒤에 함수 이름을 지정하면 됩니다. 함수 이름 인자는 deploy, logs, rollback 명령어에서도 사용할 수 있습니다.

예제

현재 디렉토리의 모든 함수를 배포합니다

$ apex deploy

~/dev/myapp 디렉토리에 있는 모든 함수를 배포합니다.

$ apex deploy -C ~/dev/myapp

특정 함수만 배포합니다.

$ apex deploy auth api

auth로 시작하는 모든 함수를 배포합니다.

$ apex deploy auth*

_reporter로 끝나는 모든 함수를 배포합니다.

$ apex deploy *_reporter

함수 실행하기

Apex로 command line에서 함수를 실행할 수 있으며 JSON 이벤트나 혹은 표준 입력 (STDIN) 스트림을 함께 전달할 수 있습니다. 주의할 점은 invoke 명령은 리모트의 람다를 직접 실행하는 것이며 로컬의 함수를 실행하는 것이 아닙니다. 함수는 가장 최신 버전이 실행됩니다.

예제

이벤트 없이 함수 실행하기

$ apex invoke collect-stats

JSON 이벤트를 전달해서 실행하기

$ echo -n '{ "value": "Tobi the ferret" }' | apex invoke uppercase
{ "value": "TOBI THE FERRET" }

파일의 내용으로 실행하기

$ apex invoke uppercase < event.json

클립보드의 내용을 표준 입력으로 전달하여 함수 실행하기

$ pbpaste | apex -C path/to/project invoke auth

phony를 이용해서 데이터를 생성한 후 여러 리퀘스트를 생성하여 함수 실행하기

$ echo -n '{ "user": "{{name}}" }' | phony | apex invoke uppercase
{"user":"DELMER MALONE"}
{"user":"JC REEVES"}
{"user":"LUNA FLETCHER"}
...

스트리밍으로 함수를 실행하고 로그를 출력하기

$ echo -n '{ "user": "{{name}}" }' | phony | apex invoke uppercase --logs
START RequestId: 30e826a4-a6b5-11e5-9257-c1543e9b73ac Version: $LATEST
END RequestId: 30e826a4-a6b5-11e5-9257-c1543e9b73ac
REPORT RequestId: 30e826a4-a6b5-11e5-9257-c1543e9b73ac  Duration: 0.73 ms   Billed Duration: 100 ms     Memory Size: 128 MB Max Memory Used: 10 MB
{"user":"COLTON RHODES"}
START RequestId: 30f0b23c-a6b5-11e5-a034-ad63d48ca53a Version: $LATEST
END RequestId: 30f0b23c-a6b5-11e5-a034-ad63d48ca53a
REPORT RequestId: 30f0b23c-a6b5-11e5-a034-ad63d48ca53a  Duration: 2.56 ms   Billed Duration: 100 ms     Memory Size: 128 MB Max Memory Used: 9 MB
{"user":"CAROLA BECK"}
START RequestId: 30f51e67-a6b5-11e5-8929-f53378ef0f47 Version: $LATEST
END RequestId: 30f51e67-a6b5-11e5-8929-f53378ef0f47
REPORT RequestId: 30f51e67-a6b5-11e5-8929-f53378ef0f47  Duration: 0.22 ms   Billed Duration: 100 ms     Memory Size: 128 MB Max Memory Used: 9 MB
{"user":"TOBI FERRET"}
...

함수 목록

apex list로 함수 목록을 출력할 수 있습니다.

테라폼 변수 출력도 지원합니다.

$ apex list --tfvars
apex_function_bar="arn:aws:lambda:us-west-2:293503197324:function:testing_bar"
apex_function_foo="arn:aws:lambda:us-west-2:293503197324:function:testing_foo"

함수 삭제

함수를 삭제할 때 apex는 정말 삭제할 것인지 물어볼 것입니다. -f, --force 플래그를 설정하면 이 과정을 건너뜁니다. 함수 이름을 지정하면 지정된 함수만 삭제합니다.

예제

모든 함수 삭제

$ apex delete
The following will be deleted:

  - bar
  - foo

Are you sure? (yes/no):

강제 삭제 (삭제할지 묻지 않음)

$ apex delete -f

특정 함수만 삭제

$ apex delete -f foo bar

auth로 시작하는 이름을 가진 함수만 삭제

$ apex delete auth*

AWS 람다 함수 관리 툴 – Apex (2)

프로젝트 구조

프로젝트는 AWS 람다 함수의 모음입니다.

설정

프로젝트 루트 디렉토리에 project.json 파일이 있습니다. 아래 예제는 모든 람다 함수에 대한 기본 AWS IAM롤과 메모리의 기본 값을 정의하고 있습니다.

{
"name": "node",
"description": "Node.js example project",
"role": "arn:aws:iam::293503197324:role/lambda",
"memory": 512
}

다중 환경

--env 플래그를 통해 복수의 환경을 지원합니다. 기본적으로 project.jsonfunction.json 파일이 이용되지만 --env 플래그가 설정되면 project.ENV.jsonfunction.ENV.json이 사용됩니다.

아래는 디렉토리 구조에 대한 예시입니다.

project.stage.json
project.prod.json
functions
├── bar
│   ├── function.stage.json
│   ├── function.prod.json
│   └── index.js
└── foo
    ├── function.stage.json
    ├── function.prod.json
    └── index.js

만약 devstaging 환경이 기본값으로 사용되길 원한다면 해당 내용을 project.jsonfunction.json에 설정하면 됩니다.

project.json
project.prod.json
functions
├── bar
│   ├── function.json
│   ├── function.prod.json
│   └── index.js
└── foo
    ├── function.json
    ├── function.prod.json
    └── index.js

Symlinks

Apex는 파일이나 디렉토리의 심볼릭 링크를 지원합니다. Apex는 링크 정보를 읽어서 함수에 포함된 파일이 아니어도 자동으로 포함시킬 것입니다.

이 기능은 npm link의 사용이나 공용 설정 등을 사용할 수 있게 해줍니다.

필드

name

프로젝트의 이름입니다. 이 필드는 복수의 프로젝트 사이에서 충돌을 막기 위한 nameTemplate의 기본값으로 사용됩니다.

  • 타입: string
  • 필수 항목

description

프로젝트에 대한 설명입니다.

  • 타입: string

runtime

function.json에 구동 환경이 별도로 설정되지 않았을 때에 함수의 기본 구동 환경을 정의합니다.

  • 타입: string

다음과 같은 구동 환경이 지원됩니다

  • java (java 8)
  • python2.7 (Python 2.7)
  • python3.6 (Python 3.6)
  • nodejs4.3 (Node.js 3.4)
  • nodejs4.3-edge (Node.js 3.4 Edge)
  • nodejs6.10 (Node.js 6.10)
  • golang (Any version)
  • clojure (Any version)
  • rust-musl[^rust-runtime][^rust-linux-only] (Any version)
  • urst-gnu[^rust-runtime][^rust-linux-only] (Any version)

[^rust-runtime] : Rust는 2가지 타입의 libc 의존성을 갖는데 rust-musl을 사용하는 것을 권장합니다. rust-gnu를 사용하면 당신의 람다 함수가 람다 서버와 당신의 PC 사이에서 glibc 버전의 불일치로 인해 실행이 거절될 수 있습니다.
[^rust-linux-only] : Rust 버전의 람다 함수는 현재 리눅스 머신에서만 빌드할 수 있습니다. 만약 Mac OS에서 빌드하려고 하면 링커 에러가 발생할 것입니다. 한 가지 솔루션은 Mac에서 apex를 Docker 컨테이너에서 실행하는 것입니다.

memory

함수의 function.json에서 별도로 설정하지 않았을 때의 기본 메모리 사용량입니다.

  • 타입: int

timeout

함수의 function.json에서 별도로 설정하지 않았을 때의 기본 타임 아웃 시간입니다.

  • 타입: int

role

함수의 function.json에서 별도로 설정하지 않았을 때의 롤입니다.

  • 타입: string

profile

사용할 AWS 프로파일의 이름입니다. 이 이름은 ~/.aws/credentials에 정의된 이름들입니다. AWS_PROFILE이나 --profile 설정을 사용하고 싶지 않다면 이 설정을 사용하세요

  • 타입: string

defaultEnvironment

기본 인프라 환경입니다.

  • 타입: string

nameTemplate

함수명을 구하는데 사용될 템플릿입니다. 기본값은 {{.Project.Name}}_{{.Function.Name}} 입니다. 예를 들어 api라는 프로젝트에 ./functions/users라는 함수가 정의되었다면 함수명은 api_users가 됩니다.

  • 타입: string

retainedVersion

함수의 function.json에서 별도로 설정하지 않았을 때의 람다 함수의 버전을 얼마나 유지할지에 대한 기본 숫자입니다.

Apex는 기본으로 10개의 버전을 유지하고 그 이전 버전의 내용은 삭제합니다. AWS는 AWS 계정 레벨에서 람다 함수들의 이전 버전 저장 공간에 대한 하드 리밋을 설정하고 있습니다.

  • 타입: int

vpc

함수의 function.json에서 별도로 설정하지 않았을 때의 기본 VPC 설정입니다.

  • 타입: object

vpc.securityGroup

보안 그룹 ID의 목록입니다.

  • 타입: array

vpc.subnets

서브넷 ID의 목록입니다.

  • 타입: array

AWS 람다 함수 관리 툴 – Apex (1)

apex

APEX는 AWS의 람다 함수의 빌드와 배포를 도와주는 툴입니다. AWS CLI로도 가능하지만 훨씬 간편하게 이용할 수 있습니다.

Github Repository
Homepage

설치

맥, 리눅스, OpenBSD에서는

curl https://raw.githubusercontent.com/apex/apex/master/install.sh | sh

윈도우에서는 바이너리 설치 파일을 받아서 설치할 수 있습니다.

AWS Credential

여타의 AWS 관련 툴과 마찬가지로 Credentail은 ~/.aws 폴더에 설정된 내용을 참고합니다.

설정되어 있지 않다면 aws configure 명령어로 설정할 수 있습니다.

Profile flag

--profile 역시 사용할 수 있습니다.

$ apex --profile my-profile deploy

Project configuration

프로젝트 실행 환경에 대한 설정을 project.json 파일을 통해서 할 수 있는데 이 파일에 Credential에 대한 profile을 지정할 수 있습니다.

아래는 제가 사용하는 설정입니다. Lambda 함수를 만들 때 사용되는 설정값들을 확인할 수 있습니다.

{
  "name": "aws-utils",
  "description": "AWS Utils",
  "memory": 128,
  "timeout": 5,
  "role": "arn:aws:iam::....",
  "environment": {},
  "runtime": "python3.6"
}

IAM Role

IAM Role에 대한 설정도 profile과 같이 --iamrole 옵션 혹은 project.json 파일을 통해서 설정할 있습니다.

Credential 참조 순서

AWS Credential 정보를 로딩하는 우선 순위는 다음과 같습니다.

  1. 플래그로 설정된 프로파일
  2. JSON 설정 파일(project.json)에 설정된 profile
  3. 환경 변수에 설정된 프로파일
  4. default 라는 이름의 프로파일

IAM 정책

Apex는 람다 함수의 배포 및 관리를 위해서 다음과 같은 IAM 권한이 필요합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "iam:CreateRole",
        "iam:CreatePolicy",
        "iam:AttachRolePolicy",
        "iam:PassRole",
        "lambda:GetFunction",
        "lambda:ListFunctions",
        "lambda:CreateFunction",
        "lambda:DeleteFunction",
        "lambda:InvokeFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:UpdateFunctionConfiguration",
        "lambda:UpdateFunctionCode",
        "lambda:CreateAlias",
        "lambda:UpdateAlias",
        "lambda:GetAlias",
        "lambda:ListAliases",
        "lambda:ListVersionsByFunction",
        "logs:FilterLogEvents",
        "cloudwatch:GetMetricStatistics"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

또한 apex init 과정에서 AWSLambdaVPCAccessExecutionRole이라는 정책이 자동으로 생성됩니다.

Getting started

Apex를 사용하기 위해서는 초기화 과정이 필요합니다.

$ export AWS_PROFILE=xxx
$ apex init

아래와 같은 화면을 볼 수 있으며 초기화 과정 중에 위에서 언급한 Apex가 사용할 IAM 역할 및 정책이 생성되고 project.json 파일과 functions라는 폴더도 생성됩니다.

functions 폴더에는 테스트용 람다 함수(functions/hello/index.js)도 만들어집니다.

console.log('starting function')
exports.handle = function(e, ctx, cb) {
  console.log('processing event: %j', e)
  cb(null, { hello: 'world' })
}

이 테스트용 함수를 바로 디플로이해볼 수 있습니다.

# project.json 파일이 있는 폴더에서 실행
$ apex deploy
$ apex invoke hello
{"hello": "world"}