mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
Merge branch 'master' of github.com:LCTT/TranslateProject
This commit is contained in:
GHLandy
commit
b579cab507
91
published/20160425 What is SRE.md
Normal file
91
published/20160425 What is SRE.md
Normal file
@ -0,0 +1,91 @@
|
||||
什么是 SRE（网站可靠性工程）？
|
||||
============================================================
|
||||
|
||||
网站可靠性工程师（Site Reliability Engineer）是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。
|
||||
|
||||
|
||||
|
||||
本文为 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑的 [<ruby>《网站可靠性工程》<rt>Site Reliability Engineering</rt></ruby>][9] 一书的摘录。
|
||||
|
||||
SRE 网站可靠性工程（Site Reliability Engineering）在[ 11 月 7-10 日在阿姆斯特丹举办的 O'Reilly Velocity 会议][10]上也有提到。
|
||||
|
||||
### 介绍
|
||||
|
||||
> 希望不是一种策略。
|
||||
>
|
||||
> —— 传统的 SRE 如是说
|
||||
|
||||
一个公认的事实是系统不会自己运行。 那么，一个系统 — 尤其是复杂大规模系统 — _应该_怎么运行呢？
|
||||
|
||||
### 系统管理员的服务管理方法
|
||||
|
||||
以前，公司雇用系统管理员来运行复杂的计算系统。
|
||||
|
||||
系统管理员（或者称为 sysadmin）这种方式包括整合现有软件组件，使之互相协作来完成一个服务。系统管理员的任务是运行服务，响应事件，并在事件发生时进行更新。随着系统复杂度的增长和流量的增长，事件和更新也相应增长，导致管理员团队也越来越庞大才能完成更多的工作。由于系统管理员的角色需要的技能与产品开发人员有很大不同，开发和系统管理员被分为不同的团队：“开发”和“运维”。
|
||||
|
||||
系统管理员模式的服务管理有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个已被人们所熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手系统管理团队不必重新发明轮子以及从头设计系统。
|
||||
|
||||
此方式将公司开发和运维分离，也有一些缺点和困难。主要有两类：直接代价和间接代价。
|
||||
|
||||
直接代价很显而易见了。利用依靠手工干预来进行变更管理和事件处理的团队进行服务管理，当服务和/或流量增长时，成本是很昂贵的，因为团队随着系统负载的增长也在相应增长。
|
||||
|
||||
开发/运维分离的间接代价可能不那么明显，但常常比直接代价还要昂贵。代价来自于两个团队背景，技术，激励都非常不同。他们使用不同的词汇来描述所面临的情境；对技术方案的风险和可能性他们持不同的假设；对产品稳定性的目标级别也会有不同的争议。团队的分离很容易导致不只是激励的不同，还有沟通、目标的不同，以及最终，信任和尊重的分离。这是一种恶性循环。
|
||||
|
||||
因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在开发团队的核心上，他们希望推出新功能，并看到它们被用户采纳。在运维团队的核心上， 他们希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。
|
||||
|
||||
两个团队都明白，以最想要的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用常见的斗争形式来提高他们的利益。 运维团队试图通过提高发布和变更门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对_每个_问题的显式审查，这些问题过去都_曾经_引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有检查元素都一样重要。开发团队很快学会了如何回应。他们通过较少的“发布”和更多的“功能切换”、“增量更新”或 “选择性失明”来规避。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
|
||||
|
||||
### Google 的服务管理方法：网站可靠性工程
|
||||
|
||||
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行自己的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由系统工程师手动完成的工作。
|
||||
|
||||
什么是网站可靠性工程（Site Reliability Engineering），是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时所发生的结果。当我在 2003 年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我以自己是一名 SRE 的方式，设计和管理了一个_我_想要的团队的样子。这个团队已经成为了 Google 的目前的 SRE 团队，它仍如最初一名终生软件工程师所想象的那个样子。
|
||||
|
||||
Google 服务管理方法的主要构成部分是由每个 SRE 团队组成的。作为一个整体，SRE 可以分为两大类。
|
||||
|
||||
50-60％ 的人是 Google 软件工程师，或者更确切地说，是通过 Google 软件工程师的标准程序招聘的人。其他 40-50％ 的候选人非常接近 Google 软件工程师资格（即拥有所需技能集的 85-99％），以及一些具有大多数软件工程师没有的一些 SRE 技术技能的人。到目前为止，UNIX 系统底层和网络（第 1 层到第 3 层）的专业知识是我们寻求的两种最常见的替代技术技能。
|
||||
|
||||
所有的 SRE 的共同点是有开发软件系统以解决复杂问题的信念和能力。在 SRE 中，我们密切跟踪两个团队的职业发展，并且迄今为止发现在两种工程师之间的表现没有实际差异。事实上，SRE 团队的多样性背景经常产生聪明、高质量的系统，这显然是几个技能集合成的产物。
|
||||
|
||||
我们这样招聘 SRE 的结果是，我们有了这样一个团队：（a）手动执行任务很快会变得无聊。（b）他们有必要的技能集来写出软件以取代以前的手动操作，即使解决方案很复杂。SRE 还会与其他开发部门分享学术以及知识背景。因此，SRE 从根本上做了一个运维团队历来做的工作，但它使用具有软件专业知识的工程师，并期望这些内在倾向于使用软件并且有能力用软件的人用软件设计并实现自动化来代替人力劳动。
|
||||
|
||||
按照设计，至关重要的是 SRE 团队专注于工程。没有恒定的工程，运维工作增加，团队将需要更多的人来上工作量。最终，传统的以运维为中心的团队与服务规模呈线性关系：如果服务支持的产品成功，运维工作将随着流量而增长。这意味着雇用更多的人一遍又一遍地完成相同的任务。
|
||||
|
||||
为了避免这种命运，负责管理服务的团队需要写代码，否则就会被工作淹没。因此，Google 为 SRE 们_设置了一个 “运维” 工作的上限，如任务单、紧急呼叫、手动任务最多只占 50% 工作量_。此上限确保 SRE 团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限；随着时间的推移，除了自己的设备，SRE 团队应该只有很少的运维工作，他们几乎可以完全从事开发任务，因为服务基本上可以运行和维修自己：我们想要的系统是_自动的_，而不只是_自动化_。在实践中，规模和新功能始终是 SRE 要考虑的。
|
||||
|
||||
Google 的经验法则是，SRE 团队必须花费剩余的 50％ 的时间来进行实际开发。那么我们该如何执行这个阈值呢？首先，我们必须测量 SRE 如何花费时间。通过测量，我们确保团队不断花费不到 50% 的时间用于开发改变他们实践的工作上。通常这意味着会将一些运维负担转移回开发团队，或者给团队添加新的员工，而不指派该团队额外的运维责任。意识到在运维和开发工作之间保持这种平衡使我们能保证 SRE 具有参与创造性的自主工程的空间，同时仍然保留从运维那学来的智慧。
|
||||
|
||||
我们发现 Google SRE 的运行大规模系统的方法有很多优点。由于 SRE 是直接修改代码以使 Google 的系统可以运行自己，SRE 团队的特点是快速创新以及大量接受变革。这样的团队能相对价廉地支持相同的服务，面向运维的团队需要大量的人。相反，运行、维护和改进系统所需的 SRE 的数量随系统的大小而线性收敛。最后，SRE 不仅规避了开发/运维分裂的障碍，而且这种结构也改善了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉训练了整个团队，并且提高了那些在学习构建百万级别分布式系统上有困难的开发人员的技能。
|
||||
|
||||
尽管有这些好处，SRE 模型的特点是其自身独特的挑战。 Google 面临的一个持续挑战是招聘 SRE：SRE 不仅与产品开发招聘流程竞争相同的候选人，而且我们将招聘人员的编码和系统工程技能都设置得如此之高，这意味着我们的招聘池必然很小。由于我们的学科相对新颖独特，在如何建立和管理 SRE 团队方面没有太多的行业信息（不过希望这本书能朝着这个方向迈进！）。一旦 SRE 团队到位，他们潜在的非正统的服务管理方法需要强有力的管理支持。例如，一旦错误预估耗尽，除非是管理层的强制要求, 否则在季度剩余的时间里决定停止发布可能不会被产品开发团队所接受。
|
||||
|
||||
> **DevOps 或者 SRE？**
|
||||
|
||||
> “DevOps” 这个术语在 2008 年末出现，并在写这篇文章时（2016 年早期）仍在发生变动。 其核心原则：IT 部门在系统设计和开发的每个阶段的参与、严重依赖自动化与人力投入、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为几种核心 SRE原则向更广泛的组织，管理结构和人员的推广。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。
|
||||
|
||||
------------------------
|
||||
|
||||
作者简介：Benjamin Treynor Sloss 创造了“网站可靠性工程（Site Reliability Engineering）”一词，他自 2003 年以来一直负责 Google 的全球运营、网络和生产工程。截至 2016 年，他管理着全球范围内一个大约 4000 名软硬件和网络工程师团队。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering
|
||||
|
||||
作者：[Benjamin Treynor][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[1]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[2]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[3]:https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering
|
||||
[4]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[5]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[6]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[7]:https://pixabay.com/
|
||||
[8]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[9]:http://shop.oreilly.com/product/0636920041528.do?intcmp=il-webops-books-videos-update-na_new_site_site_reliability_engineering_text_cta
|
||||
[10]:http://conferences.oreilly.com/velocity/devops-web-performance-eu?intcmp=il-webops-confreg-update-vleu16_new_site_what_is_sre_text_cta
|
||||
[11]:https://pixabay.com/
|
||||
@ -1,13 +1,13 @@
|
||||
如何在 Linux 中不输入密码运行 “sudo” 命令
|
||||
如何在 Linux 中不输入密码运行 sudo 命令
|
||||
============================================================
|
||||
|
||||
假设你在只有自己使用的计算机上运行 Linux 系统，比如在笔记本电脑上，在每次调用 **sudo** 时需要输入密码，从长远来看都会变得无聊。因此，在本指南中，我们将描述[如何配置 sudo 命令][4]在运行时而不输入密码。
|
||||
假设你在只有自己使用的计算机上运行 Linux 系统，比如在笔记本电脑上，在每次调用 **sudo** 时需要输入密码，长期下来就会觉得很乏味。因此，在本指南中，我们将描述[如何配置 sudo 命令][4]在运行时而不输入密码。
|
||||
|
||||
此设置在 **/etc/sudoers** 文件中完成，它让 sudoers 使用 [sudo 命令][5]的默认安全策略; 在<ruby>用户权限指定<rt>user privilege specification</rt></ruby>部分。
|
||||
此设置在 `/etc/sudoers` 文件中完成，这是使用 [sudo 命令][5]的默认安全策略；在用户权限指定部分。
|
||||
|
||||
**重要**：在 **sudeors** 文件中，默认打开的 authenticate 参数用于验证目的。如果设置了它，用户必须通过密码（或其他身份验证方法）进行身份验证，然后才能使用 **sudo** 运行命令。
|
||||
**重要**：在 `sudeors` 文件中，默认打开的 `authenticate` 参数用于验证目的。如果设置了它，用户必须通过密码（或其他身份验证方法）进行身份验证，然后才能使用 `sudo` 运行命令。
|
||||
|
||||
但是，可以使用 **NOPASSWD**（当用户调用 **sudo** 命令时不需要密码）标记来覆盖此默认值。
|
||||
但是，可以使用 `NOPASSWD`（当用户调用 `sudo` 命令时不需要密码）标记来覆盖此默认值。
|
||||
|
||||
配置用户权限的语法如下：
|
||||
|
||||
@ -19,11 +19,11 @@ user_list host_list=effective_user_list tag_list command_list
|
||||
|
||||
1. `user_list` - 用户列表或已经设置的用户别名。
|
||||
2. `host_list` - 主机列表或用户可以在其上运行 sudo 的主机别名。
|
||||
3. `effective_user_list` - 目标用户
|
||||
4. `tag_list` - 标签列表，如 NOPASSWD。
|
||||
5. `command_list` - 用户使用 sudo 运行的命令或命令别名列表。
|
||||
3. `effective_user_list` - 以该用户或别名运行的用户列表
|
||||
4. `tag_list` - 标签列表，如 `NOPASSWD`。
|
||||
5. `command_list` - 用户使用 `sudo` 运行的命令或命令别名列表。
|
||||
|
||||
要允许用户（下面的示例中的 `aaronkilik`）使用 **sudo** 不输入密码即可运行所有命令，请打开 **sudoers** 文件：
|
||||
要允许用户（下面的示例中的 `aaronkilik`）使用 `sudo` 不输入密码即可运行所有命令，请打开 `sudoers` 文件：
|
||||
|
||||
```
|
||||
$ sudo visudo
|
||||
@ -35,19 +35,19 @@ $ sudo visudo
|
||||
aaronkilik ALL=(ALL) NOPASSWD: ALL
|
||||
```
|
||||
|
||||
对于组而言，在组名前面使用 `%` 字符；这意味着 `sys` 组的所有成员都可以不用密码使用 sudo。
|
||||
对于组而言，在组名前面使用 `%` 字符；这意味着 `sys` 组的所有成员都可以不用密码使用 `sudo`。
|
||||
|
||||
```
|
||||
%sys ALL=(ALL) NOPASSWD: ALL
|
||||
```
|
||||
|
||||
要允许用户不用密码使用 sudo 运行指定命令（`/bin/kill`），添加下面的行：
|
||||
要允许用户不用密码使用 `sudo` 运行指定命令（`/bin/kill`），添加下面的行：
|
||||
|
||||
```
|
||||
aaronkilik ALL=(ALL) NOPASSWD: /bin/kill
|
||||
```
|
||||
|
||||
下面的行会让 `sys` 组成员在使用 **sudo** 运行命令：**/bin/kill**、**/bin/rm** 时不用输入密码：
|
||||
下面的行会让 `sys` 组成员在使用 `sudo` 运行命令：`/bin/kill`、`/bin/rm` 时不用输入密码：
|
||||
|
||||
```
|
||||
%sys ALL=(ALL) NOPASSWD: /bin/kill, /bin/rm
|
||||
@ -58,7 +58,7 @@ aaronkilik ALL=(ALL) NOPASSWD: /bin/kill
|
||||
|
||||
*不用密码运行 sudo*
|
||||
|
||||
对于更多的 **sudo** 配置和其他使用选项，请阅读我们的有更多例子描述的文章，：
|
||||
对于更多的 `sudo` 配置和其他使用选项，请阅读我们有更多例子描述的文章，：
|
||||
|
||||
- [在 Linux 中设置 sudo 的十条 sudoers 实用配置][1]
|
||||
- [让 sudo 在你输入错误的密码时“嘲讽”你][2]
|
||||
@ -84,7 +84,7 @@ via: http://www.tecmint.com/run-sudo-command-without-password-linux/
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/aaronkili/
|
||||
[1]:https://linux.cn/article-8145-1.html?utm_source=index&utm_medium=more
|
||||
[1]:https://linux.cn/article-8145-1.html
|
||||
[2]:https://linux.cn/article-8128-1.html
|
||||
[3]:https://linux.cn/article-8151-1.html
|
||||
[4]:http://www.tecmint.com/sudoers-configurations-for-setting-sudo-in-linux/
|
||||
@ -1,3 +1,4 @@
|
||||
Translating by scoutydren
|
||||
Can academic faculty members teach with Wikipedia?
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
translating by ypingcn
|
||||
|
||||
How to get started contributing to Mozilla
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,3 +1,6 @@
|
||||
|
||||
beyondworld 翻译中
|
||||
|
||||
How to get up and running with sweet Orange Pi
|
||||
============================================================
|
||||
|
||||
|
||||
@ -1,70 +0,0 @@
|
||||
5 DevOps Tools for Logging and Monitoring
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
These DevOps logging and monitoring tools are part of the trend that's reshaping cloud computing -- learn more in the Guide to the Open Cloud.[Creative Commons Zero][1]Pixabay
|
||||
|
||||
In the cloud, open source tools and applications produce many kinds of DevOps efficiencies, and that’s especially true for logging and monitoring solutions. Monitoring cloud platforms, applications and components — along with processing and analyzing logs — is essential for ensuring high availability, top performance, low latency, and more. In fact, RightScale’s most recent[ State of the Cloud Survey][4] reports that the most common cloud optimization action, focused on by 45 percent of enterprises and SMBs, is monitoring.
|
||||
|
||||
However, proprietary logging and monitoring solutions are expensive. Even worse, they are often bundled into even more expensive managed service offerings.
|
||||
|
||||
Enter the new wave of powerful open logging and monitoring solutions. Some of these focus on targeted tasks, such as container cluster monitoring and performance analysis, while others qualify as holistic monitoring and alerting toolkits, capable of multi-dimensional data collection and querying.
|
||||
|
||||
The Linux Foundation recently[ announced][5] the release of its report[ Guide to the Open Cloud: Current Trends and Open Source Projects.][6] This third annual report provides a comprehensive look at the state of open cloud computing, and includes a section on logging and monitoring for the DevOps community. The report, which you can[ download][7] now, aggregates and analyzes research, illustrating how trends in containers, monitoring, and more are reshaping cloud computing. The report provides descriptions and links to categorized projects central to today’s open cloud environment. It takes special note of the fact that DevOps has emerged as the most effective method for application delivery and maintenance in the cloud.
|
||||
|
||||
In [a series of posts][8] appearing here, we are calling out many of these projects from the guide, by category, providing extra insights on how the overall category is evolving. Below, you’ll find a collection of several important DevOps tools for logging and monitoring and the impact that they are having, along with links to their GitHub repositories, all gathered from the Guide to the Open Cloud:
|
||||
|
||||
### Logging and monitoring
|
||||
|
||||
[Fluentd][9]
|
||||
|
||||
Fluentd is an open source data collector for unified logging layer, sponsored by Treasure Data. It structures data as JSON to unify all facets of processing log data: collecting, filtering, buffering, and outputting logs across multiple sources and destinations. [Fluentd on GitHub][10]
|
||||
|
||||
[Heapster][11]
|
||||
|
||||
Heapster is a container cluster monitoring and performance analysis tool in Kubernetes. It supports Kubernetes and CoreOS natively and can be adapted to run on OpenShift. It also supports a pluggable storage backend: InfluxDB with Grafana, Google Cloud Monitoring, Google Cloud Logging, Hawkular, Riemann and Kafka. [Heapster on GitHub][12]
|
||||
|
||||
[Logstash][13]
|
||||
|
||||
Logstash is Elastic’s open source data pipeline to help process logs and other event data from a variety of systems. Its plugins can connect to a variety of sources and stream data at scale to a central analytics system. [LogStash on GitHub][14]
|
||||
|
||||
[Prometheus][15]
|
||||
|
||||
Prometheus is an open source systems monitoring and alerting toolkit, originally built at SoundCloud and now a Cloud-Native Computing Foundation project at The Linux Foundation. It fits both machine-centric and microservices architectures and supports multi-dimensional data collection and querying. [Prometheus on GitHub][16]
|
||||
|
||||
[Weave Scope][17]
|
||||
|
||||
Weave Scope is Weaveworks’ open source tool to monitor distributed applications and their containers in real time. It integrates with Kubernetes and AWS ECS. [Weave Scope on GitHub][18]
|
||||
|
||||
_Learn more about trends in open source cloud computing and see the full list of the top open source cloud computing projects. [Download The Linux Foundation’s Guide to the Open Cloud report today!][3]_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/open-cloud-report/2016/5-devops-tools-logging-and-monitoring
|
||||
|
||||
作者：[SAM DEAN][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/sam-dean
|
||||
[1]:https://www.linux.com/licenses/category/creative-commons-zero
|
||||
[2]:https://www.linux.com/files/images/devops-loggingjpg
|
||||
[3]:http://bit.ly/2eHQOwy
|
||||
[4]:http://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2016-state-cloud-survey
|
||||
[5]:https://www.linux.com/blog/linux-foundation-issues-2016-guide-open-source-cloud-projects
|
||||
[6]:http://go.linuxfoundation.org/l/6342/2016-10-31/3krbjr?utm_source=press-release&utm_medium=pr&utm_campaign=open-cloud-report-2016
|
||||
[7]:http://go.linuxfoundation.org/l/6342/2016-10-31/3krbjr
|
||||
[8]:https://www.linux.com/news/open-cloud-report/2016/guide-open-cloud-state-micro-oses
|
||||
[9]:http://www.fluentd.org/
|
||||
[10]:https://github.com/fluent
|
||||
[11]:http://blog.kubernetes.io/2015/05/resource-usage-monitoring-kubernetes.html
|
||||
[12]:https://github.com/kubernetes/heapster
|
||||
[13]:https://www.elastic.co/products/logstash
|
||||
[14]:https://github.com/elastic/logstash
|
||||
[15]:https://prometheus.io/
|
||||
[16]:https://github.com/prometheus
|
||||
[17]:https://www.weave.works/products/weave-scope/
|
||||
[18]:https://github.com/weaveworks/scope
|
||||
@ -1,55 +0,0 @@
|
||||
5 new guides for working with OpenStack
|
||||
============================================================
|
||||
|
||||
|
||||
Image by :opensource.com
|
||||
|
||||
OpenStack experience continues to be among the most in-demand skills in the tech world, with more and more organizations seeking to build and manage their own open source clouds. But OpenStack is a huge domain of knowledge, containing dozen of individual projects that are being actively developed at a rapid pace. Just keeping your skills up to date can be a challenge.
|
||||
|
||||
The good news is that there are lots of resources out there to keep you up to speed. In addition to the [official project documentation][9], a variety training and certification programs, printed guides, and other resources, there are also a ton of tutorials and guides written by members of the OpenStack community and published across a variety of blogs and online publications.
|
||||
|
||||
At Opensource.com, every month we gather the best of these community-created resources and bring them together for you into one handy package. Here's what we rounded up last month.
|
||||
|
||||
* First up this time is a quick introduction to [Mistral usage in TripleO][1] from Julie Pichon. Mistral is a workflow service, allowing you to set up a multi-step process automation and coordinating actions for you asynchronously. Learn the basics of Mistral, how it works, and how it is used within TripleO in this quick guide.
|
||||
|
||||
* Want to dig further into TripleO for managing OpenStack deployments using OpenStack's own set of tools? Then you'll want to check out this [set of cheatsheets][2] for people who are making use of TripleO in their OpenStack setup. It's a work in progress, so feel free to contribute if you've got an idea of what should be included.
|
||||
|
||||
* Completing our trifecta of TripleO guides, don't miss this [quick guide][3] to using TripleO to stand up a standalone Ceph deployment. All it takes is a short YAML file and an easy command.
|
||||
|
||||
* Next up, if you're an OpenStack contributor, you might be familiar with the [Grafana dashboard][4] which displays various metrics around OpenStack's continuous integration infrastructure. Ever wondered how this service works, or want to create a new addition to this dashboard? Learn [how to create][5] your own local copy of the dashboard for testing purposes so you can play around with it and create your own modifications.
|
||||
|
||||
* Ever wonder what's happening under the hood with networking on an OpenStack cloud? OpenStack often makes use of [Open vSwitch][6] for network services for Neutron and Nova; learn the basics of how it is set up in [this walkthrough][7].
|
||||
|
||||
* * *
|
||||
|
||||
That's it for this time around. As always, be sure to check out our complete collection of [OpenStack tutorials][10], which brings together hundreds of individual guides published across the past three years.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Jason Baker - Jason is passionate about using technology to make the world more open, from software development to bringing sunlight to local governments. Linux desktop enthusiast. Map/geospatial nerd. Raspberry Pi tinkerer. Data analysis and visualization geek. Occasional coder. Cloud nativist. Follow him on Twitter.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/openstack-tutorials
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/jason-baker
|
||||
[1]:http://www.jpichon.net/blog/2016/12/quick-introduction-mistral-tripleo/
|
||||
[2]:http://www.anstack.com/blog/2016/12/16/printing-tripleo-cheat-sheet.html
|
||||
[3]:http://giuliofidente.com/2016/12/tripleo-to-deploy-ceph-standlone.html
|
||||
[4]:http://grafana.openstack.org/
|
||||
[5]:http://blog.cafarelli.fr/2016/12/local-testing-of-openstack-grafana-dashboard-changes/
|
||||
[6]:http://openvswitch.org/
|
||||
[7]:http://superuser.openstack.org/articles/openvswitch-openstack-sdn/
|
||||
[8]:https://opensource.com/article/17/1/openstack-tutorials?rate=q5H-KT2pm4NLExRhlHc0ru2dyjLkTSA45wim_2KtIec
|
||||
[9]:http://docs.openstack.org/
|
||||
[10]:https://opensource.com/resources/openstack-tutorials
|
||||
[11]:https://opensource.com/user/19894/feed
|
||||
[12]:https://opensource.com/users/jason-baker
|
||||
@ -0,0 +1,253 @@
|
||||
|
||||
beyondworld 翻译中
|
||||
|
||||
Powerline - 给Vim和Bash提供更棒的状态行和提示信息
|
||||
=================================================
|
||||
|
||||
Powerline是[Vim editor][1]中一个很好的状态行插件，这个插件是使用Python开发的，主要用于显示状态行和提示信息，适用于很多软件，比如bash，zsh，tmux等。
|
||||
|
||||
[
|
||||
|
||||
][2]
|
||||
|
||||
Powerline使Linux终端更具威力
|
||||
|
||||
#### 特色
|
||||
|
||||
1. python编写使其更具扩展性且功能丰富
|
||||
2. 稳定易测的代码基础，兼容python2.6+和python3
|
||||
3. 支持多种Linux版本及工具的提示和状态栏
|
||||
4. 通过JSON保存配置和颜色方案
|
||||
5. 快速、轻量级，具有daemon支持，提供更好的显示效果
|
||||
|
||||
#### Powerline截图效果
|
||||
|
||||
[
|
||||
|
||||
][3]
|
||||
|
||||
Vim中Powerline状态行效果
|
||||
|
||||
在本文中，我会介绍如何安装Powerline和相应字体，以及如何在RedHat和Debian类的系统中使用Bash和Vim支持Powerline。
|
||||
|
||||
### 第一步：准备好安装Powerline需要的软件
|
||||
|
||||
由于和其他不相干项目之间存在命名冲突，因此powerline只能放在PyPI(Python Package Index)中的powerline-status包下.
|
||||
|
||||
为了从PyPI中安装该包，需要先准备好pip(该工具专门用于Python包的管理)工具。所以首先要在Linux系统下安装好pip工具。
|
||||
|
||||
#### 在Debian,Ubuntu和Linux Mint中安装Pip的方法
|
||||
|
||||
```
|
||||
# apt-get install python-pip
|
||||
```
|
||||
##### 示例输出
|
||||
|
||||
```
|
||||
Reading package lists... Done
|
||||
Building dependency tree
|
||||
Reading state information... Done
|
||||
Recommended packages:
|
||||
python-dev-all python-wheel
|
||||
The following NEW packages will be installed:
|
||||
python-pip
|
||||
0 upgraded, 1 newly installed, 0 to remove and 533 not upgraded.
|
||||
Need to get 97.2 kB of archives.
|
||||
After this operation, 477 kB of additional disk space will be used.
|
||||
Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/universe python-pip all 1.5.4-1ubuntu3 [97.2 kB]
|
||||
Fetched 97.2 kB in 1s (73.0 kB/s)
|
||||
Selecting previously unselected package python-pip.
|
||||
(Reading database ... 216258 files and directories currently installed.)
|
||||
Preparing to unpack .../python-pip_1.5.4-1ubuntu3_all.deb ...
|
||||
Unpacking python-pip (1.5.4-1ubuntu3) ...
|
||||
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
|
||||
Setting up python-pip (1.5.4-1ubuntu3) ...
|
||||
```
|
||||
|
||||
#### 在CentOS，RHEL和Fedora中安装Pip
|
||||
|
||||
在Fedora类系统中，需要先打开[epel-repository][4]然后按照如下方法安装pip包。
|
||||
|
||||
```
|
||||
# yum install python-pip
|
||||
# dnf install python-pip [On Fedora 22+ versions]
|
||||
```
|
||||
|
||||
##### 示例输出
|
||||
|
||||
```
|
||||
Installing:
|
||||
python-pip noarch 7.1.0-1.el7 epel 1.5 M
|
||||
Transaction Summary
|
||||
=================================================================================
|
||||
Install 1 Package
|
||||
Total download size: 1.5 M
|
||||
Installed size: 6.6 M
|
||||
Is this ok [y/d/N]: y
|
||||
Downloading packages:
|
||||
python-pip-7.1.0-1.el7.noarch.rpm | 1.5 MB 00:00:01
|
||||
Running transaction check
|
||||
Running transaction test
|
||||
Transaction test succeeded
|
||||
Running transaction
|
||||
Installing : python-pip-7.1.0-1.el7.noarch 1/1
|
||||
Verifying : python-pip-7.1.0-1.el7.noarch 1/1
|
||||
Installed:
|
||||
python-pip.noarch 0:7.1.0-1.el7
|
||||
Complete!
|
||||
```
|
||||
|
||||
### 第二步：在Linux中安装Powerline
|
||||
|
||||
现在可以从Git仓库中安装Powerline的最新开发版。在此之前系统需要安装好Git工具以便可以从仓库拉下代码。
|
||||
|
||||
```
|
||||
# apt-get install git
|
||||
# yum install git
|
||||
# dnf install git
|
||||
```
|
||||
|
||||
然后你可以通过pip命令安装Powerline。
|
||||
|
||||
```
|
||||
# pip install git+git://github.com/Lokaltog/powerline
|
||||
```
|
||||
##### 示例输出
|
||||
|
||||
```
|
||||
Cloning git://github.com/Lokaltog/powerline to /tmp/pip-WAlznH-build
|
||||
Running setup.py (path:/tmp/pip-WAlznH-build/setup.py) egg_info for package from git+git://github.com/Lokaltog/powerline
|
||||
warning: no previously-included files matching '*.pyc' found under directory 'powerline/bindings'
|
||||
warning: no previously-included files matching '*.pyo' found under directory 'powerline/bindings'
|
||||
Installing collected packages: powerline-status
|
||||
Found existing installation: powerline-status 2.2
|
||||
Uninstalling powerline-status:
|
||||
Successfully uninstalled powerline-status
|
||||
Running setup.py install for powerline-status
|
||||
warning: no previously-included files matching '*.pyc' found under directory 'powerline/bindings'
|
||||
warning: no previously-included files matching '*.pyo' found under directory 'powerline/bindings'
|
||||
changing mode of build/scripts-2.7/powerline-lint from 644 to 755
|
||||
changing mode of build/scripts-2.7/powerline-daemon from 644 to 755
|
||||
changing mode of build/scripts-2.7/powerline-render from 644 to 755
|
||||
changing mode of build/scripts-2.7/powerline-config from 644 to 755
|
||||
changing mode of /usr/local/bin/powerline-config to 755
|
||||
changing mode of /usr/local/bin/powerline-lint to 755
|
||||
changing mode of /usr/local/bin/powerline-render to 755
|
||||
changing mode of /usr/local/bin/powerline-daemon to 755
|
||||
Successfully installed powerline-status
|
||||
Cleaning up...
|
||||
```
|
||||
### 第三步：在Linux中安装Powerline的字体
|
||||
|
||||
Powerline使用特殊的符号来为开发者显示特殊的箭头效果和符号内容。因此你的系统中必须要有符号字体或者补丁字体。
|
||||
|
||||
通过下面的[wget][5]命令下载最新的系统字体及字体配置文件。
|
||||
|
||||
```
|
||||
# wget https://github.com/powerline/powerline/raw/develop/font/PowerlineSymbols.otf
|
||||
# wget https://github.com/powerline/powerline/raw/develop/font/10-powerline-symbols.conf
|
||||
```
|
||||
|
||||
然后你将下载的字体放到字体目录下/usr/share/fonts或者/usr/local/share/fonts，或者你可以通过'xset q'命令找到一个有效的字体目录。
|
||||
|
||||
```
|
||||
# mv PowerlineSymbols.otf /usr/share/fonts/
|
||||
```
|
||||
接下来你需要通过如下命令更新你系统的字体缓存。
|
||||
|
||||
```
|
||||
# fc-cache -vf /usr/share/fonts/
|
||||
```
|
||||
其次安装字体配置文件。
|
||||
|
||||
```
|
||||
# mv 10-powerline-symbols.conf /etc/fonts/conf.d/
|
||||
```
|
||||
注意：如果相应的符号没有出现，可以尝试关闭终端会话并重启X window，这样就会生效了。
|
||||
|
||||
### 步骤4：给Bash Shell和Vim状态行设置Powerline
|
||||
|
||||
在这一节将介绍bash shell和vim editor中关于Powerline的配置。首先通过在~/.bashrc中添加如下内容以便设置终端为256色。
|
||||
|
||||
```
|
||||
export TERM=”screen-256color”
|
||||
```
|
||||
|
||||
#### 打开Bash Shell中的Powerline
|
||||
|
||||
如果希望在bash shell中默认打开Powerline，可以在~/.bashrc中添加如下内容。
|
||||
|
||||
首先通过如下命令获取powerline的安装位置。
|
||||
|
||||
```
|
||||
# pip show powerline-status
|
||||
Name: powerline-status
|
||||
Version: 2.2.dev9999-git.aa33599e3fb363ab7f2744ce95b7c6465eef7f08
|
||||
Location: /usr/local/lib/python2.7/dist-packages
|
||||
Requires:
|
||||
```
|
||||
|
||||
一旦找到powerline的真正位置后，建议最好替换到下面的位置。
|
||||
|
||||
```
|
||||
powerline-daemon -q
|
||||
POWERLINE_BASH_CONTINUATION=1
|
||||
POWERLINE_BASH_SELECT=1
|
||||
. /usr/local/lib/python2.7/dist-packages/powerline/bindings/bash/powerline.sh
|
||||
```
|
||||
然后退出后重新登录，现在powerline的状态行应该如下显示了。
|
||||
|
||||
[
|
||||
|
||||
][6]
|
||||
|
||||
现在切换目录并注意显示你当前路径的面包屑提示的变化。
|
||||
|
||||
如果远程Linux服务器上安装了powerline，当你用ssh登录上去查看当前正在后台运行的任务时，会看到主机名提示发生变化。
|
||||
|
||||
#### 在Vim中打开Powerline
|
||||
|
||||
如果你喜欢使用vim，正好有一个vim的强力插件。可以在~/.vimrc中添加如下内容打开该插件。
|
||||
|
||||
```
|
||||
set rtp+=/usr/local/lib/python2.7/dist-packages/powerline/bindings/vim/
|
||||
set laststatus=2
|
||||
set t_Co=256
|
||||
```
|
||||
|
||||
然后你打开vim后会看到一个新的状态行:
|
||||
|
||||
[
|
||||
|
||||
][7]
|
||||
|
||||
### 总结
|
||||
|
||||
Powerline可以在某些软件中提供颜色鲜艳、很优美的状态行及提示内容，这对编程环境有利。希望这篇指南对您有帮助，如果您需要帮助或者有任何好的想法，请留言给我。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
|
||||
|
||||
我是Ravi Saive，TecMint的作者。一个喜欢分享诀窍和想法的电脑极客及Linux专家。我的大部分服务都运行在开源平台Linux中。关注我的Twitter，Facebook和Google+。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/powerline-adds-powerful-statuslines-and-prompts-to-vim-and-bash/
|
||||
|
||||
作者：[Ravi Saive][a]
|
||||
译者：[beyondworld](https://github.com/beyondworld)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/admin/
|
||||
[1]:http://www.tecmint.com/vi-editor-usage/
|
||||
[2]:http://www.tecmint.com/wp-content/uploads/2015/10/Install-Powerline-Statuslines-in-Linux.png
|
||||
[3]:http://www.tecmint.com/wp-content/uploads/2015/10/Powerline-Vim-Statuslines.png
|
||||
[4]:http://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/
|
||||
[5]:http://www.tecmint.com/10-wget-command-examples-in-linux/
|
||||
[6]:http://www.tecmint.com/wp-content/uploads/2015/10/Bash-Powerline-Statuslines.gif
|
||||
[7]:http://www.tecmint.com/wp-content/uploads/2015/10/Vim-Powerline-Statuslines.gif
|
||||
@ -1,94 +0,0 @@
|
||||
什么是 SRE（<ruby>网站可靠性工程<rt>Site Reliability Engineering</rt></ruby>）？
|
||||
============================================================
|
||||
|
||||
网站可靠性工程师是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。
|
||||
|
||||
|
||||
|
||||
本文为 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑的 [<ruby>《网站可靠性工程》<rt>Site Reliability Engineering</rt></ruby>][9] 一书的摘录。
|
||||
|
||||
网站可靠性工程在[ 11 月 7-10 日在阿姆斯特丹举办的 O'Reilly Velocity 会议][10]上也有提到。
|
||||
|
||||
### 介绍
|
||||
|
||||
> 希望不是一种策略。
|
||||
>
|
||||
> 传统的 SRE 说
|
||||
|
||||
一个公认的事实是系统不会自己运行。 那么，一个系统 — 尤其是复杂大规模系统 — _应该_怎么运行呢？
|
||||
|
||||
|
||||
### sysadmin 服务管理方法
|
||||
|
||||
以前，公司雇用系统管理员来运行复杂的计算系统。
|
||||
|
||||
系统管理员（或者称为 sysadmin）这种方式包括整合现有软件组件，互相协作来完成一个服务。系统管理员的任务是运行服务，响应事件，并在事件发生时进行更新。随着系统复杂度的增长和流量的增长，事件和更新也相应增长，导致管理员团队也越来越庞大以完成这些额外工作。由于系统管理员的角色需要的技能与产品开发人员有很大不同，开发和系统管理员被分为不同的团队：“开发”和“运维”。
|
||||
|
||||
sysadmin 服务管理模型有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手 sysadmin 团队不必重新发明轮子以及从头设计系统。
|
||||
|
||||
此方式将公司开发/运维分离，也有一些缺点和困难。主要有两类：直接代价和间接代价。
|
||||
|
||||
直接代价很显而易见了。利用依靠手工干预来进行变更管理和事件处理的团队进行服务管理，当服务和/或流量增长时，成本是很昂贵的，因为团队随着系统负载的增长也在相应增长。
|
||||
|
||||
开发/运维分离的间接代价可能不那么明显，但常常比直接代价还要昂贵。代价来自于两个团队背景，技术，激励都非常不同。他们使用不同的词汇来描述形式；对技术方案的风险和可能性他们持不同的假设；对产品稳定性的目标级别也会有不同的争议。团队的分离很容易导致不只是激励的不同，还有沟通、目标，以及最终，信任和尊重的分离。这是一种恶性循环。
|
||||
|
||||
因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在开发团队核心中，他们希望推出新功能，并看到它们被用户采纳。在_ops 团队_的核心上， 他们希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。
|
||||
|
||||
两个团队都明白，以最可能的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用常见的斗争形式来提高他们的利益。 ops 团队试图通过提高发布和变更门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对_每个_问题的显式审查，这些问题过去都_曾经_引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有元素都提供相等的值。开发团队很快学会了如何回应。他们有较少的“发布”和更多的“标志翻转”、“增量更新”或 “cherrypicks”。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
|
||||
|
||||
|
||||
### Google 服务管理的方法：网站可靠性工程
|
||||
|
||||
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行我们的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由 sysadmins 手动完成的工作。
|
||||
|
||||
什么是网站可靠性工程，是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时会发生的那样。当我在 2003 年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我假设我是一名 SRE，设计和管理了一个 _我_想要的团队的样子。这个团队已经成为了 Google 的目前的 SRE 团队，它仍如最初一名终生软件工程师所想象的那个样子。
|
||||
|
||||
Google 服务管理方法的主要构成部分是由每个 SRE 团队的组成。作为一个整体，SRE可以分为两大类。
|
||||
|
||||
50-60％ 的人是 Google 软件工程师，或者更确切地说，是通过 Google 软件工程师的标准程序招聘的人。其他 40-50％ 的候选人非常接近 Google 软件工程师资格（即所需技能集的 85-99％），以及一些具有大多数软件工程师没有的一些 SRE 技术技能的人。到目前为止，UNIX 系统内部和网络（第 1 层到第 3 层）的专业知识是我们寻求的两种最常见的替代技术技能。
|
||||
|
||||
所有 SRE 的共同点是对开发软件系统以解决复杂问题的信念和能力。在 SRE 中，我们密切跟踪两个团队的职业发展，并且迄今为止发现在两种工程师之间的表现没有实际差异。事实上，SRE 团队的多样背景经常产生聪明、高质量的系统，这显然是几个技能集合成的产物。
|
||||
|
||||
我们这样招聘 SRE 的结果是，我们有了这样一个团队：（a）手动执行任务很快会变得无聊。（b）他们有必要的技能集来写出软件以取代以前的手动操作，即使解决方案很复杂。SRE 还会与其他开发部门分享学术以及知识背景。因此，SRE 从根本上做了一个运维团队历来做的工作，但它使用具有软件专业知识的工程师，并期望这些内在倾向于用软件，并且有能力用软件的人用软件设计并实现自动化来代替人力劳动。
|
||||
|
||||
按照设计，至关重要的是 SRE 团队专注于工程。没有恒定的工程，运维工作增加，团队将需要更多的人来上工作量。最终，传统的以 ops 为中心的团队与服务规模呈线性关系：如果服务支持的产品成功，运维工作将随着流量而增长。这意味着雇用更多的人一遍又一遍地完成相同的任务。
|
||||
|
||||
为了避免这种命运，负责管理服务的团队需要写代码，否则就会被工作淹没。因此，Google 为 SRE 们 _设置了一个 “ops” 工作的上限，如 ticket、紧急呼叫、手动任务最多只占 50% 工作量_。此上限确保 SRE 团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限;随着时间的推移，除了自己的设备，SRE 团队应该只有很少的运维工作，他们几乎可以完全从事开发任务，因为服务基本上可以运行和维修自己：我们想要的系统是_自动的_，而不只是_自动化_。在实践中，规模和新功能始终 SRE 要考虑的。
|
||||
|
||||
Google 的经验法则是，SRE 团队必须花费剩余的 50％ 的时间来进行实际开发。那么我们该如何执行这个阈值呢？首先，我们必须测量 SRE 如何花费时间。通过测量，我们确保团队不断花费不到 50% 的时间用于开发改变他们实践的工作上。通常这意味着会将一些运维负担转移回开发团队，或者给团队添加新的员工，而不指派该团队额外的运维责任。意识到在运维和开发工作之间保持这种平衡使我们能保证 SRE 具有参与创造性的自主工程的空间，同时仍然保留从运维那学来的智慧。
|
||||
|
||||
我们发现 Google SRE 的运行大规模系统的方法有很多优点。由于 SRE 是直接修改代码以使 Googl e的系统运行自己，SRE 团队的特点是快速创新以及大量接受变革。这样的团队能相对价廉地支持相同的服务，面向运维的团队需要大量的人。相反，运行、维护和改进系统所需的 SRE 的数量随系统的大小而线性地缩放。最后，SRE 不仅规避了开发/运维分裂的障碍，而且这种结构也改善了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉培训整个团队，并且提高了那些在学习构建百万级别分布式系统上有困难的开发人员的技能。
|
||||
|
||||
尽管有这些好处，SRE 模型的特点是其自身独特的挑战。 Google 面临的一个持续挑战是招聘 SRE：SRE 不仅与产品开发招聘流程竞争相同的候选人，而且我们将招聘人员的编码和系统工程技能都设置得如此之高，这意味着我们的招聘池必然很小。由于我们的学科相对新颖独特，在如何建立和管理 SRE 团队方面没有太多的行业信息（不过希望这本书能朝着这个方向迈进！）。一旦 SRE 团队到位，他们潜在的非正统的服务管理方法需要强有力的管理支持。例如，一旦错误预估耗尽，除非是管理层的强制要求, 否则在季度剩余的时间里决定停止发布可能不会被产品开发团队所接受。
|
||||
|
||||
###### DevOps 或者 SRE？
|
||||
|
||||
“DevOps” 这个术语在 2008 年末出现，并在写这篇文章时（2016 年早期）仍在发生变动。 其核心原则：IT 部门在系统设计和开发的每个阶段的参与、对自动化与人力投入的严重依赖、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为向更广泛的组织，管理结构和人员的几种核心 SRE原则。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。
|
||||
|
||||
|
||||
------------------------
|
||||
|
||||
作者简介：Benjamin Treynor Sloss 创造了“网站可靠性工程”一词，他自 2003 年以来一直负责 Google 的全球运营、网络和生产工程。截至 2016 年，他管理着全球范围内一个大约 4000 名软硬件和网络工程师团队。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering
|
||||
|
||||
作者：[Benjamin Treynor][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[1]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[2]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[3]:https://www.oreilly.com/ideas/what-is-sre-site-reliability-engineering
|
||||
[4]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[5]:https://shop.oreilly.com/product/0636920053385.do
|
||||
[6]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[7]:https://pixabay.com/
|
||||
[8]:https://www.oreilly.com/people/benjamin-treynor-sloss
|
||||
[9]:http://shop.oreilly.com/product/0636920041528.do?intcmp=il-webops-books-videos-update-na_new_site_site_reliability_engineering_text_cta
|
||||
[10]:http://conferences.oreilly.com/velocity/devops-web-performance-eu?intcmp=il-webops-confreg-update-vleu16_new_site_what_is_sre_text_cta
|
||||
[11]:https://pixabay.com/
|
||||
@ -1,11 +1,11 @@
|
||||
如何隐藏 Apache 版本号和其他敏感信息
|
||||
============================================================
|
||||
|
||||
当远程请求发送到你的 Apache Web 服务器时，在默认情况下，一些有价值的信息，如 web 服务器版本号、服务器操作系统详细信息、已安装的 Apache 模块等等，这些服务器生成的信息会发送回客户端。
|
||||
当远程请求发送到你的 Apache Web 服务器时，在默认情况下，一些有价值的信息，如 web 服务器版本号、服务器操作系统详细信息、已安装的 Apache 模块等等，会随服务器生成的文档发回客户端。
|
||||
|
||||
这里包含了攻击者可利用的漏洞并访问 web 服务器的很多信息。为了避免显示 web 服务器信息，我们将在本文中演示如何使用特定的 Apache 指令隐藏 Apache Web 服务器的信息。
|
||||
|
||||
**推荐阅读：** [13 个有用的使你的 Apache 服务器安全的贴士][1]
|
||||
**推荐阅读：** [13 个有用的 Apache 服务器安全贴士][1]
|
||||
|
||||
两个重要的指令是：
|
||||
|
||||
@ -15,13 +15,13 @@
|
||||
|
||||
它有三个可能的值：
|
||||
|
||||
1. **On** - 允许在服务器生成的文档中添加尾部页脚行，
|
||||
2. **Off** - 禁用页脚行
|
||||
3. **EMail** - 创建一个 “**mailto:**” 引用; 它将邮件发送到所引用文档的 ServerAdmin。
|
||||
- **On** - 允许在服务器生成的文档中添加尾部页脚行，
|
||||
- **Off** - 禁用页脚行
|
||||
- **EMail** - 创建一个 “**mailto:**” 引用; 它将邮件发送到所引用文档的 ServerAdmin。
|
||||
|
||||
##### ServerTokens
|
||||
|
||||
它确定发送回客户端的服务器响应头字段是否包含服务器操作系统类型的描述和有关已启用的 Apache 模块的信息。
|
||||
它决定发送回客户端的服务器响应头字段是否包含服务器操作系统类型的描述和有关已启用的 Apache 模块的信息。
|
||||
|
||||
此指令具有以下可能的值（以及在设置特定值时发送到客户端的示例信息）：
|
||||
|
||||
@ -40,7 +40,7 @@ ServerTokens OS
|
||||
发送给客户端的信息： Server: Apache/2.4.2 (Unix)
|
||||
```
|
||||
|
||||
**注意**：在 Apache **2.0.44** 之后，**ServerTokens** 同样控制由 **ServerSignature** 指令提供的信息。
|
||||
**注意**：在 Apache **2.0.44** 之后，**ServerTokens** 也控制由 **ServerSignature** 指令提供的信息。
|
||||
|
||||
**推荐阅读：** [5 个加速 Apache Web 服务器的贴士][2]
|
||||
|
||||
@ -83,7 +83,7 @@ via: http://www.tecmint.com/hide-apache-web-server-version-information/
|
||||
|
||||
作者：[Aaron Kili][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[jasminepeng](https://github.com/jasminepeng)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
如何在 HTTP 头中隐藏 PHP 版本号
|
||||
============================================================
|
||||
|
||||
PHP 配置默认允许服务器在 HTTP 响应头 “**X-Powered-By**” 显示安装在服务器上的 PHP 版本。
|
||||
PHP 配置默认允许服务器在 HTTP 响应头 “**X-Powered-By**” 中显示安装在服务器上的 PHP 版本。
|
||||
|
||||
出于服务器安全原因（虽然不是主要的要担心的威胁），建议你禁用或隐藏此信息，避免那些针对你的服务器的攻击者知道你是否运行了 PHP。
|
||||
|
||||
假设你服务器上安装的特定版本的 PHP 具有安全漏洞，另一方面，攻击者可以了解这一点，他们将更容易利用漏洞并通过脚本访问服务器。
|
||||
|
||||
在我以前的文章中，我已经展示了[如何隐藏 apache 版本号][1]，在那里你已经看到如何不再显示 apache 的安装版本。但是如果你在你的 apache 服务器上运行 PHP，你需要隐藏 PHP 的安装版本，这我们将在本文中展示。
|
||||
在我以前的文章中，我已经展示了[如何隐藏 apache 版本号][1]，你已经看到如何不再显示 apache 的安装版本。但是如果你在你的 apache 服务器上运行 PHP，你需要隐藏 PHP 的安装版本，这我们将在本文中展示。
|
||||
|
||||
因此，在本文中，我们将解释如何隐藏或关闭服务器 HTTP 响应头中的 PHP 版本号。
|
||||
|
||||
@ -48,7 +48,7 @@ $ sudo vi /etc/php/7.0/cli/php.ini
|
||||
expose_php = off
|
||||
```
|
||||
|
||||
保存并退出文件。在这之后，重启 web 服务器：
|
||||
保存并退出文件。之后，重启 web 服务器：
|
||||
|
||||
```
|
||||
---------------- 使用 SystemD ----------------
|
||||
@ -59,7 +59,7 @@ $ sudo service httpd restart
|
||||
$ sudo service apache2 restart
|
||||
```
|
||||
|
||||
最后但并非不重要，使用下面的命令检查服务器 HTTP 响应头是否仍然显示你的 PHP 版本号。
|
||||
最后，不过同样重要，使用下面的命令检查服务器 HTTP 响应头是否仍然显示你的 PHP 版本号。
|
||||
|
||||
```
|
||||
$ lynx -head -mime_header http://localhost
|
||||
@ -67,10 +67,10 @@ $ lynx -head -mime_header http://localhost
|
||||
$ lynx -head -mime_header http://server-address
|
||||
```
|
||||
|
||||
这里的标志是：
|
||||
这里的标志含义是：
|
||||
|
||||
1. `-head` – 发送对 mime 报头的 HEAD 请求。
|
||||
2. `-mime_header` – 打印所提取文档的 MIME 标头及其来源。
|
||||
- `-head` – 发送对 mime 报头的 HEAD 请求。
|
||||
- `-mime_header` – 打印所提取文档的 MIME 标头及其来源。
|
||||
|
||||
**注意**: 确保你系统中已经安装了 [lynx- 命令行 web 浏览器][3]。
|
||||
|
||||
|
||||
@ -0,0 +1,73 @@
|
||||
5 个用于日志记录以及监控的 DevOps 工具
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
这些 DevOps 日志记录和监控工具是重塑云计算趋势的一部分 - 在“开放云”指南中了解更多。
|
||||
|
||||
[Creative Commons Zero][1]Pixabay
|
||||
|
||||
在云中，开源工具和应用程序对 DevOps 提高了很多效率，对于日志记录和监视解决方案尤其如此。监控云平台，应用程序和组件以及处理和分析日志对于确保高可用性、高性能、低延迟等至关重要。事实上，RightScale 最近的[云状态调查][4]报告中说，最常见的云优化的行为中，45％ 的大公司和中小型企业关注的是监控。
|
||||
|
||||
然而，专有的记录和监控解决方案是昂贵的。更糟的是，它们通常捆绑更昂贵的管理服务产品。
|
||||
|
||||
进入强大的开放日志和监控解决方案的新浪潮。其中一些关注于有针对性的任务，例如容器集群的监控和性能分析，而其他作为整体监控和警报工具包，它们能够进行多维度的数据收集和查询。
|
||||
|
||||
Linux基金会最近[宣布][5]了报告[开放云指导：当前趋势和开源项目][6]。这第三份年度报告全面地介绍了开放云计算的状态，包括有关 DevOps 社区的日志记录和监控的部分。该报告现在可以[下载][7]、汇总和分析研究了，它阐述了容器、监控，更多的是重塑云计算的趋势。该报告提供了对当今开放云环境的中心的分类项目的描述和链接。需要特别注意的是，DevOps 已经成为云中应用交付和维护的最有效方法。
|
||||
|
||||
在这里的[一系列帖子][8]中，我们按照类别从指南中列出了这些项目，提供了关于整体类别如何发展的额外见解。下面，你将看到一些用于记录和监视的重要 DevOps 工具集合，以及它们所带来的影响，以及它们的 GitHub 链接，这些都是从“开放云”指南收集而来的：
|
||||
|
||||
### 日志记录和监控
|
||||
|
||||
[Fluentd][9]
|
||||
|
||||
Fluentd 是一个用于统一日志记录层的开源数据收集器，由 Treasure Data 赞助。它将数据结构化为 JSON，以统一处理日志数据的所有方面：在多个源和目标之间收集、过滤、缓冲和输出日志。[Fluentd 的 GitHub][10]
|
||||
|
||||
[Heapster][11]
|
||||
|
||||
Heapster 是 Kubernetes 的一个容器集群监控和性能分析工具。它本身支持 Kubernetes 和 CoreOS，并可以适应在 OpenShift 上运行。它还支持可插拔的存储后端：使用 Grafana 的 InfluxDB、Google Cloud Monitoring、Google Cloud Logging、Hawkular、Riemann 和 Kafka。[Heapster 的 GitHub][12]
|
||||
|
||||
[Logstash][13]
|
||||
|
||||
Logstash 是 Elastic 的开源数据管道，用于帮助处理来自各种系统的日志和其他事件数据。它的插件可以连接到各种源和大规模流数据到中央分析系统。[LogStash 的 GitHub][14]
|
||||
|
||||
[Prometheus][15]
|
||||
|
||||
Prometheus 是一个开源系统监控和警报工具包，最初由 SoundCloud 构建，现在是 Linux 基金会的云计算基础项目。它适用于以机器为中心和微服务架构，并支持多维度数据收集和查询。[Prometheus 的 GitHub][16]
|
||||
|
||||
|
||||
[Weave Scope][17]
|
||||
|
||||
Weave Scope 是 Weaveworks 的开源工具，用于实时监控分布式应用程序及其容器。它与 Kubernetes 和 AWS ECS 集成。[Weave Scope 的 GitHub][18]
|
||||
|
||||
_了解更多关于开源云计算的趋势，并查看顶级开源云计算项目的完整列表。[现在下载 Linux 基金会的开放云报告指南][3]！ _
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/open-cloud-report/2016/5-devops-tools-logging-and-monitoring
|
||||
|
||||
作者：[SAM DEAN][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/sam-dean
|
||||
[1]:https://www.linux.com/licenses/category/creative-commons-zero
|
||||
[2]:https://www.linux.com/files/images/devops-loggingjpg
|
||||
[3]:http://bit.ly/2eHQOwy
|
||||
[4]:http://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2016-state-cloud-survey
|
||||
[5]:https://www.linux.com/blog/linux-foundation-issues-2016-guide-open-source-cloud-projects
|
||||
[6]:http://go.linuxfoundation.org/l/6342/2016-10-31/3krbjr?utm_source=press-release&utm_medium=pr&utm_campaign=open-cloud-report-2016
|
||||
[7]:http://go.linuxfoundation.org/l/6342/2016-10-31/3krbjr
|
||||
[8]:https://www.linux.com/news/open-cloud-report/2016/guide-open-cloud-state-micro-oses
|
||||
[9]:http://www.fluentd.org/
|
||||
[10]:https://github.com/fluent
|
||||
[11]:http://blog.kubernetes.io/2015/05/resource-usage-monitoring-kubernetes.html
|
||||
[12]:https://github.com/kubernetes/heapster
|
||||
[13]:https://www.elastic.co/products/logstash
|
||||
[14]:https://github.com/elastic/logstash
|
||||
[15]:https://prometheus.io/
|
||||
[16]:https://github.com/prometheus
|
||||
[17]:https://www.weave.works/products/weave-scope/
|
||||
[18]:https://github.com/weaveworks/scope
|
||||
@ -0,0 +1,55 @@
|
||||
5 个新的使用 OpenStack 指南
|
||||
============================================================
|
||||
|
||||
|
||||
图片提供：opensource.com
|
||||
|
||||
OpenStack 经验仍然是技术世界中最需要的技能，越来越多的组织正在寻求构建和管理自己的开源云。但是 OpenStack 是一个巨大的知识领域，包含了十几个正在积极开发的单独项目。只是保持更新你的技能仍可能是一个挑战。
|
||||
|
||||
好消息是现在有很多资源可以让你跟上。除了[官方项目文档][9]，各种培训和认证程序、印刷指南和其他资源，还有大量的由 OpenStack 社区成员编写并发布在各种博客和线上出版物上的教程和指南。
|
||||
|
||||
在 Opensource.com，我们每个月都会收集这些社区创建的资源中的最好的资源，并将它们放到一个集锦中。这是我们上个月的内容。
|
||||
|
||||
* 这次是来自 Julie Pichon 对[ Mistral 在 TripleO 中的使用][1]的一个快速介绍。Mistral 是一个工作流服务，允许你设置一个多步过程自动化和异步协调操作。在本快速指南中学习 Mistral 的基础知识、它如何工作，以及如何在 TripleO 中使用它。
|
||||
|
||||
* 想深入了解 TripleO 来使用 OpenStack 自己的一套工具来管理 OpenStack 部署么？你会想看看这[一套为那些在 OpenStack 设置中使用 TripleO 写的 cheatsheets][2]。这是一个正在进行的工作，所以如果你还想包含什么，欢迎随时自由贡献。
|
||||
|
||||
* 完成我们的 TripleO 指南，不要错过这个[快速指南][3]来使用 TripleO 设置独立的 Ceph 部署。它所需要的是一个简短的 YAML 文件和一个简单的命令。
|
||||
|
||||
* 接下来，如果你是一个 OpenStack 贡献者，你可能会熟悉[ Grafana 面板][4]，它显示了 OpenStack 持续集成基础设施的各种指标。有没有想过这个服务如何工作，或想创建一个新的指标到面板上？学习[如何创建][5]你自己的本地面板的副本，它用于测试目的，所以你可以玩弄它，并创建自己的修改。
|
||||
|
||||
* 有没有想过 OpenStack 云上的网络发生了什么？OpenStack 经常使用[ Open vSwitch ][6]用于 Neutron 和 Nova 的网络服务;在[这个演练][7]中学习设置的基础。
|
||||
|
||||
* * *
|
||||
|
||||
这次就是这样了。和往常一样，请务必查看我们完整的[ OpenStack 教程][10]，它汇集了过去三年发布的数百个单独的指南。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Jason Baker - Jason 热衷于使用技术使世界更加开放，从软件开发到给当地政府带来阳光。Linux 桌面爱好者。地图/地理空间书呆子。树莓派工匠。数据分析和可视化 geek。偶尔的码农。 云本土主义者。在 Twitter 上关注他。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/openstack-tutorials
|
||||
|
||||
作者：[Jason Baker][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/jason-baker
|
||||
[1]:http://www.jpichon.net/blog/2016/12/quick-introduction-mistral-tripleo/
|
||||
[2]:http://www.anstack.com/blog/2016/12/16/printing-tripleo-cheat-sheet.html
|
||||
[3]:http://giuliofidente.com/2016/12/tripleo-to-deploy-ceph-standlone.html
|
||||
[4]:http://grafana.openstack.org/
|
||||
[5]:http://blog.cafarelli.fr/2016/12/local-testing-of-openstack-grafana-dashboard-changes/
|
||||
[6]:http://openvswitch.org/
|
||||
[7]:http://superuser.openstack.org/articles/openvswitch-openstack-sdn/
|
||||
[8]:https://opensource.com/article/17/1/openstack-tutorials?rate=q5H-KT2pm4NLExRhlHc0ru2dyjLkTSA45wim_2KtIec
|
||||
[9]:http://docs.openstack.org/
|
||||
[10]:https://opensource.com/resources/openstack-tutorials
|
||||
[11]:https://opensource.com/user/19894/feed
|
||||
[12]:https://opensource.com/users/jason-baker
|
||||
Loading…
Reference in New Issue
Block a user