docker-composeでgitlab運用するメモ。
初めて使ったときはまだcentos動いててdockerも使ってなくて、仮想マシンを１つ作ってインストールしてた。
その後、地味にgitの練習したっけ。
今じゃソース管理だけじゃなく、この文章とか普段利用してるドキュメント類の維持管理で使わせてもらってる。
コマンドライン使うことはなくなってvscodeで書いてはcommitし、google cloudに持っていってpushしてる。
dockerで動かしてて、年に１回はgitlabコンテナを作り直してるのでそのメモ。
gitlabをdockerコンテナで使う
いつもどおり、失敗しても何度でも作り直せる。
バージョン狙い撃ちして使える。
dockerhubに公開ページがあって、今の最新だけじゃなく履歴を教えてくれる。
ここでdocker-compose.ymlにタグ指定で使うバージョン番号を確認する。
docker-compose.yml用意する
今年使ってる分の定義。
全体定義はこのへんにある。
SVgitlab2022:
image: gitlab/gitlab-ce:14.6.3-ce.0
ports:
- 10881:80
volumes:
- ./nariDockerDat/sv_gitlab2022/config:/etc/gitlab
- ./nariDockerDat/sv_gitlab2022/logs:/var/log/gitlab
- ./nariDockerDat/sv_gitlab2022/data:/var/opt/gitlab
来年用の定義。バージョンを今の最新に近いのにして、データ置き場もカラにして用意しておく。
SVgitlab2023:
image: gitlab/gitlab-ce:15.7.0-ce.0
ports:
- 10880:80
volumes:
- ./nariDockerDat/sv_gitlab2023/config:/etc/gitlab
- ./nariDockerDat/sv_gitlab2023/logs:/var/log/gitlab
- ./nariDockerDat/sv_gitlab2023/data:/var/opt/gitlab
公開ポート番号は、10880/10881を毎年交互に使う。
毎年1月だけ新旧gitlabを同時に動かす。
必要なブランチが移設できたら古い方のgitlabコンテナとイメージを潰して、永続化領域も削除。
書き足したらdocker-compose up -dしとく。
vscodeのgitgraphから見たら必要ないブランチもあるから、全部のプロジェクトではやらんけど、今年からプロジェクトのエクスポート・インポートをやってみる。
履歴は1年程度見えてくれたらええんやけど、ちゃんとできるやろか。
管理者でログイン
コンテナ起動できたらrootのパスワードを探す。
５０文字弱ぐらいの文字列が入ってる。
今年からこれメモったから探さなくてすむ。
sudo docker exec -it (コンテナ) grep 'Password:' /etc/gitlab/initial_root_password
見つけたパスワードを使ってrootでログインする。
全部が翻訳されてるわけじゃないけど、全体設定を日本語にしていったんログアウト。
ログイン画面に戻ってregistから利用者登録リクエストを出しとく。
もう１回ログインして、左上にあるメニューから「管理者」選ぶ。
「最新のユーザを表示」から開く。
LDAP使えるんやなぁ。
利用者管理を一元化できるってことか。
そしたら「承認保留中」になった利用者が見える。
２ファクタ認証使えるんやなぁ。いらんけど。
ユーザ選んで右上にある「承認する」を選んどく。
プロジェクトをエクスポート
来年に引き継ぎたい今年のプロジェクトデータをエクスポートする。
プロジェクトを選んでおいて、左のほうにある縦のアイコンの一番下の歯車アイコンをクリックして「高度な設定」を展開する。
エクスポートするデータを作るみたいで、ボタンは１つしかない。
エクスポートするデータができたら２つ押せるようになってた。
やってる間CPUとディスクが15分ぐらい頑張ってた。
終わったら普通にダウンロードする。
去年作ったdjangoのソースやったら2.3MBぐらいやった。
プロジェクトをインポート
来年用のプロジェクトを作っておいて、今年のプロジェクトデータをインポートする。
インポート終わってグラフ見たら、ちゃんと入ってるように見える。
ブランチもちゃんとある。
念のため、今動いてるdjangoのソースとさっきインポートしたプロジェクトのgit clone結果を比べると差分がないことを確認。
vscodeで開いて、コミット履歴とか実際の最近の追記を見るとちゃんと入ってる。
dockerhubのDIGEST
他のコンテナもそうやけど、一番上の段にDIGESTって書いた箇所がある。
gitlabにもタグ書いてあるページに記述がある。
例えばlatest(最新)のとこにd9cff32a3b87ってあったら、もうちょっと下のほう見たら同じDIGESTの箇所がある。
2022年12月末の段階では、「rc」と「15.7.0-ce.0」が同じDIGESTになってるから、指し示すモジュールがそれぞれ同じ。
作ってすぐ消す野良コンテナやったら「latest」ってタグ指定したらええけど、自分の場合はdocker-composeでバージョン指定する。
latestって書いたらdocker imagesの結果にもlatestって入るから、結局バージョンいくつのを使ってるのかわかりにくいし。
バージョンアップは年に１回やる
gitlabはrailsとpostgresqlで構成されてたと思う。
データベースは選べたかもしれんけど、postgresqlがdockerコンテナは動いてたはず。
気に入らんところはいろいろあるけど、ドキュメントは綺麗に残してくれる。
完全じゃない可能性あるからいっつもdiffとかwinmergeで比べながら使う。
機能が複雑で取り回ししにくかったり、ブラウザ画面で設定できる内容いっぱいあるとか、日本語化が中途半端とか。
思い出すのは、エコーバックがやたら多くて取り扱い面倒。docker -f logsとかやったらログがめっちゃ流れてったと思う。
なんであんないっぱい出るんか意味わからん。
細かいエラーとかユーザ管理とかはそこそこでええから、ドキュメントを維持管理してくれたらそれでええ。
脆弱性はローカルで使うだけやから後回し。
cert/jpcertにもたまにしか出てこーへん。
devopsって言葉が見えたから、jenkinsみたいなことができるんかもしれん。
pushしたらテストとかしてくれるんかもなぁ。
年に１回作り直すのは、バックエンドのdbがpostgresqlやから。
使い方やデータ量にもよるけど、postgresqlは追記型データベースやから完全なデータの削除をせん。
昔は手動やったけど、今は一定量使ったら自分でvacuumしてくれる。
windowsでいうとディスクのデフラグみたいなもので、このvacuumが勝手にスローダウンとか引き起こす。
postgresqlは便利で楽なこともあるけど、業務で扱うサーバで真っ昼間にスローダウン起こされたら「もー、バッチ処理あと5分で動き出すのに何で今やねん」とかなる。
そろそろ業務終了ってときにスローダウンしてCPU利用率とか上がって運用監視にひっかかったら「誰やpostgresql選んだヤツは！！！」ってムカつく。
自分の場合、1年使っただけでは発生しない。
もしかしたら2年でも大丈夫かもしれん。
それが3年でも5年でもええけど、1年は気持ちよく使いたい。
色々考えて、dockerコンテナを年に１回作り直しながら、gitlabの中に複数のプロジェクトを作って維持することにした。
維持する対象
写真とかデータベースは履歴を維持する必要はないけど、計画とかプログラムソースは履歴を維持したいときがある。
- ファイルサーバのファイル類
- djangoソース
- この文書
- phpソース
今年の年末で使うの終わりやから倉庫行きやけどphpも扱ってた。
履歴は修正に要した作業日数とか量とかを知りたい。
例えばdjangoソースで１つの機能実現に何日かけたとか、いくつぐらいファイル書き足したとか。
pdfをmariadbにblob保存する画面処理を作るのをいつ着手し、いつ頃完了してどのファイルをどれぐらい書いたのかとか。
phpで実現するときにどう書いてて、djangoやったらどう書いてたとか。
毎年いろんなことやってみようとするから、そのときに必死で努力して考えたことを思い出すと、その記憶や考え方は別の場面で使えることがあるもんね。
「たったこんだけやのに何でこんな時間かかってたんやろ」って一人で赤面してることもある。
人様に言えない恥ずかしいコミットとかあるなぁ。
なんで使うのか
差分バックアップを維持していきたいっていうのと、gitgraphをvscodeで見たとき「あ、先々月はこんな修正したなぁ」って少し振り返って考えるのに便利やから。
「コレできたから、次はこんなことやってみっかな」とか、テーマを考えるのにいい。
linux/docker/vscode/gitを使って、django/mariadb/ldap/djangoを維持してたら、結構な力がついてく。
まだまだ使ってくんやろなぁ。
