2016年6月

在 Linux 分发应用不总是那么容易。有各种不同的包格式、基础系统、可用库,随着发行版的一次次发布,所有的这些都让人头疼。然而,现在我们有了更简单的东西:Snap。

Snap 是开发者打包他们应用的新途径,它相对于传统包格式,如 .deb,.rpm 等带来了许多优点。Snap 安全,彼此隔离,宿主系统使用了类似 AppArmor 的技术,它们跨平台且自足的,让开发者可以准确地将应用所需要的依赖打包到一起。沙盒隔离也加强了安全,并允许应用和整个基于 snap 的系统,在出现问题的时候可以回滚。Snap 确实是 Linux 应用打包的未来。

创建一个 snap 包并不困难。首先,你需要一个 snap 基础运行环境,能够让你的桌面环境认识并运行 snap 软件包,这个工具叫做 snapd ,默认内置于所有 Ubuntu 16.04 系统中。接着你需要创建 snap 的工具 Snapcraft,它可以通过一个简单的命令安装:

$ sudo apt-get install snapcraft

这个环境安装好了之后就可以 snap 起来了。

Snap 使用一个特定的 YAML 格式的文件 snapcraft.yaml,它定义了应用是如何打包的以及它需要的依赖。用一个简单的应用来演示一下,下面的 YAML 文件是个如何 snap 一个 moon-buggy 游戏的实际例子,该游戏在 Ubuntu 源中提供。

name: moon-buggy
version: 1.0.51.11
summary: Drive a car across the moon
description: |
A simple command-line game where you drive a buggy on the moon
apps:
  play:
    command: usr/games/moon-buggy
parts:
  moon-buggy:
    plugin: nil
    stage-packages: [moon-buggy]
    snap:
      – usr/games/moon-buggy

上面的代码出现了几个新概念。第一部分是关于如何让你的应用可以在商店找到的信息,设置软件包的元数据名称、版本号、摘要、以及描述。apps 部分实现了 play 命令,指向了 moon-buggy 可执行文件位置。parts 部分告诉 snapcraft 用来构建应用所需要的插件以及依赖的包。在这个简单的例子中我们需要的所有东西就是来自 Ubuntu 源中的 moon-buggy 应用本身,snapcraft 负责剩下的工作。

在你的 snapcraft.yaml 所在目录下运行 snapcraft ,它会创建 moon-buggy1.0.51.11amd64.snap 包,可以通过以下命令来安装它:

$ snap install moon-buggy_1.0.51.11_amd64.snap

想了解更复杂一点的 snap 打包操作,比如基于 Electron 的 Simplenote 可以看这里,在线教程在这里,相应的代码在 Github。更多的例子可以在 Ubuntu 开发者站点找到。


via: https://insights.ubuntu.com/2016/06/01/apps-to-snaps/

作者:Jamie 译者:alim0x 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

今日关注

期待已久的代号为“Sarah”的 Linux Mint 18 发布 beta 版本。正式版本将于下个月发布。Linux Mint 18 有两个版本,Cinnamon 和 MATE 版本。

Cinnamon 版本采用 Cinnamon 3.0 桌面环境,基于流行的 Arc GTK 和 Moka 的 Mint-Y 主题定制。搭载 Linux 4.4 系列内核,基于 Ubuntu 16.04 LTS (Xenial Xerus) 操作系统,继承了其大部分的核心组件和软件应用。其中预安装的应用有 Mozilla Firefox 46.0, Mozilla Thunderbird 38.7.2 邮件和新闻客户端, LibreOffice 5.1.2 办公套件, Transmission 2.84 BitTorrent 客户端, Pidgin 2.10.12 IM 客户端, HexChat 2.10.2 IRC 客户端, 和 GIMP 2.8.16 图像编辑器。

MATE 版本采用最新的 MATE 1.14.1 桌面环境,跟 Cinnamon 版本一样,也是搭载了 Linux 4.4 内核,继承了 Ubuntu 16.04 LTS (Xenial Xerus) 的许多核心组件。不过这个版本有自己的一些软件应用集合,比如 Mozilla Firefox 46.0, Mozilla Thunderbird 38.7.2, Pidgin 2.10.12 IM 客户端, Banshee 2.6.2, LibreOffice 5.1.2, GIMP 2.8.16, Transmission 2.84, HexChat 2.10.2, 和 Synaptic Package Manger 0.83。

目前这两个类型的beta版本都可以从官网进行下载了。不过记得这只是预发行版本,还不是正式版本,不要急着用于生产环境。

新闻摘要

  • 未来的一些 Ubuntu 智能手机的 OTA 升级可能会实现生物识别功能。上周 OTA-11 更新发布,那么接下来的 OTA-12 中,就有可能会实现生物识别功能。敬请期待。
  • PCLinuxOS 64 2016.06 Xfce 社区版发布,采用轻量级的 Xfce 4.12 桌面环境,搭载 Linux 内核 4.4.11 LTS。这一新版本的系统支持新的操作快捷键,并且可以对重启、挂起、关机这样的系统操作进行快捷键绑定。目前已经可以从官网进行下载体验了。
  • Wireshark 2.0.4 发布。这一版本修复了若干安全漏洞和 bug,比如闪退的问题。同时也更新了对内置的像 IPv4, IEEE 802.11, ICMPv6, Ethernet, NFS, AFS 等协议的支持。目前已经可以下载体验了。
  • Mesa 12.0.0 3D 图像库第二个候选版本发布,开始进行公测。这一候选版本对60个问题进行了修复,值得一提的是对 Intel i965 video 驱动的改善。第三个候选版本预计下周发布。
  • Samba 4.4.4 发布,修复了共享模式锁定下的内存泄露问题,提供了对 systemd 230 的支持。

这篇文章包含 Docker 的基本概念,以及如何通过创建一个定制的 Dockerfile 来 Docker 化 Dockerize 一个应用。

Docker 是一个过去两年来从某个 idea 中孕育而生的有趣技术,公司组织们用它在世界上每个角落来部署应用。在今天的文章中,我将讲述如何通过“ Docker 化 Dockerize ”一个现有的应用,来开始我们的 Docker 之旅。这里提到的应用指的就是这个博客!

什么是 Docker?

当我们开始学习 Docker 基本概念时,让我们先去搞清楚什么是 Docker 以及它为什么这么流行。Docker 是一个操作系统容器管理工具,它通过将应用打包在操作系统容器中,来方便我们管理和部署应用。

容器 vs. 虚拟机

容器和虚拟机并不完全相似,它是另外一种提供操作系统虚拟化的方式。它和标准的虚拟机还是有所不同。

标准的虚拟机一般会包括一个完整的操作系统、操作系统软件包、最后还有一至两个应用。这都得益于为虚拟机提供硬件虚拟化的管理程序。这样一来,一个单一的服务器就可以将许多独立的操作系统作为虚拟客户机运行了。

容器和虚拟机很相似,它们都支持在单一的服务器上运行多个操作环境,只是,在容器中,这些环境并不是一个个完整的操作系统。容器一般只包含必要的操作系统软件包和一些应用。它们通常不会包含一个完整的操作系统或者硬件的虚拟化。这也意味着容器比传统的虚拟机开销更少。

容器和虚拟机常被误认为是两种对立的技术。虚拟机采用一个物理服务器来提供全功能的操作环境,该环境会和其余虚拟机一起共享这些物理资源。容器一般用来隔离一个单一主机上运行的应用进程,以保证隔离后的进程之间不能相互影响。事实上,容器和 BSD Jails 以及 chroot 进程的相似度,超过了和完整虚拟机的相似度。

Docker 在容器之上提供了什么

Docker 本身不是一个容器运行环境,事实上,只是一个与具体实现无关的容器技术,Docker 正在努力支持 Solaris ZonesBSD Jails。Docker 提供了一种管理、打包和部署容器的方式。虽然一定程度上,虚拟机多多少少拥有这些类似的功能,但虚拟机并没有完整拥有绝大多数的容器功能,即使拥有,这些功能用起来都并没有 Docker 来的方便或那么完整。

现在,我们应该知道 Docker 是什么了,然后,我们将从安装 Docker,并部署一个公开的预构建好的容器开始,学习 Docker 是如何工作的。

从安装开始

默认情况下,Docker 并不会自动被安装在您的计算机中,所以,第一步就是安装 Docker 软件包;我们的教学机器系统是 Ubuntu 14.0.4,所以,我们将使用 Apt 软件包管理器,来执行安装操作。

# apt-get install docker.io
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  aufs-tools cgroup-lite git git-man liberror-perl
Suggested packages:
  btrfs-tools debootstrap lxc rinse git-daemon-run git-daemon-sysvinit git-doc
  git-el git-email git-gui gitk gitweb git-arch git-bzr git-cvs git-mediawiki
  git-svn
The following NEW packages will be installed:
  aufs-tools cgroup-lite docker.io git git-man liberror-perl
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 7,553 kB of archives.
After this operation, 46.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y

为了检查当前是否有容器运行,我们可以执行docker命令,加上ps选项

# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

docker命令中的ps功能类似于 Linux 的ps命令。它将显示可找到的 Docker 容器及其状态。由于我们并没有启动任何 Docker 容器,所以命令没有显示任何正在运行的容器。

部署一个预构建好的 nginx Docker 容器

我比较喜欢的 Docker 特性之一就是 Docker 部署预先构建好的容器的方式,就像yumapt-get部署包一样。为了更好地解释,我们来部署一个运行着 nginx web 服务器的预构建容器。我们可以继续使用docker命令,这次选择run选项。

# docker run -d nginx
Unable to find image 'nginx' locally
Pulling repository nginx
5c82215b03d1: Download complete 
e2a4fb18da48: Download complete 
58016a5acc80: Download complete 
657abfa43d82: Download complete 
dcb2fe003d16: Download complete 
c79a417d7c6f: Download complete 
abb90243122c: Download complete 
d6137c9e2964: Download complete 
85e566ddc7ef: Download complete 
69f100eb42b5: Download complete 
cd720b803060: Download complete 
7cc81e9a118a: Download complete 

docker命令的run选项,用来通知 Docker 去寻找一个指定的 Docker 镜像,然后启动运行着该镜像的容器。默认情况下,Docker 容器运行在前台,这意味着当你运行docker run命令的时候,你的 shell 会被绑定到容器的控制台以及运行在容器中的进程。为了能在后台运行该 Docker 容器,我们使用了-d (detach)标志。

再次运行docker ps命令,可以看到 nginx 容器正在运行。

# docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
f6d31ab01fc9        nginx:latest        nginx -g 'daemon off   4 seconds ago       Up 3 seconds        443/tcp, 80/tcp     desperate_lalande 

从上面的输出信息中,我们可以看到正在运行的名为desperate_lalande的容器,它是由nginx:latest image(LCTT 译注: nginx 最新版本的镜像)构建而来得。

Docker 镜像

镜像是 Docker 的核心特征之一,类似于虚拟机镜像。和虚拟机镜像一样,Docker 镜像是一个被保存并打包的容器。当然,Docker 不只是创建镜像,它还可以通过 Docker 仓库发布这些镜像,Docker 仓库和软件包仓库的概念差不多,它让 Docker 能够模仿yum部署软件包的方式来部署镜像。为了更好地理解这是怎么工作的,我们来回顾docker run执行后的输出。

# docker run -d nginx
Unable to find image 'nginx' locally

我们可以看到第一条信息是,Docker 不能在本地找到名叫 nginx 的镜像。这是因为当我们执行docker run命令时,告诉 Docker 运行一个基于 nginx 镜像的容器。既然 Docker 要启动一个基于特定镜像的容器,那么 Docker 首先需要找到那个指定镜像。在检查远程仓库之前,Docker 首先检查本地是否存在指定名称的本地镜像。

因为系统是崭新的,不存在 nginx 镜像,Docker 将选择从 Docker 仓库下载之。

Pulling repository nginx
5c82215b03d1: Download complete 
e2a4fb18da48: Download complete 
58016a5acc80: Download complete 
657abfa43d82: Download complete 
dcb2fe003d16: Download complete 
c79a417d7c6f: Download complete 
abb90243122c: Download complete 
d6137c9e2964: Download complete 
85e566ddc7ef: Download complete 
69f100eb42b5: Download complete 
cd720b803060: Download complete 
7cc81e9a118a: Download complete 

这就是第二部分输出信息显示给我们的内容。默认情况下,Docker 会使用 Docker Hub 仓库,该仓库由 Docker 公司维护。

和 Github 一样,在 Docker Hub 创建公共仓库是免费的,私人仓库就需要缴纳费用了。当然,部署你自己的 Docker 仓库也是可以的,事实上只需要简单地运行docker run registry命令就行了。但在这篇文章中,我们的重点将不是讲解如何部署一个定制的注册服务。

关闭并移除容器

在我们继续构建定制容器之前,我们先清理一下 Docker 环境,我们将关闭先前的容器,并移除它。

我们利用docker命令和run选项运行一个容器,所以,为了停止同一个容器,我们简单地在执行docker命令时,使用kill选项,并指定容器名。

# docker kill desperate_lalande
desperate_lalande

当我们再次执行docker ps,就不再有容器运行了

# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

但是,此时,我们这是停止了容器;虽然它不再运行,但仍然存在。默认情况下,docker ps只会显示正在运行的容器,如果我们附加-a (all) 标识,它会显示所有运行和未运行的容器。

# docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                           PORTS               NAMES
f6d31ab01fc9        5c82215b03d1        nginx -g 'daemon off   4 weeks ago         Exited (-1) About a minute ago                       desperate_lalande  

为了能完整地移除容器,我们在用docker命令时,附加rm选项。

# docker rm desperate_lalande
desperate_lalande

虽然容器被移除了;但是我们仍拥有可用的nginx镜像(LCTT 译注:镜像缓存)。如果我们重新运行docker run -d nginx,Docker 就无需再次拉取 nginx 镜像即可启动容器。这是因为我们本地系统中已经保存了一个副本。

为了列出系统中所有的本地镜像,我们运行docker命令,附加images选项。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
nginx               latest              9fab4090484a        5 days ago          132.8 MB

构建我们自己的镜像

截至目前,我们已经使用了一些基础的 Docker 命令来启动、停止和移除一个预构建好的普通镜像。为了“Docker 化(Dockerize)”这篇博客,我们需要构建我们自己的镜像,也就是创建一个 Dockerfile

在大多数虚拟机环境中,如果你想创建一个机器镜像,首先,你需要建立一个新的虚拟机、安装操作系统、安装应用,最后将其转换为一个模板或者镜像。但在 Docker 中,所有这些步骤都可以通过 Dockerfile 实现全自动。Dockerfile 是向 Docker 提供构建指令去构建定制镜像的方式。在这一章节,我们将编写能用来部署这个博客的定制 Dockerfile。

理解应用

我们开始构建 Dockerfile 之前,第一步要搞明白,我们需要哪些东西来部署这个博客。

这个博客本质上是由一个静态站点生成器生成的静态 HTML 页面,这个生成器是我编写的,名为 hamerkop。这个生成器很简单,它所做的就是生成该博客站点。所有的代码和源文件都被我放在了一个公共的 Github 仓库。为了部署这篇博客,我们要先从 Github 仓库把这些内容拉取下来,然后安装 Python 和一些 Python 模块,最后执行hamerkop应用。我们还需要安装 nginx,来运行生成后的内容。

截止目前,这些还是一个简单的 Dockerfile,但它却给我们展示了相当多的 Dockerfile 语法)。我们需要克隆 Github 仓库,然后使用你最喜欢的编辑器编写 Dockerfile,我选择vi

# git clone https://github.com/madflojo/blog.git
Cloning into 'blog'...
remote: Counting objects: 622, done.
remote: Total 622 (delta 0), reused 0 (delta 0), pack-reused 622
Receiving objects: 100% (622/622), 14.80 MiB | 1.06 MiB/s, done.
Resolving deltas: 100% (242/242), done.
Checking connectivity... done.
# cd blog/
# vi Dockerfile

FROM - 继承一个 Docker 镜像

第一条 Dockerfile 指令是FROM指令。这将指定一个现存的镜像作为我们的基础镜像。这也从根本上给我们提供了继承其他 Docker 镜像的途径。在本例中,我们还是从刚刚我们使用的 nginx 开始,如果我们想从头开始,我们可以通过指定ubuntu:latest来使用 Ubuntu Docker 镜像。

## Dockerfile that generates an instance of http://bencane.com

FROM nginx:latest
MAINTAINER Benjamin Cane <[email protected]>

除了FROM指令,我还使用了MAINTAINER,它用来显示 Dockerfile 的作者。

Docker 支持使用#作为注释,我将经常使用该语法,来解释 Dockerfile 的部分内容。

运行一次测试构建

因为我们继承了 nginx Docker镜像,我们现在的 Dockerfile 也就包括了用来构建 nginx 镜像的 Dockerfile 中所有指令。这意味着,此时我们可以从该 Dockerfile 中构建出一个 Docker 镜像,然后以该镜像运行一个容器。虽然,最终的镜像和 nginx 镜像本质上是一样的,但是我们这次是通过构建 Dockerfile 的形式,然后我们将讲解 Docker 构建镜像的过程。

想要从 Dockerfile 构建镜像,我们只需要在运行 docker 命令的时候,加上 build 选项。

# docker build -t blog /root/blog 
Sending build context to Docker daemon  23.6 MB
Sending build context to Docker daemon 
Step 0 : FROM nginx:latest
 ---> 9fab4090484a
Step 1 : MAINTAINER Benjamin Cane <[email protected]>
 ---> Running in c97f36450343
 ---> 60a44f78d194
Removing intermediate container c97f36450343
Successfully built 60a44f78d194

上面的例子,我们使用了-t (tag)标识给镜像添加“blog”的标签。实质上我们就是在给镜像命名,如果我们不指定标签,就只能通过 Docker 分配的 Image ID 来访问镜像了。本例中,从 Docker 构建成功的信息可以看出,Image ID值为 60a44f78d194

除了-t标识外,我还指定了目录/root/blog。该目录被称作“构建目录”,它将包含 Dockerfile,以及其它需要构建该容器的文件。

现在我们构建成功了,下面我们开始定制该镜像。

使用 RUN 来执行 apt-get

用来生成 HTML 页面的静态站点生成器是用 Python 语言编写的,所以,在 Dockerfile 中需要做的第一件定制任务是安装 Python。我们将使用 Apt 软件包管理器来安装 Python 软件包,这意味着在 Dockerfile 中我们要指定运行apt-get updateapt-get install python-dev;为了完成这一点,我们可以使用RUN指令。

## Dockerfile that generates an instance of http://bencane.com

FROM nginx:latest
MAINTAINER Benjamin Cane <[email protected]>

## Install python and pip
RUN apt-get update
RUN apt-get install -y python-dev python-pip

如上所示,我们只是简单地告知 Docker 构建镜像的时候,要去执行指定的apt-get命令。比较有趣的是,这些命令只会在该容器的上下文中执行。这意味着,即使在容器中安装了python-devpython-pip,但主机本身并没有安装这些。说的更简单点,pip命令将只在容器中执行,出了容器,pip命令不存在。

还有一点比较重要的是,Docker 构建过程中不接受用户输入。这说明任何被RUN指令执行的命令必须在没有用户输入的时候完成。由于很多应用在安装的过程中需要用户的输入信息,所以这增加了一点难度。不过我们例子中,RUN命令执行的命令都不需要用户输入。

安装 Python 模块

Python 安装完毕后,我们现在需要安装 Python 模块。如果在 Docker 外做这些事,我们通常使用pip命令,然后参考我的博客 Git 仓库中名叫requirements.txt的文件。在之前的步骤中,我们已经使用git命令成功地将 Github 仓库“克隆”到了/root/blog目录;这个目录碰巧也是我们创建Dockerfile的目录。这很重要,因为这意味着 Docker 在构建过程中可以访问这个 Git 仓库中的内容。

当我们执行构建后,Docker 将构建的上下文环境设置为指定的“构建目录”。这意味着目录中的所有文件都可以在构建过程中被使用,目录之外的文件(构建环境之外)是不能访问的。

为了能安装所需的 Python 模块,我们需要将requirements.txt从构建目录拷贝到容器中。我们可以在Dockerfile中使用COPY指令完成这一需求。

## Dockerfile that generates an instance of http://bencane.com

FROM nginx:latest
MAINTAINER Benjamin Cane <[email protected]>

## Install python and pip
RUN apt-get update
RUN apt-get install -y python-dev python-pip

## Create a directory for required files
RUN mkdir -p /build/

## Add requirements file and run pip
COPY requirements.txt /build/
RUN pip install -r /build/requirements.txt

Dockerfile中,我们增加了3条指令。第一条指令使用RUN在容器中创建了/build/目录。该目录用来拷贝生成静态 HTML 页面所需的一切应用文件。第二条指令是COPY指令,它将requirements.txt从“构建目录”(/root/blog)拷贝到容器中的/build/目录。第三条使用RUN指令来执行pip命令;安装requirements.txt文件中指定的所有模块。

当构建定制镜像时,COPY是条重要的指令。如果在 Dockerfile 中不指定拷贝文件,Docker 镜像将不会包含requirements.txt 这个文件。在 Docker 容器中,所有东西都是隔离的,除非在 Dockerfile 中指定执行,否则容器中不会包括所需的依赖。

重新运行构建

现在,我们让 Docker 执行了一些定制任务,现在我们尝试另一次 blog 镜像的构建。

# docker build -t blog /root/blog
Sending build context to Docker daemon 19.52 MB
Sending build context to Docker daemon 
Step 0 : FROM nginx:latest
 ---> 9fab4090484a
Step 1 : MAINTAINER Benjamin Cane <[email protected]>
 ---> Using cache
 ---> 8e0f1899d1eb
Step 2 : RUN apt-get update
 ---> Using cache
 ---> 78b36ef1a1a2
Step 3 : RUN apt-get install -y python-dev python-pip
 ---> Using cache
 ---> ef4f9382658a
Step 4 : RUN mkdir -p /build/
 ---> Running in bde05cf1e8fe
 ---> f4b66e09fa61
Removing intermediate container bde05cf1e8fe
Step 5 : COPY requirements.txt /build/
 ---> cef11c3fb97c
Removing intermediate container 9aa8ff43f4b0
Step 6 : RUN pip install -r /build/requirements.txt
 ---> Running in c50b15ddd8b1
Downloading/unpacking jinja2 (from -r /build/requirements.txt (line 1))
Downloading/unpacking PyYaml (from -r /build/requirements.txt (line 2))
<truncated to reduce noise>
Successfully installed jinja2 PyYaml mistune markdown MarkupSafe
Cleaning up...
 ---> abab55c20962
Removing intermediate container c50b15ddd8b1
Successfully built abab55c20962

上述输出所示,我们可以看到构建成功了,我们还可以看到另外一个有趣的信息---> Using cache。这条信息告诉我们,Docker 在构建该镜像时使用了它的构建缓存。

Docker 构建缓存

当 Docker 构建镜像时,它不仅仅构建一个单独的镜像;事实上,在构建过程中,它会构建许多镜像。从上面的输出信息可以看出,在每一“步”执行后,Docker 都在创建新的镜像。

 Step 5 : COPY requirements.txt /build/
  ---> cef11c3fb97c

上面片段的最后一行可以看出,Docker 在告诉我们它在创建一个新镜像,因为它打印了Image ID : cef11c3fb97c。这种方式有用之处在于,Docker能在随后构建这个 blog 镜像时将这些镜像作为缓存使用。这很有用处,因为这样, Docker 就能加速同一个容器中新构建任务的构建流程。从上面的例子中,我们可以看出,Docker 没有重新安装python-devpython-pip包,Docker 则使用了缓存镜像。但是由于 Docker 并没有找到执行mkdir命令的构建缓存,随后的步骤就被一一执行了。

Docker 构建缓存一定程度上是福音,但有时也是噩梦。这是因为决定使用缓存或者重新运行指令的因素很少。比如,如果requirements.txt文件发生了修改,Docker 会在构建时检测到该变化,然后 Docker 会重新执行该执行那个点往后的所有指令。这得益于 Docker 能查看requirements.txt的文件内容。但是,apt-get命令的执行就是另一回事了。如果提供 Python 软件包的 Apt 仓库包含了一个更新的 python-pip 包;Docker 不会检测到这个变化,转而去使用构建缓存。这会导致之前旧版本的包将被安装。虽然对python-pip来说,这不是主要的问题,但对使用了存在某个致命攻击缺陷的软件包缓存来说,这是个大问题。

出于这个原因,抛弃 Docker 缓存,定期地重新构建镜像是有好处的。这时,当我们执行 Docker 构建时,我简单地指定--no-cache=True即可。

部署博客的剩余部分

Python 软件包和模块安装后,接下来我们将拷贝需要用到的应用文件,然后运行hamerkop应用。我们只需要使用更多的COPYRUN指令就可完成。

## Dockerfile that generates an instance of http://bencane.com

FROM nginx:latest
MAINTAINER Benjamin Cane <[email protected]>

## Install python and pip
RUN apt-get update
RUN apt-get install -y python-dev python-pip

## Create a directory for required files
RUN mkdir -p /build/

## Add requirements file and run pip
COPY requirements.txt /build/
RUN pip install -r /build/requirements.txt

## Add blog code nd required files
COPY static /build/static
COPY templates /build/templates
COPY hamerkop /build/
COPY config.yml /build/
COPY articles /build/articles

## Run Generator
RUN /build/hamerkop -c /build/config.yml

现在我们已经写出了剩余的构建指令,我们再次运行另一次构建,并确保镜像构建成功。

# docker build -t blog /root/blog/
Sending build context to Docker daemon 19.52 MB
Sending build context to Docker daemon 
Step 0 : FROM nginx:latest
 ---> 9fab4090484a
Step 1 : MAINTAINER Benjamin Cane <[email protected]>
 ---> Using cache
 ---> 8e0f1899d1eb
Step 2 : RUN apt-get update
 ---> Using cache
 ---> 78b36ef1a1a2
Step 3 : RUN apt-get install -y python-dev python-pip
 ---> Using cache
 ---> ef4f9382658a
Step 4 : RUN mkdir -p /build/
 ---> Using cache
 ---> f4b66e09fa61
Step 5 : COPY requirements.txt /build/
 ---> Using cache
 ---> cef11c3fb97c
Step 6 : RUN pip install -r /build/requirements.txt
 ---> Using cache
 ---> abab55c20962
Step 7 : COPY static /build/static
 ---> 15cb91531038
Removing intermediate container d478b42b7906
Step 8 : COPY templates /build/templates
 ---> ecded5d1a52e
Removing intermediate container ac2390607e9f
Step 9 : COPY hamerkop /build/
 ---> 59efd1ca1771
Removing intermediate container b5fbf7e817b7
Step 10 : COPY config.yml /build/
 ---> bfa3db6c05b7
Removing intermediate container 1aebef300933
Step 11 : COPY articles /build/articles
 ---> 6b61cc9dde27
Removing intermediate container be78d0eb1213
Step 12 : RUN /build/hamerkop -c /build/config.yml
 ---> Running in fbc0b5e574c5
Successfully created file /usr/share/nginx/html//2011/06/25/checking-the-number-of-lwp-threads-in-linux
Successfully created file /usr/share/nginx/html//2011/06/checking-the-number-of-lwp-threads-in-linux
<truncated to reduce noise>
Successfully created file /usr/share/nginx/html//archive.html
Successfully created file /usr/share/nginx/html//sitemap.xml
 ---> 3b25263113e1
Removing intermediate container fbc0b5e574c5
Successfully built 3b25263113e1

运行定制的容器

成功的一次构建后,我们现在就可以通过运行docker命令和run选项来运行我们定制的容器,和之前我们启动 nginx 容器一样。

# docker run -d -p 80:80 --name=blog blog
5f6c7a2217dcdc0da8af05225c4d1294e3e6bb28a41ea898a1c63fb821989ba1

我们这次又使用了-d (detach)标识来让Docker在后台运行。但是,我们也可以看到两个新标识。第一个新标识是--name,这用来给容器指定一个用户名称。之前的例子,我们没有指定名称,因为 Docker 随机帮我们生成了一个。第二个新标识是-p,这个标识允许用户从主机映射一个端口到容器中的一个端口。

之前我们使用的基础 nginx 镜像分配了80端口给 HTTP 服务。默认情况下,容器内的端口通道并没有绑定到主机系统。为了让外部系统能访问容器内部端口,我们必须使用-p标识将主机端口映射到容器内部端口。上面的命令,我们通过-p 80:80语法将主机80端口映射到容器内部的80端口。

经过上面的命令,我们的容器看起来成功启动了,我们可以通过执行docker ps核实。

# docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
d264c7ef92bd        blog:latest         nginx -g 'daemon off   3 seconds ago       Up 3 seconds        443/tcp, 0.0.0.0:80->80/tcp   blog  

总结

截止目前,我们拥有了一个运行中的定制 Docker 容器。虽然在这篇文章中,我们只接触了一些 Dockerfile 指令用法,但是我们还是要学习所有的指令。我们可以检查 Docker's reference page 来获取所有的 Dockerfile 指令用法,那里对指令的用法说明得很详细。

另一个比较好的资源是 Dockerfile Best Practices page,它有许多构建定制 Dockerfile 的最佳练习。有些技巧非常有用,比如战略性地组织好 Dockerfile 中的命令。上面的例子中,我们将articles目录的COPY指令作为 Dockerfile 中最后的COPY指令。这是因为articles目录会经常变动。所以,将那些经常变化的指令尽可能地放在最后面的位置,来最优化那些可以被缓存的步骤。

通过这篇文章,我们涉及了如何运行一个预构建的容器,以及如何构建,然后部署定制容器。虽然关于 Docker 你还有许多需要继续学习的地方,但我想这篇文章给了你如何继续开始的好建议。当然,如果你认为还有一些需要继续补充的内容,在下面评论即可。


via: http://bencane.com/2015/12/01/getting-started-with-docker-by-dockerizing-this-blog/

作者:Benjamin Cane 译者:su-kaiyao 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

PHP-FPM 作为 FastCGI 进程管理器而广为熟知,它是 PHP FastCGI 实现的改进,带有更为有用的功能,用于处理高负载的服务器和网站。下面列出其中一些功能:

新功能

  • 拥有具有优雅(graceful)启动/停止选项的高级进程管理能力。
  • 可以通过不同的用户身份/组身份来以监听多个端口以及使用多个PHP配置。
  • 错误日志记录。
  • 支持上传加速。
  • 特别用于在处理一些耗时任务时结束请求和清空所有数据的功能。
  • 同时支持动态和静态的子进程重生。
  • 支持IP地址限制。

在本文中,我将要讨论的是,在运行 CPanel 11.52 及 EA3 (EasyApache)的 CentOS 7 服务器上,于 Nginx 和 Apache 之上安装 PHP-FPM,以及如何来通过 CPanel 管理这些安装好的多个 PHP-FPM 实例。

在我们开始安装前, 先看看安装的先决条件。

先决条件

  1. 启用 Modproxyfcgi 模块
  2. 启用 MPM\_Event

由于我们要将 PHP-FPM 安装到一台 EA3 服务器,我们需要运行 EasyApache 来编译 Apache 以启用这些模块。

你们可以参考我以前写的,关于如何在 Apache 服务器上安装 Nginx 作为反向代理的文档来了解 Nginx 的安装。

这里,我将再次简述那些安装步骤。具体细节,你可以参考我之前写的(如何在 CentOS 7/CPanel 服务器上配置 Nginx 反向代理)一文。

  • 步骤 1:安装 Epel 仓库
  • 步骤 2:安装 nDeploy RPM 仓库,这是此次安装中最为重要的步骤。
  • 步骤 3:使用 yum 从 nDeploy 仓库安装 nDeploy 和 Nginx 插件。
  • 步骤 4:启用/配置 Nginx 为反向代理。

完成这些步骤后,下面为服务器中所有可用 PHP 版本安装 PHP-FPM 包,EA3 使用 remi 仓库来安装这些包。你可以运行这个 nDeploy 脚本来下载所有的包。

root@server1 [~]# /opt/nDeploy/scripts/easy_php_setup.sh
Loaded plugins: fastestmirror, tsflags, universal-hooks
EA4 | 2.9 kB 00:00:00
base | 3.6 kB 00:00:00
epel/x86_64/metalink | 9.7 kB 00:00:00
epel | 4.3 kB 00:00:00
extras | 3.4 kB 00:00:00
updates | 3.4 kB 00:00:00
(1/2): epel/x86_64/updateinfo | 460 kB 00:00:00
(2/2): epel/x86_64/primary_db

运行该脚本将为 PHP 54,PHP 55,PHP 56 和 PHP 70 安装所有这些 FPM 包。

Installed Packages
php54-php-fpm.x86_64 5.4.45-3.el7.remi @remi
php55-php-fpm.x86_64 5.5.31-1.el7.remi @remi
php56-php-fpm.x86_64 5.6.17-1.el7.remi @remi
php70-php-fpm.x86_64 7.0.2-1.el7.remi @remi

在以上安装完成后,你需要为 Apache 启用 PHP-FPM SAPI。你可以运行下面这个脚本来启用 PHP-FPM 实例。

root@server1 [~]# /opt/nDeploy/scripts/apache_php-fpm_setup.sh enable
mod_proxy_fcgi.c
Please choose one default PHP version from the list below
PHP70
PHP56
PHP54
PHP55
Provide the exact desired version string here and press ENTER: PHP54
ConfGen:: lxblogger
ConfGen:: blogr
ConfGen:: saheetha
ConfGen:: satest
which: no cagefsctl in (/usr/local/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin)
info [rebuildhttpdconf] Missing owner for domain server1.centos7-test.com, force lookup to root
Built /usr/local/apache/conf/httpd.conf OK
Waiting for “httpd” to restart gracefully …waiting for “httpd” to initialize ……
…finished.

它会问你需要运行哪个 PHP 版本作为服务器默认版本,你可以输入那些细节内容,然后继续配置并为现存的域名生成虚拟主机文件。

我选择了 PHP 54 作为我服务器上的默认 PHP-FPM 版本。

confirm-php-fpm

虽然服务器配置了 PHP-FPM 54,但是我们可以通过 CPanel 为各个独立的域名修改 PHP-FPM 实例。

下面我将通过一些截图来为你们说明一下,怎样通过 CPanel 为各个独立域修改 PHP-FPM 实例。

安装了 Nginx 插件后,你的域名的 CPanel 就会有一个 Nginx Webstack 图标,你可以点击该图标来配置你的 Web 服务器。我已经登录进了我其中的一个 CPanel 来配置相应的 Web 服务器。

请看这些截图。

nginxicon1

现在,你可以根据需要为选中的主域配置 web 服务器(这里,我已经选择了主域 saheetha.com)。我已经继续通过自动化配置选项来进行了,因为我不需要添加任何手动设置。

nginx_auto_proxy

当 Nginx 配置完后,你可以在这里为你的域名选择 PHP-FPM 实例。

php-fpm1

php54

php55

就像你在截图中所看到的,我服务器上的默认 PHP-FPM 是PHP 54,而我正要将我的域名的 PHP-FPM 实例单独修改成 PHP 55。当你为你的域修改 PHP-FPM 后,你可以通过访问 phpinfo 页面来确认。

谢谢你们参考本文,我相信这篇文章会给你提供不少信息和帮助。我会为你们推荐关于这个内容的有价值的评论 :)。


via: http://linoxide.com/linux-how-to/enable-multiple-php-fpm-instances-nginx-apache/

作者:Saheetha Shameer 译者:GOLinux 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

今日关注

OpenSUSE 的 Open Build Service (OBS)2.7 发布。它类似于 Canonical 的 Launchpad ,应用开发者可以创建软件库并自动推送更新给用户;也类似于 PPA ,但是它可以用于多个 Linux 发行版。

“最新的 OBS 已经部署到我们的 引用服务器 reference server 上了。” OpenSUSE 的 Henne Vogelsang 说,“所有开源开发者都可以使用引用服务器 http://build.opensuse.org 来为各种流行的发行版构建软件包,包括 openSUSE、Debian、Fedora、Ubuntu、 Arch、Red Hat Enterprise Linux 和 SUSE Linux Enterprise。”

这个版本主要实现了三个新特性。

  • 自动对软件仓库的移动和 GNU/Linux 操作系统发布更新进行跟踪;
  • 对 Git 的集成,允许应用开发者进行持续构建;
  • 实验性的 KIWI 导入功能,开发者可以从 SUSE Studio 服务导入 ISO 镜像。

新闻摘要

  • 代号为 “Stretch” 的 Debian GNU/Linux 9 创意桌面征集启动。截止日期为今年9月5号。详情见官网
  • Firefox 47 发布,这一版本提供了对 同步标签 Synced Tabs 的支持,对用户代理字符串的自定义支持,以及一个新的性能监控页面(about:performance)。用户可以进行下载体验了。
  • 基于 Ubuntu 的 ChaletOS 16.04.1 现在可以进行下载了。ChaletOS 提供了一个类似 Windows 系统的桌面,风格类似 Windows 7 和 Vista 系统,当然可以添加一些图标让系统看上去更像 Windows 10 。
  • 预计今年九月发布的 GNOME 3.22 桌面环境最新动态:GNOME 控制中心应用的图标由以前的标准图标替换成了现在具有象征意义的图标;并对控制面板进行了分组。

自从几年前云计算的概念受到IT界的关注以来,公有云、私有云和混合云这三种云计算方式都有了可观的演进。其中混合云计算方式是最热门的云计算方式,在接受调查的公司中,有88%的公司将混合云计算摆在至关重要的地位。

混合云计算的疾速演进意味着一两年前的传统观念已经过时了。为此,我们询问了几个行业分析师,混合云在2016年的走势将会如何,我们得到了几个比较有意思的答案。

2016年可能是我们将混合云投入使用的一年

混合云从本质上来说依赖于私有云,这对企业来说是比较难实现的。事实上,亚马逊,谷歌和微软的公有云已经进行了大量的投资,并且起步也比较早。私有云拖了混合云发展和使用的后腿。

私有云没有得到这么多的投资,这是有私有云的性质决定的。私有云意味着维护和投资你自己的数据中心。而许多公有云提供商正在推动企业减少或者消除他们的数据中心。

然而,得益于 OpenStack 的发展和微软的 Azure Stack ,这两者基本上就是封装在一个盒子里的私有云,我们将会看到私有云慢慢追上公有云的发展步伐。支持混合云的工具、基础设施和架构也变得更加健壮。

容器,微服务和 unikernels 将会促进混合云的发展

分析师预言,到2016年底,这些原生云技术会或多或少成为主流的。这些云技术正在快速成熟,将会成为虚拟机的一个替代品,而虚拟机需要更多的资源。

更重要的是,他们既能工作在在线场景,也能工作在离线场景。容器化和编排允许快速的扩大规模,进行公有云和私有云之间的服务迁移,使你能够更容易移动你的服务。

数据和相关性占据核心舞台

所有的云计算方式都处在发展模式。这使得云计算变成了一个技术类的故事。咨询公司 Avoa称,随着云趋于成熟,数据和相关性变得越来越重要。起初,云计算和大数据都是关于怎么得到尽可能多的数据,然后他们担心如何处理这海量的数据。

2016年,相关组织将会继续锤炼如何进行数据收集和使用的相关技术。在必须处理的技术和文化方面仍然有待提高。但是2016年应该重新将关注点放在从各个方面考虑的数据重要性上,发现最相关的信息,而不只是数据的数量。

云服务将超越按需工作负载

AWS(Amazon Web Services) 起初是提供给程序员或者是开发人员能够快速启动虚拟机、做一些工作然后离线的一个地方。本质上是按需使用,要花费更多的钱才能让这些服务持续运行、全天候工作。

然而,IT 公司正开始作为服务代理,为内部用户提供各种 IT 服务。可以是内部 IT 服务,公有云基础架构提供商,平台服务和软件服务。

他们将越来越多的认识到像云管理平台这样的工具的价值。云管理平台可以提供针对不同服务的基于策略的一致性管理。他们也将看到像提高可移植性的容器等技术的价值。然而,云服务代理,在不同云之间快速移动工作负载从而进行价格套利或者类似的原因,仍然是行不通的。

服务提供商转变成了云服务提供商

到目前为止,购买云服务成了直销模式。AWS EC2 服务的使用者通常变成了购买者,要么通过官方认证渠道,要么通过影子 IT。但是随着云服务越来越全面,提供的服务菜单越来越复杂,越来越多的人转向了经销商,服务提供商转变成了他们 IT 服务的购买者。

2nd Watch (2nd Watch 是为企业提供云管理的 AWS 的首选合作伙伴)最近的一项调查发现,在美国将近85%的 IT 高管愿意支付一个小的溢价从渠道商那里购买公有云服务,如果购买过程变得不再那么复杂。根据调查,这85%的高管有五分之四的愿意支付额外的15%或者更多。三分之一的受访高管表示,这些有助于他们购买、使用和管理公有云服务。

物联网和云对于2016年的意义好比移动和云对2012年的意义

物联网获得了广泛的关注,更重要的是,物联网已经从测试场景进行了实际应用。云的分布式特性使得云成为了物联网非常重要的一部分,对于工业物联网,与后端系统交互的机械和重型设备,混合云将会成为最自然的驱动者,连接,数据采集和处理将会发生在混合云环境中,这得益于私有云在安全和隐私方面的好处。

NIST 对云的定义开始瓦解

2011年,美国国家标准与技术研究院发布了“ NIST 对于云计算的定义”(PDF),这个定义成为了私有云、公有云、混合云和 aaS 模板的标准定义。

然而随着时间的推移,定义开始改变。IaaS 变得更加复杂,开始支持 OpenStack,Swift 对象存储和神经网络这样的项目。PaaS 似乎正在消退,因为 PaaS 和传统的中间件开发几乎无异。SaaS,只是通过浏览器进行访问的应用,也正在失去发展动力,因为许多 app 和服务提供了许多云接口,你可以通过各种手段调用接口,不仅仅通过浏览器。

分析变得更加重要

对于混合云计算来说,分析将会成为一个巨大的增长机遇,云计算具有规模大、灵活性高的优势,使得云计算非常适合需要海量数据的分析工作。对于某些分析方式,比如高度敏感的数据,私有云仍然是主导地位,但是私有云也是混合云的一部分。因此,无论如何,混合云计算胜出。

安全仍然是一个非常紧迫的问题

随着混合云计算在2016年的发展,以及对物联网和容器等新技术的引进,这同时也增加了更多的脆弱可攻破的地方,从而导致数据泄露。先增加使用新技术的趋势,然后再去考虑安全性,这种问题经常发生,同时还有缺少经验的工程师不去考虑系统的安全问题,总有一天你会尝到灾难的后果的。

当一项新技术出来,管理规范总是落后于安全问题产生后,然后我们才考虑去保护技术。容器就是一个很鲜明的例子。你可以从 Docker 下载各种示例容器,但是你知道你下载的东西来自哪里么?在人们在对容器内容不知情的情况下下载并运行了容器之后,Docker 不得不重新加上安全验证。

像 Path 和 Snapchat 这样的移动技术在智能手机市场火起来之后也出现了重大的安全问题。一项新技术被恶意利用无可避免。所以安全研究人员需要通过各种手段来保证新技术的安全性,很有可能在部署之后才会发现安全问题。


via: http://www.datamation.com/cloud-computing/9-key-trends-in-hybrid-cloud-computing.html

作者:Andy Patrizio 译者:棣琦 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出