Terraform을 통해 ECS에 지속적으로 전달

지속적인 납품은 우리 모두가 노력하고 있는 목표이다.나도 이렇게 했지만 장애에 부딪혔다.

내 지형 코드와 API 코드는 다른 항목에서

API 코드를 업데이트하여 ECS 서비스를 구축하고 업데이트하고 싶습니다

.

컨테이너 정의를 개별적으로 관리하고 싶지 않습니다. 너무 많은 리소스(Datadog sidecar 등)에 의존하기 때문입니다

.

API 코드에 개별적인git 분기를 사용하지 않으려는 여러 환경이 있습니다.

각 환경은 독립적으로 배포된 인프라에 대해 하나의 지점을 가집니다.

어쩌면 너도 이 문제가 있을지도 모른다.Terraform은 특정한 ECR 이미지 경로를 사용하여 용기 정의를 구축하기 때문에, 우리는 어떻게 자동으로 그것을 업데이트합니까?
이 문제를 해결할 수 있는 몇 가지 방법이 있는데, 그 중 많은 것이 this thread에서 토론되었다.하지만 오늘 나는 너희들에게 내가 이 문제를 어떻게 해결했는지 보여줄 것이다.

Docker 구축/배치 파이프 설정

먼저 ECR의 API Docker 이미지가 필요합니다.이것은 사용자가 사용하는 CI 시스템에 따라 다릅니다. 예를 들어 Azure DevOps를 사용합니다.
이미지를 구성할 때 고유한 태그를 지정하고자 합니다.이상적인 상황에서 너는 계산할 수 있는 것을 원한다.예를 들어 Azure의 내장 "BuildId"매개변수를 사용하여 이미지를 표시하도록 선택했습니다.
다음은 CI 파이프라인에서 우리가 채택한 구축 절차를 보실 수 있습니다.이미지가 생성되면 BuildId가 포함된 텍스트 파일을 생성하여 가공소재로 보냅니다.이것은 이후에 중요하게 변할 것이다.그러나 가장 중요한 것은 파라미터의 변화에 따라 환경에 더 많은 파이프를 터치해야 한다는 것입니다.

- task: Docker@2
  inputs:
    command: build
    DockerFile: "$(Build.SourcesDirectory)/Dockerfile"
    repository: ${{parameters.projectName}}
    tags: |
      $(Build.BuildId)

- task: ECRPushImage@1
  inputs:
    imageSource: "imagename"
    sourceImageName: ${{parameters.projectName}}
    sourceImageTag: "$(Build.BuildId)"
    repositoryName: ${{parameters.projectName}}
    pushTag: "$(Build.BuildId)"

- task: Bash@3
  displayName: "Upload Build Artifact of the Docker image Id"
  inputs:
    targetType: "inline"
    script: |
      # Add the build Id to a new file that will then be published as an artifact
      echo $(Build.BuildId) > .buildId
      cat .buildId

- task: CopyFiles@2
  displayName: "Copy BuildId file"
  inputs:
    Contents: ".buildId"
    TargetFolder: "$(Build.ArtifactStagingDirectory)"

- task: PublishBuildArtifacts@1
  displayName: "Publish Artifact"
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)

파이프를 생성한 후에 이 파이프를 실행해야 합니다.

SSM(시스템 관리자) 매개변수 설정

SSM은 내가 이전에 실제로 사용한 적이 없는 AWS 서비스다.그것의 매개 변수 저장 기능은 나중에 업데이트할 수 있는 변수를 저장할 수 있도록 합니다. 이 예는 docker 이미지 표시입니다.
AWS 시스템 관리자 > 애플리케이션 관리 > 매개 변수 저장소에 들어가서 새 매개 변수를 만듭니다.매개변수의 이름을 /my-api/${env}/docker-image-tag(여기서 env는 환경이며 모든 환경에 대해 이 매개변수를 복제해야 함)입니다.이것은 '문자열' 변수이고 CI가 파이프를 구축해서 만든 유일한 표시일 것입니다. 예를 들어 BuildId입니다.

배포 파이프 생성

현재, 우리는 특정 환경에서 이미지를 업데이트하는 방법을 정의해야 한다. (예:just development.우리가 어떻게 할 수 있겠어?우리의 설치로 인해 중복 작업은 상당히 적다.우리는 이미 자신의 이미지 구축을 가지고 있다.SSM 매개변수를 업데이트하여 빌드 파이핑에서 생성된 고유 태그(BuildId)를 사용하기만 하면 됩니다.
Azure에서는 단계 1에서 생성한 가공소재 트리거 파이프를 기준으로 트리거할 수 있습니다.그런 다음 세 가지 작업을 구성했습니다.

파일에서 BuildId를 가져와runners 환경에 추가

이 환경의 SSM 매개 변수를 새 BuildID

로 업데이트

이 환경을 촉발하는 인프라/지형 파이프 - 여기서 새로운 SSM 파라미터 값을 추출하여 용기 정의에 사용합니다.

SSM 매개변수를 사용하도록 Terraform 업데이트

이제 새 버전이 나올 때마다 SSM 매개 변수가 업데이트되므로 이미지 이름의 일부로 SSM 매개 변수를 사용하려면 Terraform을 설정해야 합니다.

// Import the SSM parameter
// This can be done on a module level because it depends on the environment
data "aws_ssm_parameter" "docker_image_id" {
  name = "/my-api/${var.environment}/docker-image-tag"
}

// Use it later on...
container_image = "<AWS_ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/my-api:${data.aws_ssm_parameter.docker_image_id.value}"

모두 완성!

이제 Terraform과 ECS로 완전한 연속 배치 파이프라인을 구축했습니다.다음은 시스템의 작업 원리이다

고유한 방식으로 표시된 새 ECR 이미지 생성 및 구축

구축 파이프는 어떤 방식으로 파이프의 새로운 이미지 라벨을 발표할 것을 알립니다 (Azure의 경우 구축 부품입니다)

게시 파이핑은 이미지 태그를 기반으로 SSM 매개 변수를 업데이트하고 해당 환경의 Terraform 배포 파이핑을 트리거합니다.

Terraform 신규 SSM 값 획득 및 달성

이런 방법은 두 가지 뚜렷한 결점이 있다.

여러 API를 여러 번 업데이트하면 잠금 문제가 발생할 수 있으므로 Terraform 파이프를 한 번 수동으로 실행해야 합니다.

이것은 다른 방법보다 좀 느리지만, 이것은 내가 찾을 수 있는 가장 좋은 방법이다.또한, 만약 당신의Terraform 환매 협의가 우리처럼 2분도 안 되어 배치된다면 이것은 큰 문제가 되지 않습니다.