分类 容器与云 下的文章

在本教程中,你将学习如何在一个“吊舱”中运行两个容器来托管一个 WordPress 站点。

 title=

无论你是将其作为工作的一部分、未来的工作机会或者仅仅是出于对新技术的兴趣,容器对很多人,即使是经验丰富的系统管理员,可能是非常难以应付的。那么如何真正开始使用容器呢?从容器到 Kubernetes 的成长路径是什么?另外,为什么有不止一条路径?如你所料,最好的起点就是现在。

1、了解容器

略一回忆,容器的开端可以追溯到早期 BSD 及其特殊的 chroot 监狱,但让我们直接跳到发展中期讲起。

之前,Linux 内核引入了 “ 控制组 cgroup ”,允许你能够使用 “ 命名空间 namespace ” 来“标记”进程。当你将进程分组到一个命名空间时,这些进程的行为就像在命名空间之外的东西不存在一样,这就像你把这些进程放入某种容器中。当然,这种容器是虚拟的,它位于计算机内部,它和你操作系统的其余进程使用相同的内核、内存和 CPU,但你用容器包含了这些进程。

分发的预制容器仅包含运行它所包含的应用程序必须的内容。使用容器引擎,如 Podman、Docker 或 CRI-O,你可以运行一个容器化应用程序,而无需进行传统意义上的安装。容器引擎通常是跨平台的,因此即使容器运行在 Linux 上,你也可以在其他 Linux、MacOS 或 Windows 上启动容器。

更重要的是,当需求量很大时,你可以运行同一应用程序的多个容器。

现在你知道了什么是容器,下一步是运行一个容器。

2、运行一个容器

在运行容器之前,你应该有一个想要运行它的理由。你可以编一个,这有助于你对让容器创建过程感兴趣,这样你就会受到鼓舞,真正去使用你所运行的容器。毕竟,运行容器但不使用它提供的应用程序,只能证明你没有注意到任何故障,但使用容器证明它可以工作。

我推荐从 WordPress 开始,它是一个很流行的 Web 应用程序,容易使用,所以一旦容器运行起来,你就可以测试使用它。虽然你可以轻松地配置一个 WordPress 容器,但还是有很多配置选项可以引导你发现更多运行容器的方式(例如运行数据库容器)以及容器如何通信。

我使用 Podman,它是一个友好、方便且无守护进程的容器引擎。如果你没有安装 Podman,可以改用 Docker 命令。它们都是很棒的开源容器引擎,而且它们的语法是相同的(只需输入 docker 而不是 podman)。因为 Podman 没有守护进程,所以它需要更多的配置,但为了这种运行免 root、无守护进程的容器的能力是值得的。

如果你使用 Docker,可以跳到下面的 运行 WordPress 容器 小节,否则,打开终端安装并配置 Podman:

$ sudo dnf install podman

容器会产生许多进程,通常只有 root 用户有权创建数千个进程 ID。创建一个名为 /etc/subuid 的文件,定义一个适当的起始 UID 和大量合法的 PID,这样就可以为你添加一些额外的进程 ID:

seth:200000:165536

在名为 /etc/subgid 的文件中对你的组执行相同的操作。在这个例子中,我的主要组是 staff(对你来说可能是 users,或者和你的用户名一样,这取决于你的系统)。

staff:200000:165536

最后,确认你的用户可以管理很多命名空间:

$ sysctl --all --pattern user_namespaces
user.max_user_namespaces = 28633

如果你的用户无权管理超过 28,000 个命名空间,创建 /etc/sysctl.d/userns.conf 文件来增加数量并输入:

user.max_user_namespaces=28633

运行 WordPress 容器

现在,无论你使用的是 Podman 还是 Docker,你都可以从在线容器仓库中下载 WordPress 容器并运行它。你可以使用以下 Podman 命令完成所有这些操作:

$ podman run --name mypress \
    -p 8080:80 -d wordpress

给 Podman 一会时间来找到容器、从互联网下载它,然后启动。

在收到终端返回提示符后,启动 Web 浏览器,打开 localhost:8080。WordPress 正在运行,等待你进行设置。

 title=

不过,你很快就会遇到障碍,因为 WordPress 使用数据库来存储数据,因此你需要为其提供一个数据库。

在继续之前,停止并删除 WordPress 容器:

$ podman stop mypress
$ podman rm mypress

3、在吊舱中运行容器

正如名字所暗示的那样,容器在设计上是独立的。在容器中运行的应用程序不应该与在容器外的应用程序或基础设施进行交互。因此,当一个容器需要另一个容器才能运行时,一种解决方案是将这两个容器放在一个更大的容器中,称为 “ 吊舱 pod ”。吊舱确保其容器可以共享重要的命名空间以便相互通信。

创建一个新的吊舱,为它提供一个名称,以及希望能够访问的端口:

$ podman pod create \
    --name wp_pod \
    --publish 8080:80

确认吊舱存在:

$ podman pod list
POD ID        NAME     STATUS    INFRA ID      # OF CONTAINERS
100e138a29bd  wp_pod   Created   22ace92df3ef   1

将容器添加到吊舱

现在你已经为相互依赖的容器创建了一个吊舱,你可以通过指定一个运行的吊舱来启动每个容器。

首先,启动一个数据库容器。你可以创建自己的凭据,只要在 WordPress 连接到数据库时使用相同的凭据。

$ podman run --detach \
    --pod wp_pod \
    --restart=always \
    -e MYSQL_ROOT_PASSWORD="badpassword0" \
    -e MYSQL_DATABASE="wp_db" \
    -e MYSQL_USER="tux" \
    -e MYSQL_PASSWORD="badpassword1" \
    --name=wp_db mariadb

接下来,在同一个吊舱中启动 WordPress 容器:

$ podman run --detach \
    --restart=always --pod=wp_pod \
    -e WORDPRESS_DB_NAME="wp_db" \
    -e WORDPRESS_DB_USER="tux" \
    -e WORDPRESS_DB_PASSWORD="badpassword1" \
    -e WORDPRESS_DB_HOST="127.0.0.1" \
    --name mypress wordpress

现在启动你最喜欢的网络浏览器并打开 localhost:8080

这一次,设置会正常进行。WordPress 会连接到数据库,因为你在启动容器时传递了这些环境变量。

 title=

创建用户账户后,你可以登录查看 WordPress 仪表板。

 title=

下一步

你已经创建了两个容器,并在一个吊舱中运行了它们。你现在已经了解了如何在自己的服务器上运行容器及服务。如果你想迁移到云,容器非常适合你。使用像 Kubernetes 和 OpenShift 这样的工具,你可以自动化启动 集群上的容器和吊舱。如果你正在考虑采取下一步行动,阅读 Kevin Casey 的 3 个开始使用 Kubernetes 的方法,并尝试他提到的 Minikube 教程。


via: https://opensource.com/article/22/2/start-running-containers

作者:Seth Kenlon 选题:lujun9972 译者:MjSeven 校对:wxy

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

MLCube 是一个新的基于基础设施规范的开源容器,被引入到基于 Python 的机器学习工作流程中,以实现可重复性。它可以利用诸如 PodmanSingularityDocker 等工具。也支持在远程平台上的执行。开发 MLCube 的 MLCommons 最佳实践工作组的主席之一是来自 Red Hat 的 Diane Feddema。这篇介绍性文章解释了如何在 Fedora Linux 上使用 Podman 运行 “hello world” MLCube 例子

Yazan Monshed 写了一篇关于 Fedora 上的 Podman 的非常有用的介绍,对这里使用的一些步骤给出了更多细节。

首先安装必要的依赖项。

sudo dnf -y update
sudo dnf -y install podman git virtualenv \
                    policycoreutils-python-utils

然后,按照文档的要求,设置一个虚拟环境并获得示例代码。为了确保可重复性,使用一个特定的提交,因为该项目正在积极改进。

virtualenv -p python3 ./env_mlcube 
source ./env_mlcube/bin/activate
git clone https://github.com/mlcommons/mlcube_examples.git 
cd ./mlcube_examples/hello_world
git checkout 5fe69bd
pip install mlcube mlcube-docker
mlcube describe

现在,通过编辑 $HOME/mlcube.yaml 文件,将运行器命令从 docker 改为 podman,即:

docker: docker

改为:

docker: podman

如果你使用的是 x86\_64 架构的电脑,你可以用以下方式获取容器:

mlcube configure --mlcube=. --platform=docker

你会看到一些选项:

? Please select an image: 
  ▸ registry.fedoraproject.org/mlcommons/hello_world:0.0.1
    registry.access.redhat.com/mlcommons/hello_world:0.0.1
    docker.io/mlcommons/hello_world:0.0.1
    quay.io/mlcommons/hello_world:0.0.1

选择 docker.io/mlcommons/hello_world:0.0.1 来获取容器。

如果你的电脑不是 x86\_64 架构的,你需要构建容器。改变文件 $HOME/mlcube.yaml,将这一行:

build_strategy: pull

变为:

build_strategy: auto

然后用以下方法构建容器:

mlcube configure --mlcube=. --platform=docker

要运行测试,你可能需要在目录中适当地设置 SELinux 权限。你可以通过输入以下内容来检查 SELinux 是否已经启用:

sudo sestatus

应该会有类似这样的输出:

SELinux status:                 enabled
...

Josphat MutaiChristopher SmartDaniel Walsh 解释说,在为容器使用的文件设置适当的 SELinux 策略时,你需要谨慎。在这里,你将允许容器读取和写入 workspace 目录。

sudo semanage fcontext -a -t container_file_t "$PWD/workspace(/.*)?"
sudo restorecon -Rv $PWD/workspace

现在检查目录策略:

ls -Z

输出结果类似于:

unconfined_u:object_r:user_home_t:s0 Dockerfile
unconfined_u:object_r:user_home_t:s0 README.md
unconfined_u:object_r:user_home_t:s0 mlcube.yaml
unconfined_u:object_r:user_home_t:s0 requirements.txt
unconfined_u:object_r:container_file_t:s0 workspace

现在运行这个例子:

mlcube run --mlcube=. --task=hello --platform=docker
mlcube run --mlcube=. --task=bye --platform=docker

最后,检查输出:

cat workspace/chats/chat_with_alice.txt

有类似于以下的文字:

Hi, Alice! Nice to meet you.
Bye, Alice! It was great talking to you.

你可以按照 这里 的描述创建你自己的 MLCube。欢迎对 MLCube 示例库 做出贡献。Udica 是一个新项目,它承诺为容器提供更精细的 SELinux 策略控制,便于系统管理员应用。这些项目的积极开发正在进行中。对它们进行测试并提供反馈,将有助于使带有 SELinux 的系统上的安全数据管理更容易、更有效。


via: https://fedoramagazine.org/mlcube-and-podman/

作者:Benson Muite 选题:lujun9972 译者:geekpi 校对:wxy

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

对齐部署镜像和描述符是很困难的,但是某些策略可以使整个过程更高效。

 title=

在软件架构中,当两个组件之间有某些概念性或技术上的差异时会出现 阻抗失配 impedance mismatch 。这个术语其实是从电子工程中借用的,表示电路中输入和输出的电子阻抗必须要匹配。

在软件开发中,存储在镜像仓库中的镜像与存储在源码控制管理系统(LCTT 译注:SCM,Source Code Management)中它的 部署描述符 deployment descriptor 之间存在阻抗失配。你如何确定存储在 SCM 中的部署描述符表示的是正确的镜像?两个仓库追踪数据的方式并不一致,因此将一个镜像(在镜像仓库中独立存储的不可修改的二进制)和它的部署描述符(Git 中以文本文件形式存储的一系列修改记录)相匹配并不那么直观。

注意:本文假定读者已经熟悉以下概念:

  • 源码控制管理 Source Control Management (SCM)系统和分支
  • Docker 或符合 OCI 标准的镜像和容器
  • 容器编排系统 Container Orchestration Platforms (COP),如 Kubernetes
  • 持续集成/持续交付 Continuous Integration/Continuous Delivery (CI/CD)
  • 软件开发生命周期 Software development lifecycle (SDLC)环境

阻抗失配:SCM 与镜像仓库

为了更好地理解阻抗失配在什么场景下会成为问题,请考虑任意项目中的软件开发生命周期环境(SDLC),如开发、测试或发布环境。

测试环境不会有阻抗失配。现在使用 CI/CD 的最佳实践中开发分支的最新提交都会对应开发环境中的最新部署。因此,一个典型的、成功的 CI/CD 开发流程如下:

  1. 向 SCM 的开发分支提交新的修改
  2. 新提交触发一次镜像构建
  3. 新生成的镜像被推送到镜像仓库,标记为开发中
  4. 镜像被部署到容器编排系统(COP)中的开发环境,该镜像的部署描述符也更新为从 SCM 拉取的最新描述符。

换句话说,开发环境中最新的镜像永远与最新的部署描述符匹配。回滚到前一个构建的版本也不是问题,因为 SCM 也会跟着回滚。

最终,随着开发流程继续推进,需要进行更多正式的测试,因此某个镜像 —— 镜像对应着 SCM 中的某次提交 —— 被推到测试环境。如果是一次成功的构建,那么不会有大问题,因为从开发环境推过来的镜像应该会与开发分支的最新提交相对应。

  1. 开发环境的最新部署被允许入库,触发入库过程
  2. 最新部署的镜像被标记为测试中
  3. 镜像在测试环境中被拉取和部署,(该镜像)对应从 SCM 拉取的最新部署描述符

到目前为止,一切都没有问题,对吗?如果出现下面的场景,会有什么问题?

场景 A:镜像被推到下游环境,如 用户验收测试 user acceptance testing (UAT),或者是生产环境。

场景 B:测试环境中发现了一个破坏性的 bug,镜像需要回滚到某个确定正常的版本。

在任一场景中,开发过程并没有停止,即开发分支上游有了一次或多次新的提交,而这意味着最新的部署描述符已经发生了变化,最新的镜像与之前部署在测试环境中的镜像不一致。对部署描述符的修改可能会也可能不会对之前版本的镜像起作用,但是它们一定是不可信任的。如果它们有了变化,那么它们就一定与目前为止你测试过的想要部署的镜像的部署描述符不一致。

问题的关键是:如果部署的镜像不是镜像库中的最新版本,你怎么确定与部署的镜像相对应的是 SCM 中的哪个部署描述符? 一言以蔽之,无法确定。两个库直接有阻抗失配。如果要详细阐述下,那么是有方法可以解决的,但是你需要做很多工作,这部分内容就是文章接下来的主题了。请注意,下面的方案并不是解决问题的唯一办法,但是已经投入到生产环境并已经对很多项目起了作用,而且已经被构建并部署到生产环境中运行了超过一年。

二进制与部署描述符

源码通常被构建成一个 Docker 镜像或符合 OCI 标准的镜像,该镜像通常被部署到一个容器编排平台(COP)上,如 Kubernetes。部署到 COP 需要部署描述符来定义镜像被如何部署以及作为容器运行,如 Kubernetes 部署CronJobs。这是因为在镜像和它的部署描述符之间有本质差异,在这里可以看到阻抗失配。在这次讨论中,我们认为镜像是存储在镜像仓库中不可修改的二进制。对源码的任何修改都不会修改镜像,而是用另一个新的镜像去替换它。

相比之下,部署描述符是文本文件,因而可以被认为是源码且可修改。如果遵循最佳实践,那么部署描述符是被存储在 SCM,所有修改都会提交,而这很容易回溯。

解决阻抗失配

建议的解决方案的第一部分,就是提供一个能匹配镜像仓库中的镜像与对保存部署描述符的 SCM 做的代码提交的方法。最直接的解决方案是用源提交的哈希值标记镜像。这个方法可以区分不同版本的镜像、容易分辨,并且提供足够的信息来查找正确的部署描述符,以便镜像更好地部署到 COP。

再回顾下上面的场景:

场景 A 镜像被推到下游环境: 当镜像被从测试环境推到 UAT 环境时,我们可以从镜像的标签中知道应该从 SCM 的哪一次源码提交拉取部署描述符。

场景 B 当一个镜像需要在某一环节中回滚:无论我们选择回滚到那个镜像版本,我们都可以知道从 SCM 的哪一次源码提交拉取正确的部署描述符。

在每一种情景中,无论在某个镜像被部署到测试环境后开发分支有多少次提交和构建,对于每一次升级的镜像,我们都可以找到它当初部署时对应的部署描述符。

然而,这并不是阻抗失配的完整解决方案。再考虑两个场景:

场景 C 在负载测试环境中,会尝试对不同的部署描述符进行多次部署,以此来验证某一次构建的表现。

场景 D 一个镜像被推送到下游环境,在该环境中部署描述符有一个错误。

在上面的所有场景中,我们都需要修改部署描述符,但是目前为止我们只有一个源码提交哈希。请记住,最佳实践要求我们所有对源码的修改都要先提交到 SCM。某次提交的哈希本身是无法修改的,因此我们需要一个比仅仅追踪原来的源码提交哈希更好地解决方案。

解决方案是基于原来的源码提交哈希新建一个分支。我们把这个分支称为部署分支。每当一个镜像被推到下游测试或发布环境时,你应该基于前一个 SDLC 环境的部署分支的最新提交创建一个新的部署分支。

这样同一个镜像可以重复多次部署到不同的 SDLC 环境,并在后面每个环境中可以感知前面发现的改动或对镜像做的修改。

注意: 在某个环境中做的修改是如何影响下一个环境的,是用可以共享数据的工具(如 Helm Charts)还是手动剪切、粘贴到其他目录,都不在本文讨论的范围内。

因此,当一个镜像被从一个 SDLC 环境中推到下一环境时:

  1. 创建一个部署分支

    1. 如果镜像是从开发环境中推过来的,那么部署分支就基于构建这个镜像的源码提交哈希创建
    2. 否则,部署分支基于当前部署分支的最新提交创建
  2. 镜像被部署到下一个 SDLC 环境,使用的部署描述符是该环境中新创建的部署分支的部署描述符

deployment branching tree

图 1:部署分支树

  1. 部署分支
  2. 下游环境的第一个部署分支,只有一次提交
  3. 下游环境的第二个部署分支,只有一次提交

有了部署分支这个解决方案,再回顾下上面的场景 C 和场景 D:

场景 C 修改已经部署到下游 SDLC 环境中的镜像的部署描述符

场景 D 修复某个 SDLC 环境中部署描述符的错误

两个场景中,工作流如下:

  1. 把对部署描述符做的修改提交到 SLDC 环境和镜像对应的部署分支
  2. 通过部署分支最新提交对应的部署描述符把镜像重新部署到 SLDC 环境

这样,部署分支彻底解决了(存储着代表一次独一无二的构建的单一的、不可修改的镜像的)镜像仓库与(存储着对应一个或多个 SDLC 环境的可修改的部署描述符的)SCM 仓库之间的阻抗失配。

实践中的思考

这看起来像是行得通的解决方案,但同时它也为开发者和运维人员带来了新的实践中的问题,比如:

A. 为了更好地管理部署分支,部署描述符作为资源应该保存在哪里,是否要与构建镜像的源码保存在同一个 SCM 仓库?

到目前为止,我们都在避免谈论应该把部署描述符放在哪个仓库里。在还没有太多细节需要处理时,我们推荐把所有 SDLC 环境的部署描述符与镜像源码放在同一个 SCM 仓库。当部署分支创建后,镜像的源码可以作为方便找到部署的容器中运行的镜像的引用来使用。

上面提到过,可以通过镜像的标签来关联镜像与原始的源码提交。在一个单独的仓库中查找某次提交的源码的引用,会给开发者带来更大的困难(即便借助工具),这就是没有必要把所有资源都分开存储的原因。

B. 应该在部署分支上修改构建镜像的源码吗?

简答:不应该

详细阐述:不应该,因为永远不要在部署分支上构建镜像,它们是在开发分支上构建的。修改部署分支上定义一个镜像的源码会破坏被部署的镜像的构建记录,而且这些修改并不会对镜像的功能生效。在对比两个部署分支的版本时这也会成为问题。这可能会导致两个版本的功能差异有错误的测试结果(这是使用部署分支的一个很小的额外好处)。

C. 为什么使用镜像 标签 tag 标记 label 不可以吗?

通过 标签 tag 可以在仓库中很容易地查找镜像,可读性也很好。在一组镜像中读取和查找 标记 label 的值需要拉取所有镜像的 清单文件 manifest ,而这会增加复杂度、降低性能。而且,考虑到历史记录的追踪和不同版本的查找,对不同版本的镜像添加 标签 tag 也很有必要,因此使用源码提交哈希是保证唯一性,以及保存能即时生效的有用信息的最简单的解决方案。

D. 创建部署分支的最佳实践是怎样的?

DevOps 最重要的三个原则:自动化、自动化、自动化。

依赖资源来持续地强迫遵循最佳实践,充其量只是碰运气,因此在实现镜像的升级、回滚等 CI/CD 流水线时,把自动化部署分支写到脚本里。

E. 对部署分支的命名规范有建议吗?

<部署分支标识>-<环境>-<源码提交哈希>

  • 部署分支标识: 所有部署分支范围内唯一的字符串;如 “deployment” 或 “deploy”
  • 环境: 部署分支适用的 SDLC 环境;如 “qa”(测试环境)、 “stg”(预生产环境)、 或 “prod”(生产环境)
  • 源码提交哈希: 源码提交哈希中包含原来构建被部署的镜像的源码,开发者可以通过它很容易地查找到创建镜像的原始提交,同时也能保证分支名唯一。

例如, deployment-qa-asdf78s 表示推到 QA 环境的部署分支, deployment-stg-asdf78s 表示推到 STG 环境的部署分支。

F. 你怎么识别环境中运行的哪个镜像版本?

我们的建议是把最新的部署分支提交哈希和源码提交哈希添加到 标记 中。开发者和运维人员可以通过这两个独一无二的标识符查找到部署的所有东西及其来源。在诸如执行回滚或前滚操作时,使用那些不同版本的部署的选择器也能清理资源碎片。

G. 什么时候应该把部署分支的修改合并回开发分支?

这完全取决于开发团队。

如果你修改的目的是为了做负载测试,只是想验证什么情况会让程序崩溃,那么这些修改不应该被合并回开发分支。另一方面,如果你发现和修复了一个错误,或者对下游环境的部署做了调整,那么就应该把部署分支的修改合并回开发分支。

H. 有现成的部署分支示例让我们试水吗?

el-CICD 已经在生产上使用这个策略持续一年半应用到超过一百个项目了,覆盖所有的 SDLC 环境,包括管理生产环境的部署。如果你可以访问 OKD、Red Hat OpenShift lab cluster 或 Red Hat CodeReady Containers,你可以下载el-CICD 的最新版本,参照 教程 来学习部署分支是何时以怎样的方式创建和使用的。

结语

通过实践上面的例子可以帮助你更好的理解开发过程中阻抗失配相关的问题。对齐镜像和部署描述符是成功管理部署的关键部分。


via: https://opensource.com/article/21/8/impedance-mismatch-cicd

作者:Evan "Hippy" Slatis 选题:lujun9972 译者:lxbwolf 校对:wxy

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

黑掉你的系统,了解为什么配置 SELinux 作为你的第一道容器防线是很重要的。

 title=

当有些事情在你的 Linux 环境中不能正常工作时,最简单的方法就是禁用 安全增强型 Linux Security-Enhanced Linux SELinux)。而当它突然可以工作了,你就会忘记了禁用这件事 —— 这是一个常见的陷阱,意味着你已经失去了一个非常强大的安全工具。

随着容器、微服务和分布式架构的兴起,威胁也在上升。这是由于一个老的、众所周知的问题:速度。容器的优势在于它们能让你快速行动,做更多的事情,并迅速改变。这意味着容器的采用已经飞速发展,但它所提供的速度也意味着你会遇到更多的问题和漏洞。当你越来越快地做更多的事情时,这自然会发生。

如何减轻威胁

正如孙子所说,“不战而屈人之兵”。当涉及到容器的基本防御时,这句话真的很有共鸣。为了避免问题(战斗),确保你的容器主机是安全的,你可以使用 SELinux 作为你的第一道防线。

SELinux 是一个开源项目,于 2000 年发布,2003 年集成到 Linux 内核中。根据 红帽公司的解释,“SELinux 是 Linux 系统 的一个安全架构,允许管理员对谁可以访问系统有更多的控制。它最初是由美国国家安全局(NSA)开发的,是使用 Linux 安全模块(LSM)对 Linux 内核 的一系列补丁。”

开始吧

当你想到容器时,首先想到的可能是 Docker。Docker 在 2013 年出现后掀起了一场容器采用革命。它是容器爆炸性流行的主要原因之一,但如上所述,大量采用增加了用户对安全风险的脆弱性。

在你用 SELinux 保护你的 Docker 容器之前,你需要设置一些东西。

前置条件

  • 安装并配置了 CentOS 8/RHEL 8。
  • 安装并配置好 Docker CE
  • 创建两个账户:root 和 非 root 用户(下面的例子中是 mcalizo)。

如果你需要在你的 RHEL 8/CentOS 8 服务器上设置 Docker,你可以按照这些 说明。如果你运行的是 RHEL 8,你需要在开始之前删除预装的 Podman 和 runc 包。

首先,确保 SELinux 被启用:

[mcalizo@Rhel82 ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31
[mcalizo@Rhel82 ~]$

然后,验证你的操作系统版本和 Docker 正在运行。以 root 身份登录并运行:

[root@rhel82 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.2 (Ootpa)
[root@rhel82 ~]#

[root@rhel82 ~]# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-10-28 19:10:14 EDT; 15s ago
     Docs: https://docs.docker.com
 Main PID: 30768 (dockerd)
    Tasks: 8
   Memory: 39.0M
   CGroup: /system.slice/docker.service
           └─30768 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.889602941-04:00" level=error msg=">
Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903413613-04:00" level=warning msg>
Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903427451-04:00" level=warning msg>
Oct 28 19:10:13 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:13.903538271-04:00" level=info msg="L>
Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.132060506-04:00" level=info msg="D>
Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.308943088-04:00" level=info msg="L>
Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.319438549-04:00" level=info msg="D>
Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.319570298-04:00" level=info msg="D>
Oct 28 19:10:14 rhel82.home.labs.com dockerd[30768]: time="2020-10-28T19:10:14.333419209-04:00" level=info msg="A>
Oct 28 19:10:14 rhel82.home.labs.com systemd[1]: Started Docker Application Container Engine

检查你的 Docker 版本:

[root@rhel82 ~]# docker --version
Docker version 19.03.13, build 4484c46d9d

黑掉主机

了解一个问题的最好方法之一就是去体验它。因此,我将告诉你,如果你的安全设置不当,向 Docker 主机注入恶意代码是多么容易。

为了能够在 Docker 主机上做坏事,“恶意”的非 root 用户(本教程中为 mcalizo)必须是可以实例化 Docker 容器的组的成员。

首先,确认 mcalizo 用户属于哪个组:

[root@Rhel82 ~]# groups mcalizo
mcalizo : mcalizo

输出显示,mcalizo 只属于它自己的组。这意味着 mcalizo 不能实例化 Docker 容器,如果它试图这样做,将会得到这个错误:

[mcalizo@Rhel82 ~]$ docker run -it --rm centos:latest /bin/sh
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.

要允许 mcalizo 实例化容器,将用户加入 docker 组:

[root@Rhel82 ~]# usermod -G docker -a mcalizo
[root@Rhel82 ~]# groups mcalizo
mcalizo : mcalizo docker

接下来,部署一个 fedora:latest 的容器,并登录到实例化的容器中去探索它:

[mcalizo@Rhel82 ~]$ docker run -it --rm fedora:latest /bin/sh
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
ee7e89337106: Pull complete
Digest: sha256:b9ec86d36fca7b1d3de39cd7c258e8d90c377d312c21a7748071ce49069b8db4
Status: Downloaded newer image for fedora:latest
sh-5.0# cat /etc/redhat-release
Fedora release 33 (Thirty Three)

当你登录到新创建的容器时,你可以看到你是以 root 身份自动登录的:

sh-5.0# whoami
root
sh-5.0#

作为 root 用户,你可以在这个容器中做任何事情,这意味着你可以利用容器主机,做很多破坏。因为你可以实例化一个容器,即使你不属于主机的 sudoers 账户,你也可以对主机做一些事情。

退出你刚刚创建的容器,并创建一个新的容器来演示这个漏洞:

[mcalizo@Rhel82 ~]$ docker run -it --rm -v /:/exploit fedora:latest /bin/bash
[root@131043f2e306 /]#

-v 选项 将 Docker 主机的 / 目录挂载到 /exploit 目录下的容器:

[root@131043f2e306 /]#ls exploit/
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

因为它已被挂载,你可以在 Docker 主机上做任何事情。例如,你可以删除文件、编辑特定的配置来破害系统,甚至安装木马程序或其他恶意软件来窃取重要信息。

为什么会发生这种情况?

你可能想知道,既然 SELinux 处于强制模式,为什么会出现这种情况?深入挖掘 SELinux,看看哪里出了问题。

验证 SELinux 是否有一个 Docker 上下文

[mcalizo@Rhel82 ~]$ ps -eZ | grep docker
system_u:system_r:container_runtime_t:s0 30768 ? 00:00:04 dockerd
[mcalizo@Rhel82 ~]$

正如预期的那样,它确实有。这意味着 SELinux 管理着 Docker 守护进程。检查 Docker 守护进程,看看 SELinux 是否默认启用:

[mcalizo@Rhel82 ~]$ docker info | grep Security -A3
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.18.0-193.el8.x86_64

Docker 守护进程中的 SELinux 在默认情况下是 不启用 的。 这就是问题所在!要解决这个问题,按 文档 说明,通过更新或创建文件 /etc/docker/daemon.json 来启用 SELinux 来控制和管理 Docker(你必须有 root 权限才能这样做):

[root@Rhel82 ~]# cat /etc/docker/daemon.json
{
  "selinux-enabled": true
}
[root@Rhel82 ~]#
[root@Rhel82 ~]# systemctl restart docker

在创建或更新该文件并重启 Docker 后,你应该看到 Docker 守护进程中启用了 SELinux 支持:

[root@Rhel82 ~]# systemctl restart docker
[mcalizo@Rhel82 root]$ docker info | grep Security -A3
 Security Options:
  seccomp
   Profile: default
  selinux
[mcalizo@Rhel82 root]$

虽然仍然可以在你的 Docker 容器上挂载 Docker 主机中的特定文件系统,但不再允许更新或访问该文件:

[mcalizo@Rhel82 root]$ docker run -it --rm -v /:/exploit fedora:latest /bin/bash
[root@ecb5836da1f6 /]# touch /exploit/etc/shadow.sh
touch: cannot touch '/exploit/etc/shadow.sh': Permission denied
[root@ecb5836da1f6 /]#

了解更多

你在容器世界中的第一道防线取决于你对容器主机的操作系统的设置有多强。有许多方法可以实现 Linux 的安全性,包括市场上可供选择的方案,以增强你的安全态势。

SELinux 是一个额外的安全层,默认情况下内置于 Linux 发行版 中。为了借助它保护你的系统不被破坏,请确保 SELinux 保持开启状态。

如果你想了解更多,请参阅:


via: https://opensource.com/article/20/11/selinux-containers

作者:Mike Calizo 选题:lujun9972 译者:wxy 校对:wxy

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

通过查看创建一个吊舱或一个部署时的 10 个步骤,可以更好地了解 Kubernetes。

 title=

当你在 Kubernetes 上使用容器时,你经常把应用程序组合在一个 吊舱 pod 中。当你把一个容器或一个吊舱发布到生产环境中时,它被称为一个 部署 deployment 。如果你每天甚至每周都在使用 Kubernetes,你可能已经这样做过几百次了,但你有没有想过,当你创建一个吊舱或一个部署时到底会发生什么?

我发现在高层次上了解事件链条是有帮助的。当然,你不一定要理解它。即使你不知道为什么,它仍然在工作。我不打算列出每一件发生的小事,但我的目标是涵盖所有重要的事情。

这里有一张 Kubernetes 不同组件如何互动的视觉地图。

 title=

你可能注意到,在上图中,我没有包括 etcd。API 服务器是唯一能够直接与 etcd 对话的组件,而且只有它能够对 etcd 进行修改。因此,你可以认为 etcd 在这张图中存在于(隐藏的)API 服务器后面。

另外,我在这里只讲到了两个主要的控制器( 部署控制器 Deployment controller 复制集控制器 ReplicaSet controller )。其他的控制器的工作方式类似。

下面的步骤描述了当你执行 kubectl create 命令时会发生什么。

步骤 1

当你使用 kubectl create 命令时,一个 HTTP POST 请求被发送到 API 服务器,其中包含部署清单。API 服务器将其存储在 etcd 数据存储中,并返回一个响应给 kubectl

步骤 2 和 3

API 服务器有一个观察机制,所有观察它的客户都会得到通知。客户端通过打开与 API 服务器的 HTTP 连接来观察变化,API 服务器会流式地发出通知。其中一个客户端是部署控制器。部署控制器检测到一个 部署 Deployment 对象,它用部署的当前规格创建一个 复制集 ReplicaSet 。该资源被送回 API 服务器,并存储在 etcd 数据存储中。

步骤 4 和 5

与上一步类似,所有观察者都会收到关于 API 服务器中的变化的通知。这一次,复制集控制器会接收这一变化。该控制器了解所需的副本数量和对象规格中定义的吊舱选择器,创建吊舱资源,并将这些信息送回 API 服务器,存储在 etcd 数据存储中。

步骤 6 和 7

Kubernetes 现在拥有运行吊舱所需的所有信息,但吊舱应该在哪个节点上运行? 调度器 Scheduler 观察那些还没有分配到节点的吊舱,并开始对所有节点进行过滤和排序,以选择最佳节点来运行吊舱。一旦节点被选中,该信息将被添加到吊舱规格中。而且它被送回 API 服务器并存储在 etcd 数据存储中。

步骤 8、9 和 10

到目前为止的所有步骤都发生在 控制平面 control plane 本身。 工作节点 worker node 还没有做任何工作。不过,吊舱的创建并不是由控制平面处理的。相反,在所有节点上运行的 kubelet 服务观察 API 服务器中的吊舱规格,以确定它是否需要创建任何吊舱。在调度器选择的节点上运行的 kubelet 服务获得吊舱规格,并指示工作节点上的容器运行时创建容器。这时就会下载一个容器镜像(如果它还不存在的话),容器就会实际开始运行。

理解 Kubernetes 的部署

对这个一般流程的理解可以帮助你理解 Kubernetes 中的许多事件。考虑一下 Kubernetes 中的 守护进程集 DaemonSet 状态集 StatefulSet 。除了使用不同的控制器外,吊舱的创建过程是一样的。

课后作业:如果部署被修改为有三个应用程序的副本,导致创建吊舱的事件链条会是什么样子?你可以参考图表或列出的步骤,但你肯定有你需要弄清楚的知识。知识就是力量,你现在有了了解 Kubernetes 的一个重要组成部分。


via: https://opensource.com/article/22/3/visual-map-kubernetes-deployment

作者:Nived Velayudhan 选题:lujun9972 译者:wxy 校对:wxy

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

如果你是容器的新手,不要被那些术语所吓倒。这些关键原则将帮助你把应用迁移到云中。

 title=

一般来说,人们想使用你的应用程序这是一件好事。然而,当应用程序在服务器上运行时,应用程序受欢迎是有代价的。随着用户对资源需求的增加,在某些时候,你可能会发现你需要扩展你的应用程序。一种选择是在这种情况下增加更多的服务器,建立一个像 Nginx 这样的 负载平衡器,以满足需求。但是,这种方法的成本可能很昂贵,因为当需求低的时候,在没有流量的服务器上运行你的应用程序的实例并不会节省资源。容器的优点是它是非持久的,在有需求时启动新实例,而随着需求的减少逐渐消失。如果这听起来像是你需要的功能,那么现在可能是将你的应用程序迁移到容器的时候了。

将应用程序迁移到容器中,很快就会变得迷失方向。虽然容器内的环境可能感觉很熟悉,但许多容器镜像是最小化的,而且它们被设计为无状态的。不过在某种程度上,这也是容器的优势之一。就像 Python 虚拟环境一样,它是一块白板,可以让你构建(或重建)你的应用程序,而没有许多其他环境所提供的无形的默认值。

每一次向云服务的迁移都是独一无二的,但在将你的应用程序移植到容器之前,你应该注意以下几个重要原则。

1、理解你的依赖关系

将你的应用程序移植到容器中是一个很好的机会,可以了解你的应用程序实际依赖的东西。由于除了最基本的系统组件外,很少有默认安装的组件,你的应用程序一开始不太可能在容器中运行。

在重构之前,确定你的依赖关系。首先,在你的源代码中用 grep 查找 includeimportrequireuse 或你选择的语言中用来声明依赖关系的任何关键词。

$ find ~/Code/myproject -type f \
    -iname ".java" \
    -exec grep import {} \;

不过,仅仅识别你使用的特定语言的库可能是不够的。审计依赖关系,这样你就能知道是否有语言本身运行所需的低级库,或者特定的模块以预期的功能运行。

2、评估你的数据存储

容器是无状态的,当一个容器崩溃或停止运行时,该容器的实例就永远消失了。如果你要在该容器中保存数据,这些数据也会消失。如果你的应用程序存储用户数据,所有的存储必须发生在容器之外,在你的应用程序的实例可以访问的某个位置。

你可以使用映射到容器内某个位置的本地存储来存储简单的应用程序配置文件。这是一种常见的技术,适用于需要管理员提供简单配置值的 Web 应用程序,如管理员的电子邮件地址、网站标题等。比如说:

$ podman run \
    --volume /local/data:/storage:Z \
    mycontainer

然而,你可以配置一个数据库,如 MariaDB 或 PostgreSQL,将大量数据在几个容器中的共享存储。对于私人信息,如密码,你可以配置一个机密存储

对于你需要如何重构你的代码,相应地调整存储位置,这可能意味着改变路径到新的容器存储映射,移植到不同的数据库,甚至是纳入容器特定的模块。

3、准备好你的 Git 仓库

容器在构建时通常会从 Git 仓库中拉取源代码。一旦你的 Git 仓库成为你的应用程序的生产就绪代码的标准来源,你必须有一个管理 Git 仓库的计划。要有一个发布分支或生产分支,并考虑使用 Git 钩子 来拒绝意外的未经批准的提交。

4、了解你的构建系统

容器化应用程序可能没有传统的发布周期。当容器被构建时,它们会被从 Git 中拉取出来。你可以启动任何数量的构建系统作为容器构建的一部分,但这可能意味着调整你的构建系统,使其比过去更加自动化。你应该重构你的构建过程,使你完全有信心它能在无人值守的情况下工作。

5、构建镜像

构建镜像不一定是复杂的任务。你可以使用 现有的容器镜像 作为基础,用一个简单的 Docker 文件对其进行调整。另外,你也可以使用 Buildah 从头开始构建你自己的镜像。

在某种程度上,构建容器的过程与实际重构代码一样,都是开发的一部分。容器的构建是为了获取、组装和执行你的应用程序,所以这个过程必须是自动化的、健壮的。建立一个好的镜像,你就为你的应用程序建立了一个坚实可靠的基础。

容器化

如果你是容器的新手,不要被术语所吓倒。容器只是另一种环境。容器化开发的感知约束实际上可以帮助你专注于你的应用程序,并更好地了解它是如何运行的、它需要什么才能可靠地运行,以及当出错时有哪些潜在的风险。相反,这导致系统管理员在安装和运行你的应用程序时受到的限制要少得多,因为从本质上讲,容器是一个受控的环境。仔细审查你的代码,了解你的应用程序需要什么,并相应地重构它。


via: https://opensource.com/article/22/2/migrate-application-containers

作者:Alan Smithee 选题:lujun9972 译者:wxy 校对:wxy

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