Использование отдельных файлов Dockerrun.aws.json для развертывания отдельных веток с Travis CI

Question

Поэтому я пытаюсь настроить простое приложение Multicontainer Elastic Beanstalk, которое автоматически развертывается через Travis CI.

Кроме того, у меня есть две среды, настроенные на Elastic Beanstalk, производственная среда и промежуточная среда, иУ меня есть настройки файла .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 сборки Iвызовите 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 в подкаталоге production или stage (поэтому у меня есть один файл в «.build / production / Dockerrun.aws.json», а другой - в «.build»./staging/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, а рабочий файл Dockerrun ищет изображения, помеченные с помощью production.latest

Кажется простым enough.

Очевидный следующий шаг - переместить файл Dockerrun в корневой каталог, в зависимости от того, в какую ветвь отправляется ветка, чтобы, когда Elastic Beanstalk получил код, он знал, что делать.

Это единственная цель второго скрипта bash из команды before_deploy: .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

В идеале, я ожидал бы, что это будет делать именно то, что я хочу, и работать без проблем.Проблема в том, что независимо от того, что я пытаюсь, я всегда получаю одну и ту же ошибку в журналах Elastic Beanstalk:

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

Это означает, что в основном код, который передается в Elastic Beanstalk, не имеет изменений, которые я сделалв .build / environment_initializer.sh, который отстой, потому что из того, что я понимаю, использование skip_cleanup внутри команды deploy должно помешать Трэвису отменить изменения, которые вы внесли в код.

Я в растерянности из-за того, что попробовать дальше, до сих пор я пробовал около тысячи различных мелких изменений в приведенном выше коде, в том числе:

1. Добавление 'gitstash -all 'в конце файла environment_initializer.sh.
2. Около ста вариантов' mv ./.build/production/Dockerrun.aws.json ./'
3. Использованиеcp вместо mv.

Но независимо от того, что я делаю, кажется, ничего не работает.Так что теперь я оставляю это в ваших руках.Любая помощь будет высоко ценится!

Answer 1

Оказывается, проблема была в том, как Трэвис передает код команде deploy.Очевидно, Трэвис использует git для передачи результатов этапа сборки на этап развертывания.Обычно Travis очищает все изменения кода, сделанные во время сборки, запустив git stash --all.

Установка skip_cleanup: true в разделе развертывания .travis.yml делает остановкой Travis отменить все изменения (пропуская команду git stash), поскольку код все еще проходит через gitпо умолчанию все неотмеченные файлы не будут переданы для развертывания.

Учитывая это, решение было простым:

Добавить 'git add.'после перемещения файла в корневой каталог, вот так:

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