3 일 동안 Gitlab CI 를 셸 executor 에서 Docker 환경 으로 부 드 럽 게 옮 겼 습 니 다.

본문https://blog.shifudao.com링크
머리말
앞의 글 에서 나 는 용기 화 납품 소프트웨어 에 대해 소프트웨어 자체 가 용기 환경 에 어떻게 적합 하도록 해 야 하 는 지 에 대해 이야기 했다.오늘 글 을 써 서 내 가 왜 Gitlab CI 를 Docker 환경 으로 옮 겨 야 하 는 지, 그리고 내 가 어떤 노력 을 했 는 지 이야기 하 자.
내 가 왜 CI 를 Docker 환경 으로 옮 겼 습 니까?
이전에 우리 의 Gitlab 은 이미 온라인 에서 여러 해 동안 운행 되 었 고 CI 프로 세 스 는 상대 적 으로 성숙 했다.CI 가 일찍 사용 되 었 기 때문에 그 당시 Gitlab CI 도 셸 executor 만 지원 하기 때문에 셸 executor 를 사용 하여 현재 사용 하고 잘 작 동 하고 있 습 니 다.
프로젝트 가 점점 많아 지면 서 개발 리듬 이 원활 해 지면 서 셸 executor 의 일부 문제 도 점점 드 러 났 다.

병행 화 하기 어렵 고 자원 충돌 이 심각 하 다.테스트 를 할 때 PostgreSQL 을 사용 해 야 합 니 다. 테스트 가 정상적으로 실 행 될 수 있 도록 runner 의 병발 수 를 1

로 제한 할 수 밖 에 없습니다.

자원 이용 이 충분 하지 않다.예 를 들 어 어떤 통합 테스트 는 10 분 정도 달 려 야 하지만 전체적으로 서버 에 대한 자원 소모 가 크 지 않다. runner 의 병발 수가 1 이기 때문에 다른 CI 작업 은 줄 을 서서 기다 릴 수 밖 에 없다.제출 이 밀집 되 었 을 때 전체 CI 라인 의 효율 은 프로젝트 납품 의 병목 이 되 었 다

.

격 리 성 이 떨어진다.셸 runner 는 시스템 의 셸 을 직접 사용 하고 시스템 의 운영 환경 을 사용 합 니 다. 실행 중인 다른 시스템 에 영향 을 주지 않 기 위해 서 는 기본적으로 CI 에 한 대, 심지어 몇 대의 서버

를 따로 배치 해 야 합 니 다.

배치 가 번거롭다.CI 서버 를 옮 기기 위해 서 라면, 사람 을 괴 롭 히 는 일이 다.저 는 깨끗 한 서버 에 JDK, NodeJS, PostgreSQL, Android SDK, Hugo,... 디 렉 터 리, 데이터 베이스 등 을 초기 화하 고 합 리 적 인 권한 을 설정 해 야 합 니 다.이 일 들 은 적어도 하루 의 작업량 이 필요 하 다.집적 환경 을 함께 포장 해 가 져 갈 수 있다 면 좋 은 경험 이다.

Docker 가 등장 하면 서 이런 환경 격 리 문제 가 해결 되 었 기 때문에 병행 화 흐름 선의 문제 도 쉽게 해결 되 었 다.또한 환경의 격 리 성 때문에 저 는 안심 하고 일부 자원 이용 이 충분 하지 않 은 서버 에 docker executor 를 배치 하여 CI 절 차 를 진행 할 수 있 습 니 다. 실행 중인 시스템 과 응용 에 방해 가 되 지 않 습 니 다.이렇게 해서 전체 CI 의 배치 작업량 이 많이 줄 어 들 었 고 CI 의 효율 을 크게 향상 시 켰 다.
Docker executor 를 간단하게 체험 한 후에 저 는 CI 환경 을 Docker 환경 으로 점차적으로 옮 기기 로 결 심 했 습 니 다.
나 는 어떤 일 을 했 습 니까?
Docker 환경 에서 CI 환경 을 구축 하 는 것 은 쉬 운 일이 아 닙 니 다. 셸 환경 에서 CI 를 직접 실행 하 는 것 에 비해:

디 버 깅 이 번거롭다.셸 환경 은 운영 체제 의 파일 시스템 에 직접 접근 하여 구축 로 그 를 받 을 수 있 고 구축 오 류 를 재현 하고 조정 하기 쉽다.하지만 Docker 환경 은 완전히 다른 세상 입 니 다.용기 운행 이 끝나 면 소각 되 고 특별한 처 리 를 하지 않 으 면 운행 로 그 를 받 기 어렵 고 고장 재현 도 셸 만큼 편리 하지 않다.docker in docker 환경 을 실행 하면 디 버 깅 이 더 번 거 롭 습 니 다.

집적 문제.Docker 는 시작 할 때마다 완전히 깨끗 한 환경 이 고 테스트 에 있어 서 가장 이상 적 인 환경 이지 만 이런 환경 을 구축 하 는 데 있어 서 비교적 번거롭다.저 는 이 stage 가 어떤 환경 을 사용 해 야 하 는 지 미리 머 릿 속 에서 살 펴 본 다음 에 이런 환경 을 준비 하 는 Docker 미 러 에 대응 한 다음 에 머 릿 속 에서 그들 이 어떻게 조립 되 었 는 지, 그리고 용기 에서 제 가 해당 하 는 운행 환경 을 어떻게 초기 화 해 야 하 는 지 생각해 야 합 니 다.이에 비해 셸 환경 은 첫 번 째 배치 가 매우 번 거 롭 고 작업량 이 많 지만 일회 성 작업 이기 때문에 앞으로 운행 하기 가 매우 쉽다.

상대 적 으로 오래 걸린다.디 버 깅 CI 환경 에 서 는 수시로 문제 가 발생 할 수 있 으 며, 미 러 를 업데이트 해 야 하 는 문제 등 이 걸 려 있다.Docker 환경 에서 CI 를 실행 하 는 데 셸 보다 더 많은 시간 이 걸 리 기 때문에 디 버 깅 시간

을 늘 렸 습 니 다.
docker executor 를 추가 하 는 것 은 어렵 지 않 지만 docker executor 에서 docker 미 러 를 구축 하기 위해 서 는 docker in docker 환경 이 필요 하기 때문에 runner 를 추가 할 때 runner 인 자 를 주의해 야 합 니 다.
셸 runner 와 달리 (오래된 호환성 을 고려 해 야 합 니 다. 다음은 설명 합 니 다) tag docker 를 추가 해 야 합 니 다. 이것 은 runner register 인 자 를 통 해 gitlab 페이지 에 직접 추가 할 수 있 습 니 다.
자체 제작 거울.실제로 가장 시간 이 걸 리 는 것 도 이 부분 이다.일부 구 축 된 환경 은 비교적 번 거 롭 고 여러 개의 기술 창고 가 필요 하 며 Docker 의 미 러 는 대부분 단일 실행 환경의 미 러 이기 때문에 자체 적 으로 미 러 를 맞 춰 야 합 니 다 (예 를 들 어 ionic, Android 의 apk 설치 패 키 지 를 구축 하기 위해 서 는 환경 이 nodejs, 자바, gradle, android sdk 등 여러 가지 운영 환경 이 있어 야 구축 할 수 있 습 니 다).
예 를 들 어 나 자신 은 다음 과 같은 몇 개의 미 러 를 구축 했다.

abcfy2/node_android

abcfy2/zhparser

abcfy2/deploy-cloud

겉 으로 는 셸 환경 보다 작업량 이 훨씬 많 지만 이런 작업량 의 지불 은 가치 가 있다.한 팀 에 있어 대부분 상황 에서 기술 스 택 은 상대 적 으로 안정 을 유지 하기 때문에 한 번 구 축 된 docker 미 러 는 여러 프로젝트 에서 재 활용 할 수 있 고 구축 환경 을 편리 하 게 가지 고 이전 할 수 있 으 며 docker 환경 만 있 으 면 전체 CI 환경 을 포장 할 수 있다.
또한, 미 러 의 필요 한 업 데 이 트 를 위해 github action 정시 작업 을 추가 하 였 습 니 다. FROM 미 러 업데이트 가 감지 되 었 을 때 자동 build (docker hub 의 auto rebuild 는 공식 미 러 업데이트 로 인해 트리거 되 지 않 습 니 다)
사후 주의사항
셸 executor 호환성
이전에 대량의 프로젝트 가 셸 executor 환경 에서 달 렸 기 때문에 먼저 이 오래된 프로젝트 들 이 정상적으로 실 행 될 수 있 도록 해 야 합 니 다. gitlab 는 두 개의 CI 환경 을 동시에 실행 할 것 입 니 다.셸 executor 를 기본 runner 로 만 들 기 위해 서 는 runner 설정 Run untagged jobs 을 선택해 야 하 며, docker runner 는 이 옵션 을 선택 할 수 없습니다.
docker 를 사용 하고 자 하 는 항목 에 대해 .gitlab-ci.yml 설정 에서 tag 선택 을 강제로 지정 합 니 다.

job:
  stage: build
  image: myimage
  scripts:
  - echo hello
  tags:
  - docker

이렇게 하면 docker 환경 으로 새로 이전 한 프로젝트 에 대해 ci 스 크 립 트 를 수정 하면 되 며, 오래된 프로젝트 를 호 환 하여 부 드 럽 게 이전 할 수 있 습 니 다.
용량 고려
docker 환경 구축 은 더 큰 디스크 공간 이 필요 합 니 다. 미 러, 용기, 저장 볼 륨, 캐 시 등 은 셸 환경 에서 몇 배 이상 의 저장 공간 을 차지 합 니 다.디스크 공간 이 넉넉 하지 않 은 서버 로 서 는 제 한 된 저장 공간 을 어떻게 활용 할 것 인 가 를 충분히 고려 해 야 한다.예 를 들 면:

가능 한 한 미 러 레이 어 (같은 버 전의 알파 인 을 기본 미 러 등 으로 사용)

정시 작업 을 통 해 활성화 되 지 않 은 용기 와 저장 소 볼 륨 을 제거 합 니 다

캐 시 고려
구축 속 도 를 높이 기 위해 서 는 캐 시 구축 (일반적으로 도구 캐 시 구축 의존 패키지 등) 을 사용 해 야 합 니 다.셸 환경 에 서 는 캐 시 를 위해 특별히 고려 할 필요 가 없습니다. 시스템 파일 시스템 을 직접 사용 하기 때문에 캐 시 는 디스크 에 직접 저 장 됩 니 다.그러나 docker 환경 에 대해 서 는 고려 해 야 한다.gitlab ci 는 캐 시 에 cache 명령 제어 가 있 습 니 다. 여 기 는 참고 할 수 있 습 니 다.
gradle 캐 시

variables:
  GRADLE_USER_HOME: build/gradle_user_home

cache:
  key: my-project
  paths:
  - ${GRADLE_USER_HOME}/caches/
  - ${GRADLE_USER_HOME}/wrapper/

nodejs 캐 시

variables:
  NPM_CONFIG_CACHE: npm_cache
  NPM_CONFIG_REGISTRY: https://registry.npm.taobao.org
  NPM_CONFIG_ELECTRON_MIRROR: https://npm.taobao.org/mirrors/electron/
  SASS_BINARY_SITE: https://npm.taobao.org/mirrors/node-sass
  NPM_CONFIG_PHANTOMJS_CDNURL: https://npm.taobao.org/mirrors/phantomjs

cache:
  key: my-another-project
  paths:
  - ${NPM_CONFIG_CACHE}

gitlab ci 의 cache 는 상대 경로 만 지원 할 수 있 고 절대 경 로 를 사용 할 수 없 기 때문에 구축 도구 가 만 든 캐 시 를 현재 디 렉 터 리 로 변경 해 야 합 니 다.key 을 더 하고 프로젝트 이름 으로 표시 하 는 것 은 가능 한 한 캐 시 를 재 활용 하기 위해 서 입 니 다.한 항목 이 상대 적 으로 안정 적 이기 때문에 지정 한 항목 이름 key 은 가능 한 한 같은 캐 시 를 재 활용 할 수 있 습 니 다 (예 를 들 어 fork 항목 도 상위 캐 시 의 장점 을 누 릴 수 있 습 니 다).
후기
이번 Gitlab CI 이전 을 통 해 서버 의 자원 이 용 률 이 크게 향상 되 었 고 앞으로 k8s 클 러 스 터 로 편리 하 게 이전 할 수 있 도록 기반 을 다 져 주 었 습 니 다.앞으로 아 리 클 라 우 드 의 server less k8s 클 러 스 터 환경 을 CI 로 사용 할 수 있 기 를 기대 하 며 일부 세부 사항 은 아직 연구 중이 다.
또한 낡은 CI 환경 호환성 을 충분히 고려 하여 부 드 럽 게 전환 할 수 있 습 니 다.일부 오래된 프로젝트 나 유지 하지 않 는 프로젝트 에 대해 낡은 환경 을 유지 하면 됩 니 다. 너무 의존 해서 docker 에서 구축 하기 어 려 운 프로젝트 에 대해 낡은 환경 을 유지 하면 됩 니 다. 기술 을 위해 기술 할 필요 가 없 으 면 의 미 를 잃 습 니 다.