'作曲家install`生产部署

我们已经部署到使用厨师'作曲家install`生产部署

〜200个EC2实例任务关键型应用程序

我们的供应商目录，目前GIT忽略，但我们在其他地方犯重要的依存关系到GIT，并自动加载他们。我们的计划是转移到更传统的方法，即通过Composer内的/ vendor和使用composer自动加载器来安装所有内容。

我的问题是：当我们发布/批量部署（200多个服务器同时）时，代码从GIT被拉到服务器上的新版本目录，因此我们需要执行我们的作曲家安装。是否有任何技术可以提高作曲家安装的可靠性？或者实际上没有什么可担心的。鉴于我们的服务器数量，即使1％的故障率意味着客户端中断。

我们有另一个应用程序在每个部署上触发作曲家安装，至少在24小时内我们无法部署，因为其中一个依赖关系“关闭”或移动了。有什么方法可以避免这个问题，同时还能避免将我们的依赖关系转化为我们的主要GIT？

谢谢！

来源

2016-04-02 sudoyum

是否有任何技术可以提高作曲家安装的可靠性？

有什么方法可以避免这个问题，同时还可以避免将我们的依赖项提交到我们的主要GIT中？

我的建议：

不要在生产环境中运行作曲家
构建和打包应用程序的部署
运行composer install和打水的依赖关系是构建步骤
最终产品的构建工具链是一个打包的应用程序，包括供应商依赖和自动加载 - 准备部署
然后将您的软件v1.2.3部署到x个实例

（旁注：Composer自动加载器生成可重定位文件。该路径是动态的，不受特定目录的束缚。这允许解压缩打包的应用程序，并将供应商依赖关系提取并自动加载到任何文件夹中。）

来源

2016-04-03 12:58:01

嗨，感谢您的回复！考虑到我们的部署实际上是一个使用厨师的GIT克隆，你在哪里推荐“包装生产构建”直播？在代码为“打包生产构建”状态的GIT中注册的代码库的“发布”分支是否是错误的？还是应该将代码构建并存储在别处以供我们的实例远程使用？我倾向于说这个版本应该在我们主要的GIT回购之外生存，以避免混淆/意外。任何推动这一点的建议/工具？ – sudoyum

嘿！它不会与'git clone'一起工作。 git checkout包含'composer.json'（或理想的'composer.lock'）。基于依赖关系被拉入。 - 当然，可以将它们存储回Git中，并根据“依赖包含”分支创建发布标签，但我不会建议这样做。 –

'应该将代码构建并存储在其他地方供我们的实例远程使用吗？是的，构建应该在外面。例如，你可以使用一个简单的makefile（或一个PHP构建脚本或一个基于Ant/Phing的build.xml文件）来完成一些构建任务：'composer install' +'zip' +'upload to downloads folder for releases' 。 –

我们实现了Jenkins来克隆我们的GIT，运行作曲家安装生产，执行几个shell脚本来帮助打包，而我们生成.tar.gz并将文件发布到AWS S3上的构建存储桶（基于正在构建的分支的文件名）。我们调整了我们的部署系统，以便从S3存储桶中获取（它具有非常有限的权限以保护对代码的访问）

来源

2016-06-22 15:58:26 sudoyum

'作曲家install`生产部署

回答

相关问题