1. 목적

💡

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

2.구성

ec2 생성

기본값으로 퍼블릭의 인스턴스 생성

→ 기본적인 web구성과 efs를 mount 시켜두기 위한 목적의 테스트 인스턴스

간단 index페이지
→ 기본으로 들어가 있을 웹페이지이다.

EFS 생성

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

EFS 사용 예시

EFS 생성시 VPC 안의 AZ subnet당 mount targer생성

두개 이상일 경우 한개만 mount target 생성 가능

console 을 통하여 EFS 생성

마운트 포인트

ec2-EFS 마운트

EFS의 가용영역 확인

보안그룹 설정

nfs 클라이언트 설치

sudo yum -y update  
$  sudo reboot
sudo yum -y install nfs-utils

nfs 클라이언트가 탑재되어있으므로 nfs 이용

efs 호스트 등록
→ auto-mount 를 편리하게 하기 위함 위에서 보이는 mount 포인트명은 너무 길기때문 사용될 가용영역만 지정해준다.

auto mount를 위한 설정

확인

efs 파일 생성후 AMI 생성

→ 해당 마운트 point로 이동후 파일 생성 뒤 해당 인스턴스 이미지 생성

auto sacling 생성

위에서 생성된 AMI를 이용하여 시작구성 생성

SSM을 사용해야 하기때문에 해당 role을 부여
→ ec2 인스턴스들이 ssm을 사용할 권한이 있어야 하므로 iam에서 역할 생성

auto-scaling 생성
→ efs 사용 가용영역을 맞춰주엇다.
최소값으로 맞춰준후 이후 추가로 다시 조정하여 테스트 예정

3. 테스트

efs 동작 테스트

auto-scaling으로 생성된 ec2 확인

mount 확인 및 파일 확인
→ 추가로 아무 파일을 생성해보고 기존 bastion에도 적용되었나 확인
정상 mount 작동 확인

cloudwatch 이벤트 - run command 동작

cloud watch를 이용해 이벤트 패턴 생성

해당 이벤트 동작시 - scale out시 이전의 생성된 efs.html이 불러와졋는지 확인 테스트
→ 이전의 3 2 3 구성을 4 2 4로 변경시 인스턴스 추가 되기때문에 해당 인스턴스를 확인할 예정

추가 인스턴스 확인

로드밸런서로 확인시
1. 기본 index.html 페이지
2. efs 로 받아온 기존 인스턴스들

3. 에러 발생

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

lambda 이용한 - run command

람다 역할 생성 → 사용할 서비스들에 대해서 역할을 지정해주었다.
- 람다의 모든 권한
- ec2가 ssm 동작을 하기 위한 권한 → 코드로 ec2를 지정해서 ssm을 부여하므로
- ssm 동작을 위한 모든 권한

람다 함수 생성

코드 작성

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
    }

이벤트 트리거 - cloudwatch 규칙
→ sacle out시 run command 동작

확인 과정
→ 람다 코드에서 내용을 변경후 작업진행해보자

sacle out 동작

→ 정상적으로 run command 동작 확인

결론

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

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

hyupLEE

auto-scaling scale-out시 run-command동작

1. 목적

결론

'Automation' 카테고리의 다른 글

+ Recent posts

티스토리툴바