funcphoneを使った電話振り分け
前回はfuncphoneの基本的な処理方法をご紹介しました
今回は特定の着信に対して別の処理を行う例をご紹介します
実行したい処理イメージ
funcphoneで作成した電話番号を【電話番号】とします
- 顧客１が【電話番号】に電話をかけると音声案内がスタート
「この番号は現在使われておりません。」 - 顧客２が【電話番号】に電話を掛けると転送処理開始
特定の電話番号に対してメッセージを流す処理、今回はこのフローを作成していきましょう！
フロー作成
では実際に処理を作成していきましょう！
最初のフロー作成については前回と同じなので割愛させていただきます
着信電話番号
- 『CallStart』ペインに『着信電話番号』アプレットを設定しましょう
『ｱﾌﾟﾚｯﾄをここへﾄﾞﾛｯﾌﾟ』と表示されている所に、右メニューにある『着信電話番号』アプレットをドラッグして貼り付けてください
『着信電話番号』欄に顧客1の電話番号を入力し、アプレットに『メッセージ』アプレットを設定します
メッセージ
- 『メッセージ』ペインの『音声選択』を『テキスト読上』に設定し文章を入力します
入力が完了したら『保存』を選択してください - テキスト読み上げ後はそのまま音声案内を終了し、会話を終了します
『次へ』に設定するアプレットを右のアプレットドラッグします
『切断』アプレットを貼り付けましょう
着信電話番号
- 『着信電話番号』ペインに戻ります
顧客１以外のお客様だった場合の処理を設定します
今回は電話転送処理を行いますので、『上記以外の着信電話番号の〜』の欄に右側のアプレットから『ダイヤル』アプレットを貼り付けます
-
前回の記事でご紹介した処理と同様、転送先の設定を行います
完了！
-
以上で、フローの設定は完了です！
前回同様フロー画面の右にある『保存』ボタンをクリックし、保存が完了したら『閉じる』ボタンを押します
-
フロー画面の電話番号の欄を確認して『None』となっていた場合、電話番号を充てましょう
方法は前回の記事をご参照ください
実際に掛けてみる
番号画面で設定した電話番号に実際に電話を掛けてみましょう（サービス外料金です）
顧客１として設定した電話番号とそれ以外の電話番号で掛けた場合の処理が違うことを確認できれば成功です！
funcphoneを使った電話転送
前回はfuncphoneの初期設定を行いました
次は実際に作成した電話番号に電話を掛けると走る処理を設定しましょう
今回は電話転送処理を想定した例です
実行したい処理イメージ
funcphoneで作成した電話番号を【電話番号】とします
- お客様が【電話番号】に電話をかけると音声案内がスタート
「お電話ありがとうございます。株式会社funcphoneです。
営業部は１を、開発部は２を押してください。」 - お客様が１、または２を押すと電話転送を実行
フロー作成
では実際に処理を作成していきましょう！
今回は『メニュー』アプレットを使います。『メニュー』アプレットは音声案内機能に最適なアプレットです
- 左のメニューから「フロー」をクリックします
-
『フロー作成』ボタンをクリックして、新規のフローを作成しましょう
フロー名はわかりやすいものを付けてください
-
OKをクリックするとフロー作成画面が表示されます
ここで、先程イメージした実行処理を作成していくことになります
メニュー
-
『CallStart』ペインに『メニュー』アプレットを設定しましょう
『ｱﾌﾟﾚｯﾄをここへﾄﾞﾛｯﾌﾟ』と表示されている所に、右メニューにある『メニュー』アプレットをドラッグして貼り付けてください
『メニューの案内』の『テキスト読上』をクリックすると、入力フォームが表示されますので実際に読み上げて欲しい文章を入力しましょう
コツとしては英語はカタカナで表記したほうが電話口ではきれいに聞こえます
テキストを入力したら『保存』ボタンをクリックします -
次に電話転送処理を設定します
『メニューオプション』を確認してください
プッシュする番号と押した後に実行する処理を設定する欄があります
今回使うダイヤルは１と２のみですので『押キー』はそのままでよさそうです
『アプレット』欄は今回は転送…つまり別のダイヤルへつなぐ処理を行いたいので、『ダイヤル』アプレットを設定しましょう
『メニューアプレット』の時と同様の設定の仕方で、右メニューから『ダイヤル』アプレットをドラッグして貼り付けてください
ダイヤル
-
番号１を押したときの処理を設定しましょう
押キー『１』に設定した『ダイヤル』アプレットをクリックして『ダイヤル』ペインを開きます
-
転送先の番号を設定します
選択は『ユーザかグループへ転送』を選択した状態で、『ユーザ・グループ選択』横の虫眼鏡をクリックします
転送先のユーザを選択します
最初に設定した自分宛に転送するようにしましょう
該当のユーザを選択します
一覧に該当のユーザが存在しない場合は『ユーザの追加』を選択します（コースにより制限あり） -
押キー２にも同様の処理を行います
完了！
-
以上で、フローの設定は完了です！
『電話転送』の右にある『保存』ボタンをクリックし、保存が完了したら『閉じる』ボタンを押します
-
フロー画面に先程作成したフローが表示されていると思いますが、電話番号の欄を確認して『None』となっていた場合、電話番号を充てる必要があります
番号画面
-
右メニューから『番号』を選択します
-
充てたい番号の通話フローをクリックし、先ほど作成したフロー名を選択します
実際に掛けてみる
以上で電話転送機能作成完了です！！
番号画面で設定した電話番号に実際に電話を掛けてみてください（サービス外料金です）
右上が『オンライン』の状態になっている事を確認し、電話案内の通り『１』ボタンを押すと着信を受けれるようになっていると思います
funcphone導入まで
この度、弊社有限会社ランカードコムは「funcphone」をリリースしました
PCとスマホがあれば、電話転送や自動音声案内など柔軟な電話業務を行えるサービスです
今回、導入部分〜利用例までを流れをいくつかの記事に分けてご紹介できればと思います
無料トライアルを行う
- funcphoneは制限さえあるものの、電話番号１つまででしたら無料で作成できますので是非利用していただきたいところです！（利用制限あり）
funcphoneのサイトにて『無料トライアルを申し込む』をクリックし、必要な情報を入力します
- 登録が完了しますと、設定したメールアドレス宛にパスワード設定のご案内のメールが届きますので、
内容に従って設定をお願い致します - パスワードの設定まで完了すると、ログイン画面が表示されます。先程設定したメールアドレスとパスワードを入力し、ログインを行います
電話番号設定
- ログインが出来るようになって１番はじめに行わなければならいのが電話番号作成です
ログインした時点で、電話番号画面が表示されますので設定を行ってください
- 右上の「番号を取得」から電話番号を取得できます（トライアル中は１つまで取得可能）
- アメリカ番号と日本番号の２つが選択できますが、転送や自動音声案内などが目的であれば日本番号でよいでしょう
ここでは「Japan」を選択し、「番号の追加」をクリックしてください - 以上で電話番号の作成までが完了です！
次回から実際の使用例をいくつかご紹介したいと思います
Laravel 5.1 でログ出力、それから (ログメールドライバー動作不良対処、クエリ出力の調整)
おひさしぶりです。運用していたら結構変わったので、またこのネタです。
一応以前の記事へのリンクおいときます。
『Laravel 5.1 でログ出力、その後 (出力レベル設定、クエリ出力)』
が、以前の記事の方法だとログメールドライバーが動作しないという問題が発生したので参考にしちゃだめ。
というわけで、以下の要件と不具合対処のために改修した内容を紹介します。
- ログファイルの権限絡みのエラー回避、何処から起動された処理かわかりやすくする等の目的で実行ユーザー名ベースでログファイルを作成。
- 動作環境(local, testing, production等のenvironment)でもログファイルを分ける。
- バッチ処理やartisanのコマンド実行の場合はARTISAN_BINARYをログファイル名に挿入してWebアクセスとはログファイルを分ける。
- デバッグフラグ(app.debug)を落とした状態ではINFO以上のログのみ出力。
- .envでAPP_QUERY_LOGGINGにtrueを設定したら発行されたクエリをinfoログで専用ログファイルに出力(デバッグフラグでのコントロールを廃止し個別にコントロール可能とし、ファイルも分けた)
- 以前の実装ではログメールドライバー(メール送信内容をログ出力するドライバ)が正常動作しなかったためLoggerインスタンスを差し替える方法から既存Loggerインスタンスのhandlerを差し替える方法に実装を変更。
CentOS7のPostgreSQL9.2で全文検索
- 2017/01/27
- aikawa
PostgreSQLの全文検索でLudia, textsearch_sennaを使っていたのですが、9.2ではどちらも使えないので、代替となりそうなものを探した結果、pg_trgm, pg_bigm, textsearch_jaの三つが使えそうでした。
ただpg_trgmは日本語を使うにはソースからのコンパイルが必要で、しかも二文字以下は使えないのでパスしました。
何故 git rebase は駄目で git pull –rebase はいいのか
- 2016/11/07
- shun
git pull –rebase は便利ですが、rebase と言えば git rebase、これが割と敬遠されがちな声を聞くので –rebase オプションなんて本当に使っていいのか心配になることもあるかと思います。
私も普段は便利に git pull –rebase していますが、ふと git rebase の解説記事をみかけると毎度不安になりこの二つの仕組みを調べてしまうので、いっそのことまとめてしまうことにしました。
実行されたJenkinsFileはReplayから確認できる
muraveです。
なうなやんぐなのでPipelineでJenkinsFileを使ってビルドについてもソースコード管理したいわけですが、他チームのJenkinsFileを参考にしたいときにJenkins上から内容が確認できないと、お願いしてJenkinsfileを送ってもらうという悲しいことになったり(実際に発生)。
Jenkins上から確認できるように出来ないものかとプラグインを探したり、ファイルは残っていたのでそれを参照できるようにできないかいろいろ試したりしていました。
しかし、そんな事をしなくても内容をみることができる方法がみつかったのでした。
まぁ、答えはタイトルに書いちゃってますが、こんなん予想できませんわー。
一部マスクしますが、キャプチャを貼っておきますね。
スクリプトを参照する場合は間違ってRunしないように注意ですね。
JenkinsのwithCredentialsでユーザー名とパスワードを扱えるのかを確認したいだけだった
muraveです。
なうなやんぐはPipelineでJenkinsFileを使ってビルドについてもソースコード管理ですよねー、ということで試してみているんですが、ユーザー名やパスワードをJenkinsFile内に書くわけにはいかないわけで。
方法を探してみたところ withCredentials でどうにか出来そうでした。
Fetch a userid and password from a Credential object in a Pipeline job.
ここを見ながらザックリと Pipeline script なジョブを作成して動作を確認しようとしたところ、少々ハマリました。
テスト用にユーザー名test、パスワードpassword、credentialsIdがtestの認証情報を作成しています。
node {
stage 'withCredentials Test'
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'test',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
sh 'echo uname=$USERNAME pwd=$PASSWORD'
}
}
これを実行したログを確認すると
[credential_****] Running shell script
+ echo uname=**** pwd=****
みたいな表示。うーん。何か権限的に引っかかってるのか、表示が潰されているだけなのかがわかりません。
結論を先に言うとユーザー名、パスワードについて表示を****で潰すようになっているようです。
あとで気づいたのですが[credential_****]のところもジョブ名がcredential_testなのでユーザー名であるtestが潰されているのでした。
ではユーザー名、パスワードが本当に取れているのかをどのように確認したのか？ですが次のような Pipeline script を作成しました。
node {
stage 'withCredentials Test'
def uname //withCredentials外にUSERNAMEを持ち出す為に使用
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'test',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
sh 'echo uname=$USERNAME pwd=$PASSWORD > idpw.txt'
sh 'pwd' //ワークスペースの位置確認をしたかったのだが、しかし
println(env.USERNAME) //groovyでの扱い
uname = env.USERNAME //withCredentials外にUSERNAMEを持ち出す
}
stage 'withCredentialsの外で出力'
println(uname)
stage 'ワークスペースの位置確認'
sh 'pwd'
}
実際に行ったのはidpw.txtファイルにリダイレクトして内容を確認でしたが、その際の謎動作の説明のための処理や、その後にログ上で確認できないかな？と思ってやってみたことも混ぜてあります。
ログから抜粋してまとめると以下のようになります。
Entering stage withCredentials Test
Proceeding
[credential_****] Running shell script
+ echo uname=**** pwd=****
[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****
****
Entering stage withCredentialsの外で出力
Proceeding
test
Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test
idpw.txtの位置が知りたくてpwdしているのですがwithCredentialsのブロック内で実行すると
[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****
と、ユーザー名のtestと同じだったために一部マスキングされてしまっています。まぁ、大体の位置は予想がついたのでidpw.txtを探して内容確認はできたわけですが(ちゃんとユーザー名、パスワードが出力されていました)。
最後にブロック外でpwdしてみるとちゃんと
Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test
と出力されているのがわかります。
ログだけでの動作確認ですがブロック外ならマスキングされないのがわかったのでuname変数を定義して外に持ちだしてやればいいかな〜と
Entering stage withCredentialsの外で出力
Proceeding
test
やはりマスキングされずに出力されました。動作の確認はできましたが、これは通常はやってはいけないパターンですね。
以上です。
Dockerのデータボリュームをバックアップ・リストア
現状試しているのはローカルストレージドライバでのデータボリュームの場合ですが、コンテナでバインドして扱うのが常道な感じです。
データ・ボリュームのバックアップ・修復・移行
http://docs.docker.jp/engine/userguide/dockervolumes.html#id9
に書いてあるやり方ですね。
jenkins-masterというコンテナの /var/jenkins_home をバックアップ・リストアする例をあげます。
バックアップ
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine tar czvf /backup/alp.tar.gz -C /var jenkins_home
リストア
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine sh -c "rm -rf /var/jenkins_home/* && cd /var && tar xzvf /backup/alp.tar.gz"
念のためユーザーにrootを指定し、Alpine Linuxで実行しています。バックアップ時、相対ディレクトリ指定のためtarの-Cオプションを使用しています。展開時はゴミファイルが残るのが嫌だったのでリストア対象ディレクトリ内を全て削除してから展開していますが、削除はしないほうが安全かもしれません。
以上です。
データボリュームコンテナについての蛇足
データ永続化のために別途データボリュームコンテナを作成している場合でもローカルストレージなデータボリュームを使用していれば同じこと、docker save や docker export でバックアップというわけにはいかないようです。残念。
DockerのJenkinsコンテナでアクセスログについて悩んでいた
muraveです。
今年の4月にリリースされたJenkins 2系をDocker公式イメージ
で試していたのですが、Webフックからキックしてのビルドを試していて大変ハマリました。Webフックからのアクセス状況とかどうなってんだ？などなどtcpdumpとか使って調べてたんですけど、アクセスログもあったほうがいいよね、と思ったのでした。
公式イメージのJenkinsさんってそのまま立ち上げたらアクセスログ出してくれないんですよね。
調べまして、JENKINS_OPTSに
--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=ログファイルのパス
てな感じで設定すれば良いことはわかりました。分かりましたが、コンテナ内やボリュームにログファイルを出すのは違う気がします。docker logs で見ることができるログはどういう扱いなんでしょう？
デフォルト設定のロギング・ドライバのログ(JSON形式)はホストの
/var/lib/docker/containers/(コンテナID)/(コンテナID)-json.log
にあって、これが docker logs の表示元になっています。
問題はどうやったらここに出力されるのか？ですが、標準出力、標準エラー出力へ出力すれば良いそうです。例えば、Nginx公式イメージのDockerfileでは
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
と、/dev/stdout と /dev/stderr へのシンボリックリンクを作成することで対応しているようです。
Jenkinsさんの場合は先ほどのJENKINS_OPTSでログファイルのパス指定が可能でしたので
--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/dev/stdout
と設定すると標準出力に出力されるようになり、コンテナのログにJenkinsさんへのアクセスログが記録されるようになりました。
これでDockerのロギング・ドライバでアクセスログも統一的にあつかえますね。
例えばFluentdロギング・ドライバに切り替えてログ集約するようにしたりする場合にも安心です。
