1. yamotuki

    No comment

    yamotuki
Changes in body
Source | HTML | Preview
@@ -1,73 +1,131 @@
### 概要
CircleCI Workflow ではテストを通した後に待たせておいて、任意のタイミングでワンクリックでデプロイするという方法をとることができます。
-この記事では特に、AWS ElasticBeanstalk の複数の環境に同じバージョンのアプリケーションをデプロイする方法について書きます。
-具体的用途としては、WebアプリケーションとWorker環境の両方に同じコードをデプロイしておきたいというような形を想定しています。
+この記事では特に、AWS ElasticBeanstalk の複数の環境に同じバージョンのアプリケーションをデプロイする方法について書きます。ElasticBeanstalk以外でもworkflowの流れと、ジョブ間での情報の受け渡しの方法は同じなので応用できるかと思います。
+
+具体的用途としては、以下のものを想定しています
+
+* WebアプリケーションとWorker環境の両方に同じコードを勝手にデプロイして欲しい
+* Dev環境と本番環境の両方にワンクリックで同じコードをデプロイしたい
### 完成イメージ
こちらはCircleCI Workflow 実行時の画面イメージです。
+
+dev の二つの環境にデプロイする場合には以下のような見た目になります。
![貼り付けた画像_2019_11_22_12_26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/144064/c115a12e-1ea1-769a-c1c2-e4fcaf50910b.png)
テストが通った状態で止まっており、 require-testsのところがクリック可能になって、クリックするとデプロイが始まります(テスト終わった直後は一回リロードしないとクリック可能にならないのでそこだけ注意)
+
+さらに本番へのデプロイを足した場合には以下のようになります。
+![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/144064/d9f02a3f-39f5-ce3f-7eba-13e626d16442.png)
+
+同様に require-dev-deploy が足されており、それをクリックすることで本番デプロイに進むことができます。
+
### 設定の記述方法
`.circleci/config.yml` に CircleCI Workflow の設定を書くことができます。
前提となるセットアップについては省略し、公式ドキュメントなどにお任せします。
```.circleci/config.yml
version: 2
jobs:
test-js:
- # ここは今回は省略
+ # ここは今回は詳細記述を省略
test-php:
- # ここは今回は省略
+ # ここは今回は詳細記述を省略
deploy-to-dev:
docker:
- image: circleci/python:3.6.4
working_directory: ~/repo
steps:
- checkout
+ # ここら辺は eb コマンドのセットアップ
- run:
name: Install awscli
command: |
sudo pip install --upgrade pip
sudo pip install awsebcli --upgrade
- run:
name: Create AWS credentials manually
command: |
mkdir ~/.aws
touch ~/.aws/config
chmod 600 ~/.aws/config
echo "[profile eb-cli]" > ~/.aws/config
echo "aws_access_key_id=$AWS_ACCESS_KEY_ID" >> ~/.aws/config
echo "aws_secret_access_key=$AWS_SECRET_ACCESS_KEY" >> ~/.aws/config
- run:
name: Deploying to dev app 1
- command: eb deploy my-appliation-1 > /tmp/eb_deploy_output
+ command: eb deploy my-dev-appliation-1 > /tmp/eb_deploy_output
- run:
name: Deploying to dev app 2
# こういう感じのアウトプットを期待してダブルクオートの中を取り出しています。 => Creating application version archive "app-2019-11-18-2-57-gd83f8-6547657_104221".
- command: eb deploy my-application-2 --label `cat /tmp/eb_deploy_output | grep "version archive" | sed -E 's/.*\"(.*)\".*/\1/'`
+ command: eb deploy my-dev-application-2 --label `cat /tmp/eb_deploy_output | grep "version archive" | sed -E 's/.*\"(.*)\".*/\1/'`
+ # ジョブ間で情報を共有するためにここが重要で、workspaceに永続化(30日)をします
+ - persist_to_workspace:
+ root: /tmp/
+ paths:
+ - app_version_label
+
+ deploy-to-production:
+ docker:
+ - image: circleci/python:3.6.4
+
+ working_directory: ~/repo
+
+ steps:
+ - checkout
+ # workspaceに入っているものを取り出します
+ - attach_workspace:
+ at: /tmp/
+ - run:
+ # devと同じなので省略
+ - run:
+ name: Deploying to production webapp
+ command: |
+ APP_VERSION_LABEL=`cat /tmp/app_version_label`
+ echo $APP_VERSION_LABEL
+ eb deploy my-production-app-1 --label $APP_VERSION_LABEL
+
workflows:
version: 2
build-and-test-approval-deploy:
jobs:
- test-js
- test-php:
requires:
- test-js
# 前提としてtestが通っていて、許可したらデプロイするというのをするなら type: approval を使う。
- require-tests:
type: approval
requires:
- test-php
- deploy-to-dev:
requires:
- require-tests
+ - require-dev-deploy:
+ type: approval
+ requires:
+ - deploy-to-dev
+ - deploy-to-production:
+ requires:
+ - require-dev-deploy
```
+
+# 補足
+### ebコマンドの `--label` でのバージョン指定について
+
`--label` を**指定せずに** eb deploy を複数回実行することもできるかと思いますが、それだと環境が増えるとElasticbeanstalkの管理コンソール上でみれるアプリケーションバージョンが複数発行されてしまい、邪魔になってしまいます。
`--label` で以前のバージョンを指定すればその問題が起こりません。1回目の eb deploy のアウトプットを取得して整形し、2回目のeb deployコマンドの`--label`オプションの引数に渡しています。
+### ジョブ間での情報受け渡し方法について
+
+永続化ではなくてジョブ間でのファイル受け渡しに persist_to_workspace(ファイルをworkspaceに30日保存) と attach_workspace(指定のパスに対してworkspaceにあったらアタッチする) のワンセットを使えることがわかった。
+
+参考ドキュメント:
+https://circleci.com/blog/build-cicd-piplines-using-docker/
+https://circleci.com/docs/ja/2.0/configuration-reference/#persist_to_workspace
+
+`$BASH_ENV` に保存すれば良いという情報もあったが、`$BASH_ENV`に保存されるファイルパスがジョブによって変わってしまって使えなかった。