Ubuntu 上で環境構築していた Redash を Docker 上で動作する環境に移行する手順
この記事は Redash Advent Calendar 2018 25日目。最終日の記事です!
参加いただいたみなさまも、読んでいただいた皆様もありがとうございます!
お題
現在、Redash の環境構築は Docker を使用する方法のみが公式ドキュメントなどでも記載されていますが、古くからの Redash ユーザーにとっては、Ubuntu の上にインストールする形で運用している方も多く、私もそのひとりです。
この記事では、旧来の Ubuntu 上に環境構築された Redash(以降、レガシーセットアップ)を Docker で構築された Redash(以降、Docker セットアップ)に移行する方法を紹介します。
注意事項
この記事で紹介する方法はあらゆる環境を網羅したものではありません。
お使いの環境を移行する際は、必ずご自身で検証してください。
また、この手順は私が業務で Redash を移行する際にも利用しているため、移行作業の結果によって、この記事を加筆修正する場合があります。
前提条件
この記事の検証で使用した Ubuntu と Docker、 Docker Compose のバージョンは以下となっています。
- Ubuntu 16.04.4 LTS
- Docker version 18.09.0, build 4d60db4
- docker-compose version 1.8.0, build unknown
この記事では Docker の導入については割愛しますが、私は以下の記事を参考にして Docker を導入しました。
How To Install and Use Docker on Ubuntu 16.04 | DigitalOcean
手順
PostgreSQL 以外の Redash 関連のサービスを停止
PostgreSQL の DB ダンプを取得する前に、Redash 関連のサービスをすべて停止します。
$ sudo service nginx stop $ sudo service supervisord stop $ sudo service redis_6379 stop
サービス名は Redash をどのバージョンから利用しているかによって異なる場合があります。
既存の Redash から DB ダンプを取得する
Docker セットアップ環境で使用する PostgreSQL にリストアするための DB ダンプを取得します。
レガシーセットアップでは PostgreSQL に redash
ユーザーを作成しますが、Docker セットアップでは postgres
ユーザーを使いますが、そのため、既存環境のダンプファイル取得時にオーナー情報を除去しておきます。
$ sudo -u postgres bash -c "pg_dump --no-owner --no-acl redash | gzip > /tmp/dump.sql.gz"
ダンプファイルの出力先は /opt/docker/redash
として、この記事内では以降の説明でも、このディレクトリ内で作業します
既存の PostgreSQL を停止
ダンプファイルを取得したら、既存の PostgreSQL は不要になるためサービスを停止します。
$ sudo service postgresql stop
docker-compose.yml をダウンロードする
移行先バージョンの docker-compose.production.yml
をダウンロードします。
この記事では移行先に v5.0.2
を使用するため、GitHub 上でタグを指定してダウンロードしています。
$ wget -o /opt/docker/redash/docker-compose.yml https://raw.githubusercontent.com/getredash/redash/v5.0.2/docker-compose.production.yml
docker-compose.yml を書き換える
Docker セットアップで使用するバージョンに合わせて docker-compose.yml
を書き換えます。
バージョンの指定
Docker イメージのタグ一覧 を参照し、利用したいバージョンのタグを指定します。
$ sed -i s/redash\\/redash:latest/redash\\/redash:5.0.2.b5486/g /opt/docker/redash/docker-compose.yml
postgres サービスのボリューム指定
PostgreSQL のデータを保持するボリュームを指定します。
postgres
サービスの volumes
がコメントアウトされているので、これをアンコメントしてホスト側のパスを書き換えます
...省略... postgres: image: postgres:9.5.6-alpine volumes: - /opt/docker/redash/postgres-data:/var/lib/postgresql/data restart: always ...省略...
環境変数を設定する
既存の Redash の .env
から必要な設定を server
, worker
サービスの environment
に設定します。
ここでは詳細な説明を省きますが、メールサーバーの設定などは .env
にで設定することが多いので、忘れずに設定しましょう。
また、server
のみに設定してしまい worker
に環境変数が適用されないというケースもあるので、忘れずに両方の environment
に設定してください。
Docker Compose で起動する
準備ができたら、サービスを起動します。
$ sudo docker-compose up -d
postgres
にダンプファイルをコピーする。
新規インストールの手順であればここで create_db
を実行するところですが、今回は既存環境からの移行なので、データベースの作成はせずに、先程取得したダンプファイルをリストアします。
そのため、ダンプファイルを postgres
サービスが動いているコンテナにコピーします。
$ sudo docker cp /tmp/dump.sql.gz `sudo docker ps|grep postgres|awk '{print $1}'`:/tmp/
DB をリストアする
コピーしたダンプファイルを使って、以下のコマンドでリストアします。
$ sudo docker-compose exec postgres bash -c "zcat /tmp/dump.sql.gz | psql -U postgres"
マイグレーションを実行する
この時点で、DB は作られていますが、古いバージョンのテーブル構造のままになっているため、マイグレーションを実行して移行先のバージョンにあったテーブル構成にします。
$ sudo docker-compose run --rm server manage db upgrade
ここまででレガシーセットアップから Docker セットアップへの移行は完了です。
疎通確認
最後に、curl
で簡単に疎通確認してみます。
$ curl -I localhost/api/config
JSON 文字列が表示されていれば、移行した Redash が動作していることが確認できています。
まとめ
バージョンアップにくらべ、さらに腰が重くなるような移行作業ですが、私も今後のアップグレードも見据えて移行を進めています。移行は計画的に進めましょう。
Redash のクエリ結果がクリーンアップされる仕組み
この記事は Redash Advent Calendar 2018 20日目の記事です。
お題
フォーラムでクエリ結果を使ってごにょごにょされている方の投稿がありました。
私もコメントしてみましたが、Redash のクエリ結果はあるルールで定期的に削除されています。
この記事では、その動きを追ってみようと思います。使用するバージョンは v6.0.0
ブランチです。
動きを追ってみる
server と worker
まず、Redash は大きく server
(Flask) と worker
(Celery) のプロセスがあります。
クエリ結果を削除する仕組みは worker
側で実行されています。
worker が実行される仕組み
Redash の worker
プロセスは Celery を使って実行されます。
エントリポイントは redash/worker.py になっています。
クエリ結果が削除される仕組み。
redash/worker.py
中の以下のコードがクエリ結果の削除に大きく影響します。
if settings.QUERY_RESULTS_CLEANUP_ENABLED: celery_schedule['cleanup_query_results'] = { 'task': 'redash.tasks.cleanup_query_results', 'schedule': timedelta(minutes=5) }
Redash は環境変数でいろいろな設定を変更できるようになっており、 QUERY_RESULTS_CLEANUP_ENABLED
もその設定のひとつです。
文字通り、クエリ結果をクリーンアップするかどうかをこの環境変数で決定しており、デフォルトは True
になっています。
この設定が有効になっていると、redash/tasks/queries.py の cleanup_query_results
が5分に1度実行されます。
@celery.task(name="redash.tasks.cleanup_query_results") def cleanup_query_results(): """ Job to cleanup unused query results -- such that no query links to them anymore, and older than settings.QUERY_RESULTS_MAX_AGE (a week by default, so it's less likely to be open in someone's browser and be used). Each time the job deletes only settings.QUERY_RESULTS_CLEANUP_COUNT (100 by default) query results so it won't choke the database in case of many such results. """ logging.info("Running query results clean up (removing maximum of %d unused results, that are %d days old or more)", settings.QUERY_RESULTS_CLEANUP_COUNT, settings.QUERY_RESULTS_CLEANUP_MAX_AGE) unused_query_results = models.QueryResult.unused(settings.QUERY_RESULTS_CLEANUP_MAX_AGE).limit(settings.QUERY_RESULTS_CLEANUP_COUNT) deleted_count = models.QueryResult.query.filter( models.QueryResult.id.in_(unused_query_results.subquery()) ).delete(synchronize_session=False) models.db.session.commit() logger.info("Deleted %d unused query results.", deleted_count)
ここで QUERY_RESULTS_CLEANUP_MAX_AGE
に指定された日数(デフォルトは 7
日) 以上前に実行されたクエリ結果を QUERY_RESULTS_CLEANUP_COUNT
に指定された件数(デフォルトは 100
)削除されます。
利用の仕方によってはクエリ結果が大きくなってしまい、ディスクなどのリソースを圧迫してしまうことがあるため、実行済みのクエリ結果を多用しない場合は QUERY_RESULTS_CLEANUP_MAX_AGE
を適切に調整するのをおすすめします。
私が業務で運用している Redash インスタンスはクエリパラメータを多用していたり、毎時結果が変わるような特性のデータを扱っていることもあるため、 QUERY_RESULTS_CLEANUP_MAX_AGE
は 3
に設定しています。
この記事で紹介した環境変数以外にもいろいろな項目が設定できるので、以下の記事もぜひ読んでみてください。
まとめ
クエリ結果が削除される仕組みについて改めて調べてみました。
クエリ結果が大きくなるようなクエリを多く運用されている方でこれらの設定を見直したことがないという方がいたら。一度見直してみると良いと思います。
明日は y-tomoyasu さんによる「Python Data Sourceの利用ケースについてなにか」です。
y-tomoyasu さんは Redash Meetup 4.0.2-dev でも少しお話を伺いましたが、Python データソースをガッツリ使われているようです!お楽しみに!
Redash v6 で追加されたオートコンプリートの無効化について挙動とコードを追ってみる
この記事は Redash Advent Calendar 19日目の記事です。勤務先でも師走ムードを感じ始めました。
お題
Redash、入力補完(スニペットとか)が出てこなくなってしまって困った...シークレットモードだとちゃんと動く!キャッシュクリアとかスーパリロードしても出てこない...謎 😢(解決方法知っている人いたら、教えてください...)
— mario (@mario_kada) 2018年12月17日
この問題と関係あるかどうかはわかりませんが、オートコンプリートと聞いて、先日リリースされた Redash v6 (正確には 6.0.0-beta から追加)で以下の機能が追加されたことを思い出しました。
If the live autocomplete in the code editor annoys you, you can disable it now
今日はこの機能について検証しつつ、ざっくりと実装を追ってみます。
検証環境は docker-compose
で起動し、Docker イメージは redash/redash:6.0.0.b8537
を使用しました。
影響範囲
この機能はクエリ編集画面に影響があります。
以下はオートコンプリートを無効にする前の画面で、今までのバージョンと同じくオートコンプリートが有効になっています。
上記の画面で表示されている、雷のマークがオートコンプリートの有効・無効を切り替えるトグルになっていて、無効にすると静止画ではわかりにくいですが、以下の画面のようにオートコンプリートが効かなくなります。
オートコンプリートの設定はどこに保持されているか?
Chrome の開発者ツールなどで見るとすぐに分かりますが、LocalStorage に保持されています。
liveAutocompleteDisabled
が false
だとオートコンプリートが有効になるようです。
オートコンプリートを制御しているのはどのコードか?
client/app/components/QueryEditor.jsx
で liveAutocompleteDisabled
を操作しています。
redash/QueryEditor.jsx at v6.0.0 · getredash/redash · GitHub
Redash は現在 Angular から React への移行を進めていて、クエリエディタ周りも v6.0.0 時点では React のコンポーネントに書き換わっています。
このコンポーネントのなかでオートコンプリートのボタンがクリックされるたび、コンポーネントの State と一緒にブラウザの Local Storage を書き換えているようです。
toggleAutocomplete
で呼ばれている localOptions.set
は Redash 独自のもので、Web Storage API を薄くラップしたもののようでした。
redash/localOptions.js at v6.0.0 · getredash/redash · GitHub
まとめ
まとめと書きつつ、これといったまとめはありませんが、オートコンプリート周りの実装を読んだことで、また少し Redash についての理解が深まりました。
それも元ツイートのおかげなので、ありがたい限りです。
お知らせ
Redash についての疑問などを Twitter で拾えることもあるのですが、できればフォーラムへの投稿をしていただけるとありがたいです!日本語でOK!
30行ぐらいで Redash のクエリ実行結果を Google スプレッドシートに書き込むサンプルコード
この記事は Redash Advent Calendar 14日目の記事です。
タイトルの通り、Redash の利用事例で話されることが多く、私も活用している Redash と Google スプレッドシートの連携について、Python のサンプルコードを公開してみます。
使うもの
主に以下のパッケージを利用します。
サンプルコード
GitHub で公開しました。
正確には 27行です。行数を削るために少し苦しい書き方になっている部分はご了承ください。
動かし方
まずは venv
で環境構築します。
$ python3 -m venv .venv $ source .venv/bin/activate $ pip install -r requirements.txt
Google のサービスアカウントを使用して API にアクセスします(この記事ではサービスアカウントの作成などについては割愛します)
サービスアカウントの JSON 鍵ファイルを環境変数で指定します。
$ export CLIENT_SECRET_FILE="/path/to/json/key/credential.json"
Redash のユーザー API キーも同様に環境変数で指定します。
このサンプルコードでは、Redash のデモサイトを使用していますが、お使いの環境にあわせてサンプルコードの URL を変更してください。
$ export REDASH_API_KEY="YOUR_REDASH_USER_API_KEY"
最後に、 main.py
を編集します。
spreadsheet_id="スプレッドシートID", spreadsheet_range="シート1!A1",
スプレッドシート ID と書き込み先の範囲を指定します。
書き込み対象のスプレッドシートには、サービスアカウントから書き込み可能な権限を付与してください。
デモサイトを使用しない場合は、以下のコードを書き換えて使用したいクエリ ID を指定してください。
df = query_to_df(redash, 1)
以下のようにパラメータを使用することもできます。
df = query_to_df(redash, 123, {'foo': 1, 'bar': 2})
実行してみる
準備ができたら実行してみましょう。
$ python main.py
実行が完了すると、上記のようにスプレッドシートの指定した範囲に結果が書き出されるはずです。
まとめ
Redash とスプレッドシートを簡単に連携されることができました。
まだスプレッドシート連携までは手が出せていない。というかたは、よろしければ試してみてください。
明日の Redash Advent Calendar は Redash のメンテナーでもある deecay さんによる「2018年の活動振り返り」です!お楽しみに!
Redash のアラート通知先を独自拡張する
この記事は Redash Advent Calendar 13日目の記事です。折返し地点ですね!
きっかけ
このツイートを見てやってみようと思いました。
Redashってプラグイン機構あるのかな…
— 睦月@インフラ技術…者? (@mutsuki99) 2018年12月12日
オリジナルの Destination 作ったのはいいんだけど、デプロイが Python ファイルのコピーってのがとてもいけてない感じがしている。環境変数のリスト見てる限りプラガブルな仕組みがある雰囲気なんだけどなぁ。
やりかた
コードをパッケージ化する
redash/destinations
に置いているコードを以下のような感じにパッケージ化します。
必ずしも GitHub や Git を使わなくてもよいのですが、今回は説明を省きたいのでこれで進めます。
この記事の本題にはたいして関係ありませんが、この Destination はアラートを JSONL 形式でログファイルに書き出す。というものにしてみました。
Redash の requirements.txt を変更する
アラート通知のパッケージを requirements.txt
に追加します。
-e git+https://github.com/ariarijp/redash-json-logger-destination.git#egg=redash-json-logger-destination-0.1.0
Redash の docker-compose.yml を変更する
検証には Docker を使用するので、docker-compose.yml
の server
と worker
の environment
に以下を追加します。
REDASH_ADDITIONAL_DESTINATIONS: "redash_json_logger_destination"
この REDASH_ADDITIONAL_DESTINATIONS
環境変数で、アラート通知先を追加することができます。
追加したいものが複数ある場合はカンマ区切りで設定できます。
ビルドする
requirements.txt
の変更を反映したイメージをビルドします。
これにはかなり時間がかかるので気長に待ちましょう。
$ docker-compose build
起動してみる
これで準備は完了です。起動してみましょう。
$ docker-compose run --rm server create_db $ docker-compose up -d
管理者ユーザーの追加などの設定は割愛します。
設定画面を見ると、アラートの通知先が追加されています。
まとめ
この手順は、去年書いたクエリランナーを追加するという記事とほとんど同じだったりします。
今朝、先のツイートを見るまでやってみようと思ったことがなかったのですが、結果として同じようにできたのでよかったです。