document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu.Wang 2018-07-11 14:55:45 +08:00
commit f0d2313df3
6 changed files with 303 additions and 422 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

343
sources/tech/20180606 Getting started with Buildah.md
View File

@ -1,343 +0,0 @@
pinewall translating
Getting started with Buildah
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/blocks_building.png?itok=eMOT-ire)
[Buildah][1] is a command-line tool for building [Open Container Initiative][2]-compatible (that means Docker- and Kubernetes-compatible, too) images quickly and easily. It can act as a drop-in replacement for the Docker daemon’s `docker build` command (i.e., building images with a traditional Dockerfile) but is flexible enough to allow you to build images with whatever tools you prefer to use. Buildah is easy to incorporate into scripts and build pipelines, and best of all, it doesn’t require a running container daemon to build its image.
### A drop-in replacement for docker build
You can get started with Buildah immediately, dropping it into place where images are currently built using a Dockerfile and `docker build`. Buildah’s `build-using-dockerfile`, or `bud` argument makes it behave just like `docker build` does, so it's easy to incorporate into existing scripts or build pipelines.
As with [previous articles I’ve written about Buildah][3], I like to use the example of installing "GNU Hello" from source. Consider this Dockerfile:
```
FROM fedora:28
LABEL maintainer Chris Collins <collins.christopher@gmail.com>
RUN dnf install -y tar gzip gcc make \
        && dnf clean all
ADD http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz /tmp/hello-2.10.tar.gz
RUN tar xvzf /tmp/hello-2.10.tar.gz -C /opt
WORKDIR /opt/hello-2.10
RUN ./configure
RUN make
RUN make install
RUN hello -v
ENTRYPOINT "/usr/local/bin/hello"
```
Buildah can create an image from this Dockerfile as easily as `buildah bud -t hello .`, replacing `docker build -t hello .`:
```
[chris@krang] $ sudo buildah bud -t hello .
STEP 1: FROM fedora:28
Getting image source signatures
Copying blob sha256:e06fd16225608e5b92ebe226185edb7422c3f581755deadf1312c6b14041fe73
 81.48 MiB / 81.48 MiB [====================================================] 8s
Copying config sha256:30190780b56e33521971b0213810005a69051d720b73154c6e473c1a07ebd609
 2.29 KiB / 2.29 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
STEP 2: LABEL maintainer Chris Collins <collins.christopher@gmail.com>
STEP 3: RUN dnf install -y tar gzip gcc make    && dnf clean all
<snip>
```
Once the build is complete, you can see the new image with the `buildah images` command:
```
[chris@krang] $ sudo buildah images
IMAGE ID        IMAGE NAME                              CREATED AT              SIZE
30190780b56e    docker.io/library/fedora:28             Mar 7, 2018 16:53       247 MB
6d54bef73e63    docker.io/library/hello:latest    May 3, 2018 15:24     391.8 MB
```
The new image, tagged `hello:latest`, can be pushed to a remote image registry or run using [CRI-O][4] or other Kubernetes CRI-compatible runtimes, or pushed to a remote registry. If you’re testing it as a replacement for Docker build, you will probably want to copy the image to the docker daemon’s local image storage so it can be run by Docker. This is easily accomplished with the `buildah push` command:
```
[chris@krang] $ sudo buildah push hello:latest docker-daemon:hello:latest
Getting image source signatures
Copying blob sha256:72fcdba8cff9f105a61370d930d7f184702eeea634ac986da0105d8422a17028
 247.02 MiB / 247.02 MiB [==================================================] 2s
Copying blob sha256:e567905cf805891b514af250400cc75db3cb47d61219750e0db047c5308bd916
 144.75 MiB / 144.75 MiB [==================================================] 1s
Copying config sha256:6d54bef73e638f2e2dd8b7bf1c4dfa26e7ed1188f1113ee787893e23151ff3ff
 1.59 KiB / 1.59 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
[chris@krang] $ sudo docker images | head -n2
REPOSITORY              TAG             IMAGE ID        CREATED                 SIZE
docker.io/hello      latest       6d54bef73e63  2 minutes ago   398 MB
[chris@krang] $ sudo docker run -t hello:latest
Hello, world!
```
### A few differences
Unlike Docker build, Buildah doesn’t commit changes to a layer automatically for every instruction in the Dockerfile—it builds everything from top to bottom, every time. On the positive side, this means non-cached builds (for example, those you would do with automation or build pipelines) end up being somewhat faster than their Docker build counterparts, especially if there are a lot of instructions. This is great for getting new changes into production quickly from an automated deployment or continuous delivery standpoint.
Practically speaking, however, the lack of caching may not be quite as useful for image development, where caching layers can save significant time when doing builds over and over again. This applies only to the `build-using-dockerfile` command, however. When using Buildah native commands, as we’ll see below, you can choose when to commit your changes to disk, allowing for more flexible development.
### Buildah native commands
Where Buildah _really_ shines is in its native commands, which you can use to interact with container builds. Rather than using `build-using-dockerfile/bud` for each build, Buildah has commands to actually interact with the temporary container created during the build process. (Docker uses temporary, or _intermediate_ containers, too, but you don’t really interact with them while the image is being built.)
Using the "GNU Hello" example again, consider this image build using Buildah commands:
```
#!/usr/bin/env bash
set -o errexit
# Create a container
container=$(buildah from fedora:28)
# Labels are part of the "buildah config" command
buildah config --label maintainer="Chris Collins <collins.christopher@gmail.com>" $container
# Grab the source code outside of the container
curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz -o hello-2.10.tar.gz
buildah copy $container hello-2.10.tar.gz /tmp/hello-2.10.tar.gz
buildah run $container dnf install -y tar gzip gcc make
Buildah run $container dnf clean all
buildah run $container tar xvzf /tmp/hello-2.10.tar.gz -C /opt
# Workingdir is also a "buildah config" command
buildah config --workingdir /opt/hello-2.10 $container
buildah run $container ./configure
buildah run $container make
buildah run $container make install
buildah run $container hello -v
# Entrypoint, too, is a “buildah config” command
buildah config --entrypoint /usr/local/bin/hello $container
# Finally saves the running container to an image
buildah commit --format docker $container hello:latest
```
One thing that should be immediately obvious is the fact that this is a Bash script rather than a Dockerfile. Using Buildah’s native commands makes it easy to script, in whatever language or automation context you like to use. This could be a makefile, a Python script, or whatever tools you like to use.
So what is going on here? The first Buildah command `container=$(buildah from fedora:28)`, creates a running container from the fedora:28 image, and stores the container name (the output of the command) as a variable for later use. All the rest of the Buildah commands use the `$container` variable to say what container to act upon. For the most part those commands are self-explanatory: `buildah copy` moves a file into the container, `buildah run` executes a command in the container. It is easy to match them to their Dockerfile equivalents.
The final command, `buildah commit`, commits the container to an image on disk. When building images with Buildah commands rather than from a Dockerfile, you can use the `commit` command to decide when to save your changes. In the example above, all of the changes are committed at once, but intermediate commits could be included too, allowing you to choose cache points from which to start. (For example, it would be particularly useful to cache to disk after the `dnf install`, as that can take a long time, but is also reliably the same each time.)
### Mountpoints, install directories, and chroots
Another useful Buildah command opens the door to a lot of flexibility in building images. `buildah mount` mounts the root directory of a container to a mountpoint on your host. For example:
```
[chris@krang] $ container=$(sudo buildah from fedora:28)
[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ echo $mountpoint
/var/lib/containers/storage/overlay2/463eda71ec74713d8cebbe41ee07da5f6df41c636f65139a7bd17b24a0e845e3/merged
[chris@krang] $ cat ${mountpoint}/etc/redhat-release
Fedora release 28 (Twenty Eight)
[chris@krang] $ ls ${mountpoint}
bin   dev  home  lib64          media  opt   root  sbin  sys  usr
boot  etc  lib   lost+found  mnt        proc  run   srv   tmp  var
```
This is great because now you can interact with the mountpoint to make changes to your container image. This allows you to use tools on your host to build and install software, rather than including those tools in the container image itself. For example, in the Bash script above, we needed to install the tar, Gzip, GCC, and make packages to compile "GNU Hello" inside the container. Using a mountpoint, we can build an image with the same software, but the downloaded tarball and tar, Gzip, etc., RPMs are all on the host machine rather than in the container and resulting image:
```
#!/usr/bin/env bash
set -o errexit
# Create a container
container=$(buildah from fedora:28)
mountpoint=$(buildah mount $container)
buildah config --label maintainer="Chris Collins <collins.christopher@gmail.com>" $container
curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz \
     -o /tmp/hello-2.10.tar.gz
tar xvzf src/hello-2.10.tar.gz -C ${mountpoint}/opt
pushd ${mountpoint}/opt/hello-2.10
./configure
make
make install DESTDIR=${mountpoint}
popd
chroot $mountpoint bash -c "/usr/local/bin/hello -v"
buildah config --entrypoint "/usr/local/bin/hello" $container
buildah commit --format docker $container hello
buildah unmount $container
```
Take note of a few things in the script above:
1. The `curl` command downloads the tarball to the host, not the image
2. The `tar` command (running from the host itself) extracts the source code from the tarball into `/opt` inside the container.
3. `Configure`, `make`, and `make install` are all running from a directory inside the mountpoint, mounted to the host rather than running inside the container itself.
4. The `chroot` command here is used to change root into the mountpoint itself and test that "hello" is working, similar to the `buildah run` command used in the previous example.
This script is shorter, it uses tools most Linux folks are already familiar with, and the resulting image is smaller (no tarball, no extra packages, etc). You could even use the package manager for the host system to install software into the container. For example, let’s say you wanted to install [NGINX][5] into the container with GNU Hello (for whatever reason):
```
[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ sudo dnf install nginx --installroot $mountpoint
[chris@krang] $ sudo chroot $mountpoint nginx -v
nginx version: nginx/1.12.1
```
In the example above, DNF is used with the `--installroot` flag to install NGINX into the container, which can be verified with chroot.
### Try it out!
Buildah is a lightweight and flexible way to create container images without running a full Docker daemon on your host. In addition to offering out-of-the-box support for building from Dockerfiles, Buildah is easy to use with scripts or build tools of your choice and can help build container images using existing tools on the build host. The result is leaner images that use less bandwidth to ship around, require less storage space, and have a smaller surface area for potential attackers. Give it a try!
**[See our related story,[Creating small containers with Buildah][6]]**
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/6/getting-started-buildah
作者：[Chris Collins][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/clcollins
[1]:https://github.com/projectatomic/buildah
[2]:https://www.opencontainers.org/
[3]:http://chris.collins.is/2017/08/17/buildah-a-new-way-to-build-container-images/
[4]:http://cri-o.io/
[5]:https://www.nginx.com/
[6]:https://opensource.com/article/18/5/containers-buildah

2
sources/tech/20180618 5 open source alternatives to Dropbox.md
View File

@ -1,3 +1,5 @@
**Translating by distant1219**
5 open source alternatives to Dropbox
======

79
sources/tech/20180626 TrueOS Doesnt Want to Be BSD for Desktop Anymore.md
View File

@ -1,79 +0,0 @@
translating---geekpi
TrueOS Doesn’t Want to Be ‘BSD for Desktop’ Anymore
============================================================
There are some really big changes on the horizon for [TrueOS][9]. Today, we will take a look at what is going on in the world of desktop BSD.
### The Announcement
![TrueOS: Core Operating System BSD](https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/06/true-os-bsd-desktop.jpeg)
The team behind [TrueOS][10] [announced][11] that they would be changing the focus of the project. Up until this point, TrueOS has made it easy to install BSD with a graphical user interface out of the box. However, it will now become “a cutting-edge operating system that keeps all of the stability that you know and love from ZFS ([OpenZFS][12]) and [FreeBSD][13], and adds additional features to create a fresh, innovative operating system. Our goal is to create a core-centric operating system that is modular, functional, and perfect for do-it-yourselfers and advanced users alike.”
Essentially, TrueOs will become a downstream fork of FreeBSD. They will integrate newer software into the system, such as [OpenRC][14] and [LibreSSL][15]. They hope to stick to a 6-month release cycle.
The goal is to make TrueOS so it can be used as the base for other projects to build on. The graphical part will be missing to make it more distro-agnostic.
[Suggested readInterview with MidnightBSD Founder and Lead Dev Lucas Holt][16]
### What about Desktop Users?
If you read my [review of TrueOS][17] and are interested in trying a desktop BSD or already use TrueOS, never fear (which is good advice for life too). All of the desktop elements of TrueOS will be spun off into [Project Trident][18]. Currently, the Project Trident website is very light on details. It seems as though they are still figuring out the logistics of the spin-off.
If you currently have TrueOS, you don’t have to worry about moving. The TrueOS team said that “there will be migration paths available for those that would like to move to other FreeBSD-based distributions like Project Trident or [GhostBSD][19].”
[Suggested readInterview with FreeDOS Founder and Lead Dev Jim Hall][20]
### Thoughts
When I first read the announcement, I was frankly a little worried. Changing names can be a bad idea. Customers will be used to one name, but if the product name changes they could lose track of the project very easily. TrueOS already went through a name change. When the project was started in 2006 it was named PC-BSD, but in 2016 the name was changed to TrueOS. It kinds of reminds me of the [ArchMerge and Arcolinux saga][21].
That being said, I think this will be a good thing for desktop users of BSD. One of the common criticisms that I heard about PC-BSD and TrueOS is that it wasn’t very polished. Separating the two parts of the project will help sharpen the focus of the respective developers. The TrueOS team will be able to add newer features to the slow-moving FreeBSD base and the Project Trident team will be able to improve user’s desktop experience.
I wish both teams well. Remember, people, when someone works on open source, we all benefit even if the work is done on something we don’t use.
What are your thoughts about the future of TrueOS and Project Trident? Please let us know in the comments below.
------------------------------
关于作者：
My name is John Paul Wohlscheid. I'm an aspiring mystery writer who loves to play with technology, especially Linux. You can catch up with me at [my personal website][23]
--------------------------------------------------------------------------------
via: https://itsfoss.com/trueos-plan-change/
作者：[John Paul Wohlscheid ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://itsfoss.com/author/john/
[1]:https://itsfoss.com/author/john/
[2]:https://itsfoss.com/trueos-plan-change/#comments
[3]:https://itsfoss.com/category/bsd/
[4]:https://itsfoss.com/category/news/
[5]:https://itsfoss.com/tag/bsd/
[6]:https://itsfoss.com/tag/freebsd/
[7]:https://itsfoss.com/tag/project-trident/
[8]:https://itsfoss.com/tag/trueos/
[9]:https://www.trueos.org/
[10]:https://www.trueos.org/
[11]:https://www.trueos.org/blog/trueosdownstream/
[12]:http://open-zfs.org/wiki/Main_Page
[13]:https://www.freebsd.org/
[14]:https://en.wikipedia.org/wiki/OpenRC
[15]:http://www.libressl.org/
[16]:https://itsfoss.com/midnightbsd-founder-lucas-holt/
[17]:https://itsfoss.com/trueos-bsd-review/
[18]:http://www.project-trident.org/
[19]:https://www.ghostbsd.org/
[20]:https://itsfoss.com/interview-freedos-jim-hall/
[21]:https://itsfoss.com/archlabs-vs-archmerge/
[22]:http://reddit.com/r/linuxusersgroup
[23]:http://johnpaulwohlscheid.work/

2
sources/tech/20180706 6 RFCs for understanding how the internet works.md
View File

@ -1,3 +1,5 @@
translating---geekpi
6 RFCs for understanding how the internet works
======

222
translated/tech/20180606 Getting started with Buildah.md Normal file
View File

@ -0,0 +1,222 @@
Buildah 入门
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/blocks_building.png?itok=eMOT-ire)
[Buildah][1] 是一个命令行工具，可以方便、快捷的构建与[<ruby>开放容器标准<rt>Open Container Initiative, OCI</rt></ruby>][2]兼容的容器镜像，意味着构建的镜像也与 Docker 和 Kubernetes 兼容。该工具可作为 Docker 守护进程 `docker build` 命令（即使用传统的 Dockerfile 构建镜像）的一种<ruby>简单<rt>drop-in</rt></ruby>替换，而且更加灵活，允许构建镜像时使用你擅长的工具。Buildah 可以轻松与脚本集成并生成<ruby>流水线<rt>pipelines</rt></ruby>，最好之处在于构建镜像不再需要运行容器守护进程（LCTT 译注：这里主要是指 Docker 守护进程）。
### docker build 的简单替换
目前你可能使用 Dockerfile 和 `docker build` 命令构建镜像，那么你可以马上使用 Buildah 进行替代。Buildah 的 `build-using-dockerfile` 或 `bud` 子命令与 `docker build` 基本等价，因此可以轻松的与已有脚本结合或构建流水线。
类似我的上一篇关于 Buildah 的[文章][3]，我也将以使用源码安装 "GNU Hello" 为例进行说明，对应的 Dockerfile 文件如下：
```
FROM fedora:28
LABEL maintainer Chris Collins <collins.christopher@gmail.com>
RUN dnf install -y tar gzip gcc make \
        && dnf clean all
ADD http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz /tmp/hello-2.10.tar.gz
RUN tar xvzf /tmp/hello-2.10.tar.gz -C /opt
WORKDIR /opt/hello-2.10
RUN ./configure
RUN make
RUN make install
RUN hello -v
ENTRYPOINT "/usr/local/bin/hello"
```
使用 Buildah 从 Dockerfile 构建镜像也很简单，使用 `buildah bud -t hello .` 替换 `docker build -t hello .` 即可：
```
[chris@krang] $ sudo buildah bud -t hello .
STEP 1: FROM fedora:28
Getting image source signatures
Copying blob sha256:e06fd16225608e5b92ebe226185edb7422c3f581755deadf1312c6b14041fe73
 81.48 MiB / 81.48 MiB [====================================================] 8s
Copying config sha256:30190780b56e33521971b0213810005a69051d720b73154c6e473c1a07ebd609
 2.29 KiB / 2.29 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
STEP 2: LABEL maintainer Chris Collins <collins.christopher@gmail.com>
STEP 3: RUN dnf install -y tar gzip gcc make    && dnf clean all
<考虑篇幅，略去后续输出>
```
镜像构建完毕后，可以使用 `buildah images` 命令查看这个新镜像：
```
[chris@krang] $ sudo buildah images
IMAGE ID        IMAGE NAME                              CREATED AT              SIZE
30190780b56e    docker.io/library/fedora:28             Mar 7, 2018 16:53       247 MB
6d54bef73e63    docker.io/library/hello:latest    May 3, 2018 15:24     391.8 MB
```
新镜像的标签为 `hello:latest`，我们可以将其推送至远程镜像仓库，可以使用 [CRI-O][4] 或其它 Kubernetes CRI 兼容的运行时运行该镜像，也可以推送到远程仓库。如果你要测试对 Docker build 命令的替代性，你可以将镜像拷贝至 docker 守护进程的本地镜像存储中，这样 Docker 也可以使用该镜像。使用 `buildah push` 可以很容易的完成推送操作：
```
[chris@krang] $ sudo buildah push hello:latest docker-daemon:hello:latest
Getting image source signatures
Copying blob sha256:72fcdba8cff9f105a61370d930d7f184702eeea634ac986da0105d8422a17028
 247.02 MiB / 247.02 MiB [==================================================] 2s
Copying blob sha256:e567905cf805891b514af250400cc75db3cb47d61219750e0db047c5308bd916
 144.75 MiB / 144.75 MiB [==================================================] 1s
Copying config sha256:6d54bef73e638f2e2dd8b7bf1c4dfa26e7ed1188f1113ee787893e23151ff3ff
 1.59 KiB / 1.59 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
[chris@krang] $ sudo docker images | head -n2
REPOSITORY              TAG             IMAGE ID        CREATED                 SIZE
docker.io/hello      latest       6d54bef73e63  2 minutes ago   398 MB
[chris@krang] $ sudo docker run -t hello:latest
Hello, world!
```
### 若干差异
与 Docker build 不同，Buildah 不会自动的将 Dockerfile 中的每条指令产生的变更提到到新的<ruby>分层<rt>layer</rt></ruby>中，只是简单的每次从头到尾执行构建。类似于<ruby>自动化<rt>automation</rt></ruby>和<ruby>流水线构建<rt>build pipelines</rt></ruby>，这种<ruby>无缓存构建<rt>non-cached</rt></ruby>方式的好处是可以提高构建速度，在指令较多时尤为明显。从<ruby>自动部署<rt>automated deployment</rt></ruby>或<ruby>持续交付<rt>continuous delivery</rt></ruby>的视角来看，使用这种方式可以快速的将新变更落实到生产环境中。
但从实际角度出发，缓存机制的缺乏对镜像开发不利，毕竟缓存层可以避免一遍遍的执行构建，从而显著的节省时间。自动分层只在 `build-using-dockerfile` 命令中生效。但我们在下面会看到，Buildah 原生命令允许我们选择将变更提交到硬盘的时间，提高了开发的灵活性。
### Buildah 原生命令
Buildah _真正_ 有趣之处在于它的原生命令，你可以在容器构建过程中使用这些命令进行交互。相比与使用 `build-using-dockerfile/bud` 命令执行每次构建，Buildah 提供命令让你可以与构建过程中的临时容器进行交互。（Docker 也使用临时或<ruby> _中间_ <rt>intermediate</rt></ruby>容器，但你无法在镜像构建过程中与其交互。）
还是使用 "GNU Hello" 为例，考虑使用如下 Buildah 命令构建的镜像：
```
#!/usr/bin/env bash
set -o errexit
# Create a container
container=$(buildah from fedora:28)
# Labels are part of the "buildah config" command
buildah config --label maintainer="Chris Collins <collins.christopher@gmail.com>" $container
# Grab the source code outside of the container
curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz -o hello-2.10.tar.gz
buildah copy $container hello-2.10.tar.gz /tmp/hello-2.10.tar.gz
buildah run $container dnf install -y tar gzip gcc make
buildah run $container dnf clean all
buildah run $container tar xvzf /tmp/hello-2.10.tar.gz -C /opt
# Workingdir is also a "buildah config" command
buildah config --workingdir /opt/hello-2.10 $container
buildah run $container ./configure
buildah run $container make
buildah run $container make install
buildah run $container hello -v
# Entrypoint, too, is a “buildah config” command
buildah config --entrypoint /usr/local/bin/hello $container
# Finally saves the running container to an image
buildah commit --format docker $container hello:latest
```
我们可以一眼看出这是一个 Bash 脚本而不是 Dockerfile。基于 Buildah 的原生命令，可以轻易的使用任何脚本语言或你擅长的自动化工具编写脚本。形式可以是 makefile、Python 脚本或其它你擅长的类型。
这个脚本做了哪些工作呢？首先，Buildah 命令 `container=$(buildah from fedora:28)` 基于 fedora:28 镜像创建了一个正在运行的容器，将容器名（buildah from 命令的返回值）保存到变量中，便于后续使用。后续所有命令都是有 $container 变量指明需要操作的容器。这些命令的功能大多可以从名称看出：`buildah copy` 将文件拷贝至容器，`buildah run` 会在容器中执行命令。可以很容易的将上述命令与 Dockerfile 中的指令对应起来。
最后一条命令 `buildah commit` 将容器提交到硬盘上的镜像中。当不使用 Dockerfile 而是使用 Buildah 命令构建镜像时，你可以使用 `commit` 命令决定何时保存变更。在上例中，所有的变更是一起提交的；但也可以增加中间提交，让你可以选择作为起点的<ruby>缓存点<rt>cache points</rt></ruby>。（例如，执行完 `dnf install` 命令后将变更缓存到硬盘是特别有意义的，一方面因为该操作耗时较长，另一方面每次执行的结果也确实相同。）
### 挂载点，安装目录以及 chroot
另一个可以大大增加构建镜像灵活性的 Buildah 命令是 `buildah mount`，可以将容器的根目录挂载到你主机的一个挂载点上。例如：
```
[chris@krang] $ container=$(sudo buildah from fedora:28)
[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ echo $mountpoint
/var/lib/containers/storage/overlay2/463eda71ec74713d8cebbe41ee07da5f6df41c636f65139a7bd17b24a0e845e3/merged
[chris@krang] $ cat ${mountpoint}/etc/redhat-release
Fedora release 28 (Twenty Eight)
[chris@krang] $ ls ${mountpoint}
bin   dev  home  lib64          media  opt   root  sbin  sys  usr
boot  etc  lib   lost+found  mnt        proc  run   srv   tmp  var
```
这太棒了，你可以通过挂载点交互对容器镜像进行修改。这允许你使用主机上的工具进行构建和安装软件，不用将这些构建工具打包到容器镜像本身中。例如，在我们上面的 Bash 脚本中，我们需要安装 tar、Gzip、GCC 和 make，在容器内编译 "GNU Hello"。如果使用挂载点，我仍使用同样的工具进行构建，但下载的压缩包和 tar、Gzip 等 RPM 包都在主机而不是容器和生成的镜像内：
```
#!/usr/bin/env bash
set -o errexit
# Create a container
container=$(buildah from fedora:28)
mountpoint=$(buildah mount $container)
buildah config --label maintainer="Chris Collins <collins.christopher@gmail.com>" $container
curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz \
     -o /tmp/hello-2.10.tar.gz
tar xvzf src/hello-2.10.tar.gz -C ${mountpoint}/opt
pushd ${mountpoint}/opt/hello-2.10
./configure
make
make install DESTDIR=${mountpoint}
popd
chroot $mountpoint bash -c "/usr/local/bin/hello -v"
buildah config --entrypoint "/usr/local/bin/hello" $container
buildah commit --format docker $container hello
buildah unmount $container
```
在上述脚本中，需要提到如下几点：
1. `curl` 命令将压缩包下载到主机中，而不是镜像中；
2. （主机中的） `tar` 命令将压缩包中的源代码解压到容器的 `/opt` 目录；
3. `configure`，`make` 和 `make install` 命令都在主机的挂载点目录中执行，而不是在容器内；
4. 这里的 `chroot` 命令用于将挂载点本身当作根路径并测试 "hello" 是否正常工作；类似于前面例子中用到的 `buildah run` 命令。
这个脚本更加短小，使用大多数 Linux 爱好者都很熟悉的工具，最后生成的镜像也更小（没有压缩包，没有额外的软件包等）。你甚至可以使用主机系统上的包管理器为容器安装软件。例如，（出于某种原因）你希望安装 GNU Hello 的同时在容器中安装 [NGINX][5]：
```
[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ sudo dnf install nginx --installroot $mountpoint
[chris@krang] $ sudo chroot $mountpoint nginx -v
nginx version: nginx/1.12.1
```
在上面的例子中，DNF 使用 `--installroot` 参数将 NGINX 安装到容器中，可以通过 chroot 进行校验。
### 快来试试吧！
Buildah 是一种轻量级、灵活的容器镜像构建方法，不需要在主机上运行完整的 Docker 守护进程。除了提供基于 Dockerfiles 构建容器的开箱即用支持，Buildah 还可以很容易的与脚本或你喜欢的构建工具相结合，特别是可以使用主机上已有的工具构建容器镜像。Buildah 生成的容器体积更小，更便于网络传输，占用更小的存储空间，而且潜在的受攻击面更小。快来试试吧！
**[阅读相关的故事，[使用 Buildah 创建小体积容器][6]]**
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/6/getting-started-buildah
作者：[Chris Collins][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/clcollins
[1]:https://github.com/projectatomic/buildah
[2]:https://www.opencontainers.org/
[3]:http://chris.collins.is/2017/08/17/buildah-a-new-way-to-build-container-images/
[4]:http://cri-o.io/
[5]:https://www.nginx.com/
[6]:https://opensource.com/article/18/5/containers-buildah

77
translated/tech/20180626 TrueOS Doesnt Want to Be BSD for Desktop Anymore.md Normal file
View File

@ -0,0 +1,77 @@
TrueOS 不再想要成为“桌面 BSD”了
============================================================
[TrueOS][9] 很快会有一些非常重大的变化。今天，我们将了解桌面 BSD 将会发生什么。
### 通告
![TrueOS: Core Operating System BSD](https://4bds6hergc-flywheel.netdna-ssl.com/wp-content/uploads/2018/06/true-os-bsd-desktop.jpeg)
[TrueOS][10] 背后的团队[宣布][11]，他们将改变项目的重点。到目前为止，TrueOS 使用开箱即用的图形用户界面来轻松安装 BSD。然而，它现在将成为“一个先进的操作系统，保留你所知道和喜欢 ZFS（[OpenZFS][12]）和 [FreeBSD][13]的所有稳定性，并添加额外的功能来创造一个全新的、创新的操作系统。我们的目标是创建一个中心操作系统，该系统具有模块化、功能性，非常适合自己动手和高级用户。“
从本质上讲，TrueOs 将成为 FreeBSD 的下游分支。他们将更新的软件集成到系统中，例如 [OpenRC][14] 和 [LibreSSL][15]。他们希望坚持 6 个月的发布周期。
目标是使 TrueOS 成为可以作为其他项目构建的基础。缺少图形部分以使其更加发行无关。
[建议阅读有关 MidnightBSD 创始人兼首席开发人员 Lucas Holt 的访谈][16]
### 桌面用户如何？
如果你读过我的[TrueOS 评论][17]并且有兴趣尝试使用桌面 BSD 或已经使用 TrueOS，请不要担心（这对于生活来说也是一个很好的建议）。TrueOS 的所有桌面元素都将剥离到 [Project Trident][18]。目前，Project Trident 网站的细节不多。他们仿佛还在进行剥离的幕后工作。
如果你目前拥有 TrueOS，则无需担心迁移。TrueOS 团队表示，“对于那些希望迁移到其他基于 FreeBSD 的发行版，如 Project Trident 或 [GhostBSD][19] 的人而言将会有迁移方式。”
[建议阅读有关 FreeDOS 创始人及开发领导 Lucas Holt 的访谈][16]
### 想法
当我第一次阅读公告时，坦率地说有点担心。改变名字可能是一个坏主意。客户将习惯使用一个名称，但如果产品名称发生变化，他们可能很容易失去对项目的跟踪。TrueOS 经历过名称更改。该项目于 2006 年启动时，它被命名为 PC-BSD，但在 2016 年，名称更改为 TrueOS。它让我想起了[ArchMerge 和 Arcolinux 传奇][21]。
话虽这么说，我认为这对 BSD 的桌面用户来说是一件好事。我听见 PC-BSD 和 TrueOS 的一个常见批评是它不是很精致。剥离项目的两个部分将有助于提高相关开发人员的关注度。TrueOS 团队将能够为缓慢进展的 FreeBSD 添加更新的功能，Project Trident 团队将能够改善用户的桌面体验。
我希望两个团队都好。请记住，当有人在开源上工作时，即使是我们不会使用的工作时，我们也都会受益。
你对 TrueOS 和 Project Trident 的未来有何看法？请在下面的评论中告诉我们。
------------------------------
关于作者：
我叫 John Paul Wohlscheid。我是一个有抱负的神秘作家，喜欢玩技术，尤其是 Linux。你可以在[我的个人网站][23]关注我。
--------------------------------------------------------------------------------
via: https://itsfoss.com/trueos-plan-change/
作者：[John Paul Wohlscheid ][a]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://itsfoss.com/author/john/
[1]:https://itsfoss.com/author/john/
[2]:https://itsfoss.com/trueos-plan-change/#comments
[3]:https://itsfoss.com/category/bsd/
[4]:https://itsfoss.com/category/news/
[5]:https://itsfoss.com/tag/bsd/
[6]:https://itsfoss.com/tag/freebsd/
[7]:https://itsfoss.com/tag/project-trident/
[8]:https://itsfoss.com/tag/trueos/
[9]:https://www.trueos.org/
[10]:https://www.trueos.org/
[11]:https://www.trueos.org/blog/trueosdownstream/
[12]:http://open-zfs.org/wiki/Main_Page
[13]:https://www.freebsd.org/
[14]:https://en.wikipedia.org/wiki/OpenRC
[15]:http://www.libressl.org/
[16]:https://itsfoss.com/midnightbsd-founder-lucas-holt/
[17]:https://itsfoss.com/trueos-bsd-review/
[18]:http://www.project-trident.org/
[19]:https://www.ghostbsd.org/
[20]:https://itsfoss.com/interview-freedos-jim-hall/
[21]:https://itsfoss.com/archlabs-vs-archmerge/
[22]:http://reddit.com/r/linuxusersgroup
[23]:http://johnpaulwohlscheid.work/