達人が語る,インフラエンジニアの心得

第14回 インフラエンジニアとプログラム

この記事を読むのに必要な時間:およそ 2 分

以前に「クロスオーバー」というテーマで,インフラエンジニアとアプリケーションエンジニアは今後クロスオーバーしていく,という趣旨のことについて述べましたが,今回はインフラエンジニアについて必要だと思われるプログラムまわりのスキルについて考えてみましょう。

まずはシェルプログラミング

まず何はなくとも必要なのが,シェルプログラミングに関するスキルです。

今ではもうシェルプログラミングといえば#!/bin/sh 系で統一されたといっていいですが,以前はsh系(b-sh)とcsh系に分かれていたものでした。ただcsh系はシェルとしては(当時はshに対して)進んだ機能をもっていましたが,シェルプログラミングには向いていませんでした。筆者もcsh系のプログラミングはほとんどやったことがありません。ですのでbashが出てきたときには,⁠これでシェルプログラミングもしつつ便利な機能が使えるシェルが!!」とかなり喜んだことを記憶しています。

今では「bash vs. tcsh論争」とかほとんど聞かないですね。筆者は上記のようにbash派だったので,今のbashメインストリームは歓迎です。

コマンドラインプログラミングはキホン

シェルプログラミングの特徴としては,もちろんスクリプトを書いて実行するというのはあたりまえですが,コマンドラインプログラミングを非常によく行う,という点が挙げられます。

csh系でふだん作業をしているのに,コマンドラインプログラミングをするときだけshを起動するとか,いちいちスクリプトを書いて実行するのではやはり不便で,そのままサブシェルもなにもなくタイピングしたいところです。

コマンドラインシェルプログラムでやはりよくやるのが,

# for x in *
> do
> command-something
> done
もしくは

# for x in *; do command-something; done

といった全ファイル対象の作業ではないでしょうか? もちろん,

# find . -type f -name "*.txt" ¦ while read x
> do
> command-something
> done > command.log 2>&1

といったようなパターンもよくあります。

STDIN 食うか食わぬか

ところで上記には非常に大きな示唆があります。シェルプログラミングをする場合,⁠どの部分が標準入力を食うのか」はとても重要です。いわゆるSTDINです。たとえばforはSTDINを食いませんが,whileは食います。もちろんforでも

# for x in `find . -type f -name "*.txt"`
> do
> command-something
> done

とすることはできます。

STDINを食うのはいいことでもあるし,不便なこともあるのです。だれしも,シェルスクリプトやコマンドラインシェルプログラムがうまく動かなくて,原因をさぐったらSTDINを予定外のところで食われていたからだった,という経験はあるのではないでしょうか。

シェルプログラムといっても,tcpserverなどと組み合わせれば,Webサーバくらいは作ることができます。とはいえ,やはりシェルプログラミングの目的は,主にサーバ管理する上で作業を確実にする,速くする,楽にする,というシーンが多いでしょう。

またrc系などのサーバ管理で使われているプログラムはシェルスクリプトが多いので,いずれにしてもシェルプログラミングは身につけないとあるレベル以上のサーバ管理はできないことになります。

次にLL

シェルプログラムの次に必要なのが,なにがしかのLL言語の知識です。どうでもいいですがLL言語ってLが1つ多いですね。

あえて言い切りますが,以前であればPerl今後ならPythonでしょう。別に筆者の私見なので,異論もたくさんあると思います。⁠あんまりいくつも覚えるのは大変だからどれか1つといえばどれ?」と聞かれた場合,⁠サーバ管理でよく使われている言語がいい」というのが筆者の考えるポイントの1つです。

今のLinuxのディストリビューションであれば,以前であればPerlがよく使われており,最近はPythonが使われている場面が増えてきていると思います。たとえばyumなどはPythonで書かれています。

もちろんPerlでもRubyでもPythonでもいいのですが,ある程度のレベル以上のことをやろうとすると,シェルプログラミングでは厳しくなってくるシーンというのが遅かれ早かれやってきます。たとえばちょっと込み入ったことをするバッチファイルで,シェルでは厳しいのでPerlやPythonで,というのはよくあるのではないでしょうか。そして,どうせ覚えるなら,システム管理に使われているケースの多い言語のほうが一石二鳥ではあると思います。

ためしに,手元にあったマシンの/usr/bin以下を見てみました。

# file /usr/bin/* ¦ grep perl ¦ wc
135
# file /usr/bin/* ¦ grep python ¦ wc
78
# file /usr/bin/* ¦ grep ruby ¦ wc
5

これだけ見るとやはりPerlかPythonが良いように思えます。甲乙つけ難いとは思うので,まわりでよく使われている言語から手をつけるのも良いのではないでしょうか。

サーバ管理をしていると,多量のファイルのあるパターンに従って書き換えたいというシーンによく出くわします。シェルでsedやawkなどを駆使すればできなくもないかもしれませんが,やはりこういう場合にはPerlやPythonやRubyなどを使うほうが断然楽で,かつ確実に作業を行うことができます。

正規表現も押さえておけ

またもちろんその場合(だけではないですが)必要になるのが正規表現の知識です。実際インフラエンジニアはかなり正規表現にお世話になることは多いのではないでしょうか。もちろんPerlもPythonもRubyも正規表現はガッツリ実装してありますので,そのあたりの差はさほどありません。また,シェルプログラミングにおいてもegrepなどで正規表現を使うケースがたくさんあります。

正規表現自体は,多少の方言はあるものの言語を越えて共通な知識ですから,一度身につければさまざまなシーンで活用することができるようになります。

C/C++で差をつけろ

そして,インフラエンジニアにはC(C++)言語(以下C言語で統一)の知識もあるほうが良いでしょう。

多くのオープンソースのサーバ類はC言語で書かれています。問題なく動いているときは問題ないですが,いざconfigureしてmakeができないときなど,ヘッダファイルの知識,ダイナミックライブラリの知識,そしてソースコードを読めるかどうかなどは必要なスキルになってきます。

またRC版にしかまだ必要な機能が実装されていなくてRC版を使っているがbuggyで問題があるような場合なども,自己の責任において(ライセンスが許せば)ソースを改修して使うこともできます。

いまはconfigureからmakeでコンパイルが通らないものはあまり見かけないですし,そもそもyumなどでサーバ群をインストールしているケースも増えてきているでしょうから,以前に比べればC言語を(自由自在にとは言えないまでもある程度)習得する必要というのは減ってきているのかもしれませんが,習得しているインフラエンジニアとしていないインフラエンジニアには明確な差が,とくにクリティカルなシーンで差が出るのは事実です。

ちなみにサーバ群はパッケージ管理ツールでインストールしないほうが良いとは思いますが。

たとえば,残念ながらDJB系のアプリケーションは,最近はLinux上でそのままではmakeが通りません。error.hというファイルにおいて

extern int errno;

という部分を

#include <errno.h>

と書き換える必要があります。

まあDJB系のアプリケーションであれば情報がネットのあちこちにあるので困らないですが,C言語の知識があれば,こういった場面に自力で対応することができます。


今回は,インフラエンジニアに求められるプログラミングスキルについて解説してみました。インフラエンジニアが相手にするのはハードウェアとソフトウェアなのですから,ソフトウェアを構成するプログラムの知識があったほうが良いのは,むしろ当然だと言えます。

著者プロフィール

山崎徳之(やまざきのりゆき)

青山学院大学卒業後,アスキー,So-netなどでネットワーク,サーバエンジニアを経験。オン・ザ・エッヂ(現ライブドア)のデータセンターである「データホテル」を構築,運営。2003年にベイエリアにおいてVoIPベンチャーであるRedSIP Inc.を創業。2006年6月に株式会社ゼロスタートコミュニケーションズ(現 ZETA株式会社)を設立,代表取締役就任(現任)。ECソリューションの「ZETA CX」シリーズとして検索エンジンやレコメンドエンジンを開発,販売している。

blog:http://blog.zaki.jp/
社長コラム:https://zetacx.com/column

コメント

コメントの記入