因为我是 AWS 新手，所以我遇到了弹性 beantalk 的问题。我设置了一切并部署了第一个应用程序，到目前为止一切顺利。但是当我推送另一组更改时，它只是替换了整个文件，而不仅仅是更改了文件。在开发过程中，localhost 和 server 有不同的配置，所以会有不同的文件，但是在这种情况下，你在本地拥有的是在服务器中，这有点奇怪。
你能建议怎么做吗？
【问题讨论】：
标签： git deployment amazon-elastic-beanstalk
如果我理解正确，你问的是两个问题：
能否只推送更改的文件？ 根据我的理解，我认为你不能。整个源包被上传并且可以被推送到相同或不同的服务器。每次部署时，它本质上都是一个全新的环境（取决于策略，即蓝绿）。
本地与生产配置文件： 为了使用不同的文件，您要么只需要在源包中提供它们，要么在部署过程中通过将脚本添加到 .ebextensions 中的 .config 文件来更改它们。看看customizing elastic beanstalk containers
【讨论】：
我不知道从什么时候开始，但现在您可以使用 AWS 中的 Git 部署来推送已更改的文件。
问：我的应用程序更新速度有多快？
将新应用版本部署到现有资源（例如环境）的速度要快得多（通常不到一分钟），并且主要取决于新应用版本的大小。使用 Git 部署，只有修改后的文件会传输到 AWS Elastic Beanstalk，更新通常需要几秒钟。
【讨论】：
我认为参考意味着只有更改的文件会为新的捆绑包创建上传，但对于每个创建的新捆绑包，捆绑包中仍然包含所有服务器应用程序。我认为您可能会将推送的应用程序与源包混淆。
这是我用来设置我的部署过程的一个很好的来源。 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（弹性 beantalk）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 部署工作原理的理解。希望这有助于澄清。
【讨论】：