게시글
질문&답변
2024.05.29
일부 event는 디폴트 브랜치에서만 동작한다 ?
안녕하세요, 김형민님 말씀하신 것처럼, issue 이벤트는 디폴트 브랜치에서만 트리거되는 이벤트입니다. (사진 첨부: Note 부분) (사진) 만약 아래와 같은 구조로 되어있다면, 정상적으로 실행되어야합니다. 디폴트 브랜치 : pr-test pr-test 브랜치의 깃헙액션 워크플로우 : 트리거 : issue, 액티비티 타입 : opened 혹시 pr-test에 정의된 깃헙액션 워크플로우가 이 구조와 일치할까요 ? 만약 pr-test에 issue 워크플로우가 정의가 되어있지 않았다면 실행이 안되기 때문에 이 부분을 확인해주시면 도움이 될 것 같습니다.
- 0
- 1
- 31
질문&답변
2024.05.29
gh auth login 관련 질문드립니다!
안녕하세요 dev님 ~ 아래처럼 secrets으로 personal access token을 시크릿으로 저장하고 진행하신게 맞을까요 ? 제 경험상으로는 아래처럼 정의하면 말씀하신 문제는 없었던 걸로 기억합니다. - name: gh auth login run: | echo ${{ secrets.PERSONAL_ACCESS_TOKEN }} | gh auth login --with-token 만약 이 코드와 동일하게 설정해도 이슈가 발생한다면, 문제가 발생한 깃헙액션 워크플로우 전체 코드와 발생한 에러로그를 보여주시면 좀 더 명확한 답변을 드릴 수 있을 것 같습니다.
- 0
- 1
- 36
질문&답변
2024.05.09
run 할때 | 의미는?
안녕하세요 HeeSeok Noh 님 질문주신 | 에 대해서, 편하게 바라는 명칭으로 표현하겠습니다. 코드로 설명하면 좀 더 이해하기 쉬울 거 같아서, 간단한 코드로 설명드리겠습니다. 예를 들어, 특정 step에서 run 이라는 키워드를 사용해서 커맨드를 실행한다고 해보겠습니다. 커맨드는 echo "hello", cat text.txt 이렇게 실행한다고 가정하겠습니다. 만약 바가 없이 정상적으로 실행하려면 코드를 아래처럼 구성해야 합니다. 이렇게 커맨드를 이어서 작성해야 합니다. run: echo "hello" cat text.txt 만약 바가 없이, 아래처럼 표현하면 깃헙액션 문법에 의해서 정상적으로 실행이 안됩니다. run: echo "hello" cat text.txt 그래서, 결론적으로 말씀드리면 바를 사용하면 깃헙액션 문법을 지키기 + 가시성도 확보가 가능해집니다. run 뿐만 아니라, if condition을 사용하는 경우도 마찬가지입니다. 이렇게 표현해서 정상적으로 실행할 수 있지만, 조건이 많아지면 코드가 길어지니까 보기가 불편합니다. if: needs.test.result == 'success' && needs.test2.result == 'success' && needs.test3.result == 'success' 바를 사용한다면, 이렇게 표현할 수 있습니다. if: | needs.test.result == 'success' && needs.test2.result == 'success' && needs.test3.result == 'success' 답변이 도움이 되면 좋겠습니다.
- 0
- 1
- 57
질문&답변
2024.04.14
EKS
안녕하세요, wnsqud70님 업로드 해주신 스크린샷을 보면, 터미널에서는 ap-northeast-1 region에 생성되었다는 로그가 보입니다. 혹시 aws console 상에서는 클러스터가 없음으로 보이는데 혹시 EKS 클러스터를 AWS내에서 조회하실 때 ap-northeast-1 리전에서 조회하신게 맞을까요 ? 생성한 리전(ap-northeast-1)에서 aws eks를 검색했을 때도 동일한 지 확인 필요할 것 같습니다.
- 0
- 1
- 89
질문&답변
2024.04.13
aws과금
안녕하세요, wnsqud70 님 EKS 프로비저닝 하기 위해 Cloud9 기반 EC2가 생성되는 시점부터 과금됩니다. 강의에서는 EKS 환경에서 CI/CD를 구성하기 위해 아래 순서로 구성합니다. A. AWS Cloud9 구성 B. scripts 실행 후, EKS 를 프로비저닝 하기 위한 cloudformation 실행 C. 외부에서 애플리케이션에 접근하기 위한 로드밸런서 생성 A 단계에서 Cloud9을 프로비저닝하면 EC2가 생성되고, 사용한만큼 과금됩니다. 만약 Cloud9 EC2를 중지시킨다면 EC2 비용은 발생하지 않고 EBS라는 볼륨 비용만 발생합니다. B 단계에서 EKS를 프로비저닝하면 EKS 클러스터 자체에 대한 비용과 노드로 사용하는 EC2에 대한 비용이 발생합니다. C 단계에서 로드밸런서 타입의 서비스가 배포되어 로드밸런서가 프로비저닝되면 해당 비용이 발생합니다. 말씀하신 것처럼, AWS에서 인프라를 프로비저닝한 상태로 계속 놔두면 비용이 계속 발생하기 때문에 아래 방법을 권장드리고 싶습니다. [ 한번만 EKS를 프로비저닝 ] 시나리오1부터 시나리오4까지 이어서 수강 이 때 깃헙액션 코드를 실행하고 싶다면, EKS에 배포하는 잡 혹은 스텝만 주석처리해서 원하는 흐름으로 워크플로우가 실행되는 지 확인 3. 시나리오4까지 수강이 완료되었다면, 이 때 강의에서 소개하는 방법으로 EKS를 프로비저닝 4. 그리고 각 시나리오에 맞게 구성한 깃헙액션 코드를 프로비저닝한 EKS를 대상으로 배포 5. 테스트 완료된 후 EKS 및 Cloud9 리소스 삭제 저의 경우 이러한 순서로 진행했고, 3달러 이내로 비용 청구가 되었습니다. 수강에 참고가 되었으면 좋겠습니다.
- 0
- 1
- 124
질문&답변
2024.04.13
링크
안녕하세요, wnsqud70님 github context 자체는 업데이트 되지 않은 것으로 알고 있습니다. 추측하기로는 slack actions을 사용할 때, payload의 구성이 조금 달라서 그로 인한 영향이지 않을까 하는 생각이 듭니다. 하지만, 제공해주신 정보로 판단하기가 조금 어려워서 작성하신 깃헙액션 코드를 보여주시면 그걸 기반으로 확인해볼 수 있을 것 같습니다.
- 0
- 1
- 83
질문&답변
2024.03.15
kubernetes cluster unreachable
올려주신 스크린샷에서 configmap 업데이트가 필요할 것 같습니다. 깃허브에 올려둔 레포에서, kubernetes/create-cluster.yaml 코드를 확인해보시면 아래처럼 구성이 되어있습니다. 올려주신 스크린샷에는, github-actions이라는 role이 있는데 configmap 에는 반영되어 있지 않습니다. (사진) configmap을 편집해서 아래 내용을 추가해주셔야할 것 같습니다. kubectl edit cm aws-auth -n kube-system 커맨드를 통해, 아래 포맷에 맞춰서 적절한 값으로 넣고 다시 시도해보시겠어요 ? (기존 값은 유지된 상태로 작업하셔야합니다) mapRoles: | - "groups": - "system:masters" "rolearn": "arn:aws:iam::${ACCOUNT_NAME}:role/github-actions" "username": "actions" 이런 구조로 해야한다는 뜻으로 이해해주시면 될 것 같습니다. (사진)
- 0
- 3
- 200
질문&답변
2024.03.15
kubernetes cluster unreachable
안녕하세요 ynmj님 현재 구성하신 인프라를 확인할 수가 없어서 말씀해주신 내용 바탕으로 답변드리겠습니다. A. IAM 신뢰 관계 Github Actions이 사용하기 위해 구성한 IAM Role이 명확히 설정되었는 지 확인이 필요합니다. deploy단계까지 진행되었다는 건, 그 전에 이미 aws-actions/configure-aws-credentials@v4 액션을 사용했다는 것으로 판단됩니다. (OIDC 설정 적용) 그래서, 사용하는 IAM Role에서 신뢰관계(trust_relationships) 설정이 올바르게 되어있는 지 해봐야할 것 같습니다. Bastion host에서, kubectl get cm aws-auth -n kube-system -o yaml 커맨드를 통해 github actions role이 정의되어 있는 지도 확인이 필요합니다. B. 환경의 차이 만약 A가 올바르게 구성되어 있다면, 말씀하신 환경의 차이일 가능성이 높습니다. 강의에서는 Cloud9에서 Cloudformation으로 EKS를 프로비저닝하는 방식을 사용합니다. 만약, EKS의 API server endpoint access가 public 으로 구성되어 있다면 깃헙액션이 OIDC를 통해 AWS에 연결하고, 올바른 IAM 권한과 신뢰관계가 설정되어 있다면 EKS클러스터에 액세스할 수 있습니다. 그런데, 이 부분이 private으로 구성되어 있다면 조금 복잡해집니다. 이 경우, 깃헙액션의 IP 대역을 허용하거나 (깃헙 엔터프라이즈가 아닌 경우 고정IP할당이 안됩니다) 아니면 깃헙액션이 제공해주는 runner가 아닌 self-hosted runner를 사용하는 방식으로 구성해야 합니다. EC2 인스턴스를 self-hosted runner로 구성하거나 혹은 ARC (Action Runner Controller) 를 사용해서 쿠버네티스의 파드로 깃헙액션 잡을 실행할 수 있도록 구성해야합니다. https://docs.github.com/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners https://docs.github.com/ko/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/quickstart-for-actions-runner-controller (사진) EKS의 API server endpoint access가 다를 것이라고 추측하고 있는데, 맞는 지 모르겠네요 . 다른 인프라 구성이면 그에 맞는 설정을 하기 위해서, 추가되는 변경사항이 많기 때문에 강의를 학습하시기 위해서는 Cloud9에서 Cloudformation으로 프로비저닝 하시기를 권장드립니다.
- 0
- 3
- 200
질문&답변
2023.12.22
PR merge 시 test job 미실행 관련 문의
안녕하세요, 올챙이님 좋은 질문 감사합니다. 해당 강의에 제가 자세히 설명드리지 못한 것 같습니다 이 강의에서는 CI 는 테스트 단계, CD는 배포 단계로 설정했습니다. PR이 open, synchronize 때는 CI 단계가 실행되도록 하고 PR이 merge되면 CD 배포 단계가 실행되도록 했습니다. PR 이벤트에 의해 CI or CD 둘 다 하나의 깃헙액션 워크플로우에서 실행이 되는데요 . Job level에서의 제어를 통해 CI 와 CD 단계를 구분 지었습니다. 아래처럼 test job level에 있는 if condition에 의해, PR open되거나 synchronize(동기화)될 때만 실행되도록 제어하면 PR이 merge 되는 시점에는 동작하지 않고 Skip하게 됩니다. image-build job은 job level에서 if condition을 통해 PR이 merge되는 시점에만 동작하게 됩니다. on: pull_request: types: [opened, synchronize, closed] jobs: test: if: github.event.action == 'opened' || github.event.action == 'synchronize' image-build: if: github.event.pull_request.merged == true 이처럼 Job level에서 if condition을 사용하면, 워크플로우가 실행될 때 잡의 실행 여부 제어가 가능합니다. 그래서, PR이 merge되는 시점에 test job이 실행되지 않는 이유는 job level에서의 if condition 설정 때문입니다. 만약, PR이 open, synchronize, merge 되는 경우에도 test job을 실행하고 싶으시다면 아래처럼 구성하시면 됩니다. on: pull_request: types: [opened, synchronize, closed] jobs: test: if: | github.event.action == 'opened' || github.event.action == 'synchronize' || github.event.pull_request.merged == true
- 0
- 1
- 266