tag:crieit.net,2005:https://crieit.net/tags/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%88/feed
「トラブルシュート」の記事 - Crieit
Crieitでタグ「トラブルシュート」に投稿された最近の記事
2022-02-24T23:44:23+09:00
https://crieit.net/tags/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%88/feed
tag:crieit.net,2005:PublicArticle/18124
2022-02-24T23:29:56+09:00
2022-02-24T23:44:23+09:00
https://crieit.net/posts/Gitlab-push-buffalo
【障害切り分けのコツはまずは森を見ること!】Gitlabのpushエラー、原因は(恐らく?)buffalo製ルータだった話
<p>お久しぶりですにゃ。<br />
やらなきゃいけない事があるからと、”<strong>優先度の低いものをする時間をマストタスクに割り当てよう</strong>”と考えながら<br />
、<strong>結局マスト作業も先延ばしになり帳尻合わせが大変になる</strong>時空を生きて21年目の私です😢</p>
<p>実はこの間に、所属している会社のブログも1ページながら担当させていただきましたねこ!業務内容とおすすめ焼酎4選という内容なので、<br />
良かったら探してみて欲しいぎょぴ!!<br />
(さすがにネコ語は自重しましたぎょぴぼー)<br />
貴重な経験をさせてくださった弊社の担当者様、ありがとうございますにゃー!</p>
<p>久しぶりの投稿ということで前置きが長くなってしまいましたが、<br />
<strong>今回は自宅で特定の通信がハングアップしてしまったときのこと</strong>を綴りますぴょん。<br />
※解決法とういうよりは、ハチャメチャに慌ててる私をご覧いただく記事となります。</p>
<hr />
<h4 id="v目次にゃv"><a href="#v%E7%9B%AE%E6%AC%A1%E3%81%AB%E3%82%83v">v目次にゃv</a></h4>
<p>1.今回起こった問題<br />
2.一旦バックグラウンド<br />
3.対処1<br />
4.対処2<br />
5. 切り分け<br />
6. 今回の件から私が得るべき教訓は…<br />
7. エンドタイトル</p>
<hr />
<h4 id="今回起こった問題"><a href="#%E4%BB%8A%E5%9B%9E%E8%B5%B7%E3%81%93%E3%81%A3%E3%81%9F%E5%95%8F%E9%A1%8C">今回起こった問題</a></h4>
<p>自宅クライアントPCからドメインでGitlabへ200MB付近の容量ファイルをgit pushすると</p>
<blockquote>
<p>error: RPC failed; curl 56 Recv failure: Connection was reset<br />
fatal: The remote end hung up unexpectedly</p>
</blockquote>
<p>とのエラーが出てpushできない。※今回は19MBのサイズでエラー出ました<br />
どうやら<strong>サイズ制限にかかり、正常にpushできていない</strong>みたい。<br />
※ファイルサイズが小さいものは問題なくpushできます。</p>
<p>〇 5KB<br />
✖ 19MB</p>
<hr />
<h4 id="一旦バックグラウンド"><a href="#%E4%B8%80%E6%97%A6%E3%83%90%E3%83%83%E3%82%AF%E3%82%B0%E3%83%A9%E3%82%A6%E3%83%B3%E3%83%89">一旦バックグラウンド</a></h4>
<p>唐突ですが、当時の自宅の簡単な構成を…<br />
<a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f062177aebea260.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f062177aebea260.png?mw=700" alt="image.png" /></a></p>
<p>Windowsサーバより外の構成は私関与していなかったので、聞き伝えでの図ですが…<br />
今回、外部からWebサーバにアクセスできるように<strong>buffaloルータでポート開放</strong>されていますうさぎ~。</p>
<p>また、CentOS内部では、80番ポートはプロジェクト管理ソフトWebGUIへ(Apache)<br />
GitLabはパッケージ内包のNginxで動いています。<br />
<strong>hoge/projects</strong>と<strong>hoge/gitlab</strong>で<strong>サブディレクトリ</strong>にして、<strong>Apaceでリバースプロキシ設定で運用</strong>していますきんぎょ~。<br />
今回アクセスする経路はドメイン指定するので<strong>1度インターネット抜けしてからLAN内にあるサーバに戻ってくる</strong>形です。(混乱する要因の1つ)<br />
この辺の詳細は省きます。わけわかランボルギーニ~(^^♪<ふんっ!ふんっ!</p>
<hr />
<h4 id="対処1"><a href="#%E5%AF%BE%E5%87%A6%EF%BC%91">対処1</a></h4>
<p>原因を調べたところ、GItLab側(Nginx)で<strong>一定値を超えるものは制限</strong>をかけているらしい。(そもそも大容量通信を想定していない)<br />
早速、ネットに記載されていた対処法を試すねこ!</p>
<p>まずは<strong>クライアント側でバッファを増やす設定</strong>をするにゃ</p>
<pre><code>git config --global http.postBuffer 524288000
</code></pre>
<p>次に<strong>サーバ側のGitlabのサイズ制限を変更す</strong>るために、Nginxのconfigに追記するぎょぴぼー。</p>
<pre><code>client_max_body_size 200M
</code></pre>
<p>その後、各ソフトとサーバーを<strong>再起動</strong>っぽ!<br />
。<br />
。<br />
。<br />
同じエラーが返ってくる…</p>
<hr />
<h4 id="対処2"><a href="#%E5%AF%BE%E5%87%A6%EF%BC%92">対処2</a></h4>
<p>根気強くネットで解決策をさがすと、”<strong>プロキシを挟まずに直でGitlabにつないだらいけた</strong>!!”との記事を発見!<br />
バックグラウンドを見ていただくと分かると思いますが、自宅構成では<br />
<strong>クライアントからGitlabに行く際に、リバースプロキシを介しています</strong>。<br />
しかし、リバースプロキシを使わないと、Gitlabかプロジェクト管理GUIのどちらか一方しかアクセス出来なくなりますぴょん…<br />
もちろん、URLでポート指定すればよいのですが、ユーザ側の負担が増えるため却下ですにゃ…<br />
というか、そもそも<strong>Apacheにデフォルトでサイズ制限はない</strong>らしい!!(もしかしたらという事もあるので一応設定をいろいろ試しました)</p>
<hr />
<h4 id="切り分け"><a href="#%E5%88%87%E3%82%8A%E5%88%86%E3%81%91">切り分け</a></h4>
<p>ここまで、サーバ側、もしくはクライアントの設定を疑い試行錯誤してきましたが、一向に解決しないため、<br />
サーバ内だけでなく全体を見て切り分けを行いましたきんぎょ。<br />
通常なら切り分けを最初にするべきですが、ネット上に同じ問題に直面している方がおり、<br />
さらに解決策まで載っているという事で<strong>先入観を持ってしまったのが私の敗因</strong>ですねこ…</p>
<p>まずはリバースプロキシが原因かどうかを確認するため、<br />
新しくテスト仮想サーバをつくり、Gitlabだけ構築します。<br />
Gitlabは設定を変更せず、リポジトリだけ作成し、大容量push時にエラーを返す状態を再現します。<br />
ドメインを紐づけるのはめんどくさかったので、プライベートIPで開くようにしました。</p>
<p>↓リポジトリパス↓</p>
<blockquote>
<p>http:\192.168.100.101/gitlab/piyopiyo.git</p>
</blockquote>
<pre><code>###push 結果↓
〇 5KBのデータ ←小さいファイルはOKですね
〇 19MBのデータ ←え!?pushできた!!!!
</code></pre>
<p>ということは、<strong>GitlabやNginxは問題なし</strong>。リバースプロキシが怪しい…<br />
前段階でリバースプロキシは違うと踏んでただけに驚きました。</p>
<p>より本番環境に近い(外部からのアクセス)挙動も確認したいので、一応ドメインとIPを紐づける(もちろん本番環境のIPは重複を避け変更しておく)<br />
クライアント側でリポジトリのパスをドメイン指定に変更<br />
↓リポジトリパス↓</p>
<blockquote>
<p>http:\hogehoge.nk/gitlab.piyopiyo.git</p>
</blockquote>
<pre><code>###push 結果↓
〇 5KBのデータ ←小さいファイルはOK
✖ 19MBのデータ ←あれ、いつものエラーで通らない…💦
</code></pre>
<p>小さいファイルは通っているのでDNSの根本的な間違えはなさそう…<br />
今回はリバースプロキシは設定していないので、リバースプロキシのせいでエラーが出るわけではなさそう<br />
もしや、<strong>wanを抜ける過程で失敗している</strong>??</p>
<hr />
<p>テスト仮想サーバを閉じ、本番サーバのIPとドメインを紐づけ直して再度検証</p>
<pre><code>###push 結果↓
〇 5KBのデータ ←小さいのは通った!
✖ 19MBのデータ ←通らない
</code></pre>
<p>この場合、以下の2つ範囲で考えることが出来ますね。<br />
<strong>①プロバイダ側で何かしら制限がある(これだったらお手上げです😢)<br />
②自分の管轄範囲のNWで問題がある</strong></p>
<p><del><strong>想定できる原因</strong></del><br />
<del>・大容量通信は弾いている<br />
→Youtube等の大容量のデータはup,down共に正常に疎通可能。おそらく違う。</del></p>
<p><del>・特定プロトコルの大容量データを弾いている<br />
→gitの仕様詳細まで分からず、未検証。(今回はサイズによらずHTTPを使っているはず)</del></p>
<p><del>・十分な帯域が確保できず、通信量を絞っている<br />
→サーバ側のタイムアウト時間も延長したがダメ</del></p>
<p>Lanでは繋がり、Wanでは繋がらない(小さいデータは繋がるが)という事で、私の手が届く1番Wan側のbuffaloルータを詳しく見てみます。<br />
設定を覗いた感じ、QoSが設定してあるわけでもなく、問題はなさそう。<br />
<strong>機器固有の設定は不明</strong>なので、我が家にある<strong>FortiGateに置き換えることにした</strong>にゃ!<br />
<a href="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0621774bb13a10.png" target="_blank" rel="nofollow noopener"><img src="https://crieit.now.sh/upload_images/c8e3813e38831a16492d64162853d8f0621774bb13a10.png?mw=700" alt="image.png" /></a><br />
ついでなので、セグメント別けしました。(NW図の構成が甘くてすみません)</p>
<p>FortiGateの設定を行い、接続確認をしました。<br />
↓リポジトリパス↓</p>
<blockquote>
<p>http:\hogehoge.nk/gitlab.piyopiyo.git</p>
</blockquote>
<pre><code>###push 結果↓
〇 5KBのデータ ←小さいファイルはOK
〇 19MBのデータ ←無事に通った!
</code></pre>
<p><strong>通常利用が想定されるWanを介しての大小データのpushに成功したのにゃ!!</strong></p>
<hr />
<h4 id="今回の件から私が得るべき教訓は…"><a href="#%E4%BB%8A%E5%9B%9E%E3%81%AE%E4%BB%B6%E3%81%8B%E3%82%89%E7%A7%81%E3%81%8C%E5%BE%97%E3%82%8B%E3%81%B9%E3%81%8D%E6%95%99%E8%A8%93%E3%81%AF%E2%80%A6">今回の件から私が得るべき教訓は…</a></h4>
<p>まずは、今回、問題解決に至るまでのネックポイント<br />
・ネット記事に、同一サーバにWebサーバを同時導入(リバースプロキシ使用)例が少ない<br />
・GitHubの方がユーザが多くGitlabはどちらかといえば少数派なため、なぜかGithubの記事に案内される<br />
・Hyper-vよりDockerを使用している例が多いため、解決法がマッチしない<br />
・buffaloルータの仕様を理解できていない</p>
<p>以上を踏まえ、<strong>今回の件から私が得るべき教訓は、全体を見て切り分けをしっかりしよう!ということだ。</strong></p>
<p>↓今回の切り分け例↓<br />
<strong>サーバサイド</strong><br />
・リバースプロキシがおかしい<br />
・Gitlabがおかしい<br />
・Nginxがおかしい<br />
・ポートやファイアウォールの設定がうまく機能していない<br />
<strong>その他物理</strong><br />
・クライアントの設定ミス<br />
・物理機器の故障、謎仕様<br />
<strong>ネットワークサイド</strong><br />
・Wan側がおかしい<br />
・Lan側がおかしい<br />
・NW境界部がうまく機能していない</p>
<p>てっきりサーバ側だと思い込んでそちらばかり対応にあたったのがダメでした。<br />
今回は<strong>ネットワークサイド、NW境界部(buffaloルータの仕様なのかな?)があたり</strong>でしたね…<br />
結局、最たる原因は仕様が不明のため、buffaloさんには問い合わせて回答をいただく予定です。</p>
<h4 id="エンドタイトル"><a href="#%E3%82%A8%E3%83%B3%E3%83%89%E3%82%BF%E3%82%A4%E3%83%88%E3%83%AB">エンドタイトル</a></h4>
<p>今回は個人的にいろいろな事象が複雑に面倒くさく絡まっていたのが、解決への道を妨げるものでした。<br />
リソースの関係上仕方がないとはいえ、シンプルな設計の重要さを身をもって学びました。み〇ほ銀行のジャングルシステムがいい例ですね。いや、悪い例か…<br />
複雑なものをどのようにまとめようか思考しながら筆をとった結果、語尾も中途半端になる始末…(しかも非常に読みづらくて申し訳ない)</p>
<p>今回はここまで🐾<br />
自宅にて、焼酎のお湯割りを飲みながら…。</p>
<p>次回も頑張るきんぎょー…</p>
<h5 id="編集後記"><a href="#%E7%B7%A8%E9%9B%86%E5%BE%8C%E8%A8%98">編集後記</a></h5>
<p>私のCrieit記事では、私個人の思ったことや考えを色濃く記事に出しています。qiitaやStack Overflowのような解決を求める記事や、参考となる記事とは違い、実際に困難(?)に直面しているへっぽこ技術者の狭い視野やドキドキを臨場感のある雰囲気を含め楽しんで屍を越えて下されば幸いです。</p>
<p>せっかくなので、次回あたりFortiGateの設定などもご紹介できればよいですにゃ~…</p>
keito_woood