isucon / isucon11-portal Goto Github PK

https://discord.com/developers/docs/resources/guild#search-guild-members

これで取得できるから「参加してないですよ」って表示するとよい？

• 選手画面
• admin画面

User data is limited to 16384 bytes

GET /api/ssh_public_keys/:team_id/:signature がすでにあるので runcmd で curl して書き込むようにするのが一番楽？

リーダーボードを自チームと他チームに分けるなどしてキャッシュが効くように

go.mod go.sum

本番環境とほぼ同じ動作チェック用環境として portal-dev 環境をデプロイする

• ElastiCache (Redis)
• RDS (Aurora)
• SQS
• ECS (#23)
• Route 53 (portal-dev.isucon.net)
• GitHub, Discord (#11)
• GitHub Actions (#27)
• IAM Role (EcsTaskExecution)

hako app

• isuxportal-dev-discordbot-fargate
• isuxportal-dev-fargate
• isuxportal-dev-grpc-fargate (ベンチマーカー用なので参加登録には不要なので後で)
• isuxportal-dev-worker-fargate

• ヘッダーの「ISUCON10 Portal」
• favicon
• 参加登録画面の文中の部分
• 規約・レギュレーションのリンク

本選作問チームが触るポータル環境を作る

• xi.isucon.dev に作る
• ログイン用の Discord, GitHub は portal-dev と共有する
  • なので Discord Bot はデプロイしない

• ECR リポジトリ作成 (#23)
• GitHub Actions 用 IAM ユーザーを作成
• GitHub Actions に AWS アクセスキーの登録
• GitHub Actions の Workflow 作成

POST /api/env_checks に name が qualify1, qualify2, qualify3 の時に、それぞれ対応する ContestantInstance にIPアドレスをセットされるようにする。
Private IP については事前に決まってるはずなのでチェッカーからは送らない。
Cloud ID も特に送ってないし、特に使うことも無いともうので適当な値を入れておく? (EC2 のインスタンス ID をチェッカーから貰っても良いかも)

(前回の定例でタスク洗い出しした際には忘れてて抜けてそうだったので Issue 作りました。一旦ポータルアプリ側の他作業も @sapphi-red さんが持ってるので Assign しておきました。)

本番環境ポータル DNS のレコードを isucon.net に設定してもらうように依頼する (早めにやる)
こっちで作業しやすいように #12 で作成したゾーン内のサブドメインに CNAME する

TLS 証明書のために Amazon Certificate Manager を通すためのレコードも設定してもらう

早めにデプロイしてベンチマーカーとのつなぎ込みもテストできるようにする

Failedのときに0点にならないことがあります。
0点： https://portal-dev.isucon.net/admin/benchmark_jobs/130
正の点： https://portal-dev.isucon.net/admin/benchmark_jobs/132

• (a) 今の実装はfinishedかつfailedのときにしか0点にならないことになっていそう
  

  isucon11-portal/portal/app/models/benchmark_result.rb

  Lines 114 to 118 in 8267bbf

  	private def set_score_zero_when_failed
  	if finished? && !passed?
  	self.score = 0
  	end
  	end

なので、恐らく

• ベンチ側のバグで、finished=trueが送れていない
• (b) portalの仕様として、failedした時点で、finished=trueが来ていなくてもベンチを終了させている

のどちらかだと思っています。

(a)や(b)は仕様ですか？

この問題自体はベンチマーク側で解決出来ると思うので、仕様ならそのままで大丈夫です。

• チェッカースクリプト
  • ベース
  • 各種チェック
  • ポータルへの送信
• AMI
  • Ansible
  • Packer

チェッカーが AMI ID や AZ ID を知るために、そういった情報を吐いてくれるエンドポイントを実装する
認証は #100 と同じものを使う

• ステージング GitHub App
• ステージング Discord App
• ステージング Discord Bot
• ステージング Discord サーバー
• 本番 GitHub App
• 本番 Discord App
• 本番 Discord Bot
• 本番 Discord サーバー

https://scrapbox.io/ISUCON11/%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%AB

去年と少しは変えたいかもしれない？

• #94
• #95

チェッカーがポータルから AMI ID を受け取って、それと一致しているかチェックしている。
競技環境確認で AMI 更新した場合に、ポータルの返す AMI ID も変えるとその前にダウンロードしてた CloudFormation では AMI 不一致としてチェックに失敗するようになる。
当日 AMI 更新が入る可能性は殆ど無いだろうけども、念の為ポータルから許容できる AMI を全て返して、どれかにマッチすればチェックをパスする仕様にしたほうが安全？

1. 必要なリソースを Terraform で作成 (@yfujit)

• RDS
• ElastiCache
• SQS
• IAM Role

2. データベース初期化 (@takonomura)

• 1 の RDS 作成後に行う
• isuxportal データベースの作成
• isuxportal ユーザーの作成 & 権限付与
• Parameter Store に DATABASE_PASSWORD 追加

3. 外部連携の設定 (@takonomura)

• GitHub App
  • GitHub App 作成
  • Parameter Store に ISUXPORTAL_GITHUB_CLIENT_{ID,SECRET} 追加
• Discord App
  • Discord App 作成
  • Discord Bot 作成
  • Parameter Store に ISUXPORTAL_DISCORD_{CLIENT_ID,CLIENT_SECRET,BOT_TOKEN} 追加
• Discord サーバー
  • Discord サーバーをテンプレートから作成
  • Widget 有効にする (Invite Channel は #readme にする)
  • Discord Bot の追加
    • bot role を付与
• Slack Incoming Webhook
  • Slack 上で Incoming Webhook 作成
  • Parameter Store に ISUXPORTAL_SLACK_WEBHOOK_URL 追加

4. 環境変数の変更 & 秘匿値の生成

• 環境変数 (@yfujit)
  • DATABASE_URL
  • REDIS_URL
  • SENTRY_DSN
  • ISUXPORATAL_FINAL
  • ISUXPORTAL_TIMING_*
  • ISUXPORTAL_TERMS_URL
  • ISUXPORTAL_RULES_URL
  • ISUXPORTAL_DOCS_URL
  • ISUXPORTAL_DISCORD_* (@takonomura)
• 秘匿値 (@takonomura)
  • SECRET_KEY_BASE
  • ISUXPORTAL_VAPID_PRIVATE_KEY
  • ISUXPORTAL_ADMIN_LOGIN
  • ISUXPORTAL_ADMIN_PASSWORD
  • ISUXPORTAL_BYPASS_SECRET
  • ISUXPORTAL_SSH_KEY_API_SECRET
  • ISUXPORTAL_BENCH_TOKEN
  • ISUXPORTAL_DCIM_TOKEN (不要)

5. hako deploy (@yfujit)

• 1~4 が全て完了したあとに行う
• oneshot で bundle exec rake db:migrate
• isuxportal-prd-fargate
• isuxportal-prd-discordbot-fargate
• isuxportal-prd-worker-fargate

6. portal.isucon.net 設定 (@yfujit)

• 先に書いて PR だけ出しといて、 5 の isuxportal-prd-fargate が完了したあとに apply する
• Route 53
• CloudFront

7. 動作チェック

• 1~6 が全て完了したあとに行う
• https://portal.isucon.net が開ける
• admin login ができる
• GitHub, Discord の認証ができる
• /admin/slacktown を叩いて Slack に通知が来る
• Discord Bot がオンラインになっている

したいな〜って思った。

isucon.dev 配下の適当なサブドメイン (xi.isucon.dev ?) で Route 53 にホストゾーンを作成する (開発や内部で使う DNS 用)

• DBにRegion/Zoneを入れる
• CloudFormationのテンプレートを返すエンドポイント
• 選手側のフロント
• admin側のフロント

CloudFormationどこ？ってなるのを防ぎたい

• アドレスの登録
• 参加者のポータルでチームごとにクーポンコードを表示できるような機能
• 予選(各自の登録)と本選(運営で用意)で切り替えられるように

予選にて、ターゲットに指定されたインスタンス以外のアドレスも必要になることがわかったので
supervisor までは gRPC で渡して、 supervisor からベンチマーカープロセスには環境変数で渡す

refs #76

8月13日に行うデプロイの手順確認用

• AMI をパブリックにする
• #136 をマージする
• bundle exec rake db:migrate
• bundle exec rails runner 'ZONE_IDS = ["apne1-az1", "apne1-az2", "apne1-az4"]; Team.active.each.with_index { |t, i| zone = ZONE_IDS[i % ZONE_IDS.size]; t.update_attributes(availability_zone: zone); puts "#{t.id} #{t.name}: #{zone}"; }'
  • デプロイより先に availability_zone 埋めることで空の状態が選手から見えることを防ぐ
• hako deploy
• 本番環境で動作確認
• Discord でアナウンス

github.com/isucon/isucon10-portal になってるところを isucon11-portal に直す

• 例えば以下

  • isucon11-portal/go.mod

    Line 1 in 795dbaf

    module github.com/isucon/isucon10-portal

ポータルと同じ VPC 内に Prometheus と Grafana を構築する

• 構築方法は何でもいい (1つ EC2 インスタンス建てて、 Prometheus と Grafana まとめて動かすとかで良い, Ansible 等使うのが手間であれば手積みでも問題ない)
• ec2_sd_config で予選ベンチマーカーの node-exporter をターゲットにするので Prometheus に IAM で必要な権限つける
• Prometheus の設定は後でするので、一旦仮で良い
• Grafana は外からアクセスできるようにする
  • *.xi.isucon.dev の ACM もあるので、 grafana.xi.isucon.dev とかで ELB 作るのが良さそう
• Grafana はログイン必須にしておく (anonymous アクセス無効にしておく, デフォルトでなっている気もする)
• Grafana の Datasource として Prometheus を追加
• Grafana の Dashboard とかはとりあえず何も作られて無くて良い

• Admin画面で登録されていない人の一覧が取れる
• 選手の画面で登録されていないよって表示が出る

レギュレーション等では「選手」に統一しているはずなので、「競技参加者向けページ」などポータルで「参加者」などになっている箇所も選手に統一する？