섹션4-7. high 이슈 추가 시 slack의 high-test 채널로 상세 알림 미전송

안녕하세요, develop2402님 질문 주신 내용에 대해서, 저는 아래처럼 이해했습니다. keyword-list.txt 에 critical, normal 을 등록했을때 받아야할 슬랙 채널로 메세지가 전송됨keyword-list.txt 에 high를 등록했을때, 슬랙 메세지가 다른 채널로 전송됨 이 상황으로 보면, 높은 확률로 설정상의 이슈일것 같습니다.일단 슬랙 메세지가 왔다라는것을 놓고보면,a. high 키워드에 대해 식별했다 b. 슬랙 메세지 전송 로직이 올바르게 동작했다a,b 는 확보된 상태인 것 같아서, github environment에서 high 에 등록된webhook url이 기존에 존재하던 곳 (high-test 채널X)이 아닐수도 있다라는 생각이 듭니다.

github-actions repo의 create-cluster.yaml과 init.sh 사용

안녕하세요~ dnwoosim님 이메일이 읽음 처리되어 있어서 확인을 못했습니다 늦게 답변드려 죄송합니다. github-actions 레포에서 정의된 /kubernetes/init.sh 파일과 /kubernetes/create-cluster.yaml을 말씀하신것같습니다.이 레포에 정의된 스크립트와 클러스터 생성을 위한 yaml구성은 최신화되어있지않아서github-actions-setting 레포에 구성된 스크립트와 yaml을 사용하시는 것이 좋을것 같습니다.

Basic Information에 다른 정보들이 뜨는데 이거 어떻게 해야 할까요?

안녕하세요~올려주신 사진에서 incoming webhook 설정을 진행해주시면 됩니다. (사진)Incoming webhook 에 들어가시면 이렇게 나오는데(저는 이미 세팅된 상태)사진 아래에서 Add New webhook 을 클릭하면 어떤 슬랙 채널을 사용할 지 선택할 수 있습니다.선택된 채널에 대한 Webhook URL을 복사하셔서 Github 에 Secrets으로 등록하시면 됩니다.(사진)

슬랙 연동 안됨

안녕하세요,슬랙 연동하는 부분이 안된다라는게 명확히 어떤 뜻일까요 ?제가 확인해봤을때, 깃헙액션 워크플로우 자체(슬랙 액션을 활용하는 것)는 문제없는 것 같습니다.예제에서 제공한 코드와 동일한 코드 사용 시에 아래처럼 확인됩니다. 저도 무료로 슬랙을 사용하기 때문에, 무료 버전인것과는 별개인것 같아요. 액션을 통해서, 실패한다고 하셨는데 깃헙액션 워크플로우에서 어떻게 에러 로그가 나오는지첨부해주시면 알려주시면 도움이 될 것 같습니다. (사진) (사진) (사진)

슬랙 연동 안됨

안녕하세요~제가 빠르게 확인해보고 답변드리겠습니다!

visual studio code 터미널에서 github-actions 경로 설정 어떻게 하는 건가요?

안녕하세요~1:25 초에서 작업했던 내용은 강의 내용에서 확인하신 것처럼 github 에서 직접 만들었습니다. 이렇게 github에서 만드셔도 되고, vscode 같은 코드 에디터로, .github 라는 디렉토리를 만들고 그 안에서 workflows 라는 디렉토리를 생성한다음 *.yaml, *.yml 포맷의 파일을 생성해서 Github Actions workflows 코드를 구성하셔도 괜찮습니다. 터미널에서 커맨드로 아래처럼 사용하셔도 됩니다.먼저 작업하실 github 레포지토리를 clone 하셔서 아래처럼 진행하셔도 됩니다. git clone cd mkdir -p .github/workflows touch .github/workflows/test.yaml

강의 자료 파일이 깨진거 같습니다

안녕하세요 V_브이_V 님,저는 모바일, 웹 둘다 정상적으로 다운로드 되고 PDF도 잘 보이는것으로 확인됩니다.다시 재시도 해주실 수 있을까요? 혹시 다시 시도하셔도 같은 상황이라면, 이메일을 통해 전달드릴 수 있도록 하겠습니다.

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가 트래픽을 전달하기 위함입니다. 혹시 더 많은 설명이 필요하시면 언제든 질문주세요~!