OiStudy #2 - パルシステムさんとオイラ大地での発表資料です。 GitLabユーザだった私がAWS Code兄弟を利用して見た所感をお話ししました。

1. AWS CodePiplineを使ってみた
GitLab CIユーザの所感
オイシックス・ラ・大地（株）@morihaya55
Photo by Alexandr Podvalny on Unsplash: https://unsplash.com/photos/WOxddhzhC1w
OiStudy #2
2019-08-05

2. 本日の流れ
● Who am I ?
● オイラ大地での利用例を紹介
● それぞれの良いところ
● それぞれの大変なところ
● 今後どうしていくか、とまとめ

3. 簡単な自己紹介
林 如弥(Yukiya Hayashi) @morihaya55
● これまで、インフラエンジニアとしてSIer、ゲーム
会社等を経験してきました
● GitLab CI歴1年、Code兄弟歴3ヶ月
● 今は安全・安心な野菜をお届けするオイラ大地の
システムの運用、改善をするSREです

4. 今から話すこと
● CICDパイプラインの話です
● オイラ大地のシステム全体ではなく、私がメインで
関わったプロジェクトの話です
● 私がSREのため、CICDの利用者というよりは構
築と運用側の目線です

5. (最初に)今回のまとめ
GitLab CIもCode兄弟も優
れたプロダクト、特性を理解
して選択しよう

6. 本日の流れ
● Who am I ?
● オイラ大地での利用例を紹介
● それぞれの良いところ
● それぞれの大変なところ
● 今後どうしていくか、とまとめ

7. オイラ大地での
GitLab Ciの利用シーン

8. 本番
開発者
git push
masterブランチ
developブランチ
その他ブランチ
構文テスト
(digdag check)
デプロイ
(digdag push)
スケジュール無効化
(digdag disable)
開発
digdagへのジョブ反映
承認
(Slack通知)

9. ● masterブランチは本番環境へ
● developブランチは開発環境へ
● 各パイプラインでコードチェック
○ digdag checkコマンドにて
シンプルに普通な形
digdagへのジョブ反映 - 2

10. ● developブランチではスケジュール実行をオフ
(自動実行は基本させないというスタンス)
● masterブランチからの本番反映は手動
(when: manualを指定している)
ちょっと工夫してます＞＜
digdagへのジョブ反映 - 3

11. ● GitLab Runnerは従来からあったサーバ
● RunnerのTAGで環境を区別
digdagへのジョブ反映 - 4

12. オイラ大地での
AWS Code兄弟の利用
シーン

13. ● CodeCommit -> Gitリポジトリ
● CodeBuild -> コードからビルド
● CodeDeploy -> アプリケーションを展開
● CodePipeline -> 上のCode3兄弟を繋げる
CodeStar -> 今回未使用
AWSアイコンの補足

14. 本番EC2
開発者
git push
masterブランチ
developブランチ
その他ブランチ
STG
デプロイ
承認
開発EC2
ECサイトのWebコンテンツ
STG EC2
デプロイ

15. ● masterブランチはSTG環境へ、手動での承認を
経て本番環境へ
● developブランチは開発環境へ
シンプルに普通な形
ECサイトのWebコンテンツ - 2

16. ● 本番サーバは複数台あるがシンプルに
○ インプレースアップデート
○ AtAllOnceで同時アップデート
とした
他にはBlue Greenなどもあります
ECサイトのWebコンテンツ - 3

17. ● Webコンテンツのパイプラインは、社内で従来か
ら使っているJenkinsで行くか、AWSのパイプラ
インで行くかを判断するポイントだったが、シンプ
ルなためか機能した
（利用者側の協力も大きいです）
ECサイトのWebコンテンツ - 4

18. 本番EC2開発者 git push
masterブランチ
developブランチ
その他ブランチ
STG
デプロイ 承認
開発EC2
Java Packages(WAR,JAR)
ビルド デプロイ
ビルド

19. Java Packages(WAR,JAR) - 2
● CodeBuildで gradle jar を行いJARを作成
● CodeDeployで各サーバへ展開
● JARとセットのconfigファイルは、CodeDeployの
hookscriptのシェル芸で展開

20. Java Packages(WAR,JAR) - 3
● CodeDeployの機能で、ALBのTargetGroupから
50%のサーバを切り離しながらデプロイ
（これによりエラー画面は出ない！ただアプリの
作りもあり、ログアウトはしてしまう問題は残って
います...)

21. 本日の流れ
● Who am I ?
● オイラ大地での利用例を紹介
● それぞれの良いところ
● それぞれの大変なところ
● 今後どうしていくか、とまとめ

22. 共通して良いところ

23. 共通して良いところ
● アプリケーションコードと同じGitリポジトリにパイ
プラインのコードがあるのが良さ
○ 従来のJenkinsだとCICDの仕組みは完全に
別管理だった
○ (なおJenkinsもJenkinsfileで実現できるた
め、弊社側の仕組みがよくないだけ :）

24. GitLab Ciの良いところ

25. GitLab CIの良いところ
● .gitlab-ci.ymlで全てが完結
● Runnerとして既存のサーバを登録することがで
き、従来の手作業からの移行も簡単
● 社内利用者がUIに慣れてる（ver10あたりのバー
ジョンアップで大きく変わったけど)

26. .gitlab-ci.ymlで全てが完結
● .gitlab-ci.ymlに全部書くシンプルさ
● コード自体はシンプルなYAML形式
● シェル芸(one liner)も受け入れてくれる

27. Runnerとして既存のサーバを登録できる
● まだまだ手組みな既存サーバも多いため、それら
を簡単に組み込めるのが良い
(K8sでのマイクロサービスが動くGitHubと
CircleCIなキラキラした環境もありますが)

28. Runnerとして既存のサーバを登録できる - 2
● 育ちきった従来のサーバを組み込むことが多い
ので基本的にExecutorはShellを選択
● 本番と開発といった
区別はTabで制御

29. 社内利用者がUIに慣れてる
● これは結構重要な要素だったと考えてます
● 開発者は普段からGitLabを利用している前提
● 新規ユーザ作成等の手間もなかった

30. 社内利用者がUIに慣れてる - 2
● いつもの画面の、メニューを押すだけ

31. 社内利用者がUIに慣れてる - 3
● 「なんかパイプライン見れる」これが大事

32. AWS Code兄弟の良いと
ころ

33. AWS Code兄弟の良いところ
● 自前のサーバからの解放(Serverless)
● ALB連携が最高
● IAMによる一貫した制御
● コンテナネイティブ

34. 自前のサーバからの解放
● Gitサーバ、ビルドサーバ、デプロイサーバ、ジョ
ブスケジュールサーバが不要になる
● 世界を支えるAWSインフラに乗っかる安心感（盲
信はしてないけど）

35. ALB連携が最高
● 繰り返しになるけどCodeDeployの機能で
TargetGroupと連携しながら 50% 生かしつつデプ
ロイできるのは素晴らしい
● 従来やっていたシェル芸やLB側の複雑な設定は不
要に

36. IAMによる一貫した制御
● 全てをAWS上のサービスで行なっているため、
IAMで大抵のことは制御できる
(複雑なことはやってないけど）
● EC2のIam-RoleでCodeCommitからgit cloneが無
認証でできるのも地味によかった

37. コンテナネイティブ
● Codebuildはコンテナを利用するため、ビルド用の
コンテナイメージが必要となった
● 今までやりそうでやらなかった良い機会に

38. コンテナネイティブ
● 「コンテナでビルドできるじゃん！？」の声
● 既存システムへの逆輸入を検討している

39. 本日の流れ
● Who am I ?
● オイラ大地での利用例を紹介
● それぞれの良いところ
● それぞれの大変なところ
● 今後どうしていくか、とまとめ

40. GitLab Ciの大変なところ

41. GitLab Ciの大変なところ
● 実はそんなに大変な印象を持ってない
● GitLab CEを利用しているので、自前サーバの
バージョンアップが大変、くらい
（GitLab Ciの大変さというと違いますね...)

42. AWS Code兄弟の大変な
ところ

43. AWS Code兄弟の大変なところ
● 初期の学習コストは低くはない(個人の感想)
○ 各サービスの役割の理解
○ 各サービスの設定方法の理解
● ブランチごとにパイプラインが必要になってる
○ 実行時に切り替えられるけど、したくない
○ GitLabならwhen句で制御できるけど...

44. ● 特に設定ファイルが複数必要なのは面食らった
○ buildspec.yml -> CodeBuild用
○ appspec.yml -> CodeDeploy用
○ 各種hookscript -> CodeDeploy用
■ 役割が違うのであたりまではあるけど
AWS Code兄弟の大変なところ - 2

45. ● 大変というかハマったところも
○ appspec.ymlで指定しても上書きできない
■ hookscriptで対応した
○ デプロイ時のTargetGroupのDraining失敗
■ Listner Portと各EC2のPortが一致してる必
要があった
AWS Code兄弟の大変なところ - 3

46. まとめ＆今後の話

47. ● GitLab CIのシンプルさ、既存サーバをそのまま
CICDに組み込める良さは素晴らしい
● AWS Code兄弟の一度作った後の手離れ感は素
晴らしい
● AWSのシステムならCode兄弟を使い、従来の国
産クラウドはGitLab CIでのカバーを進めよう
まとめ

48. ● 実はAzure AKSな環境はGitHub x Circle CIと、
社内でもパイプラインの仕組みが多様化
● 新規、既存の見直しなど、都度用途にあったパイプ
ラインを選択して作っていく
● 基本的にはコンテナネイティブにしたいのでtekton
もどこかで入れてみたい(個人の感想)
今後
ご静聴感謝 m( _ _ )m