Jenkinsの設定変更だが、
サーバー移転時など全部のJOBの設定項目が変わるときに個別のジョブ設定を開いて、変更して、保存してという作業を省力化するコマンド。
find ${JENKINS_HOME}/jobs -name "config.xml" | xargs sed -i -e 's/置換前/置換後/g'
${JENKINS_HOME}にはJENKINSのHOMEディレクトリを指定する。
-iが直接書換えなので、実施前に結果を確認したい場合は-iを除去して実施すべし！
書換えた後は設定ファイルの再読み込みが必要。
似たようなテクニックは以前にもファイルをsedで一気に書き換えるで紹介しているが、ファイルのリストを作成するところを変更すればいろいろ応用が利く。
自作のPHPアプリでフォームの行数が多いとデータが無視される状況が発生していた。
現象自体は以前から認識していたのだが、原因を追究してみた。
どうもPHP5.3よりデフォルトで受け入れるパラメータの数の制限がかかっている模様で、デフォルトは1000パラメータ。
vi /etc/php.ini # max_input_varsの値を2000にした ; How many GET/POST/COOKIE input variables may be accepted max_input_vars = 2000 service httpd restart
php.iniの設定を書き換えて、Apache再起動したら現象は解消した。
ansibleのロール単位で実行するのかしないのかをwhen条件で制御できる
- { role: setup/s3download, tags: s3download, when s3download == "True" }
しかし何回やってもこの条件が無視されてしまう状況で頭をひねっていた。
原因は単純でwhenの後のセミコロン:を忘れていたことであった。
文法チェックのエラーにも引っかからずに進んでいたため発覚が遅れたという。
ただしくは以下の通り。
s3download: “True”などと変数ファイルで定義しておくと、このroleが実行される。
- { role: setup/s3download, tags: s3download, when: s3download == "True" }
一般的なDELキーやF2キーではBIOSが起動しない。
F12でメニューに入るのだが、その情報が画面に一切出てこない不親切さ。
X220を久々に使ってみてHDDのあまりの遅さに気絶しそうだったので、SSDに換装せねば！
LTEなのにダウンロードが2M/bpsとはどういうことだ！
加入者の増加に帯域が追い付いていない模様。
スピードを気にするようになってから10M超えたことはほんのわずかで
かたやDOCOMOの人の速度を見せてもらうとお昼時でも10M以上出ていた。
乗換含めて検討すべき時期に来ている。
以前UbuntuのisoからブータブルUSBを作成するときはunetbootinを利用した。
Windowsでもそのまま行けるのかと思ったけど、公式ページのサポートリストには記載なし。
作成してだめだとダメージが大きいので、Windows10にも対応していると噂のRufusという別のソフトウェアを試してみた。
操作は簡単でUSBを刺した状態で起動して、ブートディスクを作るの欄でisoファイルを選択するのみ。
ようやくWindows8.1を入れてみようかという・・・
今まではtd-agentのインストールディレクトリまでたどってインストールしていたのだが、正式なコマンドがあった。
# td-agent-gemと同じ結果だけど、バージョンごとに違ったりするので非推奨 /opt/td-agent/embedded/bin/fluent-gem install fluent-plugin-dstat # こちらを推奨 td-agent-gem install fluent-plugin-dstat
AWSはSwap領域がデフォルトでは存在しないため、メモリ不足になるとプロセスが勝手にkillされる。
なんか動きが遅いと思ったら/var/log/messageをみて以下のようなメッセージが出ていないかをチェックしてみるべし。
Out of memory: Kill process 12288 (java) score 689 or sacrifice child
この時はt2.nanoにnginx/Tomcat8/jenkinsでビルドを走らせただけでメモリ不足となりTomcatが応答不能になってしまった。
nginxのプロセスは残っていたのでメモリを占有するJavaのプロセスがkillされた模様。
MySQLのダンプファイルが文字化けしていないのに、投入した時に文字化けするときはテーブルまたはデータベースの文字コードがlatin1になっていないかをshow create文で確認すべし！
mysql> show create database jira; +----------+-----------------------------------------------------------------+ | Database | Create Database | +----------+-----------------------------------------------------------------+ | jira | CREATE DATABASE `jira` /*!40100 DEFAULT CHARACTER SET latin1 */ | +----------+-----------------------------------------------------------------+ 1 row in set (0.00 sec)
予想通りlatin1になっていて、日本語が文字化けしていた。
基本的にテーブル作成時に文字コードを指定しないと、データベースの設定を受け継いでしまう。
というわけでdatabaseを作り直す。
mysql> create database jira default charset utf8; Query OK, 1 row affected (0.00 sec) mysql> show create database jira; +----------+---------------------------------------------------------------+ | Database | Create Database | +----------+---------------------------------------------------------------+ | jira | CREATE DATABASE `jira` /*!40100 DEFAULT CHARACTER SET utf8 */ | +----------+---------------------------------------------------------------+ 1 row in set (0.00 sec)
この後ダンプSQLを投入したら、無事文字化け解消。
AWSのロードバランサーであるElastic Load Balancerについて自分で調べたことのまとめ。
ELBの実態はEC2インスタンスと思われるが、ELBのエンドポイントをnslookupしてみると2つのIPアドレスが返ってくる。
ELBは負荷に応じてスケールアウト（台数が増える）やスケールアップ（処理速度が高いインスタンスに変更）されるが、期間限定サイトの公開直後などの急激な上昇（スパイクアクセス）が見込まれる場合はあらかじめスケールアップの準備をサポートに依頼することができる。
cookpad.comはELBだと思われるが、4つのインスタンスが用意されており、cookpadで4台でさばけているので通常のサイトであれば初期設定でも大丈夫。
ELBの配下のインスタンスは複数ぶら下げることができるが、どのインスタンスに振られても処理が継続できるような作りにしておくのが基本。いわゆるセッションを特定のインスタンスに振り分けるスティッキーセッションもELBの設定により可能だが、それだと該当インスタンスが障害になった時に一部ユーザーのセッションが失われてしまう。