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

들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세하게 알지 못하기 때문에 틀린 부분이 있을 수 있습니다. 지적은 언제든지 환영합니다 :) Github Action Marketplace 에는 다양한 액션들이 존재합니다. 그 중 Setup Node, Setup Go, Setup Python 액션 등을 통해서 필요한 언어나 툴을 러너에 설치하게 됩니다. 만약 러너에서 파이썬이 필요하다면,  Setup Python 액션을 실행해서 파이썬을 사용할 수 있는 환경을 구성할 수 있습니다.  그런데,  아쉽게도 Setup Python 액션은 Linux x64, Windows x64, MacOS Apple Silicon(Intel 포함) 은 지원..

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

들어가기 앞서 저는 Windows 를 많이 다뤄보지 않았기 때문에 부족하거나 틀린 부분이 있을 수 있습니다! 쿠버네티스는 v1.23 버전, Karpenter 는 v0.31 버전입니다. 쿠버네티스(EKS) 환경에 윈도우와 Karpenter 를 활성화 하는 방법에 대해선 여기를 참고하세요. Karpenter 에 대해 궁금하다면 여기를 참고하세요. 그럼 렛츠두더코드~ 우리가 쿠버네티스를 사용하는 방법은 바로 오케스트레이션을 위함이죠. 하나의 마스터 플레인으로 여러 노드의 여러 파드를 좀 더 쉽게 관리하기 위해서입니다. Action Runner 역시 예외는 아니죠. Action Runner Controller 를 이용하면 쉽게 쿠버네티스 환경에서 파드 단위의 Runner 배포가 가능합니다. 맨 처음 Action..

개발을 하다보면 한가지 버전뿐만 아니라 다양한 버전을 지원해줘야 합니다. 예를 들어 파이썬을 사용한다면 3.8, 3.9, 3.10 버전 모두 지원해주어야 하죠. 버전뿐만 OS 도 Linux x86, arm, Window, MacOS 등 다양하게 지원해주어야 합니다. C/C++ 로 만들어진 프로젝트를 swig 를 통해 파이썬, 자바, Go 등 다양한 언어과 다양한 버전에서 사용할 수 있는 패키지를 만들어야 했던 적이 있습니다. C/C++ 프로젝트에 사용되는 CMakeLists.txt(cmake) 와 Github Action 의 matrix 를 이용하면 어렵지 않게 다양한 버전의 패키지를 만들 수 있을 거 같습니다. 이번 글에서는 파이썬과 Linux x86 만 다루며, 3.8, 3.9, 3.10 버전의 파이..

C/C++ 기반의 프로젝트를 빌드하는데 있어 보통 cmake 와 make 를 이용해서 빌드를 하게 됩니다. 간략하게 cmake 는 CMakeList.txt 를 기반으로 Makefile 를 만들어주고, make 는 Makefile 를 통해 프로젝트를 빌드합니다. cmake 는 빌드를 위한 프로세스이고, make 는 실제로 빌드를 해주는 프로세스인 셈이죠. 그런데 C/C++ 프로젝트를 빌드하는데, 빌드 시간이 대략 1시간 정도 소모됩니다. 너무 오래걸려요.. 진행한 runner 는 2GB Memory 의 인스턴스입니다. 빌드 시간을 단축시키고 싶습니다. 빌드 시간을 단축시키기 위한 방법으로 가장 먼저 떠오르는 것은 바로 캐싱 입니다. 매번 같이 파일을 빌드하지 말고, 반복되는 빌드 파일을 캐싱해놓으면 시간이..

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

중요!! ARC 가 Github Official 프로젝트가 됨에 따라 아래에서 보여드린 ARC 관련한 리소스들은 전부 구 버전입니다. 여기를 참고해주세요! Action Controller Runner (이하 ARC) 는 파드 단위 Self Hosted Runner 입니다. 즉, 쿠버네티스 환경에서 파드를 Self Hosted Runner 로 지정할 수 있게 해주는 오픈소스죠. ARC 에 대한 정보는 여기를 확인해주세요. 근데 ARC 를 사용하는 경우 하나 고려해야 할 사항이 있습니다. 바로 ARC 에 의해 만들어지는 파드는 Github Action 의 Job 이 종료될 경우 제거되고 다시 생성됩니다. 따라서 HostPath 나 EFS 를 사용하지 않으면 Job 을 실행할 때 생성했던 Java SDK, N..