既存のPJをdocker化の上、ECSとCodepipelineを使ってビルド、デプロイまで自動化しました。
その作業の備忘録として何個か記事に分けてまとめます。
- 導入 <=ｲﾏｺｺ
- PJのDocker化
- イメージをECS上で動かす
- CodePipelineを使った自動デプロイ
#全体の作業の概要
ゴールは下記二点
- docker化したPJをCodepipelineを通じて本番にデプロイできること
- さらにそこにアクセスできること
大きく分けて下記のフローで行いました。
- ローカルで既存PJをdockerビルドできるようにする
- dockerをインストール
- PJをクローン
- dockerファイルを作成
- 動作確認
- そのPJをECS上で動かす
2. ECRを作成してローカルで作ったイメージをプッシュ
2. ECS作成
2. アクセス確認 - CodePipelineを使ったデプロイ自動化構築
3. Codepipeline作成
3. ビルドプロジェクト作成 - 動作確認
#Dockerとは
一応今回の主役みたいなものなので概要を紹介
正確な情報は公式ドキュメントまで
日本語版もあります。
Docker とは開発者やシステム管理者が、コンテナでアプリケーションを **構築（build）、実行（run）、共有（share）**するためのプラットフォームです。
（日本語版ドキュメントより引用）
要するに、クソ面倒くさい環境構築を簡単に行うための仕組み。
これを実現するために、「コンテナ」と「イメージ」を使用する。
- イメージ：ビルドしたソースコードをまとめたもの。
- コンテナ：プロセスが走るサーバーのようなもの。この中にイメージを置いている。
で、これらを作るために下記のステップが必要。
- dockerをインストール
- ソースコードを用意
- dockerファイルを作成
それぞれの詳しいやり方はまた別の記事にまとめます。
##メリットとデメリット
あくまで所感ですが。
###メリット
- 環境構築にかかる作業コストが限りなく少なくなる。
- 一度dockerファイルを作ってしまえば、あとはそれを誰かに渡すだけで環境構築が終了する。
- 基本的にローカルで動作するので、作業者が増えた時の個人環境の作成も簡単。
- 仮想マシン（VM）に比べ軽い
###デメリット
- だいぶ複雑なことをしてるため、理解と初めの構築に時間がかかる。
- EC2とは違いsshアクセスなどは基本できないため、ログの収集などをするには専用の設定が必要
- ローカルに限ってはログインコマンドがあるためこのデメリットはないが、普通のPJであればどこかのサーバー上にあげるので結局大変にはなる。
##dockerを採用した経緯
とあるPJのOSが古くなってきたので、丸ごと置き換えることになったとこからスタート。
- 元々AWSで運用していたので、CodePipelineとかを挟めばデプロイまで自動化できる
- 更新頻度がそれなりに多いため、初期構築コストよりその後の運用面でのメリットがでかい。
- 単純にdockerに関するドキュメントや記事が多い。
ということでdocker化することになりました。
社内に経験者も多くいたので不明点を聞けるっていうのも大きかったです。
メジャーな技術はこういうのがいいですよね。
#デプロイの仕組み
ローカルから変更をプッシュすると、それが本番環境に自動反映される形で組みます。
下記大まかな流れ
- あらかじめECSにアクセスできるようにしておく
- 変更をプッシュするとCodePipelineが実行され、イメージがECRにプッシュされる。
- ECRにプッシュされた最新版のイメージでビルドが実行される
- ビルド完了後、ECSで動いているコードが更新される
- これで反映完了
##ECRとは
https://aws.amazon.com/jp/ecr/
AWSのサービスで、dockerイメージを置くリポジトリのようなもの。
dockerコンテナを動かすための環境。
##CodePipelineとは
https://aws.amazon.com/jp/codepipeline/
PJをビルド、リリースまでの挙動をカスタマイズできる