試験が実際に問うていること
一言でいうと
RHCEが実際に問うのはAnsibleの文法ではなく、RHELを望む状態にできるかどうかです。そのため、減点はシステム側に集中します。
なぜ文法ではなくシステムなのか
RHCE(EX294)はAnsibleの試験のように見えますが、実際に問うのはRHELシステムを望む状態にできるかです。そのため、減点が出る箇所が、文法ではなくシステム側に集中しています。
startedとenabled
state: started # 지금 돌고 있는가
enabled: true # 재부팅 후에도 뜨는가
2つは別の話です。startedだけを書くと、採点の瞬間には合格します。再起動すると消え、再起動はたいてい明け方に起きます。
firewalldの2つの世界
firewalldは、今動いているルール(runtime)と、ファイルに書かれたルール(permanent)を別々に管理します。
| 指定したもの | 結果 | 症状 |
|---|---|---|
permanentだけ |
ファイルには書かれるが、今は開かない | 「設定したのに、なぜつながらないのか」 |
immediateだけ |
今は開くが、再起動すると消える | 「昨日は動いたのに」 |
| 両方 | 完成 |
SELinuxは静かに遮断する
SELinuxが遮断すると、アプリケーションには普通のエラーに見えます。connection refusedか403です。ファイルの権限は問題ないので、さらに混乱します。
そして、ブーリアンにpersistent: trueを書き漏らすと、今だけ有効になり、再起動のときに元に戻ります。元に戻ったあとの症状が最初とまったく同じなので、直したと信じたまま、同じ障害を再び経験します。
ファイルコンテキストは2段階です。sefcontextはルールを登録するだけで、すでにあるファイルに適用するには、restoreconを別に実行する必要があります。
冪等は信念ではなく数字で確かめる
「冪等に書いた」は信念であり、「2回目の実行のchangedが0である」は事実です。後者にだけ意味があります。
壊す原因は、ほとんどいつも2つです。
- 条件なしの
command/shell: いつもchangedになります。creates:やchanged_when:で条件を付けてください。 - 毎回変わるテンプレート: 時刻や乱数を入れると、内容が変わり続けます。そうすると、ハンドラーが毎回サービスを再起動して、何も変わっていないのにデプロイのたびに中断が発生します。
試験会場で時間を失う箇所
RHCEは、知っていることを使えなくて落ちるよりも、時間が足りなくて落ちます。そのため、手順をあらかじめ決めておくことが、知識と同じくらい重要です。
インベントリと接続を最初に確認します。プレイブックをどれだけうまく書いても、対象につながらなければ0点です。ansible all -m pingを1回実行して、全台が応答するかを見て、権限昇格ができるかも一緒に確認します。この確認にかける1分が、あとで「なぜ動かないのか」で失う20分を防ぎます。
ドキュメントをどこで見るかを決めておきます。モジュールのオプション名は、暗記するものではなく、ansible-docで探すものです。ただし、探すのに時間がかかるので、よく使うもの(package、service、copy、template、lineinfile、user、firewalld、seboolean)は手に馴染ませておき、残りだけを探します。
1つの問題を終えたら、その場で検証します。あとでまとめて確認すると、どの問題で何が間違っていたかを、もう一度探さなければなりません。サービスを扱ったならsystemctl is-enabledまで、ファイアウォールを扱ったならfirewall-cmd --list-allまで、その場で確認します。
詰まったら飛ばします。1つの問題にこだわっている間に、解けたはずの2つの問題が過ぎ去ります。飛ばすときは、何を残してきたかを書き留めておき、余った時間に戻ってきます。
そして最後に、必ず時間を残して、再起動後の状態を確認します。これが、このモジュールで繰り返し述べてきた永続性の問題を捉える、唯一の方法です。再起動する時間がないなら、最低でもsystemctl is-enabledとfirewalldのpermanent一覧だけでも、ざっと見ます。実務でも同じです。「今動くこと」と「再起動後も動くこと」は別の状態で、その差は、いつも最悪のタイミングで表面化します。
実務で本当に大切なこと
状態を変えるモジュールには、常に永続の可否も一緒に書きます。state: startedにはenabled: trueを、firewalldにはpermanentとimmediateを、SELinuxブーリアンにはpersistent: trueを、対にしておきます。書き漏らすと、今は合格して再起動後に消えますが、再起動はたいてい明け方に起きます。
冪等は、2回目の実行のchangedが0であることでだけ証明します。壊す原因は、ほとんどいつも、条件なしのcommand/shellと、毎回変わるテンプレートの2つです。後者が特に悪質です。ハンドラーが毎回サービスを再起動するので、何も変わっていないのに、デプロイのたびに中断が発生します。
SELinuxが遮断すると、アプリケーションのエラーのように見えます。connection refusedや403として現れ、ファイルの権限は問題ないので、原因を見つけるまでに最も長くかかります。sefcontextはルールを登録するだけだということも、一緒に覚えておく必要があります。すでにあるファイルに適用するには、restoreconを別に実行する必要があります。
次のラボはAlmaLinux 9のVMで動きます。SELinuxがEnforcingで、firewalldが動いているので、上のことを書き漏らすと、実際に遮断されます。