AWS에 위고 블로그 호스팅

얘는 어떻게 시작했어?

몇 달 전, 내가 개인 블로그를 회복하기로 결정했을 때, 나는 내가 신속하고 작으며, 유지보수할 시간이 필요 없는 물건을 원한다고 확신했다.
이것은 나의 선택 범위를 정적 사이트 프레임워크, 예를 들어 Hugo와 Jekyll로 좁힌다.
후자는 루비 위에 세워져 있었고, 나는 루비를 별로 좋아하지 않았기 때문에 위고가 우승했다.
이 문제를 해결한 후에 나는 다른 결정을 할 것이다.제가 뭘로 진행을 해야 될까요?
일단 우과를 들면, 너 have a lot of options, Netlify, Github Pages, Gitlab AWS Amplify, S3, 심지어 그것을 VPS 실례 LightSail 위에 놓을 수 있다.
앞에서 말한 바와 같이 저는 낮은 유지보수 업무를 찾고 있으며 가능하면 원가 효율이 높은 해결 방안을 찾고 있습니다.
내 저장소가 Github에 있을 것이기 때문에 후보 목록은 다음과 같습니다.

Github 페이지(Github 작업과 결합할 수 있습니다. 한번 해보고 싶어서)

AWS Amplify(상기와 같은 이유로 오랫동안 연구했다)

맞춤형 솔루션S3 static hosting

지난 몇 년 동안 AWS를 사용해 왔기 때문에 Github의 생각을 알고 빠른 확대 테스트를 했습니다.Hugo docs on deploying to Amplify는 당신이 이 길을 따라 기울어지고 있다면 좋은 시작이다.
괜찮은 거 하나 더 있어 AWS blog post combining Hugo with Cloud9 and Amplify.
여러 프레임워크를 지원하는 다양한 사이트나 응용 프로그램을 구축할 수 있는 아주 좋은 서비스로 보이지만, Amplify 문서 자체가 지적한 바와 같이, 이것은 전방 개발자를 돕는 데 목적을 두고 있다.
나는 infra 사람이기 때문에 개발자 중심인 것 같다.

보기에 어떠하다

이 문제를 해결한 후, 나의 해결 방안은 형태를 갖추기 시작했고, 결국은 이렇게 보였다.

나는 두 개의 Github 저장소가 있는데 하나는 블로그 인프라를 저장하는terraform 코드이고 다른 하나는 Hugo로 만든 실제 블로그 내용을 저장하고 있다.
이 두 저장소는 모두 웹훅이 있는데, 메인 지점으로 전송된 후, 두 개의 AWS Code Build 프로젝트를 시작했는데, 하나는 terraform 코드를 사용하고, 다른 하나는 블로그 내용을 나의 공공 S3 Bucket에 발표했다.
토론 중인 S3 버킷 앞에는 Amazon Cloud Front의 발행판과 AWS 인증서 관리자(ACM)가 제공하는 SSL 인증서가 있다.최종 사용자는 Route53을 통해 사이트 주소를 해석하는데 거기에 우리는 공공 위탁 관리 구역이 있고 클라우드 Front 분배 기록이 있다.

모든 것을 지형화하다

이미 지적한 바와 같이, 이 모든 것은 terraform 을 통해 만들어진 기초 구조 코드 (IaC) 이다.
내가 언급해야 할 것은 내가 여기서 지름길을 걸어서 자신의 코드를 작성하지 않고 임무를 완성하는 데 Nickolas Armstrong's 코드를 사용해서 약간의 변경과 보충을 했다.만약 네가 0에서 시작한다면, 그의 repo 는 매우 유용해서, 원래대로 사용할 수 있다.
그러나 암호화와 로그 기록을 사용하는 상태 저장통이 있기 때문에 이 부분 코드를 사용하지 않았습니다.
또한 그의 블로그 게시물에는 인증서 검증과 로트 53 기록을 수동으로 진행 중이어서 내가 직접 이 글을 썼다.
내 acm.tf는 이렇게 보입니다.

# ACM Certificate
resource "aws_acm_certificate" "blog" {
  provider          = aws.us-east-1
  domain_name       = local.blog_domain_name
  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}


resource "aws_route53_record" "blog_cert" {
  for_each = {
  for dvo in aws_acm_certificate.blog.domain_validation_options : dvo.domain_name => {
    name   = dvo.resource_record_name
    record = dvo.resource_record_value
    type   = dvo.resource_record_type
  }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 300
  type            = each.value.type
  zone_id         = data.terraform_remote_state.bootstrap.outputs.route53_hosted_zone_id
}

resource "aws_acm_certificate_validation" "blog_cert" {
  provider          = aws.us-east-1
  certificate_arn         = aws_acm_certificate.blog.arn
  validation_record_fqdns = [for record in aws_route53_record.blog_cert : record.fqdn]
}

나는 클라우드 패널에 이 부분을 추가했다.terraform을 사용하여 CloudFront 릴리스의 Route53 레코드를 만들려면 tf 파일을 사용합니다.

resource "aws_route53_record" "blog" {
  zone_id         = data.terraform_remote_state.bootstrap.outputs.route53_hosted_zone_id
  name    = var.blog_name
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.site.domain_name
    zone_id                = aws_cloudfront_distribution.site.hosted_zone_id
    evaluate_target_health = false
  }
}

자동 배포

지금까지 줄곧 괜찮았다.
만약 네가 나의 보문과 니콜라스의 보문을 결합한다면, 너는 지금 운영하는 우과 사이트를 가지고 있을 것이다.
그러나 제 해결 방안 그림에서 볼 수 있듯이 저는 블로그 콘텐츠 저장소로 전송된 후에 자동으로 블로그 게시물을 만들고 싶습니다.
이를 위해서는 세 가지가 필요합니다.

생성 CodeBuild project with a Github source repository provider (this requires authentication to GitHub)

A webhook to trigger the CodeBuild project automatically

코드 구축 프로젝트에 대한 명령 그룹 제공buildspec file에서 명령 그룹을 정의함)

It should be noted that as pointed out in the codebuild_webhook terraform resource documentation the webhook requires OAuth authorization from CodeBuild to Github,
which could be done manually in the Console prior to the terraform deployment of the resource.

웹훅의 terraform 코드 세그먼트는 다음과 같습니다.

resource "aws_codebuild_webhook" "auto_update_blog" {
  project_name = module.hugo.codebuild_name

  filter_group {
    filter {
      type    = "EVENT"
      pattern = "PUSH"
    }

    filter {
      type    = "HEAD_REF"
      pattern = "main"
    }
  }
}

나의 건축 규격.yml 파일에는 다음과 같은 내용이 있습니다.

version: 0.2

env:
  parameter-store: {}

phases:
  install:
    commands:
      - echo Install dependencies...
      - yum -y install git
      - echo Downloading Hugo ${HUGO_VERSION}
      - wget -q https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz
      - echo Extracting Hugo binary
      - tar -zxvf hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz hugo
      - mv hugo /usr/local/bin
      - rm -f hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz
    finally:
      - echo Installation done
  build:
    commands:
      - echo Entering the build static content phase
      - echo Build started on `date`
      - cd $CODEBUILD_SRC_DIR
      - git submodule init
      - git submodule update --recursive
      - /usr/local/bin/hugo
      - ls -la public
    finally:
      - echo Building the static HTML files has finished
  post_build:
    commands:
      - echo Entering the publish content phase
      - /usr/local/bin/hugo deploy --maxDeletes -1 --invalidateCDN
      - echo Publishing has finished
artifacts:
  files: []
cache:
  paths: []

봐라, 네가 앞으로 유일하게 해야 할 일은 git 추가,git 제출,git 전송이다. 이것이 바로 이 블로그 글의 인터넷 결말이다.

링크 첨부

만약 당신이 다른 방식을 채택하고 싶다면, 나는 당신이 아래의 블로그를 발표할 것을 건의합니다.

니콜라스 암스트롱 저Static hugo site with terraform

Ilya Bezdelev

How to build a Hugo website with AWS Lambda저자: 치프 졸러

Complete CI/CD for Hugo on AWS with Github Actions 내 동료와 친구 플로리안 발레리