投稿者のアーカイブ
CentOS7 での yum –security update 事情
夏風邪で減った体重がすっかりもどってしまいました。muraveです。
自身への細菌の侵入は許しましたが、サーバーへの侵入は防がねばなりません(自然な導入)
そんなわけで Ansible では yum update 相当の
yum: name=* state=latest
を毎回やっていたのですが、時間がかかりすぎて辛くなってきました。そんなわけでセキュリティアップデートだけするのがいいかな、と調べ始めました。
yum-plugin-securityというパッケージを利用して
$ yum --security update
が出来ることを知りました(そもそもCentOS7ではyum-plugin-securityがyumに統合されている模様)。 やったぜ!
CentOSのリポジトリではセキュリティアップデート情報が提供されていなくて正常動作しないらしいことも知りました。 やってなかったぜ!
先人の知恵と努力を頼りましょう。
- CEFS: CentOS Errata for Spacewalk
- Spacewalk用のCentOSエラッタを提供しているプロジェクト。
- Inject a little security in to your CentOS repositories
- CEFSのエラッタからupdateinfo.xml作るスクリプト作ったぜー、という話。
- CentOS 7でyumからSecurityUpdateを行えるようにする
- 作業内容は殆どこちらのページそのままです。ありがとうございます。
ということでまとめますと、securiy用のローカルリポジトリを作り、CEFSが提供しているSpacewalk用のエラッタからupdateinfo.xmlを作って設置、yum –security update します。
(さらに…)
VagrantでScaleway使うと開発に便利なのでは?という話
Dockerに傾倒していたので久しぶりにVagrantさわりました。muraveです。
少し前に弊社代表から「ScalewayってクラウドARM使えるし安いし、いいよ!(ネットワーク的に遠くてもいい場合には)」という情報が社内Slackに投げ込まれて気になっておりました。
Scaleaway (https://www.scaleway.com/)
私としてはX86系最安価でも 2Core + 2GB Memory + 50GB SSD + 1public IPv4 という構成で €2.99/month (€1=¥130として¥388.7) の価格性能比に魅力を感じます。
更に調べると詳細には
- VC1Sサーバー(2Cores 2GB Memory): €1/month (€0.002/hour)
- 50GB SSD Volume: €1/month (€0.002/hour)
- 1 public IPv4: €0.99/month (€0.002/hour)
合計 €2.99/month (€0.006/hour)
という価格内訳で(https://www.scaleway.com/faq/billing/)、パッケージ単位での上限が€2.99/monthとのこと。
上限が無くても時間単位で31日間フル稼働で€4.464(¥580.32)ですので、開発でインスタンスの使い捨てを繰り返して上限が無効な場合でもとんでもないことにはならないと思われます。
課金についてあまり気にしなくてもいいというのは精神的に良いです。
そんなわけでVagrantでScalewayをお気軽に使いたいと思います。
Mac からのリモートデスクトップ接続で日本語キーボード使う
- 2017/08/17
- murave
- Mac
- リモートデスクトップ
Laravel 5.1 でログ出力、faultline-php追加編
Laravel の次のLTS、5.5もそろそろ来そうな昨今ですが、また5.1のログ出力の話です。
昨日のBlogに書いたようにプロジェクトのログ出力に faultline-php (https://github.com/faultline/faultline-php) を組み込みました。Monolog integration のありがたさよ。
今日は faultline 関係の .env 対応を進めているのですが、コードがややこしくなる前の素朴なのをサンプルとして出しておこうかな〜と。
Serverless未経験おじさんのfaultline導入記
- 2017/08/02
- murave
- faultline
- Serverless
実験用に自分のメアドで新しくAWSのアカウント作ろうと思ったら存在してました、muraveです。事務所引っ越す前の住所になってたので5年以上放置してた模様。
実験にはお安めのVPSを使うことが多いのですが、Serverlessという波にのるためにAWSを使わざるをえないのです。というか faultline を使いたい!
サーバーレスアーキテクチャなエラートラッキングツール faultline
きっかけは『PHPカンファレンス福岡2017』です。その時のスライド。動画もきてました
コレだ! と思いましたね。
だいたい、今はまともなメールを送信するのも面倒じゃないですか?
某メール送信サービスを使おうと思ったこともあったのですが、エラーメール送信するには「利用者」の契約が必要とのことで、不特定多数の利用者が想定されるサービスでは使えません。そもそもエラー通知をメールで欲しいわけでもなく、今もメールから Slack に連携しています。
faultline は運用コストが低く(手間的にもマネー的にも)、そしてなによりクライアントの JavaScript についても利用できることに魅力を感じます。
faultline-jsを使ってJavaScriptのエラートラッキングにfaultlineを利用する
前置きが長くなってしまいました。これからが本番。導入について、主にどこで引っかかったか、です。
(さらに…)
PHPカンファレンス福岡2017 に参加しました
Laravel 5.1 でログ出力、それから (ログメールドライバー動作不良対処、クエリ出力の調整)
おひさしぶりです。運用していたら結構変わったので、またこのネタです。
一応以前の記事へのリンクおいときます。
『Laravel 5.1 でログ出力、その後 (出力レベル設定、クエリ出力)』
が、以前の記事の方法だとログメールドライバーが動作しないという問題が発生したので参考にしちゃだめ。
というわけで、以下の要件と不具合対処のために改修した内容を紹介します。
- ログファイルの権限絡みのエラー回避、何処から起動された処理かわかりやすくする等の目的で実行ユーザー名ベースでログファイルを作成。
- 動作環境(local, testing, production等のenvironment)でもログファイルを分ける。
- バッチ処理やartisanのコマンド実行の場合はARTISAN_BINARYをログファイル名に挿入してWebアクセスとはログファイルを分ける。
- デバッグフラグ(app.debug)を落とした状態ではINFO以上のログのみ出力。
- .envでAPP_QUERY_LOGGINGにtrueを設定したら発行されたクエリをinfoログで専用ログファイルに出力(デバッグフラグでのコントロールを廃止し個別にコントロール可能とし、ファイルも分けた)
- 以前の実装ではログメールドライバー(メール送信内容をログ出力するドライバ)が正常動作しなかったためLoggerインスタンスを差し替える方法から既存Loggerインスタンスのhandlerを差し替える方法に実装を変更。
実行されたJenkinsFileはReplayから確認できる
muraveです。
なうなやんぐなのでPipelineでJenkinsFileを使ってビルドについてもソースコード管理したいわけですが、他チームのJenkinsFileを参考にしたいときにJenkins上から内容が確認できないと、お願いしてJenkinsfileを送ってもらうという悲しいことになったり(実際に発生)。
Jenkins上から確認できるように出来ないものかとプラグインを探したり、ファイルは残っていたのでそれを参照できるようにできないかいろいろ試したりしていました。
しかし、そんな事をしなくても内容をみることができる方法がみつかったのでした。
まぁ、答えはタイトルに書いちゃってますが、こんなん予想できませんわー。
一部マスクしますが、キャプチャを貼っておきますね。
スクリプトを参照する場合は間違ってRunしないように注意ですね。
JenkinsのwithCredentialsでユーザー名とパスワードを扱えるのかを確認したいだけだった
muraveです。
なうなやんぐはPipelineでJenkinsFileを使ってビルドについてもソースコード管理ですよねー、ということで試してみているんですが、ユーザー名やパスワードをJenkinsFile内に書くわけにはいかないわけで。
方法を探してみたところ withCredentials でどうにか出来そうでした。
Fetch a userid and password from a Credential object in a Pipeline job.
ここを見ながらザックリと Pipeline script なジョブを作成して動作を確認しようとしたところ、少々ハマリました。
テスト用にユーザー名test、パスワードpassword、credentialsIdがtestの認証情報を作成しています。
node {
stage 'withCredentials Test'
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'test',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
sh 'echo uname=$USERNAME pwd=$PASSWORD'
}
}
これを実行したログを確認すると
[credential_****] Running shell script
+ echo uname=**** pwd=****
みたいな表示。うーん。何か権限的に引っかかってるのか、表示が潰されているだけなのかがわかりません。
結論を先に言うとユーザー名、パスワードについて表示を****で潰すようになっているようです。
あとで気づいたのですが[credential_****]のところもジョブ名がcredential_testなのでユーザー名であるtestが潰されているのでした。
ではユーザー名、パスワードが本当に取れているのかをどのように確認したのか?ですが次のような Pipeline script を作成しました。
node {
stage 'withCredentials Test'
def uname //withCredentials外にUSERNAMEを持ち出す為に使用
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'test',
usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
sh 'echo uname=$USERNAME pwd=$PASSWORD > idpw.txt'
sh 'pwd' //ワークスペースの位置確認をしたかったのだが、しかし
println(env.USERNAME) //groovyでの扱い
uname = env.USERNAME //withCredentials外にUSERNAMEを持ち出す
}
stage 'withCredentialsの外で出力'
println(uname)
stage 'ワークスペースの位置確認'
sh 'pwd'
}
実際に行ったのはidpw.txtファイルにリダイレクトして内容を確認でしたが、その際の謎動作の説明のための処理や、その後にログ上で確認できないかな?と思ってやってみたことも混ぜてあります。
ログから抜粋してまとめると以下のようになります。
Entering stage withCredentials Test
Proceeding
[credential_****] Running shell script
+ echo uname=**** pwd=****
[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****
****
Entering stage withCredentialsの外で出力
Proceeding
test
Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test
idpw.txtの位置が知りたくてpwdしているのですがwithCredentialsのブロック内で実行すると
[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****
と、ユーザー名のtestと同じだったために一部マスキングされてしまっています。まぁ、大体の位置は予想がついたのでidpw.txtを探して内容確認はできたわけですが(ちゃんとユーザー名、パスワードが出力されていました)。
最後にブロック外でpwdしてみるとちゃんと
Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test
と出力されているのがわかります。
ログだけでの動作確認ですがブロック外ならマスキングされないのがわかったのでuname変数を定義して外に持ちだしてやればいいかな〜と
Entering stage withCredentialsの外で出力
Proceeding
test
やはりマスキングされずに出力されました。動作の確認はできましたが、これは通常はやってはいけないパターンですね。
以上です。
Dockerのデータボリュームをバックアップ・リストア
現状試しているのはローカルストレージドライバでのデータボリュームの場合ですが、コンテナでバインドして扱うのが常道な感じです。
データ・ボリュームのバックアップ・修復・移行
http://docs.docker.jp/engine/userguide/dockervolumes.html#id9
に書いてあるやり方ですね。
jenkins-masterというコンテナの /var/jenkins_home をバックアップ・リストアする例をあげます。
バックアップ
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine tar czvf /backup/alp.tar.gz -C /var jenkins_home
リストア
$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine sh -c "rm -rf /var/jenkins_home/* && cd /var && tar xzvf /backup/alp.tar.gz"
念のためユーザーにrootを指定し、Alpine Linuxで実行しています。バックアップ時、相対ディレクトリ指定のためtarの-Cオプションを使用しています。展開時はゴミファイルが残るのが嫌だったのでリストア対象ディレクトリ内を全て削除してから展開していますが、削除はしないほうが安全かもしれません。
以上です。
データボリュームコンテナについての蛇足
データ永続化のために別途データボリュームコンテナを作成している場合でもローカルストレージなデータボリュームを使用していれば同じこと、docker save や docker export でバックアップというわけにはいかないようです。残念。