実行するタスクの自動化は、システム管理者としての私たちの仕事の最も重要な部分の1つです。サポートするシステムを稼働させ続けるために必要な多くのタスクを実行するだけではありません。それは、私たち自身や、休暇中や病気のときに私たちの代わりになる可能性のある他のシステム管理者を簡単にすることです。それは、最小限の作業と介入で、迅速かつ簡単に仕事を遂行できるようにすることです。怠惰なシステム管理者になることについてです。
私は自分の本や記事で自動化について幅広く書いてきましたが、私の信条は常に「すべてを自動化する」ことです。しかし、どこから始めればよいのか、どうやってわかりますか？
[次のこともお勧めします：信頼性の高いLinuxシステム自動化のための8つのヒント]
問題点
私は、システム管理者が実行する最も重要なタスクの1つであるバックアップの主要な問題点を減らすことから、自動化への道を歩み始めました。私は非常に小さなネットワークから始めました。1台のコンピューターとインターネット接続です。バックアップは簡単でしたが、テクノロジーは最終的に失敗した一連のテープドライブでした。
最初に、金曜日の夜にすべての重要なディレクトリをバックアップするコマンドを入力し、バックアップが正常に作成されたことを確認するために時々チェックしました。それらは、主にテープが原因でした。
ネットワークが成長し、自分以外のネットワークを担当するようになると、コマンドラインを使用して複数のバックアップを作成するのが非常に面倒になることがわかりました。ただし、テクノロジーは進歩しており、外付けUSBハードドライブが優れたバックアップメディアになり、スクリプトを使用すると複数のコンピューターのバックアップがはるかに簡単になることもわかりました。 cronジョブまたはsystemdタイマーを使用すると、バックアップをスケジュールすることもできます。
私の現在のバックアップシステムは、rsyncを使用するBashスクリプトを使用して、既存のホームネットワークに最大12台のコンピューターのバックアップを作成します。バックアップは最初に4TBの内蔵ハードドライブに作成され、次に一連の外付け4TBUSBハードドライブの1つに書き込まれます。外付けドライブを貸金庫に簡単に移動して、オフサイトバックアップを行うことができます。このバックアップシステムの詳細については、私の記事「rsyncを使用してLinuxシステムをバックアップする」を参照してください。重要なのは、最も激しい問題点を見つけて、それから始めることです。
私の戦略
最初に、または次に何を自動化するかを決定するための戦略は、実際には1つしかありません。現時点で最も苦痛を感じているタスクを簡単に特定することです。その苦痛は、同じコマンドを繰り返し入力したり、次のコマンドを入力する前に何かが起こるのを待ったり、頻繁に使用するコマンドの適切な構文を覚えたりするなど、多くの時間を費やさなければならない可能性があります。
あなたはおそらく、あなたのシステム管理者の生活の中で最も苦痛の原因をすでに知っています。これは、自動化を最初に検討する必要があることです。特に、自動化が比較的小さく、完全な高度なバックアップシステムほど重要でも重要でもない場合はそうです。私は、tarとSSHのいくつかの楽しい機能を使用した簡単なバックアップシステムから始めました。これは、2015年のベストカップルで書いたtarとsshです。
私にとってのその他の問題点は、セキュリティや機能の修正、機能の強化など、Fedoraのアップデートを実行していることです。これには、Fedora32からFedora33など、あるFedoraリリースから次のリリースへのアップグレードの実行も含まれます。
タスクに関係なく、自動化を実装するための多くのオプションもあります。私の戦略の一部は、スクリプトを使用して、発生する可能性のある解決策と問題を完全に理解することから始めることでした。 1つのホストで問題を解決するためのスクリプトを作成し、それをネットワーク上のすべてのホストにコピーしてから、コマンドラインのBashプログラムを入力して、すべてのホストでそのタスクを実行します。これは次の形式を取ります：
for host-name in `cat ~/list-of-hosts` ; do ssh host-name "script-name"; done しかし、それでも、十分なネットワーク上に十分なホストがあると、雑用と別の問題点になります。一部のホストを他のホストとは異なる方法で処理する必要がある場合にも、問題が発生する可能性があります。 Ansibleなどのより高度なツールを使用すると、サーバーなどの特定のタイプを標準のワークステーションとは異なる方法で処理しながら、ネットワーク上の多くのホストでタスクを自動化できることがわかりました。 Ansibleは、その作業を実行するために各ホストにスクリプトを配布する必要はありません。各ホストにインストールする必要はなく、「ハブ」として使用されるシステムにのみインストールする必要があります。
PHBの問題点
私たちは皆、先のとがった髪のボス（PHB）を持っていました、そして時々それらは問題点です。一部のPHBが、特定のLinuxコンピューター上のすべてのRPMのリストと、それぞれの簡単な説明を要求するとします。これは、ノースカロライナ州で働いていたときに起こりました。当時、オープンソースは州の機関による使用が「承認」されておらず、デスクトップコンピュータでLinuxのみを使用していました。 PHBは、例外を「承認」できるように、システムにインストールされている各ソフトウェアのリストを必要としていました。
彼らが私に同じ質問をしたのと同じくらい将来何度も実行できる簡単なスクリプトを書くのに約5分かかりました。ホストにインストールされているRPMパッケージが一覧表示され、各パッケージから説明が抽出されました。このスクリプトは、それぞれの簡単な説明を含む1,900を超えるパッケージのリストを作成しました。私はこのリストを要求したPHBに送信しましたが、二度と返事はありませんでした。
場合によっては、問題点は簡単に、そして迅速に解決されます。しかし、PHBは通常すぐに注意を払う必要があります。
[システム自動化についてもっと知りたいですか？ RedHatの無料の本であるTheAutomatedEnterpriseを始めましょう。 ]
最終的な考え
私は、最も苦痛を引き起こしたタスクに対処するための簡単な自動化スクリプトを作成することから始めました。次に、次の問題点に進みました。最終的に、これらの元の問題点が復活し、Ansibleなどのより高度なツールを使用して改善する必要があります。これは決して終わらない反復プロセスです。