BigQuery の標準 SQL モードで日付テーブルのフィルタリング、または Re:dash の Query Snippets を活用する話

Dec 4, 2016

要は Legacy SQL モード で FROM (TABLE_DATE_RANGE(dataset.table_, TIMESTAMP('2016-01-01'), TIMESTAMP('2016-01-14'))) とか書いていたのを標準 SQL でどう書くか、という話です。 すぐ忘れるのでメモ。 テーブルは以下のような名前になっている前提です。 table_20160101 table_20160102 table_20160103 … これで例えば直近 14 日分のテーブルを対象にしたい場合はこんな感じ。 SELECT time FROM `dataset.table_*` WHERE _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)) テーブル名はワイルドカードで指定しつつ、_TABLE_SUFFIX という擬似カラムに対して日付の条件を指定する。 詳細は以下の公式ドキュメントを参考にしましょう。 Wildcard table syntax よく使うパターンですが、覚えていられない、という人で普段 Re:dash でクエリを書いている、という人は v0.12.0 で追加された Query Snippets という機能を使うと、こんな感じにキーワード補完されるようになって便利です。 設定としては以下のようにしておけば _TABLE_SUFFIX というキーワードをトリガーに補完されます。

GitHub の Issue を作るコマンド ghissue を作った

Nov 27, 2016

作りました。 yuya-takeyama/ghissue なぜ作ったか いろいろな自動化スクリプトを書く中で、Octokit とかで毎回実装するのは面倒だったので、標準入力だけ食わせればいい感じにやってくれるものが欲しいな、と思って作りました。 タイトル・本文だけを標準出力に書き出すスクリプトだけ書けば、それをパイプで繋げるだけで ghissue が Issue を立ててくれます。 タイトル・本文だけうまく組み立てることに集中すればよくなり、テストも楽になるでしょう。 類似ツールとしては ghi というツールがありますが、これは標準入力からタイトル・本文を指定することができないので、他のコマンドと組み合わせて使うのはやや面倒です。 また、ghi が Ruby なのに対して、ghissue は Go で実装されていてコンパイル済みのバイナリも GitHub からダウンロードできます。 使い方 アクセストークンの指定 GitHub のアクセストークンを GITHUB_ACCESS_TOKEN という環境変数で指定します。 Issue を作る $ some_command | ghissue yuya-takeyama/test --labels Bug,Major --assignees yuya-takeyama some_command は Issue のタイトル・本文を生成するためのコマンドです。 1 行目がタイトルになり、残りは本文になります。 --labels (-l) ではラベルを指定します。カンマ区切りで複数指定可能です。 --assignees (-a) では assignee を指定します。これもカンマ区切りで複数指定可能です。 その他 Issue を編集する機能・コメントを記入するための機能もあっていいだろうと思うものの、今のところ個人的には必要としてないので、まぁそのうち。 よければご利用ください。

Docker コンテナを DigitalOcean 上でサクッと動かす

Oct 11, 2016

やりたいこと 任意のアプリの Docker コンテナをサクッと立ち上げたい かつグローバル IP アドレスを割り当てて外から接続したい より具体的には、今回は mitmproxy をインターネット上で動かして iPhone 等のスマートフォン端末からつなぎたかった、という感じです。 手順 DigitalOcean のアカウントを作成する ここは割愛。 DigitalOcean のアクセストークンを作成 API -> Tokens -> Generate New Token から適当に名前をつけて作ります。 docker-machine で Docker 環境を作る docker-machine のインストール手順については割愛。 Mac だと Homebrew でもインストールできるので適当にやっておく。 $ docker-machine create --driver digitalocean --digitalocean-access-token=ACCESS_TOKEN --digitalocean-region=sgp1 mitmproxy --digitalocean-access-token には前の手順で作ったアクセストークンを指定。 --digitalocean-region にはリージョンの slug を指定します。 省略すると New York にできてレイテンシが辛いので、日本からだとシンガポールでも指定しておくのがいいでしょう。 リージョンの slug 一覧はこんな感じに最新版を取得できます。 $ curl -H "Content-Type: application/json" -H "Authorization: Bearer ACCESS_TOKEN" "https://api.digitalocean.com/v2/regions" -s | jq

Continue Reading →

Docker のメトリクスを Re:dash でビジュアライズ

Oct 2, 2016

しばらく前から Dokku という Docker ベースの Heroku ライクな PaaS 基盤を趣味で運用していて、その中で旧ブログの WordPress や 自分用のツールなんかを動かしたりしている。 サーバのメトリクス収集には Mackerel を利用しているが、Docker コンテナ単位での計測は行っていなかった。 Mackerel はホスト数に応じた課金を行っていて、5 ホストまでは無料だが、コンテナまで追加してしまうとすぐにその枠を溢れてしまう。 というわけで簡単な仕組みを自分で用意いてみた。 できたもの どちらもメモリ使用量 (MB) をコンテナ名ごとにグラフ化したもので、どちらもデータは同じものを使っている。 後者はグラフを積み上げることでコンテナ全体で使用しているメモリの使用量もわかるようになっている。 今のところ Docker のリソースに関して困っているのはメモリだけなので、とりあえずはこれだけ。 なお、Dokku ではコンテナ名が アプリ名.プロセス名.プロセス番号 という感じになる (例えば blog.web.1 といった具合) になるので、アプリを再起動してコンテナ ID が変わっても連続的にモニタリングできる。 グラフ中異常値っぽいのが出ているところはまさにアプリを再起動したりしているところ。 概要 以下のような流れでこのグラフを作り出している。 fluent-plugin-docker-metrics で Docker のメトリクスを td-agent に収集 fluent-plugin-bigquery でメトリクスを BigQuery に送信 Re:dash で BigQuery 上のデータをグラフ化 手順 fluent-plugin-docker-metrics のセットアップ td-agent.conf の設定はこんな感じ。 <source> @type docker_metrics stats_interval 1m tag_prefix docker.metrics </source> tag_prefix はデフォルトだと

Continue Reading →

【RMP×Quipper】Food&Drink meetup #3 で発表した

Oct 1, 2016

Quipper とその親会社であるところのリクルートマーケティングパートナーズ (RMP) とでの合同イベント (平たくいうと採用イベント) があって、LT の発表枠が空いていたので発表してきた。 スライドは Qiita のスライド機能を初めて使ってみた。 スクリーンに写すと文字が結構小さかったので、事前のチェックが大事だと思った。 curl でサッとベンチマークをとる (スライド版) 内容的には以前同じく Qiita に書いた記事 を加筆・再編集した程度のものなので、準備にはあまり時間がかかっていない。 Google Chrome の Developer Tools からリクエストを curl コマンドとしてコピーする機能について知らない人が意外と多かったので、その点が一番バリュー高かったのかもしれない。 あとは見つけた時に超クールだと思った hyst というツールについても軽く紹介した。 hyst を作っている @winebarrel さんには miam や roadworker でもお世話になっています。 あと Quipper でも使われているみたいです。

curl でレスポンスタイムをシュッと取るヤツ

Sep 27, 2016

以前 Qiita にcurl でサッと HTTP ベンチマークと書いたが、それをもうちょい簡単にやるために以下のようなコマンドを用意してみた。 #!/bin/sh curl -s -o /dev/null -w '%{time_starttransfer}\n' "$@" これを curlb という名前で $PATH の通ったところに置いておくと以下のようにできる。 $ curlb https://blog.yuyat.jp/ 0.067

標準エラー出力に tee するコマンド tee2err を作った

Sep 26, 2016

GNU tee でも BSD tee でもできないので作りました。 yuya-takeyama/tee2err これは何か 標準入力を食わせると、標準出力と標準エラー出力に同じものを出力するだけのコマンドです。 $ echo foo | tee2err foo foo foo と 2 回出力されていますが、一方は標準出力に、もう一方は標準エラー出力に出力されています。 どういう時に使うか 標準入力からストリームを食わせるとなんらかの終端操作を行うようなツールと一緒に使います。 例えば 1 から 10 までの数列の総和を求める場合。 $ seq 10 | perl -ane '$i+=$_; END { print "SUM: $i\n"; }' SUM: 55 これはこれで特に問題ないですが、これに tee2err を組み合わせるとこのようになります。 $ seq 10 | tee2err | perl -ane '$i+=$_; END { print "SUM: $i\n"; }' 1 2 3 4 5 6 7 8 9 10

Continue Reading →

GitHub Pages を nginx のリバースプロキシ越しに配信する

Sep 25, 2016

このブログは以前の記事にも書いた通り、GitHub Pages から配信しています。 そしてさらに、前段に nginx のリバースプロキシを置いた構成になってます。 何故リバースプロキシを利用するか はっきり言って普通に考えたら無駄感はありますが、良い点をいくつか挙げてみます。 Zone apex domain を使用することができる GitHub Pages は CNAME による Custom domain に対応していますが、CNAME では通常 Zone apex domain に対応することができません。 リバースプロキシを利用することで、ドメインの A レコードにリバースプロキシを指定し、その upstream に GitHub Pages の URL を指定することで、対応することができます。 (このブログはご覧の通り Zone apex domain ではないですが、そのうちそっちにもページを作るつもりです) Custom domain でも HTTPS を使用することができる GitHub Pages はデフォルトでは USERNAME.github.io ドメインが割り当てられ、HTTPS で配信されます。 ですが、CNAME を使った場合は HTTP となってしまい、HTTPS を利用する方法は GitHub からは提供されていません。 Let’s Encrypt を使えばセットアップは簡単です。 アクセスログをちゃんと取得できる GitHub でもリポジトリの Graphs -> Traffic を見るとある程度わかりますが、nginx で好きなログを残せるようになります。 設定手順

Continue Reading →

Let's Encrypt の証明書を Ansible と certbot で Nginx にインストール & 自動更新

Sep 19, 2016

これもリニューアルネタです。 やりたいこと Let’s Encrypt の証明書を Ansible でインストールする その後の証明書の更新も自動で行うようにする その設定もやはり Ansible で行う 前提とする環境 Ubuntu 16.04 だと certbot が apt-get でインストールできますが、それ未満だと certbot-auto というコマンドを手動でインストールする必要があります。 中身はほぼ同じだと思いますが、そちらについての説明はしません。 Ubuntu 16.04 Ansible 2.1.1.0 nginx 1.10.1 手順 certbot のインストール certbot とは Let’s Encrypt の証明書の取得や更新を自動化するためのコマンドラインツールです。 こんな感じの playbook でインストールします。 - name: install certbot apt: name=letsencrypt state=present update_cache=yes 証明書の取得 certbot は Automated Certificate Management Environment (ACME) というプロトコルにより証明書の取得を行います。 これは、Let’s Encrypt のサーバが証明書を取得しようとしているドメインのある URL にアクセスし、ちゃんとレスポンスを返すことができるかチェックするというものです。 そのため事前に nginx 等の Web サーバを起動して、インターネットからリーチできる状態にしておく必要があります。 (--standalone オプションを使えば certbot 自身が

Continue Reading →

Hugo で作ったサイトを CircleCI で GitHub Pages に自動デプロイ

Sep 19, 2016

Hugo は Jekyll と違って、GitHub Pages に push しても勝手にページ生成はされません。 どうにかして自分で Hugo を実行し、それで生成されたファイルを push する必要があります。 このブログを構築するにあたって、CircleCI でビルドして自動デプロイする手順がまとまったので公開します。 なお、このブログはカスタムドメインを使用していますが、それについての説明はこの記事ではしません。 前提とする環境 Hugo Ver. 0.16 概要 以下のような環境・手順で自動デプロイが行われるようにします。 記事のソースは master ブランチに push する GitHub Pages 用のブランチには gh-pages を使う master ブランチが更新された時に gh-pages が自動的に更新される セットアップ手順 対象ブランチの設定 当然ですがリポジトリを準備します。 そしてリポジトリの Settings から GitHub Pages の Source として gh-pages を選択します。 ただし、gh-pages ブランチがない状態だと選択できないと思うので、その場合は手動でブランチだけ作るか、CircleCI によるデプロイが行われた後で行うと良いでしょう。 デプロイキーの用意 CircleCI は CI 対象のリポジトリを登録する時に、自動的に対象リポジトリの SSH キーを生成します。 が、これは read-only なので、今回の様に CircleCI から GitHub に push したい場合は使えません。 なので手動で生成し、登録する必要があります。 鍵の生成については GitHub のドキュメント等を参照してください。 Generating a new SSH key 生成したら GitHub リポジトリの Settings -> Deploy keys -> Add deploy key と進み、Key には生成した公開鍵ファイルの中身を貼り付け、Allow write access にチェックを入れてください。 また、CircleCI 側には秘密鍵を登録します。 Project Settings -> SSH Permissions -> Add SSH Key と進み、hostname には github.com、Private Key には秘密鍵の中身を貼り付けてください。 これで github.com へのデプロイ時にはこの鍵ファイルが使われるようになります。 デプロイスクリプトの用意 circle.yml は以下のようなものを準備します。 master ブランチが更新された時はデプロイ用のスクリプトを実行するようになっています。 dependencies: pre: - wget https://github.com/spf13/hugo/releases/download/v0.16/hugo_0.16-1_amd64.deb - sudo dpkg -i hugo_0.16-1_amd64.deb test: override: - "true" deployment: production: branch: master commands: - ./scripts/deploy_production.sh デプロイスクリプトは以下のようにします。 これを scripts/deploy_production.sh という名前で保存して、忘れずに chmod +x しておきましょう。 設定部分は環境変数でセットするようにしてあるので、コピペそのままで使えると思います。 #!/bin/bash -eux if [ -z "${GIT_USER_NAME}" ]; then echo "Please set an env var GIT_USER_NAME" exit 1 fi if [ -z "${GIT_USER_EMAIL}" ]; then echo "Please set an env var GIT_USER_EMAIL" exit 1 fi GIT_REPO="git@github.com:${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}.git" git submodule init git submodule update remote=`git ls-remote --heads 2> /dev/null | grep gh-pages || true` if [ -n "$remote" ]; then git clone -b gh-pages "${GIT_REPO}" public rm -rf public/* else git init public cd public git checkout -b gh-pages git remote add origin "${GIT_REPO}" cd ..

Continue Reading →


Author

Yuya Takeyama

Yuya Takeyama