GitLab CI/CD · 현장에서의 파이프라인 · 퀴즈
퀴즈: 러너와 안전장치
문항 5개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
설정에 문법 오류가 없는데 잡이 계속 대기 상태로만 남아 있다. 가장 먼저 의심할 것은?
- 잡의 tags 를 만족하는 러너가 등록돼 있지 않다
- 스테이지 이름의 철자가 stages 목록과 다르다
- 앞 잡이 만든 아티팩트의 만료 기간이 지났다
- 캐시 저장 공간의 한도를 넘겨 축출이 일어났다
CI 변수의 '마스킹' 에 대한 설명으로 옳은 것은?
- 보호 브랜치에서 도는 잡에만 값을 넘겨 주는 접근 제어 장치다
- 로그 출력에서 값을 가려 줄 뿐이라 인코딩해 찍으면 그대로 드러난다
- 값을 암호화해 저장하므로 관리자도 원본을 볼 수 없게 만든다
- 포크에서 온 병합 요청에 변수가 넘어가지 않게 막아 준다
다른 저장소의 템플릿을 `include` 로 가져올 때 `ref` 를 커밋 SHA 로 고정하는 이유는?
- SHA 로 적으면 템플릿을 내려받는 속도가 눈에 띄게 빨라지기 때문
- 브랜치 이름으로 적으면 GitLab 이 include 자체를 거부하기 때문
- 브랜치는 나중에 다른 커밋을 가리킬 수 있어 우리 설정이 조용히 바뀌기 때문
- 커밋 SHA 로 적어야 템플릿 안의 변수를 덮어쓸 수 있기 때문
운영 배포 잡을 승인 게이트로 만들려면 무엇이 필요한가?
- when 을 manual 로 두고 allow_failure 를 false 로 명시한다
- when 을 always 로 두고 stage 를 맨 뒤로 옮긴다
- needs 를 비워 다른 잡을 기다리지 않게 만든다
- rules 를 지우고 only 로 브랜치를 지정한다
배포에 쓰는 이미지 태그를 커밋 SHA 로 두면 얻는 것은?
- 레지스트리 저장 용량이 줄어 비용이 함께 내려간다
- 이미지 빌드 시간이 캐시 적중으로 크게 짧아진다
- 러너가 이미지를 내려받는 시간이 절반으로 줄어든다
- 사고 때 무엇이 나갔는지 확정할 수 있고 되돌릴 대상이 남는다