状況に応じて正しいツールを選ぶ

Windows管理はもはやコマンドラインかGUIかではない　選択の基準とは

WindowsやLinuxの標準的なコマンドラインユーティリティーは、GUIツールにない重要な機能を提供する。カスタマイズしたワークフローを作成するために、こうしたツールは有用だ。

公開 2018年03月22日 05時02分

著者

Richard Siddaway

[TechTarget]

印刷する

CLIかGUIか《クリックで拡大》

　サーバ管理は仕事をこなすことが全てだ。できれば管理に費やす労力は最低限に抑えたい。標準的なGUI（グラフィカルユーザーインタフェース）を使うか、それともコマンドラインインタフェース（CLI）を使うのかは、状況による。

　Windows環境でLinuxが歓迎されない存在ではなくなったのと同様に、もはやCLI対GUIの世界ではなくなった。オープンソースサーバOSの何らかのバリエーションに遭遇する管理者は増え、そうしたシステムの管理について学ぶことが当然になるだろう。

併せて読みたいお薦め記事

コマンドラインを使いこなす

Windows Server最新動向

　異種が混在する現代のデータセンターでは、IT担当者がWindows ServerをLinuxマシンで管理することもそれほど非現実的ではない。Microsoftは「Windows Subsystem for Linux」にBashシェルを搭載した。これは両方のシステムで作業をこなさなければならないLinux管理者にとって素晴らしいツールだ。Microsoftは2017年12月にリリースしたビルド17063から、LinuxツールのcurlとbsdtarをWindows 10に移植した。その数は今後も増えることが期待できる。

　本稿では、利用できるユーティリティーの種類と、それぞれどんな場面に適しているかを取り上げる。以下にWindowsとLinuxの標準的なツールを紹介し、一般的な管理状況にどう適しているかを解説する。

CLIとGUIツールのメリットとデメリット

　標準的なWindowsツールとLinuxツールは、グラフィカル（GUI）ツールとコマンドラインツールの2種類に分類できる。

　ほとんどのWindows管理者は、GUIツールを習得している。MicrosoftはWindows 2000をリリースしたとき、コマンドラインツールとVBScriptを使ったスクリプティングの導入に多大な労力を費やした。そうしたWindows GUIツールは主に、管理者が自前のツールを作成できる「Microsoft Management Console」（MMC）をベースとしている。

　例えば管理者は、「Active Directory Users and Computers」ツールをMMCに読み込んで、ADSI Editおよびドメイン名システムの管理画面と組み合わせ、単一の管理画面でIT担当者の日常業務をこなせるようにすることができる。これは素晴らしいオプションだが、ほとんどのユーザーは個々のツールを使う方を好む。

　GUIツールのメリットは、特にWindowsの場合、同じようなルック＆フィールを搭載している点にある。1つのツールを習得すれば、難なく他のツールも習得できる。GUIツールはまた、クラスタの作成など、それほど頻繁には行わない作業に非常に適している。管理者が作業を完了するために一連の手順を踏まなければならない場合、GUIツールはそれを思い出させてくれる。

　ただし、GUIツールは速度に関しては大きな難点がある。画面操作のためのマウスと、データ入力のためのキーボードを使い分けなければならないことで、作業は遅くなる。

　私が従業員1万2000人の組織で「Microsoft Exchange」の移行を担当したときは、まずWeb上のOutlookを有効にしているユーザーの数を調べ、次にそのユーザーの設定を一部変更しなければならなかった。それほど多くのユーザーをGUIでクリックして処理する作業には時間がかかる。やりたいと思う人はほとんどいないだろう。

　コマンドラインツールは、特にWindowsでは、一般的に2種類に分類できる。まず、ipconfigやpingのように、誰もが知っていて使っているツールがある。こうしたツールにはGUI版がなく、ずっと前から存在しているので、管理者はこれを受け入れ、自動的に使っている。2つ目のグループには、chkntfsやwmicのように、特異の状況でしか使わないツールがある。

　コマンドラインツールには、主に2つの問題がある。第一に、構文が分かりにくい。コマンドとコマンドの間の一貫性は、ほとんど、あるいは全く存在しない。管理者は多大な時間をかけてそれぞれのコマンドを学習するか、常に構文を参照しなければならない。多くの管理者は諦めて、少ない労力で利用できるGUIツールに戻りがちだ。

　第二に、恐らくこちらの方が重要な点だが、コマンドラインツールは画面に文字が表示される。これは両立できる設計にはなっていない。管理者は、多数のコマンドラインツールの相互作用を伴うワークフローを確立できる。これは一般的に、1つのツールから表示される文字を、次のコマンドへと送り出すことによって行う。

　こうした管理のアプローチは、Windows管理者にとっては斬新に感じるかもしれないが、Linux管理者にとっては当然とされる。

　これをWindows側に実装するためには、解決すべき問題が幾つかある。1つのツールの文字を、2番目のツールが理解できる方法で解析しなければならず、そのためには正規表現の奥深くまで踏み込むゾッとするような文字列処理を伴うこともある。

　さらに、特定のコマンドによって表示される文字が、そのOSの別のバージョンでも変わらないという保証はない。文字が変われば、たちまちワークフローも崩壊する。

CLIとGUIを比べてGUI利用に傾く場面

　以下のような場面では標準ツールが適している。

管理するサーバは1台のみ。この場合、どのツールを使っても恐らく問題はない
1台のサーバで行う1回限りの作業
その作業を処理するツールが他にない
頻繁に行う作業ではなく、作業が完了するまでGUIツールが管理者を導いてくれる
1つのツールで作業をこなすことができる

　作業を行うサーバの台数が増えるほど、標準ツールの有用性は低くなる。サーバにログインしてツールを起動し、作業を実行するには時間がかかる。その大部分は、接続の待ち時間と、アプリケーションが起動するまでの待ち時間に費やされる。そうした待ち時間のために、全般的な生産性は低下する。

　複数のサーバで複数の作業を実行する場合、特にその作業がサーバの種類に左右される場合、こうした標準ツールの効率性は失われる。これを選べば、各サーバに順番にアクセスして作業を実行しなければならず、最悪の場合、管理者がそれぞれのサーバに何度も接続して1つ目の作業を完了してから、2つ目の作業に取り掛からなければならない。この方法では間違いが起こりやすく、時間もかかる。

　以上のような場面でCLIツールとGUIツールを比較すると、振り子はコマンドラインツールの方に傾く。管理者は、スクリプトを通じてそうした作業を自動化できる方法を見つけられる。

印刷する