ソースコード をちゃんと管理 バージョン管理システム gitlab を 導入 commit04
ソースコード をしっかり管理するために バージョン管理システム の gitlab を 導入 します。 commit04 では serviceの内容を見ていきます。
前回は私がよく使用するserviceの設定項目についてご紹介しました。
ソースコード をちゃんと管理 バージョン管理システム gitlab を 導入 commit03
それでは今回しようした設定項目を見ていきます。
gitlab-data
このサービスはgitlab本体のストレージの役割を果たします。
Dockerはコンテナを削除するとデータもろとも消えてしまいます。
そのためデータを格納するためだけのData Volume Container(ストレージ)を作成することがDockerでの定石となっています。
gitlab-dataのサービスは以下のような設定になっています。
gitlab-data:
image: library/busybox:latest
volumes:
- ./gitlab/config:/etc/gitlab
- ./gitlab/logs:/var/log/gitlab
- ./gitlab/data:/var/opt/gitlab
networks:
- work
logging:
driver: "json-file"
options:
max-size: "100m"
max-file: "3"image
DockerイメージはDockerHub公式のbusyboxイメージを使用しました。
busyboxというのはものすごく小さなLinuxです。
なんでbusyboxを使用するのかというと・・・実は私にもわかりません(笑
別にubuntuでもいいらしいですがDockerの設計におけるイデオムみたいなものでしょうか？
volumes
この項目では、どの「ホストのフォルダ」と「コンテナのフォルダ」を結びつけるのかを定義します。
「マウント」という言葉を使うのでしょうかね？
例えば、 - ./gitlab/config:/etc/gitlab と定義すると
ホスト側のgitlab/configフォルダとコンテナ側の/etc/gitlabフォルダが紐づけられます。
ホスト側のフォルダにaaa.txtを放り込むとコンテナ側のフォルダにaaa.txtが出現するわけですね。
この項目で紐づけられたフォルダは永遠に残ります！(もちろん削除もできます。)
今回は「設定フォルダ」「ログフォルダ」「オプションフォルダ」の3つを永続化しました。
これでバックアップしたファイルを取得したりログファイルを容易に管理できるようになります。
networks
どのネットワークに参加するのか、という設定になります。
この設定をしなくてもdocker-composeが勝手にネットワークを構成して参加するので良いのですが・・・
勝手にネットワークを構成されるとたまに物理ネットワークと衝突することがあります。
ということで事前にworkというネットワークに参加します。
logging
ログの設定ですね。Dockerはデフォルトでjson形式のログを出力します。
しかも無尽蔵に！！！！
無尽蔵は困るのでファイルの最大サイズ(100MB)と最大本数(3本)を指定しました。
これでログは最大300MBにしかならないので安心です。
明日はgitlabの設定を見ていきます。
今日はここまで！