]>
Commit | Line | Data |
---|---|---|
2b371b26 SY |
1 | <!-- |
2 | ||
3 | lxc: linux Container library | |
4 | ||
5 | (C) Copyright IBM Corp. 2007, 2008 | |
6 | ||
7 | Authors: | |
8 | Daniel Lezcano <daniel.lezcano at free.fr> | |
9 | ||
10 | This library is free software; you can redistribute it and/or | |
11 | modify it under the terms of the GNU Lesser General Public | |
12 | License as published by the Free Software Foundation; either | |
13 | version 2.1 of the License, or (at your option) any later version. | |
14 | ||
15 | This library is distributed in the hope that it will be useful, | |
16 | but WITHOUT ANY WARRANTY; without even the implied warranty of | |
17 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | |
18 | Lesser General Public License for more details. | |
19 | ||
20 | You should have received a copy of the GNU Lesser General Public | |
21 | License along with this library; if not, write to the Free Software | |
22 | Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA | |
23 | ||
24 | Translated into Korean | |
25 | by Sungbae Yoo <sungbae.yoo at samsung.com> | |
26 | ||
27 | --> | |
28 | ||
29 | <!DOCTYPE refentry PUBLIC @docdtd@ [ | |
30 | ||
31 | <!ENTITY seealso SYSTEM "@builddir@/see_also.sgml"> | |
32 | ]> | |
33 | ||
34 | <refentry> | |
35 | ||
36 | <docinfo> | |
37 | <date>@LXC_GENERATE_DATE@</date> | |
38 | </docinfo> | |
39 | ||
40 | ||
41 | <refmeta> | |
42 | <refentrytitle>lxc</refentrytitle> | |
43 | <manvolnum>7</manvolnum> | |
44 | <refmiscinfo> | |
45 | Version @PACKAGE_VERSION@ | |
46 | </refmiscinfo> | |
47 | </refmeta> | |
48 | ||
49 | <refnamediv> | |
50 | <refname>lxc</refname> | |
51 | ||
52 | <refpurpose> | |
53 | <!-- | |
54 | linux containers | |
55 | --> | |
56 | Linux 컨테이너 | |
57 | </refpurpose> | |
58 | </refnamediv> | |
59 | ||
60 | <refsect1> | |
61 | <title><!-- Quick start -->빠른 도움말</title> | |
62 | <para> | |
63 | <!-- | |
64 | You are in a hurry, and you don't want to read this man page. Ok, | |
65 | without warranty, here are the commands to launch a shell inside | |
66 | a container with a predefined configuration template, it may | |
67 | work. | |
68 | <command>@BINDIR@/lxc-execute -n foo -f | |
69 | @DOCDIR@/examples/lxc-macvlan.conf /bin/bash</command> | |
70 | --> | |
71 | man 페이지를 읽고 싶지는 않지만 서둘러서 해보고 싶다면, | |
72 | 된다고 보장할 수는 없지만, 미리정의된 설정파일로 컨테이너 내에서 쉘을 실행하는 아래 명령어를 소개하고자 한다. | |
73 | ||
74 | <command>@BINDIR@/lxc-execute -n foo -f | |
75 | @DOCDIR@/examples/lxc-macvlan.conf /bin/bash</command> | |
76 | </para> | |
77 | </refsect1> | |
78 | ||
79 | <refsect1> | |
80 | <title><!-- Overview -->개요</title> | |
81 | <para> | |
82 | <!-- | |
83 | The container technology is actively being pushed into the | |
84 | mainstream linux kernel. It provides the resource management | |
85 | through the control groups aka process containers and resource | |
86 | isolation through the namespaces. | |
87 | --> | |
88 | 컨테이너 기술은 리눅스 커널의 메인스트림에서 활발하게 개발이 진행되고 있다. 컨트롤 그룹(aka. 프로세스 컨테이너)을 통한 자원 관리와 네임스페이슬 통한 자원의 고립 기능을 제공한다. | |
89 | </para> | |
90 | ||
91 | <para> | |
92 | <!-- | |
93 | The linux containers, <command>lxc</command>, aims to use these | |
94 | new functionalities to provide a userspace container object | |
95 | which provides full resource isolation and resource control for | |
96 | an applications or a system. | |
97 | --> | |
98 | linux 컨테이너 (<command>lxc</command>)는 사용자영역 컨테이너 개체를 제공하는 새로운 기능을 사용하는 것을 목표로 하고 있다. 이 새로운 기능은 응용 프로그램이나 시스템에서 모든 자원의 격리와 제어를 제공한다. | |
99 | </para> | |
100 | ||
101 | <para> | |
102 | <!-- | |
103 | The first objective of this project is to make the life easier | |
104 | for the kernel developers involved in the containers project and | |
105 | especially to continue working on the Checkpoint/Restart new | |
106 | features. The <command>lxc</command> is small enough to easily | |
107 | manage a container with simple command lines and complete enough | |
108 | to be used for other purposes. | |
109 | --> | |
110 | 이 프로젝트의 첫번째 목적은 컨테이너 프로젝트에 속해있는 커널 개발자들의 작업을 편하게 하며, 특히 새로운 기능인 Checkpoing/Restart에 대해 계속 작업을 진행해 나가는 것이다. | |
111 | <command>lxc</command>는 작지만, 컨테이너를 간단한 명령어를 통해 쉽게 관리할 수 있고, 다목적으로 사용되기에도 충분하다. | |
112 | </para> | |
113 | </refsect1> | |
114 | ||
115 | <refsect1> | |
116 | <title><!-- Requirements -->요구사항</title> | |
117 | <para> | |
118 | <!-- | |
119 | The <command>lxc</command> relies on a set of functionalities | |
120 | provided by the kernel which needs to be active. Depending of | |
121 | the missing functionalities the <command>lxc</command> will | |
122 | work with a restricted number of functionalities or will simply | |
123 | fail. | |
124 | --> | |
125 | <command>lxc</command>는 커널이 제공하는 몇가지 기능들에 의존적이며, 해당 기능이 활성화되어 있어야 한다. 부족한 기능에 따라, 제한된 기능만이 동작하거나, 아예 동작을 안 할 수 있다. | |
126 | </para> | |
127 | ||
128 | <para> | |
129 | <!-- | |
130 | The following list gives the kernel features to be enabled in | |
131 | the kernel to have the full features container: | |
132 | --> | |
133 | 아래 리스트는 컨테이너의 모든 기능을 사용하기 위해 활성화되어야 하는 커널 기능들이다. | |
134 | </para> | |
135 | <programlisting> | |
136 | * General setup | |
137 | * Control Group support | |
138 | -> Namespace cgroup subsystem | |
139 | -> Freezer cgroup subsystem | |
140 | -> Cpuset support | |
141 | -> Simple CPU accounting cgroup subsystem | |
142 | -> Resource counters | |
143 | -> Memory resource controllers for Control Groups | |
144 | * Group CPU scheduler | |
145 | -> Basis for grouping tasks (Control Groups) | |
146 | * Namespaces support | |
147 | -> UTS namespace | |
148 | -> IPC namespace | |
149 | -> User namespace | |
150 | -> Pid namespace | |
151 | -> Network namespace | |
152 | * Device Drivers | |
153 | * Character devices | |
154 | -> Support multiple instances of devpts | |
155 | * Network device support | |
156 | -> MAC-VLAN support | |
157 | -> Virtual ethernet pair device | |
158 | * Networking | |
159 | * Networking options | |
160 | -> 802.1d Ethernet Bridging | |
161 | * Security options | |
162 | -> File POSIX Capabilities | |
163 | </programlisting> | |
164 | ||
165 | <para> | |
166 | <!-- | |
167 | The kernel version >= 2.6.32 shipped with the distros, will | |
168 | work with <command>lxc</command>, this one will have less | |
169 | functionalities but enough to be interesting. | |
170 | ||
171 | The helper script <command>lxc-checkconfig</command> will give | |
172 | you information about your kernel configuration. | |
173 | --> | |
174 | 배포판들에 포함된 2.6.32 이상의 커널에서는 <command>lxc</command>가 동작한다. 매우 작은 기능만 있지만 충분히 사용할 수 있다. | |
175 | <command>lxc-checkconfig</command> 스크립트를 사용하면 현재 커널 설정에 대한 정보를 얻을 수 있다. | |
176 | </para> | |
177 | ||
178 | <para> | |
179 | <!-- | |
180 | The control group can be mounted anywhere, eg: | |
181 | <command>mount -t cgroup cgroup /cgroup</command>. | |
182 | ||
183 | It is however recommended to use cgmanager, cgroup-lite or systemd | |
184 | to mount the cgroup hierarchy under /sys/fs/cgroup. | |
185 | --> | |
186 | 컨트롤 그룹은 어디에든지 마운트될 수 있다. 예를 들어 | |
187 | <command>mount -t cgroup cgroup /cgroup</command>도 가능하다. | |
188 | ||
189 | 그러나 cgmanager, cgroup-lite 또는 systemd를 사용하여, /sys/fs/cgroup에 cgroup 계층구조를 마운트하는 것이 좋다. | |
190 | </para> | |
191 | ||
192 | </refsect1> | |
193 | ||
194 | <refsect1> | |
195 | <title><!-- Functional specification -->기능 사양</title> | |
196 | <para> | |
197 | <!-- | |
198 | A container is an object isolating some resources of the host, | |
199 | for the application or system running in it. | |
200 | --> | |
201 | 컨테이너는 응용프로그램이나 시스템을 내부에서 실행시키기 위해, 호스트의 몇몇 자원들을 격리시키는 객체이다. | |
202 | </para> | |
203 | <para> | |
204 | <!-- | |
205 | The application / system will be launched inside a | |
206 | container specified by a configuration that is either | |
207 | initially created or passed as parameter of the starting | |
208 | commands. | |
209 | --> | |
210 | 어플리케이션/시스템은 처음 생성될때 또는 시작 명령어의 인자로 넘겨주었던 설정을 기반으로 한 컨테이너 안에서 실행된다. | |
211 | </para> | |
212 | ||
213 | <para> | |
214 | <!-- | |
215 | How to run an application in a container ? | |
216 | --> | |
217 | 어떻게 컨테이너 내부에서 응용 프로그램을 실행하는가? | |
218 | </para> | |
219 | <para> | |
220 | <!-- | |
221 | Before running an application, you should know what are the | |
222 | resources you want to isolate. The default configuration is to | |
223 | isolate the pids, the sysv ipc and the mount points. If you want | |
224 | to run a simple shell inside a container, a basic configuration | |
225 | is needed, especially if you want to share the rootfs. If you | |
226 | want to run an application like <command>sshd</command>, you | |
227 | should provide a new network stack and a new hostname. If you | |
228 | want to avoid conflicts with some files | |
229 | eg. <filename>/var/run/httpd.pid</filename>, you should | |
230 | remount <filename>/var/run</filename> with an empty | |
231 | directory. If you want to avoid the conflicts in all the cases, | |
232 | you can specify a rootfs for the container. The rootfs can be a | |
233 | directory tree, previously bind mounted with the initial rootfs, | |
234 | so you can still use your distro but with your | |
235 | own <filename>/etc</filename> and <filename>/home</filename> | |
236 | --> | |
237 | 어플리케이션을 실행하기에 앞서, 고립시키고 싶은 자원을 먼저 알아야 한다. 기본 설정은 pid와 sysv ipc 그리고 마운트 포인트들을 고립시킨다. | |
238 | 만약에 간단한 쉘을 컨테이너 내부에서 실행시키기 원한다면, 특히 rootfs를 공유하고 싶다면 매우 기초적인 설정이 요구된다. | |
239 | <command>sshd</command> 같은 응용 프로그램을 실행시키고 싶다면, 새로운 네트워크 스택과 호스트네임을 제공해 주어야 한다. | |
240 | 만약 몇몇 파일들, 예를 들어, <filename>/var/run/httpd.pid</filename>이 충돌나는것을 막고 싶다면, <filename>/var/run</filename>를 빈 디렉토리로 다시 마운트하는 것이 필요하다. | |
241 | 모든 경우의 파일 충돌을 피하고 싶다면, 컨테이너를 위한 루트 파일시스템를 따로 지정해 줄 수도 있다. 루트 파일시스템은 미리 원래의 루트 파일시스템을 바인드 마운트한 디렉토리가 될 수도 있다. 이렇게 되면 자신만의 <filename>/etc</filename>, <filename>/home</filename>을 사용하면서도 배포판을 그대로 사용할 수 있다. | |
242 | </para> | |
243 | <para> | |
244 | <!-- | |
245 | Here is an example of directory tree | |
246 | for <command>sshd</command>: | |
247 | <programlisting> | |
248 | [root@lxc sshd]$ tree -d rootfs | |
249 | ||
250 | rootfs | |
251 | |-- bin | |
252 | |-- dev | |
253 | | |-- pts | |
254 | | `-- shm | |
255 | | `-- network | |
256 | |-- etc | |
257 | | `-- ssh | |
258 | |-- lib | |
259 | |-- proc | |
260 | |-- root | |
261 | |-- sbin | |
262 | |-- sys | |
263 | |-- usr | |
264 | `-- var | |
265 | |-- empty | |
266 | | `-- sshd | |
267 | |-- lib | |
268 | | `-- empty | |
269 | | `-- sshd | |
270 | `-- run | |
271 | `-- sshd | |
272 | </programlisting> | |
273 | ||
274 | and the mount points file associated with it: | |
275 | <programlisting> | |
276 | [root@lxc sshd]$ cat fstab | |
277 | ||
278 | /lib /home/root/sshd/rootfs/lib none ro,bind 0 0 | |
279 | /bin /home/root/sshd/rootfs/bin none ro,bind 0 0 | |
280 | /usr /home/root/sshd/rootfs/usr none ro,bind 0 0 | |
281 | /sbin /home/root/sshd/rootfs/sbin none ro,bind 0 0 | |
282 | </programlisting> | |
283 | --> | |
284 | 아래는 <command>sshd</command>를 사용하기 위한 디렉토리 트리 예제이다. | |
285 | <programlisting> | |
286 | [root@lxc sshd]$ tree -d rootfs | |
287 | ||
288 | rootfs | |
289 | |-- bin | |
290 | |-- dev | |
291 | | |-- pts | |
292 | | `-- shm | |
293 | | `-- network | |
294 | |-- etc | |
295 | | `-- ssh | |
296 | |-- lib | |
297 | |-- proc | |
298 | |-- root | |
299 | |-- sbin | |
300 | |-- sys | |
301 | |-- usr | |
302 | `-- var | |
303 | |-- empty | |
304 | | `-- sshd | |
305 | |-- lib | |
306 | | `-- empty | |
307 | | `-- sshd | |
308 | `-- run | |
309 | `-- sshd | |
310 | </programlisting> | |
311 | ||
312 | 그리고, 해당 마운트 포인트 파일의 내용은 아래와 같다. | |
313 | <programlisting> | |
314 | [root@lxc sshd]$ cat fstab | |
315 | ||
316 | /lib /home/root/sshd/rootfs/lib none ro,bind 0 0 | |
317 | /bin /home/root/sshd/rootfs/bin none ro,bind 0 0 | |
318 | /usr /home/root/sshd/rootfs/usr none ro,bind 0 0 | |
319 | /sbin /home/root/sshd/rootfs/sbin none ro,bind 0 0 | |
320 | </programlisting> | |
321 | </para> | |
322 | ||
323 | <para> | |
324 | <!-- | |
325 | How to run a system in a container ? | |
326 | --> | |
327 | 어떻게 컨테이너 내에서 시스템을 실행하는가? | |
328 | </para> | |
329 | ||
330 | <para> | |
331 | <!-- | |
332 | Running a system inside a container is paradoxically easier | |
333 | than running an application. Why ? Because you don't have to care | |
334 | about the resources to be isolated, everything need to be | |
335 | isolated, the other resources are specified as being isolated but | |
336 | without configuration because the container will set them | |
337 | up. eg. the ipv4 address will be setup by the system container | |
338 | init scripts. Here is an example of the mount points file: | |
339 | ||
340 | <programlisting> | |
341 | [root@lxc debian]$ cat fstab | |
342 | ||
343 | /dev /home/root/debian/rootfs/dev none bind 0 0 | |
344 | /dev/pts /home/root/debian/rootfs/dev/pts none bind 0 0 | |
345 | </programlisting> | |
346 | ||
347 | More information can be added to the container to facilitate the | |
348 | configuration. For example, make accessible from the container | |
349 | the resolv.conf file belonging to the host. | |
350 | ||
351 | <programlisting> | |
352 | /etc/resolv.conf /home/root/debian/rootfs/etc/resolv.conf none bind 0 0 | |
353 | </programlisting> | |
354 | --> | |
355 | 컨테이너 내에서 시스템을 실행하는 것은 역설적으로 어플리케이션을 실행하는 것보다 쉽다. 왜 그럴까? 왜냐하면, 어떤 자원이 고립되어야 하는지 고려할 필요가 없다. 모든 자원이 고립되면 된다. 자원들은 별다른 설정없이 고립된다고 지정만 해도 된다. 왜냐하면 컨테이너가 그 자원들을 세팅할 것이기 때문이다. 예를 들어 ipv4 주소는 시스템 컨테이너의 init 스크립트들을 통해 세팅된다. 아래는 마운트 포인트 파일의 예제이다. | |
356 | ||
357 | <programlisting> | |
358 | [root@lxc debian]$ cat fstab | |
359 | ||
360 | /dev /home/root/debian/rootfs/dev none bind 0 0 | |
361 | /dev/pts /home/root/debian/rootfs/dev/pts none bind 0 0 | |
362 | </programlisting> | |
363 | ||
364 | 설정을 돕기 위해서 컨테이너에 부가 정보를 추가할 수 있다. 아래와 같이 호스트에 있는 resolv.conf를 컨테이너 안에서 접근할 수 있다. | |
365 | ||
366 | <programlisting> | |
367 | /etc/resolv.conf /home/root/debian/rootfs/etc/resolv.conf none bind 0 0 | |
368 | </programlisting> | |
369 | </para> | |
370 | ||
371 | <refsect2> | |
372 | <title><!-- Container life cycle -->컨테이너의 생명주기</title> | |
373 | <para> | |
374 | <!-- | |
375 | When the container is created, it contains the configuration | |
376 | information. When a process is launched, the container will be | |
377 | starting and running. When the last process running inside the | |
378 | container exits, the container is stopped. | |
379 | --> | |
380 | 컨테이너가 생성될때, 컨테이너는 설정정보를 포함하게 된다. | |
381 | 프로세스가 실행될때, 컨테이너는 시작되고 실행된다. | |
382 | 컨테이너 내에서 실행되던 마지막 프로세스가 종료되면, 컨테이너는 종료된다. | |
383 | </para> | |
384 | <para> | |
385 | <!-- | |
386 | In case of failure when the container is initialized, it will | |
387 | pass through the aborting state. | |
388 | --> | |
389 | 컨테이너의 초기화가 실패했을 경우, (아래 그림처럼)중단 상태로 바뀌게 된다. | |
390 | </para> | |
391 | ||
392 | <programlisting> | |
393 | <![CDATA[ | |
394 | --------- | |
395 | | STOPPED |<--------------- | |
396 | --------- | | |
397 | | | | |
398 | start | | |
399 | | | | |
400 | V | | |
401 | ---------- | | |
402 | | STARTING |--error- | | |
403 | ---------- | | | |
404 | | | | | |
405 | V V | | |
406 | --------- ---------- | | |
407 | | RUNNING | | ABORTING | | | |
408 | --------- ---------- | | |
409 | | | | | |
410 | no process | | | |
411 | | | | | |
412 | V | | | |
413 | ---------- | | | |
414 | | STOPPING |<------- | | |
415 | ---------- | | |
416 | | | | |
417 | --------------------- | |
418 | ]]> | |
419 | </programlisting> | |
420 | </refsect2> | |
421 | ||
422 | <refsect2> | |
423 | <title><!-- Configuration -->설정</title> | |
424 | <para> | |
425 | <!-- | |
426 | The container is configured through a configuration | |
427 | file, the format of the configuration file is described in | |
428 | <citerefentry> | |
429 | <refentrytitle><filename>lxc.conf</filename></refentrytitle> | |
430 | <manvolnum>5</manvolnum> | |
431 | </citerefentry> | |
432 | --> | |
433 | </para> | |
434 | 컨테이너는 설정파일에 의해서 설정된다. 설정파일의 형식은 다음을 참조하면 된다. | |
435 | <citerefentry> | |
436 | <refentrytitle><filename>lxc.conf</filename></refentrytitle> | |
437 | <manvolnum>5</manvolnum> | |
438 | </citerefentry> | |
439 | </refsect2> | |
440 | ||
441 | <refsect2> | |
442 | <title><!--Creating / Destroying container | |
443 | (persistent container) -->컨테이너의 생성/제거 (지속 컨테이너)</title> | |
444 | <para> | |
445 | <!-- | |
446 | A persistent container object can be | |
447 | created via the <command>lxc-create</command> | |
448 | command. It takes a container name as parameter and | |
449 | optional configuration file and template. | |
450 | The name is used by the different | |
451 | commands to refer to this | |
452 | container. The <command>lxc-destroy</command> command will | |
453 | destroy the container object. | |
454 | <programlisting> | |
455 | lxc-create -n foo | |
456 | lxc-destroy -n foo | |
457 | </programlisting> | |
458 | --> | |
459 | 지속성 컨테이너 객체는 <command>lxc-create</command> 명령어로 생성된다. 컨테이너이름을 인수로 받으며, 부가적인 설정파일과 템플릿을 지정한다. | |
460 | 여기서 지정하는 이름은 다른 명령어들을 사용할 때 해당 컨테이너를 참조하기 위해 사용된다. <command>lxc-destroy</command> 명령어는 컨테이너 객체를 제거한다. | |
461 | <programlisting> | |
462 | lxc-create -n foo | |
463 | lxc-destroy -n foo | |
464 | </programlisting> | |
465 | </para> | |
466 | </refsect2> | |
467 | ||
468 | <refsect2> | |
469 | <title><!-- Volatile container -->휘발성 컨테이너</title> | |
470 | <para> | |
471 | <!-- | |
472 | It is not mandatory to create a container object | |
473 | before to start it. | |
474 | The container can be directly started with a | |
475 | configuration file as parameter. | |
476 | --> | |
477 | 컨테이너 시작전에 컨테이너 오브젝트를 생성하는 것이 의무는 아니다. | |
478 | 컨테이너는 설정파일을 파라미터로 넣어서 바로 시작할 수도 있다. | |
479 | </para> | |
480 | </refsect2> | |
481 | ||
482 | <refsect2> | |
483 | <title><!-- Starting / Stopping container -->컨테이너의 시작과 종료</title> | |
484 | <para> | |
485 | <!-- | |
486 | When the container has been created, it is ready to run an | |
487 | application / system. | |
488 | This is the purpose of the <command>lxc-execute</command> and | |
489 | <command>lxc-start</command> commands. | |
490 | If the container was not created before | |
491 | starting the application, the container will use the | |
492 | configuration file passed as parameter to the command, | |
493 | and if there is no such parameter either, then | |
494 | it will use a default isolation. | |
495 | If the application is ended, the container will be stopped also, | |
496 | but if needed the <command>lxc-stop</command> command can | |
497 | be used to kill the still running application. | |
498 | --> | |
499 | 컨테이너가 생성하면 응용 프로그램/시스템이 실행될 준비를 마친 것이다. | |
500 | 실행하는 것이 바로 <command>lxc-execute</command>와 <command>lxc-start</command> 명령어의 목적이다. | |
501 | 응용프로그램 시작전에 컨테이너가 생성되어 있지 않다면, 컨테이너는 명령어의 인수로 넘겼던 설정파일을 사용한다. 그런 인수마저 없다면, 기본 고립 환경을 사용한다. | |
502 | 만약 응용프로그램이 종료되면, 컨테이너도 역시 종료된다. 실행중인 응용프로그램을 종료시키고 싶다면 <command>lxc-stop</command>를 사용하면 된다. | |
503 | </para> | |
504 | ||
505 | <para> | |
506 | <!-- | |
507 | Running an application inside a container is not exactly the | |
508 | same thing as running a system. For this reason, there are two | |
509 | different commands to run an application into a container: | |
510 | <programlisting> | |
511 | lxc-execute -n foo [-f config] /bin/bash | |
512 | lxc-start -n foo [-f config] [/bin/bash] | |
513 | </programlisting> | |
514 | --> | |
515 | 컨테이너 내부에서 응용프로그램을 실행하는 것은 시스템을 실행하는 것과는 차이가 있다. 이런 이유로 아래의 두가지 명령어가 사용된다. | |
516 | <programlisting> | |
517 | lxc-execute -n foo [-f config] /bin/bash | |
518 | lxc-start -n foo [-f config] [/bin/bash] | |
519 | </programlisting> | |
520 | </para> | |
521 | ||
522 | <para> | |
523 | <!-- | |
524 | <command>lxc-execute</command> command will run the | |
525 | specified command into the container via an intermediate | |
526 | process, <command>lxc-init</command>. | |
527 | This lxc-init after launching the specified command, | |
528 | will wait for its end and all other reparented processes. | |
529 | (to support daemons in the container). | |
530 | In other words, in the | |
531 | container, <command>lxc-init</command> has the pid 1 and the | |
532 | first process of the application has the pid 2. | |
533 | --> | |
534 | <command>lxc-execute</command> 명령어는 컨테이너 내부에서 <command>lxc-init</command> 프로세스를 통해 실행할 명령어를 지정할 수 있다. | |
535 | lxc-init는 지정한 명령어를 실행한 후, 그 명령어로 실행된 모든 프로세스들이 종료되기를 기다린다. (컨테이너 내부에서 데몬을 지원하기 위해서이다) | |
536 | 다시 말해서, 컨테이너 내부에서 <command>lxc-init</command>는 1번 pid를 갖고, 응용프로그램의 첫번째 프로세스는 2번 pid를 가진다. | |
537 | </para> | |
538 | ||
539 | <para> | |
540 | <!-- | |
541 | <command>lxc-start</command> command will run directly the specified | |
542 | command into the container. | |
543 | The pid of the first process is 1. If no command is | |
544 | specified <command>lxc-start</command> will | |
545 | run the command defined in lxc.init_cmd or if not set, | |
546 | <filename>/sbin/init</filename> . | |
547 | --> | |
548 | <command>lxc-start</command> 명령어는 지정한 명령어를 컨테이너 내에서 직접 실행한다. 첫 프로세스의 pid는 1번이다. 만약 어떤 명령어도 지정되지 않으면, lxc.init_cmd에 지정된 명령어를 실행한다. 이마저도 지정되있지 않으면, <filename>/sbin/init</filename>를 실행한다. | |
549 | </para> | |
550 | ||
551 | <para> | |
552 | <!-- | |
553 | To summarize, <command>lxc-execute</command> is for running | |
554 | an application and <command>lxc-start</command> is better suited for | |
555 | running a system. | |
556 | --> | |
557 | 요약하자면, <command>lxc-execute</command>는 응용 프로그램 실행을 위해서, <command>lxc-start</command>는 시스템 실행을 위해 적합하다. | |
558 | </para> | |
559 | ||
560 | <para> | |
561 | <!-- | |
562 | If the application is no longer responding, is inaccessible or is | |
563 | not able to finish by itself, a | |
564 | wild <command>lxc-stop</command> command will kill all the | |
565 | processes in the container without pity. | |
566 | <programlisting> | |
567 | lxc-stop -n foo | |
568 | </programlisting> | |
569 | --> | |
570 | 만약 어플리케이션이 더이상 응답하지 않거나, 접근이 불가능하거나, 스스로 종료되지 못할 경우, <command>lxc-stop</command> 명령어는 컨테이너 내의 모든 프로세스들을 가차없이 종료시킬 것이다. | |
571 | <programlisting> | |
572 | lxc-stop -n foo | |
573 | </programlisting> | |
574 | </para> | |
575 | </refsect2> | |
576 | ||
577 | <refsect2> | |
578 | <title><!-- Connect to an available tty -->사용가능한 tty 접속</title> | |
579 | <para> | |
580 | <!-- | |
581 | If the container is configured with the ttys, it is possible | |
582 | to access it through them. It is up to the container to | |
583 | provide a set of available tty to be used by the following | |
584 | command. When the tty is lost, it is possible to reconnect it | |
585 | without login again. | |
586 | <programlisting> | |
587 | lxc-console -n foo -t 3 | |
588 | </programlisting> | |
589 | --> | |
590 | 컨테이너에 tty가 설정되어 있다면, tty를 통해 컨테이너에 접근할 수 있다. | |
591 | 아래 명령어를 통해 사용될 가능한 tty를 제공하는 것은 컨테이너에 달려있다. | |
592 | tty가 종료되었을 때는 다시 로그인하지 않고도 재접속할 수 있다. | |
593 | <programlisting> | |
594 | lxc-console -n foo -t 3 | |
595 | </programlisting> | |
596 | </para> | |
597 | </refsect2> | |
598 | ||
599 | <refsect2> | |
600 | <title><!-- Freeze / Unfreeze container -->컨테이너 동결/동결 해제</title> | |
601 | <para> | |
602 | <!-- | |
603 | Sometime, it is useful to stop all the processes belonging to | |
604 | a container, eg. for job scheduling. The commands: | |
605 | <programlisting> | |
606 | lxc-freeze -n foo | |
607 | </programlisting> | |
608 | ||
609 | will put all the processes in an uninteruptible state and | |
610 | ||
611 | <programlisting> | |
612 | lxc-unfreeze -n foo | |
613 | </programlisting> | |
614 | ||
615 | will resume them. | |
616 | --> | |
617 | 스케줄링 등을 위해 컨테이너에 속해있는 모든 프로세스를 정지 시키는 것은 때로 유용할 수 있다. 아래 명령어들을 사용하면 된다. | |
618 | ||
619 | <programlisting> | |
620 | lxc-freeze -n foo | |
621 | </programlisting> | |
622 | 는 모든 프로세스들을 인터럽트 불가능한 상태로 만든다. | |
623 | ||
624 | <programlisting> | |
625 | lxc-unfreeze -n foo | |
626 | </programlisting> | |
627 | 는 모든 프로세스를 정지 해제 시킨다. | |
628 | </para> | |
629 | ||
630 | <para> | |
631 | <!-- | |
632 | This feature is enabled if the cgroup freezer is enabled in the | |
633 | kernel. | |
634 | --> | |
635 | 이 기능은 커널에서 cgroup freezer 기능이 활성화 되어 있어야 사용 가능하다. | |
636 | </para> | |
637 | </refsect2> | |
638 | ||
639 | <refsect2> | |
640 | <title><!-- Getting information about container --> | |
641 | 컨테이너 관련 정보 얻어오기</title> | |
642 | <para> | |
643 | <!-- | |
644 | When there are a lot of containers, it is hard to follow | |
645 | what has been created or destroyed, what is running or what are | |
646 | the pids running into a specific container. For this reason, the | |
647 | following commands may be useful: | |
648 | <programlisting> | |
649 | lxc-ls | |
650 | lxc-info -n foo | |
651 | </programlisting> | |
652 | --> | |
4ff8fb6c | 653 | 컨테이너가 많이 존재하는 경우, 어떤 것이 생성되고 제거됬는지, 어떤 것이 실행 중인지 또는 어떤 프로세스들이 특정 컨테이너 내에서 실행되는지를 따라가기 힘들다. 이를 위해 다음과 같은 명령어들이 유용하게 사용될 수 있다. |
2b371b26 SY |
654 | <programlisting> |
655 | lxc-ls | |
656 | lxc-info -n foo | |
657 | </programlisting> | |
658 | </para> | |
659 | <para> | |
660 | <!-- | |
661 | <command>lxc-ls</command> lists the containers of the | |
662 | system. | |
663 | --> | |
664 | <command>lxc-ls</command>는 시스템의 컨테이너들의 리스트를 표시한다. | |
665 | </para> | |
666 | ||
667 | <para> | |
668 | <!-- | |
669 | <command>lxc-info</command> gives information for a specific | |
670 | container. | |
671 | --> | |
672 | <command>lxc-info</command>는 지정한 컨테이너의 정보를 얻어온다. | |
673 | </para> | |
674 | ||
675 | <para> | |
676 | <!-- | |
677 | Here is an example on how the combination of these commands | |
0fe2983a | 678 | allows one to list all the containers and retrieve their state. |
2b371b26 SY |
679 | <programlisting> |
680 | for i in $(lxc-ls -1); do | |
681 | lxc-info -n $i | |
682 | done | |
683 | </programlisting> | |
684 | --> | |
685 | 아래는 명령어들을 조합하여 컨테이너들의 리스트를 얻어오고 상태를 출력하는 예제이다. | |
686 | <programlisting> | |
687 | for i in $(lxc-ls -1); do | |
688 | lxc-info -n $i | |
689 | done | |
690 | </programlisting> | |
691 | </para> | |
692 | ||
693 | </refsect2> | |
694 | ||
695 | <refsect2> | |
696 | <title><!-- Monitoring container -->컨테이너 모니터링</title> | |
697 | <para> | |
698 | <!-- | |
699 | It is sometime useful to track the states of a container, | |
700 | for example to monitor it or just to wait for a specific | |
701 | state in a script. | |
702 | --> | |
703 | 컨테이너의 상태를 추적하는 것은 때때로 매우 유용하다. | |
704 | 예를 들어, 상태를 모니터링하거나, 스크립트에서 특정상태를 기다리는 경우이다. | |
705 | </para> | |
706 | ||
707 | <para> | |
708 | <!-- | |
709 | <command>lxc-monitor</command> command will monitor one or | |
710 | several containers. The parameter of this command accept a | |
711 | regular expression for example: | |
712 | <programlisting> | |
713 | lxc-monitor -n "foo|bar" | |
714 | </programlisting> | |
715 | will monitor the states of containers named 'foo' and 'bar', and: | |
716 | <programlisting> | |
717 | lxc-monitor -n ".*" | |
718 | </programlisting> | |
719 | will monitor all the containers. | |
720 | --> | |
721 | <command>lxc-monitor</command> 명령어는 하나 또는 여러개의 컨테이너들을 모니터링한다. 이 명령어의 인수로 정규표현식을 넘길 수도 있다. | |
722 | 예를 들면, | |
723 | <programlisting> | |
724 | lxc-monitor -n "foo|bar" | |
725 | </programlisting> | |
726 | 는 'foo'와 'bar'라는 이름의 컨테이너의 상태 변화를 모니터링한다. 그리고, | |
727 | <programlisting> | |
728 | lxc-monitor -n ".*" | |
729 | </programlisting> | |
730 | 는 모든 컨테이너를 모니터링한다. | |
731 | </para> | |
732 | <para> | |
733 | <!-- | |
734 | For a container 'foo' starting, doing some work and exiting, | |
735 | the output will be in the form: | |
736 | <programlisting> | |
737 | 'foo' changed state to [STARTING] | |
738 | 'foo' changed state to [RUNNING] | |
739 | 'foo' changed state to [STOPPING] | |
740 | 'foo' changed state to [STOPPED] | |
741 | </programlisting> | |
742 | --> | |
743 | 'foo' 컨테이너가 시작되고 몇 가지 작업을 수행하고 종료된 경우, | |
744 | 출력은 다음과 같다. | |
745 | <programlisting> | |
746 | 'foo' changed state to [STARTING] | |
747 | 'foo' changed state to [RUNNING] | |
748 | 'foo' changed state to [STOPPING] | |
749 | 'foo' changed state to [STOPPED] | |
750 | </programlisting> | |
751 | </para> | |
752 | <para> | |
753 | <!-- | |
754 | <command>lxc-wait</command> command will wait for a specific | |
755 | state change and exit. This is useful for scripting to | |
756 | synchronize the launch of a container or the end. The | |
757 | parameter is an ORed combination of different states. The | |
758 | following example shows how to wait for a container if he went | |
759 | to the background. | |
760 | ||
761 | <programlisting> | |
762 | <![CDATA[ | |
763 | # launch lxc-wait in background | |
764 | lxc-wait -n foo -s STOPPED & | |
765 | LXC_WAIT_PID=$! | |
766 | ||
767 | # this command goes in background | |
768 | lxc-execute -n foo mydaemon & | |
769 | ||
770 | # block until the lxc-wait exits | |
771 | # and lxc-wait exits when the container | |
772 | # is STOPPED | |
773 | wait $LXC_WAIT_PID | |
774 | echo "'foo' is finished" | |
775 | ]]> | |
776 | </programlisting> | |
777 | --> | |
778 | <command>lxc-wait</command> 명령어는 지정한 상태로 변화되는 것을 기다린다. 이 명령어는 컨테이너의 시작이나 종료와 동기화되는 스크립트를 작성할 때 유용하다. | |
779 | 인수는 다른 상태들을 OR로 묶어서 지정해 줄 수 있다. 아래 예제는 백그라운드에서 어떻게 컨테이너의 상태 변화를 기다리는지 보여준다. | |
780 | <programlisting> | |
781 | <![CDATA[ | |
782 | # launch lxc-wait in background | |
783 | lxc-wait -n foo -s STOPPED & | |
784 | LXC_WAIT_PID=$! | |
785 | ||
786 | # this command goes in background | |
787 | lxc-execute -n foo mydaemon & | |
788 | ||
789 | # block until the lxc-wait exits | |
790 | # and lxc-wait exits when the container | |
791 | # is STOPPED | |
792 | wait $LXC_WAIT_PID | |
793 | echo "'foo' is finished" | |
794 | ]]> | |
795 | </programlisting> | |
796 | </para> | |
797 | </refsect2> | |
798 | ||
799 | <refsect2> | |
800 | <title><!-- Setting the control group for container --> | |
801 | 컨테이너 컨트롤 그룹 설정 | |
802 | </title> | |
803 | <para> | |
804 | <!-- | |
805 | The container is tied with the control groups, when a | |
806 | container is started a control group is created and associated | |
807 | with it. The control group properties can be read and modified | |
808 | when the container is running by using the lxc-cgroup command. | |
809 | --> | |
810 | 컨테이너는 컨트롤 그룹과 결합되어 있다. | |
811 | 컨테이너가 시작되면 컨트롤그룹이 만들어지고 해당 컨트롤 그룹과 연결된다. | |
812 | 컨테이너가 실행중일 때, lxc-cgroup 명령어를 이용해 컨트롤 그룹 속성은 읽거나 수정될 수 있다. | |
813 | </para> | |
814 | <para> | |
815 | <!-- | |
816 | <command>lxc-cgroup</command> command is used to set or get a | |
817 | control group subsystem which is associated with a | |
818 | container. The subsystem name is handled by the user, the | |
819 | command won't do any syntax checking on the subsystem name, if | |
820 | the subsystem name does not exists, the command will fail. | |
821 | --> | |
822 | <command>lxc-cgroup</command> 명령어는 컨테이너와 연결된 컨트롤 그룹 서브시스템의 값을 얻어오거나 설정한다. | |
823 | 서브시스템의 이름은 사용자가 결정하며, 이 명령어는 이름이 적합한지 여부를 검사하지 않는다. | |
824 | 만약 서브시스템의 이름이 없다면 명령어는 실패할 것이다. | |
825 | </para> | |
826 | <para> | |
827 | <!-- | |
828 | <programlisting> | |
829 | lxc-cgroup -n foo cpuset.cpus | |
830 | </programlisting> | |
831 | will display the content of this subsystem. | |
832 | <programlisting> | |
833 | lxc-cgroup -n foo cpu.shares 512 | |
834 | </programlisting> | |
835 | will set the subsystem to the specified value. | |
836 | --> | |
837 | <programlisting> | |
838 | lxc-cgroup -n foo cpuset.cpus | |
839 | </programlisting> | |
840 | 는 해당 서브시스템의 내용을 표시한다. | |
841 | <programlisting> | |
842 | lxc-cgroup -n foo cpu.shares 512 | |
843 | </programlisting> | |
844 | 는 해당 서브시스템의 값을 설정한다. | |
845 | </para> | |
846 | </refsect2> | |
847 | </refsect1> | |
848 | ||
849 | <refsect1> | |
850 | <title><!-- Bugs -->버그</title> | |
851 | <para> | |
852 | <!-- | |
853 | The <command>lxc</command> is still in development, so the | |
854 | command syntax and the API can change. The version 1.0.0 will be | |
855 | the frozen version. | |
856 | --> | |
857 | <command>lxc</command>는 아직 개발중이다. 그래서 명령어 사용법이나, API가 변경될 수 있다. 버전 1.0.0은 변경되지 않는 고정된 버전이다. | |
858 | </para> | |
859 | </refsect1> | |
860 | ||
861 | &seealso; | |
862 | ||
863 | <refsect1> | |
864 | <title><!-- Author -->저자</title> | |
865 | <para>Daniel Lezcano <email>daniel.lezcano@free.fr</email></para> | |
866 | </refsect1> | |
867 | ||
868 | </refentry> | |
869 | ||
870 | <!-- Keep this comment at the end of the file Local variables: mode: | |
871 | sgml sgml-omittag:t sgml-shorttag:t sgml-minimize-attributes:nil | |
872 | sgml-always-quote-attributes:t sgml-indent-step:2 sgml-indent-data:t | |
873 | sgml-parent-document:nil sgml-default-dtd-file:nil | |
874 | sgml-exposed-tags:nil sgml-local-catalogs:nil | |
875 | sgml-local-ecat-files:nil End: --> |