강의 교안

안녕하세요! 0.0 강의자료에 보면 pdf가 첨부되어있습니다!

DooD, DinD 또는 Kaniko 외 다른 방법은 없는걸까요?

안녕하세요. 일단 조금 분리해서 생각할 필요가 있을 것 같습니다. 간단히 설명부터 드리면, DooD DooD는 --privileged가 아닌 도커 소켓을 공유해서 특정 요청(강의에서는 파이프라인을 동작시킬 추가 컨테이너를 띄우는 것)을 처리해주는 형태입니다. DinD DinD는 --privileged를 부여해서 DooD를 통해 생성된 컨테이너 이미지 내에서 도커 데몬을 활용하기 위한 형태입니다. Kaniko DinD 형태를 활용함으로써 부여되는 --privileged를 제거하기 위해 도커 데몬을 활용하지 않고, 로컬에 직접 다운로드한 후에 스냅샷을 만들어 이미지를 만드는 도구입니다. 결국, DinD + DooD를 섞는다는 의미는 파이프라인에서 사용할 컨테이너 이미지를 띄워주는 서비스(DooD)와 그 서비스를 통해 .gitlab-ci.yml에 정의된 이미지를 띄워서 컨테이너 이미지를 빌드하기 위한 이미지를 띄우는 거다 라고 봐주시면 좋을 것 같습니다.(이때 형태가 DinD) (쓰면서도 조금 헷갈리실 수 있을 것 같네요.) 어찌됐던, 말씀하신 내용을 모두 커버할 수 있는 방법이 없는건 아닙니다. rootless docker daemon을 사용하는건데요. 이게 방법도 복잡(?)하고 여러 제한 도 있어서 사용을 추천드리기가 조금 그렇습니다. 대신 추천드리는 도구는 builtkit 인데요. buildkitd를 rootless로 띄워서 사용하면 되긴 하지만 당연하게도 은탄환은 없기 때문에 추가로 희생되는 것들이 있긴 합니다.(도입하시기 전에 여러방면으로 꼭 테스트 많이 해보시길 권해드립니다.) 참고 부탁드립니다. 감사합니다.

Kaniko 의 한계 부분에 대한 질문

안녕하세요. "기본적인 이미지" 의 의미는 "파이프라인에서 생성되어야 하는 것을 제외한 모든 것들" 이라고 봐주시면 됩니다.(무조건은 아닙니다. 당연히 환경마다 달라질 수 있겠죠?) 강의는 Python을 기반으로 하기 때문에, 파이프라인에서도 컨테이너 이미지를 생성하기 위한 빌드를 제외하면 추가로 빌드할 것들이 없었습니다. 하지만, 소스코드를 바이너리로 바꾸는 과정이 필요한 언어들(golang 등)은 파이프라인 내에서 추가적인 빌드가 필요할 겁니다. 이러한 과정을 위해 필요한 파일들을 언급한거다(굳이 CI/CD 파이프라인에서 받을 필요가 없는 것들) 라고 봐주시면 됩니다. 이외에도, 필수 패키지(net-tools, procps 등)가 될 수도 있고, 내가 운영하고 있는 환경에 맞춰 추가적인 무언가가 필요할 수도 있을 겁니다. 요약하면, kaniko의 태생적 한계(호스트에 다운로드 후 스냅샷 생성)를 극복하기 위해 다양한 옵션(--use-new-run, --single-snapshot)을 사용하게 되면 레이어에 대한 캐시 적중률 문제 와 (거의 그럴 일은 없지만 동작방식의 한계로 인한) 비정상적인 이미지가 생성되는 것 을 막기 위해, 최대한 파이프라인 과정에서 생성되는 파일을 줄이고 캐시를 활용하자 라는 취지로 말씀드렸습니다.(어느 정도의 스냅샷은 감수할 수 있도록요.) 감사합니다.

artifacts 에 대한 질문이 있습니다!

안녕하세요. 좋은 질문 감사드립니다. 결론부터 말씀드리면, 아티팩트는 MR에 통합되는 보고서를 생성하거나 후속 작업(job)에서 사용이 필요한 경우 에 보통 사용하게 되고(무조건 존재 해야함), 캐시는 있으면 좋고 없어도 효율이 조금 낮아질 뿐이지 작업이 동작하는데 문제 없는 경우 에 사용하시면 좋습니다.(당연히 상황마다 달라질 순 있습니다.) 또한, 아티팩트는 현재 파이프라인에서만 유효하지만, 캐시는 언제든 사용할 수 있다는 장점도 있습니다. 위의 기준을 통해 답변 드리면, 파이프라인 내에서 빌드 후 생성한 아티팩트를 후속 작업에서 사용하고 싶다면 아티팩트를 사용하셔도 무방하고, 그게 아니라 파이프라인이 동작할 때 마다 가져오고 싶다면 캐시를 선택하시면 될 것으로 보입니다. 추가로, 빌드라는게 컨테이너 빌드를 말씀하시는 거면 뒤에서 배울 kaniko 파트에서 빌드 간 발생하는 레이어들을 컨테이너 레지스트리에 캐시하는 방법도 있으니 참고 하시면 좋을 것 같습니다.(컨테이너 이미지가 커질수록 전체를 아티팩트나 캐시에 보관하는 것은 정말 비효율적입니다!)

IAM 사용자별 EKS 접근 권한 추가 방법

안녕하세요. 먼저, 두 가지 관점으로 살펴봐야될 것 같습니다. 서비스(pod)가 역할을 부여받을 때 권한 제어 사용자가 EKS Cluster에 접근 할 때 권한 제어 강의에서도 말씀드렸다시피 Kubernetes에 대한 내용을 다루지는 않고 있지만, 1번 내용에 대해서는 IAM으로만 관리가 가능하기에 설명을 드렸었습니다.(그게 IRSA, EKS Pod Identity 입니다.) 현재 말씀하신 내용은 1번의 내용은 아닌 것 같기에 제외하겠습니다.(물론 IRSA, EKS Pod Identity를 통해서 쓸 수 없는건 아니지만, 정상적인 케이스는 아닌걸로 보입니다.) 결국, 2번 내용인 사용자 -> EKS Cluster 접근에 대한 질문으로 보입니다. 결론부터 말씀드리면, 해당 내용은 강의에 포함되지 않은게 맞습니다. 해당 내용을 이해하려면 Kubernetes의 권한 체계에 대해서 알아야 하기 때문입니다. 그래도 간단히 설명드려보면, 아마 말씀하신 내용은 아래 링크인 것 같습니다. https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html 예전에 유일하게 지원하던 방식으로 AWS IAM 보안주체와 EKS의 aws-auth라는 ConfigMap을 통해 권한을 부여하는 방식입니다. 다만, 이 방식은 AWS IAM 뿐만 아니라 EKS에 대한 이해도 필요하기 때문에 사용하기 쉽지는 않습니다. 그렇기에, 23년 12월에 출시한 EKS Cluster Access Management 라는 기능을 검토해보시길 추천드립니다. 기존엔 클러스터를 처음 생성한 사용자의 권한을 회수할 수 없었는데 콘솔에서 이를 확인하고 제거하는 것도 가능하고, 다양한 기본 권한 과 조건키 를 제공해서 EKS의 권한이 아니더라도 어느 정도 제어할 수 있습니다. 사진으로 보여드리면, (사진)클러스터의 Access에 가면, ConfigMap으로 기본 설정되어 있는 것을 볼 수 있습니다. "Manage access" 버튼을 누르고, (사진)위와 같이 사용 방법을 변경 가능합니다.(주의하실 점은 위로 올라갈 순 있지만, 다시 내려올 순 없습니다. 그러니 처음 적용은 EKS API and ConfigMap으로 하시고, 완벽히 마이그레이션이 완료되면 EKS API로 변경하시길 추천드립니다.) (사진)변경 후 잠시동안 Updating 상태로 변경되고, 완료되면 아래와 같이 설정을 할 수 있습니다. (사진)기존 ConfigMap 모드에서는 보이지 않던 클러스터 생성 보안주체도 보이고, 제거가 가능합니다.(사용사례가 더욱 다양해질 수 있게 변경 됐습니다.) (사진)"Create access entry" 버튼을 누르시고 필요한 정보를 입력하신 후에, (사진)필요한 정책과 접근 범위를 설정하시면 손 쉽게 사용자에게 권한을 부여하고 관리할 수 있습니다. 추가로, 문서는 아래 링크 참고 부탁드립니다. https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html 답변을 달고 보니, 이 정도는 강의에서 커버해도 괜찮겠다는 생각도 들었습니다. 추가 여부 검토해보겠습니다. 감사합니다.