はじめに
なにかにささやかれてしまった結果抗えなかった。
Ansible
nginxのAnsible
先日チューニングしていたnginxのAnsibleを作った。
記事にしてなかったが現在すごく雑にawscliでインスタンスを立てるJobをランチャーとして使っている。
もう少しリッチにしたいのだが方向性が決まっていない為、ホスト管理の方法が絶賛迷走中。
よって巷ではあまりみない[IPアドレス],というホスト指定で実行するPlaybookとなった。
インスタンス作成
実行するともちろん通る
$ ansible-playbook -i 192.168.0.98, -u centos site.yml
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller starting with Ansible 2.12. Current version: 3.6.8
(default, Apr 16 2020, 01:36:27) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]. This feature will be removed from ansible-core in version 2.12.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
PLAY [all] ***********************************************************************************************************************************
TASK [Gathering Facts] ***********************************************************************************************************************
ok: [192.168.0.98]
TASK [nginx : modify ulimit open files] ******************************************************************************************************
changed: [192.168.0.98]
TASK [nginx : modify sysctl net.ipv4.ip_local_port_range] ************************************************************************************
ok: [192.168.0.98]
TASK [nginx : modify sysctl fs.file-max] *****************************************************************************************************
ok: [192.168.0.98]
TASK [nginx : install nginx repository for centos6] ******************************************************************************************
skipping: [192.168.0.98]
TASK [nginx : install nginx repository for centos7] ******************************************************************************************
skipping: [192.168.0.98]
TASK [nginx : install nginx packages] ********************************************************************************************************
ok: [192.168.0.98]
TASK [nginx : copy nginx.conf] ***************************************************************************************************************
changed: [192.168.0.98]
TASK [nginx : copy server.crt] ***************************************************************************************************************
changed: [192.168.0.98]
TASK [nginx : copy server.key] ***************************************************************************************************************
changed: [192.168.0.98]
TASK [nginx : enable and start nginx related service] ****************************************************************************************
changed: [192.168.0.98]
PLAY RECAP ***********************************************************************************************************************************
192.168.0.98 : ok=9 changed=5 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
RundeckからAnsibleを実行する
Rundeck with Ansible
で、これをRundeckから実行してみようという話。
予めRundeckのサーバにgit cloneしている想定。
ワークフローステップのほうのAnsible playbookを選択して以下のようにする。
- ansibleやplaybookのパスに関してはそれぞれ適正なものを記載する。
- コマンドラインオプションは全部
Extra Ansible argumentsに入れる。 - sshのユーザがデフォルトだと
rundeckなので使ってるユーザが違う場合は注意。
で、実行してみると普通にansibleが通る。
ワークフローステップの場合は本当にRundeck上でAnsible-playbookを実行するだけ。
ホストも指定したinbentoryファイルしか見ないのでRundeck的にはノード設定も不要。
(ただダミーとしてノードの指定は必要)
あとほかのansibleステップでも言えるがJob側でbecomeを設定できるのでplayboookに記載しなくてもいいのはメリット。
平時は普通にやってるとはいえsudo考えながらplaybook書くのってなんだかんだしんどいので。
この場合、正直RundeckはUIしか提供してないまである感じ。わかりやすいかも。
一旦完成
テストとしてはここまででよかったがせっかくAnsibleを流すならgit pullもセットでやってほしいのでこうなった。
ansible-playbookの実行前にlocal scriptでgit pullしているだけ。
ansible-playbook(ワークフローステップ)
本当はディレクトリ見て無ければgit cloneするスクリプト書くつもりだったがやめた。
よくよく考えるとJobが出来ている時点でcloneされているはずなので多分仕組みとしては外だしされるはずと考えたため。
多分フランクに考えて以下のようなJobが任意に実行できればよいのではないかと思う。
※ちなみにこのJobはcloneしても動かないので注意。(ユーザ名入れてください)
番外編
ノードフローステップ
実は昔から私がRundeckに抱えている疑念というか疑問がある。
以下のような対象が広範囲でかつノードを選んで実行しないとJobがあるとする。(実際はもっとノード数が多いイメージ)
これを実運用で回していると押し間違えなどが発生するであろうことは想像に難くない。
そういったオペミスをどうやって防げばいいのか疑問だった。
まぁノード対象絞れっていう話なのだが実環境って「そうはならんやろ」が割と起きるので。
そこで登場するのがNode StepのほうのAnsible Playbook Workflow Node Step。
なのだが、その前にインベントリファイルの内容を共有しておきたい。
productionというグループにnginx-testというサーバが一台だけ登録されている。
(IP書きたくないけどLaunch時に毎回なにかしらDNS書くのは因果が逆な気がしている)
$ cat Ansible/nginx/hosts
[production]
nginx-test ansible_ssh_host=192.168.0.98
[all:vars]
env=production
そしてAnsible Playbook Workflow Node StepのJobがこれ。
細部に違いはあれど基本的にワークフローステップの時と設定は同じ。
重要なのは--limit productionでグループを絞っていること。
で、実行してみるとこうなる。
これはどういうことかというとnginx-testというホストに対してノード数の数だけansible-playbookを実行している。
本来はノードを指定して対象にだけ実行するのだがグループを絞ったことで各ノード毎にnginx-testだけを対象にansibleを実行する状態になってしまっている。
なのでこの状態だとどうあがいてもansible-playbookの適用先が間違えられなくなっている。これは面白い。
大変頭が悪くて私自身大好きな挙動をしているのだが先ほどのオペミスの話と照らし合わせて考えるとそう笑ってだけもいられない。
オペミス撲滅やセルフサービスの観点から考えると「間違えられない環境」というのは一つのキーワードになると思うので。
というわけでまとめると
絶対にオペミスを許さないという強い意志を感じた
あとがき
真面目に書くと「Jenkinsでいいじゃん」という呪いに押しつぶされそうだったので少しネタ寄りにしてしまった。
とはいえAnsible with Rundeck普通に使える印象。しばらくはこの形で運用してもいいかも。
なにもラクにならないかとおもっていたがラクになる部分はちゃんとあるしRundeckに乗せるメリットはあった。
(Activityとか実行結果の確認をRundeckの画面一つで完結できるので)
なによりRundeck本来のStepとAnsibleは普通に共存できるのでそこが一番のメリットなのではないかと感じた。
冒頭にも出したがこういった話だと「～～～でいいじゃん問題」が付きまとう。
Rundeckであれば一つの画面で例えばインフラはscript step、開発はplaybookみたいな住み分けができる。他とケンカしない。
あと基礎的なところだが「ansibleって実際のところみんな打ってるコマンド違うよね問題」ってあると思っている。
そういった問題に対してこういったUIで実行コマンドを指定して強制的に標準化できるというのは大きなメリットを感じた。
これでやっと目的のことが進められそうなのでまたしばらく更新がなくなる予定。(とか書くとまた更新するのだろうが)
時間ができたらほかのところもさらに深堀りしていきたい。