2019年11月

有时,你可能需要定期或以预定的时间间隔执行任务。这些任务包括备份数据库、更新系统、执行定期重新引导等。这些任务称为 “cron 任务”。cron 任务用于“自动执行的任务”,它有助于简化重复的、有时是乏味的任务的执行。cron 是一个守护进程,可让你安排这些任务,然后按指定的时间间隔执行这些任务。在本教程中,你将学习如何使用 cron 来安排任务。

crontab 文件

crontab 即 “cron table”,是一个简单的文本文件,其中包含指定任务执行时间间隔的规则和命令。 crontab 文件分为两类:

1)系统范围的 crontab 文件

这些通常由需要 root 特权的 Linux 服务及关键应用程序使用。系统 crontab 文件位于 /etc/crontab 中,并且只能由 root 用户访问和编辑。通常用于配置系统范围的守护进程。crontab 文件的看起来类似如下所示:

etc-crontab-linux

2)用户创建的 crontab 文件

Linux 用户还可以在 crontab 命令的帮助下创建自己的 cron 任务。创建的 cron 任务将以创建它们的用户身份运行。

所有 cron 任务都存储在 /var/spool/cron(对于 RHEL 和 CentOS 发行版)和 /var/spool/cron/crontabs(对于 Debian 和 Ubuntu 发行版)中,cron 任务使用创建该文件的用户的用户名列出。

cron 守护进程在后台静默地检查 /etc/crontab 文件和 /var/spool/cron/etc/cron.d*/ 目录。

crontab 命令用于编辑 cron 文件。让我们看一下 crontab 文件的结构。

crontab 文件剖析

在继续之前,我们要首先探索 crontab 文件的格式。crontab 文件的基本语法包括 5 列,由星号表示,后跟要执行的命令。

*    *    *    *    *    command

此格式也可以表示如下:

m h d moy dow command

m h d moy dow /path/to/script

让我们来解释一下每个条目

  • m:代表分钟。范围是 0 到 59
  • h:表示小时,范围是 0 到 23
  • d:代表一个月中的某天,范围是 1 到 31
  • moy:这是一年中的月份。范围是 1 到 12
  • dow:这是星期几。范围是 0 到 6,其中 0 代表星期日
  • command:这是要执行的命令,例如备份命令、重新启动和复制命令等

管理 cron 任务

看完 crontab 文件的结构之后,让我们看看如何创建、编辑和删除 cron 任务。

创建 cron 任务

要以 root 用户身份创建或编辑 cron 任务,请运行以下命令:

# crontab -e

要为另一个用户创建或安排 cron 任务,请使用以下语法:

# crontab -u username -e

例如,要以 Pradeep 用户身份运行 cron 任务,请发出以下命令:

# crontab -u Pradeep -e

如果该 crontab 文件尚不存在,那么你将打开一个空白文本文件。如果该 crontab 文件已经存在,则 -e 选项会让你编辑该文件,

列出 crontab 文件

要查看已创建的 cron 任务,只需传递 -l 选项:

# crontab -l

删除 crontab 文件

要删除 cron 任务,只需运行 crontab -e 并删除所需的 cron 任务行,然后保存该文件。

要删除所有的 cron 任务,请运行以下命令:

# crontab -r

然后,让我们看一下安排任务的不同方式。

使用 crontab 安排任务示例

如图所示,所有 cron 任务文件都带有 释伴 shebang 标头。

#!/bin/bash

这表示你正在使用的 shell,在这种情况下,即 bash shell。

接下来,使用我们之前指定的 cron 任务条目指定要安排任务的时间间隔。

要每天下午 12:30 重启系统,请使用以下语法:

30  12 *  *  * /sbin/reboot

要安排在凌晨 4:00 重启,请使用以下语法:

0  4  *  *  *  /sbin/reboot

注:星号 * 用于匹配所有记录。

要每天两次运行脚本(例如,凌晨 4:00 和下午 4:00),请使用以下语法:

0  4,16  *  *  *  /path/to/script

要安排 cron 任务在每个星期五下午 5:00 运行,请使用以下语法:

0  17  *  *  Fri  /path/to/script

0 17  *  *  *  5  /path/to/script

如果你希望每 30 分钟运行一次 cron 任务,请使用:

*/30  *  *  *  * /path/to/script

要安排 cron 任务每 5 小时运行一次,请运行:

*  */5  *  *  *  /path/to/script

要在选定的日期(例如,星期三和星期五的下午 6:00)运行脚本,请执行以下操作:

0  18  *  *  wed,fri  /path/to/script

要使用单个 cron 任务运行多个命令,请使用分号分隔任务,例如:

*  *  *  *  *  /path/to/script1 ; /path/to/script2

使用特殊字符串节省编写 cron 任务的时间

某些 cron 任务可以使用对应于特定时间间隔的特殊字符串轻松配置。例如,

1)@hourly 时间戳等效于 0 * * * *

它将在每小时的第一分钟执行一次任务。

@hourly /path/to/script

2)@daily 时间戳等效于 0 0 * * *

它在每天的第一分钟(午夜)执行任务。它可以在执行日常工作时派上用场。

@daily /path/to/script

3)@weekly 时间戳等效于 0 0 * * 0

它在每周的第一分钟执行 cron 任务,一周第一天是从星期日开始的。

@weekly /path/to/script

3)@monthly 时间戳等效于 0 0 1 * *

它在每月第一天的第一分钟执行任务。

@monthly /path/to/script

4)@yearly 时间戳等效于 0 0 1 1 *

它在每年的第一分钟执行任务,可以用于发送新年问候。

@yearly /path/to/script

限制 crontab

作为 Linux 用户,你可以控制谁有权使用 crontab 命令。可以使用 /etc/cron.deny/etc/cron.allow 文件来控制。默认情况下,只有一个 /etc/cron.deny 文件,并且不包含任何条目。要限制用户使用 crontab 实用程序,只需将用户的用户名添加到该文件中即可。当用户添加到该文件中,并且该用户尝试运行 crontab 命令时,他/她将遇到以下错误。

restricted-cron-user

要允许用户继续使用 crontab 实用程序,只需从 /etc/cron.deny 文件中删除用户名即可。

如果存在 /etc/cron.allow 文件,则仅文件中列出的用户可以访问和使用 crontab 实用程序。

如果两个文件都不存在,则只有 root 用户具有使用 crontab 命令的特权。

备份 crontab 条目

始终建议你备份 crontab 条目。为此,请使用语法:

# crontab -l > /path/to/file.txt

例如:

# crontab -l > /home/james/backup.txt

检查 cron 日志

cron 日志存储在 /var/log/cron 文件中。要查看 cron 日志,请运行以下命令:

# cat /var/log/cron

view-cron-log-files-linux

要实时查看日志,请使用 tail 命令,如下所示:

# tail -f /var/log/cron

view-live-cron-logs

总结

在本指南中,你学习了如何创建 cron 任务以自动执行重复性任务,如何备份和查看 cron 日志。我们希望本文提供有关 cron 作业的有用见解。请随时分享你的反馈和意见。


via: https://www.linuxtechi.com/schedule-automate-tasks-linux-cron-jobs/

作者:Pradeep Kumar 选题:lujun9972 译者:wxy 校对:wxy

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

在当今的专业 IT 媒体中有一个非常突出的话题,那就是在软件生命周期中的“第 0 天/第 1 天/第 2 天”。在演讲和会议讲话当中,通常着重于使软件开发过程有效且易于管理,为此,有必要明确定义所使用的概念。通常,如果直观地理解基本术语“ 第 0 天 Day 0 / 第 1 天 Day 1 / 第 2 天 Day 2 ”,这在谈论软件生命周期时可能会引起一些歧义。因此,我决定更准确地定义它们,以展示软件开发的整个过程以及它们在实际项目中的使用方式。这篇简短的博客文章提供了“天”的定义,这些“天”被理解为软件生命周期的各个阶段。它还描述了云如何改变了有关软件开发和维护过程的传统思维方式。毕竟,正如《RightScale 2019 云状态报告》所确认的那样,我们正处于“云时代”。该报告解释说,有 94% 的调查受访者正在使用云(私有云或公有云)。因此,闲话少说,让我们探讨一下“天”和云如何结合在一起。

“天”究竟是什么?

在 IT 中,术语“第 0 天/第 1 天/第 2 天”指的是软件生命周期的不同阶段。用军事术语来说,“第 0 天”是训练的第一天,新兵进入训练阶段。在软件开发中,它代表设计阶段,在此阶段中指定项目需求并确定解决方案的体系结构。

“第 1 天”涉及开发和部署在“第 0 天”阶段设计的软件。在此阶段,我们不仅创建应用程序本身,还创建应用程序的基础设施、网络、外部服务,并实现所有部分的初始配置。

“第 2 天”是产品出厂或交付给客户的时间。在这里,大部分工作都集中在维护、监控和优化系统上。分析系统的行为并做出正确的反应至关重要,因为所产生的反馈循环将一直持续到应用程序生命周期结束为止。

在云时代之前的日子里,这些阶段是分别处理的,彼此之间没有重叠。今天,情况已不再如此。让我们看一下所有这些如何应用于现代应用程序的生命周期。

第 0 天:无聊但必不可少

第 0 天经常被忽略,因为它可能很无聊,但这并不会降低其重要性。成功的软件产品是经过全面规划和设计过程的结果。必须仔细计划系统或应用程序的体系结构以及启动和运行所需的资源(CPU、存储空间、RAM)。其次,你应该定义可衡量的里程碑,以实现项目目标。每个里程碑应有一个准确的日期。这有助于衡量项目的进度,并确定你是否延迟了计划运行。所有项目时间估算都应基于概率,而不仅仅是按最佳情况预估。进行计划时,最好添加缓冲余量,因为意外事件甚至可能使精心策划的计划陷入困境。测试阶段也起着重要的作用,也应该包括在初始项目计划中。这些是基本要求,它们在“云时代”中同以往一样重要。

尽管如此,在计算资源的第 0 天计划中,云还是改变了两件事。由于云可以在项目的任何地方获得不同的资源或新资源(CPU、存储空间、RAM),因此比本地基础设施要容易得多。因此,可以避免在计划阶段犯下的一些错误。另一方面,在计划阶段对特定云供应商的承诺可能会在以后导致供应商锁定。这可能会花费你的金钱,并且需要时间来进行更改,因此选择云供应商时要明智一些。

其次,正如我们当前在向云的迁移中观察到的那样,与运维相关的工作依旧保持不变,但不再专注于基础设施。现在,正是软件在推动着自动化和价值。

第 1 天:实现创意的阶段

对于开发人员和项目负责人而言,第 1 天绝对是最有趣的阶段。最初的设计得以实现,并根据项目的规范创建了基础设施。为了成为真正的云原生,必须遵守最佳实践。可以遵循诸如 十二要素应用程序方法 Twelve-Factor Apps methodology 之类的准则。此外,使用云端意味着你应该遵循重要的 DevOps 惯例:持续集成/持续交付(如果你想了解有关 CI/CD 的更多信息,请参阅我们的博客文章)。

云为我们带来了从传统方法到软件开发的重要变化:将第一行代码拼凑在一起以进行概念验证后,应用程序即开始运行。你可以从持续集成实践开始,以测试你的应用程序的健全性,但是你很快会让企业迈入到持续交付。在开发应用程序时,我们开始引入一些运维元素,尤其是在使用多个环境的情况下。注意这些运维要素将使维护团队在维护阶段(第 2 天)的工作更加轻松。

在第 1 天期间可以使用几种工具。可以将它们按解决的问题分组。这个列表的顶部应提及“ 基础设施即代码 Infrastructure-as-a-code ”(IaaC)。 IaaC 就像应用程序或代码一样管理运维环境。这种方法允许将 DevOps 最佳实践(包括版本控制、虚拟化测试和持续监视)应用于驱动基础设施的代码。这里有很多工具可供我们使用,例如 Terraform、Ansible 或 Puppet 等。第二类工具与容器的自动化部署和管理的容器编排系统有关。Kubernetes 及其实现(例如 Google Kubernetes Engine 和亚马逊的 Elastic Kubernetes Service)至关重要。最后,还有诸如 Jenkins、Zuul 和 CircleCI 之类的 CI/CD 系统,可帮助工程师自动化软件的构建、测试以及交付或部署。

第 2 天:日常运维环节

一旦软件准备就绪,它就会上线,客户开始使用它。第 2 天始于此,并引入了包括软件维护和客户支持在内的各个元素。该软件本身将不断发展,以适应不断变化的需求和客户需求。在第 2 天期间,主要重点是建立反馈循环。我们监控该应用程序的工作方式,收集用户反馈并将其发送给开发团队,该团队将在产品中实施该应用程序并发布新版本。军事术语“ 观察-导向-决定-行动 Observe-Orient-Decide-Act ”(OODA)恰当地抓住了这一阶段发生的事情。

  • 观察:从监视系统获取信息(资源使用情况和指标,应用程序性能监控)。
  • 导向:执行问题的根本原因分析。
  • 决定:找到解决问题的方法。
  • 行动:实施解决方案。

与战斗中一样,该循环不断重复。

监控程序基于 服务水平协议 Service Level Agreement (SLA)中定义的要求。 SLA 基于 服务水平目标 Service Level Objectives (SLO),代表我们的 服务水平指标 Service Level Indicators (SLI)的状态。自动化和监控是解决第 2 天职责的关键。

有几种工具可帮助完成第 2 天的工作。 应用程序性能监控 Application Performance Monitoring (APM)类软件可以帮助 IT 管理员监控应用程序性能,从而提供高质量的用户体验。在这里,我们可以点名 Datadog、Dynatrace、SignalFX 或 Nutanix Xi Epoch。 还有一些自动化和编排工具,例如 Ansible 或 Kubernetes,可帮助管理应用程序环境。你可能已经注意到,这些工具的应用与第 1 天的工作重叠。最后,工单系统(例如 Servicedesk 或 Zendesk)可以处理客户服务,使用户可以报告故障以及与他们正在运行的应用程序有关的问题。

Day 0/Day 1/Day 2 – stages of software lifecycle

云将改变游戏规则

在前云时代,这些阶段之间的分隔清晰可见,但是今天,随着云的日常运行,事物在不断变化。使用云和现代软件开发实践,可以更轻松地处理软件生命周期中不断变化的要求。持续集成/持续开发方法使我们能够动态响应客户反馈并实时改进应用程序,而无需等待主要版本进行改进。

基于云和原生云的软件中的 DevOps 实践有助于实现 向左移动 shift left (LCTT 译注:环节前置的意思),这意味着传统上一直保留到最后的步骤现在可以更快地执行。除此以外,这导致第 1 天和第 2 天现在相互重叠。此外,传统软件开发的最大痛点在于从第 1 天到第 2 天的过渡:从开发人员到运维人员的过渡。现在,DevOps 展示了如何解决此问题:及早启动流程,并使流程一直运行到应用程序生命周期结束。最后但同样重要的是,工具链正在完善,这使得执行第 1 天的任务和适应第 2 天的更改成为可能。 可以根据我们的需求对所使用的工具进行建模,并且过程中涉及的每个人都可以使用同一套工具。

不仅可以部署简单的应用程序,还可以用 Kubernetes 运维器应对第 2 天运营。

在我的第一篇文章 为什么说 Kubernetes 是一辆翻斗车 中,我谈到了 Kubernetes 如何在定义、分享和运行应用程序方面很出色,类似于翻斗车在移动垃圾方面很出色。在第二篇中,如何跨越 Kubernetes 学习曲线,我解释了 Kubernetes 的学习曲线实际上与运行任何生产环境中的应用程序的学习曲线相同,这确实比学习所有传统组件要容易(如负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等)。这是 DevOps,是开发人员和运维人员之间的合作,用于指定事物在生产环境中的运行方式,这意味着双方都需要学习。在第三篇 Kubernetes 基础:首先学习如何使用 中,我重新设计了 Kubernetes 的学习框架,重点是驾驶翻斗车而不是制造或装备翻斗车。在第四篇文章 帮助你驾驭 Kubernetes 的 4 个工具 中,我分享了我喜爱的工具,这些工具可帮助你在 Kubernetes 中构建应用程序(驾驶翻斗车)。

在这最后一篇文章中,我会分享我为什么对在 Kubernetes 上运行应用程序的未来如此兴奋的原因。

从一开始,Kubernetes 就能够很好地运行基于 Web 的工作负载(容器化的)。Web 服务器、Java 和相关的应用程序服务器(PHP、Python等)之类的工作负载都可以正常工作。该平台处理诸如 DNS、负载平衡和 SSH(由 kubectl exec 取代)之类的支持服务。在我的职业生涯的大部分时间里,这些都是我在生产环境中运行的工作负载,因此,我立即意识到,除了 DevOps 之外,除了敏捷之外,使用 Kubernetes 运行生产环境工作负载的强大功能。即使是我们几乎不改变我们的文化习惯,也可以提高效率。调试和退役变得非常容易,而这对于传统 IT 来说是极为困难的。因此,从早期开始,Kubernetes 就用一种单一的配置语言(Kube YAML/Json)为我提供了对生产环境工作负载进行建模所需的所有基本原语。

但是,如果你需要运行具有复制功能的多主 MySQL,会发生什么情况?使用 Galera 的冗余数据呢?你如何进行快照和备份?那么像 SAP 这样复杂的工作呢?使用 Kubernetes,简单的应用程序(Web 服务器等)的第 0 天(部署)相当简单,但是没有解决第 2 天的运营和工作负载。这并不是说,具有复杂工作负载的第 2 天运营要比传统 IT 难解决,而是使用 Kubernetes 并没有使它们变得更容易。每个用户都要设计自己的天才想法来解决这些问题,这基本上是当今的现状。在过去的五年中,我遇到的第一类问题是复杂工作负载的第 2 天操作。(LCTT 译注:在软件生命周期中,第 0 天是指软件的设计阶段;第 1 天是指软件的开发和部署阶段;第 2 天是指生产环境中的软件运维阶段。)

值得庆幸的是,随着 Kubernetes 运维器 Operator 的出现,这种情况正在改变。随着运维器的出现,我们现在有了一个框架,可以将第 2 天的运维知识汇总到平台中。现在,我们可以应用我在 Kubernetes 基础:首先学习如何使用 中描述的相同的定义状态、实际状态的方法,现在我们可以定义、自动化和维护各种各样的系统管理任务。

(LCTT 译注: Operator 是 Kubernetes 中的一种可以完成运维工程师的特定工作的组件,业界大多没有翻译这个名词,此处仿运维工程师例首倡翻译为“运维器”。)

我经常将运维器称为“系统管理机器人”,因为它们实质上是在第 2 天的工作中整理出一堆运维知识,该知识涉及 主题专家 Subject Matter Expert (SME、例如数据库管理员或系统管理员)针对的工作负载类型(数据库、Web 服务器等),通常会记录在 Wiki 中的某个地方。这些知识放在 Wiki 中的问题是,为了将该知识应用于解决问题,我们需要:

  1. 生成事件,通常监控系统会发现故障,然后我们创建故障单
  2. SME 人员必须对此问题进行调查,即使这是我们之前见过几百万次的问题
  3. SME 人员必须执行该知识(执行备份/还原、配置 Galera 或事务复制等)

通过运维器,所有这些 SME 知识都可以嵌入到单独的容器镜像中,该镜像在有实际工作负荷之前就已部署。 我们部署运维器容器,然后运维器部署和管理一个或多个工作负载实例。然后,我们使用“运维器生命周期管理器”(Katacoda 教程)之类的方法来管理运维器。

因此,随着我们进一步使用 Kubernetes,我们不仅简化了应用程序的部署,而且简化了整个生命周期的管理。运维器还为我们提供了工具,可以管理具有深层配置要求(群集、复制、修复、备份/还原)的非常复杂的有状态应用程序。而且,最好的地方是,构建容器的人员可能是做第 2 天运维的主题专家,因此现在他们可以将这些知识嵌入到操作环境中。

本系列的总结

Kubernetes 的未来是光明的,就像之前的虚拟化一样,工作负载的扩展是不可避免的。学习如何驾驭 Kubernetes 可能是开发人员或系统管理员可以对自己的职业发展做出的最大投资。随着工作负载的增多,职业机会也将增加。因此,这是驾驶一辆令人惊叹的 在移动垃圾时非常优雅的翻斗车……

你可能想在 Twitter 上关注我,我在 @fatherlinux 上分享有关此主题的很多内容。


via: https://opensource.com/article/19/6/kubernetes-potential-run-anything

作者:Scott McCarty 选题:lujun9972 译者:wxy 校对:wxy

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

如果你曾经在家和办公室之外连接到 WiFi,那么通常会看到一个门户页面。它可能会要求你接受服务条款或其他协议才能访问。但是,当你无法通过这类门户进行连接时会发生什么?本文向你展示了如何在 Fedora 上使用 NetworkManager 在某些故障情况下让你仍然可以访问互联网。

强制门户如何工作

强制门户是新设备连接到网络时显示的网页。当用户首次访问互联网时,门户网站会捕获所有网页请求并将其重定向到单个门户页面。

然后,页面要求用户采取一些措施,通常是同意使用政策。用户同意后,他们可以向 RADIUS 或其他类型的身份验证系统进行身份验证。简而言之,强制门户根据设备的 MAC 地址和终端用户接受条款来注册和授权设备。(MAC 地址是附加到任何网络接口的基于硬件的值,例如 WiFi 芯片或卡。)

有时设备无法加载强制门户来进行身份验证和授权以使用 WiFI 接入。这种情况的例子包括移动设备和游戏机(Switch、Playstation 等)。当连接到互联网时,它们通常不会打开强制门户页面。连接到酒店或公共 WiFi 接入点时,你可能会看到这种情况。

不过,你可以在 Fedora 上使用 NetworkManager 来解决这些问题。Fedora 可以使你临时克隆要连接的设备的 MAC 地址,并代表该设备通过强制门户进行身份验证。你需要得到连接设备的 MAC 地址。通常,它被打印在设备上的某个地方并贴上标签。它是一个六字节的十六进制值,因此看起来类似 4A:1A:4C:B0:38:1F。通常,你也可以通过设备的内置菜单找到它。

使用 NetworkManager 克隆

首先,打开 nm-connection-editor,或通过“设置”打开 WiFi 设置。然后,你可以使用 NetworkManager 进行克隆:

  • 对于以太网:选择已连接的以太网连接。然后选择 “Ethernet” 选项卡。记录或复制当前的 MAC 地址。在 “ 克隆 MAC 地址 Cloned MAC address ” 字段中输入游戏机或其他设备的 MAC 地址。
  • 对于 WiFi:选择 WiFi 配置名。然后选择 “WiFi” 选项卡。记录或复制当前的 MAC 地址。在 “ 克隆 MAC 地址 Cloned MAC address ” 字段中输入游戏机或其他设备的 MAC 地址。

启动所需的设备

当 Fedora 系统与以太网或 WiFi 配置连接,克隆的 MAC 地址将用于请求 IP 地址,并加载强制门户。输入所需的凭据和/或选择用户协议。该 MAC 地址将获得授权。

现在,断开 WiF i或以太网配置连接,然后将 Fedora 系统的 MAC 地址更改回其原始值。然后启动游戏机或其他设备。该设备现在应该可以访问互联网了,因为它的网络接口已通过你的 Fedora 系统进行了授权。

不过,这不是 NetworkManager 全部能做的。例如,请参阅随机化系统硬件地址,来获得更好的隐私保护。


via: https://fedoramagazine.org/cloning-a-mac-address-to-bypass-a-captive-portal/

作者:Esteban Wilson 选题:lujun9972 译者:geekpi 校对:wxy

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

在云原生技术实践峰会召开前夕,匆匆奔赴北京的我,见到了刚刚从美国飞回来,却毫无时差之扰的陈恺——灵雀云的 CTO。

虽然我早就和灵雀云有了联系,也有好几位朋友在灵雀云任职,不过作为国内新锐云原生厂商灵雀云的创始人之一的陈恺,我之前并没有直接接触过。虽然我们是初次相识,但是在聊到了开源,聊到云技术,我们以云做老酒,以开源为佐酒菜,很快就俨然如同老友般进入了旁若无人的状态——旁边的朋友被我们暂时性忽视了,虽然这张合影就是她帮我们照的。 :D

滥觞始于云计算。

缘起

陈恺和左玥等人在创立灵雀云之前,他们都曾在微软 Azure 从事云计算领域的专业研究。回忆起那时候,陈恺说,那时他们也在想象云里面的应用应该长什么样子,设计最早版本的“云服务模型”、“云服务运行时”,而现在回过头看,其实云计算的发展已经千差万别。

2013 年 Docker 出现以后,左玥和陈恺他们第一时间就意识到容器技术会很有影响力,它重新了定义云技术之后发展的路径,这恍然在他们面前掀开了一个新的时代,于是灵雀云诞生了。

云技术领域发展演变的非常快,事实上,在云计算早期并不能预见到如今的云计算格局。“早期我们尝试过很多东西,总的想法是觉得容器就像是一种轻量级虚拟机,一种新的虚拟化技术。就像虚拟机需要虚拟机平台去作为它的管理平台一样,容器也需要一个容器云平台,所以我们早期想做的就是容器云平台,这一点一直没变,现在也是在做企业级的容器平台。”陈恺说,“我们最早的技术选型是 Mesos 技术栈,经历了几次大的改变,包括从 Mesos 转到支持当时的三种主流的调度系统,然后开始倾向于Kubernetes,到最后全面转向 Kubernetes,以及最近在架构上和 Kubernetes全面对齐,把我们的平台做成一个 Kubernetes 原生的平台,技术上一直在做升级。”

云原生吞噬一切,Kubernetes 编排一切

云原生正在吞噬世界

不知不觉之间,云原生已经吞噬了整个世界,如今,云原生已经是技术界最时髦的词汇之一。而应运而生并推动了这一切发生的云原生计算基金会(CNCF)也在不同的时期、不同的场所,对云原生做了不同角度的解读。那么作为一家很早就涉入云计算领域的新锐力量,陈恺对云原生的理解是什么呢?

陈恺说,“CNCF 旗下涵盖这么多云计算的技术、产品和服务,所以它对‘云原生’的定义必然会比较宽泛,但的确,‘云原生’不是一个特定的技术或者一种方法,很难把它精确的定义,也不应该把它和具体的技术对等,比如说把它直接跟 Kubernetes 挂钩,跟 Kubernetes 没关系就不是云原生?跟 Kubernetes 有关系就叫云原生?这两者都是不对的。”

他接着补充说,“我对云原生定义的观点也是比较宽泛的,(云原生)就是让应用能够最大化的释放云计算生产力的一系列的思维方式、最佳实践和技术体系,这里的关键词是让应用去释放云计算最大的生产力。这是关键。所有的云原生我觉得都是首先应该围绕应用的。什么叫‘云原生’?主要是以应用为中心的。‘原生’这个名字看起来起的不是很好,听上去似乎是只有在云上生出来的才叫‘云原生’,或者只有在公有云上才叫‘云原生’,并不是。关键不是说你在哪里跑你的应用,而是你是不是能够释放云的生产力——广义的云的生产力。”

在容器编排市场尚三分天下的时候,很多容器服务商都同时支持三种主流的编排系统,当时有一些观点认为这种三分格局会持续比较久,然而 Kubernetes 迅速崛起,很快就一家独大地统治了容器编排市场。

陈恺说,“我觉得当时 Kubernetes 可以很快的从编排之争当中胜出,并没有那么让人吃惊。为什么我们比较早的时候就开始往 Kubernetes 发力?其实第一个触发的点比较偶然。那时经常会有人问起三种容器编排系统各自的优势是什么?我们做了一些研究,业界有一些对比,当时我印象比较深的是一个细节,我觉得这才是关键——有一项对比的是基于这三种技术有哪些商业版?基于 Docker Swarm 的有一个商业版 Docker EE;Mesos 有一个商业版 MesosPhere;基于 Kubernetes 有好多商业版——这是本质的区别。这一点对它们的社区的发展速度和后续影响很广,因为它是开放式的治理。Kubernetes 虽然是谷歌发明的,但是它是开放式治理,背后有很多商业版。如果从开源软件本身社区发展角度看,很关键一点是上面有多少商业版,商业版越多说明从开源软件里面可以获利的公司越多,这样就有了正向的良性循环,会有更多资源投进来,社区里面参与的人就会更多,最后的发展会更好,生态会很繁荣。当时从这一点我们就觉得这个生态肯定会赢。”

Kubernetes 一统容器编排市场的今天,业界一些专家对此有所忧虑,担心这种垄断会形成市场压制。从长期来看,如果 Kubernetes 的发展会形成类似 Android 一样的巨头化,那么作为下游厂商,灵雀云是如何看待和应对这种发展变化的呢?

陈恺说,“回到垄断这个问题,如果是商业软件的话会有垄断这个问题,如果是开源软件的话,它的治理模式有可能是封闭式的,也有可能是开放式的,而 Kubernetes 是一个开放式的治理模式,会有一些厂商有更大的影响力,但不是被一家完全控制,所以我觉得从这个角度来说,谈不上垄断,更多的是一个标准。它可能更多像 Linux 而不像是 Android。从标准的角度来说,肯定是利大于弊,而且是远大于弊。因为有了标准,大家都围绕着标准做投入,风险就大大降低,可以放心去投入,也就会有越来越多的技术厂商会向它靠拢。”

灵雀云的 Kubernetes 生态

灵雀云在围绕 Kubernetes 生态方面也做了自己的发行版,他们是如何在符合 Kubernetes 标准的基础上形成差异化的服务和产品的呢?

“Kubernetes 发行版首先必须是跟 Kubernetes 兼容的。在 Kubernetes 上可以增加各种各样的能力,但它本身的第一属性一定是一个真正的 Kubernetes。如果为了做差异性,把它做得不像 Kubernetes,不兼容会是个很大的问题。”陈恺说,“我们走的比这个更深一步,我们的 ACP 2.0 是把整个平台都做成 Kubernetes 原生的,因为 Kubernetes 本质上是声明式 API 加上基于控制器模型的架构设计范式,容器编排相当于它的一个副产品,是它基于这个架构的一种应用,当然也可以把这种架构应用到对任意资源的编排。前一段时间有一篇很多人转发的《Kubernetes 编排一切》的文章,讲的就是这个事情,它不光可以用来编排容器,可以做各种各样的事情。我很赞同这个观点。”

陈恺在云原生技术实践峰会 2019 上演讲

灵雀云是从 2017 年底的时候决定这样做的,当时的做法是一些新的产品开始在新的架构上做一些实践,比如 DevOps 平台、基于 Istio 的 Service Mesh 等产品,完全基于新的架构来做。今年年初,灵雀云认为所有方面都成熟了:第一,方向肯定没问题,Kubernetes 编排一切;第二,对如何基于 Kubernetes 的架构构建上层产品有了更多的经验和体会。灵雀云于是把以前产品上的所有功能都逐渐迁移到 Kubernetes 原生架构上,重新融合到统一的架构里面,这就是 ACP 2.0。在此之上灵雀云还做了一些差异化。

灵雀云在这里的技术栈分为三层:

最底层的产品是一个 Kubernetes 发行版,Kubernetes 是一个开源的技术,并不是一个平台,大多数企业做不到直接把它当一个平台用。灵雀云的做法是将 Kubernetes 技术变成一个企业就绪的 Kubernetes 发行版。

再往上是 ACP 层,定位是云原生应用赋能平台。包含有三个子产品:容器平台、DevOps 平台和基于 Istio 的 Service Mesh 产品。容器平台和发行版最接近,但对发行版进行了大量扩展,比如在发行版之上增加了多集群管理和企业级多租户。ACP 把单一的 Kubernetes 集群变成企业平台级的产品,经过了三年多 100+ 企业客户生产环境的考验,而且考虑到更多开发者的场景。DevOps 也基于 Kubernetes 原生,用 Kubernetes 去编排所有的工具,定位是一个开放式 DevOps 工具链集成和编排的平台。

在此之上还有一层是灵雀云新的 ACE 3.0,它的定位是一个企业级的 PaaS 平台,或者用现在更时髦的说法,可以称之为企业技术中台,集成了更多企业需要的其他服务,比如第三方的中间件、开发框架等。它是个完整的技术中台,以容器平台为底座,以云原生黄金三角为核心,其他服务在上面做成一个个插件。这部分主要是和生态合作伙伴合作,国内外的一些最优秀的 PaaS 类服务都可以放在里面,为企业提供完整的解决方案。

云原生之于微服务和 DevOps

我们知道微服务、DevOps 等模式在云原生概念发展起来之前就已经存在,但是随着云原生的发展,似乎给它们注入了更多的活力。

陈恺认为云原生显著地推动了 DevOps、微服务的发展,对于这一现象他还专门用了一个词汇来形容:后 Kubernetes。这是在容器和 Kubernetes 出现之后开始对 DevOps 侧的微服务反过来的助推。

他认为,微服务架构的本质是用运维复杂度为代价去换取敏捷性。企业至少要考虑两件事:第一是否真的有这么高的敏捷性需求,值得用那么大的运维代价去替换,第二,假设你有着敏捷性需求,那么多出来的复杂度怎么办?早期微服务落地会很痛苦,因为大家没有准备好怎么去应付这个复杂度,而且会低估它。这复杂度是未知的,用未知的复杂度去替代已知的复杂度,这通常都是不好的,所以才会有各种各样的治理框架出来。其实它需要底下有一个好的基础设施来支撑它。

容器和微服务天生一对,容器 Kubernetes 的出现,对微服务有非常明显地推动。Kubernetes 作为底层的应用管理平台非常合适,而且很多微服务里面要考虑的与业务无关的能力也可以慢慢推到 Kubernetes 里面去。而进一步,Service Mesh 等其上的技术栈就重新定义了微服务技术栈,微服务治理方式发生了变化,反过来作用到微服务上,形成了新的最佳实践。

因此,要做微服务应该先容器化,才能解决运维复杂度的问题,容器化的服务应该跑在 Kubernetes 之上;如果进一步做服务治理,应该往 Service Mesh 方向走,Service Mesh 是基于 Kubernetes 平台的微服务治理的最佳实践。

云原生之于 DevOps 也是如此。早期大家很多的精力在持续集成上面,比如 Jenkins 最初是作为 CI 工具出现的,而有了容器和 Kubernetes 之后,持续集成变得简化了,最终生成 Docker 镜像就好。重心开始转到部署,转到 CD 上。而且,现在的 DevOps 实践或 CI/CD 通常会把 Kubernetes 作为最重要的部署目标。也就是说CI会围绕容器镜像,CD 会围绕 Kubernetes。这是容器和 Kubernetes 带给 DevOps 的影响,基础设施越强大,对 DevOps、微服务就越有帮助。以 Kubernetes 为核心的基础设施变成新的标准,DevOps 和微服务的一些最佳实践都会围绕它去改变。

源于开源,茁壮于开源

云计算构筑在开源之上,灵雀云的基础设施和服务也构建在开源之上,那么灵雀云是如何拥抱开源和贡献开源的?

陈恺说,“有几个开源社区跟我们是非常相关的,最早的时候是 Docker 社区,现在 Kubernetes 则是跟我们关系最大的开源社区。我们核心的产品是容器、DevOps 和微服务三部分。Jenkins、Istio 等相关开源项目是我们的重点,我们非常重视在开源社区的投入。我们的许多工程师会参与其中,对社区进行贡献,也会开源一些项目,我们在一步一步持续地做这件事情。我们首先会选择一些偏底层的技术或者机制,选择那些有足够亮点,真的被需要的项目和技术开源出来。”

目前灵雀云已经开源了的项目,包括基于 OVN 的网络插件 Kube-OVN,它是把 OVN 的网络和 Kubernetes 所集成的网络插件。现在该项目在国内外都受到关注,也有来自外部贡献者参与。另外一个开源的项目叫 Captain,是一个基于 Helm v3 标准的 Kubernetes 控制器,对 Helm 应用分发进行改进。

后续灵雀云还计划将更完整的东西放出来,比如灵雀云的 Kubernetes 发行版,供社区用户用来管理自己的 Kubernetes 平台,可以达到和使用灵雀云产品接近的体验。另外灵雀云也计划将其 ACP 释放社区版或者开源版本出来。陈恺说,“我们很乐意把它开源出来,因为这是一个标准的产品,我们让它较早期的接触更多用户,也能得到更多反馈,甚至吸收一些外部的贡献者参与进来。”

尾声

我采访过很多技术领袖和技术专家,不过陈恺的这场采访让我有一点不同的感受。一场对话下来,陈恺给我的感觉如同多年的老友一样言无不尽,而他对于我提到的每个话题,都非常认真、仔细的做了阐述,让人感到浓浓的专业技术风格。我想,这就是陈恺的技术初心,也是灵雀云一直以来的风格吧。


“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二:取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用;穿山甲是珍稀保护动物,宣传公益。

微软正在全面重制其 Edge Web 浏览器,它将基于开源 Chromium 浏览器。微软还要将新的 Edge 浏览器带到 Linux 桌面上,但是 Linux 版本可能会有所延迟。

微软的 Internet Explorer 曾经一度统治了浏览器市场,但在过去的十年中,它将统治地位丢给了谷歌的 Chrome。

微软试图通过创造 Edge 浏览器来找回失去的位置,Edge 是一种使用 EdgeHTML 和 Chakra 引擎构建的全新 Web 浏览器。它与 Microsoft 的数字助手 Cortana 和 Windows 10 紧密集成。

但是,它仍然无法夺回冠军位置,截至目前,它处于桌面浏览器使用份额的第四位

最近,微软决定通过基于开源 Chromium 项目重新对 Edge 进行大修。谷歌的 Chrome 浏览器也是基于 Chromium 的。Chromium 还可以作为独立的 Web 浏览器使用,某些 Linux 发行版将其用作默认的 Web 浏览器。

Linux 上新的微软 Edge Web 浏览器

经过最初的犹豫和不确定性之后,微软似乎最终决定把新的 Edge 浏览器引入到 Linux。

在其年度开发商大会 Microsoft Ignite 中,关于 Edge 浏览器的演讲中提到了它未来将进入 Linux 中。

微软确认 Edge 未来将进入 Linux 中

新的 Edge 浏览器将于 2020 年 1 月 15 日发布,但我认为 Linux 版本会推迟。

微软 Edge 进入 Linux 真的重要吗?

微软 Edge 进入 Linux 有什么大不了的吗?我们又不是没有很多可用于 Linux 的 Web 浏览器

我认为这与 “微软 Linux 竞争”(如果有这样的事情)有关。微软为 Linux(特别是 Linux 桌面)做的任何事情,都会成为新闻。

我还认为 Linux 上的 Edge 对于微软和 Linux 用户都有好处。这就是为什么。

对于微软有什么用?

当谷歌在 2008 年推出其 Chrome 浏览器时,没有人想到它会在短短几年内占领市场。但是,为什么作为一个搜索引擎会在一个“免费的 Web 浏览器”后面投入如此多的精力呢?

答案是谷歌是一家搜索引擎,它希望有更多的人使用其搜索引擎和其他服务,以便它可以从广告服务中获得收入。使用 Chrome,Google 是默认的搜索引擎。在 Firefox 和 Safari 等其他浏览器上,谷歌支付了数亿美元作为默认 Web 浏览器的费用。如果没有 Chrome,则谷歌必须完全依赖其他浏览器。

微软也有一个名为 Bing 的搜索引擎。Internet Explorer 和 Edge 使用 Bing 作为默认搜索引擎。如果更多用户使用 Edge,它可以增加将更多用户带到 Bing 的机会。而微软显然希望拥有更多的 Bing 用户。

对 Linux 用户有什么用?

对于 Linux 桌面用户,我看到有两个好处。借助 Edge,你可以在 Linux 上使用某些微软特定的产品。 例如,微软的流式游戏服务 xCloud 可能仅能在 Edge 浏览器上使用。另一个好处是提升了 Linux 上的 Netflix 体验。当然,你可以在 Linux 上使用 Chrome 或 Firefox 观看 Netflix,但可能无法获得全高清或超高清流。

据我所知,全高清和超高清 Netflix 流仅在微软 Edge 上可用。这意味着你可以使用 Linux 上的 Edge 以高清格式享受 Netflix。

你怎么看?

你对微软 Edge 进入 Linux 有什么感觉?当 Linux 版本可用时,你会使用吗?请在下面的评论部分中分享你的观点。


via: https://itsfoss.com/microsoft-edge-linux/

作者:Abhishek Prakash 选题:lujun9972 译者:wxy 校对:wxy

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