[태그:] opsworks

Opsworks agent error debugging

어느날 Prometheus alert이 와서 Portus 에 문제가 생겼음을 알렸습니다.

Prerequisite

  • AWS Opsworks chef12
  • ubuntu 16.04

디버깅

Disk Full

확인해보니 문제는

no space ….

이런 에러…

$ df -h

로 보니 root가 disk full 입니다.

확인해보니 portus의 nginx 로그가 2GB 씩 stdout, stderr 두개….

로그 지우고 nginx 재시작으로 임시 해결..

AWS opsworks 의 agent 가 업데이트 될때 마침 디스크가 꽉 차있었나 봅니다…

용량 확보 후 재시작…

opsworks-agent-cli를 수동으로 실행해서 configure를 다시 실행시키는 것을 시도 합니다….

root@portus2:/var/lib/aws/opsworks/chef# opsworks-agent-cli run_command configure

결과는 에러…

Couldn't execute run_command: RuntimeError - Couldn't gather commands. RuntimeError - Could not parse /var/lib/aws/opsworks/chef/2018-08-28-10-28-23-01.json: JSON::ParserError - A JSON text must at least contain two octets! - /opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/json-1.8.3/lib/json/common.rb:155:in `initialize'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/json-1.8.3/lib/json/common.rb:155:in `new'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/json-1.8.3/lib/json/common.rb:155:in `parse'
/opt/aws/opsworks/current/lib/cli/base.rb:69:in `parse_json'
/opt/aws/opsworks/current/lib/cli/base.rb:17:in `block in gather_commands'
/opt/aws/opsworks/current/lib/cli/base.rb:16:in `each'
/opt/aws/opsworks/current/lib/cli/base.rb:16:in `gather_commands'
/opt/aws/opsworks/current/lib/cli/runner.rb:72:in `initialize'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `new'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `run'
/usr/sbin/opsworks-agent-cli:91:in `block (2 levels) in <main>'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `execute'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:296:in `block in call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:83:in `run'
/usr/sbin/opsworks-agent-cli:110:in `<main>' - /opt/aws/opsworks/current/lib/cli/base.rb:71:in `rescue in parse_json'
/opt/aws/opsworks/current/lib/cli/base.rb:69:in `parse_json'
/opt/aws/opsworks/current/lib/cli/base.rb:17:in `block in gather_commands'
/opt/aws/opsworks/current/lib/cli/base.rb:16:in `each'
/opt/aws/opsworks/current/lib/cli/base.rb:16:in `gather_commands'
/opt/aws/opsworks/current/lib/cli/runner.rb:72:in `initialize'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `new'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `run'
/usr/sbin/opsworks-agent-cli:91:in `block (2 levels) in <main>'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `execute'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:296:in `block in call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:83:in `run'
/usr/sbin/opsworks-agent-cli:110:in `<main>' - /opt/aws/opsworks/current/lib/cli/base.rb:33:in `rescue in gather_commands'
/opt/aws/opsworks/current/lib/cli/base.rb:15:in `gather_commands'
/opt/aws/opsworks/current/lib/cli/runner.rb:72:in `initialize'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `new'
/opt/aws/opsworks/current/lib/cli/runner.rb:50:in `run'
/usr/sbin/opsworks-agent-cli:91:in `block (2 levels) in <main>'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/command_support.rb:126:in `execute'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:296:in `block in call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:309:in `call_command'
/opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/gli-2.13.4/lib/gli/app_support.rb:83:in `run'
/usr/sbin/opsworks-agent-cli:110:in `<main>'

File check

파싱이 안된다고 합니다. 파일을 오픈 합니다.

$ vi /var/lib/aws/opsworks/chef/2018-08-28-10-28-23-01.json

파일이 비어있습니다… 이상합니다…

이 JSON 파일은 opsworks 의 리소스들의 정보가 모여있는 파일입니다. 파일 내용이 있어야하는데…. 아마도 용량문제로 파일을 쓰지 못한 듯 합니다.

/var/lib/aws/opsworks/chef 이 폴더로 들어가서 뭐하는 폴더인지 확인합니다.

Directory check

$ ll
root@portus2:/var/lib/aws/opsworks/chef# ll
total 2168
drwxr-xr-x 2 aws  aws    4096 Aug 29 11:28 ./
drwxr-x--- 6 aws  aws    4096 Aug 29 11:21 ../
-rw-r--r-- 1 aws  aws       0 May 10 03:44 2018-05-08-10-10-48-01.log.gz
-rw-r--r-- 1 aws  aws  102226 Jul 17 09:55 2018-07-17-09-55-08-01.log
-rw-r--r-- 1 aws  aws       0 Aug 28 10:24 2018-08-28-10-24-52-01.json
-rw-r--r-- 1 aws  aws       0 Aug 28 10:28 2018-08-28-10-28-23-01.json
-rw-r--r-- 1 aws  aws       0 Aug 28 16:20 2018-08-28-16-20-30-01.json
-rw-r--r-- 1 aws  aws  157625 Aug 28 16:31 2018-08-28-16-31-31-01.json
-rw-r--r-- 1 root root 105741 Aug 28 16:31 2018-08-28-16-31-31-01.log
-rw-r--r-- 1 aws  aws  157559 Aug 29 05:55. 2018-08-29-05-55-37-01.json
-rw-r--r-- 1 root root 102946 Aug 29 05:55 2018-08-29-05-55-37-01.log
-rw-r--r-- 1 aws  aws  157560 Aug 29 06:14 2018-08-29-06-14-17-01.json
-rw-r--r-- 1 root root 103341 Aug 29 06:14 2018-08-29-06-14-17-01.log
-rw-r--r-- 1 aws  aws  149311 Aug 29 11:04 2018-08-29-11-04-15-01.json
-rw-r--r-- 1 root root  98073 Aug 29 11:04 2018-08-29-11-04-15-01.log
-rw-r--r-- 1 aws  aws  157559 Aug 29 11:07 2018-08-29-11-07-52-01.json
-rw-r--r-- 1 root root 103340 Aug 29 11:07 2018-08-29-11-07-52-01.log
-rw-r--r-- 1 aws  aws  157558 Aug 29 11:11 2018-08-29-11-11-30-01.json
-rw-r--r-- 1 root root 103651 Aug 29 11:11 2018-08-29-11-11-30-01.log
-rw-r--r-- 1 aws  aws  157656 Aug 29 11:21 2018-08-29-11-21-38-01.json
-rw-r--r-- 1 root root 103648 Aug 29 11:21 2018-08-29-11-21-38-01.log
-rw-r--r-- 1 aws  aws  157670 Aug 29 11:24 2018-08-29-11-24-45-01.json
-rw-r--r-- 1 root root 100655 Aug 29 11:24 2018-08-29-11-24-45-01.log

빈 파일이 몇개 있습니다..

Removing empty files

뭔지 모르겠지만 비어서 parsing error 가 나는 듯 합니다.
과감히 빈 파일을 지워줍니다. 

$> rm 2018-08-28-10-24-52-01.json

그리고 다시 위의 명령을 실행합니다.

뭔가 바뀔까요?

root@portus2:/var/lib/aws/opsworks/chef# opsworks-agent-cli run_command configure
Couldn't execute run_command: RuntimeError - Couldn't gather commands. RuntimeError - Could not parse /var/lib/aws/opsworks/chef/2018-08-28-10-28-23-01.json: JSON::ParserError - A JSON text must at least contain two octets! - /opt/aws/opsworks/current/vendor/bundle/ruby/2.2.0/gems/json-1.8.3/lib/json/common.rb:155:in `initialize'
...

그 뒤의 파일을 읽기 시도하다가 에러가 다시 발생했습니다.
이제 이상한 json 파일들을 전부 지워줍시다.

그리고 다시 agent 를 실행하면 정상동작하는 것을 볼 수 있습니다. 

[2018-08-29T11:50:10+00:00] INFO: Processing directory[/etc/logrotate.d] action create (/var/chef/runs/5f5d34e2-e02f-4871-98b9-c842712610de/local-mode-cache/cache/cookbooks/logrotate/resources/app.rb line 60)
[2018-08-29T11:50:10+00:00] INFO: Processing template[/etc/logrotate.d/nginx] action create (/var/chef/runs/5f5d34e2-e02f-4871-98b9-c842712610de/local-mode-cache/cache/cookbooks/logrotate/resources/app.rb line 67)
[2018-08-29T11:50:10+00:00] INFO: HTTP Request Returned 404 Not Found: Object not found: chefzero://localhost:8889/nodes/portus2
[2018-08-29T11:50:10+00:00] INFO: Chef Run complete in 0.286619869 seconds
[2018-08-29T11:50:10+00:00] INFO: Running report handlers
[2018-08-29T11:50:10+00:00] INFO: Report handlers complete
[2018-08-29 11:50:10]  INFO [opsworks-agent(16252)]: Finished Chef run with exitcode 0

chef12 opsworks 실행

Chef-client 를 수동으로 실행하려면 아래와 같은 명령을 사용하면 가능합니다.

opsworks-agent-cli 실행 시 확인 가능

  1. 첫번째 chef-client 실행
# RUBYOPT="-E utf-8" /opt/aws/opsworks/current/bin/chef-client -j /var/lib/aws/opsworks/chef/2018-08-30-05-10-55-01.json -c /var/lib/aws/opsworks/client.internal.rb -o aws_opsworks_agent 2>&1
  1. 두번째 chef-client 실행
# RUBYOPT="-E utf-8" /opt/chef/bin/chef-client -j /var/chef/runs/fd1800b7-5b1e-4ec8-b7dd-3579f6c568c3/attribs.json -c /var/chef/runs/fd1800b7-5b1e-4ec8-b7dd-3579f6c568c3/client.rb  2>&1

위의 attribs.json 파일을 살펴보니…

{
  "region_project": "TEST",
  "region": "TEST01",
  ...
  ...
  "run_list": [
    "recipe[logrotate::nginx]"
  ]
}

run_list 로 제가 OpsWorks Stack 에서 execute_recipes 한 내용이 기록되어 있습니다.
logrotate 레시피를 추가해줬죠…

attribs.json 파일에 현재 실행할 명령들이 들어가는 구조로 보입니다.
필요하다면 run_list 에 명령을 변경해서 실행한다면 가능할 듯….

이상 opsworks-agent-cli 관련 디버깅 경험 이슈였습니다.

[AWS] Amazon web service 의 서비스 간단 정리

AWS 서비스 정리

AWS를 공부해야겠다고 마음먹고 AWS를 막상 시작하려고 하면,
그 방대한 사이즈에 지래 겁을 먹게 됩니다.
또한 AWS의 어떤 특정 기능에 대해 찾아보려고 하면 또다른 AWS서비스들이 연계되어서 다시 리서치를 해야하는 번거로움에 빠지게 됩니다.

이에 저의 고생을 경험삼아 다른분들의 고생을 미리 방지하고자 사람들을 위해 AWS 서비스를 간단하게 정리했습니다.

EC2(Amazon Elastic Compute Cloud)

VM기반의 컴퓨팅 자원을 제공하는 서비스
일반적인 클라우드 서버 인스턴스를 의미

Instance Family Current Generation Instance Types
General purpose t2.nano, t2.micro, t2.small, t2.medium, t2.large, t2.xlarge, t2.2xlarge, m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, m4.10xlarge, m4.16xlarge, m3.medium, m3.large, m3.xlarge, m3.2xlarge
Compute optimized c4.large, c4.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge, c3.large, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge
Memory optimized r3.large, r3.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge, r4.large, r4.xlarge, r4.2xlarge, r4.4xlarge, r4.8xlarge, r4.16xlarge, x1.16xlarge, x1.32xlarge
Storage optimized d2.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge, i2.xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge, i3.large, i3.xlarge, i3.2xlarge, i3.4xlarge, i3.8xlarge, i3.16xlarge
Accelerated computing p2.xlarge, p2.8xlarge, p2.16xlarge, g2.2xlarge, g2.8xlarge
  1. T2는 웹서버, 데이터 베이스에 사용하기 좋음, 순간 확장용으로 적합
  2. M3는 SSD 스토리지 사용
  3. C4는 CPU를 많이 쓰는 서비스에 적합 -> ssd도 필요하면 C3
  4. X1, R3은 메모리가 많이 필요한 서비스에 적합(빅데이터 치리 엔진, Apache Spark, Presto)
  5. P2, G2는 GPU 계산에 특화 (머신러닝)
  6. I3는 스토리지에 최적화 (높은 I/O가 필요한 작업)

EBS(Elastic Block Store)

EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공
Amazon EBS 볼륨은 워크로드 실행에 필요한 지연 시간이 짧고 일관된 성능을 제공 -> S3와의 큰 차이점

그러나 S3에 비해 비쌈

EIP(Elastic IP)

EC2인스턴스를 생성하고 주는 IP는 고정IP가 아닌 유동IP
인스턴스를 재시작하면 IP가 변경됨
고정아이피 서비스 -> EIP

ELB(Elastic Load Balancing)

EC2를 대상으로한 요청을 여러대의 EC2 인스턴스로 자동으로 분배해주는 기능
이전엔 L4/L7 로드 밸런서를 이용하던 기능을 간단한 WEB UI로 손쉽게 이용가능

로드 밸런서는 EC2의 작동 상태를 확인하여 정상적으로 작동하고 있는 인스턴스만을 대상으로 요청을 분배함

Sticky Session을 이용하면 로드밸런싱을 해줄 때 사용자의 쿠키 세션을 이용해여 요청 분배작업을 수행, 초기 접속 인스턴스로 연결 시켜줌

Key Pairs

AWS ssh접속은 public/private 키를 이용하여 접속
각각의 key pair에는 이름이 필요하고, 이름은 publickey와 연결됨

Security Group

EC2에서 일종의 방화벽 처럼 사용됨
inbound/outbound traffic에 대해 port별로 접근 제어할 수 있는 기능 제공
호스팅 환경에서 DMZ와 같은 개념 구현 가능

S3 (Simple Storage Service)

웹 인터페이스를 통해 데이터를 저장 및 검색할 수 있는 스토리지
RRS(Reduced Redundancy Storage) 옵션으로 데이터 손실 위험도를 더 올리고 가격을 저렴하게 사용가능

Bucket

데이터를 저장하기 위한 Amazon S3의 기본 컨테이너
버킷에 데이터를 무한정으로 저장 가능

Snapshot

EBS 볼륨 전체의 내용 중 특정 시점을 파일로 저장한 형태 (EBS 볼륨 백업)

VPC(Virtual Private Cloud)

AWS에서 가상사설망을 만들어줄수 있게 해주는 서비스
이 서비스 전에는 EIP이외에는 정적 서비스를 사용할 수 없었음(ex> 10.x.x.x같은 사설 ip 사용하지 못했으나, VPC를 통해 가능해짐)

Lambda

서버없이 특정 이벤트 발생시 코드 실행을 시켜주고, 이에 대한 비용만을 지불하는 AWS의 서비스
런타임으로 Java, nodejs, python, C# 사용가능

Blue Print라는 코드 템플릿을 선택해서 사용가능하다

Route 53

AWS의 Domain Name Service 이다.
ELB(로드 밸런서)를 사용할 때 함께 사용하는 서비스

라우팅 정책

  1. 단순 라우팅
    하나의 인스턴스 사용
  2. 가중치 기반 라우팅
    다수의 리소스를 하나의 DNS와 연동 가능하나, 각 리소스에 가중치 부여 가능

    리소스 3개 -> 가중치 1,1,3 부여했을 경우
    DNS요청시 1로 설정된 리소스는 5번중 한번, 3으로 설정된 리소스는 5번중 3번 반환

  3. 지연 시간 라우팅
    지연시간이 가장 낮은 인스턴스 선택

  4. 지리적 라우팅
    사용자의 지역에 따라 인스턴스 선택 -> Localization 가능

ElastiCache

클라우드에서 In Memory Data Store로 사용 하거나, 캐시를 손쉽게 배포, 운영, 확장할 수 있게 해주는 웹서비스

  1. Redis
    Redis용 ElastiCache는 확장 가능(최대 15개의 샤드 클러스터 지원 3.55TiB)
  2. Memcached
    ElastiCache는 Memcached와 프로토콜 호환. 기존 환경에서 사용하는 도구를 손쉽게 사용 가능

CloudFront

AWS에서 제공하는 CDN서비스
이미지, 오디오, 비디오 및 일반 웹 페이지 등을 최종 사용자에게 빠르게 제공
에지 로케이션(Edge Location)이라는 일종의 캐시서버를 이용하여 지연시간 단축

IAM(Identity and Access Management)

AWS 계정의 암호나 액세스 키 공유없이 다른 계정에 권한 부여 가능

  1. 리소스에 따른 계정 권한
  2. 읽기 쓰기 권한 등.. -> 차등 권한 부여 가능

사용자

AWS의 서비스 계정으로 간주하면 됨

윈도우즈를 사용할 때 여러 계정을 만들 수 있는 것과 같은 이치

ARN(Amazon Resource Name)

아래 형태로 사용

arn:aws:iam::account-ID-without-hyphens:user/Bob

그룹

IAM사용자들의 집합체
but 리눅스의 group개념과는 다른 그냥 여러 사용자들에게 한번에 정책을 연결하는 수단일 뿐

역할

사용자와 유사
_but 역할은 한 사람과만 연관되지 않고 그 **역할이 필요한 사람이면 누구든지 맡을 수 있도록 고안**_

CodeCommit

프라이빗 Git 리포지토리를 손쉽게 운영할 수 있는 서비스
가격이 싸다

SNS(Simple Notification Service)

푸시 알림 서비스로서, 개별 메시지를 전송하거나 대규모의 수신자에게 메시지를 전송 가능
Baidu Cloud Push를 통해 Android, Apple, Google, Fire OS, Windows 디바이스에도 알림 전송 가능
Amazon Simple Queue Service(SQS), AWS Lambda 함수 또는 모든 HTTP 엔드포인트에도 메시지를 전송 가능

토픽(Topic)

여러 개의 엔드포인트를 그룹으로 만든 것. 토픽을 구독한 모든 엔드포인트로 알림 전송

SQS(Simple Queue Service)

메시지를 저장하는 대기열에 대한 액세스를 제공하는 웹 서비스

메시지 큐

대기열 유형

  1. 표준 대기열
    기본 대기열, 메시지가 1개 이상 전달될 수 있으며 순서 또한 바뀔 수 있음
    무제한의 초당 트랜잭션 수 제공
  2. FIFO 대기열
    순서 및 메시지 단일 전달 보장
    초당 트랜잭션 수가 300개 제한

CloudWatch

AWS 클라우드 리소스와 AWS에서 실행되는 애플리케이션을 위한 모니터링 서비스
자동으로 EC2 인스턴스를 모니터링
1. Auto Scaling Group
2. Elastic Load Balancer
3. Route 53

메트릭(Metric)

AWS 시스템의 퍼포먼스에 관한 데이터들을 뜻함

기본적으로 제공하는 CloudWatch의 모니터링 기능은 이 메트릭을 이용해서 보여진다(EC2, ELB등의 기본 서비스 관련 정보등..)
사용자가 커스텀 메트릭 생성가능

상태는 3가지

  1. OK
    정의된 임계치 안, 현재 정상
  2. Alarm
    정의된 임계치 상회, 비정상
  3. Insufficient
    데이터 불충분으로 상태 판독 불가

Auto Scaling

Auto Scaling이란?

EC2 인스턴스를 자동으로 생성하고 삭제해주는 서비스

Launch Configuration

Auto Scaling을 할 때 사용하는 설정값

어떤 이미지(AMI)를 어떤 인스턴스 타입(EC2)으로 스토리지(EBS) 및 보안설정(SG)과 함께 사용할 것인가를 선택

ex> Linux AMI 이미지를 t2.micro로 EBS 20G와 함께 port 80번만을 열어서 실행한다.

AutoScaling Groups

위의 설정값을 사용해서 실제 Auto Scaling을 수행하기 위한 Grouping

어떤 설정값으로, 어떤 네트워크에, 어떤 정책(인스턴스를 추가하고 제거하는 방법 등의 정책)을 이용해서 오토 스케일링을 할 것 인가에 대한 설정

ex> ASG을 통해서 생성된 EC2 인스턴스들의 CPU 점유율이 평균 80%가 5분동안 넘을 때 EC2 인스턴스를 현재의 2배씩 증가 시킨다

OpsWorks

서버 구성을 자동화 플랫폼 Chef를 사용해서 하는 관리 서비스
어플리케이션과 서버 관리를 용의하게 해줌

  1. OpsWorks Stacks
  2. AWS OpsWorks for Chef Automate

OpsWorks Stacks

OpsWorks 개념도

위의 개념도를 참고.

Stack > Layer > Instance > App

Stack

스택은 OpsWorks에서 최상위 단위
스택안에 여러 개의 레이어가 포함가능함

Layer

EC2 인스턴스 생성을 위한 틀(탬플릿의 개념)
OpsWorks 내장으로 Rails with Passenger, Java with Tomcat, Nodejs, RDS 등을 기본으로 지원하고, Custom하게 만들 수도 있음

내장 탬플릿으로 레이어를 생성하면 AWS에서 지원하는 Chef 레시피(Recipe)들이 기본적으로 들어가있다.(Chef 12의 경우는 없다고 하는데 실행해보지는 않음)

Opsworks Lifecycle Events

각 Layer들은 5개의 이벤트를 가지고 있음, 이벤트 발생시 각 이벤트마다 등록된 레시피(Recipe)가 실행됨

  1. Setup
    인스턴스 부팅이 완료된 후 발생
    수동으로 이벤트 발생 가능
    명렁 참고

  2. Configure
    스택의 모든 인스턴스들 중 어느 하나라도 아래 상황 중 하나의 경우에 해당할 경우, 모든 인스턴스에게 발생함

    • 인스턴스가 온라인 상태가 되었거나, 온라인 상태에서 벗어날때(leave the online)
    • 인스턴스가 EIP가 할당되거나, 할당이 취소될 때
    • ELB를 레이어에 연결하거나, 연결해제 할때
  3. Deploy
    Deploy Command를 실행했을 때 발생
    Setup이 완료된 후에 Deploy 레시피가 실행됨

  4. Undeploy
    앱을 지웠거나 Undeploy 명령을 실행 했을 때 발생

  5. Shutdown
    Opsworks에서 인스턴스를 종료하고, 실제로 EC2인스턴스가 종료하기전에 발생
    인스턴스를 리부팅할때는 어떤 이벤트도 발생하지 않음

AWS OpsWorks for Chef Automate

Chef Automate를 AWS에서 손쉽게 이용할 수 있는 서비스
현재(2017년 5월) US East (Northern Virginia), US West (Oregon) 및 Europe (Ireland) 지역에서만 이용 가능

Habitat(앱 빌드 및 패키징 자동화), InSpec(컴플라이언스 자동화)과 Chef를 함께 사용하는 CI(지속적 통합)서비스

Chef Automate AWS 블로그

KMS (Key Management Service)

데이터를 암호화할 때 사용하는 암호화 키를 쉽게 생성하고 제어할 수 있게 해주는 관리형 서비스

AWS product category AWS services integrated with KMS
Compute Amazon Lightsail*, Amazon EC2 SSM*, AWS Lambda
Storage & Content Delivery Amazon S3, Amazon EBS, AWS Import/Export Snowball, AWS Storage Gateway
Databases Amazon RDS, Amazon Redshift, AWS Database Migration Service
Developer Tools AWS CodeCommit*
Management Tools AWS CloudTrail
Analytics Amazon EMR, Amazon Kinesis Firehose
Application Services Amazon Elastic Transcoder, Amazon SES
Enterprise Applications Amazon WorkSpaces, Amazon WorkMail

KMS는 AWS SDK, the AWS Command Line Interface, RESTful API와 통합해서 사용

CloudTrail

  • CLoudTrail은 AWS 계정 사용에 대한 관리, 운영 감사, 취약점 감사등을 도와주는 서비스
  • AWS상의 서비스에 대한 로그, 지속적 모니터링, api사용 관련 이벤트등 제공

결론

AWS에는 훨씬 더 많은 서비스들이 존재하고 앞으로도 계속 생길 것입니다.
이번 AWS Summit 2017 in Seoul 도 참여 했었는데 새로운 서비스들이 등장하더군요.

AWS 자격증도 있던데 2년마다 갱신되고 상당히 힘들어보였습니다.
관심있으시면 한번 도전해보세요.

[adsense2]

Error occurs when start an instance AWS OpsWorks

Error occurs when start an instance AWS OpsWorks

When I start a new instance on OpsWorks Layers, I faced this error.

================================================================================
Recipe Compile Error in /var/lib/aws/opsworks/cache.stage2/cookbooks/aws/resources/cloudwatch.rb
================================================================================

NoMethodError
-------------
undefined method `property' for #&lt;Class:0x007f511b6ee538&gt;

Cookbook Trace:
---------------
/var/lib/aws/opsworks/cache.stage2/cookbooks/aws/resources/cloudwatch.rb:1:in `class_from_file'

Relevant File Content:
----------------------
/var/lib/aws/opsworks/cache.stage2/cookbooks/aws/resources/cloudwatch.rb:

1&gt;&gt; property :alarm_name, String, name_property: true
2: property :alarm_description, String
3: property :actions_enabled, TrueClass
4: property :ok_actions, Array, default: []
5: property :alarm_actions, Array, default: []
6: property :insufficient_data_actions, Array, default: []
7: property :metric_name, String
8: property :namespace, String
9: property :statistic, equal_to: %w(SampleCount Average Sum Minimum Maximum)
10: property :extended_statistic, String

I got a panic….
Because it certainly worked fine when I start an instance before a couple of hours…

I had found a solution.
Finally I found it.

That’s why AWS cookbook updated.

My OpsWorks system used chef11.
When AWS cookbook updated 6.1.0, it has used new method, property.

I specified a version of AWS cookbook on my Berkshelf

Finally it works well.

p80.pool.sks-keyservers.net: Host not found

AWS의 Opsworks에서 새로운 instances를 만들다가 만난 에러를 정리해둡니다.

AWS의 Opsworks 는 인스턴스를 새로 생성하면 등록되어있는 Chef Recipe 들을 자동으로 실행해주는 툴입니다.

이번에 Instance 한개를 추가로 생성하고, 그 Instance에 하나의 App 을 배포하려고 기존 Layer에서 추가로 Instance 를 생성하게 되었습니다.

그런데 갑자기 에러가 발생해서 로그를 봤더니 이런 로그가 있었습니다.

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
execute[install-key 58118E89F3A912897C070ADBF76221572C52609D] (/var/lib/aws/opsworks/cache.stage2/cookbooks/apt/providers/repository.rb line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
---- Begin output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
STDOUT: Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.YjqEGDmda9 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D
?: p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
STDERR: gpg: requesting key 2C52609D from hkp server p80.pool.sks-keyservers.net
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
---- End output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
Ran apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D returned 2

Resource Declaration:
---------------------
# In /var/lib/aws/opsworks/cache.stage2/cookbooks/ops-docker/recipes/install.rb

4: apt_repository 'docker' do
5: uri node['docker']['package']['repo_url']
6: distribution node['docker']['package']['distribution']
7: components ['main']
8: keyserver node['docker']['package']['repo_keyserver']
9: key node['docker']['package']['repo_key']
10: end
11:

Compiled Resource:
------------------
# Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/ops-docker/recipes/install.rb:4:in `from_file'

apt_repository("docker") do
action :add
retries 0
retry_delay 2
cookbook_name "ops-docker"
recipe_name "install"
uri "https://apt.dockerproject.org/repo"
distribution "ubuntu-trusty"
components ["main"]
keyserver "hkp://p80.pool.sks-keyservers.net:80"
key "58118E89F3A912897C070ADBF76221572C52609D"
cache_rebuild true
end

[2017-05-03T09:17:52+00:00] INFO: Running queued delayed notifications before re-raising exception
[2017-05-03T09:17:52+00:00] ERROR: Running exception handlers
[2017-05-03T09:17:52+00:00] ERROR: Exception handlers complete
[2017-05-03T09:17:52+00:00] FATAL: Stacktrace dumped to /var/lib/aws/opsworks/cache.stage2/chef-stacktrace.out
[2017-05-03T09:17:52+00:00] ERROR: apt_repository[docker] (ops-docker::install line 4) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[install-key 58118E89F3A912897C070ADBF76221572C52609D] (/var/lib/aws/opsworks/cache.stage2/cookbooks/apt/providers/repository.rb line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
---- Begin output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
STDOUT: Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.YjqEGDmda9 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D
?: p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
STDERR: gpg: requesting key 2C52609D from hkp server p80.pool.sks-keyservers.net
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
---- End output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
Ran apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D returned 2
[2017-05-03T09:17:53+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

해서 검색을 시작했습니다.
저는 OpsWorks나 Docker에 서툴러서 뭔 실수를 했나 싶었는데 결과는…
그냥 단순히 서버 다운… OTL.

p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn’t connect: Success

그냥 저 서버가 죽은거 였네요.

저 서버가 Docker설치시 기본으로 바로보는 PGP key server인 듯..
아래 링크가 이 에러와 관련된 Thread입니다.

Key server down for get.docker.com · Issue #13555 · moby/moby · GitHub

여기 가보면 kris라는 사람이
기존 Docker가 사용하는 서버주소를
From,

p80.pool.sks-keyservers.net

To,

hkp://keyserver.ubuntu.com:80

로 변경해주라고 답을 달아놨더군요.

 

결론

아무튼 이 버그의 결론은,
잠시뒤에 다시 시도 해본다;;;;

서버가 살아날 시간을 주는 것입니다;;