hacks

2015年05月05日

このエントリーをはてなブックマークに追加

新規構築は問題が無い

自分の知る限り、1.611まではJava6で動いていた。そもそも、何故、Java6を使っていたか?それは、Jenkins環境を構築し始めた頃にまで遡る。その当時は、Java6では上手く動かなかったから。それ以降、Java7ではなく、Java6を使い続けて来た。

Java7必須になった変更点を追いかける。

Changelog | Jenkins CI より

What's new in 1.612 (2015/05/03)

  • As promised, shipping with Java7 class files. (issue 28120)

Java7必須となっている事が分かる。

Java6の場合、どうなるかは下記の通り。

検証環境

  • CentOS release 6.6
  • java-1.6.0-openjdk-1.6.0.0-11.1.13.4.el6.x86_64
Java7がインストールされてない場合
# service jenkins start
Starting Jenkins Jenkins requires Java7 or later, but you are running 1.6.0_32-b32 from /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
java.lang.UnsupportedClassVersionError: 50.0
        at Main.main(Main.java:90)
                                                                   [  OK  ]

OK判定されているのに、実際は起動してない。

Java7をインストール
# yum install java-1.7.0-openjdk

Java6をアンインストールする必要は無い。

Jenkinsを起動
# service jenkins start
Starting Jenkins                                           [  OK  ]

無事に起動。

まとめ

1.612以降は、Java7を利用する。

あとがき

毎週定期的に入れ替えてるからこそ気づける細かな変化。




編集
@hansode at 12:00|PermalinkComments(0)TrackBack(0)

2015年03月02日

このエントリーをはてなブックマークに追加

CLI(jenkins-cli.jar)を扱った情報が少ない

今回はCLI(jenkins-cli.jar)を使ってジョブをbuildしてみる。軽く検索した限りでは欲しい日本語情報が見つからなかったので、探していた人にとっての有用情報になってくれたなら、幸いである。

CLI(jenkins-cli.jar)セットアップ手順は、以下のエントリ。

検証環境

  • CentOS release 6.6
  • jenkins-1.599-1.1.noarch
  • java-1.6.0-openjdk-1.6.0.0-11.1.13.4.el6.x86_64

CLI(jenkins-cli.jar)でbuildする方法

http://127.0.0.1:8080/cli/command/buildより:

java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ build JOB [-c] [-f] [-p] [-r N] [-s] [-v] [-w]
Starts a build, and optionally waits for a completion.
Aside from general scripting use, this command can be
used to invoke another job from within a build of one job.
With the -s option, this command changes the exit code based on
the outcome of the build (exit code 0 indicates a success)
and interrupting the command will interrupt the job.
With the -f option, this command changes the exit code based on
the outcome of the build (exit code 0 indicates a success)
however, unlike -s, interrupting the command will not interrupt
the job (exit code 125 indicates the command was interrupted)
With the -c option, a build will only run if there has been
an SCM change
 JOB : Name of the job to build
 -c  : Check for SCM changes before starting the build, and if there's no
       change, exit without doing a build
 -f  : Follow the build progress. Like -s only interrupts are not passed
       through to the build.
 -p  : Specify the build parameters in the key=value format.
 -s  : Wait until the completion/abortion of the command. Interrupts are passed
       through to the build.
 -v  : Prints out the console output of the build. Use with -s
 -w  : Wait until the start of the command

オプション指定方法を除くと、基本は

java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ build JOB

である事が分かる。

基本編

ここからは基本的なbuildを順に試して行く。

基本1: オプションなし/ジョブ登録(予約)

ジョブ登録(予約)である。何故、予約なのか?それは、CLIがジョブの結果を待たないからだ。これはWebUIからbuildするのと同じである。WebUIの操作に慣れている場合は、いつもの操作であるはずだ。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing

ジョブ登録が成功した場合は何も表示されず、凄くUNIXらしい振る舞いをする。終了コードもUNIXらしい振る舞いをする。成功時の$?0で、失敗時はnon 0だ。 ‘

基本2: -w/ジョブが開始するまで待つ

ジョブ予約するだけでなく、ジョブが起動するまでは待ちたい場合もある。そんな時は、-wオプションの出番だ。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -w
Started testing #39

Started <JOB> #<build-ID>が表示され、コマンドが正常終了する。

基本3: -s/ジョブの実行結果を待つ

ジョブが予約・起動するのを確認するだけでなく、ジョブの結果が出るまで待ちたい場合もある。そんな時は、-sオプションの出番だ。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -s
Started testing #40
Completed testing #40 : SUCCESS

先程の-wオプションによる実行結果に加え、Completed <JOB> #<build-ID>: <build>成否が表示され、コマンドが正常終了する。

基本4: -s -v/ジョブの実行結果を待ち、buildのconsoleログを表示

-sオプションで分かるのは、buildの成否までだ。しかし、buildのconsoleログが表示されない。デバッグ時やJOB登録直後の調整時にはconsoleログを表示したくなる。そんな時は、-vオプションの出番だ。-vは単体では無く-sと一緒に使う事が期待されている。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -s -v
Started testing #41
Started from command line by hansode
Building remotely on ct103.ci03.dh (centos-6.4 vz.vm vz.kemumaki fpmbox rbenv) in workspace /var/lib/jenkins/workspace/testing
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/axsh/wakame-vdc.git # timeout=10
Fetching upstream changes from https://github.com/axsh/wakame-vdc.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/axsh/wakame-vdc.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision ed54f8de7e72f8902700fff011a26398790bf710 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ed54f8de7e72f8902700fff011a26398790bf710
 > git rev-list ed54f8de7e72f8902700fff011a26398790bf710 # timeout=10
 > git tag -a -f -m Jenkins Build #41 jenkins-testing-41 # timeout=10
[testing] $ /bin/bash -xe /tmp/hudson9218072417606499332.sh
+ date
Sun Mar  1 22:53:02 JST 2015
Finished: SUCCESS
Completed testing #41 : SUCCESS

-sオプション単体指定時よりも出力結果が多い事は一目瞭然だ。

基本編のまとめ
  1. オプションなし: ジョブ登録のみ
  2. -w: ジョブ登録、そしてジョブ起動するまで待つ
  3. -s: ジョブ登録・ジョブ起動、そしてジョブ成否が出るまで待つ
  4. -s -v: ジョブ成否が出るまで待ち、更にconsoleを出力

応用編

次に応用編を試して行く。

応用1: -p KEY=VALUE/パラメタつきbuild

ジョブの中には、パラメタ化してあるものもあるはずだ。常にデフォルト値で良い訳が無い。そんな時は-p KEY=VALUEの出番だ。以下の例ではビルド結果表示を分かりやすくするために-wを指定している。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -w -p GIT_BRANCH=ci-fail
Started testing #80

もしも存在しないパラメタを指定すると、その旨を表示して教えてくれる。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -w -p GIT_BRANCH2=ci-fail
'GIT_BRANCH2' is not a valid parameter. Did you mean GIT_BRANCH?

似たパラメタが存在する場合は、なんと、似たパラメタ名を教えてくれている!

応用2: -c/ソースコードに変更がある場合のみbuild

build命令を受け取ると、Jenkinsはソースコードに変更があろうともなかろうともbuildする。時には変更がある場合のみbuildした場合もある。そんな時は、-cオプションの出番だ。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -c
Using strategy: Default
[poll] Last Built Revision: Revision e6cc9351e46bc8d062d5b7d27d18cba366e138bf (origin/ci-fail)
 > git --version # timeout=10
 > git ls-remote -h https://github.com/axsh/wakame-vdc.git # timeout=10
[poll] Latest remote head revision on origin/ci-fail is: e6cc9351e46bc8d062d5b7d27d18cba366e138bf - already built by 80

この結果では、already built by 80と表示され、buildされない事が分かる。もしも疑わしい場合は再度-cオプション指定で実行してみると良い。何度実行しても同じbuild番号が出力されるので、buildされてない事を確認出来る。

応用3: -f/ジョブの中断を無視?

-fオプション指定で実行した場合、コマンドを中断した場合でも、ジョブを中断しないように制御出来るらしい。それに対し、-sオプションの場合はコマンドを中断すると、それに応じてジョブを中断するようである。

ここで曖昧な表現になっているのは、-f-sの違いを明確に確認出来なかった為である。今後もしも明確な差を得られた場合は、この内容を加筆・修正する。

応用編のまとめ
  1. -p KEY=VALUE: パラメタ付きbuild
  2. -c: 変化がある時のみbuild
  3. -f: ジョブ中断を無視?

参考文献

補足:終了コードの扱い

コマンド成否は、コマンドの終了コードを使って判断可能である。その為、パイプと組み合せたコマンドライン操作やシェルスクリプトとの相性は良い。

ジョブが正しく失敗する場合

意図的にジョブが失敗するように設定を変更してみる。確認したいのは、出力結果と終了コードだ。実行し、結果を確認してみる。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa build testing -s -v
Started testing #94
Started from command line by hansode
Building remotely on ct103.ci03.dh (centos-6.4 vz.vm vz.kemumaki fpmbox rbenv) in workspace /var/lib/jenkins/workspace/testing
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/axsh/wakame-vdc.git # timeout=10
Fetching upstream changes from https://github.com/axsh/wakame-vdc.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/axsh/wakame-vdc.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision ed54f8de7e72f8902700fff011a26398790bf710 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ed54f8de7e72f8902700fff011a26398790bf710
 > git rev-list ed54f8de7e72f8902700fff011a26398790bf710 # timeout=10
 > git tag -a -f -m Jenkins Build #94 jenkins-testing-94 # timeout=10
[testing] $ /bin/bash /tmp/hudson2042532681956823107.sh
+ hoge
/tmp/hudson2042532681956823107.sh: line 5: hoge: command not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Completed testing #94 : FAILURE

ジョブは完了し、結果はFAILURE

$ echo $?
2

そして終了コードは2non 0だ。

終了コードのまとめ
  1. 成功時: 0
  2. 失敗時: non 0

失敗時の終了コードは、失敗内容によって変化する。

あとがき

CLI(jenkins-cli.jar)を使ってみて分かったのは、curlコマンドなどによるRemote API経由操作よりも、細かな操作が可能である事だ。認証プラグインとの組み合わせ課題をきっかけに検証を始めた訳だが、今の所は使ってみて良かったと思える。もしかしたら、近いうちに他のコマンドも試してみるかも知れない。




編集
@hansode at 10:30|PermalinkComments(0)TrackBack(0)

2015年03月01日

このエントリーをはてなブックマークに追加

「変態Jenkins」の裏側を少しずつ公開

ChatOps導入検討にて、WebUIを介さずにJenkinsジョブ操作をする必要性が高まった。手元のJenkinsさんが世に出回ってる様な設定・構成であれば問題はないのだが、世の中のそれとは違う為に遭遇したであろう事を、ここにまとめておく。

背景・経緯

Jenkins設定にて:

  1. グローバルセキュリティの設定を有効化
  2. アクセス制御にはGithub Authentication pluginを使用
    1. 深く掘り下げてないが、結果としてGitHub Authentication pluginを使用していると、API Tokenを利用できない。
  3. WebUI経由でしかジョブ実行する手段がないのか…と調べた結果、Jenkins CLIとCredentialの組み合せに辿り着いた。
おまけ:GitHub Authentication plugin有効時のTokenによるAPI呼び出し失敗結果

Jenkins CLI導入前は、Remote APIをAPI Token付きで使用する事を検討・検証していた。しかし、この検証ではGitHub Authentication pluginとの組み合わせ問題に遭遇した。参考までにGitHub Authentication pluginを有効にしたJenkinsにHTTPリクエストしてみると、こうなる。

$ curl curl -fsSkL -X POST -u hansode:******** http://127.0.0.1:8080/job/testing/build
curl: (22) The requested URL returned error: 400 Nothing is submitted

調査・検討した結果、自分はJenkins CLIを使う事にした。

Jenkins CLIとCredentialを使って動かす

Jenkins CLI - 日本語 - Jenkins Wikiを参考に設定して行く。

1: CLIの取得

CLIの取得 Jenkins CLIは jenkins.war の中に、jarファイルとして含まれています。http://yourserver.com/cli からダウンロードすることができます。CLI jarはJenkinsのバージョンに依存していますが、実際には異なるバージョン間でも互換性を保つことができるようになっています。

このように書かれている。手元のJenkinsUI(http://yourserver.com/cli)にアクセスしてみると、以下の様なページが表示される。ページ内にはjenkins-cli.jarダウンロードURIが存在するので、ダウンロードURIをクリックし、手元にダウンロードする。

jenkins-cli

2: Credentials(証明書) を使って動かす (1.419 以降)

Credentials(証明書) を使って動かす (1.419 以降) Jenkinsの利用に認証が求められる場合は、公開鍵認証を設定する必要があります。Web UIからログインし、 http://yourserver.com/me/configure にアクセスして下さい。そして、公開鍵を所定のテキストエリアに入力します。

http://yourserver.com/me/configureにアクセスすると、以下の様な個人設定画面が表示されるので、SSH Public Keysに公開鍵を貼り付けて、保存する。

jenkins me config

3: 秘密鍵指定で認証確認

先程ダウンロードしたjenkins-cli.jarを使い、who-am-iコマンドを実行してみる。認証が成功すると、以下の様にユーザー名が表示される。

$ java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ -i /path/to/id_rsa who-am-i
Authenticated as: hansode
Authorities:
  authenticated

hansodeとして認証された事が分かる。これ以降は好みのコマンドでJenkinsを操作可能だ。

あとがき

やや不本意な状況で辿り着いたCredentialを使ったCLIではあるが、意外と使い勝手が良さそう。




編集
@hansode at 16:00|PermalinkComments(0)TrackBack(0)

2015年01月26日

このエントリーをはてなブックマークに追加

UI経由ではバージョン指定できない(2015/01/26現在)

Jenkinsは、恐らく手頃なCIツールだ。個人的には2年半近く使っている。他のツールと同様に、ある程度使い続けていると、どこか使い辛さを感じ始める。Jenkinsにおける使い辛さの1つは、狙ったバージョンのJenkinsプラグインをインストール出来ない事。通常のJenkinsプラグインインストール手順は、こうだ。

  1. プラグインマネージャhttp://jenkins/pluginManager/からプラグインを検索
  2. 欲しいプラグインを選択
  3. プラグインをダウンロード・インストール
  4. Jenkinsを再起動

この手順には、プラグインのバージョンが登場しない。暗黙のルールとして、最新バージョン(latest)が指定され、プラグインがインストールされて行く。しかも、管理者の意図とは関係のない所で、だ。これは問題を含んでいる。とある日に構築したシステム構築を再現する様な場合は、要件を満たせない。そこをどうにかしたくて、手順を確立させた。こんな手順、本当は無くなって欲しい。

プラグインインストールの裏側を理解する

Plugins - Jenkins - Jenkins Wiki より、

By hand Download Site

Save the downloaded *.hpi/*.jpi file into the $JENKINS_HOME/plugins directory. You will then need to restart Jenkins (many containers let you do this without restarting the container)

http://updates.jenkins-ci.org/download/plugins/からJenkinsプラグインをダウンロード出来る事が分かる。プラグインリポジトリを注意深く調査していると、過去のバージョンもダウンロード出来る事が分かる。wikiの内容と調査結果をまとめると、こうなる。

最新版:

  • http://updates.jenkins-ci.org/latest/${name}.hpi

特定バージョン:

  • http://updates.jenkins-ci.org/download/plugins/${name}/${version}/${name}.hpi

保存先:

  • ${JENKINS_HOME}/plugins/${name}.hpi

反映方法:

  • Jenkins再起動

サービス起動後、プラグインマネージャを確認すると、狙ったバージョンのプラグインがインストールされている事を確認できるはずだ。少なくとも、自分が検証した限りでは、期待通りの結果となっている。

おまけ:プラグイン名とバージョンのペアを管理する

パッケージを1つ1つインストールするのは、実に面倒臭い。プラグインによっては最新版が良い場合もある。それを一括管理する為、自分は下記のようなスクリプトによりシステム構築している。

jenkins-plugin.sh:

#!/bin/bash
#
# requires:
#  bash
#
set -e
set -o pipefail

JENKINS_HOME=${JENKINS_HOME:-/var/lib/jenkins}
base_url=http://updates.jenkins-ci.org

function plugin_list() {
  cat <<_EOS_ | egrep -v '^$|^#'
PrioritySorter 1.3
config-autorefresh-plugin
configurationslicing
config-file-provider
cron_column
downstream-buildview
git        1.4.0
git-client 1.1.1
hipchat 0.1.5
greenballs
managed-scripts 1.1
nested-view
next-executions
parameterized-trigger 2.18
rebuild 1.20
timestamper 1.5.6
token-macro
urltrigger
view-job-filters
_EOS_
}

while read line; do
  set ${line}
  name=${1} version=${2}
  if [[ -z "${version}" ]]; then
    version=latest
  else
    version=download/plugins/${name}/${version}
  fi
  curl -fSkL ${base_url}/${version}/${name}.hpi -o ${JENKINS_HOME}/plugins/${name}.hpi
done < <(plugin_list)

chown -R jenkins:jenkins ${JENKINS_HOME}/plugins

ヒアドキュメント部分が、プラグイン名とバージョンを指定のペアを管理。

  • プラグイン名のみの場合は、最新版(latest)をインストール
  • プラグイン名とバージョン指定している場合は、そのバージョンをインストール

上記ヒアドキュメント部分を説明すると、こうなる。

  • バージョン固定:
    • PrioritySorter 1.3
    • git 1.4.0
    • git-client 1.1.1
    • hipchat 0.1.5
    • managed-scripts 1.1
    • parameterized-trigger 2.18
    • rebuild 1.20
    • timestamper 1.5.6
  • 最新版:
    • config-autorefresh-plugin
    • configurationslicing
    • config-file-provider
    • cron_column
    • downstream-buildview
    • greenballs
    • nested-view
    • next-executions
    • token-macro
    • urltrigger
    • view-job-filters

なお、これは自分が今までに使って来た厳選プラグインでもある。

あとがき

使い辛い所を分かった上で使い続けるJenkinsさんとの生活。もう少し続きそう。




編集
@hansode at 10:30|PermalinkComments(0)TrackBack(0)

2015年01月24日

このエントリーをはてなブックマークに追加

新規構築は問題が無い

気にすべきは、マイグレーションが実行されるので、ビルドログが多い環境ほど注意が必要となる事。いつものアップグレード時間よりも長く待たされる事を、承知した上でメンテナンスを行えたなら 、言う事は無い。なお、手元のJenkinsクラスタでは、1.596から1.597へのアップグレードは問題なくマイグレーションが完了した。

ハイライトを追いかける。

Changelog | Jenkins CI より

What's new in 1.597 (2015/01/19)

  • JENKINS_HOME layout change: builds are now keyed by build numbers and not timestamps. See Wiki for details and downgrade. (issue 24380)

JENKINS_HOMEのレイアウトを変更したとの事。

レイアウト変更により、buildIDとbuild時刻の関係が逆転

[#JENKINS-24380] Use build numbers as IDs - Jenkins JIRA より

Before:

% ls -la
total 16
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 .
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 ..
lrwxrwxrwx 1 kohsuke kohsuke   19 Apr 18 10:42 1 -> 2014-04-18_10-42-35
lrwxrwxrwx 1 kohsuke kohsuke   19 Sep 15 17:51 2 -> 2014-09-15_17-51-46
drwxrwxr-x 2 kohsuke kohsuke 4096 Apr 18 10:42 2014-04-18_10-42-35
drwxrwxr-x 2 kohsuke kohsuke 4096 Sep 15 17:51 2014-09-15_17-51-46
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastFailedBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastStableBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastSuccessfulBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnstableBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnsuccessfulBuild -> -1

After:

% ls -la
total 16
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:52 .
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 ..
drwxrwxr-x 2 kohsuke kohsuke 4096 Apr 18 10:42 1
drwxrwxr-x 2 kohsuke kohsuke 4096 Sep 15 17:51 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:52 2014-04-18_10-42-35 -> 1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:52 2014-09-15_17-51-46 -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastFailedBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastStableBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastSuccessfulBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnstableBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnsuccessfulBuild -> -1
  • 以前は、日付が実態で、build番号がsymlink
  • 今後は、日付がsymlinkで、build番号が実態

この仕様変更によるマイグレーション処理が、システムアップグレード時(プロセス起動時)に発生する。今までのbuildログが多く残されていれば多く残されている程、マイグレーションに時間がかかる。

念の為、アップグレード前にJENKINS_HOMEをバックアップしておいた方が良いかも知れない。それと、事前にbuildログをある程度掃除しておいた方が良いかも知れない。

migration進捗は/var/log/jenkins/jenkins.logで確認可能

migration進捗が気になる場合は/var/log/jenkins/jenkins.logtail -fしておくと良い。過去のbuild番号の数だけdoMigrateが記録されて行く。

Jan 24, 2015 4:08:11 PM jenkins.model.RunIdMigrator doMigrate
WARNING: found no build.xml in 2014-03-06_16-55-39
Jan 24, 2015 4:08:11 PM jenkins.model.RunIdMigrator doMigrate
WARNING: found no build.xml in 2014-01-10_16-56-22
Jan 24, 2015 4:08:11 PM jenkins.model.RunIdMigrator doMigrate
WARNING: found no build.xml in 2013-10-23_16-56-23
Jan 24, 2015 4:08:11 PM jenkins.model.RunIdMigrator doMigrate
WARNING: found no build.xml in 2014-06-16_16-56-47
Jan 24, 2015 4:08:11 PM jenkins.model.RunIdMigrator doMigrate
WARNING: found no build.xml in 2013-12-22_16-56-22

おまけ:buildログ定期削除スクリプト

参考までに、自分が使用しているbuildログ定期削除スクリプト。これを日次実行させている。Jenkinsの定期実行ジョブとして。

#!/bin/bash
#
# requires:
#  bash
#
set -e
set -o pipefail

LANG=C
LC_ALL=C

threshold=+$((30 * 2))

function disk_usage() {
  df -h
  df -k
}

disk_usage

for target_dir in /var/lib/jenkins/jobs/*/builds; do
  [[ -d "${target_dir}" ]] || continue
  echo ... ${target_dir}

  while read line; do
    [[ -f "${line}" ]] || continue
    rm ${line}
  done < <(find ${target_dir} -type f -mtime ${threshold})
done

disk_usage
  • threshold=+$((30 * 2))

thresholdで直近60日分を残すように指定している。この文字列は、findコマンドの引数として使用されるので、+に意味があるので、+を決して忘れぬように。

あとがき

Jenkinsコアパッケージアップグレードは、細目に実施した方が良い。




編集
@hansode at 18:00|PermalinkComments(0)TrackBack(0)

2015年01月06日

このエントリーをはてなブックマークに追加

快適なOpenSSH作業環境を手に入れるまでの道のり

OpenSSHによるリモートログイン対象が多く、整理せざるを得ない状況に追い込まれた所から始まり、改善を重ね、今の所は快適な環境を手に入れた。これまでの記録を、ここにまとめておく。

主な特徴

  • keychainのような機能
    • ssh-agent多重起動防止
    • ssh-addによる複数の秘密鍵登録管理
    • SSH_AUTH_SOCKパス固定化(screen/tmux detach/reattach連携対応用途)
  • keychainよりも軽量
    • 軽量な理由は、keychainよりも処理してる内容が少ないから

背景・経緯

  1. 作業対象が数台だった頃、各サーバに秘密鍵を配置する運用でしのいで来た
    1. ログイン対象数が増え始める
    2. 管理対象キーペア数が増え始め、鍵管理が面倒臭くなる
    3. SSHクライアントとなる作業用ラップトップ数が増え始める
    4. ~/.ssh/をバージョン管理し、ssh_configと秘密鍵を管理
    5. ~/.ssh/をデプロイする所までは解決 (本エントリにおいては省略)
  2. ログイン時のパスフレーズ入力が面倒になり、ssh-agentについて調査・検証を開始
    1. ssh-agentが自動起動するように~/.bashrcを改良
    2. ssh-agent多重起動問題に遭遇
    3. mitchellh謹製bashrc と出会い、コードを拝借
    4. ssh-agent多重起動防止を実装
  3. 複数の秘密鍵を扱いたいが、mitchellh版ではssh-addのデフォルトパスしか扱ってなかった
    1. 複数の秘密鍵を扱えるように改良
  4. リモートログイン先にて新たなssh-agentが起動して来てしまう問題に遭遇
    1. 大元のSSHクライアント環境においては、単一ssh-agentプロセスのみ起動していて問題は無い
    2. しかし、リモートログインすると、リモートログイン先で新たにssh-agentが起動してしまう問題に遭遇
    3. リモートログイン状態かどうかを判定する仕組みを追加
  5. screenでdetachした後、reattachすると、UNIXソケットパスが切り替わってしまう問題に遭遇
    1. ssh-agentscreenの中から使う方法を発見・拝借し、SSH_AUTH_SOCKを固定化
    2. 更にtmux内からもSSH_AUTH_SOCKが固定化されてる事を確認
  6. リモートログイン先がMacOSの場合、SSH_AUTH_SOCK が固定されない問題に遭遇
    1. Yosemiteでの外部からログインしてssh-agentを正しく使う方法を発見・拝借し、SSH_AUTH_SOCK を固定化
  7. 快適なssh生活を手に入れた
  8. 実は、ここまでまとめ来た内容と似たツールとしてkeychainの存在を知る・・・
    1. keychainモードへの切り替えを試みる
    2. プロトタイプ版を作り、使ってみると、起動するまでが遅かった
    3. keychainモードへの切り替えを保留
    4. keychainの機能のうち、ホームディレクトリがNFSマウントされた環境を考慮した仕組みだけは拝借し、機能追加
  9. 2015/01/06現在、似非keychainで快適生活を過ごしている
  10. YosemiteへのSSHログイン後の鍵が期待通りではない事に気付く
    1. 手元の環境に置いてはYosemiteでの外部からログインしてssh-agentを正しく使う方法が不要だったので、修正・削除
  11. 2015/01/08現在、似非keychainで快適生活を過ごしている

対象環境

  • ログインシェルをbashに設定しているUNIXアカウント
  • ログインシェルをzshに設定しているUNIXアカウント

対象者?(自分が置かれた環境とも言う)

  • ログイン元環境が複数台存在する
  • ログイン先環境が複数台存在する
  • 1日にSSH接続する回数が恐らく多い方だ
  • keychainが遅いと感じている

動作確認済み環境

$ bash --version
$ ssh -V
  • Cygwin 1.7 / Windows 8.1
    • GNU bash, version 4.1.17(9)-release (i686-pc-cygwin)
    • OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
  • MacOS 10.10 (Yosemite)
    • GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin14)
    • OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
  • Raspbian 7.6 (Wheezy)
    • GNU bash, version 4.2.37(1)-release (arm-unknown-linux-gnueabihf)
    • OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
  • Fedora release 20 (Heisenbug)
    • GNU bash, version 4.2.53(1)-release
    • OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013
  • CentOS-6.6
    • GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
    • OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

使い方

  1. 【設定】 後述する作業対象ファイルを作成・修正・保存
  2. 【準備】 新規bashプロセスを作成し、ssh-agentssh-addを自動起動させる
  3. 【実行】 ssh -A <remotehost> にてリモートホストにSSH接続

作業対象ファイル

  1. ~/.bashrc or ~/.zshrc - 必須
    • 追記。無い場合は新規作成。
    • SSHクライアントおよび全SSH接続対象に反映
  2. ~/.ssh/agent_keys - 必要に応じて
    • 新規作成 +SSHクライアント環境のみ
~/.bashrc or ~/.zshrc- 必須

~/.zshrcにおいても動作を確認。bash前提で話を進めて行くので、zshの場合はbashzshで読み替えて頂きたい。

SSHクライアント環境および全SSH接続対象の~/.bashrcに追記・反映する必要がある。下記内容を、~/.bashrcに追記。追記場所は行末などで良い。

#-------------------------------------------------------------------------------
# SSH Agent
# + based on https://github.com/mitchellh/dotfiles/blob/master/bashrc#L181-L203
#-------------------------------------------------------------------------------

ssh_env=${HOME}/.ssh/environment.${HOSTNAME}

function start_ssh_agent() {
  # remote?
  [[ -z "${SSH_CLIENT}" ]] || return 0

  ssh-agent | sed 's/^echo/#echo/' > ${ssh_env}
  chmod 0600 ${ssh_env}
  . ${ssh_env} > /dev/null

  local ssh_agent_keys=${HOME}/.ssh/agent_keys

  if [[ -f "${ssh_agent_keys}" ]]; then
    local privkey=
    while read privkey; do
      # expand a file path using "~" or "${HOME}"
      eval privkey=${privkey}
      [[ -f "${privkey}" ]] || continue
      ssh-add ${privkey}
    done < ${ssh_agent_keys}
  else
    ssh-add
  fi
}

# Source SSH agent settings if it is already running, otherwise start
# up the agent proprely.

if [[ -f "${ssh_env}" ]]; then
  . ${ssh_env} > /dev/null
  ps -p ${SSH_AGENT_PID} > /dev/null || {
    start_ssh_agent
  }
else
  start_ssh_agent
fi

# static ssh agent sock path

ssh_agent_sock=${HOME}/.ssh/agent.sock.${HOSTNAME}

# based on http://www.gcd.org/blog/2006/09/100/
if ! [[ -L "${SSH_AUTH_SOCK}" ]] && [[ -S "${SSH_AUTH_SOCK}" ]]; then
  ln -fs ${SSH_AUTH_SOCK} ${ssh_agent_sock}
  export SSH_AUTH_SOCK=${ssh_agent_sock}
fi
~/.ssh/agent_keys - 必要に応じて作成

このファイルは作成しなくても良い。もしも使う場合、記述例は下記の通り。

~/.ssh/keys/github/hansode
~/.ssh/keys/wakame/deploy

この仕組みが威力を発揮する主な状況は、

  • 扱う秘密鍵が複数存在する時
  • 扱う秘密鍵は単数だが、ssh-addコマンドで追加させたい秘密鍵パスがデフォルト検索パスではなく、別の場所か複数指定したい時

なお、デフォルト検索パスはssh-addmanで述べられている。

man ssh-add より:

 DESCRIPTION
     ssh-add adds private key identities to the authentication agent,
    ssh-agent(1).  When run without arguments, it adds the files
    ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and
    ~/.ssh/identity.  After loading a private key, ssh-add will try to load
    corresponding certificate information from the filename obtained by
    appending -cert.pub to the name of the private key file.  Alternative
    file names can be given on the command line.

manに述べられている通り、引数無しssh-addコマンド実行の場合は、下記ファイルが追加対象となる。

  • ~/.ssh/id_rsa
  • ~/.ssh/id_dsa
  • ~/.ssh/id_ecdsa
  • ~/.ssh/id_ed25519
  • ~/.ssh/identity

これらに該当しないファイルパス、または複数ファイルを扱いたい場合、~/.ssh/agent_keysに記述しておくと、秘密鍵を容易に扱えるようになる。例え扱う秘密鍵が単一であり、しかもデフォルト検索対象であったとしても、明示的な宣言により、何を利用しているのかが見えやすいと言うメリットがある。それゆえ、個人的には積極的に利用している。

動作確認: ローカル環境編

前提条件
  • ローカル環境の~/.bashrc 修正が完了している事
確認項目
  1. ssh-agentが自動起動する
  2. ssh-addにより秘密鍵が登録される事
  3. ssh-agentが多重起動しない事
  4. SSH_AUTH_SOCKが固定化される事
確認作業: ssh-agent自動起動、ssh-addによる鍵登録、多重起動防止

bashを起動する。設定が正しければ、ssh-agent起動とssh-addによる複数鍵登録に成功し、下記のような出力が得られる。キーペアにパスフレーズが設定されている場合は、パスフレーズ入力待ちとなる。

localhost$ bash
Identity added: /home/hansode/.ssh/keys/github/hansode (dsa w/o comment)
Identity added: /home/hansode/.ssh/keys/wakame/deploy (rsa w/o comment)

次に、ssh-agentが多重起動しない事を確認する。新たなbash起動前のPIDを確認。

localhost$ echo $$
6796

PID6796である事が分かった。更にbashを起動。

localhost$ bash
localhost$ echo $$
2388

bash起動後、今度は何も出力されていない。そしてPID2388。これにより、別PIDである事が分かる。更にもう1つbashを起動してみる。

localhost$ bash
localhost$ echo $$
3916

PIDssh-agentの起動状況をまとめると、

  1. PID=6796 - ssh-agentが起動
  2. PID=2388 - ssh-agentは起動しない
  3. PID=3916 - ssh-agentは起動しない

整理すると、

  • ssh-agnetが起動してない場合は、ssh-agentを起動し、ssh-addで秘密鍵を登録
  • ssh-agentが起動している場合は、何もしない
  • ssh-agent多重起動を防止
確認作業: SSH_AUTH_SOCK固定化

SSHに関する環境変数を確認。

localhost$ env | sort | egrep ^SSH_
SSH_AGENT_PID=192
SSH_AUTH_SOCK=/home/hansode/.ssh/agent.sock.localhost

この結果から、SSH_AUTH_SOCK~/.ssh/agent.sock.${HOSTNAME}である事が分かる。ファイルパスに${HOSTNAME}を含めている理由は、ホームディレクトリがNFSマウントされた環境においても動作させる為。

~/.ssh/agent.sock.${HOSTNAME}のファイル情報を確認してみると、

localhost$ ls -l ~/.ssh/agent.sock.localhost
lrwxrwxrwx 1 hansode なし 32 Jan  3 21:39 /home/hansode/.ssh/agent.sock.localhost -> /tmp/ssh-3RRm1KL1FZ1A/agent.6700=

SSH_AUTH_SOCKに指定されているファイルは、シンボリックリンクである事が分かる。

シンボリックリンク先は/tmp/ssh-3RRm1KL1FZ1A/agent.6700である事も分かる。/tmp/ssh-3RRm1KL1FZ1A/agent.6700のファイル情報を確認してみると、実態となるUNIXソケットである事が分かる。

localhost$ ls -l /tmp/ssh-3RRm1KL1FZ1A/agent.6700
srw------- 1 hansode なし 0 Jan  3 21:29 /tmp/ssh-3RRm1KL1FZ1A/agent.6700=

整理すると、

  1. SSH_AUTH_SOCK~/.ssh/agent.sock.${HOSTNAME}
  2. ~/.ssh/agent.sock.${HOSTNAME}は、シンボリックリンク
  3. リンク先は/tmp/ssh-3RRm1KL1FZ1A/agent.6700

ssh-agentが改めて起動する場合は、シンボリックリンク情報だけが張り替わり、SSH_AUTH_SOCK=~/.ssh/agent.sock.${HOSTNAME}は固定化・定数化される。

動作確認: リモート環境編

前提条件
  • ローカル環境の~/.bashrc 修正が完了している事
    • ssh-agentが起動してる事
    • リモート環境用キーペアの秘密鍵がssh-addによる登録されてる事
  • リモート環境の~/.bashrc 修正が完了している事
    • リモート環境用キーペアの公開鍵が~/.ssh/authorized_keysに登録されてる事
確認項目
  1. SSH_AUTH_SOCKが固定化される事
確認作業: SSH_AUTH_SOCK固定化

参考までに、ForwardAgent noの場合は、SSH_AUTH_SOCKが存在しない。

localhost$ ssh remotehost
remotehost$ env | sort | egrep ^SSH_
SSH_CLIENT=192.0.2.68 39922 22
SSH_CONNECTION=192.0.2.68 39922 192.0.2.101 22
SSH_TTY=/dev/pts/0

ForwardAgent yes(-Aオプション付き)の場合は、SSH_AUTH_SOCKが設定される。そして、リモート環境においても~/.ssh/agent.sock.remotehostが設定されている事も分かる。

localhost$ ssh -A remotehost
remotehost$ env | sort | egrep ^SSH_
SSH_AUTH_SOCK=/home/hansode/.ssh/agent.sock.remotehost
SSH_CLIENT=121.114.159.68 39934 22
SSH_CONNECTION=192.0.2.68 39922 192.0.2.101 22
SSH_TTY=/dev/pts/0

ローカル環境と同じ様に、リモート環境も~/.ssh/agent.sock.remotehostは、実態ソケットファイルを参照するシンボリックリンクとなっている事が分かる。

remotehost$ ls -l ~/.ssh/agent.sock.remotehost
lrwxrwxrwx 1 hansode hansode 31 Jan  3 22:33 /home/hansode/.ssh/agent.sock.remotehost -> /tmp/ssh-2cwxr7qAo7/agent.30716

動作確認: リモート環境screen連携編

前提条件
  • ローカル環境の~/.bashrc 修正が完了している事
  • リモート環境の~/.bashrc 修正が完了している事
確認項目
  1. SSH_AUTH_SOCK
    1. screenの外から固定化されている事
    2. screenの中から固定化されている事
    3. detach/reattachしたscreenの中からも固定化されている事
確認作業: SSH_AUTH_SOCK固定化

ForwardAgent yes(-Aオプション付き)で対象サーバにSSHログイン。

localhost$ ssh -A remotehost

screen起動前のPIDと環境変数SSH_AUTH_SOCKを確認。

remotehost$ echo $$
27973
remotehost$ printenv SSH_AUTH_SOCK
/home/hansode/.ssh/agent.sock.remotehost

期待通り~/.ssh/agent.sock.${HOSTNAME}が指定されている。

この時のファイルパスが、ローカル環境におけるファイルパスとは違う事に注目したい。リモート環境はリモート環境特有ファイルパスが生成されいてる。

  • localhost: ~/.ssh/agent.sock.localhost
  • remotehost: ~/.ssh/agent.sock.remotehost

これはローカル環境と同様にNFSマウントされたホームディレクトリ環境を考慮した仕組みである。

次にscreenを起動。

remotehost$ screen

screen内のプロセスIDと環境変数SSH_AUTH_SOCKを確認。

remotehost:screen$ echo $$
28303
remotehost:screen$ printenv SSH_AUTH_SOCK
/home/hansode/.ssh/agent.sock.remotehost

期待通り~/.ssh/agent.sock.${HOSTNAME}が指定されている。

次に、detachしreattachする。

remotehost$ screen -r

再度screen内のプロセスIDと環境変数SSH_AUTH_SOCKを確認。

remotehost:screen$ echo $$
28303
remotehost:screen$ printenv SSH_AUTH_SOCK
/home/hansode/.ssh/agent.sock.remotehost

期待通り~/.ssh/agent.sockが指定されている。これにより、detachしたscreen内の作業を後日行う事が可能だ。

余談:Keychain化を試みたが・・・

ある程度の仕組みをまとめ終えてからkeychainの存在を知り、一度はkeychainに乗り換え作業をしてみた。結果は、keychainを使わない事を選択した。理由は、keychain起動速度が遅い事。多機能ゆえに速度が犠牲になっているのだろう。秘密鍵を常時5つ登録している状況においては、特に遅く感じられた。独自実装だけでも機能要件を満たしていたので、敢えてkeychain化を中断した。

個人利用の限りでは、似非keychainで問題は無い。仮に多人数を対象にした鍵管理フローを構築したい場合は、keychain仕様が良いのかも知れない。少なくとも誰か1人が不満を言うまでは。

現バージョンの課題

  • ssh-agent再起動を考慮してない
    • 解決策はssh-agent -kを手動実行し、bashを起動

あとがき

本エントリを書くきっかけとなったのは、身近なメンバーに対して自分のssh-agent・秘密鍵管理術の説明資料が無かった事。彼らに作業改善案を口頭で説明・提案するにしては、伝える量が多く、手頃な説明資料が欲しくなった。そして、今回の末年始休みを活用し、まとめ終えた。

エントリ初版は数時間で書き終えたが、どうしても関連するコードが気になり、整理を開始。そして再検証作業、文書修正・・・。最終的に書き終えるまでにかかったのは、合計6日間。関連物も含め、整理する良い期間となった。

とにかく、手頃な説明資料を手に入れた!喜ばしい。

関連成果物

参考文献

続きを読む


編集
@hansode at 10:30|PermalinkComments(0)TrackBack(0)

2014年02月26日

このエントリーをはてなブックマークに追加

実は初のVagrant Boxエントリ

logo_vagrant-81478652

Vagrant Box生活してる人にだけ伝わればよい。そんな内容。更に限定すると、Vagrant/VirtualBoxの組み合せで生活をしていて、vagrant packagePackerを使わずにVagrant Boxをbuildするような内容の濃い生活をしてる人。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
設定項目(VirtualBox)
  • Serial Port: 1つ有効化
/var/log/messagesに出続けるメッセージ

余りにも最小設定・最小構成すぎて、syslogにガンガン書き込まれていた。

このメッセージが出てる原因は、/dev/ttyS0は存在するけども、デバイスとして認識されてない事。VMの構成要素にシリアルポートを追加し忘れていた。

box.ovfを修正

box名によってbox.ovfのファイルパスは異なる。

  • ~/.vagrant.d/boxes/${name}/virtualbox/box.ovf
修正前
修正後: slot="0"enabled="true"

vagrant reloadvagrant upによりシリアルポートが1つ追加された構成でVMが起動する。

あとがき

本エントリではbox.ovfによる修正を行ったけども、Vagrantfileから有効化・無効化する方法もある。その場合は、VBoxManagemodifyvmコマンドに指定するオプションを知っている必要がある。最終的には、VagrantBoxVagrantfile、どちらで指定するのかなどプロジェクト単位における構成管理方針次第か。provider固有設定する必要がある限りは、存在し続ける悩ましい課題の1つ。

参考文献



編集
@hansode at 15:30|PermalinkComments(0)TrackBack(0)

2014年02月22日

このエントリーをはてなブックマークに追加

bondingを検証したい

logo_vagrant-81478652

bondingを3セット、そんな検証環境が欲しかった。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
設定項目
  • NIC枚数: 7(6枚追加)
  • インターナルネットワーク: 3本
Vagrantfile

bondingインターフェースとスレーブインターフェースの構成。

  • bond0
    • eth1
      • eth2
  • bond1
    • eth3
      • eth4
  • bond2
    • eth5
      • eth6
    # -*- mode: ruby -*-
    # vi: set ft=ruby :

    # Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
    VAGRANTFILE_API_VERSION = "2"

    Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
      config.vm.box = "centos-6-x86_64"

      config.vm.provider :virtualbox do |v, override|
        config.vm.synced_folder ".", "/vagrant", disabled: true

        # bond0: eth1, eth2
        v.customize ["modifyvm", :id, "--nic2",   "intnet"]
        v.customize ["modifyvm", :id, "--nic3",   "intnet"]
        v.customize ["modifyvm", :id, "--intnet2", "bond0"]
        v.customize ["modifyvm", :id, "--intnet3", "bond0"]
        # bond1: eth3, eth4
        v.customize ["modifyvm", :id, "--nic4",   "intnet"]
        v.customize ["modifyvm", :id, "--nic5",   "intnet"]
        v.customize ["modifyvm", :id, "--intnet4", "bond1"]
        v.customize ["modifyvm", :id, "--intnet5", "bond1"]
        # bond2: eth5, eth6
        v.customize ["modifyvm", :id, "--nic6",   "intnet"]
        v.customize ["modifyvm", :id, "--nic7",   "intnet"]
        v.customize ["modifyvm", :id, "--intnet6", "bond2"]
        v.customize ["modifyvm", :id, "--intnet7", "bond2"]
      end
    end

ここで注目したいのは、単にintnetを追加するだけでなく、bondingペア毎にintnetを構成してる事。--intnetXで指定しない場合は、VirtualBoxは全て "intnet" としてインターネットワークを構成する。

あとがき

もはやVBoxManageコマンドを相当意識しないと細かな設定を行えない。

参考文献



編集
@hansode at 13:00|PermalinkComments(0)TrackBack(0)

2014年02月13日

このエントリーをはてなブックマークに追加

イベント
Docker Meetup in Tokyo #1
日付
2014/02/12(水) 19:00〜21:00
場所
国立情報学研究所
天気
晴れ
概要
発表後記
  • 開始直後の会場アンケート、30人強のうち、ICCを知ってるのは、たった1人!マジか
  • ↑な状況で話を進めたので、何だか会場全体を置き去りにしてる感
  • しかし、この発表をきっかけにICCを使う人が増え、情報共有・検証報告が増えたら、それは成功と言える。
  • 身近な数人からは『むしろ突き抜けてて良かった。』との言葉を頂けた。
  • ICCに関わらず、Dockerのネットワーク周辺を触ってる人は少数派だと言う事を実感。



編集
@hansode at 14:00|PermalinkComments(0)TrackBack(0)

2014年01月29日

このエントリーをはてなブックマークに追加

bridgeインターフェースを追加する時は特にIPアドレスは不要

logo_vagrant-81478652

2枚目のNICを追加し、bridgeインターフェースを作成した環境で検証したい。そうした場合、private_networkに属したNICを追加すれば良いのだが、IPが必須パラメタとなっている。そんな場面の回避策。

検証環境
  • Windows 8.1
  • Vagrant 1.4.3
  • VirtualBox 4.3.6 r91406
  • VMware Workstation 10.0.1 build-1379776
設定項目
  • NIC枚数: 2
  • config.vm.network "private_network", ip: "0.0.0.0"
Vagrantfile

特定provider非依存パラメタであるので、virtualboxであろうがvmwareであろうが、有効設定。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.network "private_network", ip: "0.0.0.0"
end

キモは、 0.0.0.0。

前述した通り、IPは必須パラメタなのである。仮に省略した場合はエラーとなる。これは後ほど触れる。8割り以上の設定では、NICとIPアドレスが対となる構成なのだろうけども、bridgeインターフェースを作成したい場合は、邪魔である。

参考までに、IPアドレス指定しない場合

前述のVagrantfileとは違い、ip: "0.0.0.0"を指定しない場合。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos-6-x86_64"

  config.vm.network "private_network"
end

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* An IP is required for a private network.

実行結果により、private_network指定の場合、IPは必須パラメタである事が分かる。

あとがき

『IPアドレス設定は、provisioner任せにした方が良さそうだ。』と言うのが、これまでのVagrant生活の経験則として落ち着いて来た。

参考文献



編集
@hansode at 15:00|PermalinkComments(0)TrackBack(0)