소개
현재 카카오뱅크에서 클라우드 엔지니어로 근무하고 있습니다. 서비스를 위한 아키텍처를 설계/제공하고, 조직에서 필요한 다양한 도구들을 만들고 제공하거나 구축하는 등의 일을 하고 있습니다.
강의
전체4수강평
게시글
질문&답변
2024.05.13
AWS 역할에 대해서
안녕하세요. 질문으로 미루어 보아, GitLab Runner도 온프렘에 있는 것으로 보입니다. 이런 경우, 아래와 같이 사용이 가능할 것 같습니다. 엑세스키 발급 원하시는 바는 아닐 것으로 보입니다. RolesAnywhere (권장) 인증서를 기반으로 임시 자격 증명을 사용 가능합니다. 다만, 적용 시 설계나 향후 관리에 대한 고민이 필요합니다. 만약, Runner를 AWS로 옮길 수 있다면 아래와 같은 방식으로도 활용이 가능합니다. EC2를 사용하는 경우 인스턴스 프로파일 EKS를 활용하는 경우, IRSA 또는 Pod Identity 감사합니다.
- 1
- 1
- 44
질문&답변
2024.04.23
강의 교안
안녕하세요! 0.0 강의자료에 보면 pdf가 첨부되어있습니다!
- 0
- 1
- 57
질문&답변
2024.03.19
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로 띄워서 사용하면 되긴 하지만 당연하게도 은탄환은 없기 때문에 추가로 희생되는 것들이 있긴 합니다.(도입하시기 전에 여러방면으로 꼭 테스트 많이 해보시길 권해드립니다.) 참고 부탁드립니다. 감사합니다.
- 2
- 1
- 108
질문&답변
2024.03.18
Kaniko 의 한계 부분에 대한 질문
안녕하세요. "기본적인 이미지" 의 의미는 "파이프라인에서 생성되어야 하는 것을 제외한 모든 것들" 이라고 봐주시면 됩니다.(무조건은 아닙니다. 당연히 환경마다 달라질 수 있겠죠?) 강의는 Python을 기반으로 하기 때문에, 파이프라인에서도 컨테이너 이미지를 생성하기 위한 빌드를 제외하면 추가로 빌드할 것들이 없었습니다. 하지만, 소스코드를 바이너리로 바꾸는 과정이 필요한 언어들(golang 등)은 파이프라인 내에서 추가적인 빌드가 필요할 겁니다. 이러한 과정을 위해 필요한 파일들을 언급한거다(굳이 CI/CD 파이프라인에서 받을 필요가 없는 것들) 라고 봐주시면 됩니다. 이외에도, 필수 패키지(net-tools, procps 등)가 될 수도 있고, 내가 운영하고 있는 환경에 맞춰 추가적인 무언가가 필요할 수도 있을 겁니다. 요약하면, kaniko의 태생적 한계(호스트에 다운로드 후 스냅샷 생성)를 극복하기 위해 다양한 옵션(--use-new-run, --single-snapshot)을 사용하게 되면 레이어에 대한 캐시 적중률 문제 와 (거의 그럴 일은 없지만 동작방식의 한계로 인한) 비정상적인 이미지가 생성되는 것 을 막기 위해, 최대한 파이프라인 과정에서 생성되는 파일을 줄이고 캐시를 활용하자 라는 취지로 말씀드렸습니다.(어느 정도의 스냅샷은 감수할 수 있도록요.) 감사합니다.
- 1
- 1
- 74
질문&답변
2024.03.13
artifacts 에 대한 질문이 있습니다!
안녕하세요. 좋은 질문 감사드립니다. 결론부터 말씀드리면, 아티팩트는 MR에 통합되는 보고서를 생성하거나 후속 작업(job)에서 사용이 필요한 경우 에 보통 사용하게 되고(무조건 존재 해야함), 캐시는 있으면 좋고 없어도 효율이 조금 낮아질 뿐이지 작업이 동작하는데 문제 없는 경우 에 사용하시면 좋습니다.(당연히 상황마다 달라질 순 있습니다.) 또한, 아티팩트는 현재 파이프라인에서만 유효하지만, 캐시는 언제든 사용할 수 있다는 장점도 있습니다. 위의 기준을 통해 답변 드리면, 파이프라인 내에서 빌드 후 생성한 아티팩트를 후속 작업에서 사용하고 싶다면 아티팩트를 사용하셔도 무방하고, 그게 아니라 파이프라인이 동작할 때 마다 가져오고 싶다면 캐시를 선택하시면 될 것으로 보입니다. 추가로, 빌드라는게 컨테이너 빌드를 말씀하시는 거면 뒤에서 배울 kaniko 파트에서 빌드 간 발생하는 레이어들을 컨테이너 레지스트리에 캐시하는 방법도 있으니 참고 하시면 좋을 것 같습니다.(컨테이너 이미지가 커질수록 전체를 아티팩트나 캐시에 보관하는 것은 정말 비효율적입니다!)
- 1
- 1
- 91