Furyu
[フリュー公式]

Tech Blog

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

2018年11月2日

awata

pacemaker+corosync環境を作成した時にハマった話

こんにちは。
ピクトリンク事業部インフラ課の粟田です。
今回は pacemaker+corosync環境をCentOS7上に構築した時にハマった話を書こうかと。

発生した問題

サーバ2台(CentOS7)にpacemakerとcorosyncをインストールして環境を構築中にcorosyncが疎通できていなくて、pcs status corosync や crm_mon を実行すると、お互いにOFFLINE……

ログを見てみると unclean(offline)の文字列が見えたので、ググって出てきた結果を参照すると、再起動したら直ったというようなものが出てきたけれども解決に至らず……

原因

corosyncの設定時には(DNSで解決可能な)ホスト名を指定してたんですが、corosyncはこのホスト名を127.0.0.1と認識してたんでした。

なんで127.0.0.1になるんだろうと原因探していると/etc/hostsが悪さしてたんでした。

127.0.0.1にホスト名書くなよ……

きっとこの辺の設定を全サーバで意識したくなかったせいなんだろうな。

あとがき

無駄に時間使っちゃったよ……


2018年10月31日

Kayo

sudo: ruby: コマンドが見つかりません。。。

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

最近、サーバのリプレース作業の一環として、バッチスクリプトの移行作業を実施しています。この作業中、「sudo: ruby: コマンドが見つかりません」問題に出くわしたので、対処方法をシェアしたいと思います。

問題

フリューでは、rundeckを使って日次・月次のバッチを実行しています。

新しく構築した環境(以下、新サーバとします)に、従来通りの手順でスクリプトを実行しようとしたところ、エラーが出てしまいました。

今までは問題なく実行できていたのに、なぜ……?

対応策

sudoにオプションiをつけて解決しました。

詳細

エラーになっているexample.shの52行目を確認すると、rubyスクリプトを実行する記述がありました。

エラーの原因は、このrubyコマンドを実行した際、rubyコマンドが見つかりませんというエラーのようです。

実際に新サーバにsshログインし、rubyコマンドがないのかバージョン確認で検証してみました。

やはり、「ruby:コマンドが見つかりません」が出力されました。

旧サーバで実施すると問題ありませんでした。

rootで実施すると問題ありませんでした。

原因は、sudo経由で実行した場合、環境変数が引き継がれない...という問題でした。

もう少し詳しく説明すると

sudo はrootや他のユーザの権限でコマンドを実行することができますが、sudoの設定(/etc/sudoers)によっては、環境変数が引き継がれなかったり、上書きされる設定になっている事があります。

こちらは/etc/sudoersファイルの一部を切り取ったものです。

env_resetが設定されていてますが、これはsudoが実行された際、環境変数がsecure_pathの設定値に上書きされてしまいます。
またenv_keepにPATHがないためにPATHが引き継がれません。

上記のように、/etc/sudoersに追加することで、PATHを引き継ぐことができますが、
今回、私はsudoにオプション-iをつけて対応しました。オプション-iとは、何でしょうか?

こういう時は、–helpコマンドで調べると便利です。

では、 -i  オプションの効果を踏まえて、ruby の設定が環境変数のPATHに設定されているかを見てみましょう。

sudoだと環境変数のPATHが通っていません。
オプション-iを付けることにより、この問題を解消することができます。

補足

sudo のオプションに-Eがあります。

これも環境変数を維持してくれるものになりますが、これでは問題を解決することができませんでした。
原因は不明なので、こちらに関してはもう少し調査する予定です。

最後に

フリューでは、全ユーザにsudo実行できる権限を付与するかわりにrootでのシェル操作を禁止しています。

【理由】

  • セキュリティ向上のため
  • rootコンソールでシェル操作をすると、「誰」が「何」を操作したのか解りにくくなるため
  • sudoを使用してのroot権限での操作はログに残るので追跡調査が可能になるため

 

今回のように、sudoを使っているといくつかの問題に出くわすことがあります。
しかし、セキュリティを担保するためには、rootで直接実行するよりもsudoを使うよう習慣付けるのが望ましいです。
そのためにも、今回のようにオプションを調べて対応することが、今後も大切になりそうです。


2018年09月20日

Kayo

sshfsを使ってみました!

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「sshfs」をご紹介したいと思います。

sshfsとは

SSHを経由して、他のサーバのディレクトリをマウントすることができるコマンドです。

なぜ便利なのか?

私は日々の業務でよくAnsibleを使ってサーバのミドルウェアのインストールや設定などを行います。
※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

 

今までは自分のローカルUbuntu環境からAnsibleを実行していたのですが、Macから実行すると環境違いでエラーになる事などがありました。
この状況を解消すべく、インフラ課のメンバー全員が同じ環境でAnsibleを実行できるよう専用サーバを構築しました。しかし、ローカルとリモートのコードを2重で管理という面倒な仕様になってしまい、何か解消する方法はないかと悩んでいました。

blog1

そんな時見つけたのが「sshfs」です。
これを使ってリモートで直接コードを修正しつつ、ローカルでのデバッグ実行も可能となり、とても便利になりました。

NFSと比較した場合、リモートサーバでコマンドを実行する(=SSHでログインして実行する)環境が既にできあがっているので、ローカル側にプログラムをインストールするだけで実現可能というお手軽さもあります。

使い方は簡単

  • sshfsのインストール(Ubuntuの場合)

  • マウント方法

例として、私のローカルマシーンの/testというディレクトリを作成し、サーバserver1の/home/fujimoto.kayoディレクトリをマウントします。

あとは、sshfsコマンドをローカルマシーンから実行するだけです。

これでマウントができた状態です。実際にサーバserver1の/home/fujimoto.kayo配下には、example-ansibleディレクトリが存在しますが、
ローカルマシーンの/test配下にも同じexample-ansibleが存在します。

  • アンマウント方法も簡単

最後に

コードの2重管理がなくなったり、コードの修正をローカルで使い慣れている環境のエディタで編集できたり、ちょっとした工夫で日々の業務がスムーズに行えるようになりました。

是非、皆さんもこの「sshfs」を使ってみて下さい!


2018年08月27日

Kayo

サーバ増設したらDNSラウンドロビンが壊れた!?

はじめに

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

 

先日、稼働中のサーバにアクセスが集中したため、サーバ増設を行いました。

その作業の1つとして、DNSラウンドロビン設定に増設したサーバを追加したのですが、上手く負荷分散されず、今まで特に問題なく利用していたDNSラウンドロビンの思わぬ落とし穴にはまってしまったので、忘れないようにブログに書いておきます。

DNSラウンドロビンとは

1つのドメイン名に複数のIPアドレスを割り当て、負荷を分散させる技術のこと。

スライド1

 

メリットは、簡単に設定ができることです。

スライド2
私が行ったように急遽サーバ増設が必要になった場合でも、zoneファイル上の対象ドメイン名に増設したサーバのIPアドレスを追加するだけで負荷分散してくれます。

 

デメリットは、万が一、サーバに障害が発生しても検知することができず、負荷を分散し続けてしまうこと。結果クライアントにエラーが返されてしまいます。

はまったこと

zoneファイル上の対象ドメイン名(test.com)に、増設したサーバ2台のIPアドレスを追加しました。

下記、実際に追加したzoneファイルの中身です。

この変更を加えるまでは、問題なく4台で負荷分散できていたのですが、2台を追加したことで、この2台しか負荷分散ができなくなったしまったのです。

スライド3

原因

DNSラウンドロビンの数に制限があるかなど、色々調べてみましたが、

原因は、増設したIPアドレスの「一致長が変わったのが原因でした。※参考になったURLがこちら

スライド4

4列目のIPアドレスと問い合わせる側の自分のIPアドレス(192.168.0.1)を比較し、一致する部分の長さが最も大きくなるものが使われるようです。つまり、増設した192.168.0.6と192.168.0.7が選択され、それ以外のものは使われなくなってしまったということです。

対応策

一致長が異なるのが問題だったので、これを合わせてやる(別のIPアドレスを使う)ことで増設することができました。

まとめ

DNSラウンドロビンはとても簡単に設定ができるので、弊社でも長らく利用してきました。

今回、思わぬ落とし穴にはまってしまったのですが、DNSラウンドロビンの問題は今回のものだけではありません。例えば、DNSサーバのBINDのバージョン9.13.2(unstable版)では、そもそもラウンドロビンが動作しなくなっているようです。
DNSは名前解決に専念させ、負荷分散はロードバランサに任せるなど、今後もDNSラウンドロビンを使い続けるかどうか慎重な検討が必要のようです。


2018年07月30日

Kayo

便利なtmux-xpanesのご紹介

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「tmux-xpanes」をご紹介したいと思います。

 

すでに「tmux-xpanes」ご存知の方いらっしゃるかもしれませんが、とても便利なコマンドです。

私は業務でよくサーバにsshログインし、コマンドを実行します。よくあるケースが、10台のサーバに配置された同じサービスをそれぞれ起動したりします。今までは、1台ずつサーバにsshログイン→起動→起動確認→次のサーバという動作を繰り返していました。

 

繰り返すのはとても面倒ですし、時間もかかります。そんな時見つけたのが「tmux-xpanes」です。「tmux-xpanes」を使うと、このような10回繰り返す操作を1回で済ませることができるのです。更に、サービス起動を同じタイミングで実施したいという場合にもとても便利です。

 

「tmux-xpanes」のインストール方法や詳細については、公式のREADME.mdに詳しく書かれているのでご覧ください。

使い方

例として、test-01~04というサーバにログインして、一度に4台すべてのhttpdを起動させます。
まず、ターミナルを開いてサーバにログイン。–sshオプションをつけて、sshログインします。
※他にもオプションがありますが、私が良く使うのはsshです。その他のオプションについては、先ほどの公式README.mdを見て下さいね。

<実際の画面>

1

Enterを押すと、画面が4分割され、サーバ4台にログインできました。

<実際の画面>

2

あとは、httpd起動コマンドを入力するだけですが、4サーバで同時にコマンドが打てます。

<実際の画面>

3

無事4台同時に起動することができました。

<実際の画面>

4

最後に

「tmux-xpanes」は、複数台同時にコマンドが打てるので、仕事も捗ります。

みなさんも是非、この便利な「tmux-xpanes」コマンド使ってみて下さい。
ただし、間違ったコマンドを打ってしまうと大変なことになったりもしますので、操作するときは気をつけて下さいね。