runs-on 질문

안녕하세요, gang ho lee 님GitHub Actions에서 runs-on: ubuntu-latest라고 하면,GitHub이 제공하는 가상 머신(VM)에서 Ubuntu 운영체제를 실행한다는 의미입니다. 현재 GitHub은 Azure에서 제공하는 VM을 사용하고 있으며,단순히 Ubuntu가 설치된 VM이 아니라 GitHub이 미리 세팅한 환경을 가진 VM 이미지를 제공합니다.제공되는 이미지 및 미리 설치된 패키지 목록은 아래 링크에서 확인하실 수 있습니다.https://github.com/actions/runner-images?tab=readme-ov-file#available-imageshttps://github.com/actions/runner-images/tree/main/images/ubuntu 강의에서는 Github가 제공하는 이미지를 사용하는데, 필요에 따라 원하는 설정이나 패키지를 커스텀한 이미지로 만들어서 사용할 수도 있습니다.즉, Github가 제공하는 러너가 아닌 Self-hosted 러너를 활용할 수도 있습니다. Github 에서 제공해주는 러너의 경우, 특정 시간까지만 무료로 실행할 수 있기에Github에 비용을 지불하지 않고, 많은 시간동안 실행한다라면 직접 관리하는 VM 을 지정하는 것도 가능합니다.

트렁크 베이스로 개발할 경우

안녕하세요, 팥빙수님답변이 늦어져 죄송합니다.상당히 어려운 질문을 주셔서, 고민을 많이 했습니다.CI/CD를 단순히 GitHub Actions나 다른 툴로 코드화하는 것보다, 어떻게 CI/CD 프로세스를 설계할지가 훨씬 어려운 영역이라고 생각합니다.제 답변이 명확한 정답은 아닐 수 있지만, 조금 더 풀어서 설명드리겠습니다. 참고만 부탁드리겠습니다. 저는 트렁크 베이스 방식을 하나의 main 또는 master 브랜치를 중심으로 작업하는 것으로 이해하고 있고, 이를 전제로 말씀드리겠습니다. 현재 강의를 보면 dev 브랜치와 master 브랜치를 사용하고, tagging을 통해 QA 환경으로 배포를 트리거하는 구조를 사용하고 있습니다. 이 방식의 단점단순한 변경 사항을 배포하기 위해 많은 프로세스가 필요하다는 점입니다.예를 들어:feature 브랜치에서 dev 브랜치로 PR을 생성하고, 머지하여 개발 환경으로 배포dev 브랜치에서 QA 환경으로 배포하려면 tagging을 트리거QA 확인 후 master 브랜치로 PR을 생성하고 머지하여 운영 환경으로 배포위 과정을 거치면서 시간이 많이 소요되고, 이미지 빌드도 3번이나 진행해야 합니다. 트렁크 베이스에서의 CI/CD 간소화반면, 트렁크 베이스 방식을 사용하여 main 브랜치를 중심으로 작업하면 프로세스가 훨씬 간단해집니다. 만약 환경별로 배포되는 애플리케이션의 환경변수만 다르고 나머지가 동일하다면,이미지는 한 번만 빌드해도 되고, 각 환경별로 환경변수만 다르게 설정하면 됩니다.이를 통해 변경사항을 개발 환경부터 운영 환경까지 적용하는 과정이 간소화될 수 있습니다. 트렁크 베이스 방식의 핵심은 작은 변경 사항을 짧은 주기로 main 브랜치에 머지하여 관리한다는 점인데요. 이때, 아래와 같은 고려사항 등에 대한 고민과 논의가 필요합니다.a. Hotfix 처리 방법운영 중 긴급 변경 사항 (hotfix) 발생할 때 어떻게 처리할 지b. Main 브랜치의 환경 보장여러 환경에서 정상 작동 보장하려면 강력한 CI 테스트 파이프라인 필요c. 환경별 배포 제어 환경별로 브랜치를 관리한다면, dev branch가 개발 환경 master 브랜치가 운영 환경이므로 각 브랜치가 보장하는 환경이 있습니다.그리고 명시적인 트리거가(dev branch, qa tag, master branch) 있기에 환경별 배포를 제어할 수 있습니다. 트렁크 베이스에서의 CI/CD 는 어떻게 구성해야할까잘 알고 계시겠지만, 앞에서는 필요하다고 느껴지는 부분에 대해 간략히 설명드렸고질문 주신 내용에 대한 답변은 여기서 다루게될 것 같습니다. 배포할 애플리케이션이 컨테이너화 되어있고, EKS에 배포된다라고 가정해보겠습니다. (현재 강의가 이 구조입니다) 트렁크 베이스 기반 CI/CD에서는 환경별 배포를 어떻게 제어할 것인지에 대한 부분이중요하다고 생각합니다. 예를 들어, 깃헙액션으로만 cicd를 처리하는 경우를 생각해보면 어느정도 한계가 있습니다.main branch에 PR이 머지될 때, 깃헙액션이 트리거 되어 테스트를 거쳐서 이미지를 빌드하는 워크플로우를 구성했다고 해보겠습니다. 그러면 이 빌드된 이미지를 각 환경에(dev,qa,prod) 한번에 적용하고 싶을수도 있고먼저 dev에만 반영해보고 싶을수도 있습니다.이런 많은 케이스를 깃헙액션으로만 제어하기가 쉽지 않습니다. 그래서 깃헙액션과 추가적인 CD 도구를 결합하면, 이런 부분을 개선할 수 있습니다.예를 들어 main branch에 PR이 머지될 때 이미지 빌드는 1번만 하고,해당 이미지를 사용할 지 말 지는 사용자가 제어하도록 하는 방법입니다. 깃헙액션에서는 이미지 빌드까지 진행하고, 실제로 배포 여부는 CD 에 의해서제어되도록 하는 구조입니다. 혹시라도 ArgoCD에 대해서 배경지식이 있으시다면, 아래 내용이 좀 더 수월하게 느껴지실 것 같아서 코드로 설명 이어서 드리겠습니다.

시나리오 2까지 학습 후 AWS에 관해 질문이 있습니다!

안녕하세요, 양서은님비용 절감을 위해서, 쿠버네티스 클러스터를 1개 사용하고 네임스페이스를 통해 환경별 분리를 진행했습니다.eks cluster를 생성하실 때 (create-cluster.yaml) 아래 설정을 사용하셨다면 클러스터 생성 시점에EC2 (노드) 는 2개가 생성됩니다. managedNodeGroups: - name: managed-ng instanceType: t3.medium minSize: 2 maxSize: 2 desiredCapacity: 2 volumeSize: 100=========================기본적으로 LB는 모든 노드를 로드밸런서에 등록합니다. 파드가 여러 노드에 스케줄링되더라도 트래픽을 전달해야하기 때문에 모든 노드를 등록하는 것이 기본적인 동작 방식이다라고 이해하시면 될 것 같습니다. 요약하면, 아래와 같습니다.a. EC2(노드)가 2개인 이유는, 클러스터를 생성할 때 디폴트로 2개로 설정했기 때문입니다.b. LB의 기본 동작 방식은 모든 노드를 등록해서, 파드가 또다른 노드에 스케줄링된다하더라도 LB가 트래픽을 전달하기 위함입니다. 혹시 더 많은 설명이 필요하시면 언제든 질문주세요~!

cloud9 이 종료되어서 진행하기가 힘듧니다.

안녕하세요, leejken530 님답변이 늦어 죄송합니다. cloudshell에서는 아래처럼 진행하시면 됩니다. cloud9에서 하는 작업과 크게 다르진 않은데, 수동으로 해야하는 작업이 일부 있습니다. IDE 대신 vi or nano 를 사용한 편집에서 조금 차이가 있습니다.(사진)(사진) (사진) (사진) (사진) (사진) (사진) (사진) (사진) (사진)

region 도쿄로 안하시는 분들

안녕하세요 ~이제 AWS에서 Cloud9 서비스 지원을 안하는 것 같더라구요.그래서 말씀하신대로, cloudshell을 통해서 작업하면 되는데 다른분들이 참고할 수 있도록글 남겨주셔서 감사합니다. 강의에 사용하는 Cloud9과 달리, Cloudshell을 통해서 작업을 하면 시각적인 IDE가 제공되진 않고, 터미널로 작업해야한다 정도의 차이가 있습니다. 그래서 파일 수정을 할때, vi or nano 같은 에디터를 사용해서 업데이트하면 됩니다.

Tag를 이용한 QA 환경 배포와 워크플로우 구성 질문

안녕하세요 메가님~질문에 대한 답변드리겠습니다. 강의에서는 GitHub Actions 기반의 여러 CICD 시나리오를 보여드리기 위해 되도록 간단한 시나리오로 구성했습니다. 1번 질문에 대한 답변을 드리면 QA 배포 시, 수정 사항이 발생할 때마다 버전을 올려서 사용하는 방식으로도 가능합니다.A 기능을 개발 환경에 배포한 후, v1.0.0 태깅하여 QA 환경에 배포하고A 기능을 업데이트하여, 다시 개발 환경에 배포한 후, v1.0.1 태깅하여 QA 환경에 배포할 수 있습니다.현재 강의 구성으로는 수정이 발생할 때마다 이렇게 버전을 업데이트해야 동작하는 구조로 되어있습니다.그런데, 이 방식이 과연 실무에서도 적합할지에 대한 의문이 생기실 수 있습니다. 그래서, 이 질문을 바탕으로 실무에서 활용할 수 있는 좀 더 유용한 구조를 설명드리고자 합니다. 아래는 강의 내용을 조금 벗어나지만, 실무에서 자주 사용되는 방식 중 하나입니다. 시나리오의 방식처럼 구성해서 실무에서 사용하는 데에는 어려움이 있을 수 있습니다.특히 수정 사항이 잦거나 여러 기능이 동시에 QA 환경에서 테스트되어야 할 경우, 관리가 복잡해질 수 있습니다.실무에서는 각 회사와 팀의 배포 전략, 워크플로우 복잡도에 따라 CICD 설계 방식이 달라지기 때문에 정확한 답은 없지만, 하나의 예시를 통해 이해를 도울 수 있도록 설명드리겠습니다. 2024년 11월 30일에 특정 서비스에 여러 기능(A, B, C)을 추가하여 v5.0.0 버전을 운영 환경으로 배포하기로 일정이 정해졌다고 가정하겠습니다.최종적으로 원하는 구조는:release/v5.0.0 브랜치에서 QA 환경 배포가 반복적으로 이루어지고, 최종적으로master 브랜치로 병합하여 운영 환경에 반영되는 것입니다.이를 위해 릴리즈 브랜치와 RC 태그(Release Candidate 태그)를 활용합니다.릴리즈 브랜치: QA 환경에서 테스트를 통과한 안정적인 상태를 유지하며, 운영 환경 배포를 준비하는 역할을 합니다.RC 태그: QA 환경 배포 시점마다 관리되어, 각 배포의 상태를 명확히 기록하고 문제를 추적하기 쉽게 합니다.1. A 기능 개발 및 QA 환경 배포먼저 A 기능이 개발되어 개발 환경에 배포가 완료된 상태입니다.이를 QA 환경에 배포하기 위해 v5.0.0-rc.1 태그를 사용하여 GitHub Actions를 트리거하고, A 기능을 QA 환경에 배포합니다.QA 환경 배포가 성공하면 release/v5.0.0 브랜치가 생성됩니다.이 시점에서 release/v5.0.0 브랜치는 A 기능에 대한 코드만 포함하고 있습니다. 2. QA에서 수정 사항 반영 및 재배포QA 환경에서 A 기능 테스트 중 문제가 발견되었다면, A 기능을 수정하는 커밋을 추가하여수정된 코드를 QA 환경에 다시 배포하기 위해 v5.0.0-rc.2 태그를 사용합니다.이 과정에서 release/v5.0.0 브랜치에는 A 기능뿐만 아니라 수정된 코드가 추가됩니다.QA 테스트는 A 기능이 QA 환경에서 안정적으로 동작할 때까지 이 과정을 반복하며, 최종적으로 release/v5.0.0 브랜치는 A 기능과 모든 수정 사항을 포함하게 됩니다.3. B & C 기능 개발 및 QA 환경 배포A 기능에 대한 QA 테스트가 완료된 후, B와 C 기능이 각각 개발되어 개발 환경에 배포됩니다.이후 B와 C 기능을 QA 환경으로 배포하기 위해 v5.0.0-rc.3 태그를 사용하여 QA 환경에 배포합니다.이때 B와 C 기능에 대한 커밋은 순차적으로 release/v5.0.0 브랜치에 추가됩니다.QA 환경에서는 A, B, C 기능이 모두 포함된 상태에서 통합 테스트가 진행됩니다.QA 테스트 중 문제가 발견될 경우, 이를 다시 수정하는 커밋을 추가한 후 새로운 rc 태깅(ex. rc-4)을 통해 QA 환경에 배포합니다.그리고 새로운 rc 태깅의 커밋은 release/v5.0.0 브랜치에 반영되도록 구성합니다. 4. QA 테스트 완료 후 운영 환경 배포모든 QA 테스트를 통과한 후, release/v5.0.0 브랜치는 최종적으로 안정적인 상태가 됩니다.이제 이 브랜치를 운영 환경 배포를 위해 master 브랜치로 병합합니다.운영 환경에서는 최종 릴리스 태그(예: v5.0.0)를 사용하여 배포가 진행됩니다.이런 구조를 활용한다면, QA 환경에서 버전을 매번 올릴 필요가 없고 필요한 기능이 모두 포함된버전을 운영 환경에 반영할 수 있습니다.처음 강의를 계획할 때, 이 내용으로 강의를 구성하려 했습니다.그런데, 생각보다 내용이 복잡합니다. 특히 말로 설명하기엔 더 어려운 부분이 있어서 강의에서는 간단한 시나리오로 구성했습니다.추가적으로 질문 주신다면, 좀 더 쉽게 이해하실 수 있도록 설명드리겠습니다. 이어서, 2번에 대한 답변을 드리겠습니다.질문 주신 워크플로우 파일의 관리 방식은 선택사항입니다.잡이 추가될수록 워크플로우 파일의 복잡성이 증가하기 때문에, 필요에 따라 파일을 분리하는 것도 좋은 방법입니다.예를 들면, PR이 open or synchronize 되는 경우에는 CI.yaml을 구성해서 테스트만 실행하고PR이 merge 되는 경우에는 CD.yaml을 구성해서 배포만 진행할 수 있습니다.어떤 방식이 더 적합한지는 팀의 CICD 설계와 작업 흐름에 따라 다릅니다.일반적으로는 하나의 파일로 구성하는 경우가 많지만, 복잡성이 증가할 경우 파일을 분리하는 것이 더 효율적일 수 있습니다.

애플리케이션 실행시 환경 변수에 대해서

안녕하세요 ~질문해주신 내용이 단순히 GitHub Actions의 기능을 넘어 어떻게 시크릿을 처리할지에 대한 것이네요이 주제에 대해 명확하게 “이렇게 해야 한다”라고 말씀드리기는 어렵지만, 참고할 수 있는 여러 가지 방법을 설명드리겠습니다.애플리케이션을 운영하다 보면 DB 엔드포인트, 토큰, API 키와 같은 민감 정보를 다뤄야 하는 경우가 많습니다. 이런 정보를 안전하게 관리하기 위해 보통 다음과 같은 방법을 활용합니다.A. GitHub Actions Secrets 사용GitHub Actions에서 제공하는 시크릿 기능은 특정 job이나 step에서 민감 정보를 안전하게 전달하는 데 유용합니다. 예를 들어, Docker 로그인이나 AWS 접근이 필요할 때 GitHub Actions Secrets에 저장된 정보를 활용할 수 있습니다.하지만, 애플리케이션 구동과 관련된 민감 정보는 GitHub Actions Level에서 직접 처리하지 않고, 애플리케이션 초기화 단계에서 필요한 정보를 불러오는 방식으로 운영하는 경우가 많습니다. B. Docker Build 시 --build-arg 사용Docker 빌드 과정에서 --build-arg를 통해 시크릿 값을 전달하는 방법도 가능하긴 하지만, 이렇게 하면 Docker 이미지 레이어에 민감 정보가 그대로 남을 수 있어 보안상 문제가 생길 수 있습니다. C. 외부 시크릿 관리 도구 사용 더 안전한 방법으로는 AWS Secrets Manager나 HashiCorp Vault 같은 외부 시크릿 관리 도구를 사용하는 방법이 있습니다. 예를 들어, AWS Secrets Manager는 IAM 권한을 통해 애플리케이션 초기화 시 필요한 정보를 안전하게 불러올 수 있도록 지원합니다. HashiCorp Vault는 더욱 강력한 시크릿 관리 기능과 인증 방식을 제공하며, 시크릿을 필요할 때만 가져오는 방식으로 안전하게 관리할 수 있습니다.D. 애플리케이션 초기화 단계에서 시크릿 로드컨테이너 환경에서 애플리케이션을 구동한다면, Init Container를 사용하여 민감 정보를 외부 저장소에서 불러와 특정 경로에 파일로 저장한 후, 애플리케이션 컨테이너가 실행될 때 해당 정보를 참조할 수 있습니다. 쿠버네티스를 사용 중인 환경에서는 이런 방식을 활용하기도 합니다. 이렇게 다양한 방법 중에서 애플리케이션의 보안 요구사항에 맞는 방식으로 선택하시면 됩니다. 시크릿이 빌드 단계에서 이미지에 포함되지 않도록 주의하고, 실행 단계에서 안전하게 불러오는 방식이 일반적으로 권장됩니다.

처음 강의에서 push.yaml을 workflows 폴더에서 part1으로 옮겼을때

안녕하세요 ~말씀하신대로, .github/workflows 디렉토리안에 github actions workflow (*.yaml) 가 정의되어야깃헙액션이 동작합니다. 말씀하신대로 워크플로우를 추가할 때마다 .github/workflows안에 추가해야 반영됩니다.이건 깃허브에서 정의한 규칙이라 커스텀하게 바꿀 수 있는 부분은 아닙니다. 아래 댓글 남겨주신 부분에 대해서도 답변드리겠습니다. 다른 사용자들도 테스트 할때 workflows안에 만들면 헷갈리거나 너무 많아서 정리가 쉽지 않을 것 같은데일반적인 사용 사례의 경우는 아래와 같습니다.워크플로우 테스트를 위한 브랜치 새로 생성해서 그곳에서 테스트를 완료한 후 코드 리뷰 과정 (PR)을 통해 추가하고 싶은 워크플로우를 반영합니다. (각 워크플로우마다 역할에 맞춰서 네이밍) 예시로 참고할만한 오픈소스 레포지토리의 워크플로우 링크입니다. https://github.com/aws/karpenter-provider-aws/tree/main/.github/workflows 여러 사용자가 하나의 브랜치에서 여러 워크플로우를 구성하고, 구성한 모든 워크플로우가 push 이벤트에 의해 트리거된다면 관리가 복잡해지는 경우가 생길 수 있지만 보통은 그런 경우보다 각 역할에 맞는 워크플로우를(다양한 이벤트 기반으로) 구성하고 각자의 브랜치에서 테스트 완료한 후 코드 리뷰 후에 반영되므로 관리의 복잡성이 큰 상황은 아닐 것 같습니다.

이벤트 트리거 pull_request의 types

안녕하세요 ~pull request 이벤트의 activity type으로 closed를 정의하는 이유는 PR이 merge되는 시점에 GitHub Actions 워크플로우를 트리거하기 위해서입니다. closed 이벤트는 PR이 닫힐 때 발생하며, 이때 PR이 merge되거나 취소될 때 모두 트리거됩니다. 따라서 PR이 완료된 상태를 확인하는 중요한 기준이 됩니다.closed 타입을 설정한 후, 아래와 같이 Job 레벨에서 조건을 추가하면github.event.pull_request.merged == true image-build: if: github.event.pull_request.merged == true runs-on: ubuntu-latest permissions: id-token: write contents: read steps: - name: checkout the code uses: actions/checkout@v4PR이 merge될 때만 워크플로우가 실행되도록 설정할 수 있습니다.만약 이렇게 Job level에서 if condition을 통해 제어하지 않는다면,PR이 merge or 취소되는 2가지 경우 모두 워크플로우가 실행될 수 있습니다.

강의자료 다운

안녕하세요, jyyun 님 방금 제가 수업 자료를 다운로드 받아서 확인해봤는데, 잘 확인됩니다.섹션1 강의소개에 강의자료 강의에서 오른쪽 상단 수업 자료 아이콘을 클릭하시면 다운로드가 정상적으로 동작하는데 다시 확인 부탁드리겠습니다.