Day 64 - Cloud network IAM, CICD

오늘 배운 내용

- Cloud network - IAM

- CICD 준비

---

Cloud network 

Cloud network의 보안정책은 리소스에 대한 정책과 User에 대한 정책으로 나눌 수 있다

IAM - Identity and Access Management

User에 대한 정책임 - 누가 어떤 리소스에 무엇을 할 것인지 정한다

 

GCP 

IAM이 될 수 있는 오브젝트들 - projects, resources, roles, members 

만약 내가 내친구 이슬이 구글계정에 프로젝트 ownership권한을 준다면 이슬이는 해당 프로젝트를 자신이 만든 프로젝트처럼 사용할 수 있다

 

who = 보안 주체

1. 구글 계정 - 사람에서 부여되는 권한

2. 서비스 어카운트 - 객체 (ex. VM이 스토리지(리소스)에 접근) 객체에 주는 권한 

 

cloud 스토리지에 VM이 접근하기 위해서 -> 서비스 어카운트 생성 후 VM에 권한 부여

github action에서 running 되는 컨테이너가 gke에 무엇인가를 배포하려면 서비스 어카운트가 필요

권한을 주고 배포할 수 있도록 해야 함

---

gcp service account 실습

VM과 클라우드 버킷을 만들고 클라우드 버킷에 데이터를 하나 넣어둔다

# bucket data 다운로드
gsutil ls gs://gymin/
gsutil cp gs://gymin/git.jpg .

다운받는것은 가능하지만 

로컬의 data를 버킷(클라우드 스토리지)에 올리려니까 403 error가 떨어짐 --> 권한없음 오류

read는 되지만 write는 안됨

vm에 read-write권한을 주어야 한다

 

IAM >Service accounts

Storage에 Admin 권한을 주는 서비스 어카운트 생성

--> VM 생성시 다음 서비스 어카운트를 선택하면 접근 가능하다

 

VM을 만들때 서비스 어카운트를 바로 줄 수없는 경우 -> key를 이용해서 권한을 준다

서비스 어카운트 managed key > add key 새로운 키 받아 VM에 업로드

key.json 파일을 받고 VM으로 옮겨 다음 명령어 실행

# gcloud auth activate-service-account 서비스 어카운트 이름  --key-file 키파일명
gcloud auth activate-service-account storage-rw@annular-magnet-343008.iam.gserviceaccount.com --key-file auth.json

업로드가 잘됨

---

AWS

AWS 콘솔의 모든 작업은 API 호출을 통해 요청된다

IAM - 누가 어떤 리소스에 어떻게 액션을 취할 수 있는가?

 

who = 보안 주체

1. root user : 모든 권한, 계정 생성 후 사용하지 않을것을 권장

2. IAM user : 장기 자격 증명 (내가 쓰고있는 계정)

3. Role: 임시 자격 증명, 정의된 제한범위 내에서 aws api 사용 가능 (gcp - service account)

4. application: role을 부여받은 리소스 (vm등 ..)

 

AWS	who - 계정, group	role	서비스 어카운트
GCP	who - 계정, group	정책	role

 

aws는 두가지 방법으로 api에 authentication 할 수 있다 (IAM)

1. console 접속 - ID, PW로 접속

2. api/cli/sdk 접속 - Access key, secret key 이용하여 증명

     GCP는 Access key, Secret key으로 증명 불가능 - 서비스 어카운트로 허가 후 접근

 

임시자격증명(role)은 토큰을 이용

---

AWS role 실습

IAM 역할 만들기 (VM에서 S3 접근 가능하게 하는 권한)

인스턴스 > 보안 > IAM 역할 수정

권한 부여 후 aws s3 ls

aws s3 ls gymin1 # 안에 들어있는 data가 보임

# data 업로드
echo "hi" > hi.txt
aws s3 cp hi.txt s3://gymin1

data가 업로드 됨

 

---

CICD

한번 들어보면 좋은 유튜브

 

cicd는 간단하게 말하면

수정된 소스코드를 자동으로 빌드, 배포하는 작업이다

[--> 더 자세하게 수정]

소스코드를 업데이트 하는 방법은 다음과 같다 

vm에서

<일반적인 배포>

개발 - 빌드 - 서버에 배포 (직접)

<CICD>

코드를 깃에 올린다 젠킨스(cicd tool)가 event 감지 - [ 코드 클론 - 빌드 - 서버에 배포 ] - 자동화

 

컨테이너에서

<일반적인 배포>

개발 - 빌드 - 컨테이너 이미지 생성, push - deploy image 수정

<CICD>

코드를 깃에 올린다 젠킨스(cicd tool)가 event 감지 - [ 코드 클론 - 빌드 - 컨테이너 이미지 생성, push -deploy image수정 (cli) ] - 자동화

 

이러한 자동화 프로세스를 work flow라고 한다 

 [ event 감지 - 코드 클론 - 빌드 - 컨테이너 이미지 생성, push -deploy image수정 (cli) ] = work flow

 

CICD 사용하기

jenkins - jenkins 서버가 따로 있음

--> git hib, git lab 들과 연동이 가능 

이런 이벤트성 작업을 받아 git push가 되는 순간에 다시 배포하는것을 젠킨스에서 자동으로 가능함

- 현업에서도 많이 사용하는 툴

-GUI로 작업이 가능하다

 

jenkins 서버에서 

gradle 깔고 

git 이벤트 발생 시 -> git clone -> gradle build -> docker file build, push -> k8s에 배포

 

- git과 연동하는 작업이 필요한데 조금 귀찮다

이를 대신할 수 있는 git action 이라는 기능이 생김 - 이것도 현업에서 많이 사용하는 편

 

github action 사용하기 - SaaS 형태

소스코드 파일과 git 연동 후 cicd action ymal을 만들어 사용한다

work flow에는 하나 이상의 job이 있어야 한다 

 

workflow yaml 파일

커밋

workflow 생김

 

소스코드 수정 후 push 하면 action내용이 하나 생김

들어가서 작업내용 확인하기

 

action 서버에서 소스코드 빌드(gradle), docker image 생성 workflow file

# This is a basic workflow to help you get started with Actions

name: cicd test

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3
      - name: install jdk
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '11'
          cache: 'gradle'
          
      - name: chmod gradle
        run: chmod +x ./gradlew
        
      - name: build
        run: ./gradlew build --no-daemon
        
      - name: check build
        run: ls ./build/libs
        
      # docker setup
      - name: Set up Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@v1

      - name: docker ps
        run: docker ps

      - name: docker build 
        run: |
              cp ./build/libs/*.war ./Dockerfile
              docker build -t test ./Dockerfile
              docker images

각 step별로 필요한 프로그램을 설치하고 명령어를 넣는다 

-> checkout = git clone과 같음

 

오늘의 회고

• git action yaml을 강사님과 함께 만들때 여러 오류도 많이 나고 해결하는데 시간이 좀 걸렸는데 어차피 내가 혼자 했어도 났을 오류 였기 때문에,, 강사님과 같이 해결해보고 방법을 찾아가는 과정이 유익했다 ~ 수강생분들 중에 오류가 나면 능동적으로 방법을 찾아보시고 해결책을 제시해주시는 분들이 많은데 그분들을 볼때 마다 반성하게 된다.. 열심히 해야지😂