使用单独的Dockerrun.aws.json文件进行不同的分支部署

Question

因此，我试图设置一个简单的多容器弹性Bean秸秆应用程序，它通过Travis CI自动部署。

此外，我在ElasticBean秸秆上设置了两个环境，一个是生产环境，另一个是分阶段环境，我的.travis.yml文件设置可以部署到主平台上的生产环境中，并在舞台分支上部署，如下所示：

sudo: required
services:
  - docker
before_install: docker build -t web:ci -f web/Dockerfile.dev web
script: docker run web:ci npm run test -- --coverage
before_deploy:
  - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_ID" --password-stdin
  - bash .build/image_maker.sh
  - bash .build/environment_initializer.sh
deployments:
  elasticbeanstalkdeploy: &elastic_beanstalk_deploy
    skip_cleanup: true
    provider: elasticbeanstalk
    app: "MySuperCoolApp"
    region: "us-east-2"
    bucket_name: "elasticbeanstalk-us-east-2-012345678910"
    bucket_path: "MySuperCoolApp"
    access_key_id: $ELASTIC_BEANSTALK_ACCESS_KEY
    secret_access_key:
      secure: $ELASTIC_BEANSTALK_SECRET_KEY
deploy:
  - <<: *elastic_beanstalk_deploy
    env: "MySuperCoolApp-ProductionEnv"
    on:
      branch: master
  - <<: *elastic_beanstalk_deploy
    env: "MySuperCoolApp-StagingEnv"
    on:
      branch: stage

您会注意到在构建的'before_deploy‘阶段，我在两个单独的文件上调用bash。

第一个是image_maker.sh，它负责构建EB应用程序所需的所有映像，并将它们推送到Docker。

我不会向您展示来自image_maker.sh文件的任何代码，因为我确信它是工作的，并且与问题无关，但是您应该知道，它是基于当前被推送到的分支来标记图像的。

当被推到主台时，每个图像都将被标记为production.latest (例如: image_name:production.latest)，当被推到舞台分支时，每个图像都将被标记为staging.latest (例如:image_name:staging.latest)。

这一点很重要，因为它解释了为什么我要尝试下一步(这就是我正在努力解决的问题)。

基本上，我有两个Dockerrun.aws.json文件，每个文件存储在生产或暂存子目录下的.build目录中(因此，我有一个文件位于‘..build/ production /Dockerrun.aws.json’，另一个文件存储在‘..build/暂存/Dockerrun.aws.json’)。

下面是基本的文件结构：

root
  .travis.yml
  .build
    image_maker.sh
    environment_initializer.sh
    production
      - Dockerrun.aws.json
    staging 
      - Dockerrun.aws.json

每个Dockerrun.aws.json文件之间唯一的区别是它们在容器定义中使用哪个图像标记，临时Dockerrun文件查找带有staging.latest标记的图像，而production文件查找带有production.latest标记的图像

看起来很简单。

显而易见的下一步是将Dockerrun文件移动到根目录，根据这个根目录将分支推送到哪个分支，这样当ElasticBean秸秆接收到代码时，它就知道该做什么了。

这是“before_deploy”命令中第二个bash脚本的唯一用途：. .build/environment_initializer.sh。

以下是代码：

#!/bin/bash

if [[ "$TRAVIS_PULL_REQUEST" = false ]]; then

  if [ "$TRAVIS_BRANCH" = 'master' ]; then
    echo Moving production Dockerrun.aws.json to root
    mv ./.build/production/Dockerrun.aws.json ./
  fi

  if [ "$TRAVIS_BRANCH" = 'stage' ]; then
    echo Moving staging Dockerrun.aws.json to root
    mv ./.build/staging/Dockerrun.aws.json ./
  fi

fi

理想情况下，我希望这样做完全符合我的意愿，并且无缝地工作。问题是，不管我做了什么，我在弹性豆杆日志上总是会得到相同的错误：

No ecs task definition (or empty definition file) found in environment

这基本上意味着传递给ElasticBean秸秆的代码没有我在. .build/environment_initializer.sh中所做的更改，这很糟糕，因为据我所理解，在deploy命令中使用skip_cleanup可以阻止Travis取消您对代码所做的更改。

我不知道下一步该做什么，到目前为止，我已经尝试了对上面的代码进行大约一千种不同的小调整，包括：

1. 在-all文件的末尾添加一个'git存储environment_initializer.sh‘。
2. “mv./..build/production/Dockerrun.aws.json./”中大约有100个变体。
3. 用cp代替mv。

但不管我做什么，似乎都没有用。所以现在，我把它交给你了。任何帮助都将不胜感激！

Answer 1

问题在于Travis如何将代码传递给deploy命令。显然，Travis使用git将构建阶段的结果传递给部署阶段。通常情况下，Travis将通过运行“git stash - all”来清除在构建过程中所做的所有代码更改。

设置skip_cleanup:在.travis.yml deploy部分中确实会阻止Travis取消所有更改(跳过git存储命令)，但是，由于代码仍在通过git传递，默认情况下所有未执行的文件都不会传递到部署。

考虑到这一点，解决办法很简单：

加上“git加。”将文件移动到根目录后，如下所示：

if [[ "$TRAVIS_PULL_REQUEST" = false ]]; then

  if [ "$TRAVIS_BRANCH" = 'master' ]; then
    echo Moving production Dockerrun.aws.json to root
    mv ./.build/production/Dockerrun.aws.json ./
    git add .
  fi

  if [ "$TRAVIS_BRANCH" = 'stage' ]; then
    echo Moving staging Dockerrun.aws.json to root
    mv ./.build/staging/Dockerrun.aws.json ./
    git add .
  fi

fi