由于我是 AWS 新手，因此我遇到了弹性豆茎的问题。我设置了一切并部署了第一个应用程序，到目前为止一切顺利。但是当我推送另一组更改时，它只是替换了整个文件，而不仅仅是更改了文件。在开发过程中 localhost 和 server 有不同的配置，因此会有不同的文件，但是在这种情况下，您在本地拥有的是在服务器中，这有点奇怪。
你能建议做什么吗？
问问题
1836 次
3 回答
5
如果我理解正确，您会问两个问题：
你可以只推送更改的文件吗？根据我的理解，我认为你不能。整个源包被上传，可以推送到相同或不同的服务器。每次部署它本质上都是一个全新的环境（取决于策略，即蓝绿）。
本地与生产配置文件：为了使用不同的文件，您要么只需要在源包中提供它们，要么在部署过程中通过将脚本添加到 .ebextensions 中的 .config 文件来更改它们。看看定制弹性豆茎容器
于 2013-08-14T20:08:51.833 回答
1
我不知道从什么时候开始，但现在您可以通过在 AWS 中使用 Git 部署来推送已更改的文件。
问：我的应用程序更新速度有多快？
将新应用程序版本部署到现有资源（例如环境）的速度要快得多（通常不到一分钟），并且主要取决于新应用程序版本的大小。使用 Git 部署，只有修改后的文件会传输到 AWS Elastic Beanstalk，更新通常需要几秒钟。
于 2016-06-09T18:26:27.683 回答
0
我认为参考意味着只有更改的文件会为新的捆绑包创建上传，但对于每个创建的新捆绑包，捆绑包中仍然包含所有服务器应用程序。我认为您可能会将推送的应用程序与源包混淆。
这是我用来设置我的部署过程的一个很好的来源。http://www.deplication.net/2013/11/java-war-deployment-options-on-aws.html
基本上，在弹性 beantalk 中，您拥有具有环境的应用程序。环境运行任何不同类型的代码服务器的 ec2 服务器实例（如果选择，则可扩展），无论是 java、.net 等。您的环境部署并运行与源包绑定的称为应用程序版本的东西。
应用程序版本仅适用于该应用程序的任何环境，但如果环境与该版本中的应用程序类型不同，则将无法工作。application1 的应用程序版本不适用于名为 application2 的应用程序。对于任何源包，您可能有多个应用程序版本。因此，您可以拥有 application2 的应用程序版本，它指向用于 application1 中的应用程序版本的源包。
提到的这个源包可以是您的单个应用程序。在 java 中，您可以拥有 .war 应用程序。您可以上传单个 .war 文件。这将在您的根目录或索引处运行，并且不需要应用程序名称。
在多应用程序部署的情况下，您将上传一个包含 .war 文件的 zip（每个包不能大于 512 mbs）。如果 .war 被称为 test.war，您将通过提供带有测试的 ebs（弹性豆茎）url 来访问此 java 服务。例如 ebsurl/测试。要拥有一个索引 .war 文件，您可以将其命名为 ROOT.war。您上传的这个 zip 文件或单个 .war 文件称为源包
有 3 种方法可以推送您的文件以进行部署。通过 ebs gui 上传，使用 git 作为您的提及，或将 app/zip 上传到 s3 - 创建源包 - 然后将该源包部署到 ebs 中的环境。我提供的链接中的指南显示了如何使用 java 执行此操作。
值得一提的是，我相信所有的源包都存储在与 ebs 应用程序绑定的 s3 存储桶中。这意味着当您将 zip 上传到 ebs、s3 或通过 git 推送时，它会保存在 s3 中。
每个源包或应用程序都可以有一个从中创建的应用程序版本。这些是部署到 ec2 实例的内容。您可以通过命令行、使用 git 或上传到 ebs 来实现这些，这些都是随每个源包自动创建的。
在 git 的情况下，您添加更改，推送更改，然后它可能会生成一个包含所有更改的新源包，推送的内容可能只是更改，但整个包是新的。然后它可以部署从创建的源包生成的应用程序版本。现在我不知道是所有应用程序都被重新部署还是只有那些被更改。就像说您更新了 ROOT.war 并使用相同的 test.war 创建了一个新的 zip 并上传或 git push 。它会重新部署两者还是只重新部署 ROOT.war。在可扩展的环境中，它必须将这些更改推广到所有存在的 ec2 实例。
这是我对高级别 ebs 部署如何工作的理解。希望这有助于澄清。
于 2017-11-03T21:09:01.243 回答