kakakakakku blog

Weekly Tech Blog: Keep on Learning!

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

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

Dockerfile 構文

「ヘルスチェック機能」を使う場合,まず DockerfileHEALTHCHECK を設定する.実行するコマンド以外に以下のオプションも設定できる.注意点として,--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:alpinecurl を追加した
  • kakakakakku/nginx:ok
    • nginx:alpinecurlHEALTHCHECK を追加した(ヘルスチェック成功
  • kakakakakku/nginx:ng
    • nginx:alpinecurlHEALTHCHECK を追加した(ヘルスチェック失敗

Dockerfile : kakakakakku/nginx:ok

nginx を使うため,DockerfileHEALTHCHECK を設定し,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 コマンドのオプションでヘルスチェックを指定することもできる.よって,DockerfileHEALTHCHECK が設定されていなくても「ヘルスチェック機能」は使える.オプションは以下のドキュメントに載っている.

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

docs.docker.com

さっそく kakakakakku/nginx:base を使って,「ヘルスチェックに成功するコンテナ」「ヘルスチェックに失敗するコンテナ」を起動する.すると,DockerfileHEALTHCHECK を記載したときと同様に 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 psdocker inspectdocker 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

f:id:kakku22:20191117162057p:plain

学習コンテンツは「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 を試す最も簡単な構成とも言える.

f:id:kakku22:20191117211922p:plain

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

f:id:kakku22:20191117181412p:plain

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

www.envoyproxy.io

Step.4 「Route to Docker Containers」

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

f:id:kakku22:20191117211948p:plain

なお service1service2envoyproxy/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-envoyfront-envoy.yaml を以下に載せる.ポイントは filtersroutes に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 変更に合わせて手順を見直した
  • 機能
    • 新機能「パラメータ付きクエリ(複数値)」を追加した

f:id:kakku22:20191110121657p:plain

まとめ

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

github.com

関連記事

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 設定をしている.今回は useremail を抜粋した.さらに includeIfgitdir を組み合わせて,~/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 に置く.今回は仮で bobbob@example.com にした.

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

検証結果

global 設定を反映する github/g1github/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/c1codecommit/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 コマンドも引き続き併用していく.

「Redash v8.0.0」で気になった新機能と機能改善

2019年10月末に Redash の最新バージョン「Redash v8.0.0」がリリースされた.Change Log を読むと機能改善が多くあり,今回は「個人的に気になった Redash v8 新機能と機能改善」「計10点」紹介しようと思う.Change Log は以下の CHANGELOG.md で確認できる.

目次

  1. ドロップダウンで複数値を選択できるようになった
  2. クエリ名を日本語で正しく検索できるようになった
  3. ダッシュボードがグリッド表示になった
  4. データソース追加/削除
  5. データソース設定画面の UI 改善
  6. クエリ画面にデータソースのアイコンが表示されるようになった
  7. カスタムアラート機能
  8. Query API Key を作り直せるようになった
  9. アラート送信先から Hipchat が削除された
  10. 匿名利用データ共有

1. ドロップダウンで複数値を選択できるようになった

今までも {{}} を使って「パラメータ付きクエリ」を作り,さらに「ドロップダウン」と組み合わせて「候補を選択する」ことはできたけど,あくまで「1個」しか選択できなかった.例えば,以下のクエリだと {{CountryCode}} として JPN などを選択できるようになる.

SELECT *
FROM city
WHERE CountryCode = '{{CountryCode}}'
ORDER BY Population DESC;

なんと Redash v8 では「ドロップダウンから複数値を選択できる」ようになった.例えば,以下のように IN で複数値を検索する「パラメータ付きクエリ」を作れるようになる.

SELECT *
FROM city
WHERE CountryCode IN ({{CountryCode}})
ORDER BY Population DESC;

ドロップダウンを設定するときに,以下のように「Allow multiple values」という項目があり,3種類ある Quotation から選択できる.今回は IN に合わせるため Single Quotation Mark にした.

  • None (default)
    • value1,value2,value3
  • Single Quotation Mark
    • 'value1','value2','value3'
  • Double Quotation Mark
    • "value1","value2","value3"

f:id:kakku22:20191104002553p:plain

実際にクエリ画面を見ると JPNAUS など,複数値を選択し,クエリを実行できる.これは便利!間違いなく「パラメータ付きクエリ」の用途の幅が広がると思う.

f:id:kakku22:20191104002610p:plain

2. クエリ名を日本語で正しく検索できるようになった

今までは,メニューバーにある検索フォーム(Search queries...)でクエリ名を検索しても,マルチバイト文字に対応してなく,日本語の場合は期待した結果にならず,困っていたと思う.Redash v8 でマルチバイト文字に対応し,クエリ名を日本語で正しく検索できるようになった.ただし,デフォルトでは無効化されていて,Settings 画面で Enable multi-byte を有効化する必要がある.

f:id:kakku22:20191104002632p:plain

3. ダッシュボードがグリッド表示になった

ダッシュボードがグリッド表示になり,罫線を見ながらウィジェットを配置できるようになった.地味な改善ではあるけど,神は細部に宿る!

f:id:kakku22:20191104002650p:plain

4. データソース追加/削除

Redash はバージョンアップごとにデータソースを増やしている.Redash v8 では「計7種類」が追加されて,一部は削除となり「計49種類」になった.データソースの選択肢の多さは Redash を使うメリットになる.

  • 追加
    • Azure Data Explorer (Kusto)
    • Cassandra
    • Couchbase
    • Dgraph
    • JSON
    • Phoenix
    • ScyllaDB
  • 名称変更
    • GoogleSpreadsheet → Google Sheets
  • 削除
    • MemSQL
    • Url

5. データソース設定画面の UI 改善

データソース設定画面で「インクリメンタルサーチ」が使えるようになった.今までは全てのデータソースが並んでいた.バージョンアップごとにデータソースが増えているため,今後さらに増えることを考えると,価値のある改善だと思う.

f:id:kakku22:20191104002806p:plain

6. クエリ画面にデータソースのアイコンが表示されるようになった

クエリ画面で,データソースの左にアイコンが表示されるようになった.地味に良いと思う!

f:id:kakku22:20191104002821p:plain

7. カスタムアラート機能

Redash v8 を起動するときに,環境変数 REDASH_FEATURE_EXTENDED_ALERT_OPTIONStrue を設定し,Feature Toggle を有効化すると「カスタムアラート機能」が使えるようになる.今までも「アラート機能」はあったけど,例えば Slack にアラートを通知しても「アラート名」以外に情報がなく,迅速な状況判断には使えなかった.

そこで「カスタムアラート機能」を使うと,以下のように自由にテンプレートを定義することができ,カスタマイズしたアラートを通知できるようになる.ちなみに Description templateMustache フォーマットを使う.さらに「プレビュー機能」もあり,これは便利すぎる新機能!今回はサンプルとして「閾値」「実測値」をテンプレートに埋め込んでみた.

f:id:kakku22:20191104002838p:plain

実際に Slack に通知をすると,以下のように Description が追加されていた.定義するテンプレート次第では,今までよりも格段に情報量が上がるため,障害時の迅速な状況判断に活用できそう.

f:id:kakku22:20191104002852p:plain

8. Query API Key を作り直せるようになった

Redash v8 から Query API Key を作り直せるようになった.実際に API Key のダイアログを確認すると Regenerate ボタンがあった.

f:id:kakku22:20191104015451p:plain

9. アラート送信先から Hipchat が削除された

2018年の Hipchat 廃止に伴って,アラート送信先から今まであった Hipchat が削除された.

f:id:kakku22:20191104002904p:plain

10. 匿名利用データ共有

Redash v8 から「Anonymous Usage Data Sharing(匿名利用データ共有)」の仕組みが追加されていて,オプトインをすると,クエリ数など一部の利用データが Redash 運営側に送信される.今回 Redash トップページ下部にオプトインをするメニューが追加されていた.

f:id:kakku22:20191104002922p:plain

オプトインは Settings 画面から変更できるようになっている.

f:id:kakku22:20191104002932p:plain

まとめ

  • 2019年10月末にリリースされた「Redash v8.0.0」を試した 🎉
  • 個人的に気になった新機能と機能改善を「計10点」紹介した
  • 特に以下は目玉機能だと思う 👀
    • ドロップダウンで複数値を選択できるようになった
    • クエリ名を日本語で正しく検索できるようになった
    • カスタムアラート機能

Redash v7 紹介記事

kakakakakku.hatenablog.com