「GitLab」の記事 - Crieit

DockerとKubernetes

2022-05-04T05:16:16+09:00

0 前提

Oracle LinuxとWindows

1 環境構築

準備

1-1 Dockerオフラインインストール

参考にしたURLはhttps://qiita.com/kod314/items/e574ac12c23598e0d903。
オンラインインストールの場合は、
https://qiita.com/kichise/items/f8e56c6d2d08eaf4a6a0
の手順に従えば可能。

今回はオフラインインストールを実行しようと思う。社内規則によりDockerをインストールするサーバがインターネット接続できない場合がある。その場合、インターネット接続できる自席端末からネットに接続してDockerのインストーラーをダウンロード。それをDockerをインストールしたいサーバに転送して実行させる。

1-1-1 OS確認

まずはOSのversionを確認。

$ uname -a
Linux publicpc1 5.4.17-2136.305.5.3.el8uek.x86_64 #2 SMP Thu Mar 17 10:45:33 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux

より詳細

#cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5

Linuxカーネルの確認

$ hostnamectl
Static hostname: publicpc1
Icon name: computer-vm
Chassis: vm
Machine ID: 4c3dc5bfa43b47b8b66789ce778a0711
Boot ID: 226a196eedc746e2848a6f15e9afeb0b
Virtualization: kvm
Operating System: Oracle Linux Server 8.5
CPE OS Name: cpe:/o:oracle:linux:8:5:server
Kernel: Linux 5.4.17-2136.305.5.3.el8uek.x86_64
Architecture: x86-64

x86_64と記載されているので、Intel(AMD)の64bitオペレーティングシステムであることがわかる。

1-1-2 Docker engineをインストール

Docker本体であるDocker Engineと、同時に複数のコンテナを操作するツールであるDocker Composeをダウンロードする。
参考にした公式：https://docs.docker.com/engine/install/binaries/

まずはdocker本体
https://download.docker.com/linux/static/stable/x86_64/
→バージョンがいろいろあるので、最新のdocker-20.10.9.tgz をダウンロードしてみた。
自分の端末(クライアント側にダウンロードしたファイルをLinuxサーバに転送してから解凍する。

$ ls -al /home/opc/docker-20.10.9.tgz
-rw-r--r--. 1 opc opc 63350495 May  4 04:23 /home/opc/docker-20.10.9.tgz

展開

$ tar zxvf docker-20.10.9.tgz

すると、カレントディレクトリにdockerディレクトリが作成される。
dockerディレクトリの中身を/usr/bin/配下にコピーする。

$ sudo cp docker/* /usr/bin/

試しに起動するには

$ sudo dockerd &

1-1-3 Docker Composeをインストール

続いてはdocker-compose
インストール手順は以下に記載されているので以降この指示に従う。
https://github.com/docker/compose/blob/v2/README.md

さきほど(1-1-1節)でOSとCPUを確認したので、
それに従ってdocker-compose-linux-x86_64をダウンロードする。
https://github.com/docker/compose/releases

自分のwindows端末(クライアント側）にダウンロードしたdocker-compose-linux-x86_64をdockerをインストールしたLinuxサーバに転送。
転送したら、バイナリファイルの名前をdocker-composeにリネーム。

$ mv docker-compose-linux-x86_64 docker-compose

docker-composeをいどうする。移動する先は目的に応じて移動先が異なる。
今回は

$ sudo mv docker-compose /usr/local/bin/
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose -v
Docker Compose version v2.5.0

1-1-4 Docker イメージのオフラインで利用する

$ tar zxvf helloworld_img.tar.gz
$ docker load < helloworld_img # dockerイメージをload
$ docker images # hello-worldイメージが存在することを確認

1-1-5 Dockerグループ作成

Docker daemonはrootユーザで実行しなければならず、毎回sudoを使うのは面倒である。
その場合、dockerグループを作成してそこに任意のユーザを所属させてあげる。

groupadd docker
usermod -aG docker opc

1-1-6 トラブルシュート

docklerをサービスでenebleにしようと思ったができなかった。

[root@publicpc1 system]# systemctl enable docker
Failed to enable unit: Unit file docker.service does not exist.

以下のサイトを参考に対応してみた。
https://jhooq.com/docker-daemon-centos/

/usr/lib/systemd/system配下にdocker.socketファイルを作成し以下の内容を記載した。

[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

続いて、/usr/lib/systemd/system/配下にdocker.serviceを作成する。

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service

[Service]
Type=notify
#the default is not to use systemd for cgroups because the delegate issues still
#exists and systemd currently does not support the cgroup feature set required
#for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

#Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
#Both the old, and new location are accepted by systemd 229 and up, so using the old location
#to make them work for either version of systemd.
StartLimitBurst=3

#Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
#Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
#this option work for either version of systemd.
StartLimitInterval=60s

#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

#Comment TasksMax if your systemd version does not support it.
#Only systemd 226 and above support this option.
TasksMax=infinity

#set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

#kill only the docker process, not all processes in the cgroup
KillMode=process
OOMScoreAdjust=-500

[Install]
WantedBy=multi-user.target

この中身をみるとRequires=docker.socket containerd.serviceと記載されている通り、containerd.serviceが必要。なので/usr/lib/systemd/system配下にcontainerd.serviceサービスを作成する必要がある。

#Copyright The containerd Authors.
#Licensed under the Apache License, Version 2.0 (the "License");
#you may not use this file except in compliance with the License.
#You may obtain a copy of the License at
#http://www.apache.org/licenses/LICENSE-2.0
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an "AS IS" BASIS,
#WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#See the License for the specific language governing permissions and
#limitations under the License.

[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd

Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=infinity
#Comment TasksMax if your systemd version does not supports it.
#Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target

上記を作成する。

ちゃんとリロードしとく。

systemctl daemon-reload

1-2.Kubernetesの準備

1-2-1. インストール

オフライン環境でKubernetesを構築する手順。
手順の参考にしたのは以下
https://docs.genesys.com/Documentation/GCXI/latest/Dep/DockerOffline

まずはネットにつながる端末から

$ pwd
/etc/yum.repos.d
$ cat kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

以下のコマンドを実行してファイルをダウンロード。
の部分は自分で適当なディレクトリを作成して
そこのパスを指定。

yumdownloader --assumeyes --destdir= --resolve yum-utils kubeadm-1.21.* kubelet-1.21.* kubectl-1.21.* ebtables

続いて、ダウンロードしたファイルをインストールしていく。

yum install -y --cacheonly --disablerepo=* /*.rpm

インストールする際、バージョンが異なるファイルが存在してインストールエラーになるかもしれない。
その場合は、必要のないバージョンのファイルは削除してから
再度インストールするとうまくいく。
うまくいくと以下のようになる。

Complete!

必要なイメージが揃っているか確認してみよう。

$ kubeadm config images list
I0504 23:15:36.977910  309762 version.go:254] remote version is much newer: v1.24.0; falling back to: stable-1.21
k8s.gcr.io/kube-apiserver:v1.21.12
k8s.gcr.io/kube-controller-manager:v1.21.12
k8s.gcr.io/kube-scheduler:v1.21.12
k8s.gcr.io/kube-proxy:v1.21.12
k8s.gcr.io/pause:3.4.1
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/coredns/coredns:v1.8.0

1-2-2. kubectlの概要

参考URL:https://kubernetes.io/ja/docs/reference/kubectl/_print/
Kubernetesクラスタを操作するコマンド

2.Docker入門

【障害切り分けのコツはまずは森を見ること！】Gitlabのpushエラー、原因は（恐らく？）buffalo製ルータだった話

2022-02-24T23:29:56+09:00

お久しぶりですにゃ。
やらなきゃいけない事があるからと、”優先度の低いものをする時間をマストタスクに割り当てよう”と考えながら
、結局マスト作業も先延ばしになり帳尻合わせが大変になる時空を生きて21年目の私です😢

実はこの間に、所属している会社のブログも1ページながら担当させていただきましたねこ！業務内容とおすすめ焼酎４選という内容なので、
良かったら探してみて欲しいぎょぴ！！
（さすがにネコ語は自重しましたぎょぴぼー）
貴重な経験をさせてくださった弊社の担当者様、ありがとうございますにゃー！

久しぶりの投稿ということで前置きが長くなってしまいましたが、
今回は自宅で特定の通信がハングアップしてしまったときのことを綴りますぴょん。
※解決法とういうよりは、ハチャメチャに慌ててる私をご覧いただく記事となります。

v目次にゃv

1.今回起こった問題
2.一旦バックグラウンド
3.対処１
4.対処２
5. 切り分け
6. 今回の件から私が得るべき教訓は…
7. エンドタイトル

今回起こった問題

自宅クライアントPCからドメインでGitlabへ200MB付近の容量ファイルをgit pushすると

error: RPC failed; curl 56 Recv failure: Connection was reset
fatal: The remote end hung up unexpectedly

とのエラーが出てpushできない。※今回は19MBのサイズでエラー出ました
どうやらサイズ制限にかかり、正常にpushできていないみたい。
※ファイルサイズが小さいものは問題なくpushできます。

〇　5KB
✖　19MB

一旦バックグラウンド

唐突ですが、当時の自宅の簡単な構成を…

Windowsサーバより外の構成は私関与していなかったので、聞き伝えでの図ですが…
今回、外部からWebサーバにアクセスできるようにbuffaloルータでポート開放されていますうさぎ～。

また、CentOS内部では、80番ポートはプロジェクト管理ソフトWebGUIへ（Apache）
GitLabはパッケージ内包のNginxで動いています。
hoge/projectsとhoge/gitlabでサブディレクトリにして、Apaceでリバースプロキシ設定で運用していますきんぎょ～。
今回アクセスする経路はドメイン指定するので1度インターネット抜けしてからLAN内にあるサーバに戻ってくる形です。（混乱する要因の1つ）
この辺の詳細は省きます。わけわかランボルギーニ～(^^♪＜ふんっ！ふんっ！

対処１

原因を調べたところ、GItLab側（Nginx）で一定値を超えるものは制限をかけているらしい。（そもそも大容量通信を想定していない）
早速、ネットに記載されていた対処法を試すねこ！

まずはクライアント側でバッファを増やす設定をするにゃ

git config --global http.postBuffer 524288000

次にサーバ側のＧitlabのサイズ制限を変更するために、Nginxのconfigに追記するぎょぴぼー。

client_max_body_size 200M

その後、各ソフトとサーバーを再起動っぽ！
。
。
。
同じエラーが返ってくる…

対処２

根気強くネットで解決策をさがすと、”プロキシを挟まずに直でGitlabにつないだらいけた！！”との記事を発見！
バックグラウンドを見ていただくと分かると思いますが、自宅構成では
クライアントからGitlabに行く際に、リバースプロキシを介しています。
しかし、リバースプロキシを使わないと、Gitlabかプロジェクト管理GUIのどちらか一方しかアクセス出来なくなりますぴょん…
もちろん、URLでポート指定すればよいのですが、ユーザ側の負担が増えるため却下ですにゃ…
というか、そもそもApacheにデフォルトでサイズ制限はないらしい！！（もしかしたらという事もあるので一応設定をいろいろ試しました）

切り分け

ここまで、サーバ側、もしくはクライアントの設定を疑い試行錯誤してきましたが、一向に解決しないため、
サーバ内だけでなく全体を見て切り分けを行いましたきんぎょ。
通常なら切り分けを最初にするべきですが、ネット上に同じ問題に直面している方がおり、
さらに解決策まで載っているという事で先入観を持ってしまったのが私の敗因ですねこ…

まずはリバースプロキシが原因かどうかを確認するため、
新しくテスト仮想サーバをつくり、Gitlabだけ構築します。
Gitlabは設定を変更せず、リポジトリだけ作成し、大容量push時にエラーを返す状態を再現します。
ドメインを紐づけるのはめんどくさかったので、プライベートIPで開くようにしました。

↓リポジトリパス↓

http:\192.168.100.101/gitlab/piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOKですね
〇　19MBのデータ　←え！？pushできた！！！！

ということは、GitlabやNginxは問題なし。リバースプロキシが怪しい…
前段階でリバースプロキシは違うと踏んでただけに驚きました。

より本番環境に近い（外部からのアクセス）挙動も確認したいので、一応ドメインとIPを紐づける（もちろん本番環境のIPは重複を避け変更しておく）
クライアント側でリポジトリのパスをドメイン指定に変更
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
✖　19MBのデータ　 ←あれ、いつものエラーで通らない…💦

小さいファイルは通っているのでDNSの根本的な間違えはなさそう…
今回はリバースプロキシは設定していないので、リバースプロキシのせいでエラーが出るわけではなさそう
もしや、wanを抜ける過程で失敗している？？

テスト仮想サーバを閉じ、本番サーバのIPとドメインを紐づけ直して再度検証

###push 結果↓
〇　5KBのデータ　　←小さいのは通った！
✖　19MBのデータ　 ←通らない

この場合、以下の2つ範囲で考えることが出来ますね。
①プロバイダ側で何かしら制限がある（これだったらお手上げです😢）
②自分の管轄範囲のNWで問題がある

~~想定できる原因~~
・大容量通信は弾いている
　→Youtube等の大容量のデータはup,down共に正常に疎通可能。おそらく違う。

・特定プロトコルの大容量データを弾いている
　→gitの仕様詳細まで分からず、未検証。（今回はサイズによらずHTTPを使っているはず）

・十分な帯域が確保できず、通信量を絞っている
　→サーバ側のタイムアウト時間も延長したがダメ

Lanでは繋がり、Wanでは繋がらない（小さいデータは繋がるが）という事で、私の手が届く1番Wan側のbuffaloルータを詳しく見てみます。
設定を覗いた感じ、QoSが設定してあるわけでもなく、問題はなさそう。
機器固有の設定は不明なので、我が家にあるFortiGateに置き換えることにしたにゃ！

ついでなので、セグメント別けしました。（NW図の構成が甘くてすみません）

FortiGateの設定を行い、接続確認をしました。
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
〇　19MBのデータ　 ←無事に通った！

通常利用が想定されるWanを介しての大小データのpushに成功したのにゃ！！

今回の件から私が得るべき教訓は…

まずは、今回、問題解決に至るまでのネックポイント
・ネット記事に、同一サーバにWebサーバを同時導入（リバースプロキシ使用）例が少ない
・GitHubの方がユーザが多くGitlabはどちらかといえば少数派なため、なぜかGithubの記事に案内される
・Hyper-vよりDockerを使用している例が多いため、解決法がマッチしない
・buffaloルータの仕様を理解できていない

以上を踏まえ、今回の件から私が得るべき教訓は、全体を見て切り分けをしっかりしよう！ということだ。

↓今回の切り分け例↓
サーバサイド
・リバースプロキシがおかしい
・Gitlabがおかしい
・Nginxがおかしい
・ポートやファイアウォールの設定がうまく機能していない
その他物理
・クライアントの設定ミス
・物理機器の故障、謎仕様
ネットワークサイド
・Wan側がおかしい
・Lan側がおかしい
・NW境界部がうまく機能していない

てっきりサーバ側だと思い込んでそちらばかり対応にあたったのがダメでした。
今回はネットワークサイド、NW境界部（buffaloルータの仕様なのかな？）があたりでしたね…
結局、最たる原因は仕様が不明のため、buffaloさんには問い合わせて回答をいただく予定です。

エンドタイトル

今回は個人的にいろいろな事象が複雑に面倒くさく絡まっていたのが、解決への道を妨げるものでした。
リソースの関係上仕方がないとはいえ、シンプルな設計の重要さを身をもって学びました。み〇ほ銀行のジャングルシステムがいい例ですね。いや、悪い例か…
複雑なものをどのようにまとめようか思考しながら筆をとった結果、語尾も中途半端になる始末…（しかも非常に読みづらくて申し訳ない）

今回はここまで🐾
自宅にて、焼酎のお湯割りを飲みながら…。

次回も頑張るきんぎょー…

編集後記

私のCrieit記事では、私個人の思ったことや考えを色濃く記事に出しています。qiitaやStack Overflowのような解決を求める記事や、参考となる記事とは違い、実際に困難（？）に直面しているへっぽこ技術者の狭い視野やドキドキを臨場感のある雰囲気を含め楽しんで屍を越えて下されば幸いです。

せっかくなので、次回あたりFortiGateの設定などもご紹介できればよいですにゃ～…