현재 많이 사용하고 있는 Linux 배포판인 CentOS 7의 EOL이 2024년 6월 30일로 얼마 남지 않았습니다. 이에 따라 CentOS 7을 사용하는 많은 분들이 어떤 OS로 넘어갈지 고민에 빠져있을 것 같습니다. CentOS 7을 대체하기 위해서 Rocky Linux가 주목받고 있으며있으며 Rocky Linux를 설치하는 방법을 알아봅시다.
ISO 파일 다운로드
Rocky Linux 공식 홈페이지에서 최신 Rocky Linux 8 버전을 다운로드 받습니다. 최신 버전은 2022년 11월 14일에 Release된 8.7 버전입니다. https://rockylinux.org/download/
Rocky Linux 설치
Rocky Linux의 기본적인 설치 방법은 CentOS 7과 거의 동일하며 기존에 CentOS 7을 설치해보신 분들이라면 편하게 설치를 진행하실 수 있을 것 같습니다. 저는 Rocky Linux를 설치하기 위해 Hyper-V를 통해 진행하였습니다.
VM 실행 후 Rocky Linux 8 설치 화면에서 Install Rocky Linux 8을 선택합니다.
로딩 화면 후 설치 화면이 나오는데요. CentOS 7과 거의 동일한 것을 확인하실 수 있습니다. 언어 설정은 영어를 선택 후 넘어갑니다.
설치 메뉴 중 아래 화면에 체크한 항목을 설정 후 설치를 진행해보도록 하겠습니다.
첫 번째로는 TIME & DATE 설정입니다. Asia/Seoul로 설정합니다. 시간 설정은 설치 완료 후에도 수동으로 변경할 수 있습니다.
두 번째로는 SOFTWARE SELECTION 설정입니다. 저는 필요한 패키지만 설치하여 사용하기 위해 Server With GUI가 아닌 Minimal Install을 선택하였습니다. 기본 서버에 필요한 패키지를 설치하시려면 Server, 추가로 GUI 화면이 필요하시면 Server With GUI을 선택하시면 됩니다.
세 번째로는 INSTALLATION DESTINATION 설정입니다. 저는 수동으로 디스크를 설정하기위해 Custom을 선택하였습니다. 자동으로 설정되는 Automatic을 설정하셔도 상관 없습니다.
기본 디스크가 설정되도록 Click here to create them automatically를 선택합니다.
/home 디렉토리를 사용하지 않고 / 디렉토리만을 사용하기 위해 /home 디렉토리를 삭제하고 남은 디스크 용량을 / 디렉토리에 할당합니다.
설정 변경사항을 확인 후 적용합니다.
네 번째로는 KDUMP 설정입니다. 기본 설정은 사용하도록 체크되어있으며 사용하지 않을 것이므로 해제합니다.
마지막으로 ROOT PASSWORD 설정입니다. 설정하고자하는 ROOT PASSWORD를 입력하여 설정합니다.
설정이 완료되면 Begin Installation 버튼을 클릭하여 설치를 진행합니다.
설치가 진행되고 완료되면 Reboot System 버튼을 클릭하여 시스템을 재시작 합니다.
이제 시스템 부팅이 완료되면 설치된 Rocky Linux 커널 버전을 확인하실 수 있고, 로그인을 통해 Rocky Linux를 사용하실 수 있습니다.
AWS의 Amazon SageMaker를 통해 기존에 물리서버에서 하고있었던 기계 학습(Machine Learning) 환경을 Public Cloud 환경에서도 구현가능한지 확인해보고, 비용 측면이나 활용도 측면에서도 정말 좋은지 확인해보고자 작업을 진행하고 있습니다. Amazon SageMaker를 활용하기 위해 좀 더 알아본 내용과 AWS SageMaker 교육을 통해 알아본 내용을 같이 정리해보았습니다.
개요
Amazon SageMaker는 AWS에서 2017년 11월에 출시된 Cloud 기계 학습(Machine Learning) 서비스 입니다.
SageMaker를 사용하면 개발자가 Cloud 환경에서 기계 학습 모델을 생성, 학습 및 배포할 수 있습니다. 기계 학습을 위해 다양한 언어를 지원할 뿐만 아니라 학습 환경 구성, 학습, 배포하기 위한 pipeline을 제공하여 MLOps를 구현할 수도 있습니다. EC2에서 사용가능한 다양한 GPU 인스턴스를 제공하여 적합한 사양의 서버를 사용하여 기계 학습 시 사용할 수 있습니다. 제품 추천, 개인화, 지능형 쇼핑, 로봇 공학, 음성 지원 디바이스를 포함하여 20년에 걸친 Amazon의 실제 기계 학습 애플리케이션 개발 경험에 기반하여 구축된 서비스입니다.
사용 효과
아래 이미지는 AWS의 자료로 Amazon SageMaker를 사용하면 다양한 사용 효과를 얻을 수 있다고 합니다.
TCO(Total Cost of Ownership) : IT 인프라를 구매, 설치, 실행 및 유지 관리하는 과정에서 발생하는 모든 비용
개인적인 생각으로는 AWS의 GPU 인스턴스의 가격이 저렴하진 않기 때문에 비용적인 측면은 많은 고민이 필요할 것 같지만, MLOps를 구현한다면 팀 생산성 증가와 자동화로 인한 비용 감소를 예측할 수 있을 것 같다는 생각이 듭니다.
다양한 지원
선도적인 기계 학습 프레임워크, 도구 키트 및 프로그래밍 언어 등 다양한 지원을 통해 더욱 자유롭고 효율적으로 Amazon SageMaker를 사용할 수 있도록 지원하고 있습니다.
프로그래밍 언어 같은 경우에는 다양한 언어를 지원하지만 내부적으로 python을 기준으로 동작한다고하니 참고하시면 좋을 것 같습니다.
다양한 기능
기계 학습에 기본적으로 필요한 Train, Pipelines, Deploy 등 뿐만 아니라 기계 학습 환경을 자유롭고, 간단하게 구성하기 위한 Notebooks, Model Monitor, Studio, Feature Store, Automatic Model Tuning 등 다양한 기능을 제공하고 있습니다.
Amazon SageMaker Features
다양한 기능을 사용하여 최적의 학습 환경 및 MLOps를 구축할 수 있을 것 같습니다.
사용 고객
아래 이미지는 AWS의 자료로 Amazon SageMaker를해외 기업뿐만 아니라 국내 기업에서도 Amazon SageMaker를 많이 사용하고 있는 것을 확인하실 수 있습니다.
AWS 기술 블로그에서는 Amazon SageMaker를 사용하여 모델을 개발하거나, 어떤식으로 사용하였는지 다양한 정보를 확인하실 수 있습니다.
Jenkins 에서는 Artifact 플러그인 기능을 사용하여 생성된 Artifact를 저장하거나 복사하여 필요한 프로젝트 및 빌드에서 사용할 수 있습니다. Jenkins Pipeline에서 Artifacts 기능을 활용하는 방법을 알아봅시다.
Artifacts 정의
우선 Artifacts 기능을 활용하기 전에 Artifacts에 대한 정의를 알아봅시다.
위키백과에서는 Artifacts를 소프트웨어 개발 과정에서 생성되는 다양한 유형의 부산물 중 하나라고 설명하고 있습니다. 일부 Artifacts(예: 사용 사례, 클래스 다이어그램 및 기타 UML(Unified Modeling Language) 모델, 요구 사항 및 디자인 문서)는 소프트웨어의 기능, 아키텍처 및 디자인을 설명하는 데 도움이 되고, 다른 Artifacts는 프로젝트 계획, 비즈니스 사례 및 위험 평가와 같은 개발 프로세스 자체와 관련이 있다고 설명하고 있습니다.
artifacts로 파일 및 디렉토리 지정 시 glob 형식의 패턴을 통해 아래와 같이 사용할 수 있습니다.
### target 디렉토리에 있는 main.jar 파일 지정
archiveArtifacts artifacts: 'target/main.jar'
### target 디렉토리에 있는 *.jar 파일 지정
archiveArtifacts artifacts: 'target/*.jar'
### target 디렉토리에 있는 *.jar 파일과 *.war 파일 지정
archiveArtifacts artifacts: 'target/*.jar, target/*.war'
### 모든 디렉토리에 있는 *.jar 파일 지정
archiveArtifacts artifacts: '**/*.jar'
여러 옵션을 사용하여 아래와 같이 사용할 수도 있습니다.
excludes: 디렉토리 경로 및 파일의 패턴을 지정하여 제외할 수 있습니다. 설정 패턴은 artifacts와 동일하게 사용 가능합니다.
allowEmptyArchive: 빌드 아티팩트가 없는 경우도 아카이브에 추가할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 아카이브가 빈 상태가 될 수 있습니다.
caseSensitive: 아카이브 내 파일 이름 검색시 대소문자를 구분할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 대소문자를 구분합니다.
defaultExcludes: 아카이브에서 기본적으로 제외할 파일을 결정합니다. 기본값은 true이며, false로 설정하면 Ant 파일 패턴을 사용하여 제외할 파일을 지정할 수 있습니다.
fingerprint: 빌드 아티팩트의 지문(fingerprint)을 생성하여 추적할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 빌드 아티팩트가 변경될 때마다 새로운 지문이 생성됩니다.
followSymlinks: 심볼릭 링크를 따라가서 링크가 가리키는 실제 파일을 아카이브할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 심볼릭 링크가 아닌 실제 파일이 아카이브됩니다.
onlyIfSuccessful: 빌드가 성공했을 때만 아카이브를 생성할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 빌드가 실패했을 때는 아카이브를 생성하지 않습니다.
Artifact 복사 (copyArtifacts)
archiveArtifacts{} 구문을 통해 저장된 파일을 copyArtifacts{} 구문을 통해 복사할 수 있습니다. 기본적인 구문은 아래와 같이 사용됩니다. projectName 필드 설정으로 가져올 빌드의 이름을 지정하여 파일을 복사하는 설정입니다. 다른 프로젝트 빌드에 저장되어 있는 Artifact를 복사하여 사용할 수도 있습니다.
이제 저장된 Artifact를 복사하여 사용하기 위해 아래와 같이 코드를 구성하였습니다. pipeline-project-name 이름으로 저장된 빌드의 Artifact를 설정하고, 동일하게 'vendor/**, bin/**' 디렉토리를 지정하였습니다. 복사하는 Artifact는 build/ 디렉토리에 저장되도록 구성하였으며 복사할 Artifact가 없더라도 빌드가 실패하지 않도록 설정하였습니다.
Window 환경의 Jenkins에서 Cannot run program git.exe 에러 발생 시 해결하는 방법입니다.
Jenkins에서 Pipeline 실행 시 git.exe를 실행하지 못할 경우 아래와 같이 에러가 발생합니다.
git.exe 파일의 경로를 찾지 못하는 것으로 Jenkins 웹 관리자 페이지에서 Jenkins 관리 -> Global Tool Configuration 설정을 통해 git.exe 경로를 추가해줍니다. Git installations 설정 중 Path to Git executable 설정을 Window 환경에 맞는 값으로 설정합니다.
설정 저장 후 다시 Pipeline 실행 시 정상적으로 git.exe를 실행하는 것을 확인하실 수 있습니다.
지금까지 Cannot run program git.exe 에러 발생 시 해결하는 방법을 알아보았습니다...! 끝...!
GitLab 프로젝트 연동과 간단히 Pipeline을 동작하는 설정을 완료하였고, 이제 WebHook을 연동하여 Commit 등의 Event 시 자동으로 Jenkins Pipeline이 동작되도록 설정해봅시다.
WebHook 설정
설정하고자하는 Pipeline의 상세 설정의 Build Triggers 설정합니다.
Trigger 받고자하는 Event를 선택하고 자동으로 생성되는 WebHook URL을 복사해둡니다.
하단의 고급 버튼을 클릭하여 상세 설정을 확인합니다.
Secret token 항목에서 Generate 버튼을 클릭하여 GitLab WebHook과 연동할 token 값을 생성합니다. 해당 token 값은 이후에 사용해야하므로 복사해둡니다.
설정을 완료하면 Pipeline 설정을 저장합니다.
이제 GitLab 프로젝트에서 WebHook 설정을 추가해봅시다. GitLab 프로젝트 Settings -> Webhooks 메뉴를 클릭합니다.
아까 복사해둔 WebHook URL 값과 Secret token 값을 URL, Secret token 항목에 붙여 넣습니다.
그리고 사용하고자 하는 Trigger Event를 선택해주시면 됩니다.
WebHook 설정을 추가하면 아래와 같이 추가된 설정을 확인하실 수 있습니다.
Test를 통해 WebHook이 정상적으로 연결되었는지 확인합니다.
정상적으로 WebHook 설정이 완료되었으면 상단에 "Hook executed successfully: HTTP 200" 메시지가 출력된 것을 확인하실 수 있습니다.
WebHook 테스트
WebHook 연동 설정이 완료되었으므로 해당 프로젝트에서 소스 코드 수정 및 Commit 후 자동으로 Pipeline이 동작하는지 확인합니다. Pipeline 관리 페이지를 열어둔 상태에서 프로젝트에 Commit을 해봅니다. WebHook 연동 설정을 통해 자동으로 Pipeline 빌드가 실행됩니다.
Pipeline 빌드가 완료되면 해당하는 Build ID 클릭 후 아래와 같이 빌드 상태를 확인할 수 있습니다.
지금까지 Jenkins에서 GitLab 프로젝트와의 연동과 WebHook을 통한 Pipeline 자동화 구축 작업을 완료하였습니다...! 끝...!
