mawatari.jp https://mawatari.jp ウェブエンジニアのメモ帳 Tue, 08 May 2018 05:25:21 +0000 ja hourly 1 https://wordpress.org/?v=4.9.25 RDS (MySQL) からファイル出力 (TSV,CSV) する https://mawatari.jp/archives/export-from-rds-mysql https://mawatari.jp/archives/export-from-rds-mysql#respond Wed, 02 May 2018 06:42:56 +0000 http://mawatari.jp/?p=2454 Continue reading]]> RDS (MySQL) からデータをTSVやCSVで出力する方法をメモしておきます。
様々な方法は存在しますが一例として。

まずは出力したいデータを抽出するSQLを作成し、ファイルに保存します。

CONCAT()
関数を利用してダブルクオートで挟み込みます。

SELECT
    CONCAT('"', field1, '"') AS field1,
    CONCAT('"', field2, '"') AS field2,
    CONCAT('"', field3, '"') AS field3,
    CONCAT('"', field4, '"') AS field4,
    CONCAT('"', field5, '"') AS field5
FROM
    user

そのファイルの内容を展開させる形で実行し、結果を保存すればTSVファイルの完成です。

mysql -u user_name -D database_name -p -h db.host.local -e "`cat extract.sql`" > result.tsv

CSVが欲しければ、下記のようにタブをカンマに置換しましょう。

mysql -u user_name -D database_name -p -h db.host.local -e "`cat extract.sql`" | sed -e 's/\t/,/g' > result.csv

以上です。

]]>
https://mawatari.jp/archives/export-from-rds-mysql/feed 0
エラー対応:cannot update mailbox /var/mail/root for user root. error writing message: File too large https://mawatari.jp/archives/cannot-update-mailbox-var-mail-root-for-user-root-error-writing-message-file-too-large https://mawatari.jp/archives/cannot-update-mailbox-var-mail-root-for-user-root-error-writing-message-file-too-large#respond Thu, 12 Apr 2018 10:04:20 +0000 http://mawatari.jp/?p=2449 Continue reading]]>

cannot update mailbox /var/mail/root for user root. error writing message: File too large

/var/log/maillog
に上記のようなエラーが出ていた場合、メールボックスの上限に達していることがほとんどです。
メールボックスをクリアするか上限を上げましょう。ただし、安易に上限を上げてしまうとディスク圧迫に繋がるので、メールボックスがいっぱいにならないよう、運用を見直すことを先に考えましょう。

vi /etc/postfix/main.cf
# mailbox_size_limitを100MBにする例
mailbox_size_limit = 102400000
# mailbox_size_limitを無制限にする例(安易に行うのは危険)
mailbox_size_limit = 0
postfix reload

実際のところ、どれくらい保存できるものなのか気になったので調べてみたら、有益な情報を見つけましたので共有しておきます。
Postfixのmailbox_size_limitについて調べてみる | Qiita

メールボックスを空にするには以下のように行います。

cat /dev/null > /var/mail/root

以上です。

]]>
https://mawatari.jp/archives/cannot-update-mailbox-var-mail-root-for-user-root-error-writing-message-file-too-large/feed 0
MySQLのSHOW TABLESでコメント他も合わせて表示する https://mawatari.jp/archives/how-to-display-comments-into-show-tables https://mawatari.jp/archives/how-to-display-comments-into-show-tables#comments Thu, 20 Oct 2016 02:19:17 +0000 http://mawatari.jp/?p=2432 Continue reading]]> MySQLの
SHOW TABLES
にテーブル名以外の情報も合わせて表示する方法をメモしておきます。

SHOW TABLESにテーブルコメントを追加して表示する方法

テーブル名の一覧を得る場合は

SHOW TABLES
、それ以外の付帯情報も表示する場合は
SHOW TABLE STATUS
を利用します。しかし、どちらともカラムの絞込や条件を加えることはできません。
そんなときは
information_schema
を利用します。
information_schema.tables
から
SELECT
すればカラムの絞り込みが可能です。

SELECT table_name, table_comment FROM information_schema.tables WHERE table_schema = database();
+---------------------+-----------------------+
| table_name          | table_comment         |
+---------------------+-----------------------+
| campaigns           | キャンペーン情報      |
| groups              | グループ情報          |
| prefectures         | 都道府県マスタ        |
| users               | ユーザー情報          |
+---------------------+-----------------------+
4 rows in set (0.00 sec)

WHERE table_schema = database()
として、現在閲覧中のデータベースを対象としています。セレクト文なので、用途に合わせて自由に条件を付け加える事が可能です。
INFORMATION_SCHEMAテーブルのカラムや関連する情報はMySQLの公式ドキュメントを参照してください。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 21 INFORMATION_SCHEMA テーブル

以上です。

]]>
https://mawatari.jp/archives/how-to-display-comments-into-show-tables/feed 1
Amazon Linuxのバージョン確認コマンドとアーキテクチャ確認コマンド https://mawatari.jp/archives/check-amazon-linux-version https://mawatari.jp/archives/check-amazon-linux-version#respond Thu, 06 Oct 2016 02:51:33 +0000 http://mawatari.jp/?p=2428 Continue reading]]> Amazon Linuxの操作感は、他のRedHat系のディストリビューションとほぼ同じですが一部で違いもあります。例えばリリースファイルはCentOSでは
/etc/redhat-release
ですが、Amazon Linuxでは
/etc/system-release
です。

Amazon Linuxのバージョンを確認するコマンド

cat /etc/system-release
# Amazon Linux AMI 2016.09.0 (HVM), SSD Volume Type - ami-1a15c77bの表示例
Amazon Linux AMI release 2016.09

アーキテクチャ(OSが32bit, 64bitどちらなのか)を調べるコマンド

arch
# 以下のように表示されます
# 64bitの場合
X86_64
# 32bitの公式AMIはありません

# 以下のコマンドでもOK
uname -a
# Amazon Linux AMI 2016.09.0 (HVM), SSD Volume Type - ami-1a15c77bの表示例
Linux ip-172-31-31-142 4.4.19-29.55.amzn1.x86_64 #1 SMP Mon Aug 29 23:29:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

]]>
https://mawatari.jp/archives/check-amazon-linux-version/feed 0
PHPのエラーメッセージを出力する https://mawatari.jp/archives/how-to-display-php-errors https://mawatari.jp/archives/how-to-display-php-errors#respond Wed, 05 Oct 2016 07:35:38 +0000 http://mawatari.jp/?p=2424 Continue reading]]> PHPのエラーメッセージを出力する方法をメモしておきます。
以下は全てのエラーを出力する例です。エラーレベルの詳細については公式ドキュメントを参照してください。
PHP: error_reporting – Manual

display_errors = 1
error_reporting = E_ALL

ini_set('display_errors', 1);
error_reporting(E_ALL);

httpd.conf
.htaccess
のようなPHPの外部ではビットマスク値を使用する必要があります。
PHPのバージョンによって値が異なるため注意が必要です。詳しくは公式ドキュメントを参照してください。
PHP: 定義済み定数 – Manual

php_value display_errors 1
php_value error_reporting 32767

PHP5.2.4以降であれば、

display_errors
の値に
stderr
を使用できます。

ini_set('display_errors', 'stderr')
error_reporting(E_ALL);

CLIで

php check_display_error.php > /dev/null
等と入力し実行してみると、その違いがわかります。

以上です。

]]>
https://mawatari.jp/archives/how-to-display-php-errors/feed 0
ServerspecでMacの開発環境をテストする https://mawatari.jp/archives/testing-mac-with-serverspec https://mawatari.jp/archives/testing-mac-with-serverspec#respond Tue, 21 Jul 2015 03:40:04 +0000 http://mawatari.jp/?p=2403 Continue reading]]> 開発用のMacBookを新調したのをきっかけに、HomebrewとAnsibleを用いて開発環境構築の自動化に取り組みました。今回はその環境をServerspecを使ってテストする方法をメモしておきます。
HomebrewとAnsibleでMacの開発環境構築を自動化する

testing-mac-with-serverspec-01

環境

環境は以下の通りです。

ソフトウェア バージョン
Mac OS X 10.10.4
Homebrew 0.9.5
Ansible 1.9.1
Serverspec 2.19.0

Serverspecとテストについて

Serverspecについては既知の方も多いと思いますが、簡単に説明すると、対象の環境が期待した通りの状態にあるかをテストするためのツールです。AnsibleやChef, Puppetといった構成管理ツールに依存することなく、また、OSの種別毎にテストコードを書き換える必要がないのが特徴です。
Serverspec

Ansibleでもテスト(のようなもの)を書こうと思えばかけますし、テストを書かなくても実行結果から状態を判断することはできます。そういった状況ではありますが、いつでもテストだけを単体で実行できるようServerspecでテストを書きました。
既にリポジトリにテストを追加しているので、READMEに書かれた手順で簡単に実施できます。以前に公開したプロビジョニングの利用者がそれなりにいるようなので、テストに関してもぜひ試していただければと思います。
mawatari/mac-provisioning – GitHub

テストを追加した時の作業ログ

自身でテストを作成した時の作業ログを残しておきます。何かの参考になれば幸いです。

Ruby環境の整備

ServerspecはRuby Gemsなので、Rubyを実行できる環境が必要です。Mac OS Xには初めからRubyはインストールされていますが、ここではSystem Rubyではなく、rbenvを利用したいと思います。環境を整えた後に、他のRubyプロジェクトと、干渉しないようにするためです。

rbenvで最新安定版のRubyをインストールするため、まずは、

web-development.yml
roles
ruby-build
を追加します。(ロール名は何でも構いません。)

- hosts: localhost
  connection: local
  gather_facts: no
  sudo: no
  roles:
    - homebrew
    - homebrew-cask
    - ruby-build

次に、

ruby-build
のタスクを作成します。Ansibleにはrbenvのモジュールは無いため、
shell
モジュールでrbenvの最新安定版をインストールします。以下のとおりです。

---
- name: Installs latest stable version of Ruby
  shell: rbenv install -s $(rbenv install -l | grep -v - | tail -1)
  register: result
  changed_when: '"Installed ruby" in result.stderr'

- name: Switch to latest stable version of Ruby
  shell: rbenv global $(rbenv install -l | grep -v - | tail -1)

- name: Installs latest available version of bundler.
  gem: name=bundler state=latest

web-development.yml
homebrew_packages
rbenv
が指定されていることを前提にタスクを作成しているため、
homebrew_packages
から
rbenv
を削除している人は、再度、追加するか、このタスクに
rbenv
のインストールを追加しておきましょう。
ちなみに、
rbenv install -s $(rbenv install -l | grep -v - | tail -1)
というコマンドは、rbenvでRubyの最新安定版をインストールするワンライナーです。以下で解説しているので、参照してください。
rbenvでRubyの最新安定版をインストールするワンライナー

テストの作成

ひな形の作成

いよいよテストの作成です。テストを作成するにあたって、まずは

bundle
コマンド等を用いて、ひな形を作成します。

bundle init
echo 'gem "serverspec"' >> Gemfile
bundle install --path=vendor/bundle
bundle exec serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/sample_spec.rb
 + spec/spec_helper.rb
 + Rakefile
 + .rspec

これにより、19行目から24行目にある通り、4つのファイルが生成されました。

spec/localhost/sample_spec.rb
に関しては、
homebrew_spec.rb
という名称に変更してから利用します。

ヘルパーの作成

以下のとおり、ヘルパーを作成しました。
Homebrew Caskでインストールしたパッケージは、Serverspecの

Package resource be_installed matcher
が利用できないため、パッケージ名のディレクトリが存在しているかどうかを確認するテストとしました。

require 'serverspec'
require 'yaml'

set :backend, :exec

# YAMLから設定値を読み込む
def load_configuration (key)
  configuration = YAML.load_file 'web-development.yml'
  configuration[0]['vars'][key].map do |package|
    package.kind_of?(Hash) ? package['name'] : package
  end
end

# Homebrewパッケージリストを読み込む
def homebrew_packages
  load_configuration 'homebrew_packages'
end

# Homebrew Caskパッケージリストを読み込む
def homebrew_cask_packages
  load_configuration 'homebrew_cask_packages'
end

# Caskroomのパスを得る
def homebrew_caskroom
  env = Shellwords.shellsplit(ENV['HOMEBREW_CASK_OPTS'] || '').map do |option|
    option.split('=')
  end
  Hash[*env.flatten]['--caskroom'] || '/opt/homebrew-cask/Caskroom'
end

テストの作成

以下のとおり、テストを作成しました。

be_installed
マッチャーと、
be_directory
マッチャーを使って、パッケージの存在確認を行っています。

require 'spec_helper'

homebrew_packages.each do |package|
  describe package(package) do
    it { should be_installed }
  end
end

homebrew_cask_packages.each do |package|
  describe file(homebrew_caskroom + '/' + package) do
    it { should be_directory }
  end
end

以上でテストの作成は完了です。

テストの実行

テストを書き終えたので、実行してみたいと思います。

bundle exec rake

...

File "/opt/homebrew-cask/Caskroom/vagrant"
  should be directory

File "/opt/homebrew-cask/Caskroom/virtualbox"
  should be directory

Finished in 2.51 seconds (files took 0.85425 seconds to load)
30 examples, 0 failures

すべてのテストをパスしました。面倒なことは無いと思うので、ぜひ取り組んでいただけたらと思います。以上です。

こぼれ話

テストの作成と実行に関しては以上ですが、その過程でこぼれ話もあったので、合わせてメモしておきます。
当初、Homebrewパッケージに関しても、

be_directory
マッチャーを利用してテストしようとしていました。その際、Homebrew Cellarのパスを得るヘルパーを書く必要があったのですが、そこで結構ハマりました。以下の様な内容です。

# Homebrew Cellarのパスを得る
def homebrew_cellar
  Bundler.with_clean_env do
    `brew --cellar`.chomp
  end
end

Bundler.with_clean_env
というメソッドが肝で、これが無いと期待通りにはパスを得ることができません。Homebrewだけは、System Rubyを使ってインストールしていて、かつ、このヘルパーは
bundle exec
で呼ばれるためです。
文字だけでは実感がわきにくい方もいると思います。CLIで以下の3つのコマンドを実行し、出力結果を見比べてもらえればと思います。

brew --cellar
ruby -e 'puts `brew --cellar`'
bundle exec ruby -e 'puts `brew --cellar`'
bundle exec ruby -e 'Bundler.with_clean_env { puts `brew --cellar` }'

つまり、2行目と同じことを

bundle exec
下でも得たい場合は、
Bundler.with_clean_env
を利用するということですね。

以上、こぼれ話でした。

]]>
https://mawatari.jp/archives/testing-mac-with-serverspec/feed 0
PHPカンファレンス福岡2015に参加してきた https://mawatari.jp/archives/phpconference-fukuoka-2015-report https://mawatari.jp/archives/phpconference-fukuoka-2015-report#respond Mon, 29 Jun 2015 15:35:42 +0000 http://mawatari.jp/?p=2395 Continue reading]]> 2015年6月27日に開催されたPHPカンファレンス福岡2015に参加しました。参加状況は以下のとおり。

No. タイトル 発表者 時間
1 [基調講演] 全てを結ぶ力 郡山 昭仁 @koriym 40分
2 あなたと秘伝のタレ mid 2015 石田 絢一 @uzulla 30分
3 PHP × AWS でスケーラブルなシステムをつくろう 井上 泰治 @inufs 30分
4 CakePHP3ウォークスルー 長谷川 智希 @tomzoh 30分
5 オープンソースな帳票ツールを作りました 日高 克也 @hidakatsuya 15分
6 Laravel5を使って開発してみた 野田 健夫 @nodatakeo 30分
7 Phalcon PHPフレームワーク Sense of Use 近藤 和宏 @cubicBase 15分
8 CakePHPを業務で使ってみた(7年ほど) 小山 健一郎 @k1LoW 30分
9 PhpStormで始める快適PHP開発生活 山本 裕介 @yusuke 15分
10 レイヤードアーキテクチャを意識したPHPアプリケーションの構築 新原 雅司 @shin1x1 30分
11 LT @decoy_service
@k1LoW
@akira1908jp
@cloud10designs
各5分
12 PHPカンファレンス福岡2015(懇親会) 120分
13 参加者たちとの二次会 120分

発表者のスライドは、@media_planさんがまとめてくださっているので、そちらにリンクしておきます。
phpカンファレンス福岡 登壇者スライドまとめ

感想など

業務やプライベートで頻繁に利用するCakePHPとLaravelのセッションを中心に回りました。
発表を聞いて気になったことは、その場でVMとモックを構築し、画面を見てもらって直接質問を投げかける等しました。こういった機会ならではです。
参加したセッション全体を通して、自身の取り組みの是非を再確認できたり、新たな発見があったりと、大変有意義な時間を過ごせました。
各セッションの感想などは、随時ツイートしていたので、Togetterにまとまっています。
PHPカンファレンス福岡2015まとめ #phpconfuk

また、今回の参加には、発表を聞く以外に、もう一つの明確な目的がありました。それは、普段からTwitter等で交流は持っているけど、お会いしたことがない方や、よく拝見しているブログの著者、利用しているライブラリの作者とお話をすることです。直接、感謝の気持を伝えることが出来る機会はめったにないので、そういった意味でも、このような機会を作ってくださったスタッフの皆様には感謝します。ありがとうございました。

余談ですが、他の参加者との交流をスムースに行うために、以下の様なソーシャルアカウントを記したシールを準備していきました。Twitter, GitHub等、すべて同じアイコンで統一しているので、アイコンで認知されている方も多く、交流に一役買ってくれました。数百円で自作できるので、同じアイコンを使い続けている方にはオススメです。
(7〜8年前から同じアイコンなので、本人とアイコンが似つかなくなってきているという問題が発生していますが、それはまた別の話。)

phpconference-fukuoka-2015-report-01

名刺やネームプレートの余白に添付する等して利用しました。
お名前シール用 – ラベル・シールのエーワン

]]>
https://mawatari.jp/archives/phpconference-fukuoka-2015-report/feed 0
rbenvでRubyの最新安定版をインストールするワンライナー https://mawatari.jp/archives/install-latest-stable-version-of-ruby-using-rbenv https://mawatari.jp/archives/install-latest-stable-version-of-ruby-using-rbenv#comments Wed, 24 Jun 2015 02:53:52 +0000 http://mawatari.jp/?p=2390 Continue reading]]> rbenvおよびruby-buildのインストール、そしてRubyの最新安定版をインストールする作業を自動化したいと考えていました。rbenvでRubyの最新安定版をインストールするワンライナーをメモしておきます。rbenvやruby-buildのインストールは以下の記事を参照してください。
Homebrewでrbenvをインストールする
HomebrewとAnsibleでMacの開発環境構築を自動化する

rbenvには、インストールできるバージョンを調べる

rbenv install -l
コマンドは用意されていますが、
latest
stable
などといった最新安定版を調べるコマンドは用意されていません。
何か方法はないかと、rbenvやruby-buildのリポジトリにあるイシューを巡っていた際、Stack Overflowのスレッドにたどり着きました。
‘rbenv install stable’ #312 – sstephenson/ruby-build
Suport prefix matching on ruby versons. #276 – sstephenson/ruby-build
Install Latest Stable Version of Ruby Using rbenv – Stack Overflow

Rubyの最新安定版を知るコマンド

Stack Overflowにコメントされていた幾つかの例を紹介します。例えば

sed
コマンドを用いた例。

rbenv install -l | sed -n '/^[[:space:]]*[0-9]\{1,\}\.[0-9]\{1,\}\.[0-9]\{1,\}[[:space:]]*$/ h;${g;p;}'

こちらは

grep
を用いた例。シンプルです。

rbenv install -l | grep -v - | tail -1

rbenvでRubyの最新安定版をインストールするワンライナー

というわけで、rbenvでRubyの最新安定版をインストールするワンライナーの例は以下のとおりです。ただし、以下の制約があります。ご留意ください。

  • Ruby最新安定版のバージョンが数値とドットのみで構成されていること
  • rbenv install -l
    の結果がバージョンの昇順でソートされていること

rbenv install $(rbenv install -l | grep -v - | tail -1)

以上です。

]]>
https://mawatari.jp/archives/install-latest-stable-version-of-ruby-using-rbenv/feed 1
Ansibleの実行結果を通知する https://mawatari.jp/archives/notify-the-result-of-ansible https://mawatari.jp/archives/notify-the-result-of-ansible#respond Tue, 16 Jun 2015 03:25:38 +0000 http://mawatari.jp/?p=2382 Continue reading]]> Ansibleのコールバックプラグインを使って、プロビジョニングの実行結果を通知する方法をメモしておきます。
コールバックプラグインについては、公式ドキュメントに概要とサンプルが載っていますので参照してください。
Developing Plugins #Callbacks – Ansible
ここでは、Mac OS Xの通知センター (Notification Center) にAnsibleの実行結果を表示させることを目標とします。

今回作成したプラグインは、以下よりダウンロードできます。
Ansible Callback Plugins – GitHub

環境

環境は以下の通りです。
Ansibleに関しては、Homebrewを利用してインストールしています。詳しくは以下を参考にしてください。
HomebrewとAnsibleでMacの開発環境構築を自動化する

ソフトウェア バージョン
Mac OS X 10.10.3
Ansible 1.9.1

Ansibleのコールバックプラグインを使って実行結果を通知する

Ansibleには様々なプラグイン機構が備わっています。
Developing Plugins – Ansible
その内のコールバックプラグインを使って、実行結果を通知する方法について見ていきます。
Developing Plugins #Callbacks – Ansible

コールバックプラグインの仕組みは非常に簡単です。以下に

CallbackModule Class
のテンプレートを示します。実行したいタイミングに合わせて処理を実装しましょう。

class CallbackModule(object):

    def __init__(self):
        """ constructor """

    def on_any(self, *args, **kwargs):
        pass

    def runner_on_failed(self, host, res, ignore_errors=False):
        pass

    def runner_on_ok(self, host, res):
        pass

    def runner_on_skipped(self, host, item=None):
        pass

    def runner_on_unreachable(self, host, res):
        pass

    def runner_on_no_hosts(self):
        pass

    def runner_on_async_poll(self, host, res, jid, clock):
        pass

    def runner_on_async_ok(self, host, res, jid):
        pass

    def runner_on_async_failed(self, host, res, jid):
        pass

    def playbook_on_start(self):
        pass

    def playbook_on_notify(self, host, handler):
        pass

    def playbook_on_no_hosts_matched(self):
        pass

    def playbook_on_no_hosts_remaining(self):
        pass

    def playbook_on_task_start(self, name, is_conditional):
        pass

    def playbook_on_vars_prompt(self, varname, private=True, prompt=None,
                                encrypt=None, confirm=False, salt_size=None,
                                salt=None, default=None):
        pass

    def playbook_on_setup(self):
        pass

    def playbook_on_import_for_host(self, host, imported_file):
        pass

    def playbook_on_not_import_for_host(self, host, missing_file):
        pass

    def playbook_on_play_start(self, name):
        pass

    def playbook_on_stats(self, stats):
        pass

今回は、完了後に実行結果を通知させたいので

playbook_on_stats
メソッドを実装します。

import subprocess

class CallbackModule(object):
    # 中略
    def playbook_on_stats(self, stats):
        hosts = sorted(stats.processed.keys())

        for host in hosts:
            summary = stats.summarize(host)

            status = "Provisioning succeeded!"
            if summary['failures'] > 0 or summary['unreachable'] > 0:
                status = "Provisioning failed!"

            cmd = "osascript -e 'display notification \"%s %s\" with title \"%s\"'"
            cmd = cmd % (host, summary, status)
            subprocess.call(cmd, shell=True)

以上で実装は完了です。あとは

playbook
と同じ階層に
callback_plugins
ディレクトリを作成し、その中にファイルを設置するだけです。
Playbookを実行してみましょう。実行結果に応じて、通知が表示されるはずです。

notify-the-result-of-ansible-01
notify-the-result-of-ansible-02

Ansibleの実行結果を喋らせる

画面への通知だけでは気づかないかもしれません。それでは実行結果を喋らせましょう。

import subprocess

class CallbackModule(object):
    # 中略
    def playbook_on_stats(self, stats):
        hosts = sorted(stats.processed.keys())

        for host in hosts:
            summary = stats.summarize(host)

            status = "Provisioning succeeded!"
            voice = "-v Zarvox"
            if summary['failures'] > 0 or summary['unreachable'] > 0:
                status = "Provisioning failed!"
                voice = "-v Hysterical ha ha ha, "

            cmd = "osascript -e 'display notification \"%s %s\" with title \"%s\"'"
            cmd = cmd % (host, summary, status)
            subprocess.call(cmd, shell=True)
            subprocess.call("say %s %s" % (voice, status), shell=True)

Macの

say
コマンドを利用しています。
成功した場合は、メカニカルな感じで成功を祝福してくれます。自動化バンサイ!
失敗した場合は、「プギャーwwwプロビジョニング失敗だっておwwww」みたいなノリでバカにされることでしょう。
おふざけが許されないような環境の方は、
voice = "-v Alex"
あたりにしておけば無難だと思います。

とりあえず声だけでも聞いてみたい人は、Macのターミナルで以下のコマンドを実行してみてください。

# 成功時
say -v Zarvox Provisioning succeeded!
# 失敗時
say -v Hysterical ha ha ha, Provisioning failed!
# 他にどんな声の種類があるのかを知る
say -v ?

Ansibleの実行結果を歌わせる

プロビジョニングの成功や失敗をもっと華やかに演出したい?それなら歌わせましょう。

# 成功時
say -v good la la la la la la la la la la la
# 失敗時
say -v bad di di di di di di di di di di di

# 成功時ロングバージョン
say -v good la la la la la la la la la la la la la la la la la la la la la la
# 失敗時ロングバージョン
say -v bad di di di di di di di di di di di di di di di di di di di di di di

話がだいぶ横道にそれてきました。そろそろ終わりにしたいと思います。

さて、今回紹介したMacの

say
コマンドを利用したプラグインですが、実はAnsibleの公式リポジトリにも準備されているものなんです。そんな遊び心のあるAnsibleが大好きです。他にもサンプルがいくつかありますので、ぜひ参考にしてみてください。
ansible/plugins/callbacks – GitHub

最後になりましたがお知らせです。来る2015年06月19日(金)に福岡でAnsibleの勉強会があります。私は主催ではありませんが参加します。興味のある方はぜひお越しください。
Ansible勉強会@福岡 InnoLab#1

以上です。

]]>
https://mawatari.jp/archives/notify-the-result-of-ansible/feed 0
MacにComposerをインストールする https://mawatari.jp/archives/install-composer-in-mac https://mawatari.jp/archives/install-composer-in-mac#respond Thu, 11 Jun 2015 03:23:11 +0000 http://mawatari.jp/?p=2376 Continue reading]]> MacにComposerをインストールする方法をメモしておきます。
今回はどこでもComposerコマンドが使えるようにグローバルインストールしたいと思います。その他のインストール方法などはComposerのWebページに詳しくあります。
Getting Started #Installation – Composer

環境

環境は以下の通りです。
PHPに関しては、Mac OS X 10.10.3に初めから入っているものを利用しました。

phpenv
php-version
といったバージョン管理は導入しておりません。

ソフトウェア バージョン
Mac OS X 10.10.3
PHP 5.5.20

php -v
PHP 5.5.20 (cli) (built: Feb 25 2015 23:30:53)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

MacにComposerをインストールする

MacにComposerをインストールします。手順は以下の通りです。

# 適当なディレクトリに移動
cd tmp

# composer.pharをダウンロード
curl -sS https://getcomposer.org/installer | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /Users/mawatari/tmp/composer.phar
Use it: php composer.phar

# composer.pharを移動
mv composer.phar /usr/local/bin/composer

以上でインストールは完了です。
ターミナルを立ち上げ直したあと、Composerのバージョン確認をしてみましょう。

composer -V
Composer version 1.0-dev (4f80e7ff68466cab970c22b425725b8058c32970) 2015-06-09 00:03:48

正しくインストールされていること、

composer
コマンドが利用できることが確認できました。

~/.composer/vendor/bin へパスを通す

ここから先は必要に応じての作業です。
たとえば、Composerを使ってLaravelインストーラーをグローバル領域にインストールした場合、

~/.composer/vendor/bin
laravel
コマンドが配置されます。ここへパスを通しておけば、CLIで
laravel
コマンドが使えるようになり非常に便利です。各種コマンドをグローバル領域にインストールする予定の方はパスを通しておきましょう。

composer global require "laravel/installer=~1.1"

.bash_profile
なり、
.zshrc
なりにパスを追加しておきましょう。

echo 'export PATH=$PATH:$HOME/.composer/vendor/bin' >> ~/.bash_profile

以上です。

]]>
https://mawatari.jp/archives/install-composer-in-mac/feed 0