Confluence CloudでカスタムCSSが使えない

個人で利用しているわけではないのですが、Confluence CloudではカスタムCSSが制限機能になっています。
参考) https://ja.confluence.atlassian.com/confcloud/restricted-functions-in-confluence-cloud-734070955.html

カスタムCSSだけでなく、他の多くの機能も制限されていますね。

デフォルトのテーマ

Confluence Cloudデフォルトのテーマだと、h2,h3などの違いが非常に分かり辛いことを知っていますか?

これがデフォルトのテーマなんですが、非常に見づらいですよね。
他のドキュメントを漁ると、テーマをインストールすればいいんだよとか書いてるんですが、Confluence Cloudではインストールする方法が利用者側にないです。
本当に悲しい。

それでもレイアウトは変えたい

それでもレイアウトは変えたいですよね。
俺は変えたいです。
だって見づらいもん。

ちょっと冗長になるかもしれないですが、一番簡単な方法は、各ページにStyleマクロを埋め込んでCSSを書いていくことです。

後は、このStyleマクロを埋め込んだテンプレートを用意しておくのがベターでしょう。

カスタムCSS制限するなら、もう少し見やすいテーマにしてほしい。

/vagrantにマウントしない時のやり方と注意

CentOS公式のBoxを使い、/vagrantに現在のディレクトリをマウントしない時のVagrantfileについてのメモ。

/vagrantではなく他のディレクトリにマウントする

/vagrantではなく他のディレクトリに、現在のディレクトリをマウントする時は、2つやることがある。
/appにマウントする想定で話を進める。

  • /vagrantへマウントしないようにするsynced_folderを定義する
  • /appへマウントするsynced_folderを定義する

/vagrantへマウントしないようにするsynced_folderを定義する

前者についてだが、明示的に/vagrantへのsynced_folderを定義しなくても、勝手にマウントしようとする。
これが非常に厄介だ。
そうさせないために、/vagrantへマウントしないsynced_folderを定義する必要がある。

config.vm.synced_folder '.', '/vagrant', disabled: true

最後のdisabled: trueがミソである。
こう書くことで、/vagrantへマウントしなくなる。

/appへマウントするsynced_folderを定義する

これは簡単。

config.vm.synced_folder '.', '/app', type: :nfs

これで/appにマウントされる。

ansible_localで構成管理する

ansible_localで構成管理する時で、/vagrantへマウントさせないとエラーを吐く。
ansible_localを指定した時は、/vagrantをカレントディレクトリとしてplaybookに指定されたファイルを探しに行く。
以下のような場合は、/vagrant/playbooks/ruby.ymlを探しに行ってしまう。

config.vm.provision "ruby", type: "ansible_local" do |ansible|
  ansible.playbook = 'playbooks/ruby.yml'
  ansible.install = true
end

んじゃ、どうしたらカレントディレクトリを変更できるか。
Vagrantのドキュメントにあるprovisioning_pathに、そのディレクトリを指定すれば良い。

config.vm.provision "ruby", type: "ansible_local" do |ansible|
  ansible.playbook = 'playbooks/ruby.yml'
  ansible.install = true
  ansible.provisioning_path = '/app'
end

/vagrantにマウントしない時なんてそうそうないんだけど、そういうことがあれば注意していきたい。

最後に

他にも注意点はあると思うけど、今日ハマったことはこんなところなので、とりあえずこんなもんで。

早い話、provisionで/vagrantを/appにリンクさせればいいんだけどね。

Mac miniを使ってみて 

そんな書くことはないんだけど、Mac miniを使って1年ぐらい経つと思うので、感想を。
あんまり参考になるようなことは特に書いてないと思います。

スペック

Mac mini(late 2014)でディスク以外を最上位にした。
詳細は覚えてない。

使用感

仮想マシンを1つ立ち上げて開発しつつ、Chrome50タブぐらいは割りと余裕。
ただ複数の仮想マシンを立ち上げるとなると、コア数が少ないから気になる。
コア数気になるなら、Mac Proでも買っとけばいいと思う。
Macである必要がないなら、BTOか自作した方が絶対いいけど。

最後に

普段開発する分には特に問題ない。
Mac mini買うぐらいなら、Macbook Pro買った方がいいと思う。
持ち運べるし。
Mac miniも持ち運べるけど…ね?

bashrcに環境変数が定義されていなければ設定する

.bashrcに環境変数が定義されていなければ設定するメモ。
ぶっちゃけ他にいい方法が普通にあると思うからググった方が早いと思う。

普通に環境変数を定義する

単純に定義するだけなら、普通にechoで書き込む。

echo 'export GOROOT=/usr/lib/golang' >> ${HOME}/.bashrc

bashrcに未定義の場合のみ定義する

最近はAnsibleを触ることが多いので、何度も実行されないように書く。
他にいいやり方はあるんだろうけど、とりあえずはgrepの結果が空文字列であるかどうかで判断。

if [ "$(grep 'GOROOT' ${HOME}/.bashrc)" == "" ]; then
  echo 'export GOROOT=/usr/lib/golang' >> ${HOME}/.bashrc
fi

ダサい気もするけど、パッと思いついたのはこれだし、当分はこれで行く。

GCE無料枠のTerraform定義

Google Cluod Platformでは、 Always Freeという制度があり、様々なリソースに対して無料枠を用意ししています。
各リソースの無料枠については、こちらのページを参照した方がいいと思います。

GCEの無料枠

もちろん、GCEことGoogle Compute Engine(AWSで言えばEC2にあたる)にも無料枠が存在します。

以下が、無料枠についての説明です。
引用) https://cloud.google.com/compute/pricing?hl=ja

1 つの f1-micro VM インスタンス(1 か月あたり、バージニア州北部を除く米国リージョン)
30 GB の HDD 永続ディスク ストレージ(1 か月あたり)
5 GB のスナップショット ストレージ(1 か月あたり)
1 GB の北米から他のリージョン宛て下り(1 か月あたり、中国およびオーストラリアを除く)

ということなのです。

インスタンスサイズ

インスタンスサイズは、無料枠の説明に書いてある通り、f1-microです。
スペックは、CPUは仮想CPUが1つ、メモリが0.6GBというサイズですね。
性能が良いとはお世辞にも言えないので、用途は限られそうです。

リージョン

バージニア州北部のリージョン名が分からないのですが、オレゴン・アイオワ・サウスカロライナが対象です。

  • オレゴン … us-west1
  • アイオワ … us-central1
  • サウスカロライナ … us-east1

ディスク

ディスクに関しては特にいうことはないですが、SSDではないことに注意。
日本語のドキュメントでは、標準設定容量と言われているHDDのことですね。

ネットワーク

GCEでは上りが無料なので、下りのみで考えます。
料金はこちらに書いてますが、対象の米国リージョンでは、0~1TBの使用に関しては$0.12のようです。
f1-microでこれを超えるような事は、そうそうないと思います。

無料枠のTerraform

GCEの無料枠で使えるインスタンスの定義を、書いておきます。

resource "google_compute_instance" "default" {
    name            = "test"
    machine_type    = "f1-micro"
    zone            = "us-east1-a"

    disk {
        image = "centos-7-v20170719"
    }

    network_interface {
        network = "default"

        access_config {
        }
    }
}

追加ディスクない最小限構成です。

もっと大きいインスタンス使いたいけど、自分のお金ではやりたくないですね……

VagrantのAnsible Local Provisionerの実行ユーザー

開発環境は、Vagrantで構築することが多くなりました。
Vagrantでは、Ansible Local Provisionerという機能があり、VMへのAnsibleのインストールやPlaybookに従って構成管理出来ます。
そう、Ansibleの実行時にハマりました。

要点だけ書くと、remote_userで実行ユーザーを指定しても、そのユーザーで実行されないのです。
例えば、以下のようなplaybookだと、systemdモジュールのところでエラーになります。(Boxはcentos/7

- hosts: all
  remote_user: root
  become: false
  tasks:
    - name: install epel-release
      yum:
        name: epel-release
        state: present
      become: true
    - name: update packages
      yum:
        name: '*'
        state: latest
      become: true
    - name: install yum-utils
      yum:
        name: yum-utils
        state: present
      become: true
    - name: install device-mapper-persistent-data
      yum:
        name: device-mapper-persistent-data
        state: present
      become: true
    - name: install lvm2
      yum:
        name: lvm2
        state: present
      become: true
    - name: add docker repo
      shell: 'yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo'
      args:
        chdir: '/etc/yum.repos.d'
        creates: docker-ce.repo
      become: true
    - name: install docker-ce
      yum:
        name: docker-ce
        state: present
      become: true
    - name: restart docker
      systemd:
        name: docker.service
        state: restarted
        daemon_reload: yes
        enabled: yes
      changed_when: false
      become: true

remote_userでrootを指定しているので成功するように思ってたんですが、これじゃダメでした。
これだ!っていう情報が見つからなかったですが、何を指定しようとvagrantユーザーで実行されます。
そのため、

  • sudoで実行する必要がある箇所にのみ、become: trueをつける
  • トップレベルでbecome: trueにし、sudoで実行する必要がないところだけbecome: falseにする

あたりが、落としどころこかなぁと思いつつ。

Alpineのパッケージ一覧

仕事ではDockerに触れる機会が余りないのですが、プライベートでは結構使っています。
Dockerを本格的に使うと、Dockerイメージのサイズ削減に勤しむことになるんですが、ベースイメージをAlpineにすることが多くなります。
Alpineだとパッケージが提供されておらず、自前ビルドする必要がある時が多いため、そのビルドに必要なパッケージが存在するのか確認したい時が多々あります。
そういう時は、Alpine packagesで必要なパッケージを探せます。

適当にコンテナ立ち上げて探した方が早いんですが、立ち上げられない時に利用する時には便利です。

BitbucketのプライベートリポジトリをCircleCIでビルドする時にハマった

楽できるCIツールないかなぁと探しているんですが、CircleCIをよく聞くので利用しようと思い、試してみました。

仕事でも使えればいいなぁと思い、実際に使ってみようとBitbucketのプライベートリポジトリで試したところ、ビルド結果が未ログインユーザーでも見れてしまうことが確認出来てしまいました。

ビルド結果が見える?

すでにCircleCIを利用している方などから話を聞いてみたのですが、「404 Not Found」とのことでした。
話を聞いた人がGithubのプライベートリポジトリを利用している方でしたので、Bitbucket特有の問題かなぁと思い、調査してみました。

本当に見えるのか

先に結論を言うと、設定ミスでした!すいません!

設定ミスというか初期設定が予期せぬ設定になっているのが、原因でしたね。
初期設定のままだと、何が問題だったかというと

  • 未ログインユーザーでビルド結果が閲覧可能(標準出力や.circleci/config.ymlが閲覧可能)
  • URLフラグメントの推測が容易なので、未ログインユーザーで成果物(artifact)が取得可能

結構ヤバそうですよね。
なんで、ちょっと注意点を。

何故、ビルド結果が見える?

Bitbucketについてだけ言っていきます。(Githubはならないという話ですし、Githubの有料アカウント持ってない)
Add Projectでリポジトリを選択すると、そのリポジトリがプライベートであろうとなかろうと、ビルド結果が見えるような初期設定になっているようです。
これは、Free and Open Sourceという設定が、初期でONになっているためのようでした。

そのため、プロジェクト追加後は、この設定を出来る限り早くオフにすることを推奨します。(ビルド結果を公開したい場合は除く)

最後に

ちゃんと設定を見て見つけておけば良かっただけですので、こういうことがないように出来る限り注意してきたいと思います…
リプライなどをくれた皆さん、ありがとうございました。

もし、Bitbucketのプライベートリポジトリを連携する時は、注意してくださいね!

Let’s Encryptの証明書を導入してみました

特に難しいこともなく、割りと簡単に導入することが出来ました。
すでに公開されているサーバーであれば、比較的簡単に導入出来ますし、Dockerで構築している方は、便利なイメージなども公開されているので探してみてくださいね。

本当にハマりどころ無かったのが逆に怖い

Devise関連のControllerの親クラス

BigQueryを使う仕事が、ちょっと暇になってしまったので、またRails周りの記事を少し。

Devise関連のControllerの親クラス

Ruby on Railsを使っている人達では有名なDeviseですが、その中で使われているControllerが何を継承しているのか追ってみます。(2017年7月19日 v4.3.0時点)

Devise::SessionsController

まずは、Deviseを使う時に必ず見かけると言っても過言ではないDevise::SessionControllerを見ましょうかか。
このクラスの定義はapp/controllers/devise/sessions_controller.rbになります。

先頭の数行を抜粋してみてみると、

class Devise::SessionsController < DeviseController
  prepend_before_action :require_no_authentication, only: [:new, :create]
  prepend_before_action :allow_params_authentication!, only: :create
  prepend_before_action :verify_signed_out_user, only: :destroy
  prepend_before_action only: [:create, :destroy] { request.env["devise.skip_timeout"] = true }

DeviseControllerを継承していますね。
それでは、次にDeviseControlelrの定義を見ましょうか。

DeviseController

このクラスの定義はapp/controllers/devise_controller.rbです。

こちらも抜粋。

# All Devise controllers are inherited from here.
class DeviseController < Devise.parent_controller.constantize
  include Devise::Controllers::ScopedViews

どうやら、DeviseControllerの親クラスは、Devise.parent_controller.constantizeで評価時に動的に決まっているようです。
それじゃ、このparent_controllerの中身は一体何なのでしょうか?

Devise

Deviseは、lib/devise.rbで定義されています。
こちらで、parent_controllerを探してみましょう。

では、抜粋!

  # The parent controller all Devise controllers inherits from.
  # Defaults to ApplicationController. This should be set early
  # in the initialization process and should be set to a string.
  mattr_accessor :parent_controller
  @@parent_controller = "ApplicationController"

はい、定義が見つかりましたね。
parent_controllerの中身は、ApplicationControllerという文字列のようです。
つまり、ApplicationControllerがDeviseControllerの親クラスでした。

そのため、ApplicationControllerで定義しているメソッドなどがDevise::SessionsControllerなどでも利用可能であり、コールバックを定義しているなら実行されてしまうわけです。

DeviseControllerの親クラスを変更する

こちらは、難しいこともないです。
抜粋したコード内のコメントを見てもらうと分かるのですが、initializerで変更することが可能です。

変える時は、以下をinitializerに追記してください。

config.parent_controller = 'OtherController'

簡単ですよね。

最後に

業務のRailsアプリでは、1つのアプリ内に管理画面とフロント画面のCMSを構築することも多いです。
となると、それぞれのApplicationControllerが定義されたりすることがあります。
そういう時にDevise関連のControllerの親クラスを意識せずに使用して、意図しない動作になりうることもあります。
今回は、その一例です。
Gemを利用する場合は、しっかり使う範囲だけで良いので、挙動を把握しておくといいかもしれませんね。

管理画面とフロント側を凄く分けたい…