部署脚本_部署脚本与Rultor

部署脚本

当我解释Rultor如何自动执行部署/发布过程时，经常会听到类似以下内容：

但是我已经有了一个脚本，可以自动部署所有内容。

这种响应非常普遍，因此我决定在一篇文章中总结有关自动化Rultor部署/发布过程的三个主要论点：

1. 孤立的docker容器，
2. 日志的可见性和
3. 凭证的安全性。

阅读有关它们的信息，并在现有的部署脚本之上查看Rultor为您提供的服务。

查理和巧克力工厂（2005），蒂姆·伯顿（Tim Burton）

在讨论参数之前，让我强调一下，Rultor是自定义脚本的有用接口。 当您决定使用Rultor自动化部署时，不会丢弃任何现有脚本。 您只需教Rultor如何称呼它们。

隔离的Docker容器

一旦开始从Rultor调用部署脚本，您将获得的第一个优势是Docker的使用 。 我确定您知道Docker是什么，但对于不了解Docker的人-它是虚拟Linux“机器”的管理器。 当您需要在新的虚拟机（也称为“容器”）中运行某些脚本时，可以调用该命令行脚本。 Docker几乎立即启动容器并运行您的脚本。 Docker的优点在于，每个容器都是一个完全隔离的Linux环境，具有自己的文件系统，内存，进程等。

当您告诉Rultor运行部署脚本时，它将启动一个新的Docker容器并在其中运行您的脚本。 但是，您问这给我带来什么好处？

主要好处是在脚本完成后立即将容器销毁。 这意味着您可以在容器内进行所有预配置，而不必担心与您的主要工作平台发生冲突。 让我举个例子。

我在MacBook上进行开发，在那儿我安装和删除了开发所需的软件包。 同时，我有一个项目，要进行部署，需要PHP 5.3，MySQL 5.6，phing，phpunit，phpcs和xdebug。 每个MacOS版本都需要专门配置才能启动和运行这些应用程序，这是一项耗时的工作。

我可以更改笔记本电脑，也可以更改MacOS版本，但项目保持不变。 为了成功运行其部署脚本，它仍然需要相同的软件包集。 而且该项目不再处于积极开发中。 因为我现在更多地使用Java，所以我日常工作中根本不需要这些软件包。 但是，当我需要对该PHP项目进行较小的修复并部署它时，我必须安装所有必需PHP软件包并进行配置。 只有在那之后，我才能部署该次要修补程序。

至少可以说这很烦人。

Docker使我能够将所有这些自动化在一起。 我现有的部署脚本将获得一个序言，它将在一个干净的Ubuntu容器中安装和配置所有与PHP相关的必需软件包。 该序言将在 Docker容器内的每次部署脚本运行时执行。 例如，它可能看起来像这样：

在开始使用Rultor之前，我的部署脚本如下所示：

#!/bin/bash
phing test
git ftp push --user ".." --passwd ".." --syncroot php/src ftp://ftp.example.com/

只需两行。 第一个是完整的单元测试。 第二个是到生产服务器的FTP部署。 很简单。 但是，仅当安装了PHP 5.3，MySQL，phing，xdebug，phpcs和phpunit时，此脚本才有效。 同样，每次升级MacOS或更换笔记本电脑时，都要进行大量安装和配置。

不用说，如果/当有人加入项目并尝试运行我的脚本时，他/她将不得不再次执行此预安装工作。

因此，这是一个我现在正在使用的新脚本。 每次在新的Docker容器中执行该命令：

#!/bin/bash
# First, we install all prerequisites
sudo apt-get install -y php5 php5-mysql mysql
sudo apt-get install php-pear
sudo pear channel-discover pear.phpunit.de
sudo pear install phpunit/PHPUnit
sudo pear install PHP_CodeSniffer
sudo pecl install xdebug
sudo pear channel-discover pear.phing.info
sudo pear install phing/phing
# And now the same script I had before
phing test
git ftp push --user ".." --passwd ".." --syncroot php/src ftp://ftp.example.com/

显然，在我的MacBook上运行此脚本（不进行虚拟化）会造成很多麻烦。 好了，我甚至不具有apt-get这里！

因此，Rultor给您带来的第一个好处就是在您自己的虚拟环境中隔离了部署脚本。 这主要归功于Docker。

日志的可见性

传统上，我们将部署脚本保存在~/deploy目录中，并使用一组神奇的参数运行它们。 在一个小型项目中，您可以自己执行此操作，并且此目录位于您自己的笔记本电脑上。 在更大的项目中，有一个“部署”服务器，该服务器具有该魔术目录，该目录带有一组脚本，这些脚本只能由少数几个受信任的高级开发人员执行。 我已经看过很多次了。

这里最大的问题是可追溯性。 几乎不可能找出谁部署了什么以及为什么某些部署失败了。 高级部署专家只需将SSH SSH到服务器，然后使用魔术参数运行那些魔术脚本。 日志通常会丢失，问题跟踪非常困难或不可能。

Rultor提供了一些不同的东西。 使用Rultor，不再可以通过SSH访问部署脚本。 所有脚本都保留在.rultor.yml配置文件中，并通过在问题跟踪系统（例如Github，JIRA或Trac）中发布消息来启动它们。 Rultor运行脚本并将其完整日志发布到您的票证中。 日志永远与您的项目在一起。 您始终可以返回到正在使用的故障单，并检查为什么部署失败以及实际执行了哪些指令。

例如，检查这个Github问题，我在那里部署了新版本的Rultor本身，但失败了几次： yegor256 / rultor＃563 。 我所有失败的尝试均已达成协议。 我可以随时与他们联系并进行调查。 对于大型项目，此信息至关重要。

因此，与独立部署脚本相比，Rultor的第二个好处是每个操作的可见性。

凭证安全

当您的笔记本电脑或该秘密团队部署服务器中有一个自定义脚本时，您的生产凭据就在它附近。 别无选择。 如果您的软件与数据库一起使用，则它必须知道登录凭据（用户名，密码，数据库名称，端口号等）。 好吧，在最坏的情况下，有些人只是将信息硬编码到源代码中。 我们甚至都不会讨论这种情况，那就很糟糕。

但是，假设您将数据库凭据与源代码分开。 您将拥有db.properties或db.ini文件之类的文件，这些文件将在部署之前附加到应用程序。 您还可以将该文件直接保存在生产服务器中，这虽然更好，但并非总是可能的，特别是在PaaS部署中。

将工件部署到存储库中也存在类似的问题。 假设您定期部署到RubyGems.org。 您的~/.gem/credentials将包含您的秘密API密钥。

因此，在很多情况下，部署脚本会附带一些带有敏感和安全信息的文件。 这些文件以简单，开放的格式包含此信息。 没有加密，没有保护。 纯文本形式的用户名，密码，代码和令牌。

为什么这样不好？ 好吧，对于拥有一台笔记本电脑的单个开发人员来说，这听起来似乎不是问题。 虽然，我不喜欢在机场某处丢失所有凭证并准备使用的笔记本电脑的想法。 您可能会说，有光盘保护工具，例如MacOS的FileVault或Windows的BestCrypt。 也许吧。

但是，让我们看看当我们有一个开发人员团队，一起工作并使用凭据共享这些部署脚本和文件时会发生什么。 在将部署脚本的访问权限授予团队的新成员后，您必须共享所有这些敏感数据。 只是没有办法。 为了使用脚本，他/她必须能够使用凭据打开文件。

如果您关心数据的安全性，那么这就是一个问题。

Rultor通过在部署脚本使用敏感数据之前对其提供动态GPG解密来解决此问题。 在.rultor.yml配置文件中，您只需说：

decrypt:
  db.ini: "repo/db.ini.asc"
deploy:
  script:
    ftp put db.ini production

然后，你加密你的db.ini使用Rultor GPG密钥，并提交无畏db.ini.asc到存储库。 在运行部署脚本之前，除了Rultor服务器本身之外，没有人能够打开和读取该文件。

因此，与独立部署脚本相比，Rultor的第三个好处是敏感数据的适当安全性。

相关文章

您可能还会发现以下有趣的帖子：

• 一键式发布到Rubygems的方法
• 一键式部署到CloudBees
• 一键发布到Maven Central的方法
• 鲁托尔+特拉维斯
• 每个构建都在自己的Docker容器中

翻译自: https://www.javacodegeeks.com/2014/09/deployment-script-vs-rultor.html

部署脚本