[DEVOPS-012][실무] 코드부터 모니터링까지 배포 흐름 만들기 > IT 기술 공유

• 목록

[이번 수업]

코드를 테스트해 결과물을 만들고 배포한 뒤 상태를 관찰합니다. 로컬 파이프라인으로 중단과 되돌리기 기준도 정합니다.

[선수지식]

DEVOPS-004의 지속적 통합, DEVOPS-005의 롤백, DEVOPS-008의 관측성, DEVOPS-009의 서비스 목표를 알면 좋습니다.

[학습목표]

1. 테스트→빌드→배포→검증→관찰 단계를 설명한다.
2. 같은 아티팩트를 환경 사이에서 승격한다.
3. 자동 중단과 롤백 조건을 수치로 정한다.

[핵심개념]

파이프라인은 변경을 반복 가능한 절차로 다음 단계에 전달하는 자동화 흐름입니다. 아티팩트는 한 번 빌드해 배포하는 파일이나 이미지입니다. 테스트를 통과한 같은 아티팩트를 환경 사이에서 승격해야 배포 대상을 추적할 수 있습니다. 환경마다 다시 빌드하면 결과가 달라질 수 있습니다.

기본 흐름은 검사·테스트, 빌드, 식별값 기록, 제한 배포, 상태 확인, 점진 확대입니다. 준비 상태는 요청을 받을 수 있는지, 생존 상태는 재시작이 필요한지 판단합니다. 둘을 섞으면 느린 시작 때 불필요한 재시작이 생길 수 있습니다.

모니터링은 서비스 상태를 계속 관찰하는 일입니다. 배포 버전과 시각을 로그·메트릭·트레이스에 표시하고 오류율과 지연시간 등을 비교합니다. 예를 들어 5분간 오류율이 2%를 넘으면 확대를 멈추고 직전 정상 버전으로 롤백하도록 정합니다.

[따라하기]

service.py를 만듭니다.
```python
VERSION = "1.0.0"

def health():
    return {"status": "ok", "version": VERSION}

if __name__ == "__main__":
    result = health()
    print(f"status={result['status']} version={result['version']}")
```

test_service.py를 만듭니다.
```python
import unittest
from service import health

class HealthTest(unittest.TestCase):
    def test_health_is_ok(self):
        self.assertEqual(health()["status"], "ok")

if __name__ == "__main__":
    unittest.main()
```

마지막으로 pipeline.py를 저장합니다. 이 예제의 빌드는 문법 검사, 배포는 별도 파일 복사로 작게 흉내 냅니다.
```python
import hashlib
import shutil
import subprocess
import sys

def run(stage, *command):
    print(f"stage={stage} status=start", flush=True)
    subprocess.run(command, check=True)
    print(f"stage={stage} status=ok", flush=True)

run("test", sys.executable, "-m", "unittest", "-v")
run("build", sys.executable, "-m", "py_compile", "service.py")
digest = hashlib.sha256(open("service.py", "rb").read()).hexdigest()
shutil.copy2("service.py", "release_service.py")
run("verify", sys.executable, "release_service.py")
print(f"artifact_sha256={digest[:12]}")
```

macOS·Linux는 `python3 pipeline.py`, Windows는 `py pipeline.py`를 실행합니다. 예상 결과에는 `Ran 1 test`, `OK`, 각 단계의 `status=ok`, `status=ok version=1.0.0`, 12자리 해시가 나옵니다. 실패한 명령에서는 즉시 멈춥니다. 생성된 release_service.py는 실습 뒤 지워도 됩니다.

운영에서는 빌드 결과와 해시를 보관하고, 검증 승인 뒤 소수 대상에 배포해 상태가 기준 안일 때만 확대합니다.

[흔한 실수]

테스트 실패 뒤 배포를 계속하거나 운영에서 다시 빌드하지 마세요. 고정되지 않은 표식만 쓰면 롤백 대상을 찾기 어렵습니다. 배포 메시지만 믿지 말고 사용자 경로와 준비 상태를 확인합니다.

[보안 주의]

파이프라인에는 최소 권한의 짧은 수명 자격을 사용하고 비밀값을 코드·로그·아티팩트에 넣지 않습니다. 외부 기여 코드는 비밀에 접근하지 못하는 격리 단계에서 검사하세요. 의존성과 실행 도구의 출처·버전을 고정하고, 승인 없는 운영 배포를 막습니다. 실습은 본인 소유 로컬 환경에서만 수행합니다.

[직접 해볼 과제]

VERSION을 1.0.1로 바꾸고 다시 실행해 새 해시를 기록하세요. 테스트를 일부러 실패시켜 release_service.py가 갱신되기 전에 멈추는지 확인한 뒤, 운영용 단계표에 배포 승인자·관찰 시간·오류율 중단 기준·롤백 명령을 추가합니다.

[확인문제]

1. 환경마다 아티팩트를 다시 빌드하지 않는 이유는 무엇인가요?
2. 준비 상태와 생존 상태 확인은 어떻게 다른가요?
3. 점진 배포 전에 자동 중단과 롤백 기준을 정해야 하는 이유는 무엇인가요?

[다음 학습]

SEC-012에서 격리된 환경 안에서 이 서비스의 설정·의존성·로그를 안전하게 점검합니다.

[공식 참고 자료]

https://csrc.nist.gov/pubs/sp/800/218/final
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://kubernetes.io/docs/concepts/workloads/pods/probes/
https://opentelemetry.io/docs/concepts/signals/
https://docs.python.org/3/library/unittest.html