2017/06/22

blogger を https 対応させる

タイトル通り。 自分のブログのポストを見たら http だったので今の時代これはまずいなー、と。

どうやら http -> https のリダイレクトもしてくれるようなので設定しない手は無い。
blogger > 設定 > 基本 > HTTPS > HTTPSリダイレクト にチェックを入れる。
これで https 対応とリダイレクトもしてくれる。便利。

参考

Jenkins でビルドの情報を Slack に投稿する

Jenkins ネタでもう一つ。
ビルドの開始や失敗、成功を Slack に流したくなったのでそのログ。


環境

  • CentOS Linux release 7.0.1406 (Core)
  • Docker version 1.12.6, build 1398f24/1.12.6
  • Jenkins ver. 2.46.3
  • Slack Notification Plugin 2.2


構築方法(Slack)

  • Slack 側の Add Integration で Jenkins を指定
  • 通知させたいチャンネル名を指定
  • 発行された token をコピーしておく


構築方法(Jenkins)

  • Manage Jenkins > Plugin Management > Available
    • Slack Notification Plugin をチェック
    • install without restart 
  • Manage Jenkins > Plugin Management
    • team subdomain: 通知したい Slack の subdomain
    • 例えば hoge.slack.com なら hoge
    • Integration Token は先程コピーした  token で
    • Channel は通知したいチャンネル
    • Is Bot User ? にはチェックを入れない
  • Test Connection できちんと Slack にポストされていれば設定はOKです


構築方法(Jenkins Project)

  • 通知させたい Project の Configure を開く
  • Post-build Actions
    • に Slack Notifications を追加
    • 通知させたいイベントにチェックを入れる
  • Project > serval > Post-build Actions > Advanced
    • は特別設定しなければ先程のグローバル設定が使われるので空白で良いです
    • 私は Notification message includes を commit list with authors only に設定しました


まとめ

この設定をすることで  Jenkins がビルドした時に Slack へ通知が行なわれます。
今回面倒だったこととしては、 Is Bot User? にチェックを入れていた時、Test Connection ではきちんと通知がされるのに、ビルドした時だけは通知がされないという絶妙な状態になることがありました。どうしてチェックを入れたらダメなのだろ。


参考

2017/06/20

Docker で古いコンテナとイメージを消す

Docker で適当にコンテナを作っていたり、CI とかをしていると使われなくなったコンテナが大量に積もっていきます。
それを適当に消したのでそのメモ。


環境

  • CentOS Linux release 7.0.1406 (Core)
  • Docker version 1.12.6, build 1398f24/1.12.6


コマンド

  • docker ps -aq | tail -30 | xargs  docker rm
基本的には古いものから消していく方針で。
images の option で -q を付けると hash だけを出してくれます。
あと -f で特定の条件のみで絞りこみをしてくれるようです。
  • docker ps -qaf "status=exited"
とかすると止まってるのだけ出してくれる。
動いてるコンテナは -f を付けない限り消さないので、 とりあえず全部 rm に渡してしまうのもありかも。

あとはイメージを消すだけです
  • docker images -aq | xargs docker rmi
こいつも使われているイメージは -f を付けない限り残してくれる。
なのでとりあえず消せそうなもの全部消そうとしてみる、とか可能です。

  • docker images -qf dangling=true
とかでタグが付いていないイメージだけを対象にする、というコマンドが参考記事にありましたが、今回はタグが付いているイメージもあるので -aq で。


まとめ

  • docker ps -aq | xargs  docker rm
  • docker images -aq | xargs docker rmi
とかでとりあえず起動していないコンテナ以外消えます。
新しい docker だと docker image prune とかあるらしいのでもっと楽かも。


参考文献

2017/06/13

Volume 指定を忘れた Docker からデータを取り出す

Jenkinsをたてた時、最初はボリュームを指定せずに docker run していました。
後からポートフォワードを追加しようと思って、一旦イメージを commit 。
そのイメージにオプションを追加して起動しても Jenkins が初期化されている。

どうやらボリュームを指定していないとどこかにボリュームを勝手に作るらしい。
なので今まで作業していた分を commit してもコンテナに反映されない。
ということでどこかに作られたボリュームを探せればデータを復旧できそう。

  • docker inspect <container-name>
するといろいろ出てくるがその中に怪しいものが。
Mounts の Source にパスがあるのでこいつっぽい。

  • cp -r /var/lib/docker/volumes/98ef888300af713d65b6d7534d835c7bd2e95270ad5eb016da749bbbb5f6d409/_data hoge
  • docker run -itd -P -v /foo/bar/hoge:/var/jenkins_home jenkins
とかすると復活。やったね。

環境

  • CentOS Linux release 7.0.1406 (Core) 
  • Docker version 1.12.6, build 1398f24/1.12.6

GitHub に push された時に Docker 上の Jenkins から SSH 越しでコマンドを実行する

長いタイトルですがやりたい事は以下です。

  • Jenkins 経由でデプロイ
  • デプロイするタイミングは GitHub の master が更新された時
  • Jenkins は Docker で起動しておく
  • デプロイに使用するコマンドは SSH 経由で本番サーバに適用

さて、タイトル通りややこしい状態なので記事もだいぶ読み辛いものになりそうです。


環境

  • CentOS Linux release 7.0.1406 (Core) 
  • Docker version 1.12.6, build 1398f24/1.12.6
  • Jenkins 2.46.3


Docker でやること(Jenkins を起動する)

  • docker run -itd --privileged --name kaban -v /hoge/fuga:/var/jenkins_home -P jenkins
    • これで Jenkins が立ち上がります
    • --name で名前を付けておくと楽です。とりあえずかばんちゃんです。
    • Jenkins はデータの永続化のためにボリュームを使っています
    • 適当なディレクトリを /var/jenkins_home にマウントしてください
    • Jenkins は uid 1000 なので chown 1000 -R <dir> などをしておくと良いです
    • もしくは chmod で適切な permission を与えてください
    • -P でポートマッピングを適当にやってもらいます。
  • docker exec -it kaban cat /var/jenkins_home/secrets/initialAdminPassword
    • 後で Jenkins を起動した際に要求される初期パスワードです。


Jenkins でやること(初期設定)

  • docker ps をして、8080 がどのポートに割り当てられているか確認します。
  • ブラウザから Jenkins にアクセスします (http://localhost:32769 とか)
  • まず初期パスワードを使って Jenkins を起動します
  • 適当に Install Suggested Plugin を選択します(これに Github Plugin とか入ってたので)
  • 管理者ユーザを作ります
  • Manage Jenkins > Manage Plugins から Available > Publish over SSH を選択します
    • Publish over SSH プラグインを使ってデプロイします
  • Install without restart で Publish over SSH を入れます
  • Configure System > Publish over SSH でデプロイ用サーバに SSH できる設定をします
    • SSH Servers > Add でサーバを追加します
    • Name や Hostname や Username 、 Key か Password を設定します
  • これで土台ができました。


GitHub でやること

  • デプロイ対象のプロジェクトのリポジトリページに行きます
  • Settings > Hooks&Services > Add Service から Manage Jenkins(Github Plugin) を入れます
    • Git Plugin もありますが今回は GitHub Plugin なので間違えないように
  • Jenkins hook URL に Jenkins の URL を指定します
    • http://192.168.0.1:32769/github-webhook/ とかです
  • これで push された際に Jenkins へ通知がいきます。


Jenkins でやること(プロジェクトの設定)

  • New Project から Freestyle Project を作ります
  • GitHub Project に check をいれます
    • なので最初から GitHub Project で作っても良いかも?
    • Repository URL は GitHub の Project URL を指定してください
    • Branch Specifier は */master で良いです。 master に変更があった時のみにデプロイなので
  • Build Triggers で GitHub hook trigger for GITScm polling に check を入れます
  • Build で Send files or execute commands over SSH を指定します。
    • SSH Server は先程 Configure で追加したデプロイサーバを指定します。
    • Transfars: Exec command で SSH 後に実行したいコマンドを指定します。
  • これで完了です。 GitHub の master が更新されると自動で SSH 経由でコマンドが発行されます。


長い道のりでしたがこんな感じで。

ウィンドウマネージャの Spectacle.app を入れてみた

普段はデュアルディスプレイ環境での作業が多いのですが、最近はシングルディスプレイ環境での作業も増えてきました。
私は大体のウィンドウを最大化して使うので、基本 Terminal.app + ブラウザ で二つのディスプレイが埋まっています。
Terminal.app を透過させる手もあるのですが、ちょっと私には向かなかったです。
シングルディスプレイ環境だと、どうしてもウィンドウを切り替えまくる必要があって面倒です。
ということで、この際思い切ってウィンドウマネージャを入れてみました。
今回入れたのは Spectacle.app というやつです。 @_akiyoshiaki_ さんに教えてもらいました。


環境

  • macOS Sierra 10.12.5
  • Spectacle.app 1.2


導入方法

cask に入っているので
  • $ brew cask install spectacle
で導入できます。
あとはディスプレイを動かすことを許可させるために
  • System Preference > Security & Privacy > Accessibility
の Spectacle のチェックを入れます。


設定

私は基本的に二つの画面が見えたら良いので、画面を縦か横に二分割するアクションのみ設定しています。
具体的な設定としては以下のような感じ。 Cmd + 矢印を使っています。

  • Left half : Cmd + ←
  • Right half: Cmd + →
  • Top half: Cmd + ↑
  • Bottom half: Cmd + ↓
  • Full Screen : Cmd  + Enter

設定したものの、実際一番使うのは分割ではなく Full Screen だったりします。
この Full Screen は Mac の Full Screen とは別で、ウィンドウを画面いっぱいに表示する方の Full Screen です。
昔の Mac ではウィンドウの緑のボタンをクリックするとなるやつです。
Sierraだと option を押しながら緑をクリックするやつ。
とりあえずウィンドウを操作する手間を省けそうなのでしばらくは使ってみようと思います。

2017/06/08

GitHub Badge なるものを設定してみた

GitHub Badge なるものを設定してみた。

一応このブログの右側には私の各種アカウントを書いているのだけれど、リンクを列挙しているのみなのでちょっと素っ気無かった。
どこかのブログで Github Badge を使っているのを見付けて、単なるリンクより見栄えも良さそうなので使ってみることにしました。

ちなみにこういうものです。

どのリポジトリでも .DS_Store や swp ファイルを git に commit しないようにする

git init する度に .gitignore を設定するようにしているのですが、迂闊に git add . とかをして .DS_Store などの入れたくないファイルを git に commit してしまうことが何度も発生。

何回も発生するのなら対策しておこう、ということで、どの git リポジトリでも特定のファイルを ignore するようにしました。

とはいっても ~/.config/git/ignore に ignore するファイルを指定するだけ。
これでどのリポジトリでも .DS_Store などの指定したファイルが ignore されます。便利。

にしても ~/.config で書く流儀だと ~/.gitconfig はどう書いたら良いのだろうか。


参考文献

2017/06/02

tmux 2.5 を全角記号対応させる

2017/05/13 に tmux 2.5 が Release されていたので、2.3を全角記号対応させた時のパッチを 2.5 にも当てました。
tmux 2.5 の border-ascii + EastAsianAmbiguous を強制2幅 版です。

作業としては rebase のみでパッチそのものの変更点はありません。

環境

  • macOS Sierra 10.12.5
  • Homebrew 1.2.1-143-gdaa67886
  • Homebrew/homebrew-core (git revision cce65; last commit 2017-06-02) 
  • tmux 2.5 (hash だと ae2c5ad76852d6d2e2463e45b13fc8c15b66e4b7 )
  • utf8proc 2.1
  • フォントは Ricty

インストール手順

  • $ brew tap atton-/customs
  • $ brew install atton-/customs/utf8proc
  • $ brew install --HEAD atton-/customs/tmux

過去のバージョンが利用したい方は /usr/local/Homebrew/Library/Taps/atton-/homebrew-customs
 などにある atton-/customs/tmux の git repository から古いバージョンを checkout してください。
他にも昔のバージョンを参照する方法はあると思いますがちょっと把握していません。

2017/04/22

tmux 2.4 を全角記号対応させる

2017/04/20 に tmux 2.4 が Release されていたので、前回の記事に書いたパッチを 2.4 にも当ててみました。
tmux 2.4 の border-ascii + EastAsianAmbiguous を強制2幅 版です。

作業としてはは rebase したただけなので修正点は全くありません。

環境

  • macOS Sierra 10.12.4
  • Homebrew 1.1.12-40-g02f018933
  • Homebrew/homebrew-core (git revision 5559; last commit 2017-04-15)
  • tmux 2.4 (正確には 2.4リリース以降の fd13731049148d0205fa6ed1843041dad0573677)
  • utf8proc 2.1
  • フォントは Ricty

インストール手順

  • $ brew tap atton-/customs
  • $ brew install atton-/customs/utf8proc
  • $ brew install --HEAD atton-/customs/tmux


atton-/customs/tmux の formula は HEAD build しか対応していないので、もし 2.3 のパッチ版が使いたい場合は tap したリポジトリを巻き戻すことで 2.3 が使えるはずです。
おそらくもっと楽な巻き戻し方があると思いますが、個人的には最新しか使っていないので調べていません。

2017/04/16

tmux 2.3 を全角記号対応させる

tmux 2.3 をちょっといじって全角記号の幅を2にした版を作ってみました。


環境

  • macOS Sierra 10.12.4
  • Homebrew 1.1.12-40-g02f018933
  • Homebrew/homebrew-core (git revision 5559; last commit 2017-04-15)
  • tmux 2.3 (正確には 2.3リリース以降の 640666fb36d7465b188f9d0bedc83ad60b83a1d7)
  • utf8proc 2.1
  • フォントは Ricty



状況

tmux を使っていると ─(U+2500) や(U+25bd) な文字の幅が半角扱いになってしまい、表示がおかしくなる時があります。
例えば、画面を縦2つに分割すると



のように線が何故か二本表示されたり、記号の表示が変になってしまいます。

これは分割に使用されている文字(─)の幅の扱いを tmux が勘違いしているために起こる問題です。
─ といった記号は EastAsianAmbiguous といった種類に区分され、言語圏によって文字幅が違います。
例えば英語圏では基本的に使う文字幅は1なので ─ の幅は1ですが、日本語圏では全角が基本なので文字幅は2となります。
この問題に関しては https://github.com/hamano/locale-eaw などが詳しいです。


解決法

これは Terminal の設定と locale の設定とフォントに依存するので解決方法はいくつかあります。
今回は
  • Terminal は EastAsianAmbigous を Full-Width にしている
  • フォントは日本語フォント( EastAsianAmbiguous は幅2)
  • locale には依存しない (en_US.UTF-8 でも ja_JP.UTF-8 でもOK)
の時を想定しています。
具体的には tmux が文字幅の取得に使っている utf8procちょっといじって、EastAsianAmbiguous の幅を強制的に2にしています。
あと、画面分割に使う文字を ascii にしています。


インストール方法

formula にしてあるので

  • $ brew tap atton-/customs
  • $ brew install atton-/customs/utf8proc
  • $ brew install --HEAD atton-/customs/tmux
でインストールできます。
縦に分割した時に


のようにきちんと線が1本になるはずです。



まとめ

強制的に EastAsianAmbiguous の幅を2にして日本語フォントとの相性を良くしました。
実はこれは対処療法的な解決案で、根本的な解決ではありません。
その辺りは結構長くなると思うので書くなら別の記事で書きます。


参考文献