CodePipelineを試す
Posted: | Categories: AWS | Tags: Codepipeline
CIを回すサービス
それほど設定は面倒ではなかった。CodePipelineのウィザードに従うと、必要なIAMの作成、CodeBuildのプロジェクトが一気通貫で作成される。
ただ、buildspec.ymlなど各種手順を構築するのが面倒ではある ( が、これは、会社やサービスのシステム構成によってデプロイ方法は異なるものなので、しょうがない。本質的な問題と言える。 この手のツールにありがちな「本質的な悩みに到達する前の作業に時間がかかる」といった悩みの時間は少ないと言える )
はまりポイント
- CodePipelineは「ECSのために作られている訳ではない」ので、 デプロイターゲットをECSとした場合でもIAM権限で、ECSへのアクセス権限が足りないケースがあった。 IAMロールは修正が必要 https://dev.classmethod.jp/tool/docker/20170225-codebuild-docker/ オフィシャルは日本語化されてて、だいたいこれが参照されている http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-docker.html
git cloneできない。これsshの設定からやらねばならんか…
[Container] 2017/12/21 11:25:28 Running command git clone git@github.com:zemi/Docker_Dev.git
Cloning into 'Docker_Dev'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
参考
基本、これに添っていきたい CloudFormationで、ECSのCI/CD環境を構築した際のハマりどころ 〜CodePipeline,CodeBuild,KMSも添えて〜 - Qiita
CodePipeline, CodeBuildを使ってAmazon ECSへの継続的デプロイメントを試してみた ｜ Developers.IO
ここが非常に参考になった、権限が足りない場合がある https://qiita.com/tiibun/items/f0045011c86efca254fc
高速化は –cache-from を使うようだ https://qiita.com/na-o-ys/items/7e7a7e4cde378fc54b32
手順
CloudFormationで構築した方が、作業早いし、再現性が高い、理想的といえる。 がGUIでやってみても、それほど時間がかかる訳ではないので残しておく
- CodePipelineページ開く
名前
- [ パイプラインの作成 ]->[ パイプライン名 ]
ソース
- [ ソースプロバイダ ]は s3, CodeCommit, Githubが選択できる。Githubを選択
- [ GitHubに接続 ]押すとGithubとの認証が走る模様->[ リポジトリ ]->[ ブランチ ]->[ 次のステップ ] ここでの疑問、パイプラインはブランチ単位で作成するものだろうか? できれば「新しいブランチができたら自動的に処理して欲しい」ぶっちゃけていうとRoute53で新しいブランチ名のついた検証用ドメインを作って欲しい。
ビルド
- ビルドプロバイダは AWS CodeBuild, Jenkins, Solano CIが選択可能、私はCodeBuildを選択
Codebuildを選択すると、追加で設定可能なメニューが現れる。 これはCodeBuild側のプロジェクト設定( わかりづらいが、PipelineからCodeBuildのプロジェクトが作れるようになってる。慣れると一気通貫で設定ができるので、この方が効率良さそう ) [ 新しいビルドプロジェクトを作成 ]を選択、プロジェクト名も入力。
Read more...