Closed txxxxc closed 4 months ago
一旦developmentにある程度Dockerがあるのでこれで行けそうかやってみる
流石にパニックやけどやばいって
19:53:28.221468 <=== LOAD END
19:53:28.221500 SCORE: 00.StartBenchmark : 1
19:53:28.221503 SCORE: 01.GraphGood : 0
19:53:28.221506 SCORE: 02.GraphNormal : 0
19:53:28.221508 SCORE: 03.GraphBad : 0
19:53:28.221509 SCORE: 04.GraphWorst : 1617
19:53:28.221512 SCORE: 05.TodayGraphGood : 0
19:53:28.221514 SCORE: 06.TodayGraphNormal : 0
19:53:28.221515 SCORE: 07.TodayGraphBad : 0
19:53:28.221516 SCORE: 08.TodayGraphWorst : 1393
19:53:28.221518 SCORE: 09.ReadInfoCondition : 1094
19:53:28.221519 SCORE: 10.ReadWarningCondition : 773
19:53:28.221520 SCORE: 11.ReadCriticalCondition: 31
19:53:28.221522 SCORE: _1.IsuInitialize : 74
19:53:28.221523 SCORE: _2.NormalUserInitialize : 12
19:53:28.221524 SCORE: _3.ViewerInitialize : 36
19:53:28.221525 SCORE: _4.ViewerLoop : 693
19:53:28.221526 SCORE: _5.ViewerDropout : 36
19:53:28.221529 SCORE: _6.RepairIsu : 725
19:53:28.221530 SCORE: _7.PostInfoCondition : 11315
19:53:28.221531 SCORE: _8.PostWarningCondition : 8227
19:53:28.221532 SCORE: _9.PostCriticalCondition: 1121
19:53:28.221534 SCORE: 00.StartBenchmark : 1
19:53:28.221535 SCORE: 01.GraphGood : 0
19:53:28.221535 SCORE: 02.GraphNormal : 0
19:53:28.221536 SCORE: 03.GraphBad : 0
19:53:28.221538 SCORE: 04.GraphWorst : 1617
19:53:28.221539 SCORE: 05.TodayGraphGood : 0
19:53:28.221540 SCORE: 06.TodayGraphNormal : 0
19:53:28.221541 SCORE: 07.TodayGraphBad : 0
19:53:28.221543 SCORE: 08.TodayGraphWorst : 1393
19:53:28.221544 SCORE: 09.ReadInfoCondition : 1094
19:53:28.221545 SCORE: 10.ReadWarningCondition : 773
19:53:28.221546 SCORE: 11.ReadCriticalCondition: 31
19:53:28.222595 score: 50926(50930 - 4) : pass
19:53:28.222604 deduction: 0 / timeout: 46
19:53:28.222612 <=== sendResult finish
一旦なんで動いてるか調べますか
これでそんなに性能出るもんですかえ
一旦make up-bench, run-benchでパフォーマンス測れた
docker-compose-bench.ymlに全部書いてあった
あーでもnginxとかが建ってないので実際のものと乖離はありそうだ
ここらへんいい感じに構築できるように作り変えてみるのはありかもしれない
jiaapi-mockってどこで初期化してるねん
systemd稼働させるの面倒やから一旦コンテナ同士が作用してbenchを起動できるようにするか web, db, nginx, bench, jiaapi-mockくらいかなとりあえず
docker-composeでファイル書いてるとき、どういうタイミングでDockerfileに処理を寄せればいいか分からんみたいな所があります。
別のコンテナにかかわるところ(portなど)は基本的にcompose側に書いたほうが良さそう あとは可読性かなvolumesとかはcompose.ymlで一覧できたほうがわかりやすい
ERROR: Can't initialize batch_readline - may be the input source is a directory or a block device. mysql exited with code 0
なんすかこれ
api | 2024/06/29 14:09:08 Waiting for: tcp://mysql:3306 api | 2024/06/29 14:09:08 Problem with dial: dial tcp 172.25.0.2:3306: connect: connection refused. Sleeping 1s
普通にconnection refusedではある
いけるんかい!
api | 2024/06/29 14:16:19 Connected to tcp://mysql:3306
あとはjiaapi-mockだ
jiaapi-mockはできました
bench動きました👏 あとはログ周りがちゃんと取れてるか調べてみようかしら
14:42:10.377998 score: 54800(54804 - 4) : pass 14:42:10.378000 deduction: 0 / timeout: 46 14:42:10.378005 <=== sendResult finish
nginxのログ見れなかったけど、ここらへんは設定できてなかっただけっぽい
files read later take precedence means that if you have the same option in multiple files, the setting in the last file that's read will be used.
こういうことらしいです https://dba.stackexchange.com/questions/335205/mysql-configuration-file-order-of-read
てかこれ普通にnginxを通ってない説がありますな bench markerが直でAPI触ってそう
my.cnfなんか読み込まれません
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf The following groups are read: mysql client client-server client-mariadb
order of preference, my.cnf, $MYSQL_TCP_PORT, /etc/services, built-in default (3306).
多分/etc/my.cnfの所有者がrootなので、mysqlがファイルを読み込めんなかった説ある
まあrootでmysql実行したらええか →これ無理でした
ていうか公式ドキュメントになんか載ってるんちゃいますのん https://hub.docker.com/_/mysql
etc/mysql/conf.dの中なら読んでくれるってこと?
The default configuration for MySQL can be found in /etc/mysql/my.cnf, which may !includedir additional directories such as /etc/mysql/conf.d or /etc/mysql/mysql.conf.d. Please inspect the relevant files and directories within the mysql image itself for more details.
If /my/custom/config-file.cnf is the path and name of your custom configuration file, you can start your mysql container like this (note that only the directory path of the custom config file is used in this command):
$ docker run --name some-mysql -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag This will start a new container some-mysql where the MySQL instance uses the combined startup settings from /etc/mysql/my.cnf and /etc/mysql/conf.d/config-file.cnf, with settings from the latter taking precedence.
ドキュメントどおりにやったらできましたわ ありがとう
あとはbenchのオプション指定してちゃんと動くかですな
ssl周りで死んだので、opensslで証明書作ってます。 そしたらこれで怒られました。
certificate is not valid for any names, but wanted to match isucondition-2.t.isucon.dev:
openssl x509 -in <(openssl req -subj '/CN=.t.isucon.dev' -nodes -newkey rsa:2048 -keyout roles/contestant/files/etc/nginx/certificates/tls-key.pem) -req -signkey roles/contestant/files/etc/nginx/certificates/tls-key.pem -sha256 -days 3650 -out roles/contestant/files/etc/nginx/certificates/tls-cert.pem -extfile <(echo -e "basicConstraints=critical,CA:true,pathlen:0\nsubjectAltName=DNS.1:.t.isucon.dev")
なんかこれだと無理。というか証明書周りの知識がなさすぎるからちゃんと勉強する
なるほど分からん
.pem 証明書、秘密鍵、公開鍵、CSR など PEM 形式
.crt 公開鍵証明書 PEM 形式
.cer 公開鍵証明書 PEM または DER 形式
.key 秘密鍵または公開鍵 PEM 形式
pemとは。なるほどな
PEM (Privacy Enhanced Mail) 形式は、Base64 エンコードされた ASCII テキストファイルで、SSL/TLS 証明書や鍵などのデータを保存するために使用されます。
特徴:
テキスト形式: PEM ファイルはテキストエディタで開いて内容を確認できます。
Base64 エンコード: バイナリデータをテキスト形式に変換することで、メールなどで安全に送信できます。
ヘッダーとフッター: データの種類ごとにヘッダー (-----BEGIN ...-----) とフッター (-----END ...-----) で囲まれています。これにより、複数のデータを一つのファイルにまとめることができます。
まあいろいろ調べた感じこの流れでやったら行ける説
証明書を突っ込んでupdate-ca-certificatesしたら行ける
update-ca-certificates は、Linuxシステムにおいて、信頼できるルート証明書(CA証明書)を更新するためのコマンドです。
apitestがbenchを実行するからそこに保存するのが大事説
opensslで証明書のチェーンを確認するコマンド
openssl verify -CAfile <ルート証明書ファイル> <確認したい証明書ファイル>
これで確認するのええやん
openssl s_client -connect <ホスト名>:<ポート番号> -showcerts
<ホスト名>: 証明書チェーンを確認したいサーバーのホスト名を指定します。
<ポート番号>: サーバーのポート番号を指定します(HTTPSの場合は通常443)。
このコマンドを実行すると、サーバーとのSSL/TLSハンドシェイクが行われ、サーバーから送られてきた証明書チェーンが表示されます。
やったか?
多分いけたけど別のエラーで死んでもうてます
target=go docker-compose exec apitest go run ./main.go -all-addresses 127.0.0.1,nginx,localhost -target nginx:443 -tls
15:56:07.188369 ISUCON11 benchmarker
15:56:07.188502 ===> PREPARE
15:56:07.188512 start: load initial data
15:56:07.191615 finish: load initial data
15:56:12.517556 ERR: prepare: status code: 期待する HTTP ステータスコード以外が返却されました (expected: 201): 400 (POST: /api/isu)
15:56:12.523718 ERR: prepare: status code: 期待する HTTP ステータスコード以外が返却されました (expected: 201): 400 (POST: /api/isu)
15:56:12.523810 ERR: prepare: critical: アプリケーション互換性チェックに失敗しました
backend | {"time":"2024-07-06T15:56:12.522117301+09:00","level":"ERROR","prefix":"echo","file":"main.go","line":"682","message":"JIAService returned error: status code 400, message: Bad URL Scheme: scheme must be https"}
backend | {"time":"2024-07-06T15:56:12.522934134+09:00","id":"","remote_ip":"172.22.0.6","host":"nginx:443","method":"POST","uri":"/api/isu","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) Gecko/20100101 Firefox/76.0","status":400,"error":"","latency":3126417,"latency_human":"3.126417ms","bytes_in":11731,"bytes_out":25}
これだと怒られるらしい
{"time":"2024-07-06T16:08:25.945738127+09:00","level":"-","prefix":"echo","file":"main.go","line":"655","message":"request to JIAService: {http://isucondition-1.t.isucon.dev:3000 43094ce4-31cf-4cbc-90ef-9298dd25569d}"}
curlは自己証明書を受け付けないってこと? curlで「自己署名証明書」を受け入れるには【curl: (60) SSL certificate problem: self signed certificate】 | LFI
.t.isucon.devの証明書を作ってるけど、意味あるか?そもそも.t.isucon.devっていうURL使えなくね?
ええ、、、
{"time":"2024-07-06T21:41:26.483516548+09:00","level":"ERROR","prefix":"echo","file":"main.go","line":"682","message":"JIAService returned error: status code 400, message: Bad URL: hostname must be isucondition-[1-3].t.isucon.dev"}
なんか書いてあるわ でもあんま意味わかってない。
また、サーバーに設定されている TLS 証明書は subject name が
*.t.isucon.dev
であるため、このホスト名で HTTPS 接続を行うと TLS 証明書の検証エラーは発生しません。ベンチマーカーはこれを期待します。
なお、*.t.isucon.dev
の FQDN に関しては 127.0.0.1
(IPv6 は ::1
)の DNS レコードが登録されています。必要に応じて、検証や開発などで活用してください。
これも大事そう↓
127.0.0.1 localhost
192.168.0.11 isucondition-1.t.isucon.dev
192.168.0.12 isucondition-2.t.isucon.dev
192.168.0.13 isucondition-3.t.isucon.dev
jiaapi.goの131行目に真実はあります
頑張ってみな