현재 글은 상편에서 이어집니다.들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세히 알지 못하기 때문에 틀린 부분이 있을 수 있으며, 언제든지 지적바랍니다. 그리고 Github Action 과 관련된 개념 부분은 따로 설명하지 않습니다.  시나리오는 크게 Local 영역과 Remote(Git Runner) 영역으로 나눌 수 있습니다.  Local Local 영역부터 시작해보죠. Local 영역에선 미리 Python 을 빌드 한 후에 Artifacts Repository 에 업로드 합니다.Official Setup Python 액션을 보면 versions-manifest.json 에 Python 을 다운받을 수 있는 URL 이 명시되..

쿠버네티스 환경에선 ARC 를 이용하면 어렵지 않게 다양한 OS 위에 오토스케일링에 기반한 Runner 구현이 가능합니다. Karpenter 와 함께라면 더 효율적이죠. (Karpenter 과 궁금하다면 여기 참고, ARC 가 궁금하다면 여기 참고) 또한 EKS 에서 Linux 와 Windows 기반의 노드를 지원해주기 때문에 띄우기만 한다면 파드 단위로 Runner 를 배포할 수 있습니다. (EKS 에서 Windows 를 활성화 하는 방법이 궁금하다면 여기 참고) 하지만 MacOS 는 얘기가 달라요.. EKS 에서 지원을 안해줍니다.. 그래서 만약 MacOS 기반의 워커 노드를 프로비저닝 하려고 한다면, 아마 MacOS 기반의 인스턴스를 띄운 후 거기서 수동으로 EKS 클러스터에 조인해야 할 것입니다...

지난 글에서는 Action Controller Runner (이하 ARC) 를 사용할 때 AWS EFS 를 마운트해서 특정 경로에 build 에 필요한 데이터를 캐싱했습니다. 근데 만약 AWS EFS 와 같은 데이터를 저장할 수 있는 스토리지가 없다면 어떨까요? 다행히 충분히 좋은 대책안이 있습니다. 바로 Github Action 에서 제공해주는 Action Cache 이라는 녀석입니다. Github Action 을 사용한다면 아마 이미 다들 잘 아실 수도 있겠군요. Action Cache 는 좋아요 3.7k 를 받을 만큼 많은 사랑?을 받고 있는 액션 중의 하나입니다. 도큐먼트를 보면 꽤 자세하게 설명이 되어있습니다. 예제 코드도 존재하며, 각 필요한 with 에 대해서도 친절하게 설명해주고 있습니다...