在这篇文章中，我将分享企业环境下顶级的 Linux 发行版。其中一些发行版用于服务器和云环境以及桌面任务。所有这些可选的 Linux 具有的一个共同点是它们都是企业级 Linux 发行版 —— 所以你可以期待更高程度的功能性，当然还有支持程度。

什么是企业级的 Linux 发行版？

企业级的 Linux 发行版可以归结为以下内容 —— 稳定性和支持。在企业环境中，使用的 Linux 版本必须满足这两点。稳定性意味着所提供的软件包既稳定又可用，同时仍然保持预期的安全性。

企业级的支持因素意味着有一个可靠的支持机制。有时这是单一的（官方）来源，如公司。在其他情况下，它可能是一个非营利性的治理机构，向优秀的第三方支持供应商提供可靠的建议。很明显，前者是最好的选择，但两者都可以接受。

Red Hat 企业级 Linux（RHEL）

Red Hat 有很多很棒的产品，都有企业级的支持来保证可用。其核心重点如下：

• Red Hat 企业级 Linux 服务器：这是一组服务器产品，包括从容器托管到 SAP 服务的所有内容，还有其他衍生的服务器。
• Red Hat 企业级 Linux 桌面：这些是严格控制的用户环境，运行 Red Hat Linux，提供基本的桌面功能。这些功能包括访问最新的应用程序，如 web 浏览器、电子邮件、LibreOffice 等。
• Red Hat 企业级 Linux 工作站：这基本上是 Red Hat 企业级 Linux 桌面，但针对高性能任务进行了优化。它也非常适合于大型部署和持续管理。

为什么选择 Red Hat 企业级 Linux？

Red Hat 是一家非常成功的大型公司，销售围绕 Linux 的服务。基本上，Red Hat 从那些想要避免供应商锁定和其他相关问题的公司赚钱。这些公司认识到聘用开源软件专家和管理他们的服务器和其他计算需求的价值。一家公司只需要购买订阅来让 Red Hat 做支持工作就行。

Red Hat 也是一个可靠的社会公民。他们赞助开源项目以及像 OpenSource.com 这样的 FoSS 支持网站（LCTT 译注：FoSS 是 Free and Open Source Software 的缩写，意为自由及开源软件），并为 Fedora 项目提供支持。Fedora 不是由 Red Hat 所有的，而是由它赞助开发的。这使 Fedora 得以发展，同时也使 Red Hat 受益匪浅。Red Hat 可以从 Fedora 项目中获得他们想要的，并将其用于他们的企业级 Linux 产品中。 就目前来看，Fedora 充当了红帽企业 Linux 的上游渠道。

SUSE Linux 企业版本

SUSE 是一家非常棒的公司，为企业用户提供了可靠的 Linux 选择。SUSE 的产品类似于 Red Hat，桌面和服务器都是该公司所关注的。从我自己使用 SUSE 的经验来看，我相信 YaST 已经证明了，对于希望在工作场所使用 Linux 操作系统的非 Linux 管理员而言，它拥有巨大的优势。YaST 为那些需要一些基本的 Linux 命令行知识的任务提供了一个友好的 GUI。

SUSE 的核心重点如下：

• SUSE Linux 企业级服务器（SLES）：包括任务特定的解决方案，从云到 SAP，以及任务关键计算和基于软件的数据存储。
• SUSE Linux 企业级桌面：对于那些希望为员工提供可靠的 Linux 工作站的公司来说，SUSE Linux 企业级桌面是一个不错的选择。和 Red Hat 一样，SUSE 通过订阅模式来对其提供支持。你可以选择三个不同级别的支持。

为什么选择 SUSE Linux 企业版？

SUSE 是一家围绕 Linux 销售服务的公司，但他们仍然通过专注于简化操作来实现这一目标。从他们的网站到其提供的 Linux 发行版，重点是易用性，而不会牺牲安全性或可靠性。尽管在美国毫无疑问 Red Hat 是服务器的标准，但 SUSE 作为公司和开源社区的贡献成员都做得很好。

我还会继续说，SUSE 不会太严肃，当你在 IT 领域建立联系的时候，这是一件很棒的事情。从他们关于 Linux 的有趣音乐视频到 SUSE 贸易展位中使用的 Gecko 以获得有趣的照片机会，SUSE 将自己描述成简单易懂和平易近人的形象。

Ubuntu LTS Linux

Ubuntu Long Term Release （LTS） Linux 是一个简单易用的企业级 Linux 发行版。Ubuntu 看起来比上面提到的其他发行版更新更频繁（有时候也更不稳定）。但请不要误解，Ubuntu LTS 版本被认为是相当稳定的，不过，我认为一些专家可能不太同意它们是安全可靠的。

Ubuntu 的核心重点如下：

• Ubuntu 桌面版：毫无疑问，Ubuntu 桌面非常简单，可以快速地学习并运行。也许在高级安装选项中缺少一些东西，但这使得其更简单直白。作为额外的奖励，Ubuntu 相比其他版本有更多的软件包（除了它的父亲，Debian 发行版）。我认为 Ubuntu 真正的亮点在于，你可以在网上找到许多销售 Ubuntu 的厂商，包括服务器、台式机和笔记本电脑。
• Ubuntu 服务器版：这包括服务器、云和容器产品。Ubuntu 还提供了 Juju 云“应用商店”这样一个有趣的概念。对于任何熟悉 Ubuntu 或 Debian 的人来说，Ubuntu 服务器都很有意义。对于这些人来说，它就像手套一样，为你提供了你已经熟知并喜爱的命令行工具。
• Ubuntu IoT：最近，Ubuntu 的开发团队已经把目标瞄准了“物联网”（IoT）的创建解决方案。包括数字标识、机器人技术和物联网网关。我的猜测是，我们将在 Ubuntu 中看到大量增长的物联网用户来自企业，而不是普通家庭用户。

为什么选择 Ubuntu LTS？

社区是 Ubuntu 最大的优点。除了在已经拥挤的服务器市场上的巨大增长之外，它还与普通用户在一起。Ubuntu 的开发和用户社区是坚如磐石的。因此，虽然它可能被认为比其他企业版更不稳定，但是我发现将 Ubuntu LTS 安装锁定到 “security updates only” 模式下提供了非常稳定的体验。

CentOS 或者 Scientific Linux 怎么样呢？

首先，让我们把 CentOS 作为一个企业发行版，如果你有自己的内部支持团队来维护它，那么安装 CentOS 是一个很好的选择。毕竟，它与 Red Hat 企业级 Linux 兼容，并提供了与 Red Hat 产品相同级别的稳定性。不幸的是，它不能完全取代 Red Hat 支持订阅。

那么 Scientific Linux 呢？它的发行版怎么样？好吧，它就像 CentOS，它是基于 Red Hat Linux 的。但与 CentOS 不同的是，它与 Red Hat 没有任何隶属关系。 Scientific Linux 从一开始就有一个目标 —— 为世界各地的实验室提供一个通用的 Linux 发行版。今天，Scientific Linux 基本上是 Red Hat 减去所包含的商标资料。

这两种发行版都不能真正地与 Red Hat 互换，因为它们缺少 Red Hat 支持组件。

哪一个是顶级企业发行版？我认为这取决于你需要为自己确定的许多因素：订阅范围、可用性、成本、服务和提供的功能。这些是每个公司必须自己决定的因素。就我个人而言，我认为 Red Hat 在服务器上获胜，而 SUSE 在桌面环境中轻松获胜，但这只是我的意见 —— 你不同意？点击下面的评论部分，让我们来谈谈它。

via: https://www.datamation.com/open-source/best-linux-distros-for-the-enterprise.html

作者：Matt Hartley 译者：MjSeven 校对：wxy

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

虽然现在不是万圣节，也可以关注一下 Linux 可怕的一面。什么命令可能会显示鬼、巫婆和僵尸的图像？哪个会鼓励“不给糖果就捣蛋”的精神？

crypt

好吧，我们一直看到 crypt。尽管名称不同，crypt 不是一个地窖，也不是垃圾文件的埋葬坑，而是一个加密文件内容的命令。现在，crypt 通常用一个脚本实现，通过调用一个名为 mcrypt 的二进制文件来模拟以前的 crypt 命令来完成它的工作。直接使用 mycrypt 命令是更好的选择。

$ mcrypt x
Enter the passphrase (maximum of 512 characters)
Please use a combination of upper and lower case letters and numbers.
Enter passphrase:
Enter passphrase:

File x was encrypted.

请注意，mcrypt 命令会创建第二个扩展名为 .nc 的文件。它不会覆盖你正在加密的文件。

mcrypt 命令有密钥大小和加密算法的选项。你也可以再选项中指定密钥，但 mcrypt 命令不鼓励这样做。

kill

还有 kill 命令 - 当然并不是指谋杀，而是用来强制和非强制地结束进程，这取决于正确终止它们的要求。当然，Linux 并不止于此。相反，它有各种 kill 命令来终止进程。我们有 kill、pkill、killall、killpg、rfkill、skill（）读作 es-kill）、tgkill、tkill 和 xkill。

$ killall runme
[1] Terminated ./runme
[2] Terminated ./runme
[3]- Terminated ./runme
[4]+ Terminated ./runme

shred

Linux 系统也支持一个名为 shred 的命令。shred 命令会覆盖文件以隐藏其以前的内容，并确保使用硬盘恢复工具无法恢复它们。请记住，rm 命令基本上只是删除文件在目录文件中的引用，但不一定会从磁盘上删除内容或覆盖它。shred 命令覆盖文件的内容。

$ shred dupes.txt
$ more dupes.txt
▒oΛ▒▒9▒lm▒▒▒▒▒o▒1־▒▒f▒f▒▒▒i▒▒h^}&▒▒▒{▒▒

僵尸

虽然不是命令，但僵尸在 Linux 系统上是很顽固的存在。僵尸基本上是没有完全清理掉的死亡进程的遗骸。进程不应该这样工作 —— 让死亡进程四处游荡，而不是简单地让它们死亡并进入数字天堂，所以僵尸的存在表明了让他们遗留于此的进程有一些缺陷。

一个简单的方法来检查你的系统是否有僵尸进程遗留，看看 top 命令的标题行。

$ top
top - 18:50:38 up 6 days, 6:36, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 171 total, 1 running, 167 sleeping, 0 stopped, 3 zombie  `< ==`
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.9 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 2003388 total, 250840 free, 545832 used, 1206716 buff/cache
KiB Swap: 9765884 total, 9765764 free, 120 used. 1156536 avail Mem

可怕！上面显示有三个僵尸进程。

at midnight

有时会在万圣节这么说，死者的灵魂从日落开始游荡直到午夜。Linux 可以通过 at midnight 命令跟踪它们的离开。用于安排在下次到达指定时间时运行的作业，at 的作用类似于一次性的 cron。

$ at midnight
warning: commands will be executed using /bin/sh
at> echo 'the spirits of the dead have left'
at> <EOT>
job 3 at Thu Oct 31 00:00:00 2017

守护进程

Linux 系统也高度依赖守护进程 —— 在后台运行的进程，并提供系统的许多功能。许多守护进程的名称以 “d” 结尾。这个 “d” 代表 守护进程 daemon ，表明这个进程一直运行并支持一些重要功能。有的会用单词 “daemon” 。

$ ps -ef | grep sshd
root 1142 1 0 Oct19 ? 00:00:00 /usr/sbin/sshd -D
root 25342 1142 0 18:34 ? 00:00:00 sshd: shs [priv]
$ ps -ef | grep daemon | grep -v grep
message+ 790 1 0 Oct19 ? 00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root 836 1 0 Oct19 ? 00:00:02 /usr/lib/accountsservice/accounts-daemon

万圣节快乐！

在 Facebook 和 LinkedIn 上加入 Network World 社区来对主题进行评论。

via: https://www.networkworld.com/article/3235219/linux/scary-linux-commands-for-halloween.html

作者：Sandra Henry-Stocker 译者：geekpi 校对：wxy

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

DevOps 团队需要 IT 领导者关注三件事：沟通、技术债务和信任。

IT 领导者可以从大量的 DevOps 材料和 向 DevOps 转变 所要求的文化挑战中学习。但是，你在一个 DevOps 团队面对长期或短期的团结挑战的调整中 —— 一个 CIO 真正需要他们做的是什么呢？

在我与 DevOps 团队成员的谈话中，我听到的其中一些内容让你感到非常的意外。DevOps 专家（无论是内部团队的还是外部团队的）都希望将下列的事情放在你的 CIO 优先关注的级别。

1. 沟通

第一个也是最重要的一个，DevOps 专家需要面对面的沟通。一个经验丰富的 DevOps 团队是非常了解当前 DevOps 的趋势，以及成功和失败的经验，并且他们非常乐意去分享这些信息。表达 DevOps 的概念是很困难的，因此，要在这种新的工作关系中保持开放，定期（不用担心，不用每周）讨论有关你的 IT 的当前状态，如何评价你的沟通环境，以及你的整体的 IT 产业。

相反，你应该准备好与 DevOps 团队去共享当前的业务需求和目标。业务不再是独立于 IT 的东西：它们现在是驱动 IT 发展的重要因素，并且 IT 决定了你的业务需求和目标运行的效果如何。

注重参与而不是领导。在需要做决策的时候，你仍然是最终的决策者，但是，理解这些决策的最好方式是协作，这样，你的 DevOps 团队将有更多的自主权，并因此受到更多激励。

2. 降低技术债务

第二，力争更好地理解技术债务，并在 DevOps 中努力降低它。你的 DevOps 团队都工作于一线。这里，“技术债务”是指在一个庞大的、不可持续发展的环境之中，通过维护和增加新功能而占用的人力资源和基础设备资源（查看 Rube Goldberg）。

CIO 常见的问题包括：

• 为什么我们要用一种新方法去做这件事情？
• 为什么我们要在它上面花费时间和金钱？
• 如果这里没有新功能，只是现有组件实现了自动化，那么我们的收益是什么？

“如果没有坏，就不要去修理它”，这样的事情是可以理解的。但是，如果你正在路上好好的开车，而每个人都加速超过你，这时候，你的环境就被破坏了。持续投入宝贵的资源去支撑或扩张拼凑起来的环境。

选择妥协，并且一个接一个的打补丁，以这种方式去处理每个独立的问题，结果将从一开始就变得很糟糕 —— 在一个不能支撑建筑物的地基上，一层摞一层地往上堆。事实上，这种方法就像不断地在电脑中插入坏磁盘一样。迟早有一天，面对出现的问题你将会毫无办法。在外面持续增加的压力下，整个事情将变得一团糟，完全吞噬掉你的资源。

这种情况下，解决方案就是：自动化。使用自动化的结果是良好的可伸缩性 —— 每个维护人员在 IT 环境的维护和增长方面花费更少的努力。如果增加人力资源是实现业务增长的唯一办法，那么，可伸缩性就是白日做梦。

自动化降低了你的人力资源需求，并且对持续进行的 IT 提供了更灵活的需求。很简单，对吗？是的，但是你必须为迟到的满意做好心理准备。为了在提高生产力和效率的基础上获得后端经济效益，需要预先投入时间和精力对架构和结构进行变更。为了你的 DevOps 团队能够成功，接受这些挑战，对 IT 领导者来说是非常重要的。

3. 信任

最后，相信你的 DevOps 团队并且一定要理解他们。DevOps 专家也知道这个要求很难，但是他们必须得到你的强大支持和你积极参与的意愿。因为 DevOps 团队持续改进你的 IT 环境，他们自身也在不断地适应这些变化的技术，而这些变化通常正是 “你要去学习的经验”。

倾听，倾听，倾听他们，并且相信他们。DevOps 的改变是非常有价值的，而且也是值的去投入时间和金钱的。它可以提高效率、生产力、和业务响应能力。信任你的 DevOps 团队，并且给予他们更多的自由，实现更高效率的 IT 改进。

新 CIO 的底线是：将你的 DevOps 团队的潜力最大化，离开你的领导 “舒适区”，拥抱一个 “CIOps" 的转变。通过 DevOps 转变，持续地与你的 DevOps 团队共同成长，以帮助你的组织获得长期的 IT 成功。

via: https://enterprisersproject.com/article/2017/12/what-devops-teams-really-need-cio

作者：John Allessio 译者：qhwdw 校对：wxy

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

在这个 Docker 系列的最后一篇文章中，我们将讲述在 DockerHub 上使用和发布镜像。

在前面的文章中，我们了解到了基本的 Docker 术语，在 Linux 桌面、MacOS 和 Windows上 如何安装 Docker，如何创建容器镜像 并且在系统上运行它们。在本系列的最后一篇文章中，我们将讨论如何使用 DockerHub 中的镜像以及将自己的镜像发布到 DockerHub。

首先：什么是 DockerHub 以及为什么它很重要？DockerHub 是一个由 Docker 公司运行和管理的基于云的存储库。它是一个在线存储库，Docker 镜像可以由其他用户发布和使用。有两种库：公共存储库和私有存储库。如果你是一家公司，你可以在你自己的组织内拥有一个私有存储库，而公共镜像可以被任何人使用。

你也可以使用公开发布的官方 Docker 镜像。我使用了很多这样的镜像，包括我的试验 WordPress 环境、KDE plasma 应用程序等等。虽然我们上次学习了如何创建自己的 Docker 镜像，但你不必这样做。DockerHub 上发布了数千镜像供你使用。DockerHub 作为默认存储库硬编码到 Docker 中，所以当你对任何镜像运行 docker pull 命令时，它将从 DockerHub 下载。

从 Docker Hub 下载镜像并在本地运行

开始请查看本系列的前几篇文章，以便继续。然后，一旦 Docker 在你的系统上运行，你就可以打开终端并运行：

$ docker images

该命令将显示当前系统上所有的 docker 镜像。假设你想在本地机器上部署 Ubuntu，你可能会：

$ docker pull ubuntu

如果你的系统上已经存在 Ubuntu 镜像，那么该命令会自动将该系统更新到最新版本。因此，如果你想要更新现有的镜像，只需运行 docker pull 命令，易如反掌。这就像 apt-get update 一样，没有任何的混乱和麻烦。

你已经知道了如何运行镜像：

$ docker run -it <image name>
$ docker run -it ubuntu

命令提示符应该变为如下内容：

root@1b3ec4621737:/#

现在你可以运行任何属于 Ubuntu 的命令和实用程序，这些都被包含在内而且安全。你可以在 Ubuntu 上运行你想要的所有实验和测试。一旦你完成了测试，你就可以销毁镜像并下载一个新的。在虚拟机中不存在系统开销。

你可以通过运行 exit 命令退出该容器：

$ exit

现在假设你想在系统上安装 Nginx，运行 search 命令来找到需要的镜像：

$ docker search nginx

正如你所看到的，DockerHub 上有很多 Nginx 镜像。为什么？因为任何人都可以发布镜像，各种镜像针对不同的项目进行了优化，因此你可以选择合适的镜像。你只需要为你的需求安装合适的镜像。

假设你想要拉取 Bitnami 的 Nginx 镜像：

$ docker pull bitnami/nginx

现在运行：

$ docker run -it bitnami/nginx

如何发布镜像到 Docker Hub？

在此之前，我们学习了如何创建 Docker 镜像，我们可以轻松地将该镜像发布到 DockerHub 中。首先，你需要登录 DockerHub，如果没有账户，请 创建账户。然后，你可以打开终端应用，登录：

$ docker login --username=<USERNAME>

将 “” 替换为你自己的 Docker Hub 用户名。我这里是 arnieswap：

$ docker login --username=arnieswap

输入密码，你就登录了。现在运行 docker images 命令来获取你上次创建的镜像的 ID。

$ docker images

现在，假设你希望将镜像 ng 推送到 DockerHub，首先，我们需要标记该镜像（了解更多关于标记的信息）：

$ docker tag e7083fd898c7 arnieswap/my_repo:testing

现在推送镜像：

$ docker push arnieswap/my_repo

推送指向的是 docker.io/arnieswap/my\_repo 仓库：

12628b20827e: Pushed
8600ee70176b: Mounted from library/ubuntu
2bbb3cec611d: Mounted from library/ubuntu
d2bb1fc88136: Mounted from library/ubuntu
a6a01ad8b53f: Mounted from library/ubuntu
833649a3e04c: Mounted from library/ubuntu
testing: digest: sha256:286cb866f34a2aa85c9fd810ac2cedd87699c02731db1b8ca1cfad16ef17c146 size: 1569

哦耶！你的镜像正在上传。一旦完成，打开 DockerHub，登录到你的账户，你就能看到你的第一个 Docker 镜像。现在任何人都可以部署你的镜像。这是开发软件和发布软件最简单，最快速的方式。无论你何时更新镜像，用户都可以简单地运行：

$ docker run arnieswap/my_repo

现在你知道为什么人们喜欢 Docker 容器了。它解决了传统工作负载所面临的许多问题，并允许你在任何时候开发、测试和部署应用程序。通过遵循本系列中的步骤，你自己可以尝试以下。

via: https://www.linux.com/blog/learn/intro-to-linux/2018/1/how-use-dockerhub

作者：Swapnil Bhartiya 译者：MjSeven 校对：wxy

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

借助 GitHub 的 网络钩子 webhook ，开发者可以创建很多有用的服务。从触发一个 Jenkins 实例上的 CI（持续集成） 任务到配置云中的机器，几乎有着无限的可能性。这篇教程将展示如何使用 Python 和 Flask 框架来搭建一个简单的持续部署（CD）服务。

在这个例子中的持续部署服务是一个简单的 Flask 应用，其带有接受 GitHub 的 网络钩子 webhook 请求的 REST 端点 endpoint 。在验证每个请求都来自正确的 GitHub 仓库后，服务器将 拉取 pull 更改到仓库的本地副本。这样每次一个新的 提交 commit 推送到远程 GitHub 仓库，本地仓库就会自动更新。

Flask web 服务

用 Flask 搭建一个小的 web 服务非常简单。这里可以先看看项目的结构。

├── app
│   ├── __init__.py
│   └── webhooks.py
├── requirements.txt
└── wsgi.py

首先，创建应用。应用代码在 app 目录下。

两个文件（__init__.py 和 webhooks.py）构成了 Flask 应用。前者包含有创建 Flask 应用并为其添加配置的代码。后者有 端点 endpoint 逻辑。这是该应用接收 GitHub 请求数据的地方。

这里是 app/__init__.py 的内容：

import os
from flask import Flask

from .webhooks import webhook

def create_app():
 """ Create, configure and return the Flask application """

  app = Flask(__name__)
  app.config['GITHUB_SECRET'] = os.environ.get('GITHUB_SECRET')
  app.config['REPO_PATH'] = os.environ.get('REPO_PATH')
  app.register_blueprint(webhook)

  return(app)

该函数创建了两个配置变量：

• GITHUB_SECRET 保存一个密码，用来认证 GitHub 请求。
• REPO_PATH 保存了自动更新的仓库路径。

这份代码使用 Flask 蓝图 Flask Blueprints 来组织应用的 端点 endpoint 。使用蓝图可以对 API 进行逻辑分组，使应用程序更易于维护。通常认为这是一种好的做法。

这里是 app/webhooks.py 的内容：

import hmac
from flask import request, Blueprint, jsonify, current_app 
from git import Repo

webhook = Blueprint('webhook', __name__, url_prefix='')

@webhook.route('/github', methods=['POST']) 
def handle_github_hook(): 
 """ Entry point for github webhook """

  signature = request.headers.get('X-Hub-Signature') 
  sha, signature = signature.split('=')

  secret = str.encode(current_app.config.get('GITHUB_SECRET'))

  hashhex = hmac.new(secret, request.data, digestmod='sha1').hexdigest()
  if hmac.compare_digest(hashhex, signature): 
    repo = Repo(current_app.config.get('REPO_PATH')) 
    origin = repo.remotes.origin 
    origin.pull('--rebase')

    commit = request.json['after'][0:6]
    print('Repository updated with commit {}'.format(commit))
  return jsonify({}), 200

首先代码创建了一个新的蓝图 webhook。然后它使用 Flask route 为蓝图添加了一个端点。任何请求 /GitHub URL 端点的 POST 请求都将调用这个路由。

验证请求

当服务在该端点上接到请求时，首先它必须验证该请求是否来自 GitHub 以及来自正确的仓库。GitHub 在请求头的 X-Hub-Signature 中提供了一个签名。该签名由一个密码（GITHUB_SECRET），请求体的 HMAC 十六进制摘要，并使用 sha1 哈希生成。

为了验证请求，服务需要在本地计算签名并与请求头中收到的签名做比较。这可以由 hmac.compare_digest 函数完成。

自定义钩子逻辑

在验证请求后，现在就可以处理了。这篇教程使用 GitPython 模块来与 git 仓库进行交互。GitPython 模块中的 Repo 对象用于访问远程仓库 origin。该服务在本地拉取 origin 仓库的最新更改，还用 --rebase 选项来避免合并的问题。

调试打印语句显示了从请求体收到的短提交哈希。这个例子展示了如何使用请求体。更多关于请求体的可用数据的信息，请查询 GitHub 文档。

最后该服务返回了一个空的 JSON 字符串和 200 的状态码。这用于告诉 GitHub 的网络钩子服务已经收到了请求。

部署服务

为了运行该服务，这个例子使用 gunicorn web 服务器。首先安装服务依赖。在支持的 Fedora 服务器上，以 sudo 运行这条命令:

sudo dnf install python3-gunicorn python3-flask python3-GitPython

现在编辑 gunicorn 使用的 wsgi.py 文件来运行该服务：

from app import create_app
application = create_app()

为了部署服务，使用以下命令克隆这个 git 仓库或者使用你自己的 git 仓库：

git clone https://github.com/cverna/github_hook_deployment.git /opt/

下一步是配置服务所需的环境变量。运行这些命令：

export GITHUB_SECRET=asecretpassphraseusebygithubwebhook
export REPO_PATH=/opt/github_hook_deployment/

这篇教程使用网络钩子服务的 GitHub 仓库，但你可以使用你想要的不同仓库。最后，使用这些命令开启该 web 服务：

cd /opt/github_hook_deployment/
gunicorn --bind 0.0.0.0 wsgi:application --reload

这些选项中绑定了 web 服务的 IP 地址为 0.0.0.0，意味着它将接收来自任何的主机的请求。选项 --reload 确保了当代码更改时重启 web 服务。这就是持续部署的魔力所在。每次接收到 GitHub 请求时将拉取仓库的最近更新，同时 gunicore 检测这些更改并且自动重启服务。

*注意： *为了能接收到 GitHub 请求，web 服务必须部署到具有公有 IP 地址的服务器上。做到这点的简单方法就是使用你最喜欢的云提供商比如 DigitalOcean，AWS，Linode等。

配置 GitHub

这篇教程的最后一部分是配置 GitHub 来发送网络钩子请求到 web 服务上。这是持续部署的关键。

从你的 GitHub 仓库的设置中，选择 Webhook 菜单，并且点击“Add Webhook”。输入以下信息：

• “Payload URL”： 服务的 URL，比如 <http://public_ip_address:8000/github>
• “Content type”： 选择 “application/json”
• “Secret”： 前面定义的 GITHUB_SECRET 环境变量

然后点击“Add Webhook” 按钮。

现在每当该仓库发生推送事件时，GitHub 将向服务发送请求。

总结

这篇教程向你展示了如何写一个基于 Flask 的用于接收 GitHub 的网络钩子请求，并实现持续集成的 web 服务。现在你应该能以本教程作为起点来搭建对自己有用的服务。

via: https://fedoramagazine.org/continuous-deployment-github-python/

作者：Clément Verna 选题：lujun9972 译者：kimii 校对：wxy

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

我们已经讨论过 Linux 下 gzip 命令的用法。对于初学者来说，gzip 工具主要用于压缩或者展开文件。解压时，在 gzip 命令后添加 -d 选项即可，使用示例如下：

gzip -d [compressed-file-name]

不过，在解压或扩展 gzip 创建的压缩文件时，有另一款完全不同的工具可供使用。谈及的这款工具就是 gunzip。在本文中，我们会使用一些简单、易于理解的例子来解释 gunzip 命令的用法。文中所有示例及指南都在 Ubuntu 16.04 环境下测试。

Linux gunzip 命令

我们现在知道压缩文件可以用 gzip -d 或 gunzip 命令解压。基本的 gunzip 语法为：

gunzip [compressed-file-name]

以下的 Q&A 例子将更清晰地展示 gunzip 工具如何工作：

Q1. 如何使用 gunzip 解压压缩文件？

解压命令非常简单，仅仅需要将压缩文件名称作为参数传递到 gunzip 命令后。

gunzip [archive-name]

比如：

gunzip file1.gz

Q2. 如何让 gunzip 不删除原始压缩文件？

正如你已注意到的那样，gunzip 命令解压后会删除原始压缩文件。如果你想保留原始压缩文件，可以使用 -c 选项。

gunzip -c [archive-name] > [outputfile-name]

比如：

gunzip -c file1.gz > file1

使用这种方式，原压缩文件不会被删除。

Q3. 如何用 gunzip 解压文件到其他路径？

在 Q&A 中我们已经讨论过 -c 选项的用法。 使用 gunzip 解压文件到工作目录外的其他路径，仅需要在重定向操作符后添加目标目录的绝对路径即可。

gunzip -c [compressed-file] > [/complete/path/to/dest/dir/filename]

示例如下：

gunzip -c file1.gz > /home/himanshu/file1

更多信息

以下从 gzip/gunzip 的 man 页中摘录的细节，对于想了解更多的人会有所助益。

gunzip 在命令行接受一系列的文件，并且将每个文件内容以正确的魔法数开始，且后缀名为 .gz、-gz、.z、-z 或 _z （忽略大小写）的压缩文件，用未压缩的文件替换它，并删除其原扩展名。 gunzip 也可识别一些特殊扩展名的压缩文件，如 .tgz 和 .taz 分别是 .tar.gz 和 .tar.Z 的缩写。在压缩时，gzip 在必要情况下使用 .tgz 作为扩展名，而不是只截取掉 .tar 后缀。

gunzip 目前可以解压 gzip、zip、compress、compress -H（pack）产生的文件。gunzip 自动检测输入文件格式。在使用前两种压缩格式时，gunzip 会检验 32 位循环冗余校验码（CRC）。对于 pack 包，gunzip 会检验压缩长度。标准压缩格式在设计上不允许相容性检测。不过 gunzip 有时可以检测出坏的 .Z 文件。如果你解压 .Z 文件时出错，不要因为标准解压没报错就认为 .Z 文件一定是正确的。这通常意味着标准解压过程不检测它的输入，而是直接产生一个错误的输出。SCO 的 compress -H 格式（lzh 压缩方法）不包括 CRC 校验码，但也允许一些相容性检查。

结语

到目前为止提到的 gunzip 基本用法，并不需要过多的学习曲线。我们已包含了一个初学者开始使用它所必须了解的几乎全部知识。想要了解更多的用法，去看 man 页面 吧。

via: https://www.howtoforge.com/linux-gunzip-command/

作者：Himanshu Arora 译者：erialin 校对：wxy

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