テスト/デプロイを自動化したい

[halsk]

改善詳細 / Details of Improvement

• テストとデプロイを自動化したいですね

期待する見せ方・挙動 / Expected behavior

• CI/CD環境を作る
• CIについては Testing FrameworkをRSpecにする #42 も関連
• デプロイについては、今は Elastic Beanstalk に eb deploy しています。

対象インスタンス / Instances

• 加古川市

[doyaaaaaken]

CI/CD周りでこのプロジェクトに合いそうだと個人的に感じた構成について記載します。
（全く要件理解していない上での意見なので、違和感あれば気にせずスルーしてください！）

どちらのツールも利用経験者なので、内容聞きたいとか、設定作業自体も誰かに依頼したいとかありましたら、遠慮なく教えて下さい。 🙇

CI

CircleCIのようなサービスを使うのが合っていそうに感じました。

folkしたリポジトリからのコミット含む、どんなコミットに対してもテストを回すことができるため、PRの受取時にもテストされたコミットであることが保証され安心感があります。
私自身も個人のOSSで使っていますが、簡単な設定ファイルをこのように1ファイル書けばあとは管理画面上で設定するだけなので簡単に使えます。
またOSSであることを申請することで、無料分ビルド時間が長くなったりもします。

CD

AWS Codepipelineが、AWS Elasticbeanstalkとの相性が良さそうに感じました。（私自身職場でも利用している構成です）
Githubの特定ブランチ（例えばmaster）の変更をもとにトリガーされ、指定したコマンド（ビルド系コマンド）を実行し、最後にElasticBeanstalkへのデプロイを行うことができます。
こちらもbuildspec.ymlというビルドコマンド設定ファイルを1つ書いてリポジトリ内に含めておけば、あとはCodePipelineの画面上で少し設定するだけで使えたりします。

[komtaki]

私もCircle CIとかGithub Actions & AWS Codepipelineがいいかなと思ってました。

AWS CodepipelineならAWS ECRへのpushをキーにデプロイとかできますし。

切り戻しのjobをどうフックさせるかとかが肝になりそうですね。
一旦はAWSコンソールからでもいいのかもしれませんが。

現状は、AWS Elasticbeanstalkに直接デプロイしている感じですよね。出来れば、CI/CDするなら、コンテナにしてテストされた資源をそのままデプロイするのがベストかなと思いました。その方が、厳密にテストを通ったと言えるので。

1. CIでimageをbuild
2. imageをECRにpush
3. Codepipelineが起動し、BeanstalkがECRからimageをpullし、EC2上でコンテナを起動

[halsk]

CIについて：今は Github Actions が楽なので、そちらで行きたいです！
@doyaaaaaken
@komtaki
AWS の設定、できそうであれば管理権限をシェアしますが、いかがでしょうか。
（機密事項に触ることになるので、NDA結んでいただきますが）

[komtaki]

構築頑張ります。NDAの件、承知しました。

電子契約だとありがたいです。クラウドサインとか（自社製品を押してるわけではないです。笑）

[komtaki]

Github Actionsも最近は、機能が充実してきましたからね。

AWSのリソースは、Cloud Formationで作るとコード管理できて楽なので、その方向でやりたいです。ECRとか、ほぼなんでも作れるので。

[halsk]

@komtaki ありがとうございます！
[email protected]
CC: [email protected]
宛にNDAを送る先をメールしてください。

[doyaaaaaken]

@halsk
ありがとうございます！↑のメールアドレス宛に、NDAを送る先を記載したメール送信いたしました。

@komtaki
cloud formation, ecr普段使ってないのですみませんがAWS構築はリードしていただいてもいいですか？
（変に分担するのも難しいかもしれませんが）もし分担したほうが楽そうな箇所あればやりますので遠慮なく教えて下さい！
一番きれいな分担はGithub Actionsだけ僕が設定するとかな気がしてますが、いかがでしょう？

[komtaki]

@halsk
NDA送付先をメールしました。よろしくお願いします。

@doyaaaaaken

一番きれいな分担はGithub Actionsだけ僕が設定するとかな気がしてますが、いかがでしょう？

承知しました。一旦、ふんわりこの分担でいきましょう。ただ、私はElasticBeanstalkにそこまで詳しくないので、Cloud Formationで基礎的な部分を作るので、適宜レビューしてもらう感じで。

あとは、現状、Dockerイメージは公式のイメージを使っています。ですが、イメージサイズが大きいので、セキュリティ的にもslimとかにして圧縮した方がいいと思います。途中まで作っているので、引き続き私がやろうと思います。

Github Actionsのワークフローは、こんなイメージでしょうか

1. Docker image build
2. Rubocop test
3. RSpec test
   -- masterのみ --
4. Docker image push to ECR
5. Deploy to AWS Elastic Beanstalk from AWS Code Pipeline

あとは、デプロイタイミングですかね？

• Git tagベース - > ある程度タイミングを制御する場合（毎回デプロイしない）
• Commit pushベース -> ほぼ毎回デプロイする場合

[takahashim]

deployのタイミングではRuboCopは動かさなくて良さそうです。基本的にはlintなので、RSpecによるテストが通っていれば動作は問題ないかと思います（動作に関係ない、空行の有無みたいな違いでデプロイに失敗するのは体験がよろしくない気がするので…）。

[doyaaaaaken]

@komtaki

諸々考えていただきありがとうございます！

承知しました。一旦、ふんわりこの分担でいきましょう。ただ、私はElasticBeanstalkにそこまで詳しくないので、Cloud Formationで基礎的な部分を作るので、適宜レビューしてもらう感じで。

はい、承知しました！

あとは、現状、Dockerイメージは公式のイメージを使っています。ですが、イメージサイズが大きいので、セキュリティ的にもslimとかにして圧縮した方がいいと思います。途中まで作っているので、引き続き私がやろうと思います。

#67 ですね。ありがとうございます！

Github Actionsのワークフローは、こんなイメージでしょうか

大体僕も同じイメージです。
@takahashim さんおっしゃるとおりで、 2.Rubocop test は無くそうと思います。

あとは、デプロイタイミングですかね？

この要件、決めたいですね。
@halsk デプロイタイミングはどちらがいいでしょうか？

1. Git tagベース - > ある程度タイミングを制御する場合（毎回デプロイしない）
2. Commit pushベース -> コミットがmasterブランチに入るたび毎回デプロイする

あとGithub ActionsについてはもしGithubの権限いただければ、早速CIだけでも先に作っていきたいので権限付与のタイミングもご検討よろしくおねがいします。

[halsk]

ありがとうございます！
git tag ベースが良さそうに思います。

[komtaki]

仮で、ECRのレポジトリを作成しました。現状、Tagベースでガンガンpushする印象はなかったので、ライフサイクルは設定してません。

Cloud Foramtionのテンプレートは後で、このレポジトリ？にあげます。

ECR URL
https://ap-northeast-1.console.aws.amazon.com/ecr/repositories/decidim-cfj/?region=ap-northeast-1

Cloud Formation stack
https://ap-northeast-1.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/stackinfo?filteringText=&filteringStatus=active&viewNested=true&hideStacks=false&stackId=arn%3Aaws%3Acloudformation%3Aap-northeast-1%3A887442827229%3Astack%2Fcreate-ecr-repository-decidim-cfj%2Ff786f940-1be9-11eb-8873-0a4084594d18

[halsk]

このIssue、まだ終わっていないと思うので、再オープンします。

[doyaaaaaken]

GithubActionのCIの件、着手遅くなっていてすみません 🙏
明日祝日ですので着手します。

[komtaki]

@doyaaaaaken

すみません。ざっくりデプロイのGithubActions作っちゃいました。:bow:
@\takahashim さんが、テストの方もだいたい作ってくれてるみたいですし。

そちらは大体できそうなのですが、肝心のstaging（テスト）環境のElastic Beanstalkの構築に少々手こずりそうです。
↓設定手順がわりとあるので、こちら手伝ってほしいです。

#110

[takahashim]

テストについては、現状のrails-test.ymlでのテストはGitHub上のubuntu-latestの汎用的なActionベースで動かしているため、コンテナを使うのであればその環境でも動かして問題ないかどうか確認した方がよいのでは？　という気持ちもあるのでした。

でも現状のDockerfileだとtest環境のbundle installはしないんですよね。コンテナを使ったビルド・デプロイパイプラインって最近はどういう対応にするのがいいんでしょうか？（あくまで軽量化を優先 vs あくまでtestとproductionで同一のイメージにこだわる）
この辺は詳しくないので、得意な方におまかせしたいです 🙏

[komtaki]

testとかだと、bundle installしたライブラリをDockerにmountして使うのがいいのかなと思ってます。
Gemfile.lockでlockされているので、基本バージョンはずれないはずですし。

毎回Buildすると、実行速度が遅くなるので、Dockerfileに変更がなければ、latestとかで使い回すのがいい気がします。現状latestタグはないので、一旦stsgingタグでしょうか。:thinking:

[komtaki]

だいぶ時間が空いてしまいましたが、タイミングを見てElastic beanstalkのCNAME SWAPを使ってdockerコンテナにプラットフォームごと本番も切り替えたいです。そしたら現在のgiithubのジョブをいじるだけで、github上からデプロイできるようになります。

手順は下記のような感じでやれば、ダウンタイム無で切り替えられます。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/decouple-rds-from-beanstalk/

https://dev.classmethod.jp/articles/beanstalk-cname-swap/

もしstagingだけで発現するエラーとかあれば、コンテナを調整するのでご教授いただけると助かります。:bow:

[komtaki]

@ayuki-joto 上記の流れで、対応しても問題ないでしょうか？

[ayuki-joto]

@komtaki
一旦問題ないと思うので対応いただければと思います！

[ayuki-joto]

@komtaki
こちらもしもの場合があるので実際に切り替え作業を行う際にGithub上でも構わないので一度ご連絡いただければと思います！

[komtaki]

@ayuki-joto

対応ありがとうございます。

正常に切り替わっていることを確認しました。ただちょっとCPU使用率が前よりも高い気がします。以前のアプリとログを見比べてみたんですが、特に怪しい箇所は見当たらず。:sweat_drops:

杞憂かもしれませんが、awsからリソース面からもう少し調べてみます。私はnewrelic見れないので、newrelicからパフォーマンス観点で確認をお願いできますか？

[komtaki]

@ayuki-joto
あと新しい環境だとsidekiqが動いていないですね。:sweat_drops:近日中に対応します。

一旦、旧環境で動いているので確認できたので、問題はないですかね？

[ayuki-joto]

@komtaki
おっと、ということはqueueの処理になっていないということでしょか？

[komtaki]

queueがsecret_key_baseなど環境固有値に依存していなければ、queueを積む環境と、queueの処理を消化する環境が分かれてる気がします。queueはアプリでredisにつまれるんですよね？ruby自体&sidekiqの処理にあまり詳しくないので、はっきりと明言はできないのですが。

新環境では、おそらく動いてないですが、旧環境では /app/log/sidekiq.log にログが吐かれているので動いてます。

sidekiqを設定しているのはここなのですが、見落としてました。:sweat_drops:
https://github.com/codeforjapan/decidim-cfj/blob/master/deployments/.ebextensions/03_sidekiq.config#L7

調整自体は、2,3日でできると思います。

[komtaki]

codeforjapanとか、demoサイトで試してみたいのですが、どういう操作したらキューが積まれるかわかりますか？

[ayuki-joto]

@komtaki なるほど！僕も確認漏れていましたすみません...
queueはredisに積まれるであっています！
ということは一旦旧環境に戻した方が安全とかありますでしょうか...?

codeforjapanとか、demoサイトで試してみたいのですが、どういう操作したらキューが積まれるかわかりますか？

こちらぱっと思いつくのがメール処理くらいなのですが最近そこも怪しいのではないかという話がでてたりするので一旦確認します

[komtaki]

確認ありがとうございます。確かに、mailersというのが入ってますね。

メールが全部キューで送付されているなら、事前にcodeforjapanドメインで動かした時に、メールちゃんときました。

#56 (comment)

そしたら、queueを積む環境と、queueの処理を消化する環境が分かれてるだけで障害にはなってないので、戻さなくて大丈夫な気がします。修正対応は急ぎますが。:sweat_drops:

[ayuki-joto]

productionのActiveJobは全部sidekiqに任せるような形になっているようです！
メールまわり僕も確認しましたが、コメントの通知などもきたので切り分けが難しいですね...

一旦どれかのインスタンスで、
bundle exec sidekiq -d -L log/sidekiq.log -C config/sidekiq.yml -e production
こちら実行して様子見しようと思います！(数日はこれで乗り切れるかと期待してます)
修正対応またご連絡いただければと思います！

[komtaki]

@ayuki-joto

確認ありがとうございます。 🙇

メールまわり僕も確認しましたが、コメントの通知などもきたので切り分けが難しいですね...

個人的には、切り分けは出来てると思ってました。はっきり新環境で積まれたキューが、旧環境でキューが消化されているログが出てるので。ちなみにどのあたりが不安な感じでしょうか？

docker環境では出来ないので、新環境ではなく別のインスタンスを立てるってことですよね？
やってもいいと思います。ただ結局環境が違うという意味では現状と同じなので、あまり意味はないと思います。

一旦どれかのインスタンスで、
bundle exec sidekiq -d -L log/sidekiq.log -C config/sidekiq.yml -e production
こちら実行して様子見しようと思います

結局、修正が終わるまで旧環境を消さなければ問題ないだけなので。修正は出来次第連絡します。:+1:

[ayuki-joto]

@komtaki

はっきり新環境で積まれたキューが、旧環境でキューが消化されている

すみません。この認識が抜け落ちていました。
確かにそうですね。旧環境で処理されているので問題ないと思います。

[komtaki]

私の説明が下手ですみません。:sweat_drops:

修正は急ぎます。:bow:

[ayuki-joto]

いえいえ！
僕の理解不足でした！

修正お手数おかけしますが、よろしくお願い致します！

[komtaki]

@ayuki-joto

だいたいPRで来たのですが、railsのところでつまってます。rubyほぼ触ったことないので 💦

stagingでメール送付される処理をしたとき、sidekiqがSMTPのlocalhost:25を見に行ってします。

環境変数として、SMTP_ADDRESS等は設定しました。Docker内でecho $SMTP_ADDRESSしたときに、正常にドメインが返ってきます。

mailerの初期化このあたり？

https://github.com/codeforjapan/decidim-cfj/blob/develop/config/environments/production.rb#L83

https://github.com/codeforjapan/decidim-cfj/blob/develop/config/secrets.yml#L70

べたで記載されている587ポートではなく25ポートが参照されているので、railsのconfig/secrest.ymlがよまれてないように見えます。
sidekiq単体で動かしているので、railsの初期化がされてない？気がしますが、よくわからず。。

アドバイス頂けると助かります。:bow:

[ayuki-joto]

@komtaki
遅くなってしまい申し訳ありません！

こちらまだ起こっている現象でしょうか？
railsの初期化という点があまりわかっていないのですが、sidekiqのコンテナでは設定した環境変数などは見れているのでしょうか？

一旦もろもろ検証したいのでマージしてstagingで触ってみるとかでしょうか...?

[ayuki-joto]

それと、PRのこちらの件

sidekiqはメモリ使用量が多く、webサーバーのスケールとスケールのタイミングが異なる。アクセスが増えたからと言って、キューの処理量もそれに応じて、増えるわけではない。このレベルのサービスなら1プロセスで十分。
そのため、WEBサーバーと同じパッケージに入れるのは非効率的だと感じた。パフォーマンスを追求するならfargateとかに移行するべきだと思う。

こちらについても並行して検討しております！ありがとうございます！

[komtaki]

@ayuki-joto

こちらまだ起こっている現象でしょうか？
railsの初期化という点があまりわかっていないのですが、sidekiqのコンテナでは設定した環境変数などは見れているのでしょうか？

残念ながら、まだ解決しておりません。かなり頑張っているのですが。:sweat_drops:

rails 用とsidekiq用で、コンテナを2つに分けました。イメージ、環境変数は同じものを使用しています。

sidekiqのログには、production起動したと記述があるのですが、ホストやポートがデフォルトのままでaction mailerの設定がされない状態です。

sidekiq用のコンテナ内で、rails c -e productionして、ActionMailerで関数呼ぶとメールが送れます。なのでsidekiqの問題だと思うのですが、完全にはまってます。

https://qiita.com/kon_yu/items/570a14af3f91f867e6ba

[komtaki]

MRのECSのあたりは、優先度低いですし余談なのであまり気にしないでください。

たしかにMRレビューしてもらって、問題がなければ、stagingで見てもらったほうが早そうです。お手好きの際にお願いします。:bow:

[komtaki]

sidekiqのログには、production起動したと記述があるのですが、ホストやポートがデフォルトのままでaction mailerの設定がされない状態です。

おそらくシステム上の環境変数が、sidekiqプロセス上で上手く読めてない気がしています。RAIL_ENVが見えず、railsは開発者モードで起動している？とはいえ、Redisには繋がってるので、REDIS_URLは見えてるんですよね。。

[komtaki]

@ayuki-joto

原因がわかりました！！！

組織ごとにsmtpの設定が出来るんですね。それにlocalhost 25で設定が入っていたからでした。おそらくfakerでデータを作成した時に自動で設定されたのだと思います。設定を消したらちゃんと送付されました。:sweat_drops:

どうりで、自分のMRのミスを探しても見つからないわけだ。。。

レビューと本番反映をお願いします。

[ayuki-joto]

@komtaki
あーーーこんな機能ありましたね！
失念しておりました。申し訳ありません。
レビューしましたので、確認していただければと思います！

[komtaki]

@ayuki-joto

レビュー&マージありがとうございます。

staging確認と問題なければ本番反映をお願いします。

[komtaki]

@ayuki-joto

ただちょっとCPU使用率が前よりも高い気がします。以前のアプリとログを見比べてみたんですが、特に怪しい箇所は見当たらず。💦

少しこちら調べてみました。

時折decidimのアプリの中で結構でかい/tmp/diffy-20210620***みたいなファイル2つに対してdiffを取るプロセスが実行され、IOに負荷がかかりCPUの大半を食ってますね。 🤔

ファイルの中身はHTMLぽい？設定変更した時とかに実行されるかんじでしょうか。

New RelicのAPMを入れている認識なのですが、これなんでしょうか？私はnew relicのアカウントを持っておらず。 💦

[komtaki]

@ayuki-joto

リリースありがとうございます。sidekiqも動いており、メールも送られているので大丈夫そうですね。

1日経ったので、旧環境を1台にスケールダウンしました。タイミングを見て環境も削除します。

[komtaki]

手順通り旧環境を削除しました。特に問題はなさそうです。

何かあれば連絡をください。これで本イシューは終了ですかね?

[ayuki-joto]

@komtaki リリース遅くなり申し訳ありません！
ご対応ありがとうございます！

時折decidimのアプリの中で結構でかい/tmp/diffy-20210620***みたいなファイル2つに対してdiffを取るプロセスが実行され、IOに負荷がかかりCPUの大半を食ってますね。 🤔
ファイルの中身はHTMLぽい？設定変更した時とかに実行されるかんじでしょうか。

こちらについては現在調査中なのですが、各ディベートを編集した際に生成されるバージョン管理機能の方で、負荷が高まりCPU使用率が跳ね上がる現象を確認しています！
DBのデータが問題ではないかとなっており現在DB方面調査中です！

何かあれば連絡をください。これで本イシューは終了ですかね?

問題ないと思っています！ありがとうございます！