SASUKAME OF THE YEAR 2018

この記事は Advent Calendar 2018 14日目の記事です。

adventar.org

めでたいことがありました。

kamekoopa.hateblo.jp

さすかめ先生の次回作にご期待ください!!!

My favorite SASUKAME in 2018

さすかめ Advent Calendar 2018 1日目の記事です。

adventar.org

今回は、2018年の個人的に良いと思ったさすかめをまとめてみました。

こちらからは以上です。

RHEL 8 あるいは Fedora 28 のモジュールについて

Red Hat Enterprise Linux 8 Beta がリリースされたようです。さっそくリリースノート読んでみると、RHEL 8 は Fedora 28 がベースになっているようです。さらにリリースノートを読んでいくと、気になる項目が記載されていました。モジュールです。

モジュールとは

Fedora の資料ですが、モジュールについては以下のドキュメントがありました。

https://docs.fedoraproject.org/en-US/modularity/

ざっくり言うと、システム管理者が望むような、最新バージョンよりは長年安定している少し古いバージョンを使いたい、という要望に応えるもののようです。例えば、Fedora 28 で PostgreSQL を入れようとしたら 10 が降ってきますが、これを互換性等の理由で 9.6 を入れられるようにするという代物だそうです。

使い方

以降、Fedora 28 での操作例です。RHEL 8 でも多分大きく変わらないと思います。

使えるモジュールのリストは dnf module list で確認できます。

# dnf module list
Fedora Modular 28 - x86_64
Name                     Stream              Version                Profiles                            
reviewboard              2.5 [d]             20180206144254         default, server                     

Fedora Modular 28 - x86_64 - Updates
Name                     Stream              Version                Profiles                            
ant                      1.10                20180629154141         default                             
avocado                  latest              20181004173516         default, minimal                    
byteman                  byteman             20180711142551         default                             
container-tools          2017.0              20180313063358         default                             
cri-o                    2017.0              20180313134242         default                             
django                   1.6                 20180409143454         default, python2_development        
docker                   2017.0              20180314032736         default                             
dwm                      6.0                 20180813144159         default, user                       
dwm                      6.1                 20180813122714         default, user                       
dwm                      latest              20180814184656         default, user                       
flatpak-runtime          f28                 20180307202408         buildroot, runtime, ...             
gcsf                     master [d]          20180730063540         default                             
ghc                      8.4                 20180930092756         default, minimal, ...               
gimp                     2.10                20180824144949         default, devel                      
golang                   1.10                20180327174614         default                             
golang-ecosystem         2017.0              20180312141905         default                             
hub                      pre-release         20180613180542         default                             
libgit2                  0.26 [d]            20181103165214                                             
libgit2                  0.27                20181028172505                                             
lizardfs                 devel               20180810084334                                             
mariadb                  10.1                20180419160707         client, default, ...                
maven                    3.5                 20180629153919         default                             
mongodb                  3.6                 20180601084133         client, default, ...                
mysql                    5.6                 20180507203856         client, default, ...                
mysql                    8.0                 20180507133324         client, default, ...                
nodejs                   10                  20181011185441         default, development, ...           
nodejs                   6                   20180816121924         default, development, ...           
nodejs                   8                   20180816123422         default, development, ...           
nodejs                   9                   20180614205456         default, development, ...           
postgresql               9.6                 20180429200004         client, default, ...                
reviewboard              3.0                 20180607124319         default, server                     
ripgrep                  latest              20181104174352         default                             
ripgrep                  master [d]          20180726145207         default                             
scala                    2.10                20180702155503         default                             
squid                    4.0                 20180604145326         default                             
stratis                  1 [d]               20181103101935         default                             
stratis                  master              20180726133047         default                             

Hint: [d]efault, [e]nabled, [i]nstalled, [l]ocked

ここで、先の例のように PostgreSQL を入れようとしたら、10 が降ってきます。

# dnf install postgresql
 :
========================================================================================================
 Package                      Arch                Version                    Repository            Size
========================================================================================================
Installing:
 postgresql                   x86_64              10.6-1.fc28                updates              1.5 M
Installing dependencies:
 postgresql-libs              x86_64              10.6-1.fc28                updates              301 k
 :

このとき、PostgreSQL 9.6 を入れたい場合、以下のようにすると 9.6 が降ってきます。

# dnf install @postgresql:9.6
========================================================================================================
 Package                 Arch         Version                               Repository             Size
========================================================================================================
Installing module packages:
 postgresql-server       x86_64       9.6.8-1.module_1710+abca667b          updates-modular       4.6 M
Installing dependencies:
 postgresql              x86_64       9.6.8-1.module_1710+abca667b          updates-modular       1.3 M
 postgresql-libs         x86_64       9.6.8-1.module_1710+abca667b          updates-modular       249 k

プロファイル

各モジュールには、用途に応じたプロファイルも用意されているようです。dnf module list で出てくる Profiles の欄ですね。先の PostgreSQL だと、client プロファイルというのがいるようです。client プロファイルだと、postgresql-server パッケージはインストールされないというように、用途がきっちり分かれていますね。

# dnf install @postgresql:9.6/client
========================================================================================================
 Package                Arch          Version                              Repository              Size
========================================================================================================
Installing module packages:
 postgresql             x86_64        9.6.8-1.module_1710+abca667b         updates-modular        1.3 M
Installing dependencies:
 postgresql-libs        x86_64        9.6.8-1.module_1710+abca667b         updates-modular        249 k

Fedora 29 は Python3 で Ansible が動く

タイトルのとおりです。

Fedora 28 くらいまでは、ansible-python3 というパッケージで Python3 で動く Ansible が配布されていましたが、Fedora 29 から ansible パッケージ自体が Python3 で動くことを前提にしている模様。

$ rpm -qR ansible
/usr/bin/python3
config(ansible) = 2.7.1-1.fc29
python(abi) = 3.7
python3-PyYAML
python3-crypto
python3-jinja2
python3-jmespath
python3-paramiko
python3-setuptools
python3-six
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
sshpass

なので、Fedora 29 にアップグレード後、いつもどおり ansible-playbook-3 コマンドを叩いたら command not found... とか言われてちょっとびっくりしたというお話です。

Ansible で各言語を完全にマスターするロール作った

これはさすかめ Advent Calendar 2016 の 9 日目の記事です。

www.adventar.org

かなり簡単にですが、各言語を Ansible で完全にマスターする sasukame ロールを作りました。

github.com

まだ Java しか対応してませんが、git clone して ansible-playbook -i hosts site.yml すれば以下の出力が得られます。

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [sasukame : include] ******************************************************
included: /home/ewigkeit/sasukame/roles/sasukame/tasks/java.yml for localhost

TASK [sasukame : Create Hello class] *******************************************
changed: [localhost]

TASK [sasukame : Compile Hello class] ******************************************
changed: [localhost]

TASK [sasukame : Run Hello class] **********************************************
changed: [localhost]

TASK [sasukame : Output run result] ********************************************
ok: [localhost] => {
    "msg": [
        "Hello, world."
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=6    changed=3    unreachable=0    failed=0   

Ansible のバグを見つけて Pull Request を投げた話

この記事は Ansible Advent Calendar 2016 の 8 日目の記事です。

qiita.com

Ansible を触り始めてから、かれこれ 1 年以上が経過しましたが、現在業務の片手間でやっていたサーバ移行がやっと終わりそうです。もちろん、移行に関する処理を全て Ansible で書いているので、移行作業自体は物理的な手作業を除いてほぼ一瞬で終わる予定です。

さて、本題です。皆さん、copy モジュール使ってますか?使ってますよね。かなり多用しますよね。私も大変お世話になっています。サーバ移行用に書いた処理でも使っていて、例えば RPM ファイルに入っているデフォルト設定をもとに lineinfile とかで設定を書き換えたいというときに、まずは /usr/share/hogehoge 配下に入ってる settings.conf.example とかを所定の /etc 配下にコピーすることを想定していました。当時はこんな感じのタスクを書いていました。

- name: デフォルト設定をコピー
  copy: src=/usr/share/hogehoge/settings.conf.example dest=/etc/hogehoge/settings.conf remote_src=True

さて、タスクが書けたら、まずは check モードで動作確認ですね。ansible-playbook コマンドに --check オプションを付ければいいだけです。簡単ですね。ところがどっこい、check モードで確認したはずなのに、実際にファイルが書き換えられてしまいました。

いやまぁ、草とか言ってる場合ではないんですが、どうやら調べてみたら、remote_src を付けてなければファイルが書き換えられることもなく、正しく check モードで動作していることは確認できました。

せっかくバグも見つけたんだし、と思って、さっそく Pull Request を投げてみました。

github.com

説明足らずでコミッタから再現手順くれよとか言われちゃいましたが、無事マージされて現在は上のようなバグはありません。自分が好きな Ansible に貢献できてよかったな~と思っています。

実は、現在も nmcli モジュールで少し困っていて、設定は変わっていないのに changed 扱いになってしまう問題があります。Ansible のバグ報告見てても、同様の報告が数件あるにも関わらず、現在も解消されていないようです。せっかくなので、自分が直してまた Pull Request を投げようかなと思っているところです。

Ansible でターゲットホストのファイルをターゲットホスト内でコピーする

最近 Ansible ばっかり触ってます。こんにちは。Ansible のちょっとしたテクニックなど、ググったらまぁ大抵出てくることには出てくるんですけど、だいたい英語の記事しか出てこないので、日本語でナレッジを残していくという意味でアウトプットしていきたいと思います。Ansible 好きだし、広く使ってもらいたいので。

で、掲題の件ですよ。Ansible でファイルをコピーと言えば、コントロールホスト上にあるファイルをターゲットホストにコピーする copy モジュール を使いますよね。でも、そうじゃなくて、ターゲットホスト内にあるファイルを、ターゲットホスト内でコピーしたいときどうするのかっていう話です。

これだけじゃあまり伝わらないと思うのですが、例えば RPM ファイルに含まれる /usr/share/hogehoge/sample.conf みたいなサンプルの設定を、そのまま設定ファイルとして /etc/hogehoge/main.conf にコピーしたい、みたいなことってたまにあると思うんです。そういうことです。で、こういうことは copy モジュールだと実現できません。

さて、じゃあ何を使えばいいのかって言うと、synchronize モジュール を使います。synchronize モジュールは rsync の動きをするんですが、他のモジュールと違って、rsync をターゲットホスト上ではなく、コントロールホスト上で動かします。で、この synchronize モジュールをそのまま使うだけだと意図した動作を得られないのですが、ここで delegate_to というオプションを使います。具体的なコードは以下の通り。

- synchronize:
    src: /usr/share/hogehoge/sample.conf
    dest: /etc/hogehoge/main.conf
  delegate_to: "{{ inventory_hostname }}"

delegate_to オプションは このドキュメント に記載されてるんですが、任意のタスクを実行するホストを指定する、つまり処理の移譲先を指定するオプションなんですね。上の例だと、{{ inventory_hostname }} に対して処理を委譲しているので、ターゲットホストで synchronize モジュールを動かすことになります。

これによって、ターゲットホスト上で rsync を動かして、ターゲットホスト内のファイルをコピーするという動きが実現できるようになります。