Gitlab으로 CI/CD하기( DevOps 구축 )

DevOps = Development + Operations

개발 조직과 운영 조직을 융합하기 위한 개발 방법론이다.

운영 조직에서는 서비스를 안정적으로 운영, 확장, 관리하는 것이 중요하다.

트래픽 모니터링, 재고 용량에 대해서 모니터링 등의 작업을 수행한다.

개발 조직에서는 기획에 따라서 새로운 기능을 개발하거나,

버그 수정, 성능 최적화 등을 수행한다.

어떤 작업을 수행하든 코드의 변경이 운영 조직에 영향을 미치고

결국에는 운영 서버에 반영돼야한다.

개선이 신속하고 빈틈없이 운영 서버에 반영되려면

개선된 코드가 사전에 약속된 환경에서 Build 되고

테스트를 통과해야하며

위 조건들을 만족할 때 배포되어야한다.

DevOps 개발 방법론이 대두되면서

다양한 클라우드 서비스 벤더들도 DevOps와 연관된 서비스를 출시했다.

각 서비스는 프로젝트를 빌드, 테스트, 배포할 수 있는 자동화된 서비스를 제공한다.

AWS의 경우 CodeCommit, CodeBuild, CodeDeploy, CodePipeline 등이 있다.

여기에 사용자 접근 권한이나 환경 변수 보안을 위해 추가적으로 

IAM이나 Parameter Store를 적용할 수 있겠다.

Gitlab CI와 대응하는 서비스로는 Jenkins, TracisCI가 있다.   -> 빌드, 테스트 자동화 

CD와 대응하는 서비스로는 AWS CodeDeploy가 있다. -> 배포 자동화

Gitlab에서는 Gitlab CI/CD를 제공한다.

다음은 https://gitlab.com 을 사용하여 구축하는 방법을 기입했다.

gitlab은 설치형 버전관리 시스템이기 때문에

온프레미스 서버든, 클라우드 서버를 구성할 경우

해당 서버의 정보를 연결하여 runner를 구성할 수 있다.

Gitlab CI/CD의 작동에 필요한 조건 2가지가 있다.

0 gitlab-runner.exe를 통해 runner 등록

    runner는 GitLab으로부터 소스를 다운 받아 Build 하고 

    Deploy하는 바이너리 파일이다.

    runner는 gitlab의 push event에 따라 입력한 커맨드를 실행한다.

    
    윈도우 기준으로, 바이너리 파일을 

    '관리자 권한'을 가진 CMD로 runner를 실행시킨 뒤,
    (cmd - > gitlab-runner.exe register)

    Gitlab CI에서 발급한 토큰을 입력하고
    runner의 설명, 태그 등을 입력한다.

    runner 실행 형식을 입력한다.
    local 환경에서 실행할 때는 shell,

    별도로 명세한 환경이 있을 때는 docker와 같은 컨테이너를 활용한다. 

    

    

    

    입력이 끝나면 해당 프로젝트의 설정 - CI/CD에
    내가 설정한 Runner가 등록되어 있을 것이다. 

1 Runner 타입 설정

   runner에는 Shared, Group, Specific runners 가 있다.

   Shared는 설정한 runner를 모든 그룹, 리포지토리에서 사용할 수 있게 공유한다.

   Group은 runner가 등록된 그룹의 하위 리포지토리, 하위 그룹에서만 공유한다.

   Specific은 1개의 리포지토리에서만 실행되는 runner다. 

2 .gitlab-ci.yml

    runner등록이 끝나면 

    yml파일에

    

    어떤 환경에서 빌드할 지

    어떤 테스트를 수행할 지,

    어떤 작업을 수행할 지,

    어디로 배포할 지 등을 총 명세한다.
    

    gitlab에 push를 하게 되면
    .gitlab-ci.yml에 명세된 대로 파이프라인이 구축되어 실행된다.