mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
fc9ecb5051
@ -0,0 +1,99 @@
|
||||
5 款适合程序员的开源字体
|
||||
======
|
||||
|
||||
> 编程字体有些在普通字体中没有的特点，这五种字体你可以看看。
|
||||
|
||||
|
||||
|
||||
什么是最好的编程字体呢？首先，你需要考虑到字体被设计出来的初衷可能并不相同。当选择一款用于休闲阅读的字体时，读者希望该字体的字母能够顺滑地衔接，提供一种轻松愉悦的体验。一款标准字体的每个字符，类似于拼图的一块，它需要被仔细的设计，从而与整个字体的其他部分融合在一起。
|
||||
|
||||
然而，在编写代码时，通常来说对字体的要求更具功能性。这也是为什么大多数程序员在选择时更偏爱使用固定宽度的等宽字体。选择一款带有容易分辨的数字和标点的字体在美学上令人愉悦；但它是否拥有满足你需求的版权许可也是非常重要的。
|
||||
|
||||
某些功能使得字体更适合编程。首先要清楚是什么使得等宽字体看上去井然有序。这里，让我们对比一下字母 `w` 和字母 `i`。当选择一款字体时，重要的是要考虑字母本身及周围的空白。在纸质的书籍和报纸中，有效地利用空间是极为重要的，为瘦小的 `i` 分配较小的空间，为宽大的字母 `w` 分配较大的空间是有意义的。
|
||||
|
||||
然而在终端中，你没有这些限制。每个字符享有相等的空间将非常有用。这么做的首要好处是你可以随意扫过一段代码来“估测”代码的长度。第二个好处是能够轻松地对齐字符和标点，高亮在视觉上更加明显。另外打印纸张上的等宽字体比均衡字体更加容易通过 OCR 识别。
|
||||
|
||||
在本篇文章中，我们将探索 5 款卓越的开源字体，使用它们来编程和写代码都非常理想。
|
||||
|
||||
### 1、Firacode：最佳整套编程字体
|
||||
|
||||
![FiraCode 示例][1]
|
||||
|
||||
*FiraCode, Andrew Lekashman*
|
||||
|
||||
在我们列表上的首款字体是 [FiraCode][3]，一款真正符合甚至超越了其职责的编程字体。FiraCode 是 Fira 的扩展，而后者是由 Mozilla 委托设计的开源字体族。使得 FiraCode 与众不同的原因是它修改了在代码中常使用的一些符号的组合或连字，使得它看上去更具可读性。这款字体有几种不同的风格，特别是还包含 Retina 选项。你可以在它的 [GitHub][3] 主页中找到它被使用到多种编程语言中的例子。
|
||||
|
||||
![FiraCode compared to Fira Mono][2]
|
||||
|
||||
*FiraCode 与 Fira Mono 的对比，[Nikita Prokopov][3]，源自 GitHub*
|
||||
|
||||
### 2、Inconsolata：优雅且由卓越设计者创造
|
||||
|
||||
![Inconsolata 示例][4]
|
||||
|
||||
*Inconsolata, Andrew Lekashman*
|
||||
|
||||
[Inconsolata][5] 是最为漂亮的等宽字体之一。从 2006 年开始它便一直是一款开源和可免费获取的字体。它的创造者 Raph Levien 在设计 Inconsolata 时秉承的一个基本原则是：等宽字体并不应该那么糟糕。使得 Inconsolata 如此优秀的两个原因是：对于 `0` 和 `o` 这两个字符它们有很大的不同，另外它还特别地设计了标点符号。
|
||||
|
||||
### 3、DejaVu Sans Mono：许多 Linux 发行版的标准配置，庞大的字形覆盖率
|
||||
|
||||
![DejaVu Sans Mono example][6]
|
||||
|
||||
*DejaVu Sans Mono, Andrew Lekashman*
|
||||
|
||||
受在 GNOME 中使用的带有版权和闭源的 Vera 字体的启发，[DejaVu Sans Mono][7] 是一个非常受欢迎的编程字体，几乎在每个现代的 Linux 发行版中都带有它。在 Book Variant 风格下 DejaVu 拥有惊人的 3310 个字形，相比于一般的字体，它们含有 100 个左右的字形。在工作中你将不会出现缺少某些字符的情况，它覆盖了 Unicode 的绝大部分，并且一直在活跃地增长着。
|
||||
|
||||
### 4、Source Code Pro：优雅、可读性强，由 Adobe 中一个小巧但天才的团队打造
|
||||
|
||||
![Source Code Pro example][8]
|
||||
|
||||
*Source Code Pro, Andrew Lekashman*
|
||||
|
||||
由 Paul Hunt 和 Teo Tuominen 设计，[Source Code Pro][9] 是[由 Adobe 创造的][10]，成为了它的首款开源字体。Source Code Pro 值得注意的地方在于它极具可读性，且对于容易混淆的字符和标点，它有着非常好的区分度。Source Code Pro 也是一个字体族，有 7 中不同的风格：Extralight、Light、Regular、Medium、Semibold、Bold 和 Black，每种风格都还有斜体变体。
|
||||
|
||||
![Differentiating potentially confusable characters][11]
|
||||
|
||||
*潜在易混淆的字符之间的区别，[Paul D. Hunt][10] 源自 Adobe Typekit 博客。*
|
||||
|
||||
![Metacharacters with special meaning in computer languages][12]
|
||||
|
||||
*在计算机领域中有特别含义的特殊元字符， [Paul D. Hunt][10] 源自 Adobe Typekit 博客。*
|
||||
|
||||
### 5、Noto Mono：巨量的语言覆盖率，由 Google 中的一个大团队打造
|
||||
|
||||
![Noto Mono example][13]
|
||||
|
||||
*Noto Mono, Andrew Lekashman*
|
||||
|
||||
在我们列表上的最后一款字体是 [Noto Mono][14]，这是 Google 打造的庞大 Note 字体族中的等宽版本。尽管它并不是专为编程所设计，但它在 209 种语言（包括 emoji 颜文字！）中都可以使用，并且一直在维护和更新。该项目非常庞大，是 Google 宣称 “组织全世界信息” 的使命的延续。假如你想更多地了解它，可以查看这个绝妙的[关于这些字体的视频][15]。
|
||||
|
||||
### 选择合适的字体
|
||||
|
||||
无论你选择那个字体，你都有可能在每天中花费数小时面对它，所以请确保它在审美和哲学层面上与你产生共鸣。选择正确的开源字体是确保你拥有最佳生产环境的一个重要部分。这些字体都是很棒的选择，每个都具有让它脱颖而出的功能强大的特性。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/11/how-select-open-source-programming-font
|
||||
|
||||
作者：[Andrew Lekashman][a]
|
||||
译者：[FSSlc](https://github.com/FSSlc)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com
|
||||
[1]:https://opensource.com/sites/default/files/u128651/firacode.png (FiraCode example)
|
||||
[2]:https://opensource.com/sites/default/files/u128651/firacode2.png (FiraCode compared to Fira Mono)
|
||||
[3]:https://github.com/tonsky/FiraCode
|
||||
[4]:https://opensource.com/sites/default/files/u128651/inconsolata.png (Inconsolata example)
|
||||
[5]:http://www.levien.com/type/myfonts/inconsolata.html
|
||||
[6]:https://opensource.com/sites/default/files/u128651/dejavu_sans_mono.png (DejaVu Sans Mono example)
|
||||
[7]:https://dejavu-fonts.github.io/
|
||||
[8]:https://opensource.com/sites/default/files/u128651/source_code_pro.png (Source Code Pro example)
|
||||
[9]:https://github.com/adobe-fonts/source-code-pro
|
||||
[10]:https://blog.typekit.com/2012/09/24/source-code-pro/
|
||||
[11]:https://opensource.com/sites/default/files/u128651/source_code_pro2.png (Differentiating potentially confusable characters)
|
||||
[12]:https://opensource.com/sites/default/files/u128651/source_code_pro3.png (Metacharacters with special meaning in computer languages)
|
||||
[13]:https://opensource.com/sites/default/files/u128651/noto.png (Noto Mono example)
|
||||
[14]:https://www.google.com/get/noto/#mono-mono
|
||||
[15]:https://www.youtube.com/watch?v=AAzvk9HSi84
|
||||
@ -1,15 +1,17 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10731-1.html)
|
||||
[#]: subject: (How to contribute to the Raspberry Pi community)
|
||||
[#]: via: (https://opensource.com/article/19/3/contribute-raspberry-pi-community)
|
||||
[#]: author: (Anderson Silva (Red Hat) https://opensource.com/users/ansilva/users/kepler22b/users/ansilva)
|
||||
|
||||
如何为树莓派社区做出贡献
|
||||
树莓派使用入门：如何为树莓派社区做出贡献
|
||||
======
|
||||
在我们的入门系列的第 13 篇文章中, 发现参与树莓派社区的方法。
|
||||
|
||||
> 在我们的入门系列的第 13 篇文章中，发现参与树莓派社区的方法。
|
||||
|
||||
![][1]
|
||||
|
||||
这个系列已经逐渐接近尾声，我已经写了很多它的乐趣，我大多希望它能帮助人们使用树莓派进行教育或娱乐。也许这些文章能说服你买你的第一个树莓派，或者让你重新发现抽屉里的吃灰设备。如果这里有真的，那么我认为这个系列就是成功的。
|
||||
@ -24,8 +26,6 @@
|
||||
* 帮助[翻译][7]
|
||||
* 在 [Raspberry Jam][8] 当志愿者
|
||||
|
||||
|
||||
|
||||
这些只是你可以为树莓派社区做贡献的几种方式。最后但同样重要的是，你可以加入我并[投稿文章][9]到你最喜欢的开源网站 [Opensource.com][10]。 :-)
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -35,7 +35,7 @@ via: https://opensource.com/article/19/3/contribute-raspberry-pi-community
|
||||
作者：[Anderson Silva (Red Hat)][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,24 +1,24 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10732-1.html)
|
||||
[#]: subject: (Sweet Home 3D: An open source tool to help you decide on your dream home)
|
||||
[#]: via: (https://opensource.com/article/19/3/tool-find-home)
|
||||
[#]: author: (Jeff Macharyas (Community Moderator) )
|
||||
|
||||
Sweet Home 3D：一个帮助你决定梦想家庭的开源工具
|
||||
Sweet Home 3D：一个帮助你寻找梦想家庭的开源工具
|
||||
======
|
||||
|
||||
室内设计应用可以轻松渲染你喜欢的房子，不管是真实的或是想象的。
|
||||
> 室内设计应用可以轻松渲染你喜欢的房子，不管是真实的或是想象的。
|
||||
|
||||
![Houses in a row][1]
|
||||
|
||||
我最近接受了一份在弗吉尼亚州的新工作。由于我妻子一直在纽约工作，看着我们在纽约的房子直至出售，我有责任出去为我们和我们的猫找一所新房子。在我们搬进去之前她不会看到的房子！
|
||||
我最近接受了一份在弗吉尼亚州的新工作。由于我妻子一直在纽约工作，看着我们在纽约的房子直至出售，我有责任出去为我们和我们的猫找一所新房子。在我们搬进去之前她看不到新房子。
|
||||
|
||||
我和一个房地产经纪人签约，并看了几间房子，拍了许多照片，写下了潦草的笔记。晚上，我会将照片上传到 Google Drive 文件夹中，我和我老婆会通过手机同时查看这些照片，同时我还想记住房间是在右边还是左边，是否有风扇等。
|
||||
我和一个房地产经纪人签约，并看了几间房子，拍了许多照片，写下了潦草的笔记。晚上，我会将照片上传到 Google Drive 文件夹中，我和我老婆会通过手机同时查看这些照片，同时我还要记住房间是在右边还是左边，是否有风扇等。
|
||||
|
||||
由于这是一个相当繁琐且不太准确的方式来展示我的发现，我因此去寻找一个开源解决方案，以更好地展示我们未来的梦想之家将会是什么样的，而不会取决于我的模糊记忆和模糊的照片。
|
||||
由于这是一个相当繁琐且不太准确的展示我的发现的方式，我因此去寻找一个开源解决方案，以更好地展示我们未来的梦想之家将会是什么样的，而不会取决于我的模糊记忆和模糊的照片。
|
||||
|
||||
[Sweet Home 3D][2] 完全满足了我的要求。Sweet Home 3D 可在 Sourceforge 上获取，并在 GNU 通用公共许可证下发布。它的[网站][3]信息非常丰富，我能够立即启动并运行。Sweet Home 3D 由总部位于巴黎的 eTeks 的 Emmanuel Puybaret 开发。
|
||||
|
||||
@ -32,19 +32,19 @@ Sweet Home 3D：一个帮助你决定梦想家庭的开源工具
|
||||
|
||||
现在我画完了“内墙”，我从网站下载了各种“家具”，其中包括实际的家具以及门、窗、架子等。每个项目都以 ZIP 文件的形式下载，因此我创建了一个包含所有未压缩文件的文件夹。我可以自定义每件家具和重复的物品比如门，可以方便地复制粘贴到指定的地方。
|
||||
|
||||
在我将所有墙壁和门窗都布置完后，我就使用应用的 3D 视图浏览房屋。根据照片和记忆，我对所有物体进行了调整直到接近房屋的样子。我可以花更多时间添加纹理，附属家具和物品，但这已经达到了我需要的程度。
|
||||
在我将所有墙壁和门窗都布置完后，我就使用这个应用的 3D 视图浏览房屋。根据照片和记忆，我对所有物体进行了调整，直到接近房屋的样子。我可以花更多时间添加纹理，附属家具和物品，但这已经达到了我需要的程度。
|
||||
|
||||
![Sweet Home 3D floorplan][7]
|
||||
|
||||
完成之后，我将计划导出为 OBJ 文件，它可在各种程序中打开，例如 [Blender][8] 和 Mac 上的 Preview，方便旋转房屋并从各个角度查看。视频功能最有用，我可以创建一个起点，然后在房子中绘制一条路径，并记录“旅程”。我将视频导出为 MOV 文件，并使用 QuickTime 在 Mac 上打开和查看。
|
||||
完成之后，我将该项目导出为 OBJ 文件，它可在各种程序中打开，例如 [Blender][8] 和 Mac 上的“预览”中，方便旋转房屋并从各个角度查看。视频功能最有用，我可以创建一个起点，然后在房子中绘制一条路径，并记录“旅程”。我将视频导出为 MOV 文件，并使用 QuickTime 在 Mac 上打开和查看。
|
||||
|
||||
我的妻子能够（几乎）所有我看到的，我们甚至可以开始在搬家前布置家具。现在，我所要做的就是装上卡车搬到新家。
|
||||
我的妻子能够（几乎）能看到所有我看到的，我们甚至可以开始在搬家前布置家具。现在，我所要做的就是把行李装上卡车搬到新家。
|
||||
|
||||
Sweet Home 3D 在我的新工作中也是有用的。我正在寻找一种方法来改善学院建筑的地图，并计划在 [Inkscape][9] 或 Illustrator 或其他软件中重新绘制它。但是，由于我有平面地图，我可以使用 Sweet Home 3D 创建平面图的 3D 版本并将其上传到我们的网站以便更方便地找到地方。
|
||||
|
||||
### 开源犯罪现场？
|
||||
|
||||
一件有趣的事：根据 [Sweet Home 3D 的博客][10]，“法国法医办公室（科学警察）最近选择 Sweet Home 3D 作为设计计划表示路线和犯罪现场的工具。这是法国政府建议优先考虑免费开源解决方案的具体应用。“
|
||||
一件有趣的事：根据 [Sweet Home 3D 的博客][10]，“法国法医办公室（科学警察）最近选择 Sweet Home 3D 作为设计规划表示路线和犯罪现场的工具。这是法国政府建议优先考虑自由开源解决方案的具体应用。“
|
||||
|
||||
这是公民和政府如何利用开源解决方案创建个人项目、解决犯罪和建立世界的又一点证据。
|
||||
|
||||
@ -55,11 +55,11 @@ via: https://opensource.com/article/19/3/tool-find-home
|
||||
作者：[Jeff Macharyas (Community Moderator)][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:
|
||||
[a]: https://opensource.com/users/jeffmacharyas
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/house_home_colors_live_building.jpg?itok=HLpsIfIL (Houses in a row)
|
||||
[2]: https://sourceforge.net/projects/sweethome3d/
|
||||
@ -1,87 +0,0 @@
|
||||
5 款适合程序员的开源字体
|
||||
======
|
||||
|
||||
|
||||
|
||||
什么是最好的编程字体呢？首先，你需要考虑到字体被设计出来的初衷可能并不相同。当选择一款用于休闲阅读的字体时，读者希望该字体的字母能够顺滑地衔接，提供一种轻松愉悦的体验。一款标准字体的每个字符，类似于拼图的一块，它需要被仔细的设计，从而与整个字体的其他部分融合在一起。
|
||||
|
||||
然而，在书写代码时，通常来说对字体的要求自然会更具功能性。这也是为什么当给定选择时，程序员更偏爱使用固定宽度的等宽字体。选择一款带有容易分辨的数字和标点的字体在美学上令人愉悦；但它是否拥有满足你需求的版权许可也是非常重要的。
|
||||
|
||||
使得一个字体更适合编程需要某些特定的需求。首先使得一款等宽字体看上去有条不紊需要一个非常详细的设定。这里，请考虑一会儿字母 `w` 和字母 `i` 之间的对比吧。当选择一款字体时，正如字母一样，在字母周围的空白也同样值得考虑。在物理书和新闻排版中，高效地使用空格也极为重要，相比于相对宽大的字母 `w`，字体将赋予相对瘦小的 `i` 更少的宽度。
|
||||
|
||||
然而在终端中，很幸运你将没有这些限制。每个字符享有相等的空白将非常有用。这么做的首要好处是你可以高效地通过简单的扫一下代码块，推测出你的代码有多长。第二个好处是能够很容易地对齐字符和标点，字符的高亮在视觉上更加明显。另外打印纸张上的等宽字体比均衡字体更加容易识别。
|
||||
|
||||
在本篇文章中，我们将探索 5 款卓越的开源字体，使用它们来编程和写代码都非常理想。
|
||||
|
||||
### 1. Firacode：最佳整套编程字体
|
||||
![FiraCode 示例][1]
|
||||
FiraCode, Andrew Lekashman
|
||||
|
||||
在我们列表上的首款字体是 [FiraCode][3]，一款真正符合甚至超越了其职责的编程字体。FiraCode 是 Fira 的扩展，而后者是由 Mozilla 委托设计的开源字体族。使得 FiraCode 如此特别的原因是它修改了在代码中常使用的一些符号的组合或连字，使得它看上去非常具有可读性。这款字体有几种不同的风格，特别是还包含 Retina 选项。你可以在它的 [GitHub][3] 主页中找到它被使用到多种编程语言中的例子。
|
||||
|
||||
![FiraCode compared to Fira Mono][2]
|
||||
FiraCode 与 Fira Mono 的对比，[Nikita Prokopov][3]，源自 GitHub
|
||||
|
||||
### 2. Inconsolata：优雅且由卓越设计者创造
|
||||
![Inconsolata 示例][4]
|
||||
Inconsolata, Andrew Lekashman
|
||||
|
||||
[Inconsolata][5] 是最为漂亮的等宽字体之一。从 2006 年开始它便一直是一款开源和可免费获取的字体。它的创造者 Raph Levien 在设计 Inconsolata 时秉承的一个基本原则是：等宽字体并不应该那么糟糕。使得 Inconsolata 如此优秀的两个原因是：对于 `0` 和 `o` 这两个字符它们有很大的不同，另外它还特别地设计了标点符号。
|
||||
|
||||
### 3. DejaVu Sans Mono：许多 Linux 发行版的标准配置，庞大的字形覆盖率
|
||||
![DejaVu Sans Mono example][6]
|
||||
DejaVu Sans Mono, Andrew Lekashman
|
||||
|
||||
受使用在 GNOME 中的带有版权和闭源的 Vera 字体，[DejaVu Sans Mono][7] 是一个非常受欢迎的编程字体，几乎在每个现代的 Linux 发行版中都带有它。在 Book 变种风格下 DejaVu 拥有惊人的 3310 个字形，相比于一般的字体，它们含有 100 个左右的字形。在工作中你将不会出现缺少某些字符的情况，它覆盖了 Unicode 的绝大部分，并且一直在活跃地增长着。
|
||||
|
||||
### 4. Source Code Pro：优雅、可读性强，由 Adobe 中一个小巧但天才的团队打造
|
||||
![Source Code Pro example][8]
|
||||
Source Code Pro, Andrew Lekashman
|
||||
|
||||
由 Paul Hunt 和 Teo Tuominen 设计，[Source Code Pro][9] 是[由 Adobe 创造的][10]它的首款开源字体
|
||||
。Source Code Pro 值得注意的地方在于它非常具有可读性，且对于容易混淆的字符和标点，它有着非常好的区分度。Source Code Pro 也是一个字体族，有 7 中不同的风格： Extralight, Light, Regular, Medium, Semibold, Bold 和 Black，每种风格都还有斜体变体。
|
||||
|
||||
![Differentiating potentially confusable characters][11]
|
||||
|
||||
潜在易混淆的字符之间的区别，[Paul D. Hunt][10] 源自 Adobe Typekit 博客。
|
||||
|
||||
![Metacharacters with special meaning in computer languages][12]
|
||||
在计算机领域中有特别含义的特殊元字符， [Paul D. Hunt][10] 源自 Adobe Typekit 博客。
|
||||
|
||||
### 5. Noto Mono：巨量的语言覆盖率，由 Google 中的一个大团队打造
|
||||
|
||||
![Noto Mono example][13]
|
||||
Noto Mono, Andrew Lekashman
|
||||
|
||||
在我们列表上的最后一款字体是 [Noto Mono][14]， Google 打造的庞大 Note 字体族中的等宽版本。尽管它并不是专为编程所设计，但它在 209 种语言（包括 emoji 颜文字！）中都可以获取到，并且一直在维护和更新。该项目非常庞大，是 Google 宣言“组织全世界信息” 的一个扩展。假如你想更多地了解它，可以查看这个绝妙的[关于这些字体的视频][15]。
|
||||
|
||||
### 选择合适的字体
|
||||
|
||||
无论你选择那个字体，你都有可能在每天中花费数小时面对它，所以请确保它在审美和哲学层面上与你产生共鸣。选择正确的开源字体是确保你拥有最佳生产环境的一个重要部分。这些字体都是奇妙的可选项，每个都具有让它脱颖而出的功能强大的特性。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/11/how-select-open-source-programming-font
|
||||
|
||||
作者：[Andrew Lekashman][a]
|
||||
译者：[FSSlc](https://github.com/FSSlc)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com
|
||||
[1]:https://opensource.com/sites/default/files/u128651/firacode.png (FiraCode example)
|
||||
[2]:https://opensource.com/sites/default/files/u128651/firacode2.png (FiraCode compared to Fira Mono)
|
||||
[3]:https://github.com/tonsky/FiraCode
|
||||
[4]:https://opensource.com/sites/default/files/u128651/inconsolata.png (Inconsolata example)
|
||||
[5]:http://www.levien.com/type/myfonts/inconsolata.html
|
||||
[6]:https://opensource.com/sites/default/files/u128651/dejavu_sans_mono.png (DejaVu Sans Mono example)
|
||||
[7]:https://dejavu-fonts.github.io/
|
||||
[8]:https://opensource.com/sites/default/files/u128651/source_code_pro.png (Source Code Pro example)
|
||||
[9]:https://github.com/adobe-fonts/source-code-pro
|
||||
[10]:https://blog.typekit.com/2012/09/24/source-code-pro/
|
||||
[11]:https://opensource.com/sites/default/files/u128651/source_code_pro2.png (Differentiating potentially confusable characters)
|
||||
[12]:https://opensource.com/sites/default/files/u128651/source_code_pro3.png (Metacharacters with special meaning in computer languages)
|
||||
[13]:https://opensource.com/sites/default/files/u128651/noto.png (Noto Mono example)
|
||||
[14]:https://www.google.com/get/noto/#mono-mono
|
||||
[15]:https://www.youtube.com/watch?v=AAzvk9HSi84
|
||||
@ -1,52 +1,50 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (The Fargate Illusion)
|
||||
[#]: via: (https://leebriggs.co.uk/blog/2019/04/13/the-fargate-illusion.html)
|
||||
[#]: author: (Lee Briggs https://leebriggs.co.uk/)
|
||||
|
||||
Fargate 幻觉
|
||||
破除对 AWS Fargate 的幻觉
|
||||
======
|
||||
|
||||
我在 $work 工作的近一年的时间里建立了一个基于 Kubernetes 的平台，而且成为了一个 Kubernetes 的辩护人。这是真的，我认为这项技术太棒了。然而我没有真正想过它的操作和维护究竟有多困难。我在今年早些时候阅读了[这样][1]的一篇文章，并对其中某些意见深以为然。如果我在一家规模较小的、有 10 到 15 个工程师的公司，假如有人建议管理和维护一批 Kubernetes 集群，我会深感震惊的。因为它的运营开销太高了！
|
||||
我在 $work 建立了一个基于 Kubernetes 的平台已经快一年了，而且有点像 Kubernetes 的布道者了。真的，我认为这项技术太棒了。然而我并没有对它的运营和维护的困难程度抱过什么幻想。今年早些时候我读了[这样][1]的一篇文章，并对其中某些观点深以为然。如果我在一家规模较小的、有 10 到 15 个工程师的公司，假如有人建议管理和维护一批 Kubernetes 集群，那我会感到害怕的，因为它的运维开销太高了！
|
||||
|
||||
尽管我现在对 Kubernetes 的一切都很感兴趣，但我仍然对“<ruby>无服务器<rt>Serverless</rt></ruby>”计算会消灭运维工程师的说法抱有疑问。这种奇谈怪论主要来源于希望在未来仍然能有一份有收益的工作 —— 如果我们前景光明的未来不需要运维工程师，我觉得也没什么大惊小怪的。我已经在 Lamdba 和Google Cloud Functions 上做了一些实验，结果让我印象十分深刻，但我仍然坚信无服务器解决方案只是解决了一部分问题。
|
||||
尽管我现在对 Kubernetes 的一切都很感兴趣，但我仍然对“<ruby>无服务器<rt>Serverless</rt></ruby>”计算会消灭运维工程师的说法抱有好奇。这种好奇心主要来源于我希望在未来仍然能有一份有报酬的工作 —— 如果我们前景光明的未来不需要运维工程师，那我得明白到底是怎么回事。我已经在 Lamdba 和Google Cloud Functions 上做了一些实验，结果让我印象十分深刻，但我仍然坚信无服务器解决方案只是解决了一部分问题。
|
||||
|
||||
我已经关注 [AWS Fargate][2] 已经有一段时间了，这是就是 $work 的开发人员目为“无服务器计算”的东西 —— 主要是因为使用了 Fargate，你就可以运行你的 Docker 容器而不需要管理底层节点。我想看看它到底意味着什么 —— 所以我开始尝试从头开始在 Fargate 上运行一个应用程序。我定义的成功标准是与“生产级”应用程序紧密相关的某些东西，所以我希望得到以下内容：
|
||||
我关注 [AWS Fargate][2] 已经有一段时间了，这就是 $work 的开发人员所推崇为“无服务器计算”的东西 —— 主要是因为 Fargate，用它你就可以无需管理底层节点而运行你的 Docker 容器。我想看看它到底意味着什么，所以我开始尝试从头开始在 Fargate 上运行一个应用，看看是否可以成功。这里我对成功的定义是一个与“生产级”应用程序相近的东西，我想应该包含以下内容：
|
||||
|
||||
* 一个在 Fargate 上运行的容器
|
||||
* 配置以环境变量的形式下推
|
||||
* “隐秘信息” 不能是明文的
|
||||
* 配置信息以环境变量的形式下推
|
||||
* “秘密信息” 不能是明文的
|
||||
* 位于负载均衡器之后
|
||||
* SSL 证书有效的 TLS 通道
|
||||
* 有效的 SSL 证书的 TLS 通道
|
||||
|
||||
我从基础设施即代码的方式开始整个任务，不遵循默认的 AWS 控制台向导，而是使用 terraform 来定义基础架构。这很可能让整个事情变得很复杂，但我想确保任何部署对于任何想要按此步骤复现的人都是可重复的和可发现的。
|
||||
我以“基础设施即代码”的角度来开始整个任务，不遵循默认的 AWS 控制台向导，而是使用 terraform 来定义基础架构。这很可能让整个事情变得复杂，但我想确保任何部署都是可重现的，任何想要遵循此步骤的人都可发现我的结论。
|
||||
|
||||
所有上述标准通常都可以通过基于 Kubernetes 的平台使用一些外部附加组件和插件来实现，所以我确实是以一种比较的心态来处理整个任务 —— 因为我要将它与我的常用工作流程进行比较。我的主要目标是看看Fargate 有多容易，特别是与 Kubernetes 相比时。结果让我感到非常惊讶。
|
||||
上述所有标准通常都可以通过基于 Kubernetes 的平台使用一些外部的附加组件和插件来实现，所以我确实是以一种比较的心态来处理整个任务的，因为我要将它与我的常用工作流程进行比较。我的主要目标是看看Fargate 有多容易，特别是与 Kubernetes 相比时。结果让我感到非常惊讶。
|
||||
|
||||
### AWS 是有开销的
|
||||
|
||||
我有一个干净的 AWS 账户，并决定从零到部署一个 webapp。与 AWS 中的其它基础设施一样，我必须使基本的基础设施正常工作 - 因此我首先必须定义 VPC。
|
||||
我有一个干净的 AWS 账户，并决定从零到部署一个 webapp。与 AWS 中的其它基础设施一样，我必须首先使基本的基础设施正常工作起来，因此我需要先定义一个 VPC。
|
||||
|
||||
遵循最佳实践，因此我将 VPC 划分为可用区域内的子网，具有公共子网和私有子网。在这一点上我想到，只要这种需求存在，我就能找到一份这种工作。AWS 在运维上“免费”这一概念一直让我感到厌倦。开发者社区中的许多人理所当然地认为在设置和定义设计良好的 AWS 账户和基础设施方面不需要多少工作和努力。在我们甚至开始谈论多帐户架构*之前*（现在我仍然使用单一帐户），我必须已经定义好基础设施和传统的网络设备。
|
||||
遵循最佳实践，因此我将这个 VPC 划分为跨可用区（AZ）的子网，一个公共子网和私有子网。这时我想到，只要这种设置基础设施的需求存在，我就能找到一份这种工作。AWS 是运维上“免费”这一概念一直让我感到愤怒。开发者社区中的许多人理所当然地认为在设置和定义一个设计良好的 AWS 账户和基础设施是不需要付出多少工作和努力的。在我们甚至开始谈论多帐户架构*之前*（现在我仍然使用单一帐户），我必须已经定义好基础设施和传统的网络设备。
|
||||
|
||||
这里也值得记住，我已经做了很多次，所以我*知道*该做什么。我可以在我的帐户中使用默认的 VPC 以及预先提供的子网，我觉得很多人也可以使用它。这花了我大约半个小时才能运行，但我不禁想到，即使我想运行 lambda 函数，我仍然需要某种连接和网络。在 VPC 中定义 NAT 网关和路由根本不会让你觉得“无服务器”，但要往下进行这就是必须要做的。
|
||||
这里也值得记住，我已经做了很多次，所以我*很清楚*该做什么。我可以在我的帐户中使用默认的 VPC 以及预先提供的子网，我觉得很多刚开始的人也可以使用它。这大概花了我半个小时才运行起来，但我不禁想到，即使我想运行 lambda 函数，我仍然需要某种连接和网络。在 VPC 中定义 NAT 网关和路由根本不会让你觉得很“无服务器”，但要往下进行这就是必须要做的。
|
||||
|
||||
### 运行简单的容器
|
||||
|
||||
### 运行个简单的容器
|
||||
|
||||
我启动运行了基本的基础设施之后，我想让我的 Docker 容器运行起来。 我开始翻阅 Fargate 文档并浏览 [入门][3] 文档，这些就立即突然出现在了我面前：
|
||||
在我启动运行了基本的基础设施之后，现在我想让我的 Docker 容器运行起来。我开始翻阅 Fargate 文档并浏览 [入门][3] 文档，这些就马上就展现在了我面前：
|
||||
|
||||
![][4]
|
||||
|
||||
等一下，只是让我的容器运行就至少要有**三个**步骤？这完全不像我所想的，不过还是让我们开始吧。
|
||||
等等，只是让我的容器运行就至少要有**三个**步骤？这完全不像我所想的，不过还是让我们开始吧。
|
||||
|
||||
#### 任务定义
|
||||
|
||||
“<ruby>任务定义<rt>Task Definition<rt></ruby>”用来定义要运行的实际容器。我在这里遇到的问题是，任务定义这件事非常复杂。这里有很多选项是非常简单的，比如指定 Docker 镜像和内存限制，但我还必须定义一个网络模型以及我并不熟悉的各种其他选项。真需要这样吗？如果我完全没有 AWS 方面的知识就进入到这个过程里，那么在这个阶段我会感觉非常的不知所措。可以在 AWS 页面上找到这些 [参数][5] 的完整列表，这个列表很长。我知道我的容器需要有一些环境变量，它需要暴露一个端口。所以我首先在一个神奇的 [terraform 模块][6] 的帮助下定义了这一点，这真的让这件事更容易。如果我没有这个模块，我会亲自编写 JSON 来定义我的容器定义。
|
||||
|
||||
“<ruby>任务定义<rt>Task Definition<rt></ruby>”用来定义要运行的实际容器。我在这里遇到的问题是，任务定义这件事非常复杂。这里有很多选项都很简单，比如指定 Docker 镜像和内存限制，但我还必须定义一个网络模型以及我并不熟悉的其它各种选项。真需要这样吗？如果我完全没有 AWS 方面的知识就进入到这个过程里，那么在这个阶段我会感觉非常的不知所措。可以在 AWS 页面上找到这些 [参数][5] 的完整列表，这个列表很长。我知道我的容器需要一些环境变量，它需要暴露一个端口。所以我首先在一个神奇的 [terraform 模块][6] 的帮助下定义了这一点，这真的让这件事更容易了。如果没有这个模块，我就得手工编写 JSON 来定义我的容器定义。
|
||||
|
||||
首先我定义了一些环境变量：
|
||||
|
||||
@ -90,11 +88,11 @@ module "container_definition_app" {
|
||||
}
|
||||
```
|
||||
|
||||
在这一点上我非常困惑 —— 我需要在这里定义很多配置以使其运行，而这时什么都没有开始呢，但这是必要的 —— 运行 Docker 容器肯定需要了解一些容器配置的知识。我 [之前写过][7] 关于 Kubernetes 和配置管理的问题的文章，同样的问题似乎在这里再次抬头。
|
||||
在这一点上我非常困惑，我需要在这里定义很多配置才能运行，而这时什么都没有开始呢，但这是必要的 —— 运行 Docker 容器肯定需要了解一些容器配置的知识。我 [之前写过][7] 关于 Kubernetes 和配置管理的问题的文章，在这里似乎遇到了同样的问题。
|
||||
|
||||
接下来，我从上面的模块中定义了任务定义（幸好从我这里抽象出了所需的 JSON —— 如果我不得不手写JSON，我可能已经放弃了）。
|
||||
接下来，我在上面的模块中定义了任务定义（幸好从我这里抽象出了所需的 JSON —— 如果我不得不手写JSON，我可能已经放弃了）。
|
||||
|
||||
当我定义模块参数时，我突然意识到我错过了一些东西。我也需要一个 IAM 角色！好吧，让我来定义：
|
||||
当我定义模块参数时，我突然意识到我漏掉了一些东西。我需要一个 IAM 角色！好吧，让我来定义：
|
||||
|
||||
```
|
||||
resource "aws_iam_role" "ecs_task_execution" {
|
||||
@ -124,7 +122,7 @@ resource "aws_iam_role_policy_attachment" "ecs_task_execution" {
|
||||
}
|
||||
```
|
||||
|
||||
这样做是有意义的，我需要在 Kubernetes 中定义一个 RBAC 策略，所以我仍然没有完全错失或获得任何东西。在这一点上，我开始觉得从 Kubernetes 的角度来看，这种感觉非常熟悉。
|
||||
这样做是有意义的，我需要在 Kubernetes 中定义一个 RBAC 策略，所以在这里我还未完全错失或获得任何东西。这时我开始觉得从 Kubernetes 的角度来看，这种感觉非常熟悉。
|
||||
|
||||
```
|
||||
resource "aws_ecs_task_definition" "app" {
|
||||
@ -141,11 +139,11 @@ resource "aws_ecs_task_definition" "app" {
|
||||
}
|
||||
```
|
||||
|
||||
在这里，我写了很多行代码以运行起来，我阅读了很多 ECS 文档，我所做的就是定义一个任务定义。我还没有让这个东西运行起来。在这一点上，我真的很困惑这个基于 Kubernetes 的平台增加了什么，但我继续前行。
|
||||
现在，为了运行起来我已经写了很多行代码，我阅读了很多 ECS 文档，我所做的就是定义一个任务定义。我还没有让这个东西运行起来。在这一点上，我真的很困惑这个基于 Kubernetes 的平台到底增值了什么，但我继续前行。
|
||||
|
||||
#### 服务
|
||||
|
||||
服务，一部分是如何将容器暴露给外部，另一部分是如何定义它拥有的副本数量。我的第一个想法是“啊！这就像一个 Kubernetes 服务！”我开始着手映射端口等。这是我第一次在 terraform 上跑：
|
||||
服务，一定程度上是将容器如何暴露给外部，另外是如何定义它拥有的副本数量。我的第一个想法是“啊！这就像一个 Kubernetes 服务！”我开始着手映射端口等。这是我第一次在 terraform 上跑：
|
||||
|
||||
```
|
||||
resource "aws_ecs_service" "app" {
|
||||
@ -165,9 +163,9 @@ resource "aws_ecs_service" "app" {
|
||||
}
|
||||
```
|
||||
|
||||
当我必须为此定义允许访问所需端口的安全组时，我再次感到沮丧，但我这样做了并将其插入到网络配置中后，我就像被扇了一巴掌。
|
||||
当我必须定义允许访问所需端口的安全组时，我再次感到沮丧，当我这样做了并将其插入到网络配置中后，我就像被扇了一巴掌。
|
||||
|
||||
我需要定义自己的负载均衡器？
|
||||
我还需要定义自己的负载均衡器？
|
||||
|
||||
什么？
|
||||
|
||||
@ -175,7 +173,7 @@ resource "aws_ecs_service" "app" {
|
||||
|
||||
##### 负载均衡器从未远离
|
||||
|
||||
老实说，我很满意，我甚至不确定为什么。我已经习惯了 Kubernetes 的服务和 Ingress 对象，我完全认为用 Kubernetes 将我的应用程序放到网上是多么容易。当然，我们在 $work 花了几个月的时间建立一个平台，以便更轻松。我是 [external-dns][8] 和 [cert-manager][9] 的重度用户，它们可以自动填充 Ingress 对象上的 DNS 条目并自动化 TLS 证书，我非常了解进行这些设置所需的工作，但老实说，我认为在 Fargate 上做这件事会更容易。我认识到 Fargate 没有声称自己是如何运行应用程序的全部和最终目的 —— 它只是抽象出节点管理 —— 但我一直被告知这比 Kubernetes *更加容易*。我真的很惊讶。定义负载均衡器（即使你不想使用 Ingress 和 Ingress 控制器）也是向 Kubernetes 部署服务的重要组成部分，我不得不在这里再次做同样的事情。这一切都让人觉得如此熟悉。
|
||||
老实说，我很满意，我甚至不确定为什么。我已经习惯了 Kubernetes 的服务和 Ingress 对象，我一心认为用 Kubernetes 将我的应用程序放到网上是多么容易。当然，我们在 $work 花了几个月的时间建立一个平台，以便更轻松。我是 [external-dns][8] 和 [cert-manager][9] 的重度用户，它们可以自动填充 Ingress 对象上的 DNS 条目并自动化 TLS 证书，我非常了解进行这些设置所需的工作，但老实说，我认为在 Fargate 上做这件事会更容易。我认识到 Fargate 并没有声称自己是“如何运行应用程序”这件事的全部和最终目的，它只是抽象出节点管理，但我一直被告知这比 Kubernetes *更加容易*。我真的很惊讶。定义负载均衡器（即使你不想使用 Ingress 和 Ingress 控制器）也是向 Kubernetes 部署服务的重要组成部分，我不得不在这里再次做同样的事情。这一切都让人觉得如此熟悉。
|
||||
|
||||
我现在意识到我需要：
|
||||
|
||||
@ -183,7 +181,7 @@ resource "aws_ecs_service" "app" {
|
||||
* 一个 TLS 证书
|
||||
* 一个 DNS 名字
|
||||
|
||||
所以我着手做了这些。我使用了一些流行的 terraform 模块，并想出了这个：
|
||||
所以我着手做了这些。我使用了一些流行的 terraform 模块，并做了这个：
|
||||
|
||||
```
|
||||
# Define a wildcard cert for my app
|
||||
@ -245,9 +243,9 @@ resource "aws_lb_listener" "main-tls" {
|
||||
}
|
||||
```
|
||||
|
||||
我必须承认，在这里我搞砸了好几次。我不得不在 AWS 控制台中四处翻弄，以弄清楚我做错了什么。这当然不是一个“轻松”的过程，而且我之前已经做过很多次了。老实说，在这一点上，Kubernetes 看起来对我很有启发性，但我意识到这是因为我对它非常熟悉。幸运的是我能够使用托管的 Kubernetes 平台（预装了 external-dns 和 cert-manager），我真的很想知道 Fargate 缺少了什么。它真的感觉不那么简单。
|
||||
我必须承认，我在这里搞砸了好几次。我不得不在 AWS 控制台中四处翻弄，以弄清楚我做错了什么。这当然不是一个“轻松”的过程，而且我之前已经做过很多次了。老实说，在这一点上，Kubernetes 看起来对我很有启发性，但我意识到这是因为我对它非常熟悉。幸运的是我能够使用托管的 Kubernetes 平台（预装了 external-dns 和 cert-manager），我真的很想知道我漏掉了 Fargate 什么增值的地方。它真的感觉不那么简单。
|
||||
|
||||
经过一番折腾，我现在有一个可以工作的 ECS 服务。包括服务在内的最终定义看起来有点像这样：
|
||||
经过一番折腾，我现在有一个可以工作的 ECS 服务。包括服务在内的最终定义如下所示：
|
||||
|
||||
```
|
||||
data "aws_ecs_task_definition" "app" {
|
||||
@ -282,11 +280,11 @@ resource "aws_ecs_service" "app" {
|
||||
}
|
||||
```
|
||||
|
||||
我觉得我已经接近完成了，但后来我记起了我只完成了最初的“入门”文档中所需的 3 个步骤中的 2 个 —— 我仍然需要定义 ECS 群集。
|
||||
我觉得我已经接近完成了，但后来我记起了我只完成了最初的“入门”文档中所需的 3 个步骤中的 2 个，我仍然需要定义 ECS 群集。
|
||||
|
||||
#### 集群
|
||||
|
||||
感谢 [定义模块][10]，定义要运行所有这些的集群实际上非常简单。
|
||||
感谢 [定义模块][10]，定义要所有这些运行的集群实际上非常简单。
|
||||
|
||||
```
|
||||
module "ecs" {
|
||||
@ -297,12 +295,12 @@ module "ecs" {
|
||||
}
|
||||
```
|
||||
|
||||
这里让我感到惊讶的是为什么我必须完全定义一个集群。作为一个熟悉 ECS 的人，你会觉得你需要一个集群，但我试图从一个必须经历这个过程的新人的角度来考虑这一点 —— 对我来说，Fargate 标榜自己“
|
||||
无服务器”而你仍需要定义集群，这似乎很令人惊讶。这是一个小细节，但它确实盘旋在我的脑海里。
|
||||
这里让我感到惊讶的是为什么我必须定义一个集群。作为一个相当熟悉 ECS 的人，你会觉得你需要一个集群，但我试图从一个必须经历这个过程的新人的角度来考虑这一点 —— 对我来说，Fargate 标榜自己“
|
||||
无服务器”而你仍需要定义集群，这似乎很令人惊讶。当然这是一个小细节，但它确实盘旋在我的脑海里。
|
||||
|
||||
### 告诉我你的秘密
|
||||
|
||||
在这个阶段，我很高兴我成功地运行了一些东西。然而，我的原始标准缺少一些东西。如果我们回到任务定义那里，你会记得我的应用程序有一个存放密码的环境变量：
|
||||
在这个阶段，我很高兴我成功地运行了一些东西。然而，我的原始的成功标准缺少一些东西。如果我们回到任务定义那里，你会记得我的应用程序有一个存放密码的环境变量：
|
||||
|
||||
```
|
||||
container_environment_variables = [
|
||||
@ -317,20 +315,18 @@ container_environment_variables = [
|
||||
]
|
||||
```
|
||||
|
||||
如果我在 AWS 控制台中查看我的任务定义，我的密码就在那里，明晃晃的明文。我希望不要这样，所以我开始尝试将其转化为其他东西，类似于 [Kubernetes secrets][11]。
|
||||
如果我在 AWS 控制台中查看我的任务定义，我的密码就在那里，明晃晃的明文。我希望不要这样，所以我开始尝试将其转化为其他东西，类似于 [Kubernetes 的秘密信息管理][11]。
|
||||
|
||||
#### AWS SSM
|
||||
|
||||
Fargate / ECS 执行<ruby>秘密管理<rt>secret management</rt></ruby>部分的方式是使用 [AWS SSM][12]（此服务的全名是 AWS 系统管理器参数存储库，但我不想使用这个名称，因为坦率地说这个名字太愚蠢了）。
|
||||
Fargate / ECS 执行<ruby>秘密信息管理<rt>secret management</rt></ruby>部分的方式是使用 [AWS SSM][12]（此服务的全名是 AWS 系统管理器参数存储库，但我不想使用这个名称，因为坦率地说这个名字太愚蠢了）。
|
||||
|
||||
AWS 文档很好的[涵盖了这个内容][13]，因此我开始将其转换为 terraform。
|
||||
|
||||
|
||||
##### 指定秘密信息
|
||||
|
||||
首先，你必须定义一个参数并为其命名。在 terraform 中，它看起来像这样：
|
||||
|
||||
|
||||
```
|
||||
resource "aws_ssm_parameter" "app_password" {
|
||||
name = "${var.app_password_param_name}" # The name of the value in AWS SSM
|
||||
@ -339,7 +335,7 @@ resource "aws_ssm_parameter" "app_password" {
|
||||
}
|
||||
```
|
||||
|
||||
显然，这里的关键组件是 “SecureString” 类型。这会使用默认的 AWS KMS 密钥来加密数据，这对我来说并不是很直观。这比 Kubernetes 秘密具有巨大优势，默认情况下，这些秘密信息在 etcd 中是不加密的。
|
||||
显然，这里的关键部分是 “SecureString” 类型。这会使用默认的 AWS KMS 密钥来加密数据，这对我来说并不是很直观。这比 Kubernetes 的秘密信息管理具有巨大优势，默认情况下，这些秘密信息在 etcd 中是不加密的。
|
||||
|
||||
然后我为 ECS 指定了另一个本地值映射，并将其作为秘密参数传递：
|
||||
|
||||
@ -376,23 +372,23 @@ module "container_definition_app" {
|
||||
|
||||
##### 出了个问题
|
||||
|
||||
此时，我重新部署了我的任务定义，并且非常困惑。为什么任务没有正确拉起？当新的任务定义（版本 8）可用时，我一直在控制台中看到正在运行的应用程序仍在使用先前的任务定义（版本 7）。这件事花费的时间比我预期的要长，但是在控制台的事件屏幕上，我注意到了 IAM 错误。我错过了一个步骤，容器无法从 AWS SSM 中读取秘密信息，因为它没有正确的 IAM 权限。这是我第一次真正对整个这件事情感到沮丧。从用户体验的角度来看，这里的反馈非常*糟糕*。如果我没有发觉的话，我会认为一切都很好，因为仍然有一个任务正在运行，我的应用程序仍然可以通过正确的 URL 访问 —— 只不过是旧的配置而已。
|
||||
此刻，我重新部署了我的任务定义，并且非常困惑。为什么任务没有正确拉起？当新的任务定义（版本 8）可用时，我一直在控制台中看到正在运行的应用程序仍在使用先前的任务定义（版本 7）。解决这件事花费的时间比我预期的要长，但是在控制台的事件屏幕上，我注意到了 IAM 错误。我错过了一个步骤，容器无法从 AWS SSM 中读取秘密信息，因为它没有正确的 IAM 权限。这是我第一次真正对整个这件事情感到沮丧。从用户体验的角度来看，这里的反馈非常*糟糕*。如果我没有发觉的话，我会认为一切都很好，因为仍然有一个任务正在运行，我的应用程序仍然可以通过正确的 URL 访问 —— 只不过是旧的配置而已。
|
||||
|
||||
在 Kubernetes 里，我会清楚地看到 pod 定义中的错误。Fargate 可以确保我的应用不会停止，这绝对是太棒了，但作为一名运维，我需要一些关于发生了什么的实际反馈。这真的不够好。我真的希望 Fargate 团队的人能够读到这篇文章，改善这种体验。
|
||||
|
||||
### 就这样了
|
||||
|
||||
到这里就结束了 —— 我的应用程序正在运行，也符合我的所有标准。我确实意识到我做了一些改进，其中包括：
|
||||
到这里就结束了，我的应用程序正在运行，也符合我的所有标准。我确实意识到我做了一些改进，其中包括：
|
||||
|
||||
* 定义一个 cloudwatch 日志组，这样我就可以正确地写日志了
|
||||
* 添加了一个 route53 托管区域，使整个事情从 DNS 角度更容易自动化
|
||||
* 修复并重新调整了 IAM 权限，这里太宽泛了
|
||||
|
||||
但老实说，在这一点上我想反思一下这段经历。我写了一个关于我的经历的 [推特会话][14]，然后花了其余时间思考我在这里真正感受到的。
|
||||
但老实说，现在我想反思一下这段经历。我写了一个关于我的经历的 [推特会话][14]，然后花了其余时间思考我在这里的真实感受。
|
||||
|
||||
### 代价
|
||||
|
||||
经过一夜的反思，我意识到无论你是使用 Fargate 还是 Kubernetes，这个过程都大致相同。最让我感到惊讶的是，尽管我经常声称 Fargate “更容易”，但我真的没有看到任何超过 Kubernetes 平台的好处。现在，如果你正在构建 Kubernetes 集群，我绝对可以看到这里的价值 —— 管理节点和控制面板只是不必要的开销。问题是 —— 基于 Kubernetes 的平台的大多数消费者都*没有*这样做。如果你很幸运能够使用 GKE，你几乎不需要考虑集群的管理，你可以使用单个 gcloud 命令来运行集群。我经常使用 Digital Ocean 的 Kubernetes 治理服务，我可以肯定地说它就像操作 Fargate 集群一样简单 —— 实际上在某种程度上它更容易。
|
||||
经过一夜的反思，我意识到无论你是使用 Fargate 还是 Kubernetes，这个过程都大致相同。最让我感到惊讶的是，尽管我经常听说 Fargate “更容易”，但我真的没有看到任何超过 Kubernetes 平台的好处。现在，如果你正在构建 Kubernetes 集群，我绝对可以看到这里的价值 —— 管理节点和控制面板只是不必要的开销，问题是 —— 基于 Kubernetes 的平台的大多数消费者都*没有*这样做。如果你很幸运能够使用 GKE，你几乎不需要考虑集群的管理，你可以使用单个 `gcloud` 命令来运行集群。我经常使用 Digital Ocean 的 Kubernetes 托管服务，我可以肯定地说它就像操作 Fargate 集群一样简单，实际上在某种程度上它更容易。
|
||||
|
||||
必须定义一些基础设施来运行你的容器就是此时的代价。谷歌本周可能刚刚使用他们的 [Google Cloud Run][15] 产品改变了游戏规则，但他们在这一领域的领先优势远远领先于其他所有人。
|
||||
|
||||
@ -400,19 +396,19 @@ module "container_definition_app" {
|
||||
|
||||
#### 公平比较
|
||||
|
||||
令我印象深刻的另一个现实是，技术 A 和技术 B 之间的比较通常不太公平，我经常在 AWS 上看到这一点。这种实际情况往往与 Jeff Barr 博客文章截然不同。如果你是一家足够小的公司，你可以使用 AWS 控制台在 AWS 中部署你的应用程序并接受所有默认值，这绝对更容易。但是，我不想使用默认值，因为默认值几乎是不适用于生产环境的。一旦你开始剥离掉云服务商服务的层面，你就会开始意识到最终你仍然是在运行软件。它仍然需要设计良好、部署良好、运行良好。我相信 AWS 和 Kubernetes 以及所有其他云服务商的增值服务使得它更容易运行、设计和操作，但它绝对不是免费的。
|
||||
令我印象深刻的另一个现实是，技术 A 和技术 B 之间的比较通常不太公平，我经常在 AWS 上看到这一点。这种实际情况往往与 Jeff Barr 博客文章截然不同。如果你是一家足够小的公司，你可以使用 AWS 控制台在 AWS 中部署你的应用程序并接受所有默认值，这绝对更容易。但是，我不想使用默认值，因为默认值几乎是不适用于生产环境的。一旦你开始剥离掉云服务商服务的层面，你就会开始意识到最终你仍然是在运行软件 —— 它仍然需要设计良好、部署良好、运行良好。我相信 AWS 和 Kubernetes 以及所有其他云服务商的增值服务使得它更容易运行、设计和操作，但它绝对不是免费的。
|
||||
|
||||
#### Kubernetes 的争议
|
||||
|
||||
最后就是：如果你将 Kubernetes 纯粹视为一个容器编排工具，你可能会喜欢 Fargate。然而，随着我对 Kubernetes 越来越熟悉，我开始意识到它作为一种技术的重要性 - 不仅因为它是一个伟大的容器编排工具，而且因为它的设计模式 - 它是声明性的、API 驱动的平台。 在*整个* Fargate 过程期间发生的一个简单的事情是，如果我删除这里某个东西，Fargate 不一定会为我重新创建它。自动缩放很不错，不需要管理服务器和操作系统的补丁及更新很棒，但我觉得因为无法使用 Kubernetes 自我修复和 API 驱动模型而失去了很多。当然，Kubernetes 有一个学习曲线 - 但从这里的体验来看，Fargate 也是如此。
|
||||
最后就是：如果你将 Kubernetes 纯粹视为一个容器编排工具，你可能会喜欢 Fargate。然而，随着我对 Kubernetes 越来越熟悉，我开始意识到它作为一种技术的重要性 —— 不仅因为它是一个伟大的容器编排工具，而且因为它的设计模式 —— 它是声明性的、API 驱动的平台。 在*整个* Fargate 过程期间发生的一个简单的事情是，如果我删除这里某个东西，Fargate 不一定会为我重新创建它。自动缩放很不错，不需要管理服务器和操作系统的补丁及更新也很棒，但我辉觉得因为无法使用 Kubernetes 自我修复和 API 驱动模型而失去了很多。当然，Kubernetes 有一个学习曲线，但从这里的体验来看，Fargate 也是如此。
|
||||
|
||||
### 总结
|
||||
|
||||
尽管我在这个过程中遭遇了困惑，但我确实很喜欢这种体验。我仍然相信 Fargate 是一项出色的技术，AWS 团队对 ECS/Fargate 所做的工作确实非常出色。然而，我的观点是，这绝对不比 Kubernetes “更容易”，只是……难点不同。
|
||||
|
||||
在生产环境中运行容器时出现的问题大致相同。如果你从这篇文章中有所收获，它应该是这样的：*不管你选择的哪种方式都有运维开销*。不要相信你选择一些东西你的世界就变得更轻松。我个人的意见是：如果你有一个运维团队，而你的公司将为多个应用程序团队部署容器 —— 选择一种技术并围绕它构建流程和工具以使其更容易。
|
||||
在生产环境中运行容器时出现的问题大致相同。如果你从这篇文章中有所收获，它应该是这样的：*不管你选择的哪种方式都有运维开销*。不要相信你选择一些东西你的世界就变得更轻松。我个人的意见是：如果你有一个运维团队，而你的公司要为多个应用程序团队部署容器 —— 选择一种技术并围绕它构建流程和工具以使其更容易。
|
||||
|
||||
人们说的一点肯定是没错，某种技术肯定比现在更容易一些。在这个阶段，谈到 Fargate，下面的漫画这总结了我的感受：
|
||||
人们说的一点肯定没错，用点技巧可以更容易地使用某种技术。在这个阶段，谈到 Fargate，下面的漫画这总结了我的感受：
|
||||
|
||||
![][16]
|
||||
|
||||
@ -422,8 +418,8 @@ via: https://leebriggs.co.uk/blog/2019/04/13/the-fargate-illusion.html
|
||||
|
||||
作者：[Lee Briggs][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[Bestony](https://github.com/Bestony)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user