先月末より研究比較のために利用し始めたカゴヤ・クラウドのVPSであるが、
インスタンスの作成から起動までの時間はさくらのVPSやAWSと比べても早い！
インスタンス作成して、一分以内にSSHログインできるぐらいの早さである。
起動の速さに関しては今まで利用してきた中で一番！
カゴヤ・クラウドのVPSではAWSとの比較では以下の点が違うので注意。
インスタンスを停止しても、IPアドレスが変わらない。
インスタンスを削除しない限り、料金加算の対象になる。
インスタンスの課金単位は一日（１時間単位ではない）
以前Ansibleでの設定ファイルの変更にlineinfileモジュールを使う記事を投稿した。
今度はMySQLの設定で[mysqld]のセクションに入れねばならず、
設定ファイルの特定の位置に入れたいときはどうするかという問題が発生。
insertafterを指定するとその正規表現にマッチする行の後ろに入れてくれる。
insertbeforeなら前に入れてくれる。
実際の使用例
- name: set buffer size lineinfile: dest=/etc/my.cnf insertafter="^\[mysqld\]" line="max_allowed_packet = 32M" state=present
AmazonLinuxはパッケージが豊富なため、検証目的に最適であるが、そのままCentOS6で動かすとパッケージがなくてエラーになってしまうときがある。
AmazonLinuxの時だけ実施したいタスクに以下のように条件を追加すると、AmazonLinuxの時だけ実施されるようになる。
- name: tomcat restart service: name=tomcat8 state=restarted enabled=yes notify: tomcat8_restart when: ansible_distribution == "Amazon"
fluentd(td-agent)では通常ログファイルを監視するが、設定をいろいろ試したいときに都合よくログが出力されるとは限らない。
そんな時に便利なのがtype dummyである。
その名の通りダミーの文字列をデフォルトでは一秒ごとに出力し続けてくれる。
/etc/td-agent/td-agent.confに以下の記述を入れる
（デフォルトの記述は削除してもよいし、最下部に追記する形でも良い)
<source>
type dummy
tag raw.dummy
dummy {"message":"your message here"}
</source>
<match raw.dummy>
type stdout
</match>
#文法チェック
/etc/init.d/td-agent configtest
#文法チェックの結果確認
tail /var/log/td-agent/td-agent.log
#問題なければリロード
/etc/init.d/td-agent reload
これで入力された文字列が/var/log/td-agent/td-agent.logに出力される。
正規表現で何か加工したいなどの場合は、目的の文字列をdummyに指定しておき、/var/log/td-agent/td-agent.logで目的の結果になっているかを確認していくとよいだろう。
fluentdを使うならば、関連パッケージをひとまとめにしたtd-agentを入れるのが楽。
（単体で使うことはあまりないため）
公式パッケージにあるとおりのコマンドを打ち込むだけでインストール完了
curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh
上記curlの中身を見てもらうとわかるが、通常主導で実行する/etc/yum.repos.d/へのリポジトリ追加と
yumインストールを一気に行うコマンドが記載されている。
インストールが終わったら、以下のコマンドで起動してみよう。
/etc/init.d/td-agent start
wgetでproxyの記事は以前書いたのだが、あくまであれはwgetのものでgitの場合は独自に設定が必要。
コマンドを打ち込むか設定ファイルを追加するかのどちらでも良い。
（コマンドを実行すると設定ファイルに記載される）
git config --global http.proxy http://yourproxyhost:port/
git config --global https.proxy http://yourproxyhost:port/
# 実行結果はファイルに記載される。
cat ~/.gitconfig
[http]
proxy = http://yourproxyhost:port/
[https]
proxy = http://yourproxyhost:port/
現状のVPSサービス(さくらのVPS)に特に不満はないのだが、カゴヤ・クラウド/VPSの場合日額課金でありながら、月額にしてもさくらのVPSなどの同一スペックとほぼ同じ価格になるという点で魅力的だった。
またデフォルトでCentOS7を用意しているのも、利用してみたかった理由。
(さくらのVPSではカスタムインストールとなるうえに、なんか遅かったのでCentOS6に戻した経緯あり）
特に初期費用もないのでお気軽に始められるのと、スペックアップができるのもありがたい。
オンラインサインアップ完了後からすぐに利用可能。
ログインには秘密鍵が必要となるのでさくらのVPSの初期状態よりはセキュアである。
しかし公開鍵認証に関して説明が探さないと見つからないので、ハードルは高いかも。
仮想化方式がOpenVZらしいので
KVMのさくらVPS
XenベースのAWSとはまた違った特徴があるのかもしれない。スワップはないということでメモリの管理は要注意である。
久々にAnsibleを変更するとすっかり忘れてしまうので備忘録的メモ。
ansible-playbook -i hosts チェック対象.yml --syntax-check
文末につけた–syntax-checkをつけると構文が間違っていないかを事前にチェックできる。
文法的に間違っていなければ特に出力はない。
Ansible Playbookを大幅に変更した時は–syntax-checkを実行するようにしておくべし！
Ansibleで条件分岐などのOSの名前やバージョンなどを利用したいときがある、
事前調査としてその情報をリモートから取得できるコマンドがsetupコマンドである。
ansible -m setup -i hosts 対象のホスト
#出力結果のごく一部
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "6",
"ansible_distribution_release": "Final",
"ansible_distribution_version": "6.7",
"ansible_domain": "xxxx.example.com",
このようなOS情報が出てくるので、これを変数の条件として利用することができる。
OS情報だけではなくネットワークの情報やメモリの情報などハードウェアの情報も出てくるのでぜひ自分で打ちこんで確認してみてほしい。
先日の投稿でAWSのメンテナンスの記事を上げたが、来月下旬以降のメンテナンスにかなりの台数が巻き込まれて
サーバー本体再起動を行った。
その中で自動起動になっているはずのJenkinsがなぜかやたら時間がかかって、503連発で焦る。
もちろんJenkinsの起動にはそれなりの時間がかかるのだが、起動したと思ったらCSSやJSが読み込めていないようで真っ白のデザイン崩れ状態になっていた。
これは困った！再起動しただけなのにどういうことだ！
Jenkins CSS JS 404で検索すると同じ現象がヒットする。
「It’s happening because the static resources are unpacked in your /tmp directory and something else is cleaning up files older than x number of days old in there. 」
主な原因としては/tmpにstatic領域を展開しているため、時折消されるということらしい。ただし今回のケースは再起動前はうまくいっているため該当しない。
八方ふさがり感が漂うが、一度目の再起動中にJenkinsに頻繁にアクセスして503エラーを出しまくっていたので、もう一度再起動した。
そしたら不思議なことに現象は解消していた。よくわからん謎現象である。