2015年04月05日

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

まとめページを作りたかった

これまでWakame-vdc情報をはてブにてwakame-vdcタグを付けしていたので、とりあえず集約は出来ている。そう、とりあえずは...。しかし、どこか使い辛かった。例えば初期リリースから今までを振り返ろうとすると、ブックマークした順序では使い辛い。

  • いつ、はてブしたのか?ではなく
  • 何日付けの記事なのか

都合の良いツールが見つからなかったので、Markdown形式でリンク集を作る事にした。

これで目出度く欲しい情報を手に入れた。なお、更新作業は気が向いた時に行っている。

リンクの過不足報告は、プルリクエストで

今の所は自分個人のリンク集でしかない。GitHubで公開しているので、もしも過不足を発見した等の場合はプルリクエストして頂けると幸いです。

あとがき

勝手に情報収集するbotを作るのが良いのか。




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

2015年04月02日

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

2015/03の出来事を個人的視点で振り返ってみる。毎月月初にお届けするつもりで、今回が記念すべき第一弾。

機能に関して

1: Pull Requestより

分類すると3つの機能が取り込まれた事になる。

それぞれ簡単にまとめると、

  • wakame-init for ubuntu-14.04
    • マシンイメージをubuntu対応して欲しいとの要望が来ていたので、ubuntu用wakame-initの開発が進んでいる。
  • isonoのバージョンを0.2.19から0.2.20へ
    • 低スペック環境においてキューの扱いに問題が生じていたので、その修正。
  • wakame-vdcのバージョンを13.08から15.03へ
    • 影響範囲は主にRPM。
      • wakame-vdc-13.08-<commit-datetime>git<commit-hash>.el6.x86_64.rpmから
      • wakame-vdc-15.03-<commit-datetime>git<commit-hash>.el6.x86_64.rpm
2: enterprise-iaas-easy-builder 公開

このツールは、これまでに構築して来た作業手順を整理したもので、環境構築作業時間を大幅に短縮する事が目的の1つとなっている。今後の構築作業のベースとして使用する予定で、改善すべき内容があれば、随時EIEBに反映して行く。

関連記事やblogエントリ

あとがき

何度か書いてみないと分からないので、宣言通りに毎月月初にアウトプットする。




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

2015年03月27日

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

個人作業環境を一撃セットアップ

身近なメンバーに説明する手頃な材料が欲しかったので、本エントリを書いた。

作業ノードを転々としていると、各所に作業環境を構築する回数が多くなる。作業対象が使い捨てである事が増えれば増える程、その傾向が強くなった。構築回数が多いからこそ、整理する機会に恵まれていたとも言う。その結果、今ではログイン後に下記コマンド1行を実行するだけだ。

$ curl -fSkL https://raw.githubusercontent.com/hansode/env-bootstrap/master/build-personal-env.sh | bash

build-personal-env.shの処理を掘り下げて行く。

build-personal-env.sh 処理概要

  1. mkdir -p ${HOME}/repos/git/github.com
  2. hansode/dotfiles${HOME}/repos/git/github.com/に配置
    1. cd ${HOME}/repos/git/github.com/ && make
    2. make 実行により、自分好みのdotfilesが配置・セットアップされる

dotfilesdotfileだけを管理し、env-bootstrapdotfilesをセットアップする。dotfilesにセットアップスクリプトを置いても良いが、役割分担を明確にする為にも別プロジェクトで管理している。今(2015/03/27現在)は、たまたまdotfilesしか扱ってないが、他のプロジェクトを扱いたい場合は、今の様に役割分担してる方が柔軟な管理が可能。かつては別プロジェクトを扱っていた経緯がある。

dotfilesが環境を判定

作業対象は複数あり、プラットフォーム毎に必要なdotfileが異なって来る。

  • Cygwin 1.7 / Windows 8.1
  • MacOS 10.10 (Yosemite)
  • Raspbian 7.6 (Wheezy)
  • Fedora release 20 (Heisenbug)
  • CentOS-6.6/6.5/6.4
  • CentOS-7.0.1406

例えばCygwin環境にはDropboxをインストールしているので、Cygwinのホームディレクトリからアクセスしやすいようにしている。また、CygwinとMacOSでは、Vagrantを扱う事があるので、Vagrant環境を整理している。

自身の${HOME}構造を標準化

build-personal-env.shが配置するdotfileswork/repos/git/github.com/dotfiles配下。これは自分だけのルールであり、第三者に強制されるものではない。長年の経験から程よく管理しやすい構造として辿り着いた構造は、下記の通り。

まとめ

自分が実施して来た手順を整理すると、こうなる。

  1. dotfilesを整理する
  2. dotfilesをセットアップするスクリプトを管理
  3. ${HOME}構造を標準化する
  4. 1〜3を繰り返す

自分は上記順序で整理して来たが、1〜3の順序に根拠や強制力は無い。整理出来そうな所から整理すれば良い。重要なのは、整理する事だ。

関連成果物




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

頻繁なRPMリリースサイクルを実現させる為に

rpmspecファイルの重要箇所のみ抜粋。一般的なrpmspecではReleaseタグを静的に定義する。

Release: 0.0.1%{?dist}

Wakame-vdcでは頻繁にrpmをビルドしている都合上、毎回rpmspecファイルを書き換える作業は、実に都合が悪い。可能であればリリースIDを動的に指定したい。そう言った要件を満たす為、wakame-vdc.specでは、少し工夫している。

Releaseタグを動的に指定出来れば解決する

工夫している該当箇所は、この3行。

https://github.com/axsh/wakame-vdc/blob/master/rpmbuild/SPECS/wakame-vdc.spec#L10-L12 (2015/03/27現在)

%define release_id 1.daily
%{?build_id:%define release_id %{build_id}}
Release: %{release_id}%{?dist}

コメントを添えて補足すると、

# release_idを定義。値は 1.daily
%define release_id 1.daily

# build_idが定義されている場合は、build_idの値でrelease_idを再定義
%{?build_id:%define release_id %{build_id}}

# Releaseタグの値をrelease_idの値で定義
Release: %{release_id}%{?dist}

rpmbuild実行時に--defineオプションを指定すると、マクロを定義可能だ。

$ rpmbuild -bb ./wakame-vdc.spec --define "build_id 20150318183519git1a6d5b4"

これにより、rpmspecをコミットごとに修正する事無く、頻繁にrpmをリリース可能に出来る。なお、リリースIDに関しては

で述べているので、合わせてどうぞ。

まとめ

SRPMの事を考慮すると、Releaseタグの値は固定化されている事が望ましい。しかしWakame-vdcではSRPM生成を放棄しているので、問題にはならない。少なくとも、独自RPMの道を歩んでいる限りは。




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

<committer_datetime>git<commit_hash>に辿り着くまで

Wakame-vdcOpenVNetに付与するリリースIDは、Gitのコミット履歴を基にして生成している。具体的には、

  • 20150318183519git1a6d5b4

メタ情報を含めて説明すると、

  • <committer_datetime>git<commit_hash>

この文字列を生成する手順は、下記の通り。

$ commit_hash=$(git log HEAD -n 1 --pretty=format:"%h")
$ committer_datetime=$(date --date="$(git log ${commit_hash} -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S)
$ echo ${committer_datetime}git${commit_hash}

本エントリは、何故この様にしたのかを振り返る。

先輩パッケージの幾つかは既にgitのコミット履歴を利用していた

過去に何度かバージョン番号にgit情報らしきものを含んだパッケージを見かけた事があったので、それらを参考にする事にした。CentOS6で調査してみると、RPMにおける%{Release}タグにgitの情報を含んだパッケージが存在する。その一例を列挙する。

$ rpm -qa --qf '%{NAME} %{Release}\n' | awk '$2 ~ "git"'   | sort | sed 's,.el6,,'
deltarpm 0.5.20090913git
dkms 30.git.7c3e7c5
libpcap 6.20091201git117cb5
python-deltarpm 0.5.20090913git
tcpdump 3.20090921gitdf3cb4.2
xz 0.3.beta.20091007git
xz-libs 0.3.beta.20091007git
xz-lzma-compat 0.3.beta.20091007git

これらを整理してみると、3つに分類される。

  1. 数字.<comitter_date>git
    • deltarpm 0.5.20090913git
    • python-deltarpm 0.5.20090913git
    • xz 0.3.beta.20091007git
    • xz-libs 0.3.beta.20091007git
    • xz-lzma-compat 0.3.beta.20091007git
  2. 数字.git.<commit_hash>
    • dkms 30.git.7c3e7c5
  3. 数字.<committer_date>git<commit_hash>
    • libpcap 6.20091201git117cb5
    • tcpdump 3.20090921gitdf3cb4.2

いずれも、先頭の数字の意味が良く分からない。良く分からないので削除。

  1. <comitter_date>git
  2. git.<commit_hash>
  3. <committer_date>git<commit_hash>

これらを吟味。

  1. 【却下】コミットハッシュが含まれていないので追跡し辛い
  2. 【却下】辞書順に並べた時に、新旧を判断できない
  3. 【採用】欲しい情報を含んでいる

3をそのまま採用すると、<committer_date>の場合、1日に複数回ビルドすると、どちらのbuildが古いのか・新しいのかが分かり辛い。そこで<comitter_date>ではなく<comitter_datetime>を使う事にした。

  • <committer_datetime>git<commit_hash>

コミット時刻とコミットハッシュを含んだ理想的なリリースID。

リリースIDを生成・組み立てる

1: <commit_hash>を生成

特定コミットのハッシュを取得する。

$ git log HEAD -n 1 --pretty=format:"%h"
1e1b0ec

なお、HEADの代わりにブランチ名を指定する事も可能である。

$ git log master -n 1 --pretty=format:"%h"
1e1b0ec

これによりコミットハッシュを取得出来る。

2: <committer_datetime>を生成

--date=shortを指定すると、Y-m-dで取得可能だ。

$ git log HEAD -n 1 --pretty=format:"%cd" --date=short
2015-03-25

-はパッケージマネージャの予約文字列である可能性が高いので、-を削除したい。また、Y-m-dだけでなくH:M:Sも取得したい。しかし、この2つの要望を満たす--date=xxxを、git-logがサポートしてなかった。そこで、dateコマンドと組み合せて生成する事にした。

$ date --date="$(git log HEAD -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S
20150325193037

コミット時刻を取得出来た。

3: 文字列gitを含める

参考にしたパッケージには、Gitの情報である事を明確化する為に文字列gitが含まれている。そのポリシーを拝借し、1と2を合わせる。

$ echo ${committer_datetime}git${commit_hash}

期待する文字列を生成出来る。

4: 1+2+3

3つをつなぎ合わせる。

$ commit_hash=$(git log HEAD -n 1 --pretty=format:"%h")
$ echo commit_hash=${commit_hash}
commit_hash=1e1b0ec

$ committer_datetime=$(date --date="$(git log ${commit_hash} -n 1 --pretty=format:"%cd" --date=iso)" +%Y%m%d%H%M%S)
$ echo committer_datetime=${committer_datetime}
committer_datetime=20150325193037

$ echo ${committer_datetime}git${commit_hash}
20150325193037git1e1b0ec

これにより、リリースIDを生成出来るようになった。

最後はrpmbuildと組み合せる

rpmbuildを実行する際にリリースIDをオプション指定すれば良い。Wakame-vdcの場合は、こうなる。

$ rpmbuild -bb ./wakame-vdc.spec --define "build_id 20150325193037git1e1b0ec"

build_idは標準マクロではないので、rpmspecファイルを工夫する必要がある。rpmspecの書き方は、本エントリの本題ではないので、別エントリにて。

まとめ

Wakame-vdcは、このリリースIDで約3年運用している。もしも何か不具合が生じた場合には、リリースIDに含まれているコミットハッシュから追跡可能だ。また、コミット時刻も含まれているので、どのコミットをビルドしたのが一目瞭然。今の所、凄く上手く行っている。結構おススメです。




編集

2015年03月25日

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

GitリポジトリのツリーをRPMとして手っ取り早くパッケージングしたかった。手順をまとめ、git2rpmとして実装・公開してみた。

主な特徴・制約

  • Gitリポジトリを指定して実行するとRPMが生成される
  • パッケージ名は rpm4<パッケージ名>
  • インストール先は/home/git2rpm/<パッケージ名>
  • コミット履歴をもとにバージョン番号<コミット時刻>git<コミットハッシュ>を生成

使い方

引数にGitリポジトリURIを指定するだけ。

$ git2rpm <git-repo>

git2rpm実行例

試しに https://github.com/hansode/makistrano を一撃でrpm化してみる。

1: Gitリポジトリを指定してgit2rpmを実行
$ ./git2rpm https://github.com/hansode/makistrano.git
+ repouri=https://github.com/hansode/makistrano.git
+ reponame=makistrano.git
+ reponame=makistrano
+ reponame=rpm4makistrano
+ mkdir -p /home/vagrant/rpmbuild/BUILD /home/vagrant/rpmbuild/BUILDROOT /home/vagrant/rpmbuild/RPMS /home/vagrant/rpmbuild/SOURCES /home/vagrant/rpmbuild/SPECS /home/vagrant/rpmbuild/SRPMS
+ [[ -d rpm4makistrano ]]
+ cd rpm4makistrano
+ git pull
Already up-to-date.
++ git log HEAD -n 1 --pretty=format:%h
+ git_version=2add2a4
+++ git log 2add2a4 -n 1 --pretty=format:%cd --date=iso
++ date '--date=2013-11-18 18:07:42 -0800' +%Y%m%d%H%M%S
+ git_datetime=20131119110742
+ build_id=20131119110742git2add2a4
+ cd /home/vagrant/rpmbuild/SPECS
+ cat
+ rpmbuild -bb rpm4makistrano.spec --define 'repouri https://github.com/hansode/makistrano.git' --define 'reponame rpm4makistrano' --define 'build_id 20131119110742git2add2a4'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.qpo4o6
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d rpm4makistrano-20131119110742git2add2a4 ']'
+ rm -rf rpm4makistrano-20131119110742git2add2a4
+ git clone https://github.com/hansode/makistrano.git rpm4makistrano-20131119110742git2add2a4
Initialized empty Git repository in /home/vagrant/rpmbuild/BUILD/rpm4makistrano-20131119110742git2add2a4/.git/
remote: Counting objects: 278, done.
remote: Total 278 (delta 0), reused 0 (delta 0), pack-reused 278
Receiving objects: 100% (278/278), 36.30 KiB, done.
Resolving deltas: 100% (106/106), done.
+ cd rpm4makistrano-20131119110742git2add2a4
+ :
+ cd /home/vagrant/rpmbuild/BUILD
+ cd rpm4makistrano-20131119110742git2add2a4
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.pRFBqi
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd rpm4makistrano-20131119110742git2add2a4
+ LANG=C
+ export LANG
+ unset DISPLAY
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.bbDnBu
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ '[' /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64 '!=' / ']'
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
++ dirname /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
+ mkdir -p /home/vagrant/rpmbuild/BUILDROOT
+ mkdir /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
+ cd rpm4makistrano-20131119110742git2add2a4
+ LANG=C
+ export LANG
+ unset DISPLAY
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
+ mkdir -p /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64//home/git2rpm/rpm4makistrano
++ pwd
+ rsync -aHA --exclude=.git '--exclude=.git/*' /home/vagrant/rpmbuild/BUILD/rpm4makistrano-20131119110742git2add2a4/ /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64//home/git2rpm/rpm4makistrano/
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/vagrant/rpmbuild/BUILD/rpm4makistrano-20131119110742git2add2a4
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: rpm4makistrano-20131119110742git2add2a4-1.el6.noarch
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/bash /bin/sh
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
warning: Could not canonicalize hostname: vagrant-centos6
Wrote: /home/vagrant/rpmbuild/RPMS/noarch/rpm4makistrano-20131119110742git2add2a4-1.el6.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.xqZHo1
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd rpm4makistrano-20131119110742git2add2a4
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/rpm4makistrano-20131119110742git2add2a4-1.el6.x86_64
+ exit 0

/home/vagrant/rpmbuild/RPMS/noarch/rpm4makistrano-20131119110742git2add2a4-1.el6.noarch.rpm が生成された。

  • パッケージ名はrpm4makistrano
  • バージョンは20131119110742git2add2a4
2: 生成されたrpmをインストールしてみる
$ sudo yum install --disablerepo='*' /home/vagrant/rpmbuild/RPMS/noarch/rpm4makistrano-20131119110742git2add2a4-1.el6.noarch.rpm                  Loaded plugins: fastestmirror
Setting up Install Process
Examining /home/vagrant/rpmbuild/RPMS/noarch/rpm4makistrano-20131119110742git2add2a4-1.el6.noarch.rpm: rpm4makistrano-20131119110742git2add2a4-1.el6.noarch
Marking /home/vagrant/rpmbuild/RPMS/noarch/rpm4makistrano-20131119110742git2add2a4-1.el6.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package rpm4makistrano.noarch 0:20131119110742git2add2a4-1.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================================================================================
 Package                        Arch                   Version                                         Repository                                                             Size
===================================================================================================================================================================================
Installing:
 rpm4makistrano                 noarch                 20131119110742git2add2a4-1.el6                  /rpm4makistrano-20131119110742git2add2a4-1.el6.noarch                  40 k

Transaction Summary
===================================================================================================================================================================================
Install       1 Package(s)

Total size: 40 k
Installed size: 40 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : rpm4makistrano-20131119110742git2add2a4-1.el6.noarch                                                                                                            1/1
  Verifying  : rpm4makistrano-20131119110742git2add2a4-1.el6.noarch                                                                                                            1/1

Installed:
  rpm4makistrano.noarch 0:20131119110742git2add2a4-1.el6

Complete!
3: rpmの情報を確認
$ rpm -qi rpm4makistrano
Name        : rpm4makistrano               Relocations: /home/git2rpm/rpm4makistrano
Version     : 20131119110742git2add2a4          Vendor: (none)
Release     : 1.el6                         Build Date: Mon 16 Mar 2015 06:31:31 PM JST
Install Date: Mon 16 Mar 2015 06:33:05 PM JST      Build Host: vagrant-centos6
Group       : Unspecified                   Source RPM: rpm4makistrano-20131119110742git2add2a4-1.el6.src.rpm
Size        : 41404                            License: BSD
Signature   : (none)
URL         : https://github.com/hansode/makistrano.git
Summary     : git2rpm
Description :
4: ファイルリストを確認
$ rpm -ql rpm4makistrano
/home/git2rpm/rpm4makistrano
/home/git2rpm/rpm4makistrano/.travis.yml
/home/git2rpm/rpm4makistrano/Makefile
/home/git2rpm/rpm4makistrano/README.md
/home/git2rpm/rpm4makistrano/bin
/home/git2rpm/rpm4makistrano/bin/maki
/home/git2rpm/rpm4makistrano/examples
/home/git2rpm/rpm4makistrano/examples/Makifile
/home/git2rpm/rpm4makistrano/functions
/home/git2rpm/rpm4makistrano/functions/makistrano.sh
/home/git2rpm/rpm4makistrano/test
/home/git2rpm/rpm4makistrano/test/Makefile
/home/git2rpm/rpm4makistrano/test/integration
/home/git2rpm/rpm4makistrano/test/integration/Makefile
/home/git2rpm/rpm4makistrano/test/integration/makistrano
/home/git2rpm/rpm4makistrano/test/integration/makistrano/Makefile
/home/git2rpm/rpm4makistrano/test/integration/makistrano/helper_shunit2.sh
/home/git2rpm/rpm4makistrano/test/integration/makistrano/t.makistrano_cli.sh
/home/git2rpm/rpm4makistrano/test/shunit2
/home/git2rpm/rpm4makistrano/test/unit
/home/git2rpm/rpm4makistrano/test/unit/Makefile
/home/git2rpm/rpm4makistrano/test/unit/makistrano
/home/git2rpm/rpm4makistrano/test/unit/makistrano/Makefile
/home/git2rpm/rpm4makistrano/test/unit/makistrano/helper_shunit2.sh
/home/git2rpm/rpm4makistrano/test/unit/makistrano/t.makistrano_cli.sh
/home/git2rpm/rpm4makistrano/test/unit/makistrano/t.makistrano_eval.sh
/home/git2rpm/rpm4makistrano/test/unit/makistrano/t.makistrano_load_config.sh
/home/git2rpm/rpm4makistrano/test/unit/makistrano/t.makistrano_node.sh
/home/git2rpm/rpm4makistrano/test/unit/makistrano/t.makistrano_nodes.sh

/home/git2rpm/rpm4<パッケージ名>にインストールされている事が分かる。

TODO?

機能追加は、機能不足を感じた時など、気が向いた時に。

  • パッケージ名のprefixrpm4を無効化・別名を指定出来るようにする?
  • インストール先を/home/git2rpmではないディレクトリを指定可能にする?
  • 単にファイルツリーをrpm化しているだけなので、make等のbuild手順を定義出来るようにする?
  • masterブランチだけでなく、他のブランチを指定?

機能追加すると使い辛くなりそうなので、使い辛さが残る程度が丁度良いのかも知れない。

まとめ

git2rpmを使う事により、rpmspecファイルを生成せずにrpmを一撃生成出来た。yumリポジトリと連携させると、バージョンを意識したデプロイ・管理をしやすくなるはずである。

あとがき

yumと連携しなければ、下記と大差がない。yumを使わないと意味がない。

$ git clone <git-uri> /home/git2rpm/<name>



編集

2015年03月24日

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

自作rpmの作成手順を説明する必要があった

何度か自作RPMして来たが、数年前の事であり、スクラッチから作る手順をすっかり忘れていた。今後、同じ事にならぬよう、整理と復習を兼ね、ここに書き残す。

必須項目を知るには、最小構成を知った方が良い

もしも最小構成RPM作成出来たとしたら、何が必須項目かを理解できるはずである。そこで、ファイル数の少ないツールをRPM化しながら進めて行く事にした。自作ツールhansode/makistranoが1ファイルで完結する作りなので、makistranoを使う。

いざ、自作RPMへ!

検証環境

  • CentOS release 6.6
  • rpm-build-4.8.0-37.el6.x86_64

事前準備

1: ビルド環境を構築
$ sudo yum install -y git rpm-build rpmlint
2: rpmbuild事前準備
$ mkdir -p ${HOME}/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}

rpm作成作業へ

最小構成が目的であり、美しさは求めていない。

1: rpmspecファイルを作成

検証した限りで最小のrpmspecファイルが下記の通り。

$ cd ${HOME}/rpmbuild/SPECS
$ vi makistrano.spec
Name:           makistrano
Version:        0.1.0
Release:        1%{?dist}
Summary:        makistrano
License:        BSD

%description

%prep
[ -d %{name}-%{version} ] && rm -rf %{name}-%{version}
git clone https://github.com/hansode/makistrano %{name}-%{version}
cd %{name}-%{version}
: # don't delete this line.
%setup -T -D

%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/bin
cp bin/maki $RPM_BUILD_ROOT/usr/bin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
/usr/bin/maki
%doc

%changelog

幾つかの項目を補足。

License: BSD

  • 他で流用する場合は、適切なライセンスに変更する必要あり

%prep

  • git clone https://github.com/hansode/makistrano
  • 一般的なRPMでは${HOME}/rpmbuild/SOURCE配下に事前配置するが、本rpmspecではgit cloneを利用し、手間を省いている

%install

  • bin/maki/usr/bin/makiへインストール

%files

  • /usr/bin/makiをパッケージング対象へ

2: rpmlintでrpmspecファイルの内容を確認

$ rpmlint makistrano.spec
makistrano.spec: W: no-buildroot-tag
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

もしも問題がある場合は、rpmlintが警告してくれる。

3: rpmbuildを実行

$ rpmbuild -bb makistrano.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.LhEZL4
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ '[' -d makistrano-0.1.0 ']'
+ rm -rf makistrano-0.1.0
+ git clone https://github.com/hansode/makistrano makistrano-0.1.0
Initialized empty Git repository in /home/vagrant/rpmbuild/BUILD/makistrano-0.1.0/.git/
remote: Counting objects: 278, done.
remote: Total 278 (delta 0), reused 0 (delta 0), pack-reused 278
Receiving objects: 100% (278/278), 36.30 KiB, done.
Resolving deltas: 100% (106/106), done.
+ cd makistrano-0.1.0
+ :
+ cd /home/vagrant/rpmbuild/BUILD
+ cd makistrano-0.1.0
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.MPZw45
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd makistrano-0.1.0
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.Qh0Vp7
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd makistrano-0.1.0
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/makistrano-0.1.0-1.el6.x86_64
+ mkdir -p /home/vagrant/rpmbuild/BUILDROOT/makistrano-0.1.0-1.el6.x86_64/usr/bin
+ cp bin/maki /home/vagrant/rpmbuild/BUILDROOT/makistrano-0.1.0-1.el6.x86_64/usr/bin/
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
Processing files: makistrano-0.1.0-1.el6.x86_64
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/bash
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/makistrano-0.1.0-1.el6.x86_64
warning: Could not canonicalize hostname: vagrant-centos6
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/makistrano-0.1.0-1.el6.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.6iMJEo
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd makistrano-0.1.0
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/makistrano-0.1.0-1.el6.x86_64
+ exit 0

4: 出来上がったrpmをインストールしてみる

$ sudo rpm -ivh sudo rpm -ivh ${HOME}/rpmbuild/RPMS/x86_64/makistrano-0.1.0-1.el6.x86_64.rpm
/rpmbuild/RPMS/x86_64/makistrano-0.1.0-1.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:makistrano             ########################################### [100%]

5: rpmの情報を確認

$ rpm -qi makistrano
Name        : makistrano                   Relocations: (not relocatable)
Version     : 0.1.0                             Vendor: (none)
Release     : 1.el6                         Build Date: Tue 24 Mar 2015 06:44:49 PM JST
Install Date: Tue 24 Mar 2015 06:45:18 PM JST      Build Host: vagrant-centos6
Group       : Unspecified                   Source RPM: makistrano-0.1.0-1.el6.src.rpm
Size        : 2391                             License: BSD
Signature   : (none)
Summary     : makistrano
Description :

6: ファイルリストを確認

$ rpm -ql makistrano
/usr/bin/maki
$ ls -l `rpm -ql makistrano`
-rwxr-xr-x 1 root root 2391 Mar 24 18:44 /usr/bin/maki

期待通り。

7: 削除出来る事を確認

$ sudo rpm -e makistrano
$ rpm -qi makistrano
package makistrano is not installed
$ ls -la /usr/bin/maki
ls: cannot access /usr/bin/maki: No such file or directory

後処理も問題ない。

まとめ

最小構成rpm/rpsmspecを無事に手に入れた。これにより、rpmspecに必要な項目が何であるかが判明した。もしも流用したい場合は、パッケージ名とGitリポジトリを変更すれば、直ぐに使える。簡易的なパッケージング用途には十分使えるはずである。

参考文献




編集

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)Jenkins 

2015年03月01日

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

ライブドアブログ(livedoor Blog)は、Markdownで書けない

この内容には背景説明が必要だ。

背景1: Markdown生活

GitHubを本格利用し始めた4年前辺りから、Markdown形式でドキュメントを書いている。Markdownは実に単純な形式・規則であり、気持ちよく執筆作業を行える。そして、すっかりMarkdownに慣れてしまった身体では、HTMLを書くのは苦行に近い...。本来書きたい事を書く為の時間だけでなく、HTMLによる整形が、執筆作業の邪魔をする。

背景2: ライブドアブログ(livedoor Blog)を本ブログでは利用している

記事投稿画面のエディタ形式を変える - livedoor Blog ヘルプセンターより(2015/03/01現在):

記事投稿画面のエディタ部分(本文を入力する部分)は、デフォルトでは記事の見た目そのままに近い表示がされる「HTMLエディタ」になっていますが、右上の「HTMLタグ編集」をクリックすると、HTMLタグを直接編集できる画面に切り替えることができます。

エディタの種類は、HTMLかシンプルの2種類。Markdownは対応してないのである。そのうち対応してくれえるのかも知れない。

背景3: 移行か、継続か

Markdown対応ブログサービスへの移行を考えた事もある。サービス移行先候補を使ってみると、無料プラン・有料プランに限らず、上手くURIを引き継げないなどの課題が出て来た。どうにかして・思い切って移行するか、それとも、ライブドアブログを継続利用するか...。検討した結果、移行によるデメリットが大きかったので、ライブドアブログ継続利用に落ち着いた。しかしながら、相変わらずMarkdown形式で書きたかったのである。

どうにかしてMarkdownで書く

MarkdownをHTMLに変換できさえすれば、ほぼ解決する。幾つか試した中で辿り着いたのが、以下の執筆から出稿までのフロー。

  1. Dillingerを使う
    1. Markdownで記述
    2. HTML形式で出力
  2. 出力されたHTMLソースを表示
  3. <body></body> に挟まれた領域をコピー
  4. コピーした内容を、livedoorブログの記事領域に貼り付けて投稿

それぞれの手順内容を補足して行く。

手順1: Dillingerを使いMarkdownで記述しHTMLで出力

Dillingerは、無料で利用可能(2015/03/01現在)。アクセスすると直ぐに利用可能で、以下の様な編集画面が表示される。

  • 左ペイン: Markdown記述領域
  • 右ペイン: プレビュー内容

基本的には左ペインにMarkdown形式で記述して行く。記述した内容は随時プレビューされるので、レンダリング後の状態と、Markdown的に間違いがあるのかどうかを、同時に確認出来る。

手順2: 出力されたHTMLソースを表示

切りの良い所まで書けたら、

  1. メニューバーのEXPORT ASをクリックして開き、
  2. HTMLを選択すると、
  3. HTMLが自動的にダウンロードされる
手順3: <body></body> に挟まれた領域をコピー

  1. ダウンロードされたHTMLをエディタ等で開き、
  2. <body>...</body>で挟まれた領域を選択・コピー
手順4: コピーした内容を、livedoorブログの記事領域に貼り付けて投稿

ここまで来ると、今までのHTMLエディタによる操作と同じである。仮に誤字脱字を見つけた場合は、手順1へ戻り、同じ手順を繰り返す。こうする事によりMakdown対応してないサービスと上手く付き合って行ける。

おまけ: MarkdownをHTMLへ変換するツールの選択

今回紹介した内容ではDillingerだけで完結しているが、自分が一番愛用しているMarkdownエディタサービスは StackEditだ。

このStackeditもMarkdownからHTMLを出力可能だ。しかしながら、StackEditが出力したHTMLには着色やレイアウト用途の余計なHTML要素が含まれている。この余計な要素は、シンプルなHTMLを期待するツールとの相性が悪い。

今回紹介したDillingerでは、シンプルなHTMLを出力してくれる。Markdownに対応してないサービスとの連携に注目した場合は、Dillingerが良い訳である。

あとがき

本エントリでは、Markdownファイル管理については触れていない。例えばMarkdownエディタが持ち合わせている管理機能を使って管理すれば良い。参考ままでに、自分は専用Gitリポジトリで管理している。この管理方法に関する内容は本エントリの主題から逸れるので、触れないでおく。




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

「変態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)Jenkins