リモートでの設定管理について (NETCONF)
とあるサーバを作っているんだけど、その設定をネットワーク越しに実行して管理できれば便利だなー、と思った (というか設定管理系を自分で作るのが面倒……)。
SNMPはどっちかって言うと監視用な気がするし、MIBはそれなりに複雑だ。
そこでリモートで設定を構成・管理するためのプロトコルについて簡単にサーベイにしたので、覚書。
NETCONF (NETwork CONFiguration protocol)
- ネットワーク構成プロトコル。RFC 6241。
- 設定情報の定義は、YANG (RFC 6020)で書く。
- SNMP代替にななる部分が多い。
- RFCの一覧はNETCONF WGを参照。
実装
- Netopeer2
-
- NETCONFサーバ。libnetconf2に基づく。
- Netoppeer2はNETCONFによるサービスの提供だけを行い、実際の設定はsysrepoを通じて管理する。
- 具体的な構成は、sysrepoで提供されている図がとてもわかりやすい。
- sysrepo
-
- YANGで定義された設定と状態を保存するためのデータストア。
- NETCONFで設定を公開したいサーバは、sysrepoに対してアクセスすることで設定を保存できる。
- sysrepoに対するアクセスのために、クライアントライブラリが用意されている。
- sysrepoとのプロトコルはGoogle Protocol Buffersで定義されている。
Windowsで任意のアプリをサービス化するには
(これはまだ完成していない。)
NSSM ( the Non-Sucking Service Manager) を使う。NSSMを使うと、任意のアプリケーションをサービスとして実行できる。
これまで
Windows Server 2003 Resource Kit Toolsに含まれる、srvany.exeおよびinstsrv.exeなんかを使っていた。けど、これはちょっと問題があったりする。サービスとして実行したアプリが死んだ時、自動的に再起動してくれなかったりとか。インストール時におけるOSのバージョン制限があったりとか。srvany.exeだけダウンロードできなかったりとか。いろいろです。
その辺りのケアもしてくれるのが、NSSM。上記の制限がなく、ついでに設定だってGUIでできちゃったりする (コンソールがまったく要らなくなるわけではないんだけどね)。
とりあえずソースも公開されているので、必要なら改造だってできるはず (ライセンスはパブリックドメインですよ)。
NSSM自体のインストール
NSSMそのものは、適当なフォルダにおけばいい。しかし、CLIでのコマンドによる操作が必要になるので、環境変数PATHに含まれるフォルダにおいておくと便利です。
各サービスのインストール
C:\> nssm install service_name
とすると、service_nameという名前でサービスがインストールされる。この名前はいろいろ使うので、ちゃんと覚えておくと捗ります。
そうすると、設定用GUIが起動する。
サービスの設定
(TBD)
各サービスのアンインストール
C:\> nssm remove service_name
とする。確認ダイアログがでるので、「Yes」と答えればアンインストール実行。
NSSM自体のアンインストール
単純に消せばOK。ただし、NSSMを使ってインストールしたサービスは先に削除しておくこと。そうでないと、色々大変になる可能性が高い (サービスが起動できない! ってログがたくさん残ってしまう)。
使い方の例
外部Webサーバをリバースプロクシにした上で、内部でWebアプリケーション・サーバを複数動かすような構成を考える。
このとき、ThinをWebアプリケーション・サーバとしたRailsアプリを動作させたいとする。
Linuxなんかではごく普通に構成できるこの組み合わせだけど、Windows環境下においてはいろいろ面倒なことがおこる。ThinはWindows上でのデーモン化 (Windows語でいうならサービス化だ) をサポートしていないからだ。
もちろん、手動で起動してがんばる手もあるんだけど、Windows Updateなんかによる自動再起動が有効になっていた場合など、ちょっといろいろ面倒。手動で更新してる場合でも、再起動ごとに忘れずにThinを起動しないとサービス不能になっちゃうし。
こんな時、NSSMをつかってプロセスをサービス化してしまえば、OSの再起動にも負けないサービス提供ができるようになる。RubyやRailsの生産性・既存資産を使いたいんだけど、どうしてもWindows環境を使わざるを得ない制約があるとき、NSSMはとても有効な解になる。
(TBD)
セキュリティ基準について
セキュリティ関係はほんとに面倒で、チェックするべきことが多すぎる。
残念系ノーミソには難しすぎ、その上やらかしてしまうと命取り。知らなかったじゃ済まされない!
というわけで、後から楽するためにいろいろサーベイしておきます。
よく知らない分野の1つなので、気がつくたびに追記していく方向で覚書。
基準、仕様、および規格
PCI DSS
- クレジットカード情報を取り扱う際のセキュリティ基準。
- 要求される基準を達成するために、チェックするべき項目を具体的にまとめたもの。
- 日本語版がある!
- PCI Security Standards Councilが策定。Visaなどのカード会社さんだね。
- 詳しくはWikipediaの当該項目参照のこと。
- NTTデータ先端技術さんが提供している、「PCI DSS徹底解説」もありがたい。
これを使えば機械的に全てがセキュアになるというわけではないけど、何をどうチェックすればいいのかが具体的。とってもありがたい。
もっと追記できるようがんばる。
Gentoo Linux (OpenRC) でinitスクリプトを書くには [多重起動編]
基本編から続く。
「楽をするためならどんな努力も惜しまない」のが、良いプログラマの条件なんだって。
それが正しいかどうかはともかく、確かに同じようなこと何度も繰り返すのは面倒だと思う。
例えば、こういう場合。
- 複数のWebアプリ、例えばSinatraでWebアプリを作った場合を考える。
- その場合、サービスを提供するにはWEBrickかThinを使うことが多い。
- そうすると、各Webアプリの起動方法は同じだが、起動オプションや設定ファイル (文書ルートやDBの接続先など) のみが異なることになる。
このように多くのWebアプリを、initシステムを使って管理する必要がある場合、細かいオプションのみ変えたinitスクリプトをたくさん作らないといけない……。
コピー&ペーストでもいいけど、数が多くなるとバグの温床になりそうだ。
これを解決するには、1つのinitスクリプトを異なる設定で起動できるようにして、initスクリプトと設定ファイルを分割して、多重起動できるようにする方向でがんばる。
今回は、こんなユースケースに対応するinitスクリプトをメモメモ。
続きを読むGentoo Linux (OpenRC) でinitスクリプトを書くには [基本編]
何かの機能を提供するシステムを構成する時、OSのパッケージ管理システムに必要なサービスが含まれていなくて、手動でインストールしないといけない場合がある。
その場合、困るのが「再起動時の自動起動」。手動でやってると、メンテナンスで再起動なんかした時に、つい忘れてしまうんだよね。
ここは精神の安定とシステムの平和を守るためにも、自動にしておきたいところ。
Gentoo (正確にはOpenRCをinitシステムとして使っている場合のみだけど ) では、initスクリプト (起動スクリプト) を用意してやることで、サービスや開始や停止、自動起動の登録などの制御ができるようになる。
これは、サービス (デーモン) を自作するときにも役に立つ。例えばWebアプリを稼働させる場合、キャッシュサーバ、Webサーバ、アプリサーバ、DBサーバなどが相互に依存して絡み合いながら動作するので、適切な起動順で各サービスを自動起動させるのは、運用上、結構重要だ。
というわけで、今回はOpenRCにおけるinitスクリプトの基本をメモメモ。
続きを読むちょっと知識のある人向けGentoo Linuxの簡単な紹介
Linuxの使用歴が長い人は、Gentoo Linuxをご存知だと思う。
「何でもできるが、目的がなければオプションが自由すぎて何にもできない」ことで有名な、あの小粋なあんちくしょうだ。
しかし実際に使ってみると、サーバ用途とかCLIを用いた開発環境としては結構向いてると思うのだ。
ここでは、ちょいとLinuxを知っているけどGentooを知らない人向けに、Gentoo Linuxを簡単に紹介してみたいと思う。
続きを読む