Business IntelligenceのRedashはデータから経営判断するとても良いツールです。 SQLさえ書ければ、難しいプログラミング知識も必要のないのでテックに強いスタッフにSQLを勉強してもらえれば使ってもらえます。

AWSのAMIイメージも用意されてるのですぐに導入できます。しかし、TLS/SSL化されてないので大事なデータを傍受されてしまう危険性があります。 そこで、https化ですが、少し手間取ったので記録しておきます。

AMIを中身を見るとわかるのですが、DockerでRedash周りのプロセスが動いています。なので、方針として、ホスト側にlet’s encryptを入れる。Let’s encryptのキーがあるディレクトリをdockerからマウント。ホストでcertbotのリフレッシュで期限切れになるのを防ぐという感じです。

1. ホスト側にcertbot導入

方法はいろいろあると思いますが、AWSのRoute53を利用して作成しました。

参考：https://qiita.com/komazarari/items/88c1ed18765fb7cab6c1

https://certbot.eff.org/lets-encrypt/ubuntubionic-other通りにcertbotをインストールして、

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot 

pipでcertbot-dns-route53アドオンをインストール

$ sudo apt install python3-pip libssl-dev libffi6
$ sudo pip3 install certbot-dns-route53

AWSのsecretkey/apikeyをセットして、下記で/etc/letsencrypt以下にファイルを作成。systemd経由で期限切れの確認が走っているみたい。

 sudo certbot certonly --dns-route53 \
    -d 'redash.exmpale.com' \
    --email redashadmin@example.com \
    -n \
    --agree-tos \

2. Redash nginxのconfig作成

参考：https://gist.github.com/arikfr/64c9ff8d2f2b703d4e44fe9e45a7730e

redashのインストール場所に行って、ディレクトリとファイルを作成。

$ sudo su
$ mkdir /opt/redash/nginx
$ vi /opt/redash/nginx/nginx.conf

nginx.confは下記のようにした。

upstream redash {
  server redash:5000;
}

server {
    listen      80;
    listen [::]:80;
    server_name redash.example.com;

    location ^~ /ping {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

        proxy_pass       http://redash;
    }

    location / {
        rewrite ^ https://$host$request_uri? permanent;
    }

    location ^~ /.well-known {
        allow all;
        root  /data/letsencrypt/;
    }
}

server {
    listen      443           ssl http2;
    listen [::]:443           ssl http2;
    server_name               redash.example.com;

    add_header                Strict-Transport-Security "max-age=31536000" always;

    ssl_session_cache         shared:SSL:20m;
    ssl_session_timeout       10m;

    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers               "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;";

    ssl_stapling              on;
    ssl_stapling_verify       on;
    resolver                  8.8.8.8 8.8.4.4;

    ssl_certificate           /etc/letsencrypt/live/redash.example.com/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/redash.example.com/privkey.pem;
    ssl_trusted_certificate   /etc/letsencrypt/live/redash.example.com/chain.pem;

    access_log                /dev/stdout;
    error_log                 /dev/stderr info;

    # other configs

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

        proxy_pass       http://redash;
    }
}

3. Redashのdocker composeファイルの編集

/opt/redash/docker-compose.ymlを開いて、

nginx:
 image: nginx:latest
 ports:
   - "80:80"
   - "443:443"
 depends_on:
   - server
 links:
   - server:redash
 volumes:
   - /opt/redash/nginx/nginx.conf:/etc/nginx/conf.d/default.conf
   - /etc/letsencrypt:/etc/letsencrypt
 restart: always

その後、リスタート。

docker-compose up -d

systemdのpost-hook設定

直接certbot.serviceファイルを触るのはあまり良いプラクティスでなさそうだが、、

$ sudo vi /lib/systemd/system/certbot.service

で開いて下記を追加(/usr/local/bin/certbotに変更。でないとバージョンのエラーで失敗していた)

ExecStart=/usr/local/bin/certbot -q renew --post-hook "docker-compuse up -d"

sysytemdのコンフィグをリロードすればOK.

systemctl daemon-reload

SendGridのAPI経由のEメール送信がテンプレートを使えて非常に良いので切り替えたいが、現在smtpで送っているメールをすべて一回で切り替えるのは不可能なので、同時運用したい。 下記のように、delivery_methodとdelivery_method_optionsをmailメソッドに入れるとwrapしてくれるので、smtpを使わなくなる。

  def send_test_mail
    mail(
      to: 'myemail@change.this.com', 
      subject: 'email subject', 
      body: 'not used',
      template_id: "xxxx",
      delivery_method: :sendgrid_actionmailer, 
      delivery_method_options: {
        api_key: ENV['SENDGRID_API_KEY'] 
      }
    )
  end

以前のRailsはjquery-ujsを使っていたみたいで、rails-ujsでのdata-confirmダイアログの変更方法が見つからなかったのでjquery-ujsのoverride方法を参考にしながら、試行錯誤しつつdata-confirmmの挙動を変更しました。showConfirmDialog内をお好きなmodalモジュールに変更すれば動くはず。今回はUIKitを使っていたのでそれを使いました。

var handleConfirm = function(element) {
    if (!allowAction(this)) {
      Rails.stopEverything(element)
    }   
  }
  var allowAction = function(element) {
    if (element.getAttribute('data-confirm') === null) {
      return true
    }   
    showConfirmDialog(element);
    return false
  }
  var confirmed = function(element, result) {
    if (result.value) {
      // User clicked confirm button
      element.removeAttribute('data-confirm')
      element.click()
    }   
  }
  var showConfirmDialog = function(link) {
    var message = $(link).attr('data-confirm');
    UIkit.modal.confirm(message).then(function(){
      confirmed(link, {value: true});
    }); 
  }
  $("a[data-confirm]").on('click',handleConfirm);

sitemap_generator gem

sitemap作成でハマったのでメモ。Herokuで動的なsitemapを作る一つの方法として、s3を使ったsitemap配信があります。ググれば、たくさんブログなどあるのですが、aws-sdkのバージョン２を使ったものがメイン。今回はaws sdk version3で構築してたのでAws::S3::Errors::AccessDenied: Access Deniedが出て時間を無駄に消費しました。

require 'aws-sdk-s3'が必要なのはissueを漁ればわかりました。

#config/sitemap.rb
require 'aws-sdk-s3'
SitemapGenerator::Sitemap.sitemaps_host = "https://s3-ap-northeast-1.amazonaws.com/YOUR_BACKET/"
SitemapGenerator::Sitemap.adapter = SitemapGenerator::AwsSdkAdapter.new(
  "YOUR_BACKET",
  aws_access_key_id: ENV['AWS_ACCESS_KEY_ID'],
  aws_secret_access_key: ENV['AWS_SECRET_ACCESS_KEY'],
  aws_region: 'ap-northeast-1' 
)

Aws::S3::Errors::AccessDenied: Access Deniedですが、s3のバケットをpublicにしていないと出ていました。なので、コンソールから下記を追加すればOK。