Innovation EGG 第４回 『各クラウドの現状とこれから』開催しました
を先週の7月4日に開催しました。
Twitterまとめ
エントリーはキャンセル分含め200名近い登録があったのですが
当日は雨だったののあると思いますが50名近い方がドタキャン涙。
それでも沢山の方に参加して戴き、会場のイノベーションハブは
ちょっとクーラーの効きが弱い状況になりました汗。
今回は各クラウドベンダーの方や企業様からグッズの提供をして頂きました。
※ハンズラボ様・サイボウズ様・さくらインターネット様・KDDIウェブコミュニケーションズ様・google様・構造計画研究所様・セールスフォース様ありがとうございました(順番は提供が決まった順に記載しています)。
今回はクラウドユーザーグループのみ講師の方のみ登壇可能(
これは次のクロスエッグの布石でもあります)で、
沢山のクラウドの話をいっぺんに聴ける＆ユーザーグループからの登壇ですので
利用者側としての本音なども聴けて、よかったのではないかなと思います。
今回は6割以上の方が新規の方のようでイノベーションエッグ的には
各コミュニティの案内役として目的は果たせているのかなとほっと一安心な感じではありました。
オープニングと司会は主催者として比企のほうで今回させて頂きましたが
司会に関しては慣れている人にしてもらったほうが良いなと素直に思いました汗
そんな反省もしながらも本編がスタート
JAWS-UG 大阪からは森さんが登壇。今回はモバイル系のサービスをメインに話をされていました。
ロックオンの三原さんは株式上場した時のサイトのCloud Frontの話をして頂けました。
ものすごく生生しい話だったのか、資料が公開されていませんw
かなり質問も多く非常に参加者の皆様Cloud Frontに興味があるようでした。
Innovation EGG - Innovation EGG 第四回の講師＆内容発表 第５弾は 三原... | Facebook
ウメキタフォースからは山田商店の鈴木さん鈴木商店の山田さんと株式会社TAMの男前の白石さんが登壇。緩い話からのセールスフォースでしたが面白かったです。
JAZ-UGからは亀渕さんが登壇。マイクロソフトの全体の話からMicrosoft Azureの話で
時間が足りないぐらいのボリュームでした。Azureというかこのごろのマイクロソフトは
非常に動きが軽快でエンジニアの心をわしづかみにするものが多いので、比企的には
非常に楽しみです。
kintone Caféからは圧力団体宣言をしている金春さんが登壇。
R3に6月にJOINした池上さんを引き連れていつもの軽快なトークで語って頂けました。
9月に第一回が開催されるTwilioJP-UG 大阪からは新原さんが登壇。
男前・喋り上手・そしてデモで会場の参加者の巻き込むと全く付け入る隙？が
ない登壇でした。
Twilioはデモのインパクトが強く、自分としてはIoTの中で現実的なサービスとして
最もクローズアップされるべきサービスかなと思っています。
日本SoftLayerユーザー会からは常田さんが参戦。
運用面含み非常になまなましいトークでしたが、それを面白く伝えてくれて会場の評判は非常によかったでした。
GCPUGからは吉積さんが参戦。GAE話からGCAの話・Big Queryの話などをして頂けました。GAEは比企的にも個人的な思い入れが強いサービスなので、色々とおもいかえすものがありました。
とりを勤めるのはSky株式会社のエンジニアとして昼間働き翻訳も副業でやっている
玉川竜司さん。
非常に忙しいところを、Big Queryの話と、これからのクラウドはこうなるよね？って話をして頂きました。
Google Big Query from 玉川 竜司
そして熱気さめやらぬまま、懇親会のスタート。
50名を超える方が参加して頂きました。
司会の池上さんはコスプレで参戦w
LTは今年の6月に電撃でハンズラボに入社したJAWS-UGの女帝 青木さんからのスタート
懇親会LTは飛び入り野方も含め12人の方が登壇。
そしてTwilioからエバンジェリストの宋さんがトリで、Twilioによる電話を使った抽選会。
そして景品はTwilioだけではなくSendGridのノートやフリスビーを中井さんが提供してくれました。
こういうクラウド同士でのコラボもイノベーションエッグならではな感じですね。
そして懇親会は集合写真をとって無事に終了しました。
今回は懇親会でお酒が余ったのと思いのほか食べ物が早くなくなった(結構買っていたのですが汗)以外は予定外の事もおこらず、運営メンバーの方がかなりがんばって頂けたからこその結果なのかなと思いました。
今年中にもう一回イノベーションエッグ(IoTメインのやつ)を開催して、
来年にクロスエッグも実施する予定です。
イノベーションエッグは関西のコミュニティが盛り上がってほしいとの想いで
運営していますので、今までイノベーションエッグで登壇されてないコミュニティの方も
是非今後、ご登壇して頂ければと思います。
※比企まで是非連絡ください。
それでは次回のイノベーションエッグでお会いしましょう。
【cloudpack 大阪 BLOG】Google Apps ScriptからAmazon API Gateway経由でLambdaをコールしてSlackに投稿する
本当のタイトルは
「PagerDutyのWeb HookからAmazon API Gateway経由でLambdaをコールしてSlackに投稿する」
だったんですが、
なぜかPagerDutyのWeb Hookからcallしてくれないので
とりあえず現状動いているものをBlogに書きます。
LambdaがAmazon API Gatewayという新しい相棒を携えて、
ついにWEB APIとして使えるようになりました。
http://aws.typepad.com/aws_japan/2015/07/amazon-api-gateway-build-and-run-scalable-application-backends.html
Amazon API GatewayはLambdaのおまけ?かというと全然そうではなく、Amazon API Gateway自体が非常に可能性のあるものとなっていますが
今回はMSPのIT見える化に使う為に、Amazon API Gatewayの詳細はおいておきます。
まず下準備としてLamdaで実行するnode.jsのプロジェクトを用意します(macでやっています。node.jsのインストールは別でお願いします(簡単です))。
macのコンソールで下記を実施
$ mkdir lambdatest
$ cd lambdatest
$ npm install request
$ vi index.js
index.jsのコードは下記
exports.handler = function(event, context) {
var options = {
url: 'https://hooks.slack.com/services/ここはslackのAPIから払い出されたURLを参照',
headers: {"Accept":"application/json", "Content-Type":"application/json","Authorization":"Basic _authcode_"},body: JSON.stringify({"channel": "#投稿するチャンネル名", "username": "botの名前です", "text": "tessです", "icon_emoji": "好きな絵文字を"} )
};
request.post(options, function(error, response, body){
if (!error && response.statusCode == 200) {
console.log(body);
} else {
console.log('error: '+ response.statusCode);
}
});
};
で上記を保存し、
$ zip -r myfunc.zip index.js node_modules
で、UP用のプロジェクトをzipで固めます。
次はAWS側ですがとりあえず動かす事をメインにしますので、詳細なパラメータは放置しますw
Amazon API GatewayからでもLambdaのどちらからでも作成できますが、今回はAmazon API Gatewayから作成します。
対応しているリージョンを選択しAmazon API Gatewayを選びます
Get Startedを選択し
API nameをつけて
Create Methodを選択し
今回はpostを選択(他のメソッドも選べれます)
Lumbda Functionを選択し
microservice-http-endpointを選択し
Function Nameを入力し
Upload a .ZIP fileで先ほどUPしたファイルをアップします
でLambdaのIAM Roleを選択し
今回はLambdaはAWSの機能を使わないので上記のような感じでロールを作成し
前の画面のnextを選択し
さらにnextを選択
Create Functionを選択し、作成。
作成後に上記の画面が出てくるのでTESTを選択すると下記のような投稿がslackに投稿されれば、Lambda側はとりあえずOKです(ちなみにこのFunctionは実行時にエラー出ますが、とりあえずslackへの投稿が出来ているのでこのままで行きます(また直します))。
ここからは外部公開する為の操作となります。Deploy APIを選択し
Deployします。
上記までで公開できましたので、curlなどで一度確認してみてください。
でGoogle Apps Scriptから
function sendToLambda() {
var r;
try {
var url = "https://Invoke URL:で表示されていたURLをここに";
var data = {"operation": "echo","somekey1": "somevalue1","somekey2": "somevalue2"};//ここは不要ですが元々のdynamoのサンプルを動かしたいとき用に記載しておきます
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
var response = UrlFetchApp.fetch(url, options);
} catch(e){
var error = e;
r = null
return false;
}
return true;}
で呼び出すと間違っていなければ
が無事表示されます。
ここまででAPIを公開する事ができるようになりました。
LambdaとAmazon API Gatewayにより、インスタンス数などを気にせずに
スケーラブルなAPIを外部に公開する事が可能になります。
今回は紹介できてませんが、Amazon API Gatewayでは
他のAPIサーバーのラッパー(要求や結果を変換する機能？)になる事も出来るようで、
モバイルからの利用や過去のAPIサーバーの再活用など色々と可能性がありそうです。
GAEやAzureが先行して従量課金型のPaaSを出していましたが
早すぎた投入によりインパクトはあまり出なかったですが、
AWSがcloudの普及状況を見ての今回の投入、
利用者のマインドの変化により、これから色々と大きな変化がありそうですね。
【cloudpack 大阪 BLOG】MSPのシステム化について chatworkからslackへのメッセージ転送
hatworkからslackへのメッセージ転送・・・普通やりませんよね汗
ただどっちも使ってるけどslackの方がメインなのでって狭いニーズもあるのでやってみました。
ちなみにこのブログを書いている時点でまだ社内でもこのプログラムの存在は出していません。
とりあえず説明(コードはgoogle apps scriptです)。
下部に記載されているコードを下記のようなサンプルコードで
chatworkでAPIが前回呼び出したチャットのメッセージの差分をslackに通知します。
sendFunction("①slackでgetしたwebhookurl","②chatwork apiで取得したキー","チャットワークのルームID","slackのチャンネル");
<①slackでgetしたwebhookurl>の情報の取得に関しては
https://my.slack.com/services/new/incoming-webhook
でチャンネルを選択し
”Add Incoming WebHooks Integration”ボタンを押下すると
下記のような感じのWebhook URL
https://hooks.slack.com/services/hogehoge/hogehoge/hogehoge
が作成されます。
<②chatwork apiで取得したキー>の情報の取得に関しては
ChatWorkの動作設定の「API発行」タブから取得します。
ちなみにchatworkのAPIのドキュメントは
にありますので、他の実装する時の参考にしてください。
あとは下記のような感じで(エラー処理等は自身で記載願います)
//転送用関数
function sendFunction(slackkey,chartworkapikey,room,slackchannel){
var result = getMessageToRoom(chartworkapikey,room);
if(result.getContentText().length > 0){
var eventSearchResult = JSON.parse(result.getContentText());
for each(var obj in eventSearchResult){
sendToSlack(slackkey,slackchannel,obj.account.name+"さんのchatwokからの通知",obj.body);
}
}
}
//chatworkのルームからメッセージを取得
function getMessageToRoom(token, roomId) {
var params = {
headers : {
"X-ChatWorkToken" : token
},
method : "get"
};
var url = "https://api.chatwork.com/v1/rooms/" + roomId + "/messages?force=0";
return UrlFetchApp.fetch(url, params);
}
//slackへ通知
function sendToSlack(url,channel,username,body) {
var data = {"channel": channel, "username": username, "text": body, "icon_emoji": ":ghost:"};
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json",
"Authorization":"Basic _authcode_"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
var response = UrlFetchApp.fetch(url, options);}
なお実際に使うのはメッセージの加工なども少し行いますので
単に転送だけではないですが最低限必要な部分を抜き出しました。
あとPagerDutyでメッセージをある程度の単位で管理したい(ニーズがあれば)。
#誰が見てそのメッセージの内容を対応するのか？24365で複数人が
チャットを見て対応するので、作業着手やchatworkへのメッセージの返信が
かぶらないように。
こういうのをやりすぎると酸素欠乏症になったアムロの親父みたいな扱いに
なりかねないので、きちんとニーズがあるかを確認して
色々とやっていきたいと思います(現状からのニーズと最適化は別ものなので
声を聞いているだけでも駄目なんですが汗)。
【cloudpack 大阪 BLOG】MSPのシステム化について Google Apps ScriptからPagerDutyに通知する
現在cloudpackではPagerDutyを試験的に導入していってます。
PagerDutyとは何ぞや？と言う方への説明や導入方法を記載すべきところですが
それはおいおいしていくとして(置いといてよいのかw)、
今回は「Google Apps ScriptからPagerDutyに通知する」を試します。
※ほとんど備忘録です
まずは通知先のPD側の設定を行います。下記画面で設定します。
そして設定した画面のService API Keyの情報をメモします。
でGASのプログラミング部分は下記になります
function sendToPagerDuty(service_key) {
var url = "https://events.pagerduty.com/generic/2010-04-15/create_event.json";
var data = {
"service_key": service_key,
"event_type": "trigger",
"description": "FAILURE for production/HTTP on machine srv01.acme.com",
"client": "Sample Monitoring Service",
"client_url": "https://monitoring.service.com",
"details": {
"ping time": "1500ms",
"load avg": 0.75
},
"contexts":[
{
"type": "link",
"href": "http://acme.pagerduty.com",
"text": "View the incident on PagerDuty"
},{
"type": "image",
"src": "https://chart.googleapis.com/chart?chs=600x400&chd=t:6,2,9,5,2,5,7,4,8,2,1&cht=lc&chds=a&chxt=y&chm=D,0033FF,0,0,5,1"
}
]
};
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json",
"Authorization":"Basic _authcode_"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
try {
var response = UrlFetchApp.fetch(url, options);
var json = JSON.parse(response.getContentText());
Logger.log("status:" + json.status + " message:" + json.message + " incident_key:" + json.incident_key);
} catch(e){
var error = e;
Logger.log("message:" + error.message + "fileName:" + error.fileName + "\nlineNumber:" + error.lineNumber + "\nstack:" + error.stack);
}
}
※サンプルコードをそのままGASに移植していますので内容が気になる方は
を参考にしてください。
上記を実行すると
のような画面がPDの画面にインシデントとして表示されます。
Google Apps Scriptから”インシデントとしての”の登録はまず無いとは思いますが
PDのインシデント管理機能とエスカレーション機能を使って
作業をその日の当番の方に明示的に通知とかも出来るので、
計画作業(Googleカレンダーに登録されている作業)や日次・週次的な作業の通知＆
状態管理なんかに使いたいと思っています(今までHubotに任せていた状態管理部分をPDへ)。
基本的な使い方ではなく、いきなり応用編になってしまいましたが、PagerDutyは
スケジュール作成の部分に癖？(シンプルすぎるので一手間必要でここをどう対応したかはまた今度)もありますが、試す分には非常に簡単ですので試してみてください。
【cloudpack 大阪 BLOG】MSPのシステム化について GMailとGoogle スプレッドシートとslack連携
本来なら
「MSPのシステム化について Hubotでの状態管理(mysql)とGoogleカレンダーとslack連携 その2」
なのですが、自身のHubot熱が急速に冷めて行っている＆JAWS-UG大阪で廣山さんが
発表した資料
の中に記載されているPagerDutyの導入を比企のほうで進める事になり、
Hubot&MYSQLで対応している部分をPagerDutyに置き換えよう熱が高まったので
その２は延期?させて貰います汗。
※HubotのNode.jsのコールバック地獄がMSPしながらだと
※どうしても手軽に実現できない事情もあります(単純に開発だけしてたら良い時期は
※今考えたら楽でしたねw)
今回はGMailとGoogle スプレッドシートとslack連携について
お題は
①Backlogの担当者が未設定のものをslackに通知する
②監視サーバーからのアラートメールに状況(Google スプレッドシートに記載しているものをマッチング)を送付してslackに通知する
です。
まず①ですが、処理する方法は
Gmailにアクセスする(1/7):初心者のためのGoogle Apps Scriptプログラミング入門
を見て頂ければ処理の仕方はわかるので、上記を参照して頂ければと思いますが
引っかかった部分としてgmailのAPIを個別にCALLにしてしまうと、
メールが少ない場合は問題ないのですが、②も含め、cloudpackはメールの量が多いので
GASの処理可能時間を簡単に消費して24時間経たないと処理が再実行されない状況になります。
var thds = GmailApp.search('検索条件');
var thd = thds[n];
var msgs = thd.getMessages();
var msg = msgs[m];
var from = msg.getFrom();
var to = msg.getTo();
var date = msg.getDate();
var subject = msg.getSubject();
var body = msg.getBody();
などは処理上仕方ないのですが
msg.markRead();
GmailApp.moveMessageToTrash(msg);
などメールの個別のAPIをコールせずに
GmailApp.markThreadsRead(thds);
GmailApp.moveThreadsToTrash(thds);
などのスレッドに対するAPIで処理をまとめて行うようなAPIをコールして処理を行わないと処理が回らなくなりました。
また、処理の実行間隔のタイミングはGASは1分・5分・10分・15分しか設定できないので、
var d1 = new Date();
if((d1.getMinutes()%2) != 0) return;
関数の先頭で、上記コードで2分間隔ぐらいで実施するように修正しました。
※地味だけど本当に処理時間に気をつけないといけないので汗
またこれも処理時間ネタですが②に関してもGoogle スプレッドシートを
スプレッドシート利用の基本(1/5):初心者のためのGoogle Apps Scriptプログラミング入門
のサンプルで実装するととりあえず動くものは簡単に出来るのですが、
これもGoogle スプレッドシートの処理APIを毎回コールすると、処理の量が多いと
すぐにあふれてしまうので、
var data = getMainSheet().getRange(取得開始業,取得開始列,取得終了行,取得終了列).getValues();
でスプレッドシートの値を範囲指定で取得し
data[取得行][取得列]
な配列でアクセスして処理時間を短くする必要があります。
※処理時間は関数単位ではなく、アカウント全体での時間になるので自分が作った関数だけちょっと重いけどまあいいやなんて
※感じでその場限りで対応すると後でトラブった時に詰んでしまいますので処理時間は必ずスクリプトのメニューの表示→実行トランスクリプトの
※処理時間を見ながら計算してください。
そしてslackへの投稿部分ですが
でslack側で出力先のチャンネル名を設定し、登録後のURLをメモしておき
UrlFetchApp.fetchを使って下記コードでslackへ送信します。
function sendToSlack(channel,body) {
var r;
try {
var url = "メモしたslackのURL";
var data = {"channel": channel, "username": "bot名称", "text": body, "icon_emoji": ":smiling_imp:"};
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json",
"Authorization":"Basic _authcode_"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
var response = UrlFetchApp.fetch(url, options);
} catch(e){
var error = e;
Logger.log("message:" + error.message + "\nfileName:" + error.fileName + "\nlineNumber:" + error.lineNumber + "\nstack:" + error.stack);
r = null
return false;
}
return true;
}
なお現在ですが
Hubotによる自動化の推進は止めて、PagerDutyの運用を24365の
MSP業務に合わせる為に導入設計・導入を対応していますが、
PagerDutyの導入が一段落したらPagerDutyをベースに既存機能の置き換えや
PagerDutyによるMSP業務の見える化を実施する予定です。
うまく今あるサービスを活用し、足りない部分を実装して運用の負荷を減らして
いきたいと思います。
PagerDutyの解説(運用方法)もニーズがあれば投稿します
