전쟁 이야기: fleet OS 업그레이드

"Mac 하나 업그레이드는 잡일이야. 아홉을, 하나도 벽돌 안 만들고 뭐가 됐는지 거짓말도 안 하면서 하는 건, campaign 이야."

승인 때 정확한 빌드를 굳혀

첫 수는 승인 시점에 정확한 버전이랑 빌드 번호를 못 박는 거야. 최신 도, 돌 때 제일 새 것 도 아니라 특정한, 굳은 빌드. 그래야 다음 날 아침 나온 Apple release 가 campaign 을 조용히 못 바꾸거나 넓혀. 그리고 exact-build 동등이 설치 후 기준이 돼. 기계는 재부팅했다고 끝난 게 아니라 그 빌드에 올라섰다고 끝난 거야.

core 가 먼저 통과하고 나머지를 막아

아빠가 core 호스트, 그러니까 control plane 이랑 늘 켜둔 서버를 손으로 업그레이드하고 직접 통과시켜. 뭐가 움직이기 전에. 일부러야. core 는 대충 넘길 수 없는 canary 고, core 에 안 풀린 이슈가 남아 있으면 backup Mac 으로 자동 rollout 이 안 나가. 제일 잘 알고 제일 잃으면 안 되는 기계에서 업그레이드를 증명하고, 그제서야 퍼뜨려.

reboot 버티는 executor, 저장된 owner credential 은 없이

read-only 자격은 agentless 로 남지만, download, install, reboot, post-boot 작업은 좁고 서명된 launchd-backed executor 가 필요해. job 이 SSH 끊김이랑 심지어 control plane 상실까지 버텨야 하니까. 결정적으로, 그 executor 는 Apple 의 volume-owner 랑 bootstrap-token 규칙을 절대 우회 안 하고, 아빠 credential 을 절대 저장 안 해. reboot 를 건너 이어할 순 있어도, volume 을 소유할 authority 를 만들어낼 순 없어.

예상된 reboot disconnect 는 target 상태

업그레이드 도중 기계가 재부팅하고 연결을 떨궈. 그건 상태 지 failure 가 아냐. plan 이 잘 도는 거야. 성공은 SSH 돌아옴 이 아니라, 정확한 OS 랑 빌드, 끝난 boot, 끝난 GUI Setup Assistant, 건강한 Tailscale 이랑 서비스를 제한적으로 확인하는 거야. download 전략은 따로야. auto_fastest 는 이미 준비된 content cache 가 진짜 시간을 줄일 게 아니면 direct 병렬 download 를 써. cache 를 데우겠다고 절대 순서를 세우지 않아.

빌드를 굳히고, core 를 통과시키고, reboot 너머를 verify 해. fleet 업그레이드가 안전한 건 아무것도 안 틀려서가 아니라, '끝남' 이 verify 된 정확한 빌드를 뜻해서야. 돌아온 연결 하나가 절대 아니라.

Code

업그레이드 campaign, frozen·python

campaign = OSUpgradeCampaign(
    exact_build="25F84",             # 승인 시 FROZEN. 더 새 release 가 못 끼어듦
    core=["control-plane", "always-on-a", "always-on-b"],  # 아빠가 먼저 업그레이드+통과
    rollout=[...],                    # backup Mac. core 통과 뒤에 gate
    download="auto_fastest",          # 준비된 cache 가 더 빠르지 않으면 direct 병렬
    executor="signed launchd job",    # reboot 버팀. volume-owner cred 절대 저장 안 함
)

# core 는 못 가짜 낼 canary. 미해결 core 이슈는 rollout 을 막아.
# 성공 != 'SSH 돌아옴.' 성공 == 정확한 빌드 + boot + GUI setup 완료
#          + 건강한 서비스. 예상된 reboot 뒤 target 별로 verify.

Exercise

네가 아끼는 기계 몇 대의 업그레이드 rollout 을 설계해. 나머지가 움직이기 전에 통과해야 할 'core' canary 를 골라. '끝남'('재부팅됨' 이 아니라)을 뜻하는 정확한 설치 후 체크를 쓰고, rollout 시작할 때 자고 있는 기계엔 어떤 상태를 기록할지 정해.

Hint

'끝남' 체크는 정확한 target 버전이랑, 기계가 실제로 다시 쓸 만하다는 신호 최소 하나(서비스 복귀, desktop 도달)를 짚어야 해. 그냥 ping 에 답한 게 아니라. 자는 기계는 'pending' 이야. 이어할 거지 절대 'failed' 가 아냐.

승인 때 정확한 빌드를 굳혀

core 가 먼저 통과하고 나머지를 막아

reboot 버티는 executor, 저장된 owner credential 은 없이

예상된 reboot disconnect 는 target 상태

Code

External links

Exercise

Progress

댓글 0