wordpress小说站,企业网站建设作用,seo需要会什么,小企业做网站多少钱作者 | Timothy Mugayi译者 | 弯月#xff0c;责编 | 夕颜封图 | CSDN付费下载自视觉中国出品 | CSDN#xff08;ID:CSDNnews#xff09;在使用Docker的大部分时间里#xff0c;我们并不关心其内部的工作原理。仅凭启动一个Docker容器并且让应用程序运行良好#xff0c;并… 作者 | Timothy Mugayi译者 | 弯月责编 | 夕颜封图 | CSDN付费下载自视觉中国出品 | CSDNID:CSDNnews在使用Docker的大部分时间里我们并不关心其内部的工作原理。仅凭启动一个Docker容器并且让应用程序运行良好并不能说明你已经实现了一个良好的解决方案。有时由于时间限制我们只能复制粘贴Docker镜像却没能真正理解实现细节以及如何构建Docker镜像的细微差别。 在本文中我们将探讨Docker的最佳实践和反模式。反模式是人们对于反复出现的问题的一般解决方案这些方案没有效率甚至会完全抵消Docker技术栈带来的好处。 下面我们来看看我们的哪些做法不可取。 我们需要的标签 标签是必不可少的我们需要通过标签传达有关Docker镜像的信息。你可以将标签视为Docker镜像ID的别称。Git标签负责标记特定的提交而Docker标签与之类似可以给不同时间点上的Docker镜像添加版本。忘记打标签是小事但会带来一些弊端具体来讲如果未指定标记则默认镜像将被标记为latest。 FROM your_image_name:latest如果你频繁执行该操作那么很有可能镜像不是最新的可能指向的是旧版本。因此请使用适当的标签并遵守某个版本控制标准例如语义版本控制。这样Docker镜像使用者才能确保Docker镜像的兼容性并时刻保持最新还可以有计划地使用正确的版本。 还有一个情况应该避免。你可以利用最新的默认标签如FROM python3:latest从Docker镜像仓库中提取最新的镜像。乍一看这种做法似乎是个好主意但却有一些意想不到的副作用每个最新的请求可能都会派生出与以前的构建完全不同的Docker镜像。弄明白Docker镜像损坏的原因将会变得很困难因为镜像本应该是不可变的。因此我强力建议使用特定的标签来标记镜像例如python3:1.0.1。这种方法可以确保你的Dockerfile保持不变。 在同一个容器中运行多个服务 虽然你可以在同一个容器中运行多个服务但我并不建议你这么做原因有两个。在使用Docker服务时我们应该努力维持责任单一性。最佳做法是组成应用程序的每个服务都应在各自的容器中运行请务必将每项独立的功能都打包到单独的独立容器镜像中。 将多个服务添加到一个Docker镜像的做法似乎很诱人但是你不应该将容器镜像视为虚拟机。一个容器包含多个服务可能会导致你的应用程序很难水平扩展。Docker容器核心概念是它们都是瞬态的专为分发而设计这对于现代Web应用程序来说很理想因为它的瞬态特性、扩展和并发会非常容易。添加多个服务会增加管理分发的难度。 另外单个容器上的多个服务还会加大管理安全性的难度。庞大的镜像可能会降低CI/CD的速度你需要小心。 使用LABEL对镜像进行分类 这并不能说是反模式但我认为值得一提。我在处理各种Docker镜像时注意到了一件事有时这些镜像的创建者没有使用LABEL maintainer标签。这个标签可在事件中设置镜像的Author字段当出现问题或需要澄清时这个标签可以方便大家了解该与何人内部联系如果镜像是公开共享的也可以知道该与哪个外部的人联系。 这绝不是唯一可以使用的标签。你可以根据需要定义各种标签来对镜像进行分类定义许可信息也可以定义标签来帮助自动化。 除了maintainer还可以使用多行标签# Set one or more individual labels
LABEL com.example.version0.0.1-beta
LABEL vendor1RBTSB Incorporated
LABEL vendor2TIPTAPCODE\ Incorporated
LABEL com.example.release-date202-04-02
LABEL com.example.version.production0.0.1
Docker 1.10之前的单行标签会创建新的docker层如果你使用的是最新版的Docker则不必担心创建额外的层。LABEL vendorACME\ Incorporated \
com.example.is-beta \
com.example.is-production \
com.example.version0.0.1-beta \
com.example.release-date2015-02-12
我们应该将尽可能多的元数据添加到不可变的Docker镜像以方便追踪提高可见性和可维护性。 避免构建依赖特定环境的镜像 在构建Docker镜像时我们应始终牢记不变性。最好不要使用带有dev、test、staging和production的镜像因为这会破坏单一来源的原则。另一个问题是如果在不同环境上验证或调试则这种做法无法保证镜像的相似。 为什么要使用非Root容器 在默认情况下Docker容器以root身份运行。以root用户身份运行的Docker容器可以完全控制主机系统。然而出于安全考虑我并不推荐这种做法。使用非root运行的Docker容器镜像可以多一层保护在生产环境中通常建议使用非root容器。但是由于这些容器由非root用户运行因此无法执行需要特殊权限的任务。如果需要利用USER指令指定非root用户如以下示例所示则需要进行一些上下文切换。 FROM python:3.6-slim-buster
LABEL maintainerTimothy Mugayi timothy.mugayigmail.comRUN apt-get update apt-get install -y --no-install-recommends \
wget rm -rf /var/lib/apt/lists/*# Dumb init
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64
RUN chmod x /usr/local/bin/dumb-initRUN pip install --upgrade pipWORKDIR /usr/src/appCOPY requirements.txt .RUN pip install -r requirements.txtCOPY helloworld.py .USER 1001ENTRYPOINT [/usr/local/bin/dumb-init, python3, -u, ./helloworld.py]
如果你使用的基础镜像不是由root生成的但需要切换回root则可以执行以下操作 FROM namespace/image:tag_versionUSER root
不要在单个容器内运行太多进程 容器的优点以及容器相对于虚拟机的优势在于通过多个相互交互的容器组成一个完整的应用程序。我们无需在单个容器中运行完整的应用程序。相反我们应尽可能将应用程序分解为多个服务并将服务分布到多个容器上。这样可以最大程度地提高灵活性和可靠性。 不要在容器内安装操作系统 使用一段时间Docker后你就有可能遇到这种情况。虽然你可以在容器内安装和运行完整的Linux操作系统。但是你应该这样做吗 这可能不是一个好主意。Docker镜像是使用层的概念构建的因此添加的东西越多镜像就会膨胀得越大。一个完整的操作系统并不是Docker的理想使用情况。在理想情况下你的容器内部只应该加载必要的组件。 不要在容器内运行不必要的服务 为了充分利用容器的优势你应该尽可能保持容器精简。这样可以最大程度地提高性能并最大程度地降低安全风险。因此请避免运行并非绝对必要的服务。例如若非必要请不要在容器内运行SSH服务你可以选用其他方式例如Docker exec登录到容器。 不要在容器内加载不必要的程序 你必须知道这种反模式。在使用Docker时很多人倾向于在镜像中加载sonar之类的工具来确保代码覆盖率等。 使用从Docker CE 17.05开始支持的多阶段构建Multistage builds模式你可以在Dockerfile中使用多个FROM stage。临时构建的阶段容器将被丢弃因此最终的运行时容器镜像都很精简。举个例子当你需要从源文件编译一些二进制文件然后在第二个阶段中将二进制文件复制到最终镜像中。 优点 构建速度更快精简的镜像可以让CI/CD过程更快镜像通过网络进行传输时花费的时间也更少。需要的存储空间更少。冷启动拉取镜像更快。潜在的受攻击面更少。 缺点 容器内的工具较少但这是保证容器的精简所需付出的一点小小的代价。在容器内加入供观察的工具 即便没有监视解决方案你也可以照常运行容器但需要牢记从本质上来说你很难知道容器内部发生了什么特别是随着容器数量的增加。 Docker本身自带了许多指标能够公开每个运行容器的CPU、内存、网络和I/O使用情况可通过Docker远程API的/stats端点访问。App dynamics 和 Newrelic 是两个现成的程序可以与Docker镜像一起打包帮助你从应用程序级别了解应用程序和容器的运行状况。 基础镜像的爱恨交织 “你知道是谁构建了这个景象里面都添加了什么吗” 这里说的都是可追溯性。牢记安全性是所有软件开发人员都应努力的方向。你需要了解如何跟踪Docker镜像的源并了解里面有什么。 你需要时刻牢记以下几点 镜像是怎样创建的。验证镜像在创建后未经更改。验证镜像的内容。扫描镜像是否有安全漏洞。 我们可以通过一些工具对容器进行静态分析。这些工具涉及方方面面已超出了本文的范围但是我建议你花一些时间来学习。 Clair是一个有趣的工具可为你的Docker应用程序提供自动容器漏洞和安全扫描。扫描基于常见的漏洞和公开CVE的数据库。如果你本地运行Docker则可以下载Postgres然后将Clair连接到Postgres上。以下是启动和运行Clair所需的最低配置$ mkdir $PWD/clair_config
$ curl -L https://raw.githubusercontent.com/coreos/clair/master/config.yaml.sample -o $
PWD/clair_config/config.yaml
$ docker run -d -e POSTGRES_PASSWORD -p 5432:5432 postgres:9.6
$ docker run --nethost -d -p 6060-6061:6060-6061 -v
PWD/clair_config:/config quay.io/coreos/clair:latest -config/config/config.yaml
如果你想更改Postgres的端口请确保同时修改config.yaml文件。如果你的系统上已经运行了另一个Postgres请注意不要将docker端口更改为5432以外的端口。 clair:
database:
# Database driver
type: pgsql
options:
# PostgreSQL Connection string
# https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING
source: hostlocalhost port5432 userpostgres password123456 sslmodedisable statement_timeout60000
在镜像启动并执行后你可以运行Docker ps来确认容器已启动且正常运行你需要注意Clair没有Web UI或CLI。你只能通过REST API或第三方CLI工具来使用。 Bayan Collector是一款轻巧的静态分析应用程序可以从镜像仓库启动容器以进行静态分析可以运行任意脚本并收集有用的信息例如已安装的软件包强制执行策略以及对镜像进行校验。 Docker Bench for Security是由Docker团队创建的工具它会在Docker的宿主上运行一个安全最佳做法清单并标记发现的任何问题。 不要在容器镜像中存储敏感数据 请一定避免这个错误。如果你的镜像对外公开或者开发人员无意中将镜像推送到公共的Docker镜像仓库中那么就会导致隐私和敏感信息的泄露。切记永远不要在Dockerfile中对敏感信息使用COPY或。 为了避免这种情况请将敏感数据存储在安全文件系统上并让容器进行连接。一般情况下这个文件系统应该在容器所在的宿主上或者可通过AWS Elastic Block StorageEBS等块存储或S3等对象存储服务来使用。 此外你应避免在Docker镜像中存储安全凭证。作为开发人员有时我们会采用偷懒的做法在代码中硬编码密码和私钥。你需要习惯使用-e参数在运行时为Docker容器指定环境变量。 你也可以通过env-file从文件中读取环境变量。通过CMD或从第三方来源获取凭据的自定义脚本也可用于获取Docker容器所需的相关凭据。 不要在容器内存储数据或日志 容器化改变了日志的性质。容器是瞬态、无状态应用程序的理想选择。本质上存储在运行容器中的所有数据都应该是短暂的你可能已经注意到当容器关闭时数据将丢失。因此将数据存储在Docker容器之外的做法更值得推崇。有一些工具可以帮助你提取Docker日志并将其放在更永久的数据存储中。 在处理Docker日志时需要牢记一点Docker至少拥有三个级别的日志记录即Docker容器、Docker服务和宿主操作系统你选择的日志记录方法应该能够提取所有级别的日志。 不要写入容器的文件系统 每次将内容写入容器的文件系统都会激活“写时复制”策略。这会使用存储驱动程序deviermapper、overlayfs或其他驱动创建新的存储层。在实际应用中这会给存储驱动带来巨大的压力特别是使用Devicemapper或BTRFS的情况下。 确保容器只向卷中写入数据。对于小型的临时文件可以写入tmpfs因为tmpfs是仅存在于内存或交换分区中的临时文件系统。 不要运行PID 1 这是许多人都不知道的常见问题。 Docker中的进程运行时没有init进程负责清理子进程所以容器可能会出现僵尸进程导致意料之外的错误。 使用tini或dumb-init PID 1在Unix中很特殊因此在init系统中忽略它通常会导致进程和信号处理错误。这会导致类似于容器无法优雅地停止或本应摧毁的容器出现泄露等问题。 僵尸进程指的是运行已经停止但依然在进程表中占据位置的进程因为它们的父进程没有调用wait系统调用进行回收。理论上每个结束的进程都会非常短暂地呈现僵尸状态但有些进程的僵尸状态会持续很久。 如果某个进程会生成新进程但信号处理的实现不好无法捕获子进程的信号并将其终止那么可以使用Tini或dumb-init。例如bash脚本就无法正确处理或释放信号。 下面是运行dumb init的示例其中prepare.sh可以是shell脚本也可以是用于执行应用程序的命令RUN wget -O
/usr/local/bin/dumb-init
https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64RUN chmod x /usr/local/bin/dumb-initENTRYPOINT [/usr/local/bin/dumb-init, /usr/bin/prepare.sh]
或者如果你选择tini可以参考下面使用Python anaconda conda的示例 RUN conda install --yes -c
conda-forge tiniENTRYPOINT [tini, -g, --, /usr/bin/prepare.sh]最后这里是一个更一般的示例不依赖于任何编程语言 FROM node:13.12.0-slimMAINTAINER Timothy Mugayi timothy.mugayigmail.comENV TINI_VERSIONv0.13.0
# Add tini init, see https://github.com/krallin/tini
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tiniRUN chmod x /tini
# Set tini as entrypoint
ENTRYPOINT [/tini, --]
在CI/CD中使用Dockerfile格式检查 跟编程语言一样Docker也有格式检查工具。 采用格式检查工具有许多好处因为它会强制你使用最佳实践。在CI/CD过程中加入格式检查可以帮助团队避免常见的错误并在构建产品Docker镜像时建立最佳实践。可以从hadolint开始这是一个用Haskell编写的Dockerfile格式检查工具能够解析Dockerfile成AST并在AST上执行规则检查。 我们来运行一个示例。要对Docker进行格式检查可以执行以下命令$ docker run --rm -i
hadolint/hadolint Dockerfile格式检查完成后会显示以下结果 上图中的错误码DL3008“Pin”来自hadolint的错误码描述状态。固定版本号可以强制构建时安装特定版本的包不论缓存中是什么。这个技巧可以减少依赖包意料之外的改变导致的构建错误。 最后的一点想法 在本文中我们谈了很多内容覆盖了从安全到Docker镜像流水线的方方面面。 有许多技巧可以让Docker镜像更好、更安全。希望这篇文章可以给你带来一些启发帮助你理解应该做什么、不应该做什么并为你提供一些在构建内部或外部Docker容器镜像时可以应用的方案。 原文链接https://medium.com/better-programming/docker-best-practices-and-anti-patterns-e7cbccba4f19本文为CSDN翻译文章转载请注明出处。 推荐阅读大促下的智能运维挑战阿里如何抗住“双11猫晚”20万个法人、百万条银行账户信息正在暗网兜售当莎士比亚遇见Google Flax教你用字符级语言模型和归递神经网络写“莎士比亚”式句子Hyperledger Fabric 和企业级以太坊谁才是企业首选面试时遇到「看门狗」脖子上挂着「时间轮」我就问你怕不怕同期两篇 Nature运行温度高于 1K 的量子计算平台问世GitHub 标星 10,000Apache 顶级项目 ShardingSphere 的开源之路真香朕在看了
