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' 답변이 도움이 되면 좋겠습니다.

EKS

안녕하세요, wnsqud70님 업로드 해주신 스크린샷을 보면, 터미널에서는 ap-northeast-1 region에 생성되었다는 로그가 보입니다. 혹시 aws console 상에서는 클러스터가 없음으로 보이는데 혹시 EKS 클러스터를 AWS내에서 조회하실 때 ap-northeast-1 리전에서 조회하신게 맞을까요 ? 생성한 리전(ap-northeast-1)에서 aws eks를 검색했을 때도 동일한 지 확인 필요할 것 같습니다.

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달러 이내로 비용 청구가 되었습니다. 수강에 참고가 되었으면 좋겠습니다.

링크

안녕하세요, wnsqud70님 github context 자체는 업데이트 되지 않은 것으로 알고 있습니다. 추측하기로는 slack actions을 사용할 때, payload의 구성이 조금 달라서 그로 인한 영향이지 않을까 하는 생각이 듭니다. 하지만, 제공해주신 정보로 판단하기가 조금 어려워서 작성하신 깃헙액션 코드를 보여주시면 그걸 기반으로 확인해볼 수 있을 것 같습니다.

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" 이런 구조로 해야한다는 뜻으로 이해해주시면 될 것 같습니다. (사진)