mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-27 02:30:10 +08:00
发布：lmctfy - Let Me Contain That For You
This commit is contained in:
wxy
parent
d194a0d0ff
commit
3cd6decfb1
247
published/lmctfy - Let Me Contain That For You.md
Normal file
247
published/lmctfy - Let Me Contain That For You.md
Normal file
@ -0,0 +1,247 @@
|
||||
lmctfy（Let Me Contain That For you）：让我用集装箱为你的程式打包
|
||||
===========================================================
|
||||
|
||||
lmctfy (发音是lem-kut-fee)是谷歌[Google][1]开发的容器栈，可以为Linux应用提供容器（container）。这些容器可以让一台机器上的不同应用使用相互隔离的资源，以独占的方式运行在同一台机器上。这些应用也可以拥有容器，因此能够创建和管理属于他们自己的子容器。
|
||||
|
||||
这项项目旨在提供一组以用户的意图为原点的高级API，来实现对容器概念的抽象化。这些创建的容器自身也通过继承也可以拥有了自己的容器、也能够被其他的用户程序所管理。
|
||||
|
||||
Lmctfy是为某些特定的场景（配置环境）设计、实现的，所以可能不能在所有场景（配置环境）中正常运作。我们的目标是为更多的场景（配置环境）提供更多的支持，所以你可以为这项项目[贡献][2]你的补丁或是在[邮件列表][3]中发送邮件，这样我们可以朝着既定的[路线图][4]前进。
|
||||
|
||||
lmctfy 内包含一个C++库和一个CLI（命令行界面程序）
|
||||
|
||||
## 最新进展
|
||||
|
||||
lmctfy 还是一个在beta阶段的应用，目前仍在主要开发中。最新的版本是`0.1`。她目前只支持CPU和内存资源的隔离。点击查看我们的[路线图][4]来了解各部分的开发情况，点击查看[贡献][2]。
|
||||
|
||||
## 从此开始
|
||||
|
||||
这一节描述如何编译你的CLI，运行所有的UI测试，和初始化机器的细节。 [CLI][5]这节提供了一些CLI操作的例子，[C++ 库][6]描述了这个库的使用详情。
|
||||
|
||||
### 依赖
|
||||
|
||||
编译本程序需要使用make和g++4.7。 lmcfy使用了C++11，所以需要支持这项功能的编译器。我们在 **Ubuntu 12.04+** 上测试过编译。如果有为其他环境的编译提供支持的补丁，我们很高兴而且希望这越多越好。
|
||||
|
||||
lmctfy 依赖下列几个库，需要这些库存在于你的计算机系统里。
|
||||
|
||||
* [Protocol Buffers](https://code.google.com/p/protobuf/)
|
||||
* [gflags](https://code.google.com/p/gflags/)
|
||||
* [RE2](https://code.google.com/p/re2/)
|
||||
|
||||
### 编译CLI
|
||||
|
||||
编译`lmctfy`的CLI：
|
||||
|
||||
```bash
|
||||
make -j <线程数> lmctfy
|
||||
```
|
||||
CLI程序会生成在 `bin/lmctfy/cli/lmctfy`
|
||||
|
||||
### 编译C++库
|
||||
|
||||
编译lmctfy的库：
|
||||
|
||||
```bash
|
||||
make -j <线程数> liblmctfy.a
|
||||
```
|
||||
库文件会生成在 `bin/liblmctfy.a`.
|
||||
|
||||
### 运行测试
|
||||
|
||||
编译和运行所有的UI测试：
|
||||
|
||||
```bash
|
||||
make -j <线程数> check
|
||||
```
|
||||
|
||||
### 初始化
|
||||
|
||||
lmctfy已经在 **Ubuntu 12.04+** 上的 **3.3** 和 **3.8** 内核上测试过。 lmctfy在一台机器的所有容器都是运行它的时候运转得最好，所以不建议让她运行在[LXC][7]或者其他container系统上（尽管在某些特殊得配置下这能够跑起来）。
|
||||
|
||||
为了运行lmctfy，我们必须首先初始化计算机。这只需要运行一次就可以，而且一般是在计算机第一次启动时候就完成了。当cgroup的hierarchies已经挂载了，接下来通常一个空的配置会可以让lmctfy自动监测到目前的挂载。
|
||||
|
||||
```bash
|
||||
lmctfy init ""
|
||||
```
|
||||
|
||||
如果cgroup的hierarchies没有被挂载，那么必须指明这些资源，这样lmctfy才可以挂载他们。目前版本需要以下cgroup的hierarchies资源`cpu`，`cpuset`，`cpuacct`，`memory`和`freezer`。 `cpu`和`cpuacct` 是目前唯一可以被共享挂载的，其他的必须被单独地挂载。具体配置说明可以查看[lmctfy.proto][8]中的`InitSpec`节。以下的例子是一个挂载了`/dev/cgroup`中的所有hierarachies的配置文件：
|
||||
|
||||
|
||||
```bash
|
||||
lmctfy init "
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpu'
|
||||
hierarchy:CGROUP_CPU hierarchy:CGROUP_CPUACCT
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpuset' hierarchy:CGROUP_CPUSET
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/freezer' hierarchy:CGROUP_FREEZER
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/memory' hierarchy:CGROUP_MEMORY
|
||||
}"
|
||||
```
|
||||
|
||||
这样，机器就可以被`lmctfy`使用、进行容器的操作。
|
||||
|
||||
## 容器的命名
|
||||
|
||||
容器的命名系统简化了文件系统的路径，因为以后只需要一系列容器的继承（容器的容器、子容器、子子容器）就可以了♪───Ｏ（≧∇≦）Ｏ──── ♪。
|
||||
|
||||
容器名称允许的字符集：
|
||||
|
||||
* 英文字母＋阿拉伯数字 (`[a-zA-Z0-9]+`)
|
||||
* 下划线 (`_`)
|
||||
* 横县 (`-`)
|
||||
* 英文句号 (`.`)
|
||||
|
||||
绝对路径是从容器（比如是`/sys/subcont`）的根目录(`/`)开始计算的。容器的名字也可以是相对的（比如`subcont`）。一般地（除非特殊情况说明），都是沿用一般的文件路径方式。
|
||||
|
||||
### 例子
|
||||
|
||||
```
|
||||
/ : 容器的根目录
|
||||
/sys : "sys" 容器
|
||||
/sys/sub : "sub" 容器，"sys"容器的子容器
|
||||
. : 当前的容器
|
||||
./ : 当前的容器
|
||||
.. : 当前的容器的父容器
|
||||
sub : 当前的容器的"sub" 子容器
|
||||
./sub : 当前的容器的"sub" 子容器
|
||||
/sub : "sub" 容器
|
||||
../sibling : 当前的父容器的“sibling”子容器
|
||||
```
|
||||
|
||||
|
||||
## CLI
|
||||
|
||||
### 创建
|
||||
|
||||
创建一个容器：
|
||||
|
||||
```bash
|
||||
lmctfy create <名称> <参数>
|
||||
```
|
||||
|
||||
更完整的细节参见[lmctfy.proto](/include/lmctfy.proto)
|
||||
|
||||
例子(创建一个内存限制在100MB的容器)：
|
||||
|
||||
```bash
|
||||
lmctfy create memory_only "memory:{limit:100000000}"
|
||||
```
|
||||
|
||||
### 销毁
|
||||
|
||||
销毁一个容器：
|
||||
|
||||
```bash
|
||||
lmctfy destroy <名称>
|
||||
```
|
||||
|
||||
### 列表
|
||||
|
||||
从根目录递归显示当前机器的所有容器：
|
||||
|
||||
```bash
|
||||
lmctfy list containers -r /
|
||||
```
|
||||
|
||||
你也可以只列出当前的子容器：
|
||||
|
||||
```bash
|
||||
lmctfy list containers
|
||||
```
|
||||
|
||||
### 运行
|
||||
|
||||
在一台容器中运行命令：
|
||||
|
||||
```bash
|
||||
lmctfy run <名称> <命令行>
|
||||
```
|
||||
|
||||
例子：
|
||||
|
||||
```bash
|
||||
lmctfy run test "echo hello world"
|
||||
lmctfy run /test/sub bash
|
||||
lmctfy run -n /test "echo hello from a daemon"
|
||||
```
|
||||
|
||||
### 其他
|
||||
|
||||
键入`lmctfy help`查看全部的命令和文档
|
||||
|
||||
## C++ Library
|
||||
|
||||
此库包含了`::containers::lmctfy::ContainerApi` 用来创建、获取、销毁、监测`::containers::lmctfy::Container`类型的对象，并且被独立的容器相互交流。具体的lmctfy C++库的文档可以查看头文件[lmctfy.h][9]（你是认真的吗(￣▽￣)）。
|
||||
|
||||
## 路线图
|
||||
|
||||
lmctfy项目通过两个层（CL1、CL2）来实现一个容器栈。CL1围绕着驱动进程，并执行CL2制定的容器策略。CL1会为更高层创建和维护容器的抽象。她应当是唯一直接和内核交流以维护容器的层。 CL2发展和设定容器策略，她使用CL1来执行策略和操控容器。比如，CL2（后台进程）实现了一个策略：所有容器的CPU和内存使用总和不可以超过现提供的CPU和内存资源（以防止对内存资源的过度使用）。为了执行这条策略，她（CL2）会使用CL1（library／CLI）来创建带这条内存限制规则的容器。另一条对应的策略可能包括了允许过度使用X％的机器资源或者对不同资源的多重层次控制。
|
||||
|
||||
lmcfty项目现在提供了CL1组件，CL2还没有实现。
|
||||
|
||||
### CL1
|
||||
|
||||
现在只提供高性能CPU和内存隔离。在我们的路线图中我们还需要实现以下几项：
|
||||
|
||||
* *磁盘IO隔离:* 这部分几乎完成了，但是我们还缺少控制器和资源处理器。
|
||||
* *网络隔离:* 这部分和cgroup实现还在计划中。
|
||||
* *命名空间支援:* 给所有命名空间支援并且整合到相关的资源中。
|
||||
* *根文件系统支援:* 识别并建立根文件系统。
|
||||
* *磁盘镜像:* 可以导入和导出容器的根文件系统的镜像。
|
||||
* *支持暂停／继续:* 使用继承的freezer。
|
||||
* *还原点恢复:* 可以建立还原点并恢复到不同机器的容器中。
|
||||
|
||||
### CL2
|
||||
|
||||
最基础的CL2 应当有一个容器策略来保证在机器不允许超载运行情况下的资源合理分配。我们的目标是CL2最终实现提供不同层次的服务。在这个框架下一些层次可以比其他的获得更多好的服务。
|
||||
|
||||
* 监控和统计支持。
|
||||
* 管理功能和功能检查。
|
||||
* 服务的质量保证和执行。
|
||||
|
||||
## 内核支持
|
||||
|
||||
lmctfy 最初的设计和实现是在一个自定义的内核上（一个原生linux内核外加一些列自选的补丁）上。由此，一些特性在这些内核补丁上跑得最理想。但是lmctfy应该在没有他们得情况下正常运行。她应当监测可用得内核支援并且与之适应。我们已经在原生的 **Ubuntu** 的 **3.3** 和 **3.8** 系列内核上测试过。如果你发现在其他版本内核下的问题，请汇报。
|
||||
|
||||
一些相关的内核补丁：
|
||||
|
||||
* *CPU 延时:* 这个补丁为cpu hierarchy增加了`cpu.lat`的cgroup 文件。她限制了cgroup能预测的CPU唤醒延时时间。
|
||||
* *CPU 柱状图统计:* 这个补丁为cpuacct hierarchy增加了`cpuacct.histogram` cgroup 文件。她为CPU计划行为提供了多种柱状图方案。
|
||||
* *OOM 管理:* 一系列的补丁，用于在内存用尽的情况下执行优先权。
|
||||
|
||||
## 贡献
|
||||
|
||||
对项目感到兴趣了？看看我们的[路线图][4]，看你是不是由很多想贡献的方向呢？ [从此开始][10]，你应该可以运行我们的程序。如果无法运行，请让我们知道，这样我们可以改进这份指南。
|
||||
|
||||
## 邮件列表
|
||||
|
||||
本项目的邮件列表是<lmctfy@googlegroups.com>。本邮件列表用来发布、讨论、一般性支持。
|
||||
|
||||
---
|
||||
|
||||
原文: https://github.com/google/lmctfy/
|
||||
|
||||
本文由[LCTT][] 原创翻译，[Linux中国][] 荣誉推出
|
||||
|
||||
译者：[Chilledheart][] 校对：[wxy][]
|
||||
|
||||
[LCTT]:https://github.com/LCTT/TranslateProject
|
||||
[Linux中国]:http://linux.cn/portal.php
|
||||
[Chilledheart]:http://linux.cn/space/Chilledheart
|
||||
[wxy]:http://linux.cn/space/wxy
|
||||
|
||||
[1]:http://www.google.com
|
||||
[2]:#contributing
|
||||
[3]:#mailing-list
|
||||
[4]:#roadmap
|
||||
[5]:#cli-commands
|
||||
[6]:#c-library
|
||||
[7]:http://lxc.sourceforge.net/
|
||||
[8]:https://github.com/google/lmctfy/blob/master/include/lmctfy.proto
|
||||
[9]:https://github.com/google/lmctfy/blob/master/include/lmctfy.h
|
||||
[10]:#getting-started
|
||||
@ -1,212 +0,0 @@
|
||||
lmctfy - Let Me Contain That For You
|
||||
====================================
|
||||
|
||||
lmctfy (pronounced *lem-kut-fee*) is the open source version of [Google](http://google.com)’s container stack, which provides Linux application containers. These containers allow for the isolation of resources used by multiple applications running on a single machine. This gives the applications the impression of running exclusively on a machine. The applications may be container-aware and thus be able to create and manage their own subcontainers.
|
||||
|
||||
The project aims to provide the container abstraction through a high-level API built around user intent. The containers created are themselves container-aware within the hierarchy and can be delegated to be managed by other user agents.
|
||||
|
||||
lmctfy was designed and implemented with specific use-cases and configurations in mind and may not work out of the box for all use-cases and configurations. We do aim to support more use-cases and configurations so please feel free to [contribute](#contributing) patches or send e-mail to the [mailing list](#mailing-list) so that we may incorporate these into the [roadmap](#roadmap).
|
||||
|
||||
lmctfy is released as both a C++ library and a CLI.
|
||||
|
||||
## Current Status
|
||||
lmctfy is beta software under heavy development and may change as it evolves. The latest release version is `0.1`. It currently only provides CPU and memory isolation. Take a look at our [roadmap](#roadmap) for areas of development and possible [contributions](#contributing).
|
||||
|
||||
## Getting Started
|
||||
This section describes building the CLI, running all unit tests, and initializing the machine. The [CLI Commands](#cli-commands) section provides some examples of CLI operations and [C++ Library](#c-library) describes the use of the underlying library.
|
||||
### Dependencies
|
||||
The build system is targeted for use with `make` and `g++-4.7`. lmctfy makes use of `C++11` and as such needs a compiler that supports it. We've tested the setup on **Ubuntu 12.04+**. We are happy to accept patches that add support for other setups.
|
||||
|
||||
lmctfy depends on the following libraries and expects them to be available on the system:
|
||||
* [Protocol Buffers](https://code.google.com/p/protobuf/)
|
||||
* [gflags](https://code.google.com/p/gflags/)
|
||||
* [RE2](https://code.google.com/p/re2/)
|
||||
|
||||
### Building the CLI
|
||||
To build the `lmctfy` CLI:
|
||||
|
||||
```bash
|
||||
make -j <number of threads> lmctfy
|
||||
```
|
||||
|
||||
The CLI should now be available at: `bin/lmctfy/cli/lmctfy`
|
||||
### Building the C++ Library
|
||||
To build the lmctfy library:
|
||||
|
||||
```bash
|
||||
make -j <number of threads> liblmctfy.a
|
||||
```
|
||||
|
||||
The library should now be available at: `bin/liblmctfy.a`.
|
||||
### Running Unit Tests
|
||||
|
||||
To build and run all unit tests:
|
||||
|
||||
```bash
|
||||
make -j <number of threads> check
|
||||
```
|
||||
|
||||
### Initialization
|
||||
lmctfy has been tested on **Ubuntu 12.04+** and on the **Ubuntu 3.3** and **3.8** kernels. lmctfy runs best when it owns all containers in a machine so it is not recommended to run lmctfy alongside [LXC](http://lxc.sourceforge.net/) or another container system (although given some configuration, it can be made to work).
|
||||
|
||||
In order to run lmctfy we must first initialize the machine. This only needs to happen once and is typically done when the machine first boots. If the cgroup hierarchies are already mounted, then an empty config is enough and lmctfy will auto-detect the existing mounts:
|
||||
|
||||
```bash
|
||||
lmctfy init ""
|
||||
```
|
||||
|
||||
If the cgroup hierarchies are not mounted, those must be specified so that lmctfy can mount them. The current version of lmctfy needs the following cgroup hierarchies: `cpu`, `cpuset`, `cpuacct`, `memory`, and `freezer`. `cpu` and `cpuacct` are the only hierarchies that can be co-mounted, all other must be mounted individually. For details on configuration specifications take a look at `InitSpec` in [lmctfy.proto](/include/lmctfy.proto). An example configuration mounting all of the hierarchies in `/dev/cgroup`:
|
||||
|
||||
```bash
|
||||
lmctfy init "
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpu'
|
||||
hierarchy:CGROUP_CPU hierarchy:CGROUP_CPUACCT
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpuset' hierarchy:CGROUP_CPUSET
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/freezer' hierarchy:CGROUP_FREEZER
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/memory' hierarchy:CGROUP_MEMORY
|
||||
}"
|
||||
```
|
||||
|
||||
The machine should now be ready to use `lmctfy` for container operations.
|
||||
|
||||
## Container Names
|
||||
Container names mimic filesystem paths closely since they express a hierarchy of containers (i.e.: containers can be inside other containers, these are called **subcontainers** or **child containers**).
|
||||
|
||||
Allowable characters for container names are:
|
||||
* Alpha numeric (`[a-zA-Z0-9]+`)
|
||||
* Underscores (`_`)
|
||||
* Dashes (`-`)
|
||||
* Periods (`.`)
|
||||
|
||||
An absolute path is one that is defined from the root (`/`) container (i.e.: `/sys/subcont`). Container names can also be relative (i.e.: `subcont`). In general and unless otherwise specified, regular filesystem path rules apply.
|
||||
|
||||
### Examples:
|
||||
```
|
||||
/ : Root container
|
||||
/sys : the "sys" top level container
|
||||
/sys/sub : the "sub" container inside the "sys" top level container
|
||||
. : the current container
|
||||
./ : the current container
|
||||
.. : the parent of the current container
|
||||
sub : the "sub" subcontainer (child container) of the current container
|
||||
./sub : the "sub" subcontainer (child container) of the current container
|
||||
/sub : the "sub" top level container
|
||||
../sibling : the "sibling" child container of the parent container
|
||||
```
|
||||
|
||||
|
||||
## CLI Commands
|
||||
### Create
|
||||
To create a container run:
|
||||
|
||||
```bash
|
||||
lmctfy create <name> <specification>
|
||||
```
|
||||
|
||||
Please see [lmctfy.proto](/include/lmctfy.proto) for the full `ContainerSpec`.
|
||||
|
||||
Example (create a memory-only container with `100MB` limit):
|
||||
|
||||
```bash
|
||||
lmctfy create memory_only "memory:{limit:100000000}"
|
||||
```
|
||||
|
||||
### Destroy
|
||||
To destroy a container run:
|
||||
|
||||
```bash
|
||||
lmctfy destroy <name>
|
||||
```
|
||||
|
||||
### List
|
||||
To list all containers in a machine, ask to recursively list from root:
|
||||
|
||||
```bash
|
||||
lmctfy list containers -r /
|
||||
```
|
||||
|
||||
You can also list only the current subcontainers:
|
||||
|
||||
```bash
|
||||
lmctfy list containers
|
||||
```
|
||||
|
||||
### Run
|
||||
To run a command inside a container run:
|
||||
|
||||
```bash
|
||||
lmctfy run <name> <command>
|
||||
```
|
||||
|
||||
Examples:
|
||||
|
||||
```bash
|
||||
lmctfy run test "echo hello world"
|
||||
lmctfy run /test/sub bash
|
||||
lmctfy run -n /test "echo hello from a daemon"
|
||||
```
|
||||
|
||||
### Other
|
||||
Use `lmctfy help` to see the full command listing and documentation.
|
||||
|
||||
## C++ Library
|
||||
The library is comprised of the `::containers::lmctfy::ContainerApi` factory which creates, gets, destroys, and detects `::containers::lmctfy::Container` objects that can be used to interact with individual containers. Full documentation for the lmctfy C++ library can be found in [lmctfy.h](/include/lmctfy.h).
|
||||
|
||||
## Roadmap
|
||||
|
||||
The lmctfy project proposes a containers stack with two major layers we’ll call CL1 and CL2. CL1 encompases the driver and enforcement of the containers policy set by CL2. CL1 will create and maintain the container abstraction for higher layers. It should be the only layer that directly interacts with the kernel to manage containers. CL2 is what develops and sets container policy, it uses CL1 to enforce the policy and manage containers. For example: CL2 (a daemon) implements a policy that the amount of CPU and memory used by all of a machine’s containers must not exceed the amount of available CPU and memory (as opposed to overcommitting memory in the machine). To enforce that policy it uses CL1 (library/CLI) to create containers with memory limits that add up to the machine’s available memory. Alternate policies may involve overcommitting a machine’s resources by X% or creating levels of resources with different guarantees for quality of service.
|
||||
|
||||
The lmctfy project currently provides the CL1 component. The CL2 is not yet implemented.
|
||||
|
||||
### CL1
|
||||
Currently only provides robust CPU and memory isolation. In our roadmap we have support for the following:
|
||||
* *Disk IO Isolation:* The specification is mostly complete, we’re missing the controller and resource handler.
|
||||
* *Network Isolation:* The specification and cgroup implementation is up in the air.
|
||||
* *Support for Namespaces:* Bringing support for all namespaces and integrating them to the relevant resources.
|
||||
* *Support for Root File Systems:* Specifying and building root file systems.
|
||||
* *Disk Images:* Being able to import/export a container’s root file system image.
|
||||
* *Support for Pause/Resume:* Using the freezer hierarchy.
|
||||
* *Checkpoint Restore:* Being able to checkpoint and restore containers on different machines.
|
||||
|
||||
### CL2
|
||||
The most basic CL2 would use a container policy that ensures the fair sharing of a machine’s resources without allowing overcommitment. We aim to eventually implement a CL2 that provides different levels of guaranteed quality of service. In this scheme some levels are given stronger quality of service than others. The following CL2 features are supported in our roadmap:
|
||||
* Monitoring and statistics support.
|
||||
* Admission control and feasibility checks.
|
||||
* Quality of Service guarantees and enforcement.
|
||||
|
||||
## Kernel Support
|
||||
|
||||
lmctfy was originally designed and implemented around a custom kernel with a set of patches on top of a vanilla Linux kernel. As such, some features work best in conjunction with those kernel patches. However, lmctfy should work without them. It should detect available kernel support and adapt accordingly. We’ve tested lmctfy in vanilla **Ubuntu 3.3*** and **3.8** kernels. Please report any issues you find with other kernel versions.
|
||||
|
||||
Some of the relevant kernel patches:
|
||||
* *CPU latency:* This adds the `cpu.lat` cgroup file to the cpu hierarchy. It bounds the CPU wakeup latency a cgroup can expect.
|
||||
* *CPU histogram accounting:* This adds the `cpuacct.histogram` cgroup file to the cpuacct hierarchy. It provides various histograms of CPU scheduling behavior.
|
||||
* *OOM management:* Series of patches to enforce priorities during out of memory conditions.
|
||||
|
||||
## Contributing
|
||||
|
||||
Interested in contributing to the project? Feel free to send a patch or take a look at our [roadmap](#roadmap) for ideas on areas of contribution. Follow [Getting Started](#getting-started) above and it should get you up and running. If not, let us know so we can help and improve the instructions.
|
||||
|
||||
## Mailing List
|
||||
|
||||
The project mailing list is <lmctfy@googlegroups.com>. The list will be used for announcements, discussions, and general support.
|
||||
|
||||
---
|
||||
|
||||
via: https://github.com/google/lmctfy/
|
||||
|
||||
本文由 [LCTT][] 原创翻译，[Linux中国][] 荣誉推出
|
||||
|
||||
译者：[译者ID][Chilledheart](http://linux.cn/space/Chilledheart) 校对：[校对者ID][]
|
||||
|
||||
[LCTT]:https://github.com/LCTT/TranslateProject
|
||||
[Linux中国]:http://linux.cn/portal.php
|
||||
[译者ID]:http://linux.cn/space/译者ID
|
||||
[校对者ID]:http://linux.cn/space/校对者ID
|
||||
@ -1,245 +0,0 @@
|
||||
lmctfy - Let Me Contain That For you 讓我用集裝箱為你的程式打包
|
||||
====================================
|
||||
lmctfy (發音是 lem-kut-fee)是谷歌[Google](http://www.google.com)開發的容器棧，可以為Linux程式提供容器（container）。這些容器可以讓一台機器上的不同程式使用相互隔離的資源。這可以讓那些程式以獨佔的方式運行在一台機器上。這些程式也可以擁有容器，因此能夠創建和管理屬於他們自己的子容器。
|
||||
|
||||
這項項目旨在提供一組以用戶的意圖為原點的高級API，來實現對容器概念的抽象化。這些創建的容器自身也通過繼承也可以擁有了自己的容器、也能夠杯其他的用戶程序所管理。
|
||||
|
||||
Lmctfy是為某些特定的場景（配置環境）設計、實現的，所以可能不能在所有場景（配置環境）中正常運作。我們目標是為更多的場景（配置環境）提供更多的支持，所以你可以為這項項目[貢獻](#貢獻])你的補丁 或是 在[郵件列表](#郵件列表)中發送郵件，這樣我們可以朝著[路線圖](#路線圖)前進。
|
||||
|
||||
lmctfy 內包含一個C++庫 和一個CLI（命令行界面程序）
|
||||
lmctfy is released as both a C++ library and a CLI.
|
||||
|
||||
## 最新進展
|
||||
|
||||
lmctfy 還是一個在beta階段程式，目前仍在高度的開發中。最新的版本是0.1。她目前只支持CPU和內存資源的隔離。點擊查看我們的[路線圖](#路線圖)查看各部分的開發情況，點擊查看[貢獻](#貢獻)。
|
||||
|
||||
## 從此開始
|
||||
|
||||
這一節描述如何編譯你的CLI，運行所有的UI測試，和初始化機器的細節。[CLI](#cli)這節提供了一些CLI操作的例子，[C++ 庫](#c-library)描述了這個庫的使用詳情。
|
||||
|
||||
### 依賴
|
||||
|
||||
編譯本程序需要使用make和g++4.7。lmcfy使用了C++11，所以需要支援這項feature的編譯器。我們在 **Ubuntu 12.04+** 上測試過編譯。如果有為其他環境的編譯提供支援的補丁，我們很哈皮而且希望這越多越好。
|
||||
|
||||
lmctfy 依賴下列幾個庫，需要這些庫存在於你的計算機系統裡。
|
||||
* [Protocol Buffers](https://code.google.com/p/protobuf/)
|
||||
* [gflags](https://code.google.com/p/gflags/)
|
||||
* [RE2](https://code.google.com/p/re2/)
|
||||
|
||||
### 編譯CLI
|
||||
|
||||
編譯lmctfy的CLI：
|
||||
|
||||
```bash
|
||||
make -j <進程數> lmctfy
|
||||
```
|
||||
|
||||
CLI程序會生成在 `bin/lmctfy/cli/lmctfy`
|
||||
### Building the C++ Library
|
||||
編譯C++庫
|
||||
編譯Lmctfy的庫：
|
||||
|
||||
|
||||
```bash
|
||||
make -j <進程數> liblmctfy.a
|
||||
```
|
||||
|
||||
庫文件會生成在 `bin/liblmctfy.a`.
|
||||
### 運行測試
|
||||
|
||||
編譯和運行所有的UI測試：
|
||||
|
||||
```bash
|
||||
make -j <進程數> check
|
||||
```
|
||||
|
||||
### 初始化
|
||||
|
||||
lmctfy已經在 **Ubuntu 12.04+** 和 **Ubuntu 3.3** and **3.8** 內核上測試過。lmctfy 當一台機器的所有容器都是運行她得時候 運轉得最好。所以不建議讓她運行在 [LXC](http://lxc.sourceforge.net/) 或者 其他container系統上（儘管在某些特殊得配置下這能夠跑起來）。
|
||||
|
||||
為了運行lmctfy，我們必須首先初始化計算機。這只需要運行一次就可以，而且一般是在計算機第一次啓動時候就完成了。當cgroup的hierarchies已經掛載了，接下來通常一個空的配置會可以讓lmctfy自動監測到目前的掛載。
|
||||
|
||||
```bash
|
||||
lmctfy init ""
|
||||
```
|
||||
|
||||
如果cgroup的hierarchies沒有被掛載，那麼這些資源必須被指明，這樣lmctfy才可以掛載他們。目前版本需要以下 cgroup 的hierarchies資源 `cpu`, `cpuset`, `cpuacct`, `memory`, and `freezer` 。 `cpu` and `cpuacct` 是目前衛衣可以被共享掛載的，其他的必須被單獨地掛載。具體配置說明可以查看`InitSpec` 在 [lmctfy.proto](/include/lmctfy.proto) 中。以下的例子是一個掛載 `/dev/cgroup` 中地所有hierarachies的配置文件：
|
||||
|
||||
|
||||
```bash
|
||||
lmctfy init "
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpu'
|
||||
hierarchy:CGROUP_CPU hierarchy:CGROUP_CPUACCT
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/cpuset' hierarchy:CGROUP_CPUSET
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/freezer' hierarchy:CGROUP_FREEZER
|
||||
}
|
||||
cgroup_mount:{
|
||||
mount_path:'/dev/cgroup/memory' hierarchy:CGROUP_MEMORY
|
||||
}"
|
||||
```
|
||||
|
||||
這樣，機器就可以被`lmctfy`使用、進行容器的操作。
|
||||
|
||||
## 容器的命名
|
||||
|
||||
容器的命名系統簡化了文件系統的路徑，因為以後之需要一系列容器的繼承（容器的容器、子容器、子子容器）就可以了♪───Ｏ（≧∇≦）Ｏ────♪。
|
||||
|
||||
容器名稱允許的字符集：
|
||||
* 英文字母＋阿拉伯數字 (`[a-zA-Z0-9]+`)
|
||||
* 下劃線 (`_`)
|
||||
* 橫縣 (`-`)
|
||||
* 西文句號 (`.`)
|
||||
|
||||
絕對路徑是由從容器（比如是 `/sys/subcont`）的根目錄(`/`)開始計算的 。容器的名字也可以是相對的（比如 `subcont`）。一般地（除非特殊情況說明），都是沿用正常的文件路徑計算規則。
|
||||
|
||||
### 例子
|
||||
|
||||
```
|
||||
/ : 容器的根目錄
|
||||
/sys : "sys" 容器
|
||||
/sys/sub : "sub" 容器，"sys"容器的子容器
|
||||
. : 當前的容器
|
||||
./ : 當前的容器
|
||||
.. : 當前的容器的父容器
|
||||
sub : 當前的容器的"sub" 子容器
|
||||
./sub : 當前的容器的"sub" 子容器
|
||||
/sub : "sub" 容器
|
||||
../sibling : 當前的父容器的“sibling”子容器
|
||||
```
|
||||
|
||||
|
||||
## CLI
|
||||
|
||||
### 創建
|
||||
|
||||
創建一個容器：
|
||||
|
||||
```bash
|
||||
lmctfy create <名稱> <參數>
|
||||
```
|
||||
|
||||
更完整的細節參見 [lmctfy.proto](/include/lmctfy.proto)
|
||||
|
||||
例子 (創建一個內存限制在100MB的容器)：
|
||||
|
||||
```bash
|
||||
lmctfy create memory_only "memory:{limit:100000000}"
|
||||
```
|
||||
|
||||
### 摧毀
|
||||
|
||||
摧毀一個容器：
|
||||
|
||||
```bash
|
||||
lmctfy destroy <名稱>
|
||||
```
|
||||
|
||||
### List
|
||||
列表
|
||||
從根目錄遞歸顯示當前機器的所有容器：
|
||||
|
||||
```bash
|
||||
lmctfy list containers -r /
|
||||
```
|
||||
|
||||
你也可以指列出當前的子容器：
|
||||
|
||||
```bash
|
||||
lmctfy list containers
|
||||
```
|
||||
|
||||
### 啓動
|
||||
|
||||
在一台容器中運行程式：
|
||||
|
||||
```bash
|
||||
lmctfy run <名稱> <命令式>
|
||||
```
|
||||
|
||||
例子：
|
||||
|
||||
```bash
|
||||
lmctfy run test "echo hello world"
|
||||
lmctfy run /test/sub bash
|
||||
lmctfy run -n /test "echo hello from a daemon"
|
||||
```
|
||||
|
||||
### 其他
|
||||
|
||||
鍵入`lmctfy help`查看全部的命令和文檔
|
||||
|
||||
## C++ Library
|
||||
|
||||
此庫包含了`::containers::lmctfy::ContainerApi` 用來創建、獲取、銷毀、監測`::containers::lmctfy::Container`類型的對象，並且被獨立的容器相互交流。具體的lmctfy C++庫的文檔可以查看頭文件[lmctfy.h](/include/lmctfy.h)（你是認真的嗎(￣▽￣)）。
|
||||
|
||||
## 路線圖
|
||||
|
||||
|
||||
lmctfy項目通過兩個層（CL1、CL2）來實現一個容器棧。CL1圍繞這驅動程式，並執行CL2製定的容器策略。CL1會為更高層創建和維護容器的抽象。她應當是唯一直接和內核交流以維護容器的層。CL2發展和設定容器策略，她使用CL1來執行策略和操控容器。比如，CL2（後台程式）實現了一個策略：所有容器的CPU和內存使用綜合不可以超過現提供的CPU和內存資源（以防止對內存資源的過度使用）。為了執行這條策略，她（CL2）會使用CL1（庫／CLI）來創建帶這條內存限制規則的容器。另一條對應的策略可能包括了允許過度使用X％的機器資源或者對不同資源的多重層次控制。
|
||||
|
||||
lmcfty項目現在提供了CL1組件，CL2還沒有實現。
|
||||
|
||||
### CL1
|
||||
現在只提供高性能CPU和內存隔離。在我們的路線圖中我們還需要實現以下幾項：
|
||||
* *Disk IO Isolation:* The specification is mostly complete, we’re missing the controller and resource handler.
|
||||
* *磁盤IO隔離:* 這部分幾乎完成了，但是我們還缺少控制器和資源處理器。
|
||||
* *Network Isolation:* The specification and cgroup implementation is up in the air.
|
||||
* *網絡隔離:* 這部分和cgroup實現還在計劃中。
|
||||
* *Support for Namespaces:* Bringing support for all namespaces and integrating them to the relevant resources.
|
||||
* *命名空間支援:* 給所有命名空間支援並且整合到相關的資源中。
|
||||
* *Support for Root File Systems:* Specifying and building root file systems.
|
||||
* *根文件系統支援:* 識別並建立根文件系統。
|
||||
* *Disk Images:* Being able to import/export a container’s root file system image.
|
||||
* *磁盤鏡像:* 可以導入和導出容器的根文件系統的鏡像。
|
||||
* *Support for Pause/Resume:* Using the freezer hierarchy.
|
||||
* *為暫停／繼續提供支援:* 使用繼承的 freezer。
|
||||
* *Checkpoint Restore:* Being able to checkpoint and restore containers on different machines.
|
||||
* *還原點恢復:* 可以建立還原點並恢復到不同機器的容器中。
|
||||
|
||||
### CL2
|
||||
最基礎的CL2 應當有一個容器策略來保證在機器不允許超載運行情況下的資源合理分配。我們的目標是CL2最終實現提供不同層次的服務。在這個框架下一些層次可以比其他的獲得更多好的服務。
|
||||
* Monitoring and statistics support.
|
||||
* 檢視和統計支援。
|
||||
* Admission control and feasibility checks.
|
||||
* 管理功能和功能檢查。
|
||||
* Quality of Service guarantees and enforcement.
|
||||
* 服務的質量保證和執行。
|
||||
|
||||
## 內核支援
|
||||
|
||||
lmctfy 最初的設計和實現是在一個自定義的內核上（一個原生linux內核外加一些列自選的補丁）上。由此，一些特性在這些內核補丁上跑得最理想。但是lmctfy應該在沒有他們得情況下正常運行。她應當監測可用得內核支援並且與之適應。我們已經在原生的 **Ubuntu 3.3*** and **3.8** 系列內核上測試過。如果你發現在其他版本內核下的問題，請匯報。
|
||||
|
||||
一些相關的內核補丁：
|
||||
* *CPU latency:* This adds the `cpu.lat` cgroup file to the cpu hierarchy. It bounds the CPU wakeup latency a cgroup can expect.
|
||||
* *CPU 延時:* 這個補丁為cpu hierarchy增加了 `cpu.lat`的 cgroup 文件。她限制了cgroup能預測的CPU喚醒延時時間。
|
||||
* *CPU histogram accounting:* This adds the `cpuacct.histogram` cgroup file to the cpuacct hierarchy. It provides various histograms of CPU scheduling behavior.
|
||||
* *CPU 柱狀圖統計:* 這個補丁為cpuacct hierarchy增加了 `cpuacct.histogram` cgroup 文件。她為CPU計劃行為提供了多種柱狀圖方案。
|
||||
* *OOM management:* Series of patches to enforce priorities during out of memory conditions.
|
||||
* *OOM 管理:* 一系列的補丁，用於在內存用盡的情況下執行優先權。
|
||||
|
||||
## 貢獻
|
||||
|
||||
對項目感到興趣了？檢視下我們的i[路線圖](#路線圖)，看看你是不是由很多想貢獻的方向呢？[從此開始](#從此開始)，你應該可以運行我們的程式。如果無法運行，請讓我們知道，這樣我們可以改進這份指南。
|
||||
|
||||
## 郵件列表
|
||||
|
||||
|
||||
本項目的郵件列表是 <lmctfy@googlegroups.com>。本郵件列表用來發佈、討論、一般性支持。
|
||||
|
||||
---
|
||||
|
||||
原文引入: [github](https://github.com/google/lmctfy/)
|
||||
|
||||
本文由 [LCTT][] 原创翻译，[Linux中国][] 荣誉推出
|
||||
|
||||
译者：[译者ID][Chilledheart](http://linux.cn/space/Chilledheart) 校对：[校对者ID][]
|
||||
|
||||
[LCTT]:https://github.com/LCTT/TranslateProject
|
||||
[Linux中国]:http://linux.cn/portal.php
|
||||
[译者ID]:http://linux.cn/space/译者ID
|
||||
[校对者ID]:http://linux.cn/space/校对者ID
|
||||
Loading…
Reference in New Issue
Block a user