From 32e3754988f5eadb76e6af881f4861677b1a9d4e Mon Sep 17 00:00:00 2001 From: uhyung182 Date: Fri, 30 Jan 2026 11:48:04 +0900 Subject: [PATCH 1/2] =?UTF-8?q?docs:=20Add=20Week2=20summary=20by=20?= =?UTF-8?q?=EC=B5=9C=EC=9A=B0=ED=98=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...265\234\354\232\260\355\230\225-Week2.rst" | 91 +++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 "week2/\354\265\234\354\232\260\355\230\225-Week2.rst" diff --git "a/week2/\354\265\234\354\232\260\355\230\225-Week2.rst" "b/week2/\354\265\234\354\232\260\355\230\225-Week2.rst" new file mode 100644 index 0000000..07c67b4 --- /dev/null +++ "b/week2/\354\265\234\354\232\260\355\230\225-Week2.rst" @@ -0,0 +1,91 @@ +================================================ +Zuul & CI/CD 개념 및 아키텍처 정리 +================================================ + +1. CI/CD란? +=========== +단순히 코드를 합치고 배포하는 것이 아니라, 소프트웨어 개발의 전 과정을 **자동화된 컨베이어 벨트** 위에 올리는 것. + +* **CI (Continuous Integration):** 합칠 때마다 자동으로 빌드하고 테스트해서 이 코드가 기존 시스템을 망가뜨리지 않는지 즉시 검증함. +* **CD (Continuous Delivery/Deployment):** 이 코드를 실제 사용자 환경이나 테스트 환경으로 자동으로 전송함. + +왜 필요한가? +------------ +* **사전 차단:** 코드를 올릴 때마다 Zuul이 검사함. 에러가 나면 즉시 반려시켜 작은 에러를 미리 잡아 큰 불을 막음. +* **본질 집중:** CI/CD 파이프라인은 테스트 및 배포 과정을 단축시킴. 개발자는 코드 작성이라는 본질적 가치에 집중할 수 있음. +* **안전 장치:** 파이프라인 상의 테스트가 장애를 감지하고 배포를 중단시킴. 검증되지 않은 코드는 절대 서비스에 나갈 수 없음. + +OpenStack 관점에서의 중요성 +--------------------------- +OpenStack처럼 수십 개의 프로젝트가 서로 얽혀 있는 거대 오픈소스 프로젝트에서는 CI 없이는 개발이 불가능함. +프로젝트 수정 사항이 다른 프로젝트를 깨뜨리는지 확인하기 위해 Zuul 같은 고도화된 CI 시스템이 **모든 연관 관계를 따져서 검증**하는 것임. + +2. Jenkins vs Zuul 차이점 +========================= + +**Jenkins** + * CI 및 자동화 도구 + * 주로 **머지 후(Post-merge)** 테스트 + * 프로젝트 간 연동이 복잡하고 어려움 + * Master-Slave 구조 (병목 발생 가능) + * 기존 서버 재사용 (설정 꼬임 발생 가능) + +**Zuul** + * 프로젝트 게이팅(Project Gating) 시스템 + * **머지 전(Pre-merge)** 테스트 + * Cross-Project Dependency 완벽 지원 + * 무상태(Stateless) 아키텍처 (수평 확장 용이) + * Nodepool로 매번 **깨끗한 새 환경** 생성 + +**결론:** OpenStack 같은 마이크로 서비스 생태계에서는 상호 의존성 검증과 무결성 보장에 특화된 Zuul이 필수임. + +3. 오픈소스 발전과 인프라 +======================= +OpenStack은 데이터센터의 서버, 스토리지, 네트워크 장비를 소프트웨어로 제어하는 거대한 운영체제(오픈소스 AWS)임. + +* **Nova:** 가상머신 생성 +* **Neutron:** 가상 네트워크 생성 +* **Swift/Cinder:** 데이터 저장 +* **Keystone:** 로그인 및 인증 담당 + +**Nodepool의 역할:** +Nodepool은 작업장(Node)을 생성함. Zuul은 OpenStack의 복잡한 개발을 자동화하기 위해 탄생했으며, Nodepool을 통해 OpenStack의 자원을 할당받아 테스트 환경을 동적으로 구축함. + +4. Job 실행의 핵심: Ansible과 Nodepool +====================================== +Zuul은 직접 명령어를 실행하지 않음. 실제 실행은 **Ansible**과 **Nodepool**이 담당함. + +Ansible +------- +* 서버에 접속해서 명령어를 수행하는 자동화 도구 (Agentless, SSH만 있으면 됨). +* Zuul이 Nodepool에게 받은 서버 정보로 **인벤토리(서버 주소록)**를 작성함. +* ``ansible-playbook`` 명령어로 작성된 YAML을 실행함. +* 따라서 Custom Job을 만들려면 쉘 스크립트가 아니라 Ansible 문법을 배워야 함. + +Nodepool & Docker +----------------- +* Nodepool은 자원을 관리함. +* 로컬 환경에서는 무거운 OpenStack VM 대신 **Docker 컨테이너**를 VM인 척 속여서 띄움. +* **흐름:** Zuul 요청 -> Nodepool Launcher -> Docker Daemon -> Container 생성(SSH 키 주입) -> Zuul에게 IP 전달 + +5. Sample Job의 동작 아키텍처 분석 +================================== + +1. **이벤트 감지 (Gerrit -> Zuul Scheduler)** + * 코드를 업로드하면 Gerrit이 Zuul에게 새 이벤트 발생 신호를 보냄. + +2. **계획 수립 (Zuul Scheduler)** + * YAML 설정을 읽고 어떤 Job을 수행할지 파악함. + +3. **자원 할당 (Zuul Scheduler -> Nodepool -> Docker)** + * Zuul이 자원을 요청하면, Nodepool이 Docker에게 명령해 새 컨테이너를 띄우고 정보를 Zuul에게 전달함. + +4. **실행 (Zuul Executor -> Ansible -> Test Node)** + * Zuul Executor가 받은 IP로 Ansible Inventory를 만듦. + * ``job.yaml``을 실행함 (Ansible이 SSH로 컨테이너에 접속해 코드 수행). + * 성공/실패 결과를 반환함. + +5. **결과 보고 (Zuul Scheduler -> Gerrit)** + * Zuul이 Gerrit에 접속(SSH)하여 해당 Change에 댓글(Verified +1)을 남김. + +**요약:** Zuul은 Gerrit(코드), Nodepool(인프라), Ansible(실행) 3박자를 조율하는 엔진임. From 724b6dcf5f7469164bc5c9d4db4e05e95ff082af Mon Sep 17 00:00:00 2001 From: uhyung182 Date: Sun, 8 Feb 2026 13:42:51 +0900 Subject: [PATCH 2/2] docs: Add Korean translation (upgrading) by uhyung --- uhyung_upgrading.po | 119 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 uhyung_upgrading.po diff --git a/uhyung_upgrading.po b/uhyung_upgrading.po new file mode 100644 index 0000000..4476df8 --- /dev/null +++ b/uhyung_upgrading.po @@ -0,0 +1,119 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2012-2026, Zuul project contributors +# This file is distributed under the same license as the Zuul package. +# FIRST AUTHOR , YEAR. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Zuul latest\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2026-02-08 13:08+0900\n" +"PO-Revision-Date: 2026-02-08 13:38+0900\n" +"Last-Translator: \n" +"Language-Team: \n" +"Language: ko\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Poedit 3.8\n" + +#: ../../source/upgrading.rst:2 +msgid "Upgrading" +msgstr "업그레이드" + +#: ../../source/upgrading.rst:5 +msgid "Rolling Upgrades" +msgstr "롤링 업그레이드(무중단 업그레이드)" + +#: ../../source/upgrading.rst:7 +msgid "" +"If more than one of each Zuul component is present in a system, then Zuul " +"may be upgrading without downtime by performing a rolling upgrade. During a " +"rolling upgrade, components are stopped and started one at a time until all " +"components are upgraded. If there is a behavior change during an upgrade, " +"Zuul will typically wait until all components are upgraded before changing " +"behavior, but in some cases when it is deemed safe, new behaviors may start " +"to appear as soon as the first component is upgraded. Be sure not to begin " +"using or rely on new behaviors until all components are upgraded." +msgstr "" +"만약 시스템에 각 Zuul 컴포넌트가 하나 이상 존재한다면, Zuul은 롤링 업그레이드" +"를 수행함으로써 다운타임(중단 시간) 없이 업그레이드될 수 있습니다. 롤링 업그" +"레이드 동안에는, 모든 컴포넌트가 업그레이드 완료될 때까지 컴포넌트들이 한 번" +"에 하나씩 중지되었다가 다시 시작됩니다. 만약 업그레이드 도중 동작(behavior)" +"의 변경이 있다면, Zuul은 일반적으로 모든 컴포넌트가 업그레이드될 때까지 동작" +"을 변경하는 것을 기다릴 것입니다. 하지만 안전하다고 간주되는 일부 경우에는, " +"첫 번째 컴포넌트가 업그레이드되자마자 새로운 동작들이 나타나기 시작할 수도 있" +"습니다. 모든 컴포넌트가 업그레이드될 때까지는 새로운 동작을 사용하기 시작하거" +"나 그것에 의존하지 않도록 확실히 주의하십시오." + +#: ../../source/upgrading.rst:17 +msgid "" +"Unless specified in the release notes, there is no specific order for which " +"components should be upgraded first, but the following order is likely to " +"produce the least disruption and delay the use of new behaviors until closer " +"to the end of the process:" +msgstr "" +"릴리스 노트에 명시되지 않는 한, 어떤 컴포넌트들이 먼저 업그레이드되어야 하는" +"지에 대한 구체적인 순서는 없습니다. 그러나 다음의 순서는 혼란(disruption)을 " +"최소화하고, 프로세스가 거의 끝날 때까지 새로운 동작의 사용을 지연시킬 가능성" +"이 높습니다:" + +#: ../../source/upgrading.rst:22 +msgid "" +"Gracefully restart executors (one at a time, or as many as a system's over-" +"allocation of resources will allow)." +msgstr "" +"익스큐터(Executor)들을 정상적으로(gracefully) 재시작합니다 (한 번에 하나씩, " +"또는 시스템의 자원 초과 할당이 허용하는 만큼)." + +#: ../../source/upgrading.rst:24 +msgid "Gracefully restart mergers." +msgstr "머저(Merger)들을 정상적으로 재시작합니다." + +#: ../../source/upgrading.rst:25 +msgid "Restart schedulers." +msgstr "스케줄러(Scheduler)들을 재시작합니다." + +#: ../../source/upgrading.rst:26 +msgid "Restart web and finger gateways." +msgstr "웹(Web) 및 핑거(Finger) 게이트웨이들을 재시작합니다." + +#: ../../source/upgrading.rst:29 +msgid "Skipping Versions" +msgstr "버전 건너뛰기" + +#: ../../source/upgrading.rst:31 +msgid "" +"Zuul versions are specified as `major.minor.micro`. In general, skipping " +"minor or micro versions during upgrades is considered safe. Skipping major " +"versions is not recommended, as backwards compatibility code for older " +"systems may be removed during a major upgrade. This means that, for " +"example, an upgrade from 5.x.y to 7.0.0 should include at least an upgrade " +"to 6.4.0 (the latest 6.x release) before proceeding to 7.0.0." +msgstr "" +"Zuul 버전들은 major.minor.micro(메이저.마이너.마이크로) 형식으로 지정됩니다. " +"일반적으로, 업그레이드 도중 마이너(minor) 또는 마이크로(micro) 버전을 건너뛰" +"는 것은 안전한 것으로 간주됩니다. 메이저(major) 버전을 건너뛰는 것은 권장되" +"지 않습니다. 왜냐하면 오래된 시스템을 위한 하위 호환성 코드가 메이저 업그레이" +"드 도중에 제거될 수 있기 때문입니다. 이것은 예를 들어, 5.x.y 버전에서 7.0.0 " +"버전으로의 업그레이드는 7.0.0으로 진행하기 전에 적어도 6.4.0(가장 최신 6.x 릴" +"리스)으로의 업그레이드를 포함해야 함을 의미합니다." + +#: ../../source/upgrading.rst:39 +msgid "" +"If skipping major versions is required, then a rolling upgrade is not " +"possible, and Zuul should be completely stopped, and the ``zuul-admin delete-" +"state`` command should be run before restarting on the new version." +msgstr "" +"만약 메이저 버전을 건너뛰는 것이 요구된다면, 롤링 업그레이드는 불가능하며, " +"Zuul은 완전히 중지되어야 하고, 새로운 버전에서 재시작하기 전에 zuul-admin " +"delete-state 명령어가 실행되어야만 합니다." + +#: ../../source/upgrading.rst:44 +msgid "" +"Some versions may have unique upgrade requirements. See release notes for " +"additional information about specific version upgrades." +msgstr "" +"일부 버전들은 고유한 업그레이드 요구 사항들을 가질 수 있습니다. 특정 버전 업" +"그레이드에 대한 추가 정보는 릴리스 노트를 참조하십시오."