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

안녕하세요 ~질문해주신 내용이 단순히 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 강의소개에 강의자료 강의에서 오른쪽 상단 수업 자료 아이콘을 클릭하시면 다운로드가 정상적으로 동작하는데 다시 확인 부탁드리겠습니다.

cloud9 서비스 종료

안녕하세요 ~확인해보니 aws cloud9에 대한 서비스 종료가 있었네요 . 말씀하신대로, cloudshell을 사용하는 방법도 가능해요 .현재 시점에 테스트를 해봐야 더 정확한 답변을 드릴 것 같은데,제가 알기로 cloudshell 사용하는 상황이라면, 새롭게 ec2 인스턴스를 생성할 필요가 없고aws에 로그인할 때 사용하는 권한을 가지는 shell을 사용할 수 있는 것으로 알아요 . 만약 root 권한으로 로그인했다면, cloudshell 사용 시 루트 권한을 가진 shell을 사용할 수 있고그러면 강의에서 안내하는 IAM Role을 생성해서 붙일 필요 없이 바로 실행하실 수 있어요 . ec2 인스턴스를 새로 생성할 필요 없이, cloudshell에서 github clone한 이후에강의에서 진행하는대로 init script실행하고 eks cluster setup 한 다음에 그대로 진행해도 될 것 같습니다. cloudshell로 진행하실 때, 문제 생기는 부분이 있다면 댓글로 상황 설명 자세히 해주시면제가 확인해보고 명확한 가이드 드리겠습니다 !