Skip to content

Commit 151f6d4

Browse files
committed
Move files
1 parent f88ee50 commit 151f6d4

3 files changed

Lines changed: 329 additions & 0 deletions

File tree

uhyung_upgrading.po

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# SOME DESCRIPTIVE TITLE.
2+
# Copyright (C) 2012-2026, Zuul project contributors
3+
# This file is distributed under the same license as the Zuul package.
4+
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
5+
#
6+
#, fuzzy
7+
msgid ""
8+
msgstr ""
9+
"Project-Id-Version: Zuul latest\n"
10+
"Report-Msgid-Bugs-To: \n"
11+
"POT-Creation-Date: 2026-02-08 13:08+0900\n"
12+
"PO-Revision-Date: 2026-02-08 13:38+0900\n"
13+
"Last-Translator: \n"
14+
"Language-Team: \n"
15+
"Language: ko\n"
16+
"MIME-Version: 1.0\n"
17+
"Content-Type: text/plain; charset=UTF-8\n"
18+
"Content-Transfer-Encoding: 8bit\n"
19+
"X-Generator: Poedit 3.8\n"
20+
21+
#: ../../source/upgrading.rst:2
22+
msgid "Upgrading"
23+
msgstr "업그레이드"
24+
25+
#: ../../source/upgrading.rst:5
26+
msgid "Rolling Upgrades"
27+
msgstr "롤링 업그레이드(무중단 업그레이드)"
28+
29+
#: ../../source/upgrading.rst:7
30+
msgid ""
31+
"If more than one of each Zuul component is present in a system, then Zuul "
32+
"may be upgrading without downtime by performing a rolling upgrade. During a "
33+
"rolling upgrade, components are stopped and started one at a time until all "
34+
"components are upgraded. If there is a behavior change during an upgrade, "
35+
"Zuul will typically wait until all components are upgraded before changing "
36+
"behavior, but in some cases when it is deemed safe, new behaviors may start "
37+
"to appear as soon as the first component is upgraded. Be sure not to begin "
38+
"using or rely on new behaviors until all components are upgraded."
39+
msgstr ""
40+
"만약 시스템에 각 Zuul 컴포넌트가 하나 이상 존재한다면, Zuul은 롤링 업그레이드"
41+
"를 수행함으로써 다운타임(중단 시간) 없이 업그레이드될 수 있습니다. 롤링 업그"
42+
"레이드 동안에는, 모든 컴포넌트가 업그레이드 완료될 때까지 컴포넌트들이 한 번"
43+
"에 하나씩 중지되었다가 다시 시작됩니다. 만약 업그레이드 도중 동작(behavior)"
44+
"의 변경이 있다면, Zuul은 일반적으로 모든 컴포넌트가 업그레이드될 때까지 동작"
45+
"을 변경하는 것을 기다릴 것입니다. 하지만 안전하다고 간주되는 일부 경우에는, "
46+
"첫 번째 컴포넌트가 업그레이드되자마자 새로운 동작들이 나타나기 시작할 수도 있"
47+
"습니다. 모든 컴포넌트가 업그레이드될 때까지는 새로운 동작을 사용하기 시작하거"
48+
"나 그것에 의존하지 않도록 확실히 주의하십시오."
49+
50+
#: ../../source/upgrading.rst:17
51+
msgid ""
52+
"Unless specified in the release notes, there is no specific order for which "
53+
"components should be upgraded first, but the following order is likely to "
54+
"produce the least disruption and delay the use of new behaviors until closer "
55+
"to the end of the process:"
56+
msgstr ""
57+
"릴리스 노트에 명시되지 않는 한, 어떤 컴포넌트들이 먼저 업그레이드되어야 하는"
58+
"지에 대한 구체적인 순서는 없습니다. 그러나 다음의 순서는 혼란(disruption)을 "
59+
"최소화하고, 프로세스가 거의 끝날 때까지 새로운 동작의 사용을 지연시킬 가능성"
60+
"이 높습니다:"
61+
62+
#: ../../source/upgrading.rst:22
63+
msgid ""
64+
"Gracefully restart executors (one at a time, or as many as a system's over-"
65+
"allocation of resources will allow)."
66+
msgstr ""
67+
"익스큐터(Executor)들을 정상적으로(gracefully) 재시작합니다 (한 번에 하나씩, "
68+
"또는 시스템의 자원 초과 할당이 허용하는 만큼)."
69+
70+
#: ../../source/upgrading.rst:24
71+
msgid "Gracefully restart mergers."
72+
msgstr "머저(Merger)들을 정상적으로 재시작합니다."
73+
74+
#: ../../source/upgrading.rst:25
75+
msgid "Restart schedulers."
76+
msgstr "스케줄러(Scheduler)들을 재시작합니다."
77+
78+
#: ../../source/upgrading.rst:26
79+
msgid "Restart web and finger gateways."
80+
msgstr "웹(Web) 및 핑거(Finger) 게이트웨이들을 재시작합니다."
81+
82+
#: ../../source/upgrading.rst:29
83+
msgid "Skipping Versions"
84+
msgstr "버전 건너뛰기"
85+
86+
#: ../../source/upgrading.rst:31
87+
msgid ""
88+
"Zuul versions are specified as `major.minor.micro`. In general, skipping "
89+
"minor or micro versions during upgrades is considered safe. Skipping major "
90+
"versions is not recommended, as backwards compatibility code for older "
91+
"systems may be removed during a major upgrade. This means that, for "
92+
"example, an upgrade from 5.x.y to 7.0.0 should include at least an upgrade "
93+
"to 6.4.0 (the latest 6.x release) before proceeding to 7.0.0."
94+
msgstr ""
95+
"Zuul 버전들은 major.minor.micro(메이저.마이너.마이크로) 형식으로 지정됩니다. "
96+
"일반적으로, 업그레이드 도중 마이너(minor) 또는 마이크로(micro) 버전을 건너뛰"
97+
"는 것은 안전한 것으로 간주됩니다. 메이저(major) 버전을 건너뛰는 것은 권장되"
98+
"지 않습니다. 왜냐하면 오래된 시스템을 위한 하위 호환성 코드가 메이저 업그레이"
99+
"드 도중에 제거될 수 있기 때문입니다. 이것은 예를 들어, 5.x.y 버전에서 7.0.0 "
100+
"버전으로의 업그레이드는 7.0.0으로 진행하기 전에 적어도 6.4.0(가장 최신 6.x 릴"
101+
"리스)으로의 업그레이드를 포함해야 함을 의미합니다."
102+
103+
#: ../../source/upgrading.rst:39
104+
msgid ""
105+
"If skipping major versions is required, then a rolling upgrade is not "
106+
"possible, and Zuul should be completely stopped, and the ``zuul-admin delete-"
107+
"state`` command should be run before restarting on the new version."
108+
msgstr ""
109+
"만약 메이저 버전을 건너뛰는 것이 요구된다면, 롤링 업그레이드는 불가능하며, "
110+
"Zuul은 완전히 중지되어야 하고, 새로운 버전에서 재시작하기 전에 zuul-admin "
111+
"delete-state 명령어가 실행되어야만 합니다."
112+
113+
#: ../../source/upgrading.rst:44
114+
msgid ""
115+
"Some versions may have unique upgrade requirements. See release notes for "
116+
"additional information about specific version upgrades."
117+
msgstr ""
118+
"일부 버전들은 고유한 업그레이드 요구 사항들을 가질 수 있습니다. 특정 버전 업"
119+
"그레이드에 대한 추가 정보는 릴리스 노트를 참조하십시오."

week2/최우형-Week2.rst

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
================================================
2+
Zuul & CI/CD 개념 및 아키텍처 정리
3+
================================================
4+
5+
1. CI/CD란?
6+
===========
7+
단순히 코드를 합치고 배포하는 것이 아니라, 소프트웨어 개발의 전 과정을 **자동화된 컨베이어 벨트** 위에 올리는 것.
8+
9+
* **CI (Continuous Integration):** 합칠 때마다 자동으로 빌드하고 테스트해서 이 코드가 기존 시스템을 망가뜨리지 않는지 즉시 검증함.
10+
* **CD (Continuous Delivery/Deployment):** 이 코드를 실제 사용자 환경이나 테스트 환경으로 자동으로 전송함.
11+
12+
왜 필요한가?
13+
------------
14+
* **사전 차단:** 코드를 올릴 때마다 Zuul이 검사함. 에러가 나면 즉시 반려시켜 작은 에러를 미리 잡아 큰 불을 막음.
15+
* **본질 집중:** CI/CD 파이프라인은 테스트 및 배포 과정을 단축시킴. 개발자는 코드 작성이라는 본질적 가치에 집중할 수 있음.
16+
* **안전 장치:** 파이프라인 상의 테스트가 장애를 감지하고 배포를 중단시킴. 검증되지 않은 코드는 절대 서비스에 나갈 수 없음.
17+
18+
OpenStack 관점에서의 중요성
19+
---------------------------
20+
OpenStack처럼 수십 개의 프로젝트가 서로 얽혀 있는 거대 오픈소스 프로젝트에서는 CI 없이는 개발이 불가능함.
21+
프로젝트 수정 사항이 다른 프로젝트를 깨뜨리는지 확인하기 위해 Zuul 같은 고도화된 CI 시스템이 **모든 연관 관계를 따져서 검증**하는 것임.
22+
23+
2. Jenkins vs Zuul 차이점
24+
=========================
25+
26+
**Jenkins**
27+
* CI 및 자동화 도구
28+
* 주로 **머지 후(Post-merge)** 테스트
29+
* 프로젝트 간 연동이 복잡하고 어려움
30+
* Master-Slave 구조 (병목 발생 가능)
31+
* 기존 서버 재사용 (설정 꼬임 발생 가능)
32+
33+
**Zuul**
34+
* 프로젝트 게이팅(Project Gating) 시스템
35+
* **머지 전(Pre-merge)** 테스트
36+
* Cross-Project Dependency 완벽 지원
37+
* 무상태(Stateless) 아키텍처 (수평 확장 용이)
38+
* Nodepool로 매번 **깨끗한 새 환경** 생성
39+
40+
**결론:** OpenStack 같은 마이크로 서비스 생태계에서는 상호 의존성 검증과 무결성 보장에 특화된 Zuul이 필수임.
41+
42+
3. 오픈소스 발전과 인프라
43+
=======================
44+
OpenStack은 데이터센터의 서버, 스토리지, 네트워크 장비를 소프트웨어로 제어하는 거대한 운영체제(오픈소스 AWS)임.
45+
46+
* **Nova:** 가상머신 생성
47+
* **Neutron:** 가상 네트워크 생성
48+
* **Swift/Cinder:** 데이터 저장
49+
* **Keystone:** 로그인 및 인증 담당
50+
51+
**Nodepool의 역할:**
52+
Nodepool은 작업장(Node)을 생성함. Zuul은 OpenStack의 복잡한 개발을 자동화하기 위해 탄생했으며, Nodepool을 통해 OpenStack의 자원을 할당받아 테스트 환경을 동적으로 구축함.
53+
54+
4. Job 실행의 핵심: Ansible과 Nodepool
55+
======================================
56+
Zuul은 직접 명령어를 실행하지 않음. 실제 실행은 **Ansible**과 **Nodepool**이 담당함.
57+
58+
Ansible
59+
-------
60+
* 서버에 접속해서 명령어를 수행하는 자동화 도구 (Agentless, SSH만 있으면 됨).
61+
* Zuul이 Nodepool에게 받은 서버 정보로 **인벤토리(서버 주소록)**를 작성함.
62+
* ``ansible-playbook`` 명령어로 작성된 YAML을 실행함.
63+
* 따라서 Custom Job을 만들려면 쉘 스크립트가 아니라 Ansible 문법을 배워야 함.
64+
65+
Nodepool & Docker
66+
-----------------
67+
* Nodepool은 자원을 관리함.
68+
* 로컬 환경에서는 무거운 OpenStack VM 대신 **Docker 컨테이너**를 VM인 척 속여서 띄움.
69+
* **흐름:** Zuul 요청 -> Nodepool Launcher -> Docker Daemon -> Container 생성(SSH 키 주입) -> Zuul에게 IP 전달
70+
71+
5. Sample Job의 동작 아키텍처 분석
72+
==================================
73+
74+
1. **이벤트 감지 (Gerrit -> Zuul Scheduler)**
75+
* 코드를 업로드하면 Gerrit이 Zuul에게 새 이벤트 발생 신호를 보냄.
76+
77+
2. **계획 수립 (Zuul Scheduler)**
78+
* YAML 설정을 읽고 어떤 Job을 수행할지 파악함.
79+
80+
3. **자원 할당 (Zuul Scheduler -> Nodepool -> Docker)**
81+
* Zuul이 자원을 요청하면, Nodepool이 Docker에게 명령해 새 컨테이너를 띄우고 정보를 Zuul에게 전달함.
82+
83+
4. **실행 (Zuul Executor -> Ansible -> Test Node)**
84+
* Zuul Executor가 받은 IP로 Ansible Inventory를 만듦.
85+
* ``job.yaml``을 실행함 (Ansible이 SSH로 컨테이너에 접속해 코드 수행).
86+
* 성공/실패 결과를 반환함.
87+
88+
5. **결과 보고 (Zuul Scheduler -> Gerrit)**
89+
* Zuul이 Gerrit에 접속(SSH)하여 해당 Change에 댓글(Verified +1)을 남김.
90+
91+
**요약:** Zuul은 Gerrit(코드), Nodepool(인프라), Ansible(실행) 3박자를 조율하는 엔진임.

week4/uhyung_upgrading.po

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# SOME DESCRIPTIVE TITLE.
2+
# Copyright (C) 2012-2026, Zuul project contributors
3+
# This file is distributed under the same license as the Zuul package.
4+
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
5+
#
6+
#, fuzzy
7+
msgid ""
8+
msgstr ""
9+
"Project-Id-Version: Zuul latest\n"
10+
"Report-Msgid-Bugs-To: \n"
11+
"POT-Creation-Date: 2026-02-08 13:08+0900\n"
12+
"PO-Revision-Date: 2026-02-08 13:38+0900\n"
13+
"Last-Translator: \n"
14+
"Language-Team: \n"
15+
"Language: ko\n"
16+
"MIME-Version: 1.0\n"
17+
"Content-Type: text/plain; charset=UTF-8\n"
18+
"Content-Transfer-Encoding: 8bit\n"
19+
"X-Generator: Poedit 3.8\n"
20+
21+
#: ../../source/upgrading.rst:2
22+
msgid "Upgrading"
23+
msgstr "업그레이드"
24+
25+
#: ../../source/upgrading.rst:5
26+
msgid "Rolling Upgrades"
27+
msgstr "롤링 업그레이드(무중단 업그레이드)"
28+
29+
#: ../../source/upgrading.rst:7
30+
msgid ""
31+
"If more than one of each Zuul component is present in a system, then Zuul "
32+
"may be upgrading without downtime by performing a rolling upgrade. During a "
33+
"rolling upgrade, components are stopped and started one at a time until all "
34+
"components are upgraded. If there is a behavior change during an upgrade, "
35+
"Zuul will typically wait until all components are upgraded before changing "
36+
"behavior, but in some cases when it is deemed safe, new behaviors may start "
37+
"to appear as soon as the first component is upgraded. Be sure not to begin "
38+
"using or rely on new behaviors until all components are upgraded."
39+
msgstr ""
40+
"만약 시스템에 각 Zuul 컴포넌트가 하나 이상 존재한다면, Zuul은 롤링 업그레이드"
41+
"를 수행함으로써 다운타임(중단 시간) 없이 업그레이드될 수 있습니다. 롤링 업그"
42+
"레이드 동안에는, 모든 컴포넌트가 업그레이드 완료될 때까지 컴포넌트들이 한 번"
43+
"에 하나씩 중지되었다가 다시 시작됩니다. 만약 업그레이드 도중 동작(behavior)"
44+
"의 변경이 있다면, Zuul은 일반적으로 모든 컴포넌트가 업그레이드될 때까지 동작"
45+
"을 변경하는 것을 기다릴 것입니다. 하지만 안전하다고 간주되는 일부 경우에는, "
46+
"첫 번째 컴포넌트가 업그레이드되자마자 새로운 동작들이 나타나기 시작할 수도 있"
47+
"습니다. 모든 컴포넌트가 업그레이드될 때까지는 새로운 동작을 사용하기 시작하거"
48+
"나 그것에 의존하지 않도록 확실히 주의하십시오."
49+
50+
#: ../../source/upgrading.rst:17
51+
msgid ""
52+
"Unless specified in the release notes, there is no specific order for which "
53+
"components should be upgraded first, but the following order is likely to "
54+
"produce the least disruption and delay the use of new behaviors until closer "
55+
"to the end of the process:"
56+
msgstr ""
57+
"릴리스 노트에 명시되지 않는 한, 어떤 컴포넌트들이 먼저 업그레이드되어야 하는"
58+
"지에 대한 구체적인 순서는 없습니다. 그러나 다음의 순서는 혼란(disruption)을 "
59+
"최소화하고, 프로세스가 거의 끝날 때까지 새로운 동작의 사용을 지연시킬 가능성"
60+
"이 높습니다:"
61+
62+
#: ../../source/upgrading.rst:22
63+
msgid ""
64+
"Gracefully restart executors (one at a time, or as many as a system's over-"
65+
"allocation of resources will allow)."
66+
msgstr ""
67+
"익스큐터(Executor)들을 정상적으로(gracefully) 재시작합니다 (한 번에 하나씩, "
68+
"또는 시스템의 자원 초과 할당이 허용하는 만큼)."
69+
70+
#: ../../source/upgrading.rst:24
71+
msgid "Gracefully restart mergers."
72+
msgstr "머저(Merger)들을 정상적으로 재시작합니다."
73+
74+
#: ../../source/upgrading.rst:25
75+
msgid "Restart schedulers."
76+
msgstr "스케줄러(Scheduler)들을 재시작합니다."
77+
78+
#: ../../source/upgrading.rst:26
79+
msgid "Restart web and finger gateways."
80+
msgstr "웹(Web) 및 핑거(Finger) 게이트웨이들을 재시작합니다."
81+
82+
#: ../../source/upgrading.rst:29
83+
msgid "Skipping Versions"
84+
msgstr "버전 건너뛰기"
85+
86+
#: ../../source/upgrading.rst:31
87+
msgid ""
88+
"Zuul versions are specified as `major.minor.micro`. In general, skipping "
89+
"minor or micro versions during upgrades is considered safe. Skipping major "
90+
"versions is not recommended, as backwards compatibility code for older "
91+
"systems may be removed during a major upgrade. This means that, for "
92+
"example, an upgrade from 5.x.y to 7.0.0 should include at least an upgrade "
93+
"to 6.4.0 (the latest 6.x release) before proceeding to 7.0.0."
94+
msgstr ""
95+
"Zuul 버전들은 major.minor.micro(메이저.마이너.마이크로) 형식으로 지정됩니다. "
96+
"일반적으로, 업그레이드 도중 마이너(minor) 또는 마이크로(micro) 버전을 건너뛰"
97+
"는 것은 안전한 것으로 간주됩니다. 메이저(major) 버전을 건너뛰는 것은 권장되"
98+
"지 않습니다. 왜냐하면 오래된 시스템을 위한 하위 호환성 코드가 메이저 업그레이"
99+
"드 도중에 제거될 수 있기 때문입니다. 이것은 예를 들어, 5.x.y 버전에서 7.0.0 "
100+
"버전으로의 업그레이드는 7.0.0으로 진행하기 전에 적어도 6.4.0(가장 최신 6.x 릴"
101+
"리스)으로의 업그레이드를 포함해야 함을 의미합니다."
102+
103+
#: ../../source/upgrading.rst:39
104+
msgid ""
105+
"If skipping major versions is required, then a rolling upgrade is not "
106+
"possible, and Zuul should be completely stopped, and the ``zuul-admin delete-"
107+
"state`` command should be run before restarting on the new version."
108+
msgstr ""
109+
"만약 메이저 버전을 건너뛰는 것이 요구된다면, 롤링 업그레이드는 불가능하며, "
110+
"Zuul은 완전히 중지되어야 하고, 새로운 버전에서 재시작하기 전에 zuul-admin "
111+
"delete-state 명령어가 실행되어야만 합니다."
112+
113+
#: ../../source/upgrading.rst:44
114+
msgid ""
115+
"Some versions may have unique upgrade requirements. See release notes for "
116+
"additional information about specific version upgrades."
117+
msgstr ""
118+
"일부 버전들은 고유한 업그레이드 요구 사항들을 가질 수 있습니다. 특정 버전 업"
119+
"그레이드에 대한 추가 정보는 릴리스 노트를 참조하십시오."

0 commit comments

Comments
 (0)