GitHub Actions, AWS Elastic Container Registry(ECR)를 이용한 배포 자동화 (youtube.com)

 

위 영상을 참고하여 아래 github workflow CI기본 지식을 바탕으로

CI공부 : Github workflow(깃헙 워크플로우) (tistory.com)

 

CI공부 : Github workflow(깃헙 워크플로우)

깃헙에서 CI(Continuous Integration)을 하려면 .gitub 폴더 뒤에 workflows를 우선 만들어야 한다. 그 다음에 Actions 탭에가서 New workflow 버튼을 누른다. 필자는 Java with Gradle로 workflow를 만들예정이다. 해당 Con

iamipro.tistory.com

 

workflows 폴더에 depoly.yml 파일로 하기 배포라인을 작성하였다.

name: Create and publish a Docker image to AWS ECR, Deploy to Cloudtype

on:
  push:
    branches:
      - master

env:
  REGISTRY: ${{ secrets.AWS_ECR_REGISTRY }}
  IMAGE_NAME: test

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ secrets.AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha
      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

      - name: Deploy to Cloudtype
        uses: cloudtype-github-actions/deploy@v1
        with:
          token: ${{ secrets.CLOUDTYPE_TOKEN }}
          project: iamipro/pharm
          stage: main
          yaml: |
            name: pharmacy-app
            app: container
            options:
              ports: 8080
              image: ${{ steps.meta.outputs.tags }}

영상에도 나와 있지만

위의 보안을 위한 secrets 키는 

깃헙의 Settings탭에 가서

Secrets and variables - Actions에 가서

설정을 해둘수 있다.

 

위 영상을 따라 확인해보니 배포작업이 모두 잘 작동되었다.

 

AWS의 ECR에 가보면 private repository에 

test 리포지토리를 만들었는데

아래와 같이 이미지가 잘 들어감을 알 수 있다.

 

LIST

테스트를 위해서 만드는데

제일 유의해야 하는게 RDS의 모니터링 내지는, 스냅샷 , 자동백업을 꺼야한다..

안그러면 아래와 같이 일주일만에 갑자기 요금 폭탄을 보기 된다...

 

EC2에서는 탄력적 IPNAT게이트웨이 그리고 프리티어 EC2인스턴스를 만들었어도 초과용량시 과금된다...

그리고 EBS라고 스냅샷 백업하는게 있는데 이런것들로 갑자기 요금이 새면서 나간다...

 

EC2 초과용량이라는게 t2.micro 에서 사용량 750시간 EBS스토리지 30GiB, IO2백만개, 스냅샷 1GB, 인터넷 대역폭 100GB가 포함되는데...

멋 모르고 막 테스트하다가 안끄고.. 31일 넘어서 750시간 넘어 한달 넘어가거나 EBS스토리지 30GiB , 스냅샷 훅훅 떨어지면 나도모르게 요금이 나가니 안쓰면 그냥 꺼버리는게 좋다..( 빌린 컴퓨터는 반납.. 중지해도 저장하고 있는줄 몰랐다...

 

EC2 같은거 여러개 만들면 EBS에서 저장하고 있는데 30GiB 훅 넘어간다는거 필히 알고... 

EC2 여러개 사용시 꼭 중지가 아니라 종료해버려야 한다.

 

 

 

ELB로 aws 에서 로드밸런스를 구축하면 이것도... 돈나오고...

WAF로 aws에서 방화벽 뭐시기 그냥 한다고 별 생각없이 하면.. 또 돈나오고..

Route53으로 aws에서 도메인 만드는것도 돈인데 유지비용도 있었다...

 

보니까 CloudFront에서는 돈이 나오지 않았는데

CloudTrail도 저거 보고 듣기만 했다..

 

ECR도 만들어 놓으면 돈이었다... 상황파악해서 지워놓지 않았으면 큰일 날뻔했다.

 

이 외에도 보니 CloudWatch , KMS, SecretsManager ,SnS, VPC 등에서도 청구된다.

KMS는 다행히 프리티어 였고, SecretsManager는 API 사용량이 만개중 2개로 적어서..

청구되지 않았으나 청구가 될거라는 걸 몰랐다..

 

마지막으로 세금도 있다...

 

기가막힌 노릇이다.

 

aws architect 수업한다고 해서 열심히 들으면서

이모저모 배우는데 이렇게 뒤통수 치는줄 알았으면

강사가 알려주는지 aws에서 뭔가 해야지

딱히 쓴것도 없는데....

 

특히 DB는 지가 백업하는걸 내가 왜 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

 

아... aws에서 하소연 해봐야 겠다..

 

고객 지원 팀에 문의 - AWS 비용 및 사용 보고서 (amazon.com)

 

고객 지원 팀에 문의 - AWS 비용 및 사용 보고서

AWS Support사례를 개설하고 관련 주제: 계정 및 결제 Support 을 지정하려면 루트 계정AWS 소유자로 에 로그인하거나 지원 사례를 개설할 수 있는 IAM 권한이 있어야 합니다. 자세한 내용은AWS Support 사

docs.aws.amazon.com

 

 

Amazon CloudWatch 는 강력한 시각화 도구를 사용하여 리소스 및 애플 

(custom metric , 대시보드 생성, 알람생성)

LIST

aws 가상네트워크를 만들어보자

가상네트워크 안에 서브넷 6개를 구성한다.

가용영역AZ 2개 안에 각각 3개 씩 배치한다.

 

서브넷은 오픈영역 1개, 사설영역에 DB와 application 2개 총 세개를 만드는데

가용영역 a,c 에 각각 배치하므로

총 서브넷은 가용영역 2개 안에 3개씩 총 6개다.

 

라우팅 테이블의 오픈영역은 인터넷게이트웨이(Internet Gateway)로서 인터넷 망과 연결 역할을 한다.

라우팅 테이블의 사설영역은 NAT(Network Address Translation) Gateway로서 VPC안의 내부망과 외부망을 이어주는 역할을 한다.

 

이렇게 서브넷6개와 라우팅 테이블 3개와 네트워크 연결점 2개로 AWS 가상네트워크를 만들었다.

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

aws 와 사용자의 공동책임모델의 key point는

클라우드 안의 보안은 사용자가 책임지고 ( db, network&firewall 설정, app, platform, identify &access management , traafic , encryption, data)

클라우드의 보안은 aws가 책임진다. (software, compute, storage, database, networking, hardware global infrastructure , regions, availability zones, edge locations )

 

뭐 결국 클라우드 자체의 인프라는 aws 가 책임지고

고객은 클라우드내의 설정이나 db data, traffice을 책임진다.

 

비용은 사용량 기반이 일반이나,

스팟인스턴스로 사용량 기반의 70~90%절감된 비용으로 쓸수 있다.

약정을 하면 1~3년 약정하는 SP로 사용량기반대비 72프로 싸고,

예약약정을 하면(RI) 사용량 대비 기준 최대 72프로 싸다

 

 

네트워크 트래픽 비용을 계산할때 트래픽양은

용량 * 사용자수 * 개수가 된다.

4GB용량에 10명이 10개를 쓰면 400GB의 트래픽이 발생한다.

 

트래픽이 리전 밖으로 나갈때 비용발생($0.09/GB - 10TB) 하고

 

이 트래픽은 리전의  같은 가용영역 내에서는 인바운드 아웃바운드 내 다 무료이다.

리전간에도 서버응답 전송이 나가면 $0.02/GB가 발생하고

리전 내의 다른 가용영역에서 서버응답 전송이 나가면 $0.01/GB 비용이 발생한다.

 

결국 aws 클라우드안의 리전 응답에만 비용이 발생하는게 아니라,

리전간에도 비용이 발생하고 , 리전 안의 가용영역 안에서도 비용이 발생하는 것이다.

 

 

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

DEVOPS는 설계(Design)/개발(Develop-Test)/운영(Deploy-Operate)/인프라(Support - CI/CD , IAC ,MSA, Monitoring)를 통합한다.

devops의 로드맵은 하기와 같다.

 

물리/데이터/시스템/네트워크/어플리케이션 보안이 있다.

 

 

 

자 위에서, aws 클라우드 안에서 VPC를 만들어 두개의 AZ안에서  서브넷 public 1개,  private 서브넷 2개를 

구축했었다.

 

여기서 Route53을 통해서 도메인을 구성하고, Cloudfront에서 정적Contents는 S3에서 처리하고

동적Contents는 ELB( 로드밸런서)로 보낸다. ELB ( 로드밸런서)는 탄력적이고 지속적으로 대응해서 EC컴퓨터를 만들어서 대응한다.

 

 

트래픽은 용량*사용자수*개수로 계산한다면,

대역폭은 (용량*사용자수 *8bit )/처리시간으로 나온다. 단위는 bps다.

 

www.google.com을  을 입력시에

한명의 사용자가 사용을요청을 하면 아래와 같은 프로세스가 발생한다.

브라우저가 url 보고 https만의 통신을 위한 hsts목록 로드하여, 

브라우저와 os 캐시 확인하고 로컬pc의 hosts설정 본다음

mac주소와 ip주소 대응해서(dhcp & arp) 라우터가 확인한다음

 

root name서버, com name서버, google.com  name서버를 방문후에

응답을 한다.

 

이 말인 즉슨 내가 route 53에서 도메인 등록을 하면

도메인 서버를 이리저리 거쳐서 해당 도메인 주소를 가지고

aws 에서 만들어준 도메인으로 온다.

 

aws 클라우드 입구에

CloudFront를 만들면 사용이 가능한데.. 여기서 비용이 발생한다.

CloudFront에서 html,css,js ,image  같은 정적인 파일의 배포가 빠르게 할 수 있다.

파일은 S3의 bucket쪽에서 만든다.

 

 

이렇게 VPC, Route53, CloudFront 까지 설정을 마치면,

대망의 EC2에서 아까 만든 VPC 네트워크 설정을 해서 

동적소스를 비롯한 것들을 제어할 수 있다.

 

EC2에서 보안그룹(Security Group)에서는 인스턴스 수준의 보안적용이 되고,

Network ACL은 서브넷 단위의 보안이 적용된다.

 

위에서 만든 대로 vpc 안에 동적 컨텐츠 요청을 하면, Internet Gateway가 public 오픈 영역과 연결되고

사설 private 영역 은 따로 만든 NAT Gateway로 접근하여 연결된다.

 

이 public 오픈영역에 좀더 안전하고 편리한 연결을 위해 OpenVPN(가상 사설망)을  설치해두면

vpn을 통해서 쉽게 내부망에 접근이 가능하다.

 

이렇게 하면 내부망에 구축한 EC2로 연결이 된다.

 

EC2는 기본적으로, 

 

보안그룹에서 인바운드/아웃바운드 규칙을 설정할 수 있다.

탄력적IP를 통해 IP를 임의로 할당할 수있는데 여기는 돈이 또 나간다.(NAT Gateway 등에 탄력적 IP를 할당한다.)

 

로드밸런서는 대상그룹을 정해서 , 프로토콜 리스너 규칙을 만들수 있다.( http, https)

규칙에는 80 -> 443

 

AutoScaling 그룹생성은 AMI 이미지를 등록하고, 시작템플릿을 만든 다음 가동이 가능하다

 

인스턴스를 이리저리 탄력적으로 만들어서 운용하는데

 

ECS ( Elastic Container Service) 를 사용하면 ECS Cluster를 사용할 수 있다.

Docker 컨테이너가 여러개 올라간다.

 

Fargate -  별도로 인스턴스를 생성 관리하지 않고, 완전한 매너지드 서비스의 형태로 도커 컨테이너를 실행시킬 수 있는 아마존의 서비리스 컨테이너 상품이다. Docker 이미지가 리파지터리에 푸시되어 있다면, 클러스터 -> 작업정의 -> 서비스의 순서로 생성하여 완전히 24시간 서비스 가능한 애플리케이션을 기동할 수 있다. (ECS, EKS에서 사용)

 

ECR ( Elastic Container Registry) 은 안전하고 확장가능하고 신뢰할 수 있는 AWS 관리형 컨테이너 이미지 레지스트리 서비스이다. ECR은 AWS IAM을 사용하여 리소스 기반 권한을 가진 프라이빗 리포지토리를 지원합니다. 따라서 지정된 사용자 또는 EC2 인스턴스가 컨테이너 리포지토리 및 이미지에 액세스할 수 있다. => 도커이미지를 저장하고 관리

 

ECS를 통하여 도커처럼 ECR에 등록한 이미지를 Cloud9으로 배포하고,

Code Build를 이런것들을 통해서 소스접근 관리하고

Code Deploy에서 배포한다.

LIST

+ Recent posts