[Githib Action]CI / CD 자동 배포 정리 (질 & 답 형식)

728x90

루트 경로에 ci / cd 지정할 파일 생성

<루트 경로>/.github/workflows/<파일이름>.yml

.yml 파일은 GitHub Actions에서 실행되는 작업의 집합을 정의하는 워크플로우 파일의 확장자입니다. 이 파일은 YAML (YAML Ain't Markup Language) 형식으로 작성되며, GitHub Actions에서 워크플로우를 구성하는 데 사용됩니다.

q . development.yml 실행되는 원리가 무엇이지? 깃허브에서 머지된이후 어떤 과정을 걸쳐서 머지되는지 알려줘.

a. development.yml은 GitHub Actions 워크플로우 파일의 이름입니다. 워크플로우 파일은 특정 이벤트(예: 푸시, 풀리퀘스트 등)가 발생할 때 GitHub Actions에서 실행되는 작업의 집합을 정의합니다.

일반적으로 development.yml은 머지 이후의 작업을 자동화하기 위해 사용됩니다. 머지 이후의 과정은 다음과 같은 단계를 거칩니다:

q. name: Github Actions Workflow 은 단순히 이름을 정의하는 것? 그 이상의 의미가 있나?

name: Github Actions Workflow

a. name: Github Actions Workflow는 GitHub Actions 워크플로우의 이름을 정의하는 부분입니다. 이 부분은 워크플로우를 구분하고 식별하기 위한 용도로 사용됩니다.

이름을 정의하는 것은 워크플로우 파일 자체의 동작에 직접적인 영향을 주지는 않습니다. 즉, 워크플로우의 동작을 변경하거나 제어하는데는 영향을 미치지 않습니다. 그러나 이 이름은 워크플로우 파일을 관리하고 이해하기 쉽도록 도움이 됩니다.

q. 각 한줄한줄의 의미?

on:
  push:
    branches: ['develop', 'develop']

  workflow_dispatch:

a. 위의 코드 블록은 GitHub Actions 워크플로우 파일의 on 키워드를 사용하여 이벤트를 정의하는 부분입니다. 아래는 각 줄의 의미를 정확하게 설명한 것입니다:

on: 이벤트를 정의하는 키워드입니다.
push: 코드가 푸시될 때 이 워크플로우가 실행되도록 트리거를 설정합니다.
branches: 푸시 이벤트를 제한하는 브랜치를 지정합니다. 여기서는 'develop' 브랜치에 푸시 이벤트가 발생했을 때만 워크플로우가 실행되도록 설정되어 있습니다. 'develop' 브랜치 외에 다른 브랜치에서의 푸시 이벤트는 트리거하지 않습니다.
workflow_dispatch: 수동으로 워크플로우를 트리거할 수 있는 옵션을 설정합니다. 이 설정을 추가하면 GitHub UI에서 워크플로우를 수동으로 실행할 수 있는 버튼이 표시됩니다.

따라서 위의 코드 블록은 'develop' 브랜치로의 푸시 이벤트와 수동으로 워크플로우를 실행하는 경우에만 해당 워크플로우가 실행되도록 설정되어 있습니다. 다른 브랜치로의 푸시 이벤트는 워크플로우를 트리거하지 않습니다.

q. ['develop', 'develop'] 의미는 뭐지?

a. ['develop', 'develop']는 브랜치 이름의 배열을 나타냅니다.

GitHub Actions에서 on 키워드의 push 이벤트를 정의할 때, 푸시 이벤트가 발생한 브랜치를 제한할 수 있습니다. 이때 branches 키워드를 사용하여 원하는 브랜치를 지정할 수 있습니다.

해당 코드에서 branches: ['develop', 'develop']는 'develop' 브랜치에서의 푸시 이벤트를 제한하는 것을 의미합니다. 배열 내에 동일한 브랜치 이름이 두 번 나열되어 있지만, 이는 두 번째 'develop'를 추가하는 것이 오타이므로 정확한 의미는 아닙니다.

일반적으로 브랜치 제한을 설정할 때는 특정 브랜치나 브랜치 패턴을 지정하여 원하는 푸시 이벤트를 트리거할 수 있습니다. 예를 들어, branches: ['develop', 'feature/*']는 'develop' 브랜치와 'feature/'로 시작하는 모든 브랜치에서의 푸시 이벤트를 허용합니다.

따라서 branches: ['develop', 'develop']는 'develop' 브랜치에서의 푸시 이벤트만을 허용한다는 의도로 작성되었지만, 동일한 브랜치 이름이 두 번 나열되어 있어서 올바르지 않은 표현입니다.

q. jobs: 의미?

a. jobs는 GitHub Actions 워크플로우 파일에서 작업을 정의하는 섹션입니다. 워크플로우에서 수행할 작업을 구성하고 실행하는 데 사용됩니다.

jobs 섹션은 워크플로우 내에서 병렬로 실행될 수 있는 여러 작업을 정의할 수 있습니다. 각 작업은 독립적으로 실행되며, 작업은 단계(steps)로 구성됩니다. 각 작업은 하나 이상의 단계를 포함하고, 단계는 원하는 작업을 수행하는 명령문 또는 액션으로 구성됩니다.

jobs 섹션은 워크플로우 파일의 중요한 부분으로, 워크플로우 실행 중에 실제 작업이 수행되는 곳입니다. 각 작업은 독립적으로 설정되며, 다양한 환경과 요구사항에 따라 원하는 작업을 실행할 수 있습니다. 작업은 일련의 단계를 순차적으로 실행하거나, 병렬로 실행할 수도 있습니다.

예를 들어, jobs 섹션에서는 다음과 같은 작업을 정의할 수 있습니다:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Step 1
        run: echo "Hello, Step 1!"

      - name: Step 2
        run: echo "Hello, Step 2!"

위의 예시에서 jobs 섹션에는 build라는 작업이 정의되어 있습니다. 이 작업은 runs-on 키워드를 사용하여 Ubuntu 환경에서 실행되며, steps 내에 두 개의 단계가 포함되어 있습니다. 각 단계는 이름과 실행할 명령문을 가지고 있습니다.

따라서 jobs 섹션은 워크플로우 파일에서 원하는 작업을 정의하고, 해당 작업의 실행 환경과 순서를 구성하는 데 사용됩니다.

q. build: 는 뭐고? jobs: 안에 build: 말고 다른게 들어갈 수 있나?

a. build는 작업(Job)의 이름을 정의하는 데 사용되는 식별자입니다. 작업 이름은 워크플로우 내에서 해당 작업을 식별하기 위한 용도로 사용됩니다. build라는 이름은 예시로 제공된 것이며, 실제 작업의 목적이나 역할에 따라 이름을 원하는 대로 지정할 수 있습니다.

jobs 섹션에는 하나 이상의 작업을 정의할 수 있습니다. 각 작업은 고유한 이름을 가져야하며, 작업 이름은 워크플로우 파일 내에서 유일해야 합니다. 따라서 jobs 섹션 내에 build 이외의 다른 작업을 정의할 수 있습니다. 예를 들어, 다음과 같이 두 개의 작업을 정의하는 것이 가능합니다:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Step 1
        run: echo "Hello, Step 1!"

  test:
    runs-on: ubuntu-latest
    steps:
      - name: Step 1
        run: echo "Hello, Step 1!"
      - name: Step 2
        run: echo "Hello, Step 2!"

위의 예시에서 jobs 섹션 내에는 build 작업과 test 작업이 정의되어 있습니다. 각 작업은 독립적으로 실행되며, 각각에 대해 실행 환경과 실행할 단계들이 정의되어 있습니다. build와 test 외에도 다른 작업을 추가로 정의할 수 있으며, 작업 이름은 원하는 대로 지정할 수 있습니다.

따라서 jobs 섹션은 여러 작업을 정의하는 컨테이너로서, 각 작업은 워크플로우 파일에서 독립적으로 실행될 수 있습니다. 작업의 이름은 작업을 식별하는 데 사용되며, 여러 개의 작업을 정의하여 복잡한 워크플로우를 구성할 수 있습니다.

runs-on: 은 ?

ChatGPT

runs-on은 GitHub Actions 워크플로우에서 작업이 실행될 환경을 정의하는 키워드입니다.

runs-on 키워드는 작업(Job) 수행에 사용할 실행 환경을 지정하기 위해 사용됩니다. 주어진 작업은 지정된 환경에서 실행되며, 해당 환경에 필요한 리소스와 설정이 제공됩니다.

runs-on 키워드에는 다양한 실행 환경 옵션이 포함될 수 있으며, 일반적으로 다음과 같은 값이 사용됩니다:

runs-on: ubuntu-latest: 최신 버전의 Ubuntu 환경에서 작업을 실행합니다.
runs-on: windows-latest: 최신 버전의 Windows 환경에서 작업을 실행합니다.
runs-on: macos-latest: 최신 버전의 macOS 환경에서 작업을 실행합니다.

또한, 특정 버전의 운영 체제나 커스텀 환경을 사용하기 위해 runs-on 키워드에 직접 값을 지정할 수도 있습니다. 예를 들어, runs-on: ubuntu-20.04는 Ubuntu 20.04 버전에서 작업을 실행하도록 지정하는 것입니다.

실행 환경은 작업 수행에 필요한 종속성, 도구, 소프트웨어 버전 등을 포함할 수 있습니다. 예를 들어, 특정 프로그래밍 언어 또는 프레임워크의 설치, 특정 패키지의 의존성 해결, 환경 변수 설정 등을 실행 환경에서 구성할 수 있습니다.

runs-on 키워드를 사용하여 작업을 실행할 환경을 지정함으로써, 해당 환경에서 필요한 작업을 수행하고 워크플로우를 구성할 수 있습니다.

- name: Checkout Repository

uses: actions/checkout@v3

name 은 명칭이고 uses: 버전? 명령어? 뭘 의미하지?

ChatGPT

name은 GitHub Actions 워크플로우에서 단계 또는 작업에 부여하는 이름을 정의하는 역할을 합니다. 이름은 해당 단계 또는 작업을 식별하기 위해 사용되며, 워크플로우 실행 중에 로그 및 출력에서 식별 목적으로 표시됩니다.

uses는 GitHub Actions에서 제공하는 액션(Action)을 사용하여 단계를 수행하도록 지정하는데 사용됩니다. 액션은 재사용 가능한 작업 단위로, 특정 작업을 자동화하기 위한 사전 정의된 동작을 포함합니다. uses 키워드를 사용하여 액션을 지정하면 해당 액션이 워크플로우 실행 중에 실행되고 해당 단계에서 정의된 작업이 수행됩니다.

예를 들어, 다음은 name과 uses가 함께 사용된 예시입니다:

yaml

Copy code

- name: Checkout Repository uses: actions/checkout@v3

위의 예시에서 name은 "Checkout Repository"로 지정되었으며, 이는 해당 단계를 식별하는데 사용됩니다. uses는 actions/checkout@v3로 지정되었으며, 이는 actions/checkout 액션의 버전 3을 사용하여 해당 단계를 수행하도록 지정하는 것을 의미합니다. 이 액션은 원격 저장소를 체크아웃하여 현재 작업 디렉토리에 가져오는 역할을 수행합니다.

따라서 name은 작업의 이름을 정의하고, uses는 해당 작업을 수행하기 위해 어떤 액션을 사용할지 지정하는데 사용됩니다.

그럼 다음에 같은 명령을 쓸때는 어떻게 써야되는거지? 특정 작업을 자동화하기 위한 사전 정의 동작이라고 너가 설명했잖아

ChatGPT

GitHub Actions에서 동일한 액션을 여러 단계에서 사용하려면 jobs 섹션 내에서 해당 액션을 다시 정의하면 됩니다. 액션은 액션의 이름 또는 ID를 사용하여 참조할 수 있습니다.

예를 들어, 이전 단계에서 사용한 "Checkout Repository" 액션을 다른 단계에서 다시 사용하려면 다음과 같이 작성할 수 있습니다:

yaml

Copy code

jobs: build: runs-on: ubuntu-latest steps: - name: Checkout Repository uses: actions/checkout@v3 - name: Build run: yarn build # 다른 단계에서 액션 재사용 - name: Run Tests uses: actions/checkout@v3 # 다른 옵션 또는 매개변수를 추가하여 액션을 재사용할 수도 있음 with: ref: develop

위의 예시에서 "Checkout Repository" 액션은 uses: actions/checkout@v3로 정의되어 있습니다. 이 액션은 Checkout Repository라는 이름으로 사용되었습니다. 이후 "Run Tests" 단계에서 같은 액션을 다시 사용하기 위해 uses: actions/checkout@v3를 사용하였습니다.

이렇게 액션을 재사용함으로써 같은 동작을 여러 단계에서 중복 작성하지 않고 효율적으로 워크플로우를 구성할 수 있습니다. 필요한 경우 다른 옵션이나 매개변수를 추가하여 액션을 사용자 정의할 수도 있습니다.

uses: 은 명령실행 명령어로 봐도 되는거지?

ChatGPT

uses는 GitHub Actions에서 사용할 액션을 지정하는 역할을 합니다. 액션은 GitHub Actions에서 작업을 자동화하기 위해 사전에 정의된 동작을 포함한 코드 또는 스크립트입니다.

uses 키워드 뒤에는 액션을 식별하는 문자열이 옵니다. 이 문자열은 두 가지 주요 형식을 가질 수 있습니다:

GitHub Marketplace의 액션: owner/repo@version
예: uses: actions/checkout@v3
이 형식은 GitHub Marketplace에 등록된 액션을 사용하는 방법입니다. owner는 액션 소유자의 GitHub 계정 또는 조직, repo는 액션이 포함된 GitHub 리포지토리, version은 사용할 액션의 버전을 나타냅니다.
저장소 내의 액션 경로: ./path/to/action
예: uses: ./actions/my-action
이 형식은 현재 워크플로우 리포지토리에 저장된 액션을 사용하는 방법입니다. ./path/to/action은 워크플로우 리포지토리 내에 액션을 포함한 디렉토리 또는 경로를 나타냅니다.

uses는 액션의 실행을 트리거하고 해당 액션에 정의된 작업을 수행하는 역할을 합니다. 액션은 주로 코드를 실행하거나, 외부 도구나 서비스와 상호작용하거나, 리포지토리 관련 작업 등을 수행하는데 사용됩니다. 따라서 uses는 명령 실행 명령어로 보기보다는 액션을 지정하여 해당 작업을 실행하는 용도로 이해하는 것이 적절합니다.

GitHub Marketplace의 액션: owner/repo@version 을 일반적인 터미널에서 칠때

owner/repo@version 이라고 친다는 뜻이야?

ChatGPT

네, GitHub Marketplace의 액션을 일반적인 터미널에서 사용할 때도 owner/repo@version 형식으로 사용합니다. 이것은 액션을 식별하는 방법입니다.

터미널에서 uses 키워드를 사용하여 GitHub Marketplace의 액션을 실행하려면 다음과 같이 입력합니다:

bash

Copy code

uses: owner/repo@version

여기서 owner는 액션 소유자의 GitHub 계정 또는 조직 이름, repo는 액션이 포함된 GitHub 리포지토리 이름, version은 사용할 액션의 버전을 나타냅니다. 이 정보를 포함하여 액션을 지정하면 GitHub Actions에서 해당 액션을 검색하고 실행합니다.

실제 예로 uses: actions/checkout@v3는 actions라는 GitHub 계정/조직에 속한 checkout 리포지토리의 버전 3을 사용하는 액션을 의미합니다.

따라서, 일반적인 터미널에서 GitHub Marketplace의 액션을 지정할 때 owner/repo@version 형식을 사용하면 됩니다.

uses: ls -l 이런식도 가능한거지?

ChatGPT

아쉽게도 uses 키워드는 GitHub Actions에서 액션을 지정하는 목적으로 사용되며, 해당 액션은 GitHub Marketplace에 등록된 액션 또는 워크플로우 리포지토리 내에 저장된 액션과 관련됩니다.

uses 키워드는 GitHub Actions 액션을 실행하는 데 사용되며, 명령 실행을 위한 일반적인 셸 명령어를 직접 지정하는 용도로는 사용할 수 없습니다. uses 키워드는 액션을 실행하기 위한 액션 경로나 액션의 소유자와 저장소 정보를 나타내는 문자열을 기대합니다.

따라서 uses 키워드를 사용하여 GitHub Actions에서 액션을 지정할 때는 액션의 소유자/저장소/버전 정보를 제공해야 하며, 일반적인 셸 명령어를 직접 사용하는 것은 지원되지 않습니다.

깃허브 액션을 나타내는 명령어들을 나열해주고 그에대해 설명 해줘

ChatGPT

GitHub Actions에서 사용되는 일부 명령어를 아래에 나열하고 설명드리겠습니다:

name: 작업의 이름을 정의하는데 사용됩니다. 이는 워크플로우 실행 로그에서 해당 작업을 식별하는 데 사용됩니다.
on: 워크플로우를 트리거하는 이벤트를 정의하는데 사용됩니다. push, pull_request, schedule 등 다양한 이벤트를 사용할 수 있습니다.
jobs: 워크플로우에서 수행할 작업을 정의하는데 사용됩니다. 각 작업은 하나 이상의 단계(steps)로 구성됩니다.
runs-on: 작업을 실행할 환경을 정의하는데 사용됩니다. 예를 들어 ubuntu-latest, macos-latest, windows-latest 등이 사용될 수 있습니다.
steps: 작업을 수행하는 데 필요한 단계들을 정의하는데 사용됩니다. 각 단계는 순차적으로 실행되며, 여러 명령어 및 액션을 포함할 수 있습니다.
uses: GitHub Marketplace에서 제공되는 액션을 사용하여 작업을 실행하는데 사용됩니다. owner/repo@version 형식으로 액션을 지정합니다.
run: 단일 명령어 또는 셸 스크립트를 실행하는데 사용됩니다. 예를 들어 run: echo "Hello, world!"와 같이 사용할 수 있습니다.
env: 환경 변수를 정의하는데 사용됩니다. 작업 내에서 사용할 환경 변수를 설정할 수 있습니다.
if: 조건에 따라 작업을 실행할지 여부를 제어하는데 사용됩니다. 조건에 맞지 않으면 해당 작업은 건너뜁니다.
with: 액션이나 단계에 전달되는 입력(매개변수) 값을 정의하는데 사용됩니다. 액션 또는 단계에 대한 추가적인 구성을 제공할 수 있습니다.

이것은 GitHub Actions에서 사용되는 일부 주요 명령어의 예입니다. 물론 더 많은 명령어와 옵션이 있으며, 사용하는 컨텍스트와 요구사항에 따라 다양한 방식으로 GitHub Actions를 구성할 수 있습니다.

uses: ls -l 은 불가하고, uses: actions/checkout@v3 은 가능한 근본적인 차이가 머야?

ChatGPT

네, uses 키워드를 사용하여 액션을 지정할 때 명령어를 직접 입력하는 것은 지원되지 않습니다. uses 키워드는 GitHub Marketplace에 등록된 액션을 실행하거나 워크플로우 리포지토리 내에 저장된 액션을 실행하는 데 사용됩니다.

따라서 uses: ls -l과 같이 명령어를 직접 입력하는 것은 잘못된 사용입니다.

반면, uses: actions/checkout@v3은 actions라는 GitHub 계정/조직에 속한 checkout 리포지토리의 버전 3을 사용하는 액션을 실행하도록 지정하는 것입니다. 이것은 GitHub Actions에서 제공하는 "Checkout" 액션을 사용하여 현재 작업 중인 리포지토리를 체크아웃하는 동작을 수행하는 예입니다.

즉, uses: actions/checkout@v3은 GitHub Marketplace에 등록된 checkout 액션의 버전 3을 사용하여 액션을 실행하도록 지정하는 것이며, 이는 특정 액션을 호출하여 워크플로우의 일부 동작을 수행하는 데 사용됩니다.

# Login to AWS ECR

- name: Configure AWS credentials

uses: aws-actions/configure-aws-credentials@v2

with:

aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}

aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

aws-region: ap-northeast-2

설명 ㄱ

ChatGPT

해당 코드 블록은 AWS Elastic Container Registry (ECR)에 로그인하기 위해 AWS 자격 증명을 구성하는 단계를 나타냅니다.

해당 단계는 aws-actions/configure-aws-credentials@v2 액션을 사용하여 AWS 자격 증명을 구성합니다. 이 액션은 GitHub Marketplace에 등록된 AWS Actions의 하나로, AWS 자격 증명을 설정하고 워크플로우에서 AWS 서비스와 상호 작용할 수 있도록 도와줍니다.

아래는 해당 액션에 전달되는 입력(매개변수)들입니다:

aws-access-key-id: AWS 액세스 키 ID를 비밀로 저장된 GitHub 암호화 비밀 (secrets.AWS_ACCESS_KEY_ID)에서 가져와 사용합니다.
aws-secret-access-key: AWS 비밀 액세스 키를 비밀로 저장된 GitHub 암호화 비밀 (secrets.AWS_SECRET_ACCESS_KEY)에서 가져와 사용합니다.
aws-region: 사용할 AWS 리전을 지정합니다. 이 경우 ap-northeast-2로 설정되어 있습니다. 필요에 따라 다른 리전으로 변경할 수 있습니다.

이렇게 AWS 자격 증명을 구성한 후, 워크플로우의 다음 단계에서는 해당 자격 증명을 사용하여 AWS ECR에 로그인하고, Docker 이미지를 빌드하고 푸시하는 등의 작업을 수행할 수 있습니다.

AWS 정확히 머냐?

ChatGPT

AWS는 "Amazon Web Services"의 약자로, 아마존 닷컴이 제공하는 클라우드 컴퓨팅 플랫폼입니다. AWS는 다양한 클라우드 기반 서비스를 제공하여 개발자와 기업이 IT 인프라를 구축하고 운영할 수 있도록 지원합니다.

AWS는 수많은 서비스를 포괄하며, 다음과 같은 주요 카테고리로 구성됩니다:

컴퓨팅 서비스: EC2 (Elastic Compute Cloud), ECS (Elastic Container Service), Lambda 등을 포함하여 가상 서버, 컨테이너, 서버리스 컴퓨팅 등을 제공합니다.
스토리지 및 데이터베이스 서비스: S3 (Simple Storage Service), RDS (Relational Database Service), DynamoDB 등을 포함하여 다양한 스토리지 및 데이터베이스 옵션을 제공합니다.
네트워킹 서비스: VPC (Virtual Private Cloud), CloudFront 등을 포함하여 가상 네트워크, 로드 밸런싱, CDN (Content Delivery Network) 등을 제공합니다.
관리 및 모니터링 서비스: IAM (Identity and Access Management), CloudWatch, CloudTrail 등을 포함하여 보안, 모니터링, 로깅 등의 기능을 제공합니다.
AI 및 기계 학습 서비스: Amazon Rekognition, Amazon SageMaker 등을 포함하여 인공지능, 기계 학습, 데이터 분석 등을 지원합니다.
서버리스 서비스: AWS Lambda, AWS API Gateway 등을 포함하여 서버리스 아키텍처를 구축하고 실행할 수 있는 서비스를 제공합니다.

이 외에도 AWS는 컴퓨팅, 스토리지, 데이터베이스, 보안, 인공지능, 분석, IoT (Internet of Things) 등 다양한 분야에서 다양한 서비스를 제공합니다. AWS는 클라우드 기반 인프라를 사용하여 애플리케이션을 개발, 배포, 운영하는 데 필요한 도구와 리소스를 제공하여 개발자와 기업이 비용 효율적이고 확장 가능한 방식으로 IT 인프라를 구축할 수 있도록 지원합니다.

깃허브 액션을 하기전에 내가 aws측에 무슨 작업을 안해도 깃허브에 해당 값들만 넣으면 알아서 동작하는건가?

ChatGPT

깃허브 액션을 사용하여 AWS와 상호 작용하려면 몇 가지 사전 작업이 필요합니다. 액션 자체는 깃허브에서 실행되지만 AWS와의 연결을 위해 AWS 계정 및 자격 증명 설정이 필요합니다.

아래는 일반적으로 깃허브 액션을 AWS와 통합하기 위해 수행해야 할 작업입니다:

AWS 계정 및 자격 증명: AWS 계정을 생성하고 액세스 키 ID 및 비밀 액세스 키를 생성해야 합니다. 이 액세스 키는 깃허브 저장소의 Secrets에 안전하게 저장해야 합니다. 작업 흐름에서 aws-actions/configure-aws-credentials@v2 액션의 aws-access-key-id와 aws-secret-access-key 입력으로 사용됩니다.
IAM 역할 및 권한: AWS Identity and Access Management (IAM)을 사용하여 액션에서 필요한 권한을 가진 IAM 역할을 생성해야 합니다. 이 역할은 액션에서 AWS 리소스에 액세스할 수 있는 권한을 부여하는 데 사용됩니다. IAM 정책을 사용하여 필요한 권한을 정의하고, IAM 역할에 해당 정책을 연결해야 합니다.
AWS 리전 설정: 액션에서 AWS 리소스를 사용하기 전에 액션에서 작동할 AWS 리전을 명시적으로 지정해야 합니다. 예를 들어, aws-region 입력을 사용하여 액션에서 사용할 AWS 리전을 설정합니다.

위의 사전 작업을 수행한 후, 깃허브 액션에서 AWS와 상호 작용하기 위해 필요한 자격 증명 및 권한이 설정되어 있으므로 해당 액션을 사용할 수 있습니다. 예를 들어, aws-actions/configure-aws-credentials 액션을 사용하여 액션 실행 도중 AWS 자격 증명을 구성하고, 다른 액션을 통해 AWS 리소스에 액세스할 수 있게 됩니다.

중요한 점은 AWS 자격 증명과 권한 설정은 깃허브 액션과 AWS 간의 연결을 가능하게 하는 것이며, 액션을 사용하기 전에 사전 작업을 수행해야 한다는 것입니다.

- name: Login to Amazon ECR Private

id: login-ecr

uses: aws-actions/amazon-ecr-login@v1

설명 ㄱ

ChatGPT

위의 코드 블록은 AWS Elastic Container Registry (ECR)에 로그인하는 작업을 수행하는 깃허브 액션입니다. 이 액션은 aws-actions/amazon-ecr-login@v1 액션을 사용하여 실행됩니다.

해당 액션은 AWS 자격 증명을 사용하여 ECR에 액세스하고 로그인하여 액션 실행 중에 이미지를 푸시하거나 이미지를 가져오는 등의 작업을 수행할 수 있도록 도와줍니다.

액션의 구체적인 동작은 다음과 같습니다:

AWS 자격 증명을 사용하여 ECR에 로그인합니다.
성공적인 로그인 후, ECR의 레지스트리 URL 및 기타 관련 정보를 출력합니다.
이러한 정보는 다른 액션에서 사용될 수 있으며, 예를 들어 Docker 이미지를 빌드하고 ECR에 푸시하는 단계에서 사용될 수 있습니다.

이 액션을 통해 AWS ECR에 로그인하여 이미지 관련 작업을 수행할 수 있습니다.

# Build docker image and puch to ECR

- name: Build, tag, and push docker image to Amazon ECR

env:

REGISTRY: ${{ steps.login-ecr.outputs.registry }}

REPOSITORY: front/carsuri-partners-web-app

IMAGE_TAG: ${{env.APP_VERSION}}

run: |

docker build -t $REGISTRY/$REPOSITORY:$IMAGE_TAG .

docker push $REGISTRY/$REPOSITORY:$IMAGE_TAG

설명 ㄱ

ChatGPT

위의 코드 블록은 Docker 이미지를 빌드하고 Amazon ECR로 푸시하는 작업을 수행하는 깃허브 액션입니다.

해당 액션은 다음과 같은 작업을 수행합니다:

Build, tag, and push docker image to Amazon ECR라는 이름의 작업을 정의합니다.
steps.login-ecr.outputs.registry를 사용하여 이전 단계(Login to Amazon ECR Private)에서 출력된 ECR 레지스트리 URL을 가져옵니다. 이는 로그인된 ECR의 URL입니다.
front/carsuri-partners-web-app와 같이 이미지를 저장할 ECR 리포지토리의 경로를 REPOSITORY 환경 변수로 설정합니다.
$env.APP_VERSION을 사용하여 이미지의 태그를 설정합니다. APP_VERSION은 이전에 package.json에서 읽은 애플리케이션 버전입니다.
docker build 명령을 사용하여 Docker 이미지를 빌드합니다. -t $REGISTRY/$REPOSITORY:$IMAGE_TAG는 이미지에 태그를 지정하여 ECR에 푸시할 이미지의 이름을 설정합니다.
docker push 명령을 사용하여 빌드된 이미지를 ECR에 푸시합니다. $REGISTRY/$REPOSITORY:$IMAGE_TAG는 푸시할 이미지의 이름과 태그를 지정합니다.

이렇게 하면 깃허브 액션을 사용하여 Docker 이미지를 빌드하고 Amazon ECR로 푸시할 수 있습니다.

728x90

저작자표시

'React 실습' 카테고리의 다른 글

[FE 개념]리덕스 vs 모벡스 정리 (0)	2023.07.21
[React] jsx 문법 요령 - map을 이용하여 여러개의 태그 출력 (0)	2023.06.08
리액트 커스텀 훅 만들기 (0)	2022.11.22
오늘의 술 프로젝트 - 작업 정리(1) [페이지네이션, 검색] 구현 (1)	2022.11.04
yoga 프로젝트 작업일지 - 5 (0)	2022.10.27

코딩 복습용 블로그

[Githib Action]CI / CD 자동 배포 정리 (질 & 답 형식)

'React 실습' 카테고리의 다른 글

티스토리툴바

[Githib Action]CI / CD 자동 배포 정리 (질 & 답 형식)

'React 실습' 카테고리의 다른 글

'React 실습' Related Articles

티스토리툴바