저는 평생 동안 Cloudformation을 사용하면서 이러한 6가지 교훈을 배웠습니다.

나는 함께 일하기 시작했다 구름 형성 4 년 전. 그 이후로 저는 이미 생산 중인 인프라를 포함하여 많은 인프라를 망가뜨렸습니다. 하지만 뭔가를 망칠 때마다 새로운 것을 배웠습니다. 이 경험을 통해 제가 배운 가장 중요한 교훈 중 일부를 공유하겠습니다.

레슨 1: 변경사항을 배포하기 전에 테스트

나는 이 교훈을 일을 시작한 직후에 배웠다. 구름 형성. 그때 정확히 무엇을 깨뜨렸는지는 기억나지 않지만, 다음 명령을 사용한 것은 확실히 기억합니다. AWS 클라우드포메이션 업데이트. 이 명령은 배포될 변경 사항을 확인하지 않고 단순히 템플릿을 롤아웃합니다. 모든 변경 사항을 배포하기 전에 테스트해야 하는 이유에 대해서는 설명이 필요하지 않다고 생각합니다.

이 실패 후 나는 즉시 바뀌었다 배포 파이프 라인, 업데이트 명령을 다음 명령으로 바꿉니다. 생성-변경-세트

# OPERATION is either "UPDATE" or "CREATE"
changeset_id=$(aws cloudformation create-change-set 
    --change-set-name "$CHANGE_SET_NAME" 
    --stack-name "$STACK_NAME" 
    --template-body "$TPL_PATH" 
    --change-set-type "$OPERATION" 
    --parameters "$PARAMETERS" 
    --output text 
    --query Id)

aws cloudformation wait 
    change-set-create-complete --change-set-name "$changeset_id"

변경 세트가 생성되면 기존 스택에는 영향을 주지 않습니다. update 명령과 달리 변경 집합 접근 방식은 실제 배포를 트리거하지 않습니다. 대신 배포 전에 검토할 수 있는 변경 사항 목록을 생성합니다. aws 콘솔 인터페이스에서 변경 사항을 볼 수 있습니다. 하지만 가능한 모든 것을 자동화하고 싶다면 CLI에서 확인하세요.

# this command is presented only for demonstrational purposes.
# the real command should take pagination into account
aws cloudformation describe-change-set 
    --change-set-name "$changeset_id" 
    --query 'Changes[*].ResourceChange.{Action:Action,Resource:ResourceType,ResourceId:LogicalResourceId,ReplacementNeeded:Replacement}' 
    --output table

이 명령은 다음과 유사한 출력을 생성해야 합니다.

--------------------------------------------------------------------
|                         DescribeChangeSet                        |
+---------+--------------------+----------------------+------------+
| Action  | ReplacementNeeded  |      Resource        | ResourceId |
+---------+--------------------+----------------------+------------+
|  Modify | True               |  AWS::ECS::Cluster   |  MyCluster |
|  Replace| True               |  AWS::RDS::DBInstance|  MyDB      |
|  Add    | None               |  AWS::SNS::Topic     |  MyTopic   |
+---------+--------------------+----------------------+------------+

Action이 변경된 부분에 특별한 주의를 기울이세요. 교체, . 아니면 어디서 교체 필요 - 참. 이는 가장 위험한 변경이며 일반적으로 정보 손실로 이어집니다.

변경 사항이 검토되면 배포할 수 있습니다.

aws cloudformation execute-change-set --change-set-name "$changeset_id"

operation_lowercase=$(echo "$OPERATION" | tr '[:upper:]' '[:lower:]')
aws cloudformation wait "stack-${operation_lowercase}-complete" 
    --stack-name "$STACK_NAME"

레슨 2: 스택 정책을 사용하여 상태 저장 리소스가 교체되거나 제거되는 것을 방지

단순히 변경 사항을 보는 것만으로는 충분하지 않은 경우도 있습니다. 우리는 모두 인간이고 모두 실수를 합니다. 변경 세트를 사용하기 시작한 직후 팀원이 자신도 모르게 배포를 수행하여 데이터베이스가 업데이트되었습니다. 테스트 환경이었기 때문에 나쁜 일은 없었습니다.

스크립트가 변경 사항 목록을 표시하고 확인을 요청했지만 변경 사항 목록이 너무 커서 화면에 맞지 않아 바꾸기 변경을 건너뛰었습니다. 그리고 이는 테스트 환경에서는 일반적인 업데이트였기 때문에 변경 사항에 큰 관심을 두지 않았습니다.

교체하거나 제거하고 싶지 않은 리소스가 있습니다. 이는 RDS 데이터베이스 인스턴스 또는 Elasticsearch 클러스터 등과 같은 상태 저장 서비스입니다. 수행 중인 작업에서 해당 리소스를 삭제해야 하는 경우 aws가 자동으로 배포를 거부하면 좋을 것입니다. 다행스럽게도 cloudformation에는 이를 수행하는 방법이 내장되어 있습니다. 이를 스택 정책이라고 하며 이에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 선적 서류 비치:

STACK_NAME=$1
RESOURCE_ID=$2

POLICY_JSON=$(cat <<EOF
{
    "Statement" : [{
        "Effect" : "Deny",
        "Action" : [
            "Update:Replace",
            "Update:Delete"
        ],
        "Principal": "*",
        "Resource" : "LogicalResourceId/$RESOURCE_ID"
    }]
}
EOF
)

aws cloudformation set-stack-policy --stack-name "$STACK_NAME" 
    --stack-policy-body "$POLICY_JSON"

레슨 3: 비밀 매개변수로 스택을 업데이트할 때 UsePreviousValue 사용

RDS mysql 엔터티를 생성할 때 AWS에서는 MasterUsername 및 MasterUserPassword 제공을 요구합니다. 소스 코드에 비밀을 유지하지 않는 것이 더 낫고 모든 것을 완전히 자동화하고 싶었기 때문에 배포하기 전에 자격 증명을 s3에서 가져오고 자격 증명을 찾을 수 없는 경우 새 자격 증명을 생성하는 "스마트 메커니즘"을 구현했습니다. s3 에 저장됩니다.

그러면 이러한 자격 증명이 cloudformation create-change-set 명령에 매개변수로 전달됩니다. 스크립트를 실험하는 동안 s3에 대한 연결이 끊어졌고 내 "스마트 메커니즘"이 이를 새 자격 증명을 생성하는 신호로 처리했습니다.

프로덕션에서 이 스크립트를 사용하기 시작했는데 연결 문제가 다시 발생하면 새 자격 증명으로 스택이 업데이트됩니다. 이 특별한 경우에는 나쁜 일이 일어나지 않습니다. 그러나 저는 이 접근 방식을 포기하고 스택을 생성할 때 자격 증명을 한 번만 제공하는 다른 접근 방식을 사용하기 시작했습니다. 나중에 스택을 업데이트해야 할 때 매개변수의 비밀 값을 지정하는 대신 간단히 다음을 사용합니다. UsePreviousValue=true:

aws cloudformation create-change-set 
    --change-set-name "$CHANGE_SET_NAME" 
    --stack-name "$STACK_NAME" 
    --template-body "$TPL_PATH" 
    --change-set-type "UPDATE" 
    --parameters "ParameterKey=MasterUserPassword,UsePreviousValue=true"

레슨 4: 롤백 구성 사용

제가 함께 일했던 다른 팀이 이 기능을 사용했습니다. 구름 형성~라고 불리는 롤백 구성. 나는 이전에 그것을 본 적이 없었으며 그것이 내 스택 배포를 더욱 멋지게 만들 것이라는 것을 빨리 깨달았습니다. 이제는 cloudformation을 사용하여 람다 또는 ECS에 코드를 배포할 때마다 이를 사용합니다.

작동 방식: 귀하가 지정합니다. CloudWatch 경보 매개변수에서 --롤백 구성변경 세트를 생성할 때. 나중에 일련의 변경 사항을 실행하면 aws는 최소 XNUMX분 동안 경보를 모니터링합니다. 이 시간 동안 경보 상태가 ALARM으로 변경되면 배포를 롤백합니다.

다음은 템플릿 발췌의 예입니다. 구름 형성내가 만드는 곳 클라우드워치 알람, 클라우드 로그의 오류 수로 클라우드 사용자 측정항목을 추적합니다. 측정항목은 다음을 통해 생성됩니다. 메트릭 필터):

Resources:
  # this metric tracks number of errors in the cloudwatch logs. In this
  # particular case it's assumed logs are in json format and the error logs are
  # identified by level "error". See FilterPattern
  ErrorMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: !Ref LogGroup
      FilterPattern: !Sub '{$.level = "error"}'
      MetricTransformations:
      - MetricNamespace: !Sub "${AWS::StackName}-log-errors"
        MetricName: Errors
        MetricValue: 1
        DefaultValue: 0

  ErrorAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-errors"
      Namespace: !Sub "${AWS::StackName}-log-errors"
      MetricName: Errors
      Statistic: Maximum
      ComparisonOperator: GreaterThanThreshold
      Period: 1 # 1 minute
      EvaluationPeriods: 1
      Threshold: 0
      TreatMissingData: notBreaching
      ActionsEnabled: yes

지금 경보 다음과 같이 사용할 수 있습니다. 롤백 도구 상자를 실행할 때 트리거:

ALARM_ARN=$1

ROLLBACK_TRIGGER=$(cat <<EOF
{
  "RollbackTriggers": [
    {
      "Arn": "$ALARM_ARN",
      "Type": "AWS::CloudWatch::Alarm"
    }
  ],
  "MonitoringTimeInMinutes": 1
}
EOF
)

aws cloudformation create-change-set 
    --change-set-name "$CHANGE_SET_NAME" 
    --stack-name "$STACK_NAME" 
    --template-body "$TPL_PATH" 
    --change-set-type "UPDATE" 
    --rollback-configuration "$ROLLBACK_TRIGGER"

레슨 5: 최신 버전의 템플릿을 배포해야 합니다.

최신 버전이 아닌 cloudformation 템플릿을 배포하는 것은 쉽지만 그렇게 하면 많은 피해를 입게 됩니다. 이런 일이 한 번 일어났습니다. 개발자가 Git의 최신 변경 사항을 푸시하지 않았고 자신도 모르게 이전 버전의 스택을 배포했습니다. 이로 인해 이 스택을 사용하는 애플리케이션에 가동 중지 시간이 발생했습니다.

커밋하기 전에 브랜치가 최신인지 확인하기 위해 검사를 추가하는 것만큼 간단한 것도 괜찮습니다(git이 버전 제어 도구라고 가정).

git fetch
HEADHASH=$(git rev-parse HEAD)
UPSTREAMHASH=$(git rev-parse master@{upstream})

if [[ "$HEADHASH" != "$UPSTREAMHASH" ]] ; then
   echo "Branch is not up to date with origin. Aborting"
   exit 1
fi

교훈 6: 바퀴를 재발명하지 마세요

다음을 사용하여 배포하는 것처럼 보일 수 있습니다. 구름 형성 - 그것은 간단합니다. aws cli 명령을 실행하는 bash 스크립트가 필요합니다.

4년 전 저는 aws cloudformation create-stack 명령이라는 간단한 스크립트로 시작했습니다. 곧 대본은 더 이상 단순하지 않게 되었습니다. 배운 각 교훈은 스크립트를 점점 더 복잡하게 만들었습니다. 어려울 뿐만 아니라 버그도 많았습니다.

저는 현재 소규모 IT 부서에서 근무하고 있습니다. 경험에 따르면 각 팀에는 Cloudformation 스택을 배포하는 고유한 방법이 있습니다. 그리고 그것은 나쁘다. 모두가 같은 접근 방식을 취하면 더 좋을 것입니다. 다행히 Cloudformation 스택을 배포하고 구성하는 데 도움이 되는 많은 도구가 있습니다.

이 수업은 실수를 피하는 데 도움이 될 것입니다.

출처 : habr.com