DevOps 이론 2
AWS Lambda
Chef/AWS OpsWorks
1~2교시
어제 막바지에 말씀하셨는데, Chef가 구성이 복잡한 편이고 자주 사용하는 편은 아니라고 한다.
해당 회사에서 Chef를 쓰고, AWS를 사용한다면 AWS OpsWorks Chef 서비스를 사용하게 될 것이다.
Workstation이 설정 내용(Cookbook)을 Chef Server에 업로드하고, 이 서버가 Cookbook을 사용해서 노드들에게 설정 내용을 뿌리는 것이다. 서버는 Workstation/노드/Cookbook을 관리하는 관리 머신의 기능이다.
-> 버전 관리란? : Cookbook의 버전이 달라지면 버전에 따라 배포하는 것이 가능
어제는 사용했던 Github 링크가 망가져서 문제가 발생했다고 한다.
어제 실습 다시
AWS OpsWorks Chef Automate Server는 어제와 동일하게 생성 > credentials, Starter Kit 다운로드
우분투 20.04 인스턴스를 하나 만들어서 Chef Workstation 생성 > 접속 > 패키지 설치
sudo dpkg -i chef-workstation_0.2.43-1_amd64.deb
chef --version으로 확인
sudo snap install aws-cli --classic : AWS API와 통신할 수단 설치
콘솔에서 IAM > 사용자 추가 > 사용자 이름 작성, 액세스 유형은 액세스 키 방식 > 권한 설정은 기존 정책 직접 연결(AmazonS3 FullAccess) 후 생성 > 생성 완료 후 .csv 파일 다운로드. 이 파일에서 Secret access key와 Access key ID가 중요.
aws configure 실행 > Access Key ID와 Secret Access Key 입력
AWS OpsWorks Chef 서버 대시보드로 들어가서 credentials로 받은 계정명, 비밀번호 입력해서 로그인
콘솔 서비스에서 S3로 진입 > 어제와 동일하게 버킷 만들어서 Starter Kit 업로드
이제 Workstation에서 S3에 접근, Start Kit을 다운받아야 하는데... 에러 발생.
-> Fatal error : Unable to locate credentials
-> aws configre를 sudo로 실행해서 로그인
-> sudo aws s3 cp s3://버킷명/파일명 [다운받을 경로]
-> 다운로드 성공.
credentials 정보는 사용자 홈 디렉터리의 .aws/credentials 파일에 작성되어 있다.
-> 다운로드는 sudo로 실행하려면서 aws configure는 그냥 실행해서 로그인하니 어긋나는 것이다.
-> 전자는 root 사용자 홈 디렉터리에 있는 credentials 정보를 사용하고, 후자는 사용자 홈 디렉터리에 있는 credentials 정보를 사용하니 저런 에러가 뜬 것이다.
sudo apt install unzip 설치해서 압축 풀 준비
unzip 파일명 : S3에서 받은 파일 압축 해제
작업용 디렉터리(learn_chef) 하나 생성(mkdir)
압축 풀어서 생긴 디렉터리로 들어가서 .chef 디렉터리를 방금 만든 작업용 디렉터리로 이동시킨다.
작업 디렉터리로 이동, knife ssl check 실행해서 연결 체크
-> 도메인으로 연결 확인 메시지가 뜬다. 이러면 연동이 완료된 것.
이제 노드쪽으로 Cookbook을 사용해 아파치 웹 서버를 설치해 보자.
-> 작업 디렉터리 안에 cookbook용 디렉터리 생성
-> 이동해서 git clone https://github.com/rk-rlpl/learn_chef_apache2.git로 Cookbook 다운로드
작업 디렉터리로 돌아가서 knife cookbook upload learn_chef_apache2를 실행하면 Chef Automate 서버에 파일이 올라간 것이 보인다.
테스트용 노드를 만들자. 인스턴스 생성(HTTP, HTTPS 보안 그룹 열어두기)
싱가포르 키 파일 열어서 복사, Workstation의 홈 디렉터리의 .ssh 디렉터리로 이동
-> .pem 파일 생성해서 복사한 키 파일 붙여 넣기
-> 지금 만든 파일은 664 권한인데, 600 권한으로 변경
-> ssh -i [.pem 파일명] ubuntu@[노드 퍼블릭 IP 주소] : 노드 접속
접속 가능이 확인되면 다시 Workstation의 작업 디렉터리로 이동
3교시
knife bootstrap [노드 공인 IP 주소] --ssh-user [사용자명] --sudo --identity-file ~/.ssh/[.pem 파일명] --node-name [노드 이름 명명] --run-list 'recipe[learn_chef_apache2]'
knife node list 실행해서 확인
knife node show [노드명] 실행해서 노드의 정보 확인
Chef Automate 웹 페이지에서도 Infrastructure 탭에 들어가 확인 가능
-> 노드의 공인 주소로 들어가 보면 웹 페이지가 만들어져 있다.
버전 관리 기능을 확인해 보자.
Workstation의 작업 디렉터리 > cookbooks 디렉터리 > learn_chef_apache2 > templates 디렉터리로 이동해 보면 index.html.erb 파일이 있는데, 이게 아까 노드의 화면에 뜬 파일.
-> 이거 살짝 수정하고
learn_chef_apache2 디렉터리에 있는 metadata.rb 파일 확인해서
-> version 숫자를 수정
작업 디렉터리로 돌아와서 knife cookbook upload learn_chef_apache2 실행, 바뀐 버전의 cookbook 업로드
-> Chef Automate 웹 페이지에서도 확인 가능
작업 디렉터리에서
knife ssh 'name:노드명' 'sudo chef-client' --ssh-user 사용자명 --ssh-identity-file ~/.ssh/[.pem 파일명] --attribute [노드 주소]
실행해서 노드에 적용된 버전 업데이트
- 삭제 순서
knife node delete [노드명]
knife client delete [노드명]
AWS OpsWorks 콘솔에서 Chef Automate Server 삭제
Workstation 노드 삭제, 테스트 노드 삭제
S3 버킷에 있는 파일 삭제 후 버킷 삭제
IAM에 추가했던 사용자도 삭제
4교시
- IAM(Identity and Access Management)
root 계정은 모든 권한이 주어져 있어서 작업할 때마다 사용하면 보안상 위험하다.
-> IAM 사용자를 만들고, 정책으로 각 사용자에게 권한을 부여
-> 사용자/사용자 그룹을 만들고 각 사용자 혹은 사용자 그룹별로 필요한 권한만을 제한적으로 부여 가능
1. 루트 사용자
모든 접속 권한을 가지는 가장 중요한 사용자. 특정 그룹에 속하지 않고 사용자를 만들 수 있는 권한이 있으며 AWS 콘솔에 아이디와 비밀번호로 접속
2. 사용자
AWS 콘솔에 아이디와 비밀번호로 접속 가능. 그룹에도 속할 수 있으나 부여된 정책에 한해서만 리소스 접근 가능.
3. 그룹
사용자 관리를 위한 기능. 그룹에 정의된 특별한 정책은 소속 사용자가 영향을 받는다.
4. 역할
사용자와 유사하지만 비밀번호를 통해 접속할 수 없으며 그룹에 속할 수 없음. 정책에 한해서만 리소스에 접근 가능. 정책이 부여되지 않았다면 아무것도 할 수 없다. 리소스가 다른 리소스를 사용할 때도 역할이 필요.
5~6교시
내일 오후 3시쯤에 2차 취업 강의
다음은 Serverless 서비스를 위한 AWS Lambda
-> Severless는 서버가 없는 것이 아니다. 스냅숏 같은 개념으로, 리소스를 사용하지 않는 상태에서 요청이 들어오면 리소스를 끌어와서 응답하는 유형.
특정 시간대에만 트래픽이 발생한다면 유용하다.
FaaS(Function as a Service)
-> 함수를 서비스로 이용하는 것. 개발자가 환경을 구성하고 서버 코드를 작성하는 것이 아닌 FaaS를 이용해서 함수만 구성하면 된다.
서버 코드 실행을 위해 서버를 구성하고 코드를 배포하던 형식을 줄이고, 원하는 작동만 함수를 기반으로 구현하여 각 클라우드 서비스 제공사의 조건에 충족되면 실행된다.
-> App 자체를 제외하면 우리가 신경 쓸 일은 없다.
함수가 호출되면 컨테이너(VM)가 실행되어 정의한 함수가 실행 환경 내에서 실행된 다음 종료된다.
-> 이벤트 기반 동작. 여러 함수와 서비스를 연결하여 복잡한 로직도 구현 가능
- 3 Tier Architecture
Client Tier(Client Computer) - Application Tier(Application Server) - DB Tier(DB Server)
- Serverless의 단점
1. 상태 유지가 되지 않는다.
컨테이너는 잠시 실행되는 환경이다. 상태를 저장하지 않는다(Stateless)
서버 코드로 상태 값을 유지, 상태 값으로 로직을 구현하던 방식 사용 불가.
2. 함수가 실행되기 위해 항상 준비된 상태가 아니다.
실행 시 지연 시간 발생(Cold Start)
함수를 실행했다면 함수를 실행한 컨테이너는 잠시 대기 상태가 되는데, 이때 다시 실행하는 것을 Warm Start라고 한다.
이러면 준비되어 있어 처음 호출할 때 발생하는 지연시간이 발생하지 않는다.
3. 서비스 제공사(클라우드 회사)에 의존적이다.
AWS 기반으로 설계되어 있는 것을 Azure나 GCP 환경으로 변경하기 어렵다.
7~8교시
Lambda로 이동, 함수 생성
새로 작성 선택, 런타임은 파이썬 3.7, 나머지는 내버려두고 함수 생성
우측 상단에 '조절'은 람다 실행에 필요한 예약된 동시성을 0으로 초기화하는 기능
Layers : 추가 코드와 라이브러리를 등록하여 사용할 수 있는 기능
트리거 추가 : 람다 함수를 실행시킬 서비스나 이벤트를 지정
트리거 종류 : API Gateway, ALB, CodeCommit, CloudWatch, S3, SNS, SQS, DynamoDB 등
S3 버킷과 Lambda 함수로 이미지 Thumbnail 생성
일단 Lambda 함수가 S3 버킷 접근 권한이 있어야 한다.
IAM 들어가서 역할 생성 > 개체 유형은 AWS 서비스, 사용 사례 Lambda 클릭 후 다음 > AWSLambdaBasicExecutionRole과 AmazonS3FullAccess 체크 후 다음 > 태그는 대충 넘기고 다음 > 역할 이름 작성 후 생성
사용자 생성 > 이름 작성, 액세스 유형은 액세스 키 > 기존 정책 직접 연결, AmazonS3FullAccess 체크해서 생성
버킷 생성 > 이전과 동일하게 만들고 이미지 하나 업로드
Resize용 버킷 하나 더 생성
함수 생성 > 새로 작성, 파이썬 3.7 선택 후 생성 > 우측 상단에서 '에서 업로드' 선택, 강사님께 받은 코드의 zip 파일 업로드
함수에서 구성 탭 > 권한 > 실행 역할 편집 > 람다 S3 역할 만든 거 추가
상단의 트리거 추가 > S3 선택 > 이미지 업로드한 버킷 선택 후 생성
테스트 탭 > 템플릿은 s3-put, 이름 작성
아래 코드에서
"bucket" 블록에서 "name": "mybucket4613" 수정, "object" 블록에서 "key": "mohang.jpg" 수정
테스트 > 에러 발생. PIL 라이브러리가 없다. 다운로드하자.
인스턴스 하나 대충 만들어서 접속 > 업데이트 후 /usr/lib64/python2.7/site-packages/PIL 삭제 > ec2-user 홈 디렉터리에서 yum install -y gcc bzip2-devel ncurses-devel gdbm-devel xz-devel sqlite-devel openssl-devel tk-devel uuid-devel readline-devel zlib-devel libffi-devel 실행
pip3.7 install pillow 실행, pip3.7 install boto3 실행
이제 /usr/local/lib/python3.7/site-packages/에 생긴다. 이 경로에 있는 파일들을 /home/ec2-user/lambda_layers/python/lib/python3.7/ 디렉터리 하위에 복사 후 site-packages 디렉터리 복사
이 뒤는 놓쳤다. 다시 듣자
아무튼 에러 발생해서 내일 다시 할 듯. S3 버킷과 람다는 요금은 안 먹으니 내버려두어도 된다고 한다.
1교시 후반부(10:10~10:20) Chef 실습 구조 설명 다시 듣기
6교시 다시 듣기
8교시 실습 막바지 다시 듣기
'교육' 카테고리의 다른 글
| [63일 차] 21.10.22 : DevOps 4 (0) | 2021.10.22 |
|---|---|
| [62일 차] 21.10.21 : DevOps 3 (0) | 2021.10.21 |
| [60일 차] 21.10.19 : DevOps 1 (0) | 2021.10.19 |
| [59일 차] 21.10.18 : 개인 프로젝트 6 (0) | 2021.10.18 |
| 21.10.17 : 개인 프로젝트 5 (0) | 2021.10.17 |
댓글