ソースコード をちゃんと管理 バージョン管理システム gitlab を 導入 commit02

ソースコード をしっかり管理するために バージョン管理システム の gitlab を 導入 します。 commit02 では 前回定義したdocker-composeファイルの解説を行います。

前回gitlab本体の定義をささっと行いました。

ソースコード をちゃんと管理 バージョン管理システム gitlab を 導入 commit01

よく見ると構文誤りがあったので修正し、もう一度掲載します。

version : "3.8"
services:
# GitLabのデータボリュームコンテナ
    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"
# GitLab系
    gitlab:
        image: gitlab/gitlab-ee:14.1.0-ee.0
        restart: always
        volumes_from:
            - gitlab-data
        expose: 
            - "80"
        ports:
            - "80:80"
        mem_limit: 4g
        environment:
            GITLAB_OMNIBUS_CONFIG: |
              external_url 'https://git.ik-genety.com'
              gitlab_rails['time_zone'] = 'Asia/Tokyo'
              alertmanager['flags'] = {'cluster.advertise-address' => '127.0.0.1:9094'}
        networks:
            - work
        logging:
            driver: "json-file"
            options:
                max-size: "100m"
                max-file: "3"
    
# ネットワーク定義
networks:
    work:
        external: true

# docker network create -d bridge -subnet=172.100.100.0/24 work

version

version : "3.8"

docker-composeで使用するファイルのフォーマットバージョンになります。

Dockerエンジンのバージョンによって使用できるversionが異なります。

Compose file | Docker Documentation

versionによってdocker-composeファイルの構文が異なったりしてエラーになったりするので注意が必要です。

最新のversionは3.8(3.9?)のようですね。

sevices

docker-compseではアプリケーション(コンテナ)をserviceという単位で管理しています。

servicesはその親分です。このservices配下に定義したserviceが1つのグループとなるわけです。

このセクションがdocker-composeファイルの要だったりします。

今回、serviceとして定義したのはgitlab-dataとgitlabになります。
またこの名前が「サービス名」となります。docker-composeでの管理はこのサービス名で行います。
名前は半角英数字であれば任意の名前を付けても問題ありません。

つまり2つのserviceを1つのグループとしてdocker-composeで管理し動作させるのです。
Dockerだけこれらを管理しようとするととても大変です😅

gitlab-dataはgitlabのデータを保管するためだけの単純なserviceです。
gitlabは今回の目玉serviceですね。gitlabの定義でgitlab-dataという文字列が出てきてますよね？
このようにdocker-compose内では各サービス間ではサービス名で認識できます。

gitlab-dataとgitlabはDockerHubにアップロードされている公式のDockerImageを使用しています。

services:
# GitLabのデータボリュームコンテナ
    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"
# GitLab系
    gitlab:
        image: gitlab/gitlab-ee:14.1.0-ee.0
        restart: always
        volumes_from:
            - gitlab-data
        expose: 
            - "80"
        ports:
            - "80:80"
        mem_limit: 4g
        environment:
            GITLAB_OMNIBUS_CONFIG: |
              external_url 'https://git.ik-genety.com'
              gitlab_rails['time_zone'] = 'Asia/Tokyo'
              alertmanager['flags'] = {'cluster.advertise-address' => '127.0.0.1:9094'}
        networks:
            - work
        logging:
            driver: "json-file"
            options:
                max-size: "100m"
                max-file: "3"

networks

# ネットワーク定義
networks:
    work:
        external: true

ネットワークのエイリアス名になります。
今回は事前に`docker network create -d bridge -subnet=172.100.100.0/24 work`というコマンドを実行してdockerに仮想ネットワークを作成しようと思います。
このネットワークにdocker-composeで定義されたserviceは参加するわけです。

このようなことをしなくても、デフォルトでdocker-composeは「docker-composeファイル単位で」仮想のネットワークを自動作成します。
そして作成されたネットワークに参加するわけです。
これでもよいのですがdocker-composeファイルが多くなってくると仮想ネットワークも増えていきます。
これが原因で物理ネットワークとかぶってしまい問題発見にかなりはまってしまった経験から毎回自分で定義するようにしました。

workというネットワーク内ではサービス名で各サービスはほかのサービスを認識できます。
逆に言うとwork内ではサービス名はかぶってはいけないということです。

 

次回はserviceの内容に迫ってみたいと思います。

今日はここまで！

Docker,バージョン管理,ミドルウェア,環境構築Docker,git,gitlab,バージョン管理

Posted by raika@blog