気分を変えるために StumpWM を久々に動かしてみた。
StumpWM は Common Lisp で記述されたシンプルなウインドマネージャーで、タイル型と呼ばれるウインドマネージャーです。キーボードを中心に操作を行い、Emacs と相性が良いです。
xrdp で動かす場合の導入のメモを残しておきます。roswellのおかげですごく簡単になっています。
ものぐさ playbook
Tweet
ちょっとした一発処理を Ansible で流そうとした時に、YAMLの Block Scalars(| とか > とか) と Jinja2 を組み合わせると1ファイルでいろんな処理が流せるようになるので便利です。
実行するとこんな感じ
- hosts: localhost connection: local gather_facts: no vars: flag: false nodes: - 192.168.1.11 - 192.168.1.12 - 192.168.1.13 private_key_path: /root/keypair.pem tasks: - shell: >- {% if flag %} echo "flag=true" {% else %} echo "flag=false" {% endif %} register: ret - debug: var=ret.stdout - copy: content: | [web] {% for i in nodes %} node-{{ loop.index }} ansible_host={{ i }} {% endfor %} [all:vars] ansible_user=centos ansible_ssh_private_key_file={{ private_key_path }} dest: result.txt
実行するとこんな感じ
$ ansible-playbook block_scalar.yml PLAY [localhost] ********************************************************* TASK [shell] ************************************************************* changed: [localhost] TASK [debug] ************************************************************* ok: [localhost] => { "ret.stdout": "flag=false" } TASK [copy] ************************************************************** changed: [localhost] PLAY RECAP *************************************************************** localhost : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 $ cat result.txt [web] node-1 ansible_host=192.168.1.11 node-2 ansible_host=192.168.1.12 node-3 ansible_host=192.168.1.13 [all:vars] ansible_user=centos ansible_ssh_private_key_file=/root/keypair.pem
"WARNING: Setting locale failed" with CentOS8 on Docker
Tweet
To fix:
こんだけ。
dnf install -y glibc-all-langpacks
こんだけ。
uri モジュール
Tweet
Ansible には get_url というモジュールがあります。これは指定したURLを取得してターゲットホスト上に保存する機能をもち、ファイルのダウンロードなどに使われます。
似たようなモジュールでより汎用的なものとして uri があります。これはREST APIを叩いたり、WEBの動作確認など様々な使い方ができます。いわゆる curl コマンドのAnsibleモジュール版といっても良いでしょう。汎用HTTPリクエスト機能とも言いかえられるかもしれません。
このモジュールは shell などと同じく、冪等性を考慮していない汎用コマンド系なのでその点は注意が必要です。
公式のサンプルを少し見てみましょう。
似たようなモジュールでより汎用的なものとして uri があります。これはREST APIを叩いたり、WEBの動作確認など様々な使い方ができます。いわゆる curl コマンドのAnsibleモジュール版といっても良いでしょう。汎用HTTPリクエスト機能とも言いかえられるかもしれません。
このモジュールは shell などと同じく、冪等性を考慮していない汎用コマンド系なのでその点は注意が必要です。
公式のサンプルを少し見てみましょう。
時刻:
12:44
Assertモジュールによる「テスト、確認の自動化」とTAP(Test Anything Protocol)
Tweet
本記事は以下の12日目の記事です。ノウハウの塊です。
https://qiita.com/advent-calendar/2018/ansibleblogger
こっちもおすすめです。
https://qiita.com/advent-calendar/2018/ansible
Ansibleの「自動化の確かさ」ををテストするノウハウも最近ちらほらと出始めました。
このあたりの記事はとても参考になります。
- コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは
- Molecule入門
- Ansible Playbook の CI をまわす
- GitLab CIでAnsibleの自作モジュールのCIをやってみる
Moleculeはとても良いです。Roleのテストの方向性が固まって来た感があります。インフラCI実践ガイドで取り上げたかったですが、執筆の構想をしたときにはそれほどメジャーではなかったので見送りました(入れておけばよかった・・・
インフラにおけるAnsibleのテストはこんな感じで整理できます。
(1)Role単品のテスト
(2)Roleを組み合わせときのテスト
(3)出来上がった結果を確認するテスト
(4)上記が時間経過や周辺環境の変更があっても動くのかを確認するテスト
(1)はMoleculeでほぼ十分です。(4)に関しては(1, 2, 3)に対してマトリックスを組んでのテストになります。
(2)は現状では少々悩ましいです。問題が出やすいところでもあります。特にチームで開発した場合には、単品のロールとしては完璧でも、組み合わせると矛盾がでるケースがあるからです。Moleculeだけでできるのかもうちょっと研究が必要。
(3)はインテグレーションテストやシステムテストに相当するテストです。ここはテストのシナリオを書いて、独自で実装する必要があります。いわゆるブラックボックステストとして非機能要件やシステムの振る舞いを確認する必要があります。
前置きは長くなりましたが、Ansibleでなにかを確認したいとき、そこで活躍するのが assert モジュールです。
https://docs.ansible.com/ansible/latest/modules/assert_module.html
https://qiita.com/advent-calendar/2018/ansibleblogger
こっちもおすすめです。
https://qiita.com/advent-calendar/2018/ansible
Ansibleの「自動化の確かさ」ををテストするノウハウも最近ちらほらと出始めました。
このあたりの記事はとても参考になります。
- コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは
- Molecule入門
- Ansible Playbook の CI をまわす
- GitLab CIでAnsibleの自作モジュールのCIをやってみる
Moleculeはとても良いです。Roleのテストの方向性が固まって来た感があります。インフラCI実践ガイドで取り上げたかったですが、執筆の構想をしたときにはそれほどメジャーではなかったので見送りました(入れておけばよかった・・・
インフラにおけるAnsibleのテストはこんな感じで整理できます。
(1)Role単品のテスト
(2)Roleを組み合わせときのテスト
(3)出来上がった結果を確認するテスト
(4)上記が時間経過や周辺環境の変更があっても動くのかを確認するテスト
(1)はMoleculeでほぼ十分です。(4)に関しては(1, 2, 3)に対してマトリックスを組んでのテストになります。
(2)は現状では少々悩ましいです。問題が出やすいところでもあります。特にチームで開発した場合には、単品のロールとしては完璧でも、組み合わせると矛盾がでるケースがあるからです。Moleculeだけでできるのかもうちょっと研究が必要。
(3)はインテグレーションテストやシステムテストに相当するテストです。ここはテストのシナリオを書いて、独自で実装する必要があります。いわゆるブラックボックステストとして非機能要件やシステムの振る舞いを確認する必要があります。
前置きは長くなりましたが、Ansibleでなにかを確認したいとき、そこで活躍するのが assert モジュールです。
https://docs.ansible.com/ansible/latest/modules/assert_module.html
手軽にAnsibleを試しながら勉強する方法
Tweet
Ansible Advent Calendar 2018 の1日目です。
最初に宣伝させてください。
Software Design 2018年12月号のAnsible特集に寄稿しました。Ansibleの入門からネットワーク機器管理、Tower/AWX、CIの触りまで幅広いテーマを扱っています。Ansible漫画も付属しているので、頑固な上司の机に忍ばせてAnsibleを理解させるたりと活用できると思います。
さて、Ansibleの勉強方法ですが、一番いいのは実際に手を動かすことです。書籍や記事もたくさんありますが、やはり手を動かして実際にAnsibleを動かしてみると、何ができて何ができないのか、Ansibleで自動化するために何をする必要があるのかを実感することができます。その後で様々な書籍や記事で基礎固めや実践的な知識を入手するのが良い方法です。
しかし、Ansible自身のインストールは簡単なのですが、実際に動かすためには自動化の対象となるノードを準備したりとやや手間がかかるのも事実です。
ということで、もっと簡単にAnsibleを体験してもらうために、ブラウザだけあればAnsibleがいろいろ試せる環境をKatacoda上に作成しました。Katacodaは受講者がブラウザだけで完結するハンズオンコースを実装できるSaaSサービスです。特にコンテナ関連のコースが充実しており、ここ最近注目を集めております。自分でコースを実装することも可能ですので、そちらを利用してAnsibleの入門コースを作成してみましたので使ってみてください。
最初に宣伝させてください。
Software Design 2018年12月号のAnsible特集に寄稿しました。Ansibleの入門からネットワーク機器管理、Tower/AWX、CIの触りまで幅広いテーマを扱っています。Ansible漫画も付属しているので、頑固な上司の机に忍ばせてAnsibleを理解させるたりと活用できると思います。
さて、Ansibleの勉強方法ですが、一番いいのは実際に手を動かすことです。書籍や記事もたくさんありますが、やはり手を動かして実際にAnsibleを動かしてみると、何ができて何ができないのか、Ansibleで自動化するために何をする必要があるのかを実感することができます。その後で様々な書籍や記事で基礎固めや実践的な知識を入手するのが良い方法です。
しかし、Ansible自身のインストールは簡単なのですが、実際に動かすためには自動化の対象となるノードを準備したりとやや手間がかかるのも事実です。
ということで、もっと簡単にAnsibleを体験してもらうために、ブラウザだけあればAnsibleがいろいろ試せる環境をKatacoda上に作成しました。Katacodaは受講者がブラウザだけで完結するハンズオンコースを実装できるSaaSサービスです。特にコンテナ関連のコースが充実しており、ここ最近注目を集めております。自分でコースを実装することも可能ですので、そちらを利用してAnsibleの入門コースを作成してみましたので使ってみてください。
Hyper-V (Win10) で Nested する
Tweet
意味のわからないタイトルですが、ようは kvm on CentOS on hyper-v とか、virtualbox on windows on hyper-v とかをします。
ここを参考。
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization
1. Hypter-V を有効にして仮想マシンを作成する
2. 起動する前に、PowerShellを管理者モードで起動して以下を実行
<vmname> のところには自分がつけた仮想マシンの名前を入れます。
以上。簡単ですね。
以下の画像は 母艦のWin10上の Hyper-V で CentOS7 を起動して、その CentOS の中で VirtualBox(vagrant) を起動しています。
ここを参考。
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization
1. Hypter-V を有効にして仮想マシンを作成する
2. 起動する前に、PowerShellを管理者モードで起動して以下を実行
Set-VMProcessor -VMName <vmname> -ExposeVirtualizationExtensions $true
<vmname> のところには自分がつけた仮想マシンの名前を入れます。
以上。簡単ですね。
以下の画像は 母艦のWin10上の Hyper-V で CentOS7 を起動して、その CentOS の中で VirtualBox(vagrant) を起動しています。
Ansible: include の代わりに使う import_xxx, include_yyy とは
Tweet
この記事は Ansible Advent Calendar 2017 の一部です。
ここ数年、Advent Calendar の季節くらいしか記事を書かなくなってしまいました。もうちょっとアウトプットしたいのですが、色々手を出しすぎてなかなか時間が取れないのが悩みです。
さて、Ansible 2.4 をお使いの方は、以下のような警告をみたことがある方もいると思います。
この警告は「include が廃止されるので別の方法に切り替えてね」というメッセージです。
include は Playbook や Task の再利用において重要な機能であるため、多くの方が include は当たり前の様に使っていると思います。
今回はこの変更点に触れていきたいと思います。
これはモジュールの解説ページにも記載されていますが、include は2.8をめどに完全に削除される予定になっています。
http://docs.ansible.com/ansible/latest/include_module.html
* include は実際にはモジュールではなく Ansible 本体の機能です。モジュールっぽく取り扱った方が説明が平易なため、ここでは include モジュールと表現していきます。
では代わりに何を使うかというと、
になります。これらの違いは後に説明します。
include モジュールは他のPlaybookやTaskを呼び出すことができますが、呼び出されるコンテキストによって挙動が変わるように実装されていました。特に2.0以降で include には Dynamic と Static という考え方も追加され、更にそれを特定条件で抑制したり有効にしたりと include の挙動が複雑化していました。
Dynamic と Static については去年のAnsible Advent Calendar 2016 「AnsibleのDynamic IncludeとStatic Include」で解説されています。
その結果、特に include のネストが深くなった際に予期せぬ動作が発生してしまうケースが報告されるようになりました(2.3で顕在化)。そのため、複雑化した include の動作を分解して、利用者が状況に応じて Dynamic と Static を使い分けるようにしよう、と今回の変更が行われたというのが経緯になります。
こちらに詳しい説明があります。
https://docs.ansible.com/ansible/2.4/playbooks_reuse.html
https://docs.ansible.com/ansible/2.4/playbooks_reuse_includes.html
また、挙動の詳細に関しては先のブログでも例題付きで解説されていますので、ここではポイントのみを解説します。
role に関しては2.3より前では常に Static でしたが、2.3で追加された include_role でタスク内から Dynamic に呼び出す事が可能になっています。
今までは include がいい感じに判断してくれていたので、あまり意識する必要はありませんでしたが、今後は幾つかのケースにおいては利用者がきっちりと使い分ける必要がでてきます。ここではその使い分けを意識するケースを紹介していきます。
■ループ系の処理と組み合わせる場合は include_yyy (Dynamic) しか使えない
おそらくこれが一番大きな点になります。
これらのループ処理と一緒に使う場合は、include_yyy しか使えません。
http://docs.ansible.com/ansible/latest/playbooks_loops.html
■変数化したファイル名を指定する場合には include_yyy (Dynamic) しか使えない
import_xxx はPlaybookの実行前に読み込みが行われるので変数の値は使えません。
これは先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。
■include_yyy した先のタグやタスクを取得することができない
例えば、import_xxx した場合は --list-tag で import_xxx の先のタグを表示し、指定することができますが、include_yyy ではできません。
これも先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。
■nofify で include_yyy (Dynamic) の handler を認識できない。
Dynamicに指定されたファイルは実行時まで読み込まれないので「ハンドラーがない」とエラーになります。
これから新しいPlaybookを書く場合には「includeは使わない」という事を覚えておけばあまり問題にならないと思います。import_xxx/include_yyy の使い方を間違えるとだいたいはエラーになるからです。
厄介なのは新旧のPlaybookが混在し include/import_xxx/include_yyy が入り乱れている場合です。
改修が難しい場合には、Ansibleのバージョンを固定して切り離した環境として使い捨てにしてしまうの1つの手です。
Ansible は利用者の増加に伴い、急速に機能・モジュールの拡充が進んでいます。バージョン固定すると新しいモジュールも使えなくなってしまうので、このあたりはバランスをどう取るかが課題です。
もし、今後のバージョンアップを含めてAnsibleを末永く使っていこうと計画している場合は、これを機にCI環境を整備して、Playbookの鮮度を保っていくという取り組みも有効です。
Ansible は目の前の作業を自動化するにはおそらく最も簡単な方法の一つです。ぜひ作業を自動化して得られた時間で、より自動化を活用するための「仕組み」も一緒に考えてみてください。
それでは皆様、来年もよい自動化を。
ここ数年、Advent Calendar の季節くらいしか記事を書かなくなってしまいました。もうちょっとアウトプットしたいのですが、色々手を出しすぎてなかなか時間が取れないのが悩みです。
さて、Ansible 2.4 をお使いの方は、以下のような警告をみたことがある方もいると思います。
[DEPRECATION WARNING]: The use of 'include' for tasks has been deprecated. Use 'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. [DEPRECATION WARNING]: include is kept for backwards compatibility but usage is discouraged. The module documentation details page may explain more about this rationale.. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
この警告は「include が廃止されるので別の方法に切り替えてね」というメッセージです。
include は Playbook や Task の再利用において重要な機能であるため、多くの方が include は当たり前の様に使っていると思います。
今回はこの変更点に触れていきたいと思います。
include モジュールは 2.8 で廃止予定
これはモジュールの解説ページにも記載されていますが、include は2.8をめどに完全に削除される予定になっています。
http://docs.ansible.com/ansible/latest/include_module.html
* include は実際にはモジュールではなく Ansible 本体の機能です。モジュールっぽく取り扱った方が説明が平易なため、ここでは include モジュールと表現していきます。
では代わりに何を使うかというと、
|-----------------+-----------------------------------+---------| | module | description | version | |-----------------+-----------------------------------+---------| | import_playbook | import a playbook. | 2.4 | | import_role | Import a role into a play | 2.4 | | include_role | Load and execute a role | 2.2 | | import_tasks | import a task list. | 2.4 | | include_tasks | dynamically include a task list. | 2.4 | |-----------------+-----------------------------------+---------|
になります。これらの違いは後に説明します。
どのような問題が include モジュールにはあったのか?
include モジュールは他のPlaybookやTaskを呼び出すことができますが、呼び出されるコンテキストによって挙動が変わるように実装されていました。特に2.0以降で include には Dynamic と Static という考え方も追加され、更にそれを特定条件で抑制したり有効にしたりと include の挙動が複雑化していました。
Dynamic と Static については去年のAnsible Advent Calendar 2016 「AnsibleのDynamic IncludeとStatic Include」で解説されています。
その結果、特に include のネストが深くなった際に予期せぬ動作が発生してしまうケースが報告されるようになりました(2.3で顕在化)。そのため、複雑化した include の動作を分解して、利用者が状況に応じて Dynamic と Static を使い分けるようにしよう、と今回の変更が行われたというのが経緯になります。
include_xxx, import_yyy の違い
こちらに詳しい説明があります。
https://docs.ansible.com/ansible/2.4/playbooks_reuse.html
https://docs.ansible.com/ansible/2.4/playbooks_reuse_includes.html
また、挙動の詳細に関しては先のブログでも例題付きで解説されていますので、ここではポイントのみを解説します。
import_yyy モジュール
Static
Playbookの読み込み時に一緒にimport先が読み込まれます(先読み)
include_xxx モジュール
Dynamic
Playbookの実行時に include 箇所まで処理が来た時にinclude先が読み込まれます(後読み)
role に関しては2.3より前では常に Static でしたが、2.3で追加された include_role でタスク内から Dynamic に呼び出す事が可能になっています。
具体的にどう使い分けるのか?
今までは include がいい感じに判断してくれていたので、あまり意識する必要はありませんでしたが、今後は幾つかのケースにおいては利用者がきっちりと使い分ける必要がでてきます。ここではその使い分けを意識するケースを紹介していきます。
■ループ系の処理と組み合わせる場合は include_yyy (Dynamic) しか使えない
おそらくこれが一番大きな点になります。
これらのループ処理と一緒に使う場合は、include_yyy しか使えません。
http://docs.ansible.com/ansible/latest/playbooks_loops.html
■変数化したファイル名を指定する場合には include_yyy (Dynamic) しか使えない
import_xxx はPlaybookの実行前に読み込みが行われるので変数の値は使えません。
これは先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。
■include_yyy した先のタグやタスクを取得することができない
例えば、import_xxx した場合は --list-tag で import_xxx の先のタグを表示し、指定することができますが、include_yyy ではできません。
これも先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。
■nofify で include_yyy (Dynamic) の handler を認識できない。
Dynamicに指定されたファイルは実行時まで読み込まれないので「ハンドラーがない」とエラーになります。
まとめ
これから新しいPlaybookを書く場合には「includeは使わない」という事を覚えておけばあまり問題にならないと思います。import_xxx/include_yyy の使い方を間違えるとだいたいはエラーになるからです。
厄介なのは新旧のPlaybookが混在し include/import_xxx/include_yyy が入り乱れている場合です。
改修が難しい場合には、Ansibleのバージョンを固定して切り離した環境として使い捨てにしてしまうの1つの手です。
Ansible は利用者の増加に伴い、急速に機能・モジュールの拡充が進んでいます。バージョン固定すると新しいモジュールも使えなくなってしまうので、このあたりはバランスをどう取るかが課題です。
もし、今後のバージョンアップを含めてAnsibleを末永く使っていこうと計画している場合は、これを機にCI環境を整備して、Playbookの鮮度を保っていくという取り組みも有効です。
Ansible は目の前の作業を自動化するにはおそらく最も簡単な方法の一つです。ぜひ作業を自動化して得られた時間で、より自動化を活用するための「仕組み」も一緒に考えてみてください。
それでは皆様、来年もよい自動化を。
Make an IT infrastructure engineer great again
Tweet
こちらの24日目の記事なります。
今冬人気のドラマでこんなセリフがありました。
この前か後か忘れましたが「インフラエンジニアはいないと困るでしょう」というセリフもあったような気がします。たしかリストラの話の流れだったと思います。
この部分について、自分の思うところを書いてみようと思います。
確かにインフラエンジニアはいないと困るのですが、しかし「今までみたいなインフラエンジニア」はそのうちいなくても誰も困らなくなる、ってのが実際のところだと思います。
インフラエンジニアの置かれた状況は業種業態によって異なりますが、多くの環境ではインフラエンジニアの価値は下がり続けていると私は考えているからです。
ITインフラの優劣がビジネスに直結・大きな影響を与える通信キャリアや大規模なWEBやコンテンツサービスプロバイダーなどの例外も存在していますが、大多数を占める旧態然としたいわゆる企業の情シスに所属するインフラエンジニアやSIerのインフラエンジニアの価値は間違いなく低下の傾向であり、このままではいずれその価値は限りなくゼロ、むしろ企業にとっては経済的にマイナスの存在(お荷物)になるのでは、と器具しています。
この記事では、「なぜインフラエンジニアの価値が低下しているのか?」という点と「これからのインフラエンジニアはどうすべきなのか?」について自分の考えを整理してみようと思います。
今冬人気のドラマでこんなセリフがありました。
この前か後か忘れましたが「インフラエンジニアはいないと困るでしょう」というセリフもあったような気がします。たしかリストラの話の流れだったと思います。
この部分について、自分の思うところを書いてみようと思います。
確かにインフラエンジニアはいないと困るのですが、しかし「今までみたいなインフラエンジニア」はそのうちいなくても誰も困らなくなる、ってのが実際のところだと思います。
インフラエンジニアの置かれた状況は業種業態によって異なりますが、多くの環境ではインフラエンジニアの価値は下がり続けていると私は考えているからです。
ITインフラの優劣がビジネスに直結・大きな影響を与える通信キャリアや大規模なWEBやコンテンツサービスプロバイダーなどの例外も存在していますが、大多数を占める旧態然としたいわゆる企業の情シスに所属するインフラエンジニアやSIerのインフラエンジニアの価値は間違いなく低下の傾向であり、このままではいずれその価値は限りなくゼロ、むしろ企業にとっては経済的にマイナスの存在(お荷物)になるのでは、と器具しています。
この記事では、「なぜインフラエンジニアの価値が低下しているのか?」という点と「これからのインフラエンジニアはどうすべきなのか?」について自分の考えを整理してみようと思います。
[改訂新版]プロのためのLinuxシステム構築・運用技術 (Software Design plus)
Tweet
@enakai00 さんが5年前に執筆された書籍の改訂版です。
現在主流のRHEL7系向けに書き直されています。
なんとなく仕事や趣味でLinuxを使っている人が、「プロ」と呼ばれるレベルに到達するために押さえておくべきポイントを実際の操作例や著者の体験を通した業務の経験をもとに解説されています。
章構成は こちら から確認できます。
クラウドやコンテナの活用に伴い、インフラエンジニアだけでなくアプリエンジニアもLinuxに触れる機会が増えています。
普段なんとなく使っているLinuxを深掘りして学習することは、クラウドやコンテナを一歩進んで活用するためにも役立ちます。
ちなみに、この本の内容は @enakai00 さんと私が担当している こちら と こちら の講義に大部分が組み込まれています(改定前の内容です
講義は OpenStack を題材にしたクラウド基盤の基礎コースですが、クラウドの裏側を理解するにはLinuxの知識が必要不可欠であるためです。
仕事でOpenStack等のクラウドの裏側に触れる機会のある方にもこの本の内容は有益(むしろ必須)です。
電子版もあります。
登録:
投稿 (Atom)