20220426 TIL

CI/CD / GitHub Action

• GitHub Action은 간단하게는 서버에 소스를 배포하는 서비스 입니다.
• CI = Continuous Integration
• CD = Continuous Deployment

[CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념

For example, every time someone creates a release from GitHub on a specified branch then automatic commands get executed.

→ Github 액션이 자동으로 검사

https://medium.com/scalereal/ci-cd-with-github-action-deploying-to-amazon-elastic-container-service-5f5877186216

요즘 트랜드는 CI/CD의 통합입니다. 소스저장소와 배포시스템을 통합하는 것입니다. 아키텍처의 변화로 작아진 어플리케이션들을 부담없이 자주 배포하기 위함이죠.

⇒ 계속적으로 소스코드를 통합하면서 delivery를 할 수 있음

Github action(CD) ⇒ 바로 인프라를 업데이트

예전에는 사람들이 결재 많이 하다가 간신히 배포했는데, 요즘은 마이크로 서비스 아키텍쳐로 잘게 찢어져 있기 때문에 배포를 계속 하면서 진행

• CD 없이 CI만 하다보면 그게 쌓여서 오히려 감당 안될 수도

 

git action 초기설정

파이참 프로젝트 폴더내에

.github/workflows 폴더 생성하고 main.yml 파일 생성

이 때 폴더 명이 github 가 아니라 온점을 포함한 .github로 해야 정상작동 된다

그 안에 다음의 내용 집어 넣음

그리고 깃허브에 push

레포지토리의 action탭에 들어가면 뭔가가 돌아가고 있는걸 볼 수 있음

<아래 코드 바탕으로 설명>

• on : action이 언제 일어나는지?
  • main 브랜치에 push될 때

name: my-front
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: 'ap-northeast-2'

    steps:
      - name: Checkout source code.
        uses: actions/checkout@master

      - name: Upload binary to S3 bucket
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --exclude '*' --include 'index.html'
        env:
          AWS_S3_BUCKET: ${{ secrets.BUCKET_NAME }}

      - name: Invalidate cache CloudFront
        uses: chetan/invalidate-cloudfront-action@master
        env:
          DISTRIBUTION: ${{ secrets.DISTRIBUTION_ID }}
          PATHS: '/index.html'
        continue-on-error: true

• 여기서 secrets.대문자 라고 되어있는 부분들이 있음
• 말그대로 보안사항이므로 코드에 넣으면 유출이 될 수 있기 때문에 github에서 secret으로 등록을 해준다.
  1. Settings 카테고리 - secrets - actions
  2. name에 placeholder설정 되어있음
     1. 거기에 secrets.대문자 값을 넣고
     2. value란에는aws에서 만들어진 key나 액세스 값을 입력
     3. add secret 하면 끝
     distribution ID는 cloudfront의 ID값 넣어주면 됨
     • 이거 해도 안되면 key를 IAM가서 재발급 받고
     • 중요! ⇒ 터미널 열고 aws configuration 쳐서 key를 재 등록하자

cloudFront → CDN과 유사

CDN은 무엇이길래 CloundFront가 유사한 기능을 하는 걸까

S3를 사용해서 example.com 도메인으로 글로벌 서비스를 해야하는 상황이라고 해보자

S3의 버킷은 생성시 리전이 정해져 있다.

서울 리전에 있는 호스팅 기능을 이용해서 미국에 서비스 한다고 하면 엄청나게 사이트가 늦게 뜰것

그러면...리전마다 똑같은 S3버킷을 생성해줘야 할까...? 돈만 더 들음...

CloudFront는 정적 파일들을 캐싱해주는 서버

→ 우리가 서울에서 업로드한 파일을 배치시켜줌=캐싱해줌

→ 근데 중국에서 들어오면 중국에서 가까운 곳으로, 미국에서 들어오면 미국에서 가까운 곳으로

→ 그런 캐싱 서버에 접속을 하게 하는 방식이 CDN

→ 근데 CloudFront가 이점은 더 많을 수 있음

기존에 글로벌 서비스 하는 곳들은 Akamai나 CD네트웍스를 이용했는데, 더 비쌈

이와 같이 내가 S3에 파일 심어놓고 서버에 올리고 CloudFlare 연결하면

요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생

• S3에 올린 파일 직접 접속시 과금되는게 이걸 통하면 적게 부과될 수도 있다고 함
• edge 서비스에 배포가 추가로 이루어져야하기 때문에 바로바로는 안될 수 있지만, 글로벌 서비스할 때 큰 장점이 있을 수 있음
• ID 값이 생성되는데 CloudFront의 유니크한 ID라고 생각하면 됨
• 도메인도 생성 됨 → 이제 S3가 아닌 여기로 접속
• 접속시 Access Denied 라고 나오면 뭔가 잘못된 상황이므로, 옵션을 수정하러 가자
  • CloudFront - 배포 - 링크로된 ID값 선택 - 일반탭 - 설정 - 편집
  • default root object(기본값 루트 객체) : 어떤 object 파일이 호출되는지 지정해줘야 함(초기 메인페이지로 사용할 파일명)
• Cloudfront에서는 region 선택 없이 글로벌로 해도 됨

 

 

VPC(Virtual Private Cloud)

Amazon Virtual Private Cloud

• 네트워크는 어차피 IDC 센터, 컴퓨팅 서버 자원이 있는 곳에서 연결하는 것인데 왜 VPC같은 네트워크를 사용하는가?ex) VPC를 두 개 만들어서 하나는 인터넷에 연결되는 public PC, 하나는 인터넷에 연결되고 외부와 차단된 private한 네트웤을 가지고 싶을 때(보안이 철저하게 지켜져야 하는 경우→ private VPC)
• ⇒ 내 클라우드 내에서 논리적인 네트워크를 사용하고 싶을 때
• AWS 계정을 만들면 기본적으로 디폴트 VPC 하나가 생성이 되고, 외부 인터넷과 연동이 되어 있는 VPC가 생성이 됨

IPV4 이라고 나와있는 곳에 있는 게 VPC 내부에서 사용되는 IP

<aside> 👉 IPV4 CIDR은 IP의 범위를 지정하는 방법입니다. 예를 들어 172.32.0.0/16 이라고 하면 IP의 범위가 172.32.0.0 ~ 172.32.255.255 지정되게 됩니다.

</aside>

 

ELB 연결 시 유의사항

보안그룹 설정하면서 인바운드 규칙을 설정하지 않아도 설정은 되지만, 나중에 DNS 주소가 작동하지 않을 수 있으므로사용자 TCP 하고 포트 80 으로 설정하기