#Q&A

#使用関連

#チャレンジのタイプでの「静的コンテナ」は、すべての参加者が一つのコンテナを共有することを指しますか？

いいえ。静的コンテナは動的コンテナと同じで、各参加チームには独立したコンテナがあります。

しかし、静的コンテナの内容は同じで、動的なフラッグは送信されません。コンテナ内にハードコードされた一つまたは複数の静的フラッグを取得して検証指標とするだけで、「静的」の意味です。

#現在のチーム形成のロジックはどのようなものですか？

一人のユーザーは複数のチームに参加でき、各ゲームでは各チーム員が個別に登録する必要があります。同一人物が異なるチームの身分で複数のゲームに同時に参加することができ、登録時にどのチームで参加するかを選択する必要があります。

承認待ちや拒否されたときは登録を撤回できます。承認通過、ブロック時は登録をキャンセルしたり所属チームを変更したりすることはできず、チームはロックされます。

ゲームが終了した後も、チームはロック状態で表示されます。他に進行中のゲームがないことを確認し、人員の変動を行うと、チームは自動的に解除されます。

#複数のコンテナのチャレンジをサポートしていますか？

現在、一部のコンテナバックエンドの互換性問題を考慮して、複数のコンテナのチャレンジはサポートしていません。

#複数の人が同時にチャレンジを編集することができますか？

現在のチャレンジ編集のロジックは、一度データを取得し、ローカルで更新した後にデータベースを全量更新するもので、複数の人が編集するとデータの競合や損失が発生する可能性があります。最終的なデータは最後の更新を基準にするため、同じチャレンジを複数の人が同時に編集することはお勧めしません。

#複数段階のチャレンジをサポートしていますか？

複数段階のチャレンジでは、フラッグを注入する際にスライスし、それを異なる位置に分散させたり、チャレンジが必要とする方法で組み合わせたりすることをお勧めします。

#チャレンジ説明の書き方について

一定期間のテストと使用の後、我々はより良いチャレンジの説明の書き方を見つけました。この方法では、添付ファイルのダウンロードボタンの位置を占有することはありませんし、さらに多くのチャレンジの情報を提供することができます：

**Author:** GZTime
**Difficulty:** Baby
**Category:** Misc

---

Description of the challenge...

注意すべき点は、Markdownの書き方の規則では、改行をしながら新しい段落を始めない場合は、行末に2つのスペースを追加する必要があります。

GZCTFでチャレンジを作成する際は、情報行や他の改行が必要な行の後に適切にスペースを追加し、できるだけ多くの改行を行い、短い文章の各行の幅を 490px （約30文字）以内に保つことで、より良い表示効果を得ることができます。

#プラットフォームのデプロイ関連

#デプロイについてのアドバイスは？

複数のマシンクラスタとそのデプロイ要件を持つユーザーには、K3sをK8sのディストリビューションとして使用することをお勧めします。これは必要な全ての機能を提供し、インストールとデプロイが容易です。

より一般的な場合では、最も便利なデプロイ方法はDocker + K3sの分離デプロイで、docker-composeを実行するだけでGZCTFプラットフォームのデプロイが完了し、K3sのデプロイはインストール後にkubeconfigをエクスポートしてGZCTFにマウントするだけです。

K3sクラスタ内でのデプロイが必要な場合は、2つのPVC（データベースと添付ファイルのストレージ用）、1つのConfigMap（appsettings.jsonのストレージ用）、1つのSecret（自身のクラスタを指すkube-config.yamlのストレージ用）を提供する必要があります。データベースのデプロイとRedisのデプロイは必要に応じて行うことができ、GZCTFのインスタンスを1つだけ実行する場合は、Redisをデプロイしなくてもよいです。

テストの結果、データベースの性能を考慮して、現時点では複数のインスタンスの分散デプロイは推奨されていません。単一のインスタンスのパフォーマンスは、ほとんどのゲームには十分です。

#GZCTFクラスタの複数インスタンスのデプロイには何か注意すべきことはありますか？

GZCTFは複数のインスタンスを同時に実行することをサポートしていますが、同じデータベースインスタンスとRedisインスタンス（複数インスタンス必須）と共有ストレージ（例えばNFS）をPVCとして提供する必要があります。データベースインスタンスと共有ストレージはデータの一貫性を保証するために使用され、Redisインスタンスはバックエンドの一部のデータのキャッシュ同期とSignalRのScale-Outブロードキャストのために使用されます。

また、SignalRがwebsocketに基づいて正常に動作するためには、ロードバランサーでSticky Sessionを設定する必要があります。

#HTTPポートにアクセスできませんか？

このような問題は、Docker + K8sの分離デプロイの場合に、GZCTFをDockerを介してK8sノードで直接実行し、マシンのHTTPポートがtraefikとそのロードバランサーによって占有されているためアクセスできない場合に発生します。解決策は多くあり、非常に柔軟です：

• 1つのマシンしかない場合は、GZCTFをK8sクラスタ内に直接デプロイし、ServiceとIngressを介してサービスを公開します。
• 別のマシンでGZCTFを実行し、K8sノードをクリーンに保ち、GZCTFによるリソース占有を回避します。
• K8sクラスタのtraefikサービスをオフにして、GZCTFまたはリバースプロキシサービスが関連ポートをリッスンできるようにします。

#プラットフォームのポジショニング

#AWD / AWDPのゲーム形式をサポートすることを考えていますか？

GZCTFは無料のオープンソースプロジェクトであり、AWDPのサポートを行う予定はありません。

現在考えられる解法は非常に高い互換性を持っており、実装することは不可能ではありませんが、それには大量の時間投資が必要であり、おそらく3つの付属プロジェクトも必要になるでしょう。これには収入がないと受け入れられません。また、実装した場合、一部の企業の収益源に影響を与える可能性があり、それはあまり良いことではありません。

解答形式のゲーム自体がすでにほとんどの技術能力を訓練することができ、fix / patchも直接教えたり、イメージを配布してローカルで実験したりすることで実現できます。GZCTFの初心は学校がCTFチームをより良く訓練するのを助けることであり、公式のゲームを開催するのではなく、教育の観点から出発して、AWDプラットフォームを作る必要性は低いです。ゲーム形式を訓練したいのであれば、現場ゲームに参加する方が良いでしょう。これも考慮の一部です。