1. 목적

💡
서버 운영중 auto-scaling으로 scale-out이 될시 모든 서버가 페이지 업데이트 되는지 확인과정을 거쳐 보자 예를 들어) 홈페이지의 이벤트 기간에 즉각적인 업데이트를 해주기 위해 sacle-out 될떄마다 EFS 를 통해 모든 서버의 페이지를 업데이트 해보자

 

2.구성
ec2 생성
  1. 기본값으로 퍼블릭의 인스턴스 생성
    → 기본적인 web구성과 efs를 mount 시켜두기 위한 목적의 테스트 인스턴스
  1. 간단 index페이지
    → 기본으로 들어가 있을 웹페이지이다.
EFS 생성

개념 참고 : https://practice.hooniworld.io/entry/AWS-EFS-개념-및-구성-방법

EFS 사용 예시

  • EFS 생성시 VPC 안의 AZ subnet당 mount targer생성
  • 두개 이상일 경우 한개만 mount target 생성 가능
  1. console 을 통하여 EFS 생성
  1. 마운트 포인트
ec2-EFS 마운트
  1. EFS의 가용영역 확인
  1. 보안그룹 설정
  1. nfs 클라이언트 설치
    sudo yum -y update  
    $  sudo reboot
    sudo yum -y install nfs-utils
  1. nfs 클라이언트가 탑재되어있으므로 nfs 이용
  1. efs 호스트 등록
    → auto-mount 를 편리하게 하기 위함 위에서 보이는 mount 포인트명은 너무 길기때문 사용될 가용영역만 지정해준다.
  1. auto mount를 위한 설정
  1. 확인
efs 파일 생성후 AMI 생성
→ 해당 마운트 point로 이동후 파일 생성 뒤 해당 인스턴스 이미지 생성
auto sacling 생성
  1. 위에서 생성된 AMI를 이용하여 시작구성 생성
  1. SSM을 사용해야 하기때문에 해당 role을 부여
    → ec2 인스턴스들이 ssm을 사용할 권한이 있어야 하므로 iam에서 역할 생성
  1. auto-scaling 생성
    → efs 사용 가용영역을 맞춰주엇다.
  2. 최소값으로 맞춰준후 이후 추가로 다시 조정하여 테스트 예정

3. 테스트
efs 동작 테스트
  1. auto-scaling으로 생성된 ec2 확인
    1. mount 확인 및 파일 확인
      → 추가로 아무 파일을 생성해보고 기존 bastion에도 적용되었나 확인
    2. 정상 mount 작동 확인
cloudwatch 이벤트 - run command 동작
  1. cloud watch를 이용해 이벤트 패턴 생성 
  1. 해당 이벤트 동작시 - scale out시 이전의 생성된 efs.html이 불러와졋는지 확인 테스트
    → 이전의 3 2 3 구성을 4 2 4로 변경시 인스턴스 추가 되기때문에 해당 인스턴스를 확인할 예정
  1. 추가 인스턴스 확인
    1. 로드밸런서로 확인시
      1. 기본 index.html 페이지
      2. efs 로 받아온 기존 인스턴스들
      3. 에러 발생

→ 최근 인스턴스가 못받아왓다 인스턴스 실행하면서 auto mount보다 run command 동작이 우선시 되어 받아오지 못했다.

lambda 이용한 - run command
  1. 람다 역할 생성 → 사용할 서비스들에 대해서 역할을 지정해주었다.
    • 람다의 모든 권한
    • ec2가 ssm 동작을 하기 위한 권한 → 코드로 ec2를 지정해서 ssm을 부여하므로
    • ssm 동작을 위한 모든 권한
  1. 람다 함수 생성
  1. 코드 작성
    1. 단일 인스턴스 run command 동작
    import json
    import boto3
    
    def lambda_handler(event, context):
        ssm_client = boto3.client('ssm')
        response = ssm_client.send_command(
            InstanceIds=['i-0e4c2788a45b4baf2'],
            DocumentName="AWS-RunShellScript",
            Parameters={'commands': ['sudo echo "<html><body>lambda test webserver6</body></html>" > /var/www/html/index.html']}, )
        
        return {
            'statusCode': 200
        }
    
    2. tag를 이용한 run command 동작
    import json
    import boto3
    ssm = boto3.client('ssm')
    
    def lambda_handler(event, context):
       
    
        ssmcommand = ssm.send_command(
    
            Targets = [
            {'Key': 'tag:Name', 
                 'Values': [
                        'ec2-efs']
                    }
                  ],
            DocumentName="AWS-RunShellScript",
            Parameters={'commands': 
    ['sudo cp -fv "<html><body>tag lambda runcommand22</body></html>" 
    > /efstest/index.html'],['sudo cp -fv /efstest/index.html /var/www/html/] }, )
        return{
            'status_code': 200
        }
  1. 이벤트 트리거 - cloudwatch 규칙
    → sacle out시 run command 동작
  1. 확인 과정
    → 람다 코드에서 내용을 변경후 작업진행해보자
  1. sacle out 동작
    → 정상적으로 run command 동작 확인

 

결론

따라서, Cloudwatch를 이용하여 SSM runcommand 를 적용하기보단 Cloudwatch Event 와 Lambda를 트리거 시키는 방식이 용이했다,
또한, ASG 구성 방식중 Launch Template을 이용하여 버전관리를 통하여 서버를 업데이트 하는 방식이 존재 하며 
해당 Template을 인스턴스 새로고침 or Warm pool 방식을 적용하면 편리할 것 이다.
 

 

 

'Automation' 카테고리의 다른 글

SSM Automation을 통한 자동화  (0) 2022.08.23
image builder 2  (0) 2021.06.16
Image Builder -golden ami 생성  (0) 2021.03.29
Lambda Ec2 start / stop Tag기반  (0) 2021.01.20

+ Recent posts