RSpecとMinitestの違いってなんだろ?
Rubyで利用できるテスティングツールのRSpecとMinitestについて違いを軽く調べてみた。
きっかけ
bundle gem
でgemパッケージの雛形を生成しようとした時の話
❯ bundle gem ressy_gem_sample [19:31:20] Creating gem 'ressy_gem_sample'... Do you want to generate tests with your gem? Type 'rspec' or 'minitest' to generate those test files now and in the future. rspec/minitest/(none):
こんな質問が飛んできた。
「どっちにしようかな?&この2つってどう違うんだろ?」ってなったので軽く調べた。
RSsecとMinitestの違い
ここを参考にしました。
RSpecとMinitest、使うならどっち? / #kanrk06 // Speaker Deck
できること自体はRSpecもMinitestも差して違いはないみたい。
それ以外の部分で違いがあって、ざっくり比較するとこんな感じ。
- 文法・構文の違い
- 利用率、情報量
- RSpec:多い
- Minitest:少ない
この辺を踏まえて、とりあえずRSpecを使うことにした。
理由
- 情報量が多いので、自己学習目的としてはとっつきやすいと判断
- RSpecを身につけてから、Minitestを勉強し始めても遅くはないかなと思った
参考
この記事は以下を参考にしています
RSpecとMinitest、使うならどっち? / #kanrk06 // Speaker Deck
pingコマンドについてちょっとだけ調べてみた
ネットワーク疎通を確認するためにpingコマンドを結構使いますが、なんとなく使っている人って結構いるのではないでしょうか?(自分もそうです)
というわけでpingコマンドのことを少しだけ調べてみました。
pingの仕組み
仕組みと言っても、結構シンプルですね。
ここでは、サーバAからサーバBへpingを実行した場合で説明します。
- AからBへICMP echo requestが送信される
- BはICMP echo requestを受信する
- BからAへICMP echo replyを送り返す
これだけです。
echo request/replyというだけあって、Aが「ヤッホー」っていったらBから「ヤッホー」って返ってくるイメージですかね。
pingコマンドって意外とオプションとかが多い
こちらの記事をよんでみると、pingコマンドって結構できることがあるみたいですね。
Linuxのpingコマンドで覚えておきたい使い方16個(+2個) | 俺的備忘録 〜なんかいろいろ〜
試行回数を指定する-c
とか、インターフェースを指定する-I
とかは結構使いますけど、pingコマンド実行中にCtrl + \
を押下すると、パケットロスなどの実行状況を表示できるのは初めて知りました(自分が知らないだけ?)。
参考
この記事は、以下を参考にしています。
ネットワーク・コマンド道場 - pingコマンド -- No.1 トラブル対策の基本,パケットを送って応答を待つ:ITpro
Linuxのpingコマンドで覚えておきたい使い方16個(+2個) | 俺的備忘録 〜なんかいろいろ〜
サーバ監視に関する基本中の基本の話 part2
サーバ監視に関する基本中の基本について話していきたいと思います。
この記事の続きになります。
サーバ監視に関する基本中の基本の話 part1 - ressyのナレッジ的なブログ
注意
サーバ監視に関する基礎を書いて行こうと思いますが、私自身の考えも色々と含まれております。
中には、反論したくなるような考えもあるかもしれませんが、考え方の一つという程度に留めていただければと思います。
大まかなサーバ監視の種類
サーバ監視を行う際は、どのような監視をするか(目的)を明確にする必要があります。
対象のサーバが提供するサービスを正常に利用できなくなる要因は一つではないため、要因に応じた監視を行う必要があります。
おおよそ、以下のように考えることができるのではないかと思います。
監視対象に対する目的 | 監視方法 |
---|---|
サーバに到達するか | pingコマンドによる応答の確認 |
アクセス経路はどうか | tracerouteコマンドによるサーバまでの通信経路確認 |
意図した動作をしているか | サービスを実際に操作する動作の確認 |
パフォーマンスに問題ないか | 要求を出してから応答までの時間の確認 |
ネットワーク的に到達するかを確認する場合は、pingコマンドによる確認が定番かと思います。
サーバが落ちてないかどうかの確認を、pingで代用する場合もあるみたいです。
最後に
この記事を書いてたら、pingコマンドを無意識に 疎通確認
のために使っているけど、仕組みを詳しく理解しながら使ってないかもなぁと思いました。
(「ICMPを使っている」と考えた程度)
次回はpingコマンドのことを取り上げようかと思います。
参考
本記事は、以下を参考にしています。
サーバ/インフラエンジニア養成読本 管理/監視編 [24時間365日稼働を支える知恵と知識が満載!] (Software Design plus)
- 作者: SoftwareDesign編集部編
- 出版社/メーカー: 技術評論社
- 発売日: 2012/04/11
- メディア: 大型本
- 購入: 6人 クリック: 39回
- この商品を含むブログ (7件) を見る
マラソンの話:マラソンを走った後は体調を崩しやすい part2
今日は、前回の続きでマラソン後できるだけ体調を崩さないようにするための対策を話そうと思います。
特に大会直後(当日の夜など)の対策にスポットを当てます。
注意としては、疲労回復ではなく体調を崩さないための対策がメインだと言うこと。
なので、疲労回復に良い食べ物とかそういった話はほとんど出てきませんのでご了承ください。
前回:マラソンの話:マラソンを走った後は体調を崩しやすい part1 - ressyのナレッジ的なブログ
対策前の心がけ
マラソン後1〜2週間は体調を崩しやすいと考えてください。
前回、マラソン直後は体調を崩しやすいと話しましたが、これはマラソンを走った日に限ったことではありません。
最低でも、1〜2週間は免疫が落ちていると考えてください。
対策(大会後当日)
(1) 体を温めるものを事前に持っていく
マラソン後は、ただでさえ体温が奪われる状態になるので、体を温める手段を色々と用意しておきましょう。
事前に準備できるものとしては
- 着替え(できるだけ厚着)
- 使い捨てカイロ
などがありますね。
ランニングウェアで会場入り&完走後そのまま帰る人もいますが、 個人的にはオススメしません。
理由は、前回話した汗冷えになりやすいからです。
完走後はしっかりと汗を拭いて、温かい格好に着替えてから帰るようにしましょう。
使い捨てカイロなどもマラソン後の帰り道で役立ちます。
(2) 温かい&体に優しいものを飲む/食べる
これも体温が奪われないようにするための対策ですね。
温かいスープやホットドリンクが良いでしょう。
ただし、前回話した通り内臓のダメージが大きい状態なので、脂っこいものなどは避けてください。
ちなみに、大きい大会の場合、会場のブースで食べ物がもらえたりします(豚汁とかが多いイメージ)。
こう行ったブースも活用すると良いでしょう。
なければ、帰り道にコンビニに寄ってホットドリンク買って帰るなどでもありだと思います。
(3) 30分以上ウォーキングする
今までと真逆のような対策ですが、結構重要です。
ウォーキングによって、足回りに集中していた血液が全身に回りやすくなります。
すると、脳や内臓に血液が回るようになるので、結果的に体調が回復しやすくなります。
また、翌日以降の筋肉痛対策にもつながります(要はクールダウン)。
ただ、 ウォーキングについては体調に余裕があったらで構いません。
「体が痛い」などの場合は多少頑張った方が良いですが、「気分が悪い」などの場合は無理せず翌日でもOKです。
まぁ、大会が終わってからの帰り道で、駅まで歩くなどしておけば、だいたい15〜20分くらい歩いちゃうんですけどね。
(4) 家に帰ってからも体を温める
家に帰ってからも、風呂に入るなどして体を温めるようにしましょう。
自分の場合は、40度くらいのお湯に最低20分は浸かりますね。
熱い風呂だと心臓に負荷がかかったり、体からさらにエネルギーが奪われて、返って体調が悪化することもあるので避けた方が良いと思います。
後は、寝る前に軽いストレッチをしてさっさと就寝しましょう。
最後に
長々と書きましたが、ざっくりとポイントをまとめるとこの2点です。
- あの手この手で体を温める
- 疲労回復のためにウォーキングする
体を温める対策に関しては、風邪を引いた時のような対処をすると思えば良いでしょう。
自分の場合、マラソン後は油断するとすぐに寒気がするので体を温める対策は必要不可欠です。
なお、今回取り上げた対策は、体調を崩さないための対策です。
炎症した筋肉を回復させるために、部分的にアイシングするなどは全然OKですので、その辺はうまく組み合わせてみてください。
マラソンの話:マラソンを走った後は体調を崩しやすい part1
今日、ハーフマラソンを走ってきたのですが、走った後体調を崩してしまいました。
せっかくなので、何回かに分けてマラソン後、体調を崩しやすい理由を話そうかと思います。
(実はこの記事を書いてる今もちょっと熱が出ていたり。。。)
マラソン後は体調を崩しやすい?
体調管理のために、適度な運動をする人はたくさんいると思います。
実際、適度な運動は体の免疫力を高めるので、非常に良いことです。
例えば、週2〜3回、5〜10km程度ジョギングするとかでしょうか。
ですが、フルマラソンなどハードな運動をした場合は、逆に免疫が低下し、体調を崩しやすくなります。
自分の場合、マラソンの後は微熱が出たり寒気が出ることが多いです。
なぜ体調を崩しやすい?
簡単にいうと、体がマラソンで受けたダメージを回復することに注力し、風邪などの免疫で使う力も消費してしまうからです。
免疫が弱くなる結果、体調を崩しやすくなるということですね。
よくある症状は
- 風邪をひく
- 熱が出る
- 吐き気がする
などでしょうか。
自覚しやすい症状は上記の通りですが、実は身体中の内臓もダメージを受けています。
理由は、大きく二つです。
- 血液が筋肉へ集中することで内臓へ回る血液が少なくなり、内臓はその状態で疲労物質の処理をしているため
- 長時間の激しい運動で、内臓が揺れ続けるため
このように、マラソン(に限らずハードな運動)をした場合体調を崩しやすい状態になってしまいます。
特にマラソンの場合、寒い時期に大会が開催されることが多いことや、走った後は汗などで体温を奪われやすい状態(汗冷えと言います)になることが、拍車をかけます。
今日はここまで
本日は、マラソン後体調を崩しやすい理由を簡単に話しました。
次回は、その対策などを書こうと思います。
参考
この記事は、以下を参考にしています。
第155回:フルマラソン後の免疫力低下に要注意!二週間の“養生期間”の過ごし方・食事のとり方|走るなら食べよう!~体は必ず変わります~|JogNote連載・走る人の為の健康食事コラム
http://sports-crowd.net/detail.php?no=1646
サーバ監視に関する基本中の基本の話 part1
今回から、サーバ監視に関する基本中の基本の話を少しずつしていこうかなと思います。
本記事末尾の"参考"欄に記載した書籍を参考文献とし、サーバ監視の基礎を整理していこうと思います。
注意
サーバ監視に関する基礎を書いて行こうと思いますが、私自身の考えも色々と含まれております。
中には、反論したくなるような考えもあるかもしれませんが、考え方の一つという程度に留めていただければと思います。
監視の目的
今回は、監視の目的について取り上げたいと思います。
監視を行う一番の目的は、利用者が継続してサービスを利用できる状態か確認する事だと思います。
サービスにログインできないなど、サービスが正常に利用できない状態になってしまうと、エンドユーザがサービス利用をやめてしまうなど、利益を得る機会を失うことにつながりかねません。
そのためにも、サーバ監視をしっかり行いサービスの異常にいち早く気づくことが重要になります。
とはいっても、異常が一切発生することのないシステムというのはさすがに存在しません。
どんなに信頼性の高いシステムを構築しても、所詮は作り物。
サーバの劣化・パッケージ製品の不具合・プログラムのバグなどなど、異常のきっかけとなるものは必ず存在します。
バグなどを事前に潰しておくのは前提ですが、それでもどうしても異常は必ず発生します。
なので、異常が発生した場合にいかに早く検知し、早期復旧につなげるかも重要な要素となります。
そして、いち早く検知し、復旧するためにはどこに異常が発生したかをいち早く突き止められるような監視をすることも重要なのではと思います。
まとめ
- 監視を行う一番の目的は、利用者が継続してサービスを利用できる状態か確認する事にある
- 異常が発生した場合にいかに早く検知し、早期復旧につなげるかが重要になる
- ただ監視するだけなく、どこに異常が発生したかをいち早く突き止められるような監視をすることが大切
参考
本記事は、以下を参考にしています。
サーバ/インフラエンジニア養成読本 管理/監視編 [24時間365日稼働を支える知恵と知識が満載!] (Software Design plus)
- 作者: SoftwareDesign編集部編
- 出版社/メーカー: 技術評論社
- 発売日: 2012/04/11
- メディア: 大型本
- 購入: 6人 クリック: 39回
- この商品を含むブログ (7件) を見る
PuppetでApacheを管理してみる part3
前回に引き続き、Apacheの構成管理をやって見たいと思います。
前回:PuppetでApacheを管理してみる part2 - ressyのナレッジ的なブログ
httpd.confのテンプレートを用意する
前回の記事で作成したマニフェストのうち、ファイルリソースに注目しましょう。
# cat /etc/puppet/modules/http/manifests/init.pp ... # ファイルは、httpd.confのテンプレートを使用する file { '/etc/httpd/conf/httpd.conf': ensure => present, content => template('/etc/puppet/modules/http/templates/httpd.conf'), require => Package['httpd'], } ...
content => template('/etc/puppet/modules/http/templates/httpd.conf')
部分でテンプレートを指定しています。
というわけで、/etc/puppet/modules/http/templates/httpd.conf
を作成します。
httpd.conf
を一から作成するのは大変なので、/etc/httpd/conf/httpd.conf
をコピーして作成します。
ファイルがない場合は、一度yum install -y httpd
をしてファイルを用意しましょう。
(後々構成管理するので、一旦パッケージを入れてしまっても問題ないです。)
# cp -p /etc/httpd/conf/httpd.conf /etc/puppet/modules/http/templates/httpd.conf
httpd.confのテンプレートを編集する
続いて、コピーしたテンプレートを編集していきます。
今回はポート番号で、変数port
で指定できるようにします。
# cat /etc/puppet/modules/http/manifests/init.pp class http( $enabled = 'false', # 変数:運用する/しない $port = '80' # 変数:ポート番号(templatesで使用する予定) ) { ...
この変数port
をテンプレートに適用できるようにします。
テンプレートでListen
を以下のようにしてください。
# vi /etc/puppet/modules/http/templates/httpd.conf ... 127 # 128 # Listen: Allows you to bind Apache to specific IP addresses and/or 129 # ports, in addition to the default. See also the <VirtualHost> 130 # directive. 131 # 132 # Change this to Listen on specific IP addresses as shown below to 133 # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) 134 # 135 #Listen 12.34.56.78:80 136 # Listen 80 137 Listen <%=port %> 138 ...
ポイントは137行目の<%=port %>
です。
ここに、クラスhttp
の変数port
の値が設定されます。
テンプレートの設定は以上です。
マニフェストの適用
各サーバでマニフェストを適用します。
先に--noop
をつけてテストしましょう。
# puppet agent -t --verbose --noop Info: Retrieving pluginfacts Info: Retrieving plugin Info: Caching catalog for web01 Info: Applying configuration version '1479299354' Notice: /Stage[main]/Http/File[/etc/httpd/conf/httpd.conf]/content: --- /etc/httpd/conf/httpd.conf 2016-07-12 20:00:40.000000000 +0900 +++ /tmp/puppet-file20161116-25474-167ozr3-0 2016-11-16 21:29:15.637651861 +0900 @@ -133,6 +133,7 @@ # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 +# Listen 80 Listen 80 # Notice: /Stage[main]/Http/File[/etc/httpd/conf/httpd.conf]/content: current_value {md5}f6351c6d8c8dfc5899820d8c46d74651, should be {md5}8216a7e8c82725a59cdd504a2a007daa (noop) Info: /Stage[main]/Http/File[/etc/httpd/conf/httpd.conf]: Scheduling refresh of Service[httpd] Notice: /Stage[main]/Http/Service[httpd]: Would have triggered 'refresh' from 1 events Notice: Class[Http]: Would have triggered 'refresh' from 2 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.46 seconds
上記は、WEB01に適用した例です。
マニフェストを適用する様子が読み取れると思います。
エラーや警告が出ていなければ、--noop
を外して適用しましょう。
# puppet agent -t --verbose --noop
これを全てのAgentサーバで実行すればOKです。
以上で、Apacheの簡単な構成管理ができました。
前々回の記事以降で取り上げた内容を活用して、各自好みの構成管理をしてみてください。