nginx でアクセスログを JSON フォーマットにする場合は「escape=json」を設定する

nginx で nginx.conf に access_log と log_format を設定すると，ログフォーマットをカスタマイズできる．log_format のデフォルト設定は combined だけど，ログ集計などを考慮して，JSON フォーマットに変更する場面も多いと思う．例えば，以下のように log_format を設定すると，JSON フォーマットでアクセスログを出力できる．

log_format json '{'
    '"time": "$time_local",'
    '"remote_addr": "$remote_addr",'
    '"host": "$host",'
    '"remote_user": "$remote_user",'
    '"status": "$status",'
    '"server_protocol": "$server_protocol",'
    '"request_method": "$request_method",'
    '"request_uri": "$request_uri",'
    '"request": "$request",'
    '"body_bytes_sent": "$body_bytes_sent",'
    '"request_time": "$request_time",'
    '"upstream_response_time": "$upstream_response_time",'
    '"http_referer": "$http_referer", '
    '"http_user_agent": "$http_user_agent",'
    '"http_x_forwarded_for": "$http_x_forwarded_for",'
    '"http_x_forwarded_proto": "$http_x_forwarded_proto"'
'}';

access_log /var/log/nginx/access.log json;

アクセスログに " が含まれる場合

例えば，アクセスログに " が含まれる場合，自動的に \x22 に変換されてしまう．検証として，以下のように User Agent に kakaka"kakku と設定し，nginx にリクエストを送る．

$ curl -H 'User-Agent: kakaka"kakku' http://www.example.com/

すると，以下のように出力される（アクセスログを整形している）．User Agent を http_user_agent の値で確認すると，確かに kakaka\x22kakku になっている．なお，今回は例として " で検証をしているけど，正確に言うと " 以外にも「RFC 4627」で定義された文字は変換されてしまう．

{
    "time": "22/Nov/2019:00:00:00 +0900",
    "remote_addr": "x.x.x.x",
    "host": "www.example.com",
    "remote_user": "-",
    "status": "200",
    "server_protocol": "HTTP/1.1",
    "request_method": "GET",
    "request_uri": "/",
    "request": "GET / HTTP/1.1",
    "body_bytes_sent": "0",
    "request_time": "0.000",
    "upstream_response_time": "-",
    "http_referer": "-",
    "http_user_agent": "kakaka\x22kakku",
    "http_x_forwarded_for": "x.x.x.x",
    "http_x_forwarded_proto": "http"
}

解決策 : escape=json を設定する

ドキュメントを読むと，「nginx 1.11.8（2016年12月リリース）」から使える escape パラメータを使って，escape=json を設定すると，今回の件は解決する．

nginx.org

escape=json を設定し，最終的な nginx.conf は以下のようになる．

log_format json escape=json '{'
    '"time": "$time_local",'
    '"remote_addr": "$remote_addr",'
    '"host": "$host",'
    '"remote_user": "$remote_user",'
    '"status": "$status",'
    '"server_protocol": "$server_protocol",'
    '"request_method": "$request_method",'
    '"request_uri": "$request_uri",'
    '"request": "$request",'
    '"body_bytes_sent": "$body_bytes_sent",'
    '"request_time": "$request_time",'
    '"upstream_response_time": "$upstream_response_time",'
    '"http_referer": "$http_referer", '
    '"http_user_agent": "$http_user_agent",'
    '"http_x_forwarded_for": "$http_x_forwarded_for",'
    '"http_x_forwarded_proto": "$http_x_forwarded_proto"'
'}';

access_log /var/log/nginx/access.log json;

もう1度，User Agent に kakaka"kakku と設定し，nginx にリクエストを送ると，http_user_agent の値が kakaka\"kakku となり，うまくエスケープされて出力できるようになった．なお，remote_user など，もともと値が - だった部分もブランクになっていて，ここはドキュメントには仕様が書かれてなく，理由までは追えなかった．

{
    "time": "22/Nov/2019:00:00:00 +0900",
    "remote_addr": "x.x.x.x",
    "host": "www.example.com",
    "remote_user": "",
    "status": "200",
    "server_protocol": "HTTP/1.1",
    "request_method": "GET",
    "request_uri": "/",
    "request": "GET / HTTP/1.1",
    "body_bytes_sent": "0",
    "request_time": "0.000",
    "upstream_response_time": "",
    "http_referer": "",
    "http_user_agent": "kakaka\"kakku",
    "http_x_forwarded_for": "x.x.x.x",
    "http_x_forwarded_proto": "http"
}

まとめ

nginx でアクセスログを JSON フォーマットにする場合，「nginx 1.11.8（2016年12月リリース）」から使える escape パラメータを使って，escape=json を設定する．数年前から使えるパラメータだとしても，無限に知らないことはあるし，引き続き学んだことをブログにアウトプットしていくぞ！

Dockerfile に HEALTHCHECK を設定すると「ヘルスチェック機能」が使えるようになる

今回は Docker で使える「ヘルスチェック機能」を試す．Release Note を読むと，機能としては Docker 1.12 から使えるらしく，3年前からあったなんて...！仕組みとしては，Docker デーモンからコンテナに指定したコマンドを定期的に実行する．

Dockerfile 構文

「ヘルスチェック機能」を使う場合，まず Dockerfile に HEALTHCHECK を設定する．実行するコマンド以外に以下のオプションも設定できる．注意点として，--retries 以外は秒数を指定するため，表記は 5s のように単位も付ける．

• --interval=DURATION (default: 30s)
• --timeout=DURATION (default: 30s)
• --start-period=DURATION (default: 0s)
• --retries=N (default: 3)

以下にサンプルを載せる．

HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/ || exit 1

docs.docker.com

検証用コンテナイメージ

今回は検証用コンテナイメージを「計3種類」作成した．Alpine を使うため，事前に curl をインストールしておく必要がある．

• kakakakakku/nginx:base
  • nginx:alpine に curl を追加した
• kakakakakku/nginx:ok
  • nginx:alpine に curl と HEALTHCHECK を追加した（ヘルスチェック成功）
• kakakakakku/nginx:ng
  • nginx:alpine に curl と HEALTHCHECK を追加した（ヘルスチェック失敗）

Dockerfile : kakakakakku/nginx:ok

nginx を使うため，Dockerfile に HEALTHCHECK を設定し，curl を実行する．今回は検証として，オプションは --interval=5s と --timeout=3s にした．kakakakakku/nginx:ok は，デフォルトの index.html にアクセスできるため，ヘルスチェックに成功する．

FROM nginx:alpine

RUN apk add curl

HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/ || exit 1

Dockerfile : kakakakakku/nginx:ng

kakakakakku/nginx:ng は，誤った URL に curl を実行するため「終了コード 1」となり，ヘルスチェックに失敗する．

FROM nginx:alpine

RUN apk add curl

HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/ng || exit 1

詳細は GitHub を見てもらえればと！

github.com

コンテナを起動する

コンテナを起動し，docker ps コマンドを実行すると，以下のように STATUS で「ヘルスチェック結果」を確認できる．通常は非表示だけど，今回は (healthy) と (unhealthy) が表示されている．なお，起動直後は (health: starting) という表記になっていた．

$ docker run -d -p 8000:80 --name nginx01 kakakakakku/nginx:base
$ docker run -d -p 8001:80 --name nginx02 kakakakakku/nginx:ok
$ docker run -d -p 8002:80 --name nginx03 kakakakakku/nginx:ng

$ docker ps --format "table {{.Image}}\t{{.Status}}\t{{.Names}}"
IMAGE                    STATUS                     NAMES
kakakakakku/nginx:ng     Up 3 minutes (unhealthy)   nginx03
kakakakakku/nginx:ok     Up 3 minutes (healthy)     nginx02
kakakakakku/nginx:base   Up 3 minutes               nginx01

コンテナの起動時にヘルスチェックを設定する

実は docker run コマンドのオプションでヘルスチェックを指定することもできる．よって，Dockerfile に HEALTHCHECK が設定されていなくても「ヘルスチェック機能」は使える．オプションは以下のドキュメントに載っている．

• --health-cmd
• --health-interval
• --health-retries
• --health-start-period
• --health-timeout

docs.docker.com

さっそく kakakakakku/nginx:base を使って，「ヘルスチェックに成功するコンテナ」と「ヘルスチェックに失敗するコンテナ」を起動する．すると，Dockerfile に HEALTHCHECK を記載したときと同様に STATUS に「ヘルスチェック結果」が表示された．オプションを柔軟に設定できるため，Dockerfile にベタ書きするよりも使えそう．

$ docker run -d -p 8003:80 --name nginx04 \
  --health-cmd 'curl -f http://localhost/ || exit 1' \
  --health-interval 5s \
  --health-timeout 3s \
  kakakakakku/nginx:base

$ docker run -d -p 8004:80 --name nginx05 \
  --health-cmd 'curl -f http://localhost/ng || exit 1' \
  --health-interval 5s \
  --health-timeout 3s \
  kakakakakku/nginx:base

$ docker ps --format "table {{.Image}}\t{{.Status}}\t{{.Names}}"
IMAGE                    STATUS                      NAMES
kakakakakku/nginx:base   Up 19 seconds (unhealthy)   nginx05
kakakakakku/nginx:base   Up 27 seconds (healthy)     nginx04
kakakakakku/nginx:ng     Up 11 minutes (unhealthy)   nginx03
kakakakakku/nginx:ok     Up 11 minutes (healthy)     nginx02
kakakakakku/nginx:base   Up 11 minutes               nginx01

ヘルスチェック結果でフィルタリングする

docker ps コマンドと --filter を組み合わせることにより，ヘルスチェック結果でコンテナをフィルタリングすることもできる．

$ docker ps --format "table {{.Image}}\t{{.Status}}\t{{.Names}}" --filter 'health = healthy'
IMAGE                    STATUS                    NAMES
kakakakakku/nginx:base   Up 2 minutes (healthy)    nginx04
kakakakakku/nginx:ok     Up 13 minutes (healthy)   nginx02

$ docker ps --format "table {{.Image}}\t{{.Status}}\t{{.Names}}" --filter 'health = unhealthy'
IMAGE                    STATUS                      NAMES
kakakakakku/nginx:base   Up 3 minutes (unhealthy)    nginx05
kakakakakku/nginx:ng     Up 14 minutes (unhealthy)   nginx03

docs.docker.com

ヘルスチェックログを確認する

docker inspect コマンドと --format を組み合わせることにより，ヘルスチェックログ（直近5件）を確認できる．以下はヘルスチェックに失敗した nginx03 のログとなり，curl の結果 404 で「終了コード 1」になっている（Output の結果が長く，横スクロールをする必要がある）．

$ docker inspect --format='{{json .State.Health}}' nginx03 | jq .
{
  "Status": "unhealthy",
  "FailingStreak": 242,
  "Log": [
    {
      "Start": "2019-11-21T06:22:46.3344018Z",
      "End": "2019-11-21T06:22:46.611824Z",
      "ExitCode": 1,
      "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (22) The requested URL returned error: 404 Not Found\n"
    },
    {
      "Start": "2019-11-21T06:22:51.622651Z",
      "End": "2019-11-21T06:22:51.8756001Z",
      "ExitCode": 1,
      "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (22) The requested URL returned error: 404 Not Found\n"
    },
    {
      "Start": "2019-11-21T06:22:56.8871398Z",
      "End": "2019-11-21T06:22:57.0339383Z",
      "ExitCode": 1,
      "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (22) The requested URL returned error: 404 Not Found\n"
    },
    {
      "Start": "2019-11-21T06:23:02.046402Z",
      "End": "2019-11-21T06:23:02.4194353Z",
      "ExitCode": 1,
      "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (22) The requested URL returned error: 404 Not Found\n"
    },
    {
      "Start": "2019-11-21T06:23:07.4317862Z",
      "End": "2019-11-21T06:23:07.6609581Z",
      "ExitCode": 1,
      "Output": "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (22) The requested URL returned error: 404 Not Found\n"
    }
  ]
}

docs.docker.com

ヘルスチェック結果の変化を検知する

docker events コマンドと --filter を組み合わせることにより，Docker のイベント情報から「ヘルスチェック結果の変化」を検知できる．以下は nginx05 コンテナを起動し，unhealthy となったタイミングに取得したイベント情報となる．

$ docker events --filter 'type=container' --filter event=health_status
2019-11-21T15:44:18.141166300+09:00 container health_status: unhealthy xxxxx (image=kakakakakku/nginx:base, maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>, name=nginx05)

docs.docker.com

まとめ

• Docker で使える「ヘルスチェック機能」を試した
  • Dockerfile に設定することもできるし，docker run コマンドのオプションに設定することもできる
• docker ps や docker inspect や docker events コマンドを使うと「ヘルスチェック」に関する情報を取得できる
• 注意点として，Docker 単体だとヘルスチェックに失敗して unhealthy になったとしても，コンテナ自体はそのまま残る

「Try Envoy」で Envoy を学ぼう！「Getting Started with Envoy」を試した

Envoy のサイトに「Try Envoy」という学習コンテンツがあり，現在は以下の「計11種類」のシナリオから選んで学べる．実際にはブラウザベースで進められる Katacoda の学習コンテンツが埋め込まれているため，特別な環境構築をせずに進められるのは便利．

• Getting Started with Envoy（今回紹介する）
• Migrating from NGINX to Envoy Proxy
• Migrating from HAProxy to Envoy Proxy
• Securing traffic with HTTPS and SSL/TLS
• File Based Dynamic Routing Configuration
• API Based Dynamic Routing Configuration
• Detecting Down Services with Health Checks
• Implementing Blue / Green Rollouts
• Implementing Metrics and Tracing Capabilities
• Debugging Envoy Proxy
• Controlling load balancing policies

学習コンテンツは「Try Envoy」からアクセスできるけど，当然ながら Katacoda にもある．個人的には画面レイアウトの広さという観点から Katacoda を使うと良いと思う．

www.envoyproxy.io

www.katacoda.com

「Try Envoy」のシナリオを数個試してみて，当然ながら手順通りには動くけど，Envoy 初学者には理解しにくそうな点もあった．そこで，学んだことを整理しつつ，イメージしにくそうな部分をまとめておこうと思う．

Getting Started with Envoy

今回は Envoy に入門するシナリオ「Getting Started with Envoy」を紹介する．Envoy を使ってリクエストを外部サービスに流したり，複数のアプリケーションにパスベースルーティングをする．

www.katacoda.com

手順は以下の「計4種類」ある．サイトに「Estimated Time: 10 minutes」と書いてあるけど，考えながら進めるとすぐに終わらないと思う．時間は参考レベルで見ておくと良さそう．

• Step.1 「Create Proxy Config」
• Step.2 「Start Proxy」
• Step.3 「Admin View」
• Step.4 「Route to Docker Containers」

Step.1 「Create Proxy Config」

最初は Envoy の挙動を設定する envoy.yaml を作成する．実際にエディタで envoy.yaml を書く場面はなく，手順上で Copy to Editor ボタンをクリックすると自動的にエディタに反映される仕組みになっている．Katacoda 便利！その前に基本的な用語を整理しておく．詳細はドキュメントを参照してもらえればと．

• Listeners : リクエストを受ける設定
• Filters : リクエストをフィルタする設定（複数のフィルタを設定できる）
• Clusters : リクエストを転送する設定

そして envoy.yaml を読み解く前に構成図を整理しておく．コンテナとして起動した Envoy にリクエストを投げると，そのまま Google に転送される．Envoy を試す最も簡単な構成とも言える．

envoy.yaml のポイントはザッと以下となる．

• listeners
  • 10000 Port でリクエストを受ける
• filter_chains
  • route_config にルーティング設定を書く
  • プレフィックスが / の場合に host_rewrite で HTTP Host Header 書き換える
  • service_google Cluster に転送する

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }

    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { host_rewrite: www.google.com, cluster: service_google }
          http_filters:
          - name: envoy.router

  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    hosts: [{ socket_address: { address: google.com, port_value: 443 }}]
    tls_context: { sni: www.google.com }

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }

Envoy で HTTP を制御するフィルタ envoy.http_connection_manager の詳細は以下のドキュメントに書いてある．

www.envoyproxy.io

Step.2 「Start Proxy」

さっそく envoy.yaml を指定して Envoy コンテナを起動する．80 Port にリクエストをすると，Google に転送される．ホスト内だと curl localhost でも良いし，Katacoda だと https://xxx.environments.katacoda.com という一時的な URL も使えるため，どちらも使える．

$ docker run --name=proxy -d \
  -p 80:10000 \
  -v $(pwd)/envoy/envoy.yaml:/etc/envoy/envoy.yaml \
  envoyproxy/envoy:latest

Step.3 「Admin View」

次に Envoy の「Administration interface」機能を試す．UI は直感的に理解しにくく感じたけど，メトリクス／統計情報／ログなど，Envoy の状態を確認するときに使える．

$ docker run --name=proxy-with-admin -d \
    -p 9901:9901 \
    -p 10000:10000 \
    -v $(pwd)/envoy/envoy.yaml:/etc/envoy/envoy.yaml \
    envoyproxy/envoy:latest

詳しくは以下のドキュメントに書いてある．

www.envoyproxy.io

Step.4 「Route to Docker Containers」

最後は Python アプリケーションと Envoy を組み合わせて使う．docker-compose.yml から構成を読み取ると以下となる．リクエストの URL を判断して service1 と service2 にパスベースルーティングをしていて，アプリケーション側は環境変数 SERVICE_NAME を表示する程度になっている．

なお service1 と service2 は envoyproxy/envoy-alpine:latest イメージをベースに Python と Flask をインストールしているため，Envoy でよく使われる「サイドカーパターン」になっていない点に注意する．とは言え，今回のように Envoy を試すことが目的の場合は問題ないと言える．

version: '2'
services:

  front-envoy:
    build:
      context: .
      dockerfile: Dockerfile-frontenvoy
    volumes:
      - ./front-envoy.yaml:/etc/front-envoy.yaml
    networks:
      - envoymesh
    expose:
      - "80"
      - "8001"
    ports:
      - "8000:80"
      - "8001:8001"

  service1:
    build:
      context: .
      dockerfile: Dockerfile-service
    volumes:
      - ./service-envoy.yaml:/etc/service-envoy.yaml
    networks:
      envoymesh:
        aliases:
          - service1
    environment:
      - SERVICE_NAME=1
    expose:
      - "80"

  service2:
    build:
      context: .
      dockerfile: Dockerfile-service
    volumes:
      - ./service-envoy.yaml:/etc/service-envoy.yaml
    networks:
      envoymesh:
        aliases:
          - service2
    environment:
      - SERVICE_NAME=2
    expose:
      - "80"

networks:
  envoymesh: {}

front-envoy の front-envoy.yaml を以下に載せる．ポイントは filters の routes に2種類の prefix が設定されている点で，URL によって転送する Cluster を変えている．

static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/service/1"
                route:
                  cluster: service1
              - match:
                  prefix: "/service/2"
                route:
                  cluster: service2
          http_filters:
          - name: envoy.router
            config: {}
  clusters:
  - name: service1
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: service1
        port_value: 80
  - name: service2
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: service2
        port_value: 80
admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8001

実際に起動すると，期待した通りにリクエストをルーティングできた．

$ docker-compose -f ~/envoy/examples/front-proxy/docker-compose.yml up -d

$ curl localhost:8000/service/1
Hello from behind Envoy (service 1)! hostname: 211d6aaf214c resolvedhostname: 172.19.0.3

$ curl localhost:8000/service/2
Hello from behind Envoy (service 2)! hostname: 30ce9b84004a resolvedhostname: 172.19.0.2

まとめ

• Envoy のサイトに「Try Envoy」という学習コンテンツがある
  • 現在は「計11種類」のシナリオから選べる
• 今回は「Getting Started with Envoy」を試した
  • リクエストを外部サービスに流したり，複数のアプリケーションにパスベースルーティングをしたり，基本的な動作確認はできる
• まだ「Envoy の良さ」を感じられる内容ではなく，引き続き「Try Envoy」を進めていく

Redash v8 を試そう！「Redash ハンズオン資料」v8 をリリースした

2019年10月末に Redash の最新バージョン「Redash v8.0.0」がリリースされた．多くの新機能と機能改善があり，既にまとめている．

kakakakakku.hatenablog.com

Redash ハンズオン資料 v8 リリース

2017年12月に公開した「Redash ハンズオン資料」も，Redash のメジャーバージョンアップごとに一緒にバージョンアップし，既に2年間もメンテナンスし続けている．個人学習用途／研修用途など，今でも様々な場面で使って頂けているらしく，嬉しい！Star はもう少しで 200 ⭐️

github.com

既にサポートしている Redash バージョン「v2 / v4 / v5 / v6 / v7」に加えて，今回さっそく「v8」もサポートした！主な変更点は以下となる．

• 全般
  • スクリーンショットを更新した
  • UI 変更に合わせて手順を見直した
• 機能
  • 新機能「パラメータ付きクエリ（複数値）」を追加した

まとめ

「Redash ハンズオン資料」を使って Redash v8 を試そう！Happy querying :)

github.com

関連記事

• 最新バージョン Redash v7.0.0 をすぐに試せる「Redash ハンズオン資料」 - kakakakakku blog
• 最新バージョン Redash v6.0.0 をすぐに試せる「Redash ハンズオン資料」 - kakakakakku blog
• 最新バージョン Redash v5 をすぐに試せる「Redash ハンズオン資料」 - kakakakakku blog
• 最新バージョン Redash v4 に対応した「Redash ハンズオン資料」を作った - kakakakakku blog
• Redash を詳しく学べる「Redash ハンズオン資料」を作った - kakakakakku blog

includeIf を使って git config をプロジェクトごとに読み替える

GitHub と AWS CodeCommit を併用したり，プロジェクトごとに別アカウントを使ったり，リポジトリごとに git config を変える場面もある．今までは個人用 GitHub を global 設定とし，別アカウントはリポジトリごとに git config --local コマンドで設定をしていたけど，最近リポジトリが増えて，設定を忘れる場面もあり，direnv のように自動設定をする方法を探していた．

includeIf

Git Documentation を読むと，「Includes (include)」と「Conditional includes (includeIf)」の説明があり，なんと includeIf を使うと，設定ファイルを条件付きで読み込めるため，さっそく検証することにした．

git-scm.com

検証環境

以下のように，ホームディレクトリ直下に github ディレクトリと codecommit ディレクトリを作成した．さらにサンプルリポジトリ g1 / g2 / c1/ c2 を作って git init をしておく．

~/github
    ├── g1
    └── g2
~/codecommit
    ├── c1
    └── c2

~/.gitconfig

今まで通り，ホームディレクトリに ~/.gitconfig を置き，GitHub 用に global 設定をしている．今回は user と email を抜粋した．さらに includeIf と gitdir を組み合わせて，~/codecommit/ 直下にあるリポジトリの場合に ~/.gitconfig_codecommit を読み込む設定を追加した．Git Documentation を読むと，gitdir 以外に onbranch なども使える．

[user]
  name = kakakakakku
  email = y.yoshida22@gmail.com

[includeIf "gitdir:~/codecommit/"]
  path = ~/.gitconfig_codecommit

~/.gitconfig_codecommit

そして，条件付きで読み込む設定を ~/.gitconfig_codecommit に置く．今回は仮で bob と bob@example.com にした．

[user]
  name = bob
  email = bob@example.com

検証結果

global 設定を反映する github/g1 と github/g2 は今まで通りだった．

$ cd ~/github/g1
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

$ cd ~/github/g2
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

そして codecommit/c1 と codecommit/c2 は，期待通りに bob になり，条件付きで読み込めていることを確認できた．便利だ！

$ cd ~/codecommit/c1
$ git config user.name
bob
$ git config user.email
bob@example.com

$ cd ~/codecommit/c2
$ git config user.name
bob
$ git config user.email
bob@example.com

まとめ

プロジェクトごとに git config を読み替える場合は includeIf を使うと便利！特に git clone した直後にすぐ使えるのは体験として大きく改善した．小規模なら git config --local コマンドも引き続き併用していく．