Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月11日

furusin

指定したURLへのアクセスをcronのように定期実行する

こんにちは。ピクトリンク事業部の古川です。

この記事はフリューAdvent Calendar 2018の12/11分となります。

今回は、URLへのアクセスを定期的に実行してくれるWebサービス「cron-job.org」についてです。

はじめに

自分でWeb APIを立てて、GETやPOSTを定期的に実行したい時はないでしょうか。

私の場合、個人的にFirebase Cloud FunctionsにRest APIを作ったものの、定期的に実行する方法が無かったので色々な方法を探していました。

Firebase Cloud FunctionsのAPIを叩くためだけに別のサーバを建てるのは…うーん…

と考えていた時に出会ったのが、このcron-job.orgでした。

ちなみに日本語版はありません。英語とドイツ語のみです。

ですが非常に簡単なので、下記に説明しますのでご安心ください。

あ、あとオープンソースなのでコントリビュートも可能なようです。

実際に使ってみる

cron-job.org にアクセスしましょう。英語ですが大丈夫です。

スクリーンショット 2018-12-04 15.19.49

ユーザー登録する

登録は簡単ですので、画面右上の「Signup」から必要事項を入力して「create free account」をクリックしましょう!

スクリーンショット 2018-12-04 15.27.58

実際にジョブを作成する

画面右上の「Members」から「Cronjobs」を選択し、「Create cronjob」を押下します。

スクリーンショット 2018-12-04 15.30.27

cronを実際に作成する画面は以下のようになっています。

設定できる項目

  • HTTPの認証
  • 定期実行の時間的条件
    • ◯分ごとに実効する
    • 毎日◯時◯分に実行する
    • 毎月◯日の◯時◯分に実行する
    • 自分で決める(複数選択可)

私がやりたかったのは「5分毎にFirebase FireStoreの情報を更新する」ことだったので、

「Every 5 minutes」として設定して実行しました。

時間の色々な選択肢があるのはステキです。

スクリーンショット 2018-12-04 15.38.31

 

リクエストに失敗し続けたらどうなるの?

たとえばRest APIサーバが死んでいて、リクエストが失敗し続けたとしましょう。

その場合、以下のような内容でメールが来て「めっちゃ失敗してるからCron-Job止めたやで!」と知らせてくれます。

まとめ

いかがでしたか?

cron実行だけのためのサーバを建てずとも、簡単にHTTPリクエストを送り続ける設定を作ることができました。

失敗したときもメールで知らせてくれますし、個人で使うには便利なツールかと思います。

ちなみに、つい先日Google Cloud Platformに「Google Cloud Scheduler」が登場したようです。

cron-jobsと似たような動きをしてくれるもののようですので、そちらも試してみてもよいかもしれません!


2018年10月16日

awata

ansible で become_user が失敗した時の対応

はじめまして。こんにちは。
ピクトリンク事業部インフラ課の粟田です。

今回の内容を書くに至った経緯

ansibleを社内で利用している事は他の記事を参照してもらえればわかると思いますが、今回そんな運用の中で発生した問題とその解決方をメモとして残しておこうという次第です。

ついでに周りからのなんか書いて投稿しろ、という感じだったりします。

 

発生した問題

ユーザ管理とsudoの権限設定にはldapを使用している環境になります。

実際にログインした状態で

などは実行できます。

また、ansibleを実行する際に、ansible_ssh_userにrootを基本的には使用しないのが運用ルールとしてあります。

どのサーバにもrootでログインしようとする人が居るので、これは禁止すべきでしょ、普通。

この状態で、以下の様なplaybookを実行するとエラーになりました。

エラー内容はこう(あまりにも見難かったのでjqで整形してあります)

become_userを記載しない場合には問題なく実行完了するので、油断してたんですが、実際にログインして、コマンドを実行してみました。

ようは、

  • ansibleでログインする際のユーザは一般ユーザ
  • 一般ユーザでもsudoできる
  • sudo -u 別ユーザ コマンド が実行できない

という部分がポイントです。

そんな環境そうそうないでしょうけど…

解決方法

  • 今更ldapの設定を変更して失敗したら影響範囲が大きいのでとっても億劫
  • 一部バッチ処理でもsudoしてるのがあるのでldapいじりたくないな
  • とりあえず、運用としてansibleユーザだけなんとかできれば良い

という事で、ansibleユーザのsudoの権限を単純に解決することにしました。

としてローカルで作成したファイルをansibleのcopyモジュールでリモートの/etc/sudoers.d以下に配置するという最も単純な手法で解決としました。

あとがき

ldapサーバ作った時にもうちょっと検証しておけば…

内輪ネタは削除された…


2018年03月27日

CentOS7でのSpring Bootの起動について

こんにちは。フリューのジョンです。

さてさて、以前以下の記事でSpring Bootアプリケーションのserviceでの起動について触れました。
Spring Boot アプリケーションの再起動時にハマったこと

しかし、上記はCentOS6での話でした。CentOS7になるとより柔軟なサービスの管理ができます。
さて、何が変わるのでしょうか?

serviceとsystemctlの違い

私が感じている良い点としては以下です

  1. systemctl statusでサービスの状態がわかる(いつ起動したのかなどもわかります)
  2. 後述する、ユニットファイルの設定によって起動の依存を記述することができる(あるサービスが起動していなければ動かさないなど
  3. 起動時、停止時に呼ばれるスクリプトを指定することができる

実際に複雑なマイクロサービスを作っていく上では欲しい機能になるかと思います。

変更方法

主に前回のものとの比較になりますが2点が異なるのみです。

サービスの登録方法がことなる

サービスの登録には以下のコマンドを実行していましたが

CentOS7では、プロセス名.service というユニットファイルを /usr/lib/systemd/system に配置します。
中身は以下のようになります。(中身の詳細は 9.6. システムのユニットファイルの作成および変更 を参照ください)

プロセスの起動方法が異なる

サービスの実行には以下コマンドで実行していましたが、

CentOS7では、systemctlコマンドを利用します。

この2点だけです。それ以外のconfファイルの書き方、配置などは全く変わりません。

補足

デフォルトのユニットファイル設定では /var/log/messages にログが吐き出されます。
そのため、アプリケーションのログは別に出しているし、ここに吐き出されたくない場合はユニットファイルのServiceに以下を追加します。

まとめ

systemctlコマンドによる起動で再起動スクリプトを自作する必要もありません(serviceによる起動でも同じですが
マイクロサービスを進めていくには、インフラ回りについてきちんと勉強していく必要があると感じます。

それでは素敵なマイクロサービス運用、Spring Bootライフを!!

弊社では一緒にサービスを作ってくれるSpringエンジニアを募集しています!!

詳しくはこちら

追記:

Spring Boot 2系でのリリースについて若干変更がありましたのでページを作りました。
Spring Boot 2系でServiceによる起動をさせてみる


2013年11月15日

kasuya

CentOSでScalaからSoXを使って音声ファイルを操作する手順

ソフトウェア開発部、粕谷(@daiksy)です。

今回は音声ファイルの操作についてのお話です。

我々のチームでは、ソーシャルゲームのサーバサイドの開発・運用を行っています。
昨今のソーシャルゲームは、アニメーションや音声の再生など、一昔前に比べて表現がずいぶんリッチになっています。

そのような流れの中で、我々のチームでも音声ファイルの操作について検証をはじめました。

別にどのような技術を用いても良かったのですが、我々のチームでは、ゲームのサーバサイドのシステムをPlay + Scalaで構築しており、どうせならScalaから音声ファイルを操作しようと思いました。

やりたいことは、

  • wav -> mp3 などの形式変換
  • 音声ファイルのサイズ(再生秒数)の取得
  • 複数の音声ファイルの結合

の3要件です。

我々が扱っているScalaは、JVMで動作する言語であり、Javaの豊富なライブラリを使用することができます。
そういったライブラリ群を用いれば、音声ファイルの操作は行えるでしょうが、今回はそれらを使わずにSoXというツールをScalaから呼び出すことで要件を実現することにしました。
理由は、SoXは基本的にコマンドラインで音声ファイルを操作するツールなので、Scalaからこれらのコマンドを呼び出せば、Javaのライブラリを使うよりも楽に要件が実現できそうだったからです。

まとめると、システム構成は以下のようになります。

  • OS: CentOS 5.5
  • 使用言語: Scala
  • 音声ファイル操作: SoX

まず、最初の手順としては、SoXをCentOSにインストールする必要があります。
インストールは実に簡単で、wgetで最新版をとってきて解凍し、makeするだけです。  

 
これだけで、SoXは使えるようになるはずです。しかし、CentOSを扱っている場合は注意が必要です。  

 
を実行すると、SoXの設定状態が一覧表示されます。この時点での設定状態を見てみましょう。
注目すべきはこの部分です。  

 
ご覧のように、mp3がサポートされていません。
今回、我々はmp3のファイルを扱う必要があるのですが、CentOSはデフォルトではmp3を扱えないのです。 そこで、mp3を扱うために必要なライブラリを入れましょう。  
こちらのサイトを参考にしました。  

 
再度、SoXをmakeします。  
 

 
これで、SoXの状態が下記になっていれば準備完了です。    

 
サーバでSoXさえ動くようになれば、Scalaからこれを呼び出すのは容易です。  
ScalaからOSのコマンドを叩くには scala.sys.process を使います。
これは非常に強力で、import scala.sys.process._とimportすると、Scalaの暗黙の型変換(implicit conversion)によってStringにプロセスを実行するメソッドが拡張されます。  
例えば、  

 
を実行してやると、変数retls -lコマンドの実行結果が格納されます。
詳しくは、こちらをご参照ください。  
この scala.sys.process と、Scala2.10のString Interpolationを組み合わせることで、可読性も非常に高くSoXコマンドを扱うことができます。
それぞれのコード例を見てみましょう。  
 
例1) wav -> mp3 の形式変換

 
例2) 音声ファイルのサイズ取得

 
例3) 複数の音声ファイルの結合

 
非常に簡単ですね!!


2013年09月4日

kunihira

AnsibleでNginxインストールしてみた

全国のプロビジョニングフレームワークファンの皆さんこんにちは。 フリューChef導入委員長(自称)の国平です。

前回の記事から2ヶ月も間が開いてしまいました。 この2ヶ月間何をやっていたかというと、ネタLTしてみたり、フレームワーク作ってみたり、夏サミ2013に参加してみたり、あとはひたすらPlay2.1+Scalaと格闘していました。

さて、今回の記事ですが、プロビジョニングフレームワーク周りでChefの対抗馬として注目を集めているAnsibleを触ってみたので、その使用感をレポートしたいと思います。

目的

本記事の目的は、プロビジョニングフレームワークの検討です。 前々回の記事で、ChefとFabricを使ってみた感想をまとめましたが、同様にAnsibleを検証してみます。

Ansibleとは

http://www.ansibleworks.com/

Ansibleは最近話題の構成管理ツールです。 Python製のツールで、サーバの環境設定はPlaybookと呼ばれるyaml形式のファイルにまとめます。このPlaybookがChefのrecipeに相当します。 構成管理ツールとして作られているので、べき等性が保証されており、Playbookに記述した状態にリモートマシンを収束させます。

サーバに対する操作はsshで実行されるので、リモートマシンにAnsibleをインストールする必要がなく、Ansibleをインストールしたマシンが1台あれば利用出来ます。

使ってみる

今回もNginxのインストール手順をAnsibleで自作してみました。 Nginxインストールの要件は、以前の記事と同じで下記のようになっています。

  • Nginxをソースからビルドする
  • ビルドに必要なライブラリもインストールする
  • nginx.confを配備する
  • nginx.confはテンプレートを用意し、本番環境/開発環境で設定内容を書き換える
  • 本番環境は、AWS EC2のm1.largeを想定しworker_processを2に設定
  • 開発環境は、m1.smallを想定し worker_processを1に設定

ファイル構成

Ansibleを実行するための最小ファイル構成は、非常にすっきりしています。 公式ドキュメントでは、ディレクトリ構成などのベストプラクティスも紹介されていますが、今回は以下のディレクトリ構成となりました。 Chefに比べて非常にスッキリとしています。

このPlaybookはGistで公開しています。 Playbook|Gist

今回、環境ごとに変数を切り替える方法が調べきれなかったので、実行時に外部から–extra-varsオプションで変数を渡すことでnginx.confの出し分けを行いました。 (こういった出し分け方法をご存知の方がいらっしゃれば是非ご教授ください。)

使った感想

いろいろなところで、「Chefに挫折したのでAnsible」という記事をよく見かけますが、確かにChefより実行環境の構築が楽で、やりたい事が記述しやすいように思います。 特に、Push型の構成で、リモートサーバに対するインストールが不要というのが大きいと思います。 Chefの場合ですと、knife-soloを利用する事で、Push型に似せた実行が出来るのですが、やはりプラグインを追加でインストールしなくてはならない上に、あくまでPush型ライクな実行ができるだけにとどまっています。

Playbookもシンプルなので、これまでシェルスクリプトを書いていたり、実行していたコマンドを元に、書き起こしやすいと思います。

ただ、やはりyamlファイルなので、込み入った事がやりづらいという印象でした。 今回のような、変数の出し分けで、まずはPythonのDictionaryを使いたいと思ったのですが、yamlで扱う方法がわかりませんでした。 この辺り、ChefやFabricならRubyなりPythonなりでダーティーながらも、やりたい事を無理矢理書いて動かしてしまえました。 その一方で、Ansibleは、きちんと型に沿って利用するのが大前提になっているようです。

Chef/Fabricとの比較

どのツールでも、サーバに対する操作をソースコードにまとめられるので、Gitなどでバージョン管理する事が出来ます。 また、Ansibleはべき等性が保証されている点がChefと同様であり、リモートマシン環境を収束させるという使い方で実力を発揮します。

その一方で、Chefが基本的にはサーバ/クライアント構成のPull型アーキテクチャであるのに対して、AnsibleはFabric同様のPush型アーキテクチャになっています。

比較表

項目 Ansible Chef Fabric
構成 Ansibleサーバ → リモートマシン Chef-Solo Fabricサーバ → リモートマシン
言語 Python(2.6~) Ruby(1.9系) Python(2.5~)
設定ファイル yamlで記述 DSLで記述 Pythonで記述(シェルライク)
日本語ドキュメント 少ない 豊富 少ない
サンプル 少ない 豊富 少ない
サーバ追加の作業 少ない:実行先をhostsファイルに追加するだけ 多少多い: Chefインストールの手間がかかる 少ない:タスクの実行先を追加するだけ

まとめ

今回、話題のAnsibleを利用して、使い勝手を検討してみました。 環境構築が楽で、すぐに実行出来る点は非常に優れていますが、一方でyamlの記述力が物足りない感じでした。

また、あくまで現段階の比較ですが、Chefが既に膨大なrecipeが公開されているのに対して、Ansibleは参考になるPlaybookが見つけづらく、日本語の資料もまだまだ少ないようでした。 この辺りは、時間とともに充実してくると思いますが、現段階ではChefの方が情報がまとまっていて、扱いやすいように思いました。 また、VagrantはAnsibleも使えるようになったようですが、AWS OpsWorksやPackerなど利用されている範囲が広い点でも、まだChefが優位な様子です。

参考

最後に、Ansibleを利用する上で役に立ったサイトを挙げておきます。