배포
빅뱅 배포
- 애플리케이션 전체 또는 대부분을 한 번에 업데이트
롤링 업데이트
- 점차 새로운 버전으로 바꿔나가는 것
- 두가지 업데이트가 공존함
- 업데이트 시간이 길다
Blue/Green
- 서비스되고 있는 장비와 되고 있지 않은 장비를 나눠놓음
- 똑같은 장비가 두 대가 있어야 됨
장점: 업데이트 시간과 롤백시간이 굉장히 짧다
단점: 자원을 많이 사용한다
Canary
- 일부 사용자만 새로운 버전을 사용하도록
- 점점 사용자를 늘려가는 과정
ex) 시험 테스트
장점:
단점: 많은 양의 하드웨어 필요
롤링과 ,카나리, blue/green 차이점
- 실제 업데이트 > 카나리, blue/green
- 롤링업데이트는 현위치 배포, 단계적 배포
*In place update
CodeDeploy를 이용한 현재 위치 배포
- CodeDeploy란 애플리케이션 배포 자동화 서비스
*인스턴스, 람다, ec2 내가 만든 소스코드가 포함
- 서버에서 실행되고 저장소에 있는 리소스를 배포
실행 중 배포(in place)
blue/green 배포 : 두 개의 쌍을 만들어놓고 현재버전, 다음버전 소스코드 배치
EC2에 배포
CodeDeploy에서 사용할 역할 생성
- IAM > 역할생성 > CodeDeploy
EC2 인스턴스에 적용할 정책과 역할 생성
*EC2는 서비스를 사용자에게 제공 : 정책과 역할 (S3버킷에 업로드한 새로운 버전의 코드를 가져와서 실행)
>S3 버킷과 객체를 읽을 수 있는 권한이 필요
- IAM > 정책생성
*반드시 정책을 통해서 부여해야한다.
- 역할 생성 > EC2 > 만들었던 권한 부여
CodeDeploy로 소스코드 배포 가능한 인스턴스 생성
- 애플리케이션 코드가 없는 인스턴스 생성 > 해당 인스턴스를 이용해서 서비스환경(오토스케일링, 로드밸런싱 구성)
*인스턴스가 실행될 때 CodeDeploy를 통해서 소스코드를 가져오도록 설정
기본 vpc 생성
인스턴스 생성 > 22번+80번 포트 허용하도록 설정
*사용자 데이터
bitvise ssh에서 sudo rm -rf /var/www/html/*
인스턴스 > 이미지생성
AutoScailing 그룹 생성
*로드밸런서 대상그룹 생성 > 보안그룹을 22번,80번포트 모두 붙을 필요는 없기때문에
보안 그룹을 새로 만드는게 원칙 (지금은 편의상)
>>> 여기까지 서비스 인프라 구성
github > sourcecode, appsec.yml
*yaml 파일 들여쓰기는 반드시 스페이스로 처리 (tab사용시 에러)
GitHub 레포지터리 생성 후 소스코드(web page)를 commit
깃 허브 사이트 > new > 레포지터리
레포지터리에 index.html 파일 추가
> create a new file > 소스코드 삽입 후 생성
레포지터리에 appspec.yml 파일 추가
- CodeDeploy Agent가 수행할 내용을 기술한 파일
> Add file > Create new file
레포지터리에 scripts/set_owner 파일 추가
> add file > new file > 코드 삽입 후 생성
배포할 레포지터리의 주소와 커밋 ID(커밋 버전) 확인
> 레포지터리 주소 > 본인 레포지터리 주소
> 커밋 id 확인
CodeDeploy 애플리케이션 생성
- codedeploy 대시보드 > 애플리케이션 생성
> EC2/온프레미스
생성 확인 후에 배포그룹 생성
- 배포 대상(개발, 테스트, 운영 등) 과 배포 방법(한번에, 반반, 단계적 등) 정의를 생성
> 배포유형(현재 위치: 현 인프라, 인스턴스에 소스코드 바꾸는 방법)
*블루/그린 새로운 코드를 올리고 현재 코드와 바꿔치기, 노드밸런스에 주소
배포 생성
- CodeDeploy agent 제대로 실행되지 않음
> EC2 codedeploy agent가 동작하기 위한 EC2에 역할 부여해야함
EC2 역할(CodeDeployEC2Role) 부여
> 인스턴스 대시보드에서 보안 > IAM 역할 수정
각 인스턴스 ssh 에 > sudo systemctl restart codedeploy-agent
후에 다시 재배포
- beforeblocktraffic 성공확인 : 로드 밸랜서의 요청 각 인스터들에게 트래픽 전달, 업데이트 하는 트래픽이 들어오면 안되고 트래픽을 막는 것이 blockTraffic
CodeDeployEC2Role 역할에 불필요한 권한 삭제
- S3 버킷과 파일을 읽을 수 있는 권한 부여 > s3 관련 권한 정책 삭제
>> CodeDeployEC2Policy-038 에서 s3권한 삭제
ASG의 용량을 0으로 설정해서 기존에 생성된 인스턴스를 모두 종료
EC2 인스턴스에 역할이 부여되지 않아서 에이전트 동작하지 않는 문제
>> 시작 템플릿을 수정 > 인스턴스에 역할 하도록 수정
시작템플리 수정 > 새로운 버전 생성
ASG의 용량을 2로 변경 > 새롭게 생성된 인스턴스에 에이전트가 정상적으로 동작하는 것 확인
IAM > 역할 > CodeDeployEC2Policy-038 제거
>> 신뢰관계만 남게됨,
AutoScailing 그룹 편집
- 2개 씩되 있는 용량을 0으로 수정
AMI 생성을 위해서 실행했던 인스턴스 종료(불필요 인스턴스 정리)
시작 템플릿 > 템플리 수정
- 고급 세부 정보에서 역할 설정
asg > 시작 템플릿에서 버전 최신(2)로 변경
세부정보에서 용량 2로 변경
- 인스턴스 2개 다시 생성
- ELB의 DNS 이름으로 접근
* codedeploy 실행중이면 인스턴스 실행 안됨
- 애플리케이션 다시 생성
다시 배포하면 같은 결과로 깃허브에 있는 코드 반영 확인
ASG 용량을 3개로 변경
삭제 과정
codedeploy > asg > elb > 대상그룹 > 시작템플릿 > AMI 등록 취소 > 스냅샷 > 보안그룹 > vpc > 역할, 정책 삭제
*ASG 삭제시에 용량 0으로 업데이트 한 뒤에 ASG 삭제
SK 쉴더스 클라우드 보안 가이드
- 운영 관리: 암호화
- 로그를 남기는 것 로그가 보호되어야 함.
로그 파일의 개인정보 유출 가능성
중요정보는 로그 암호화
키페어
- puttygen으로
- ec2 접근 할경우 key pair(pem)으로 접근
> 키파일 내 pc에 저장하는 것은 옳지 않음
> 공개된 절차를 통해서 보관되어야 함
점검가이드, 보안가이드 만들어보기
'수업' 카테고리의 다른 글
| 12/12 : burp Academy (0) | 2023.12.12 |
|---|---|
| 12/11 : burp Academy (0) | 2023.12.11 |
| 12/7 : 서버리스 아키텍처 (0) | 2023.12.07 |
| 12/6: AWS RDS (1) | 2023.12.05 |
| 12/5 :AWS 명령어, CLI 이용 (0) | 2023.12.05 |