はじめに
2/23(土)に開催されたJAWS DAYS2019のセミナーレポートです。 走り書きの部分もありますので、内容に不備がありましたらご了承ください。
JAWS DAYS2019のテーマ
満漢全席召し上がれ
以下、セミナーレポートです。
テーマ
今日からはじめるCI/CD...のためのAWSアーキテクチャ事始め
- 山崎 奈緒美さん
- 波田野 裕一さん
アーキテクチャ支部の紹介
- アーキテクチャ談義をする場所が欲しかった
- 支部作った！
- ディスカッション中心の支部
- 次回は3/14(木)
- ディスカッション中心の支部
- 支部作った！
夫婦喧嘩から始まるCI/CD
- 夫
- アプリ開発担当
- 妻
- 同じ会社
- インフラグループ
- 今のアプリはデプロイ方式が手動
- ある日の夫婦の会話
- 妻「CD/CI欲しいなあ」
- 夫「いらなくね？」
- 夫婦喧嘩へwww
- 自動化めんどくさい
- やってるのは妻！！
- 自動化めんどくさい
- 夫婦喧嘩へwww
論点@インフラ
- 手動スケールしたくない
- アクセス負荷に応じたスケールイン・アウトしたい
- インスタンス立ち上げ自動化したい
- コンテナとかマイクロサービスしたい
論点＠アプリ
支部で相談してみた
- 色んな意見が出た
- CI/CDとオートスケーリングは違う
- コンテナなら話は違う
- DockerImageのビルドとか
- CI/CDを分けて考えてみては？
- まずはCI
- CDよりもCIすることが開発の本質
- バグを早期発見して対処すること！
- CDはDelivery、Deploy2つある
- コード変更があると自動的にリリース準備が実行される
- CDの目的
- ユーザからのフィードバックを早く得る
- Deployのために無駄な時間を書けない
- デプロイすることか、ユーザに届けること、どっちに主眼を置くか？
- CI/CDは品質向上を目的としてみては？
- 何のためにシステムを作っているかを考えてみる
- 誰のため？
- SIerならお客様企業
- 事業会社ならお客様
- 情シスなら自社社員
- 誰のため？
- リリースの属人化、権限の縦割りは無駄
- リリースしていい日
- 主任クラスはリリース権限ある
- 若手はリリース権限ない
- 本番サーバ入れないとか
- そういうのは無駄
- プログラム書いてる人が自由にリリースできる方が良い
- リリース権限者がボトルネックになる
- リリース権限の縦割りは古い
- そういうのは無駄
- 本番サーバ入れないとか
- リリースしていい日
- CDから始めるほうがお手軽では？
- CI/CD一気にやると考えることたくさん
- 既存プロジェクトにあとからCI導入は難しい
- SVNで開発してるPJとか・・・
- CIやるにはテストコード必要
- Deployだけでも自動化したら楽では
- 非コンパイル言語ならCDだけでもやってみる価値あり
- CDができるならAuto Scalingに持っていきやすい
- まとめ
- CIとCDの違いを認識する
- 組織や役割分担を変えることにもなる
- 何のためにしたいのかを考える
- 導入しやすいところから始める
- 何のためにシステムを作っているかを考えてみる
- まずはCI
- CI/CDとオートスケーリングは違う
- その後の社内
- 少しずつ動き出している
今日から始めるCI/CD
- 波多野さん
- AWS Samurai2017
- CI/CDってもう当たり前？
- やったほうが良いのはわかるけど、どこから手を付けたら良いのか・・・？
- こういう人多い
- みんな悩んでる
- アーキテクチャ支部で議論してる
CI/CD全体像
- CodeCommit
- ソースコード
- github相当のサービス
- リポジトリ作ってコミット
- issue管理はない
- 単体で使うにはお手軽
- 競合
- Github
- S3
- github相当のサービス
- ソースコード
- CodeBuild
- テスト&ビルド
buildspec.ymlに従ってテストやビルドできる- 何でもできる
- 秘伝のタレ化するので自重も必要ww
- 入力
- Codecommit
- CodePipeline
- Github
- など
- 出力先
- CodePipeline
- S3
- NO_SOURCE
- ymlに書いた場所
- CodeDeploy
- Deploy
- Agentの入ってるEC2にデプロイ
- Lambdaにも対応
- ECSにも対応
- これを軸に考えることになるかも
- Deploy先の箱は固定化されてしまうのが欠点
- 肥大化の香りを感じる
- 入力元
- S3
- 出力先
- EC2など
- Deploy
- CodePipeline
- CI/CDをつなぐもの
- JSONで書かないといけない
- 辛い
- マルチソース対応した
- CloudWatchEventsに対応
- インプット側で変更があれば即時実行が可能になった
- 連携
- 入力
- S3,ECR
- 出力先
- S3,ECS、CloudFormationなど
- 入力
- CodeStar
- とりあえずここからやると上の4つが組み合わせられる
- お試しとしては面白い
- 今回は省略
- 上記を組み合わせてCI/CDパイプラインを組む
- 慣れてない人はまずはCodeStarから
- 今日から始められる
- 慣れてない人はまずはCodeStarから
- この4つを使ってデザインパターンを考えてみよう
- 自分たちのパイプラインを考えてから、ツールに組み込むべき！@SA 大村さん
- 正しい全体像
- 目的
- 自分たちのパイプライン
- 手段
- Code4兄弟
- 自分たちのCI/CDパイプラインにツールを組み込む
- 目的
- CI/CDのデザインマップ
- 提供者
- コード
- ビルド
- Deploy
- Deploy先(ユーザ)
- 自分たちの飯はお客様が払ってくれるお金がもと
- ユーザを意識するべき
- 自分たちのパイプラインの行き先はユーザ！！！
- 自分たちのパイプラインの行き先はユーザ！！！
- 自分たちのCI/CDパイプラインにツールを組み込む
- ツールは何でも良いし、時代で変わる
- いくらツールに精通しても、半年~1年後には変わる
- まずは自分たちのデザインを決めてから、ツールを組み込む
- CI/CDは自分たちの内なる思いを実現する
- 提供者
CI/CDデザインマップから見えてきた形
- 提供者
- コード
- ビルド
- 中間成果物
- Deploy
- Deploy先(ユーザ)
- CodeCommit + CodePipeline + S3
- 提供者
- コード
- S3
- ビルド
- 中間成果物
- S3
- Deploy
- Deploy先(ユーザ)
- S3
- WebShiteHosting
- 単純な上書き。異動や削除には追随できない
- 消したコンテンツが残るので注意が必要
- お試しするには良い構成
- コード
- ツールはいろいろある。アウトプット側からデザインしていくといい
- 今後の議論ネタ
- コンパイル、非コンパイル
- CSSやフロントもコンパイルする
- AMIを使ったDeployどうする？
まとめ
- まずはCI/CDのデザインマップ作ろう！
- なぜその形なのか、ロジカルに説明できるようにすること！
- 客観化して構造化する
- ツールの話になりがちだが、ユーザを意識する！
おわりに
朝から満席のセッションで、非常に勉強になりました。今の現場でデプロイを楽にしようと思い、自分でCodeDeployを導入しましたが、Githubとの連携が不十分で、毎回手動でコミットハッシュを指定している状態です。CircleCIとの連携も不十分です。
どうしたもんかと悩んでいるので、アーキテクチャ支部に参加してみたいと思いました。
CI/CDの話面白かった！自分のプロダクトにCI入れたいのでアーキテクチャ支部行ってみたいなあ。ぼっち参加でもいいんだろうか…。 #jawsdays #jd2019_d
— Yokoyama Hironori (@yokoyantech) 2019年2月23日
