デプロイの構成
CircleCI は、ほぼすべてのサービスにデプロイできるように構成できます。 以下のプラットフォームでのデプロイ方法とその例を紹介します。
概要
アプリケーションをデプロイするには、ジョブを .circleci/config.yml
ファイルに追加します。 また、環境変数と SSH キーを追加する必要があります。
以下に、Rails アプリケーションを Heroku にデプロイする場合の簡単な例を示します。 アプリケーション全体は、CircleCI デモ ワークフロー リポジトリの連続ジョブのブランチで確認できます。
version: 2
jobs:
build:
docker:
- image: circleci/ruby:2.4-node-jessie
- image: circleci/postgres:9.4.12-alpine
working_directory: ~/circleci-demo-workflows
steps:
- checkout
- run: bundle install --path vendor/bundle # 依存関係のインストール
- run: bundle exec rake db:create db:schema:load # データベースのセットアップ
- run:
name: テストの実行
command: rake
deploy:
machine:
enabled: true
working_directory: ~/circleci-demo-workflows
environment:
HEROKU_APP: "sleepy-refuge-55486"
steps:
- checkout
- run:
name: Heroku への master のデプロイ
command: |
git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP.git master
workflows:
version: 2
build-and-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: sequential-branch-filter
sequential-branch-filter
ブランチがチェック アウトされ build
ジョブが実行された場合にのみデプロイされるように、ワークフローを使用して構成されています。 デプロイ ジョブで前のジョブからの出力を使用する場合は、ワークスペースを使用することでそのデータを共有できます。 条件付きデプロイについては、「ワークフローにおけるコンテキストとフィルターの使用」を参照してください。
AWS
AWS S3 にデプロイするには、以下の手順を行います。
AWS ECR から AWS ECS にデプロイする方法については、「AWS ECR/ECS へのデプロイ」を参照してください。
-
セキュリティ上のベスト プラクティスとして、CircleCI 専用の新しい IAM ユーザーを作成します。
-
AWS アクセス キーをプロジェクト環境変数またはコンテキスト環境変数として CircleCI に追加します。 アクセス キー ID を
AWS_ACCESS_KEY_ID
という変数に、またシークレット アクセス キーをAWS_SECRET_ACCESS_KEY
という変数に格納します。 -
.circleci/config.yml
ファイルで、新しいdeploy
ジョブを作成します。deploy
ジョブで、プライマリ コンテナにawscli
をインストールするステップを追加します。 -
AWS CLI に関するドキュメントに従って、プライマリ コンテナに
awscli
をインストールします。 -
AWS CLI を使用して、アプリケーションを S3 にデプロイするか、他の AWS 操作を実行します。 以下の例は、CircleCI でこのドキュメント サイトを S3 にデプロイする方法を示しています。 ビルド ジョブが終了し、現在のブランチが
master
である場合にのみ、ワークフローを使用してデプロイしてください。
version: 2
jobs:
# 簡潔にするためにビルド ジョブは省略しています
deploy:
docker:
- image: circleci/python:3.7-stretch
working_directory: ~/circleci-docs
steps:
- run:
name: awscli のインストール
command: sudo pip install awscli
- run:
name: S3 へのデプロイ
command: aws s3 sync jekyll/_site/docs s3://circle-production-static-site/docs/ --delete
workflows:
version: 2
build-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
AWS CLI のコマンドとオプションの一覧は、「AWS CLI コマンド リファレンス」で参照できます。
AWS Orb のサンプル
CircleCI はパートナーと協力して、AWS アプリケーションを迅速にデプロイするための AWS Orb をいくつか開発しています。これらの Orb は CircleCI Orb レジストリで確認できます。 以下に AWS S3、AWS ECR、AWS ECS の各 Orb の使用方法を説明します。
AWS S3 Orb
version: 2.1
orbs:
aws-s3: circleci/aws-s3@1.0.11
jobs:
build:
docker:
- image: 'circleci/python:2.7'
steps:
- checkout
- run: mkdir bucket && echo "lorum ipsum" > bucket/build_asset.txt
- aws-s3/sync:
from: bucket
to: 's3://my-s3-bucket-name/prefix'
arguments: |
--acl public-read \
--cache-control "max-age=86400"
overwrite: true
- aws-s3/copy:
from: bucket/build_asset.txt
to: 's3://my-s3-bucket-name'
arguments: '--dryrun'
AWS S3 Orb の詳細については、CircleCI AWS S3 Orb のページを参照してください。
AWS ECR と AWS ECS の Orb のサンプル
AWS ECR
この Orb では、AWS にログインしてビルドし、イメージを Amazon ECS にプッシュできます。
orbs:
aws-ecr: circleci/aws-ecr@0.0.10
version: 2.1
workflows:
build_and_push_image:
jobs:
- aws-ecr/build_and_push_image:
account-url: AWS_ECR_ACCOUNT_URL_ENV_VAR_NAME
aws-access-key-id: ACCESS_KEY_ID_ENV_VAR_NAME
aws-secret-access-key: SECRET_ACCESS_KEY_ENV_VAR_NAME
context: myContext
create-repo: true
dockerfile: myDockerfile
path: pathToMyDockerfile
profile-name: myProfileName
region: AWS_REGION_ENV_VAR_NAME
repo: myECRRepository
tag: myECRRepoTag
AWS ECS
この Orb では、既存の AWS ECS インスタンスを更新できます。
version: 2.1
orbs:
aws-ecr: circleci/aws-ecr@0.0.4
aws-ecs: circleci/aws-ecs@0.0.3
workflows:
build-and-deploy:
jobs:
- aws-ecr/build_and_push_image:
account-url: '${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com'
repo: '${MY_APP_PREFIX}'
region: '${AWS_REGION}'
tag: '${CIRCLE_SHA1}
'
- aws-ecs/deploy-service-update:
requires:
- aws-ecr/build_and_push_image
family: '${MY_APP_PREFIX}-service'
cluster-name: '${MY_APP_PREFIX}-cluster'
container-image-name-updates: 'container=${MY_APP_PREFIX}-service,tag=${CIRCLE_SHA1}'
AWS CodeDeploy
aws-code-deploy
Orb を使用すると、AWS CodeDeploy を通じてデプロイを実行できます。
version: 2.1 # Orb を使用するには 2.1 を使用する必要があります
orbs: # 使用するすべての Orb を指定します
aws-code-deploy: circleci/aws-code-deploy@1.0.0
workflows:
deploy_application:
jobs:
- aws-code-deploy/deploy:
application-name: myApplication # 該当する IAM ユーザーまたは AWS アカウントに関連付けられた AWS CodeDeploy アプリケーションの名前
deployment-group: myDeploymentGroup # 指定されたアプリケーションの新規デプロイ グループの名前
service-role-arn: myDeploymentGroupRoleARN # デプロイ グループのサービス ロール
bundle-bucket: myApplicationS3Bucket # アプリケーションのリビジョンが格納される s3 バケット
bundle-key: myS3BucketKey # アプリケーションのリビジョンが格納される s3 バケットのキー
AWS ECS、AWS ECR、AWS CodeDeploy Orb の詳細については、Orb レジストリの各ページを参照してください。
Azure
Azure にデプロイするには、上記の例と同様のジョブで適切なコマンドを使用します。 リポジトリにプッシュする必要がある場合は、「GitHub と Bitbucket のインテグレーション」の GitHub または Bitbucket への読み取り/書き込みデプロイ キーの追加に関するセクションで手順を確認してください。 次に、production ブランチを使用するように Azure Web App を構成します。
Capistrano
version: 2
jobs:
# ビルド ジョブとテスト ジョブ
deploy-job:
docker:
- image: image pinned to a version and tag
working_directory: ~/repo
steps:
- checkout
- run:
name: バンドル インストール
command: bundle check || bundle install
- run:
name: テストが完了し、ブランチが master である場合は AWS にデプロイ
command: bundle exec cap production deploy
workflows:
version: 2
build-deploy:
jobs:
- build-job
- deploy-job:
requires:
- build-job
filters:
branches:
only: master
Cloud Foundry
Cloud Foundry へのデプロイには Cloud Foundry CLI が必要です。 アーキテクチャは必ず Docker イメージに一致させてください。以下のコマンドは、Debian ベースのイメージが使用されていることを前提としています。 この例では、Cloud Foundry の map-route/unmap-route コマンドを使用して、”Blue-Green” デプロイを実装しています。これは、基本の cf push
にはないオプションの機能です。
CLI のインストール
- run: name: CF CLI のセットアップ command: | curl -v -L -o cf-cli_amd64.deb ‘https://cli.run.pivotal.io/stable?release=debian64&source=github’ sudo dpkg -i cf-cli_amd64.deb cf -v cf api https://api.run.pivotal.io # またはプライベート Cloud Foundry デプロイをターゲットにします cf auth “$CF_USER” “$CF_PASSWORD” cf target -o “$CF_ORG” -s “$CF_SPACE”
dark デプロイ
これは Blue-Green デプロイの最初のステップで、アプリケーションを non-production ルートにプッシュします。
- run:
name: CF デプロイ
command: |
# "dark" サブドメインにアーティファクトをプッシュしますが、環境変数を付加できるように開始はしません
cf push --no-start app-name-dark -f manifest.yml -p application.jar -n dark -d example.com
# CircleCI の変数を Cloud Foundry に渡します (オプション)
cf set-env app-name-dark circle_build_num ${CIRCLE_BUILD_NUM}
cf set-env app-name-dark circle_commit ${CIRCLE_SHA1}
cf set-env app-name-dark circle_workflow_guid ${CIRCLE_WORKFLOW_ID}
cf set-env app-name-dark circle_user ${CIRCLE_PROJECT_USERNAME}
cf set-env app-name-dark circle_repo ${CIRCLE_PROJECT_REPONAME}
# アプリケーションを開始します
cf start app-name-dark
# dark ルートを dark アプリケーション専用にします
cf unmap-route app-name example.com -n dark || echo "Dark Route Already exclusive"
live デプロイ
ここまで、前にプッシュした “app-name” は変更されていません。 最後に、本番 URL を dark アプリケーションにルーティングし、それまでのバージョンへのトラフィックを停止し、アプリケーションの名前を変更します。
- run:
name: 最新の live ドメインへの再ルーティング
command: |
# "実際の" URL を新バージョンに送信します
cf map-route app-name-dark example.com -n www
# 以前のバージョンへのトラフィックを停止します
cf unmap-route app-name example.com -n www
# 以前のバージョンを停止します
cf stop app-name
# 以前のバージョンを削除します
cf delete app-name -f
# "dark" バージョンの名前を正しい名前に切り替えます
cf rename app-name-dark app-name
手動による承認
さらなるコントロールとバリデーションを行うには、以下のサンプル ワークフローに示すように、dark のステップと live のステップの間に手動の “hold” ステップを追加します。
workflows:
version: 2
build-deploy:
jobs:
- test
- dark-deploy:
requires:
- test
filters:
branches:
only: master
- hold:
type: approval
requires:
- dark-deploy
filters:
branches:
only: master
- live-deploy:
requires:
- hold
filters:
branches:
only: master
Orb のデプロイ例
CircleCI は、構成ワークフローを簡略化するために Cloud Foundry Orb を開発しました。 CircleCI Orb レジストリには、Cloud Foundry で実行できるタスクのサンプルがいくつか含まれています。この中には、単一のジョブで Cloud Foundry アプリケーションをビルドしてデプロイする方法を示した以下のサンプルも含まれています。
version: 2.1
build_and_push:
description: |
単一ジョブでアプリケーションをビルドしてデプロイします
usage:
version: 2.1
orbs:
cloudfoundry: circleci/cloudfoundry@1.0
workflows:
version: 2
build-deploy:
jobs:
- cloudfoundry/push:
appname: your-app
org: your-org
space: your-space
build_steps:
- run: # ビルド ステップ
- run: # さらに追加できます
manifest: # manifest.yml ファイルへのパス
package: # アプリケーション パッケージへのパス
構成ワークフローで使用できるさまざまな Cloud Foundry Orb のサンプルについては、CircleCI Orb レジストリの Cloud Foundry Orb のページで詳細を確認できます。
Firebase
CircleCI で firebase-tools をグローバルにインストールすることはできません。このため、firebase-tools はプロジェクトの devDependencies に追加します。
npm install --save-dev firebase-tools
以下のコマンドを使用して、Firebase CLI トークンを生成します。
firebase login:ci
生成されたトークンを CircleCI プロジェクトの環境変数に $FIREBASE_DEPLOY_TOKEN として追加します。
以下の行をプロジェクトの config.yml
ファイルに追加します。
<br /> deploy-job:
docker:
- image: my-image-version-tag
working_directory: /tmp/my-project
steps:
- run:
name: Firebase への master のデプロイ
command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_DEPLOY_TOKEN
workflows:
version: 2
-deploy:
jobs:
- build-job
- deploy-job:
requires:
- build-job
filters:
branches:
only: master
Firebase で Google Cloud Functions を使用する場合は、以下の行を config.yml
に追加し、Google Cloud Functions が保存されているフォルダー (この場合は ‘functions’) に移動して、npm インストールを実行するように CircleCI に指示します。
- run: cd functions && npm install
Firebase Orb のサンプル
Firebase の構成ワークフローを簡略化するには、必要な構成が含まれた事前構成済みパッケージ (「Orb」と呼ばれます) を使用して、アプリケーションを Firebase にデプロイします。 以下は、Firebase Orb の一例です。
version: 2.1
description: Firebase デプロイ用の Orb
commands:
deploy:
description: Firebase へのデプロイ
parameters:
token:
type: string
description: Firebase デプロイ トークン
steps:
- run:
name: Firebase ツールのインストール
command: npm install --prefix=./firebase-deploy firebase-tools
- run:
name: Firebase へのデプロイ
command: ./firebase-deploy/node_modules/.bin/firebase deploy --token=<< parameters.token >>
Firebase Orb を使用してアプリケーションをデプロイする方法については、CircleCI Orb レジストリの Firebase Orb のデプロイに関するページを参照してください。
Google Cloud
Google Cloud Platform にデプロイする前に、Google Cloud SDK を承認して、デフォルトの構成設定を行う必要があります。 詳細については、「Google Cloud SDK の承認」を参照してください。
以下の例では、build-job
が終了し、現在のブランチが master ブランチである場合に、deploy.sh
が実行され、実際のデプロイ処理が行われます。
<br /> deploy-job:
docker:
- image: my-image-version-tag
working_directory: /tmp/my-project
steps:
- run:
name: GKE への master のデプロイ
command: ./deploy.sh
workflows:
version: 2
build-deploy:
jobs:
- build-job
- deploy-job:
requires:
- build-job
filters:
branches:
only: master
デプロイ スクリプトを実行すると、新しく作成された Docker イメージがレジストリにプッシュされ、K8s デプロイが更新されます。これにより、gcloud
コマンドでは新しいイメージが使用されて、承認の処理とイメージのプッシュが一度に実行されます。
sudo /opt/google-cloud-sdk/bin/gcloud docker -- push us.gcr.io/${PROJECT_NAME}/hello
これで、新しいイメージが GCR で使用可能になり、GCP インフラストラクチャからアクセスできるようになります。 次に、権限を変更します。
sudo chown -R ubuntu:ubuntu /home/ubuntu/.kube
最後に、kubectl
の patch サブコマンドを使用して、コンテナで使用するイメージを指定する行を検索し、ビルドしたイメージのイメージ タグを置き換えます。 これで、K8s デプロイによって以前のコンテナがシャット ダウンされ、最新のコンテナの使用が開始されて、クラスタがアップグレードされます。
kubectl patch deployment docker-hello-google -p '{"spec":{"template":{"spec":{"containers":[{"name":"docker-hello-google","image":"us.gcr.io/circle-ctl-test/hello:'"$CIRCLE_SHA1"'"}]}}}}'
deploy.sh
ファイル全体は GitHub で確認できます。 また、CircleCI 2.0 Google Cloud デプロイ サンプル プロジェクトはこちらで確認できます。
Google Cloud Orb のサンプル
CircleCI Orb (ジョブ、コマンド、Executor を含む構成パッケージ) を使用して構成ワークフローを簡略化するには、CircleCI Orb レジストリで提供されている Google Cloud 向けの Orb のサンプルを参照してください。この中には、以下のサンプルも含まれています。
version: 2.1
orbs:
gcp-cli: circleci/gcp-cli@1.0.0
workflows:
install_and_configure_cli:
# 使用する Executor を決定 (オプション)
executor: default
jobs:
- gcp-cli/install_and_initialize_cli:
context: myContext # コンテキストまたはプロジェクトレベルの環境変数を介して gCloud サービス キーを保存します
google-project-id: myGoogleProjectId
google-compute-zone: myGoogleComputeZone
この Orb の詳細については、CircleCI Orb レジストリの CircleCI Google Cloud Orb に関するページを参照してください。
Heroku
Heroku は、クラウドでアプリケーションをホスティングするための一般的なプラットフォームです。 アプリケーションを Heroku にデプロイするように CircleCI を構成するには、以下の手順を行います。
-
Heroku アカウントを作成し、Heroku の Web ページに記載された手順に従って、選択した言語でプロジェクトをセットアップします。
-
Heroku アプリケーションの名前と Heroku API キーを環境変数として追加します。 手順については、「プロジェクトでの環境変数の設定」を参照してください。 以下の例では、これらの変数はそれぞれ
HEROKU_APP_NAME
およびHEROKU_API_KEY
として定義されています。 -
.circleci/config.yml
で、deploy
ジョブを作成し、Executor タイプを追加します。
手順については、Executor タイプに関するドキュメントを参照してください。
- コードをチェック アウトし、git を使用して master ブランチを Heroku にデプロイするコマンドを追加します。
version: 2
jobs:
build:
...
deploy:
docker:
- image: buildpack-deps:trusty
steps:
- checkout
- run:
name: Heroku への master のデプロイ
command: |
git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git master
workflows:
version: 2
build-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
メモ: Heroku では、デプロイまたは自動デプロイで、デプロイの前に渡す CI を待機するオプションが提供されます。 詳細については、Heroku のドキュメントを参照してください。
Heroku Orb のサンプル
Heroku をデプロイする場合や、Heroku ワークフローをカスタマイズする場合などに、Heroku 構成ワークフローを簡略化するには、以下のような Heroku Orb を使用します。
Heroku のデプロイ
version: 2.1
orbs:
heroku: circleci/heroku@1.0.0
workflows:
heroku_deploy:
jobs:
- heroku/deploy-via-git
Heroku ワークフローのカスタマイズ
version: 2.1
orbs:
heroku: circleci/heroku@1.0.0
workflows:
heroku_deploy:
jobs:
- deploy
jobs:
deploy:
executor: heroku/default # 標準の buildpack-deps イメージを使用します。このイメージは、Heroku の CLI をインストールする際に前提条件を提示します。
steps:
- checkout
- heroku/install # 必要に応じて heroku インストール コマンドを実行します。
- heroku/deploy-via-git: # git プッシュを使用して Heroku にブランチをデプロイします。
only-branch: master # only-branch を指定した場合、他のブランチでデプロイは行われません。
これらの Heroku Orb の詳細については、CircleCI Orb レジストリの CircleCI Heroku Orb のページを参照してください。
NPM
パッケージを npm レジストリにパブリッシュするように CircleCI をセットアップすると、プロジェクトのコラボレーターは、一貫性のある予測可能な方法で新しいパッケージのバージョンを簡単にリリースできるようになります。
- パッケージのパブリッシュに使用するアカウント用に npm authToken を取得します。
そのためには、まず npm にログインします (npm login
)。 これで、authToken が ~/.npmrc
ファイルに保存されます。 以下の行を探します。
```
//registry.npmjs.org/:_authToken=00000000-0000-0000-0000-000000000000
```
この場合、authToken は `00000000-0000-0000-0000-000000000000` です。
-
プロジェクト設定に移動して、取得した authToken に
NPM_TOKEN
変数を設定します。 -
authToken を
~/.npmrc
に追加するように CircleCI を構成し、バージョンが指定されたタグにのみnpm publish
を実行します。
version: 2
jobs:
publish:
docker:
- image: circleci/<language>:<version TAG>
steps:
- checkout
- run:
name: NPM へのパブリッシュ
command: |
npm set //registry.npmjs.org/:_authToken=$NPM_TOKEN
npm publish
workflows:
version: 2
tagged-build:
jobs:
- publish:
filters:
tags:
only: /v[0-9]+(\.[0-9]+)*/
-
新しいバージョンを npm にパブリッシュするには、以下に示すように
npm version
を実行して新しいバージョンを作成します。npm version 10.0.1
これで、
package.json
ファイルが更新され、タグ付きの Git コミットが作成されます。 次に、タグ付きのコミットをプッシュします。git push --follow-tags
-
テストが完了すると、パッケージが npm に自動的にパブリッシュされます。
SSH
SSH を介してアプリケーションをデプロイするように CircleCI を構成するには、以下の手順を行います。
-
デプロイ先のサーバー用の SSH キーを追加します。 手順については、「CircleCI に SSH キーを登録する」を参照してください。
-
ビルド VM の SSH ユーザー名と SSH ホスト名を環境変数として追加します。 手順については、「プロジェクトでの環境変数の設定」を参照してください。 以下の例では、これらの変数はそれぞれ
SSH_USER
およびSSH_HOST
として定義されています。 -
.circleci/config.yml
で、deploy
ジョブを作成し、master ブランチをデプロイするコマンドを追加します。
version: 2
jobs:
build:
#...
deploy:
machine:
enabled: true
steps:
- run:
name: SSH 経由のデプロイ
command: |
ssh $SSH_USER@$SSH_HOST "<remote deploy command>"
workflows:
version: 2
build-and-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master