服务器端Swift：制作机盖（3/6）

上周，我谈到了如何选择Perfect作为Canopy服务器的基础。 本周，我将讨论云提供商，Linux上的Swift，开发过程和部署。

什么是天篷？

现在输入swift run将运行您的服务器。 我建议您使用Xcode，但是要执行这种类型的swift package generate-xcodeproj ，您将获得一个Xcode项目，该项目将在您R时运行您的服务器。

在开发过程中，您需要在Mac上运行服务器应用程序的本地实例，并使您的应用程序与此相对应。 这大大减少了调试周期。 就像我在本系列的第1部分中所说的那样，如果您有一个用于客户端和服务器的项目，则可以共享代码并降低Rev-lock的严重性。

但是，您不可避免地要部署这些开发版本，并且使用rsync很容易：

该脚本将源与服务器同步，构建应用程序，然后要求systemd重新启动它。 在脚本中，我使用了foo ，在其中您可以将foo更改为.ssh/config服务器的名称。

下周我将讨论systemd和其他生产问题。

值得注意的是，使用最便宜的实例编译代码将花费很多时间。 也许有足够的理由升级您的实例，或者直接进入本地交叉编译，接下来我将讨论这些选项。

在某个时候，您将决定现在的时间：上线的时间！ 生产似乎很可怕，但实际上您只需要做好准备。 此时，您需要进行大量练习，并且您会非常了解自己的应用及其代码，因此对自己有信心。

首先为您的用户配置密码，以便sudo要求输入密码（默认情况下， sudo AWS实例不提供密码）

您应该在本地或Docker Ubuntu实例上设置交叉编译，以便可以在本地构建应用程序，然后将其scp到您的服务器。 现在，您可以删除服务器上的Swift，并将远程软件包安装减少到最低限度。 Swift二进制文件需要一些内容，尤其是libicu和libcurl才能保留。

我发现由于SwiftPM团队做出了许多奇怪的决定，导致交叉编译不起作用：特别是#if os(Linux)在Package清单中不起作用，事实证明我的依赖关系图充满了此类声明。 我理解为什么有这些陈述： 这是一种语言功能 。 我不明白为什么苹果公司决定在Package.swift文件中不支持此语言功能 。 相反，他们打算强迫用户指定平台作为清单声明的一部分。 海事组织，这可能会使每个地方平台规范（即DSL每个子部分的每个子部分）肿，这将需要数年（基于当前进展），这意味着该功能将无法使用（因此强制#if os因为还没有其他选择）。 毕竟，＃if os仍然更加灵活。 SwiftPM团队为什么要与这种语言作斗争 ？ 你告诉我。

总而言之，我别无选择，只能使用Docker实例来构建我的Linux二进制文件，因为SwiftPM无法交叉编译我的依赖图。 幸运的是，Docker可以正常工作。

您可以使用简单的脚本在本地进行构建，使用scp二进制文件并调用systemctl restart foo来重新启动服务器应用程序。

请注意，指定--static-swift-stdlib进行swift build否则生成的二进制文件在未安装Swift的情况下将无法工作（严格来说，如果没有LD_PATH中的libswift.so和libFoundation.so ，它将无法工作）。 另外，不要忘记使用发行版优化（ -c release ）来构建它！

使用AWS升级，您的实例变得微不足道。 （大多数）实例的存储未连接到计算机，因此您将其关闭（点击复选框），等待其完成，更改实例类型，然后再次启动。 第一次有点吓人，但实际上它很轻松，并且ssh foo仍然可以正常工作。

一旦上线，我建议您使用更高的级别，但是由于Swift具有较高的性能（相对而言），因此您可以坚持使用T3 IMO，至少对于初学者而言。

我对此无话可说，因为Canopy尚未达到其实例上的CPU最大化的水平，如果发生这种情况，我还有几层可以升级。 但这是要考虑的事情，但是，要使一个可以在云中的多台机器上运行的系统比我在这里所说的要重要得多。 这绝不是一件小事，而正如斯威夫特生态系统所代表的那样，我对此一无所知。 所以：被警告！

第四部分。