【AI時代のLinuxエンジニア IaC編】第3回：AnsibleによるUbuntu 26.04のOS内部構成と冪等性の確保

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
大反響をいただいている新シリーズ「AI時代のLinuxエンジニア IaC（Infrastructure as Code）編」。今回は、インフラの内部を芸術的に整える「第3回：AnsibleによるUbuntu 26.04のOS内部構成と冪等性の確保」をお届けします。

前回の第2回では、Terraformを使ってAWSなどのクラウド上に「Ubuntu 26.04の仮想マシン（EC2インスタンスなど）」という「ハコ」を自動で立ち上げる方法を学びました。
しかし、立ち上がったばかりのUbuntuの中身は、文字通り「空っぽ」です。Webサーバー（Nginx）も動いていなければ、AIを動かすためのDockerやNVIDIAドライバも入っていませんし、ファイアウォール（UFW）のセキュリティ設定もデフォルトのままです。

この「空っぽのハコ」に対して、SSHでログインしてコマンドを1行ずつ手打ちしていく……のは、前時代的なレガシーエンジニアのやり方です。
AI時代のインフラエンジニアは、OSの中身の設定すらもすべて「Ansible（アンシブル）」という構成管理（Configuration Management）ツールを用いて、完全自動化します。

本記事では、対象OSを最新の Ubuntu 26.04 LTS に設定し、Ansibleのアーキテクチャから、Playbookの基礎、セキュリティとDocker環境の完全自動デプロイ、そしてAI（LLM）を活用したコード生成プロンプトまで、現場のプロが実践する構成管理の極意を8000文字超の圧倒的ボリュームで完全解説します。

---

1. なぜシェルスクリプトは死んだのか？「冪等性（Idempotency）」の魔法

モダンなインフラ環境において、OSの初期設定にシェルスクリプト（Bash）を用いることは「アンチパターン（避けるべき悪手）」とされています。その最大の理由は、シェルスクリプトが「命令型（Imperative）」であり、「冪等性（べきとうせい）」を持たないからです。

1-1. 冪等性（Idempotency）とは？

冪等性とは、「ある操作を1回行っても、100回連続で行っても、対象のシステムが全く同じ状態になる性質」のことです。

例えば、「SSHのポートを22番から2222番に変更する」というタスクをシェルスクリプトで書いたとします。

# 冪等性のないシェルスクリプトの例（危険）
echo "Port 2222" >> /etc/ssh/sshd_config
systemctl restart ssh

このスクリプトを1回実行すれば、ファイルの末尾に Port 2222 が追記されます。しかし、後日「別の設定を追加したいから」ともう一度このスクリプトを実行するとどうなるでしょうか？
ファイルの中に Port 2222 が2行、3行と増殖していき、設定ファイルが完全に破壊されます。これが「冪等性がない」状態の恐怖です。

1-2. Ansibleが提供する「宣言型（Declarative）」の安心感

Ansibleは「どうやって変更するか（How）」を指示するのではなく、「最終的にファイルがどういう状態になっていてほしいか（What）」を宣言（定義）します。

# 冪等性のあるAnsibleの例（安全）
- name: SSHのポートを2222に変更する
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^Port '
    line: 'Port 2222'
    state: present

Ansibleはこのコードを実行する際、まず sshd_config の中身を読み取ります。

• もしすでに Port 2222 になっていれば、何もしません（OK状態を返す）。
• もし Port 22 であれば、その行を Port 2222 に書き換えます（Changed状態を返す）。

これにより、「スクリプトが途中でエラーになって止まった場合でも、原因を直してもう一度最初から実行すれば、安全に続きから構成される」という、運用における絶大な心理的安全性が生まれるのです。

---

2. Ansibleのアーキテクチャ：エージェントレスの圧倒的優位性

世の中には Chef や Puppet といった他の構成管理ツールも存在します。しかし、なぜAnsibleがこれほどまでに世界中のインフラエンジニアに愛されているのでしょうか？

2-1. SSHさえ通ればどこでも操作可能

Ansibleの最大の強みは、「エージェントレス（Agentless）」である点です。
他のツールは、管理対象のサーバー（Ubuntuなど）の中に、あらかじめ「受信用の特別な常駐ソフトウェア（エージェント）」をインストールしておかなければ動きません。

一方、Ansibleはあなたの手元のパソコン（コントロールノード）で動きます。対象のサーバー（ターゲットノード）には、「Python」がインストールされており、「SSH接続」さえできれば、他に何もインストールする必要がありません。Ubuntu 26.04には最初からPython3がインストールされているため、文字通り「立ち上げた瞬間のまっさらなサーバー」に対して即座に構成自動化を開始できるのです。

特徴	Ansibleの優位性	プロの視点でのメリット
エージェントレス	対象サーバーに専用ソフトを入れない。	新しいサーバーを立ち上げた際、事前準備なしで即座に設定を流し込める。リソース（メモリ）も無駄に消費しない。
YAML構文	プログラミング言語（Ruby等）ではなく、人間が読めるYAMLで記述。	インフラエンジニアだけでなく、アプリ開発者やSREなど、チーム全体でコードの意図を共有・レビューしやすい。
Push型アーキテクチャ	コントロールノードから対象サーバーへ変更を「押し込む」。	「今、この瞬間に100台のサーバーを一斉に変更したい」という運用（デプロイ）のコントロールが容易。

---

3. 環境準備：Ubuntu 26.04へのAnsible導入とInventory（インベントリ）

それでは、実際にAnsibleを使う準備をしましょう。Ansibleはあなたの手元の管理用PC（または踏み台サーバー）にインストールします。

3-1. コントロールノードへのインストール

管理用PCがUbuntu 26.04の場合、以下のコマンドで最新のAnsibleをインストールします。

sudo apt update
sudo apt install software-properties-common -y
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible -y

# バージョンの確認
ansible --version

3-2. Inventory（インベントリ）ファイルの作成

Ansibleに「どのサーバーを操作してほしいか」を教えるための名簿が「インベントリ（Inventory）」です。hosts.ini というファイルを作成し、対象のIPアドレスを記述します。

nano hosts.ini

# hosts.ini の内容
[webservers]
192.168.1.100
192.168.1.101

[dbservers]
192.168.1.102

[all:vars]
# 接続に使うユーザー名とSSH鍵の指定
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/my_private_key.pem

このようにグループ分け（[webservers] など）をしておくことで、「WebサーバーグループにだけNginxをインストールする」「DBサーバーグループにだけMySQLを入れる」といった柔軟な制御が可能になります。

3-3. 疎通確認（Pingモジュール）

インベントリに書いたサーバーに対して、Ansibleが正しくSSH接続できるかテストします。

ansible all -i hosts.ini -m ping

対象サーバーから緑色の文字で "ping": "pong" と返ってくれば、Ansibleがサーバーを支配下においた証拠です。

---

4. Playbookの解剖学：YAML構文とモジュールの活用

Ansibleに「何をしてほしいか（状態の定義）」を記述した設計図が「Playbook（プレイブック）」です。PlaybookはYAML（ヤムル）形式で記述します。

4-1. Playbookの基本構造

以下は、Ubuntuサーバーのパッケージ（apt）を最新化する、最もシンプルなPlaybookの例です。

---
- name: サーバーの初期セットアップ
  hosts: all
  become: yes  # sudo（root権限）で実行するという宣言

  tasks:
    - name: aptパッケージキャッシュを更新し、全パッケージをアップグレード
      ansible.builtin.apt:
        update_cache: yes
        upgrade: dist

4-2. モジュール（Modules）という強力な武器

Playbookの中で ansible.builtin.apt: と書かれている部分が「モジュール」です。Ansibleには、Linuxのあらゆる操作を抽象化したモジュールが何千種類も用意されています。

モジュール名	何をしてくれるか（機能）	シェルコマンドでの相当操作
ansible.builtin.apt	Debian/Ubuntuのパッケージのインストール・削除・更新を安全に行う。	apt-get install / apt-get update
ansible.builtin.systemd	サービスの起動・停止・自動起動の有効化を管理する。	systemctl start / systemctl enable
ansible.builtin.template	変数（IPアドレス等）を動的に埋め込んだ設定ファイルをサーバーに配置する。	scp + sed（ファイル転送と文字列置換）
community.general.ufw	Ubuntu標準のファイアウォール（UFW）のルールを定義する。	ufw allow / ufw deny

プロのインフラエンジニアは、「シェルコマンドを直接実行するモジュール（shell や command）」の使用を極力避け、これらの専用モジュールを使うことで冪等性を完璧に担保します。

---

5. 【実践1】UFWとSSHのセキュリティ・ハードニング自動化

それでは、実際のプロの現場で使われているPlaybookを書いてみましょう。
Terraformで立ち上げたばかりのUbuntu 26.04サーバーに対し、最も重要な「ファイアウォール（UFW）の有効化」と「SSHのセキュリティ強化（ルートログイン禁止・パスワード認証禁止）」を全自動で行うPlaybook（security.yml）です。

---
- name: Ubuntu 26.04 セキュリティ・ハードニング
  hosts: all
  become: yes

  tasks:
    # --- UFW (Firewall) の設定 ---
    - name: UFWでデフォルトの受信を拒否（deny）に設定
      community.general.ufw:
        state: enabled
        direction: incoming
        policy: deny

    - name: UFWでSSH（22番ポート）を許可し、ブルートフォース対策の制限（limit）をかける
      community.general.ufw:
        rule: limit
        port: '22'
        proto: tcp

    - name: UFWでWeb（80/443番ポート）を許可する
      community.general.ufw:
        rule: allow
        port: '{{ item }}'
        proto: tcp
      loop:
        - '80'
        - '443'

    # --- SSHの堅牢化 ---
    - name: SSHのパスワード認証を無効化する
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present
      notify: Restart SSH

    - name: SSHのrootログインを無効化する
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: Restart SSH

  # ハンドラーの定義（後述）
  handlers:
    - name: Restart SSH
      ansible.builtin.systemd:
        name: ssh
        state: restarted

このPlaybookを ansible-playbook -i hosts.ini security.yml と実行するだけで、10台でも100台でも、一瞬にして完璧なセキュリティ設定が施されたサーバー群が完成します。

---

6. プロのインフラ管理術：Handlers（ハンドラー）による賢い再起動

先ほどのコードの末尾にある notify と handlers という記述に気づいたでしょうか。これはAnsibleをプロレベルで使いこなすための最重要機能です。

6-1. なぜ「毎回再起動」してはいけないのか？

もし、SSHの設定ファイルを書き換えた後に、単なる systemd モジュールを使って再起動（Restart）を書いたとします。すると、Ansibleを実行するたびに、設定が変更されていなくても「毎回SSHサービスが再起動」してしまいます。本番環境のNginxなどでこれをやると、実行するたびに通信が瞬断される大惨事になります。

---

7. 【実践2】AI開発環境（Docker & NVIDIA Toolkit）の全自動デプロイ

セキュリティが整ったら、次は本連載のテーマである「AIインフラ」の土台を作ります。
Ubuntu 26.04上に、最新のDocker Engineと、GPUをコンテナから認識させるための NVIDIA Container Toolkit を全自動でインストールするPlaybook（ai-env.yml）です。

手動でやるとGPGキーの追加やリポジトリの設定でタイポしがちな地獄の作業も、Ansibleなら美しくコード化できます。

---
- name: Ubuntu 26.04 AI・Docker環境の自動構築
  hosts: ai_servers
  become: yes

  tasks:
    - name: 必須パッケージのインストール
      ansible.builtin.apt:
        name:
          - ca-certificates
          - curl
          - gnupg
        state: present
        update_cache: yes

    - name: Dockerの公式GPGキーを追加
      ansible.builtin.apt_key:
        url: https://download.docker.com/linux/ubuntu/gpg
        keyring: /etc/apt/keyrings/docker.gpg
        state: present

    - name: Docker公式リポジトリの追加
      ansible.builtin.apt_repository:
        repo: "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu noble stable"
        state: present
        filename: docker

    - name: Docker EngineとComposeプラグインのインストール
      ansible.builtin.apt:
        name:
          - docker-ce
          - docker-ce-cli
          - containerd.io
          - docker-compose-plugin
        state: present
        update_cache: yes

    - name: NVIDIA Container ToolkitのGPGキー追加とリポジトリ設定（shellモジュールでの実装例）
      # ※NVIDIAの特殊なスクリプトは、shellで冪等性を考慮して実行する
      ansible.builtin.shell: |
        curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
        curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
          sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
          sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
      args:
        creates: /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

    - name: NVIDIA Container Toolkitのインストール
      ansible.builtin.apt:
        name: nvidia-container-toolkit
        state: present
        update_cache: yes

    - name: DockerランタイムにNVIDIAを設定する
      ansible.builtin.command: nvidia-ctk runtime configure --runtime=docker
      args:
        creates: /etc/docker/daemon.json
      notify: Restart Docker

  handlers:
    - name: Restart Docker
      ansible.builtin.systemd:
        name: docker
        state: restarted

注目すべきは、args: creates: [ファイルパス] の記述です。
shell や command といった「冪等性のないモジュール」を使う場合でも、この creates を指定することで、「もしそのファイルが既に存在していれば、このコマンドはスキップする」という条件を付与でき、無理やり冪等性を担保することができるのです。これも現場必須のテクニックです。

---

8. Role（ロール）によるコードの部品化とモジュラー設計

Terraformで「モジュール」化を学んだように、AnsibleのPlaybookも1つのファイルに何百行も書くのはアンチパターンです。「Nginxのインストール」「Dockerのインストール」「ユーザー作成」といった機能ごとにフォルダを分割し、再利用可能な部品（ブロック）を作る機能を「Role（ロール）」と呼びます。

8-1. 最高の可読性を生む Role の構造

プロのAnsibleリポジトリは、以下のような美しいディレクトリ構造を持っています。

ansible-project/
├── hosts.ini
├── site.yml               # 全体を統括するマスターPlaybook
└── roles/
    ├── common/            # 全サーバー共通（ユーザー作成、NTP設定等）
    ├── security/          # セキュリティ（UFW, SSH設定等）
    ├── docker_nvidia/     # DockerとNVIDIA Toolkit（先ほどのコード）
    └── webserver_nginx/   # Nginx設定

マスターとなる site.yml は、以下のように極めてシンプルになります。

---
# すべてのサーバーに適用
- hosts: all
  roles:
    - common
    - security

# AIサーバーグループにのみ適用
- hosts: ai_servers
  roles:
    - docker_nvidia

# Webサーバーグループにのみ適用
- hosts: web_servers
  roles:
    - webserver_nginx

このように役割（Role）を分離することで、新しいプロジェクトが立ち上がった際にも、「今回はAI用のサーバーだから docker_nvidia ロールを使い回そう」と、レゴブロックのようにインフラを組み立てることができるようになります。

---

9. AIを部下にする：Ansible PlaybookをLLMに書かせる神プロンプト

AnsibleのYAML構文や、何千種類もあるモジュールの使い方をすべて暗記する必要はありません。2026年のインフラエンジニアは、設計の意図をAI（Gemini等）に伝え、Playbookのドラフト（骨組み）を一瞬で生成させます。

9-1. Ansibleコード生成の「神プロンプト」

「あなたはシニアSRE（サイト信頼性エンジニア）です。
最新の『Ubuntu 26.04 LTS』を対象に、本番環境向けの『Nginxリバースプロキシ』を自動構築するAnsible Playbook（またはRoleのtasks/main.yml）を生成してください。

【要件定義】
1. aptモジュールを使用し、Nginxをインストールすること。
2. Nginxのメイン設定ファイル（nginx.conf）において、以下のチューニングを行うタスクを含めること（lineinfileまたはtemplateモジュールを使用）。
   - `worker_processes auto;` の確認/設定
   - `client_max_body_size 100M;` の追加（AIの画像アップロード用）
3. サービス（systemd）の設定として、Nginxを起動状態（started）にし、OS再起動時の自動起動（enabled）を有効にすること。
4. 設定ファイルに変更があった場合のみ、Nginxを安全にリロード（reloaded）させるHandlerの仕組み（notify）を必ず実装すること。

【コーディング規約】
・すべてのタスクは「冪等性（Idempotency）」を担保すること。
・shell/commandモジュールの使用は極力避け、Ansibleの標準モジュールを利用すること。
・各タスクの `name` には、何を実行しているか分かりやすい日本語の解説を記載すること。」

このプロンプトを投げることで、AIは「単にインストールするだけの素人のスクリプト」ではなく、「Handlerを使いこなし、冪等性を担保したエンタープライズ品質のPlaybook」を確実に出力してくれます。
人間であるあなたは、AIが出力したYAMLのインデントのズレや、意図しない設定が含まれていないかをレビューし、Gitにコミットするだけで業務が完了するのです。

---

総まとめ：設定の「手順」ではなく「状態」を支配せよ

「AI時代のLinuxエンジニア IaC編」第3回、本当にお疲れ様でした！

今回は、クラウド上に立ち上がったばかりの「空っぽのUbuntu 26.04」を、Ansibleという魔法のツールを使って「完璧にチューニングされたAIインフラ」へと全自動で変貌させる技術を学びました。

1. 冪等性の威力： シェルスクリプトの限界を知り、何度実行してもシステムが壊れない「宣言型」の構成管理を理解した。
2. エージェントレスの強み： 対象サーバーにPythonとSSHさえあれば、すぐに支配下に置けるAnsibleの身軽さを知った。
3. Handlerの最適化： 必要な時だけサービスを再起動し、本番環境のダウンタイムをゼロにするプロの作法を身につけた。
4. Roleによるモジュール化： インフラのコードを部品化し、チームで再利用可能な資産にする設計手法を学んだ。

「Terraform」でインフラのハコを作り、「Ansible」でその中身（OS設定）を完璧に整える。
この2つのIaCツールを組み合わせることで、あなたは「いつでも、どこでも、数分で、全く同じAIインフラを何百台でも生み出せる神の力」を手に入れたことになります。

しかし、現代のインフラ自動化はこれだけでは終わりません。
次回、第4回「CI/CDパイプラインによるGitOps完全自動デプロイ」では、あなたが書いた（あるいはAIに書かせた）TerraformやAnsibleのコードを、GitHubにプッシュ（提出）した瞬間に、裏側でテストが走り、自動的に本番のクラウド環境へ反映させる「究極の全自動パイプライン（GitOps）」の世界を解説します。お楽しみに！