2017年10月19日木曜日

Jenkins の API を curl でサラッと試してみた

概要

久しぶりに Jenkins のリモート API に触れたので使い方などをまとめておきます

環境

  • macOS X 10.12.6
  • Jenkins 2.60.3

事前作業

今回は docker 上で動かしました
Jenkins を動かすのはどこでも問題ないです
一番初めのテンポラリーパスワードによる認証とプラグインのインストール、ユーザの作成までは済ませておいてください

今回は root という名前のユーザを作成した体で勧めます

CSRF の無効化

Jenkins -> Jenkins の管理 -> グローバルセキュリティ設定 -> CSRF対策

のチェックをオフにして Apply

API トークンの取得

root -> 設定 -> API トークン -> API トークンの表示

ジョブの作成

適当に作成してください
API でも良いですが面倒なので手動で作成しました
ちなみに API で作成した場合は謎の XML ファイルを作成して FORM として POST すれば作成できます -> 参考

いろいろコールしてみる

つらつらと curl でコールしてみました
ちなみに全部 POST で送っていますが GET でも OK です

ジョブの一覧の取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/api/json?tree=jobs'

ちなみに件数を指定して取得することもできます

curl --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/api/json?tree=jobs%5Bname%5D%7B0%2C1%7D'

URL にするとこんなフォーマットです
curl でコールするときは URL エンコードする必要があるので上記のようになっています

http://localhost:8080/api/json?tree=jobs[name]{0,1}

ジョブのビルド

curl -v -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/build'

ここでポイントですがレスポンスの Location ヘッダにキューの情報が付与されています
ここに番号が振られておりそれがビルドの番号にもなるので、実行したビルドの結果を追いたい場合には Location ヘッダの情報を使用してください

Location: http://localhost:8080/queue/item/3/

最後に成功したビルドの結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/lastSuccessfulBuild/api/json?pretty=true'

最後に成功したビルドのコンソール結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/lastSuccessfulBuild/logText/progressiveText?start=0'

ビルド番号を指定してビルドの結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/api/json?pretty=true'

ビルド番号を指定してビルドのコンソール結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/logText/progressiveText?start=0'

ビルド番号を指定してビルドのコンソール結果を HTML で取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/logText/progressiveHtml?start=0'

Tips

トークンを使わないでも API をコールすることができます
トークンの箇所に作成したユーザのパスワードを入力しても API をコールすることができます

また、良くないですがそもそも認証情報付与するの面倒くさいという場合はグローバルセキュリティ設定から「セキュリティを有効化」のチェックをオフにすればトークンもパスワードもなしで API をコールできます

最後に

Jenkins のリモート API を試してみました
基本は UI で操作していて、その操作を API として使いたいときに URL の最後に /api を付け加えてやるとその操作の API リファレンスがいろいろと表示されるのでそこでやり方を確認するといいと思います

コンソールの結果が平文 or HTML じゃなくてそれっぽい JSON とかに置き換えできれば Jenkins を使って簡単な API サーバが作れそうな気がしました
プラグインとか探せばあるのかな、、、

2017年10月18日水曜日

packer + WindowsServer2016 で vmxnet3 を使う

概要

前回 packer + esxi で WindowsServer2016 を自動構築してみました
しかし Windows2016 はデフォルトでネットワークドライバに vmxnet3 が使えません
packer ビルド時にドライバをインストールすれば使用することができたのでその方法を紹介します

環境

  • ESXi 6.0.0 (Build 3620759)
  • Ubuntu 16.0.4
  • packer 1.0.4

ドライバファイル

こちらです (GoogleDrive なので wget などはできません、手動でダウンロードしてサーバにアップロードしてください)
この中に inf ファイルが含まれています
WindowsServer2016 はこのファイルを自動実行してくれます
そうすることでビルド時にドライバを自動インストールします

テンプレートの修正

ほぼ同じなので一部だけ紹介します
ダウンロードした zip ファイルを展開して drivers 配下に配置します
そしてテンプレートファイル内の floppy_files に含めるようにします

zip ファイルのまま drivers 配下においても inf ファイルが見つからず自動で実行されないので、ちゃんと解凍したファイルたち (.dll や .inf ファイルなど) を drivers 配下に配置してください

"floppy_files": [
    "answer_files/Autounattend.xml",
    "drivers/",
    "scripts/winrm.ps1"
]

動作確認

これでビルドしてみましょう
もちろん Autounattend.xml や winrm.ps1 などもちゃんと配置して実行してください
うまくいくと vmxnet3 のドライバで動作する WindowsServer2016 が作成されると思います

最後に

packer + esxi + WindowsServer2016 で vmxnet3 ドライバを使用する方法を紹介しました
ドライバは以下の参考サイトで紹介されているものをそのまま使用しています
なくなっても問題ないようにキャッシュとして残しているだけなので、Github から持ってきても OK です
おそらく同様にストレージドライバなどをインストールすれば PVSCSI などを利用することもできると思います

参考サイト

2017年10月17日火曜日

packer を使って ESXi 上で WindowsServer2016 を自動構築してみた

概要

前回 Virtualbox 上で Windows Server 2016 の自動構築を行いました
今回は VMware ESXi 上でビルドして vmx + vmdk ファイルを作成してみたいと思います

環境

  • ESXi 6.0.0 (Build 3620759)
  • Ubuntu 16.0.4
  • packer 1.0.4

事前準備

Windows Server 2016 の ISO は事前にダウンロードしておいてください
過去にダウンロードの仕方を紹介しているので参考にしてください
packer を実行するマシン (今回であれば Ubuntu を使っています) 上に配置してください

前回同様 Windows の自動構築の仕組みは Autounattend.xml を使います
これは前回使用したものをそのまま流用できます

Autounattend.xml は Windows の OS 自動インストールを行うための仕組みなので Virtualbox であろうが ESXi であろうが同じものが使えて当然です
そして、内部で使用している WinRM を有効にする Powershell スクリプトも前回と同じものを流用します

テンプレートファイルの準備

ESXi 上で実行するテンプレートファイルを新規で作成します

  • win2016.json
{
    "builders": [{
        "type": "vmware-iso",
        "vm_name": "win2016",
        "guest_os_type": "windows8srv-64",
        "vmx_data": {
            "gui.fitguestusingnativedisplayresolution": "FALSE",
            "memsize": "2048",
            "numvcpus": "2",
            "virtualHW.version": "10",
            "scsi0.virtualDev": "lsisas1068",
            "ethernet0.networkName": "VM Network",
            "ethernet0.virtualDev": "e1000",
            "ethernet0.present": "TRUE",
            "ethernet0.connectionType": "custom",
            "ethernet0.vnet": "vmnet8",
            "ethernet0.startConnected": "TRUE"
        },
        "disk_size": 81920,
        "disk_type_id": "thin",
        "remote_type": "esx5",
        "remote_host": "192.168.100.101",
        "remote_datastore": "datastore12",
        "remote_username": "esxi_user",
        "remote_password": "esxi_password",
        "headless": "false",
        "iso_url": "/vol/win2016.ISO",
        "iso_checksum": "18a4f00a675b0338f3c7c93c4f131beb",
        "iso_checksum_type": "none",
        "communicator": "winrm",
        "winrm_username": "winuser1",
        "winrm_password": "winpass123",
        "winrm_timeout": "12h",
        "floppy_files": [
            "answer_files/Autounattend.xml",
            "scripts/winrm.ps1"
        ]
    }]
}

VirtualBox 時のテンプレートファイルと比較してポイントをいくつか説明します

まず type は vmware-iso を指定します
こうすることで VMware 環境 (今回は ESXi) 上でビルドを行うことができます
ESXi の情報は remote_type, remote_host, remote_datastore, remote_username, remote_password で設定しています

guest_os_type は Windodws8 のものを使用しています
とりあえずこれでも動作します

vmx_data で VM の構成を設定します
ここが一番のポイントです
まず scsi0.virtualDevlsisas1068 を指定してください
これは LSI Logic SAS というドライバなのですが、これでないとハードディスクをうまく認識することができません
これ以外のドライバを使いたい場合は別途ドライバをインストールする必要があります
次に ethernet0.virtualDeve1000 を指定してください
これも e1000 にしないとネットワークアダプタがうまく認識されず IP アドレスが取得できません
IP アドレスが取得できないと WinRM で接続もできないためビルドが失敗します

あとは "iso_checksum_type": "none" ですが、こうすることで ISO のアップロードを毎回行わないようにします
VirtualBox 時は md5 で指定していたのですが、md5 にするとなぜか ESXi に ISO を毎回アップロードしてしまいます
本来であればチェックサムの値が同じであれば既にアップロードしてある ESXi のデータストアにキャッシュされた ISO を使うのですが、なぜか使ってくれません
なので、ワークアラウンド的に none を指定しています

それ以外の項目に関しては前回の VirtualBox で使用したテンプレートとほぼ同じです

実行する

  • packer build win2016.json

で実行しましょう
問題なくビルドが完了すると指定したデータストア上に「output-vmware-iso」というディレクトリが作成されその配下に vmx ファイルと vmdk ファイルが保存されます
packer_vmware_win2016.jpg

今回のテンプレートの設定だとビルドが完了するとサーバは削除されてしまいます

最後に

packer を使って ESXi 上で Windows2016 をビルドしてみました
ハマったのは使用するドライバをテンプレートで指定する箇所で vmxnet3 や VMware Paravirtual (PVSCSI) を使用するとうまくデバイスが認識されませんでした

少し上記で述べましたが vmxnet3 にしていると Windows がネットワークアダプタを認識できず WinRM を使って packer から接続できずにビルドエラーとなります

ちなみに PVSCSI にしていると OS インストール時に Windows could not apply the unattend answer file's <DiskConfiguration> setting というエラーが発生します
うまくハードディスクが認識されないためパーティションの作成と設定に失敗しています
packer_vmware_win2016_2.jpg

この問題も頑張れば解決することができるらしいので解決できたらその方法を紹介したいと思います

2017年10月13日金曜日

dep で SSH な git リポジトリを使う方法

概要

dep init するときにリポジトリにアクセスするのですが、デフォルトだと https でアクセスしに行きます
もし https でアクセスできないと以下のエラーとなり init に失敗します

emote repository at https://your-domain-git-repo.local/project/repository.git does not exist, or is inaccessible: : exit status 128

こんな場合に SSH + git で対象にリポジトリにアクセスする方法を紹介します

環境

  • Ubuntu 16.04.2
  • git 2.7.4
  • golang 1.8.4
  • dep devel

対応方法

以下のコマンドを実行します

  • git config --global url.git://your-domain-git-repo.local/.insteadOf https://your-domain-git-repo.local/

これで「your-domain-git-repo.local」には https ではなく SSH で接続するようになります
うまくいかない場合は

  • git config --global url.git@your-domain-git-repo.local/.insteadOf https://your-domain-git-repo.local/

も試してみてください

ちなみに global な .gitconfig を直接編集したい場合は ~/.gitconfig にあります

参考サイト

2017年10月12日木曜日

golang 純正のパッケージ管理ツール「dep」を使ってみた

概要

golang 純正のパッケージ管理ツールである dep を使ってみました
ruby で言うところの gem、python で言うところの pip という感じでしょうか

環境

  • macOS X 10.12.6
  • golang 1.9.1
  • dep devel

dep のインストール

  • brew install dep

で今回はインストールしました
homebrew が使えない場合は go get でもインストール可能です

  • go get -u github.com/golang/dep/cmd/dep

GOPATH 配下に作業ディレクトリを作成する

今回 GOPATH は /Users/hawksnowlog/go/ とします
この配下に作業ディレクトリを作成します

  • mkdir -p /Users/hawksnowlog/go/src/github.com/hawksnowlog/dep-test
  • cd /Users/hawksnowlog/go/src/github.com/hawksnowlog/dep-test

初期化

  • dep init

とすると dep 関連のファイルが自動で生成されます

  • Gopkg.lock
  • Gopkg.toml
  • vendor/

Gopkg.toml ファイルに依存パッケージを記載していきます

テスト用のコード

以下を使います
logrus というロギング用のライブラリを使っています

  • vim main.go
package main

import (
        log "github.com/Sirupsen/logrus"
)

func main() {
        log.WithFields(log.Fields{
                "key": "value",
        }).Info("logrus test")
}

依存パッケージを追加する

今回はとりあえず 1 つだけ追加してみます

  • dep ensure -add github.com/Sirupsen/logrus

Gopkg.toml に以下のように定義が追加されていると思います

  • cat Gopkg.toml
[[constraint]]
  name = "github.com/Sirupsen/logrus"
  version = "1.0.3"

パッケージをインストールする

  • dep ensure

と実行すると Gopkg.toml に記載されたパッケージが vendor/ 配下にインストールされます
確認は dep status で確認できます

  • dep status
PROJECT                     CONSTRAINT  VERSION        REVISION  LATEST   PKGS USED
github.com/Sirupsen/logrus  ^1.0.3      v1.0.3         f006c2a   f006c2a  1  
golang.org/x/crypto         *           branch master  9419663   9419663  1  
golang.org/x/sys            *           branch master  ebfc5b4   ebfc5b4  2  

簡単です

動作確認

  • go build
  • go install
  • dep-test

と実行すると以下のようにログが表示されると思います

INFO[0000] logrus test                                   key=value

追加してもコード内で使用されていないと vendor/ 配下には配置されない

試しに使っていないパッケージを追加してみます

  • dep ensure -add github.com/astaxie/beego

まず使っていないパッケージを追加しようとすると警告が出ます

"github.com/astaxie/beego" is not imported by your project, and has been temporarily added to Gopkg.lock and vendor/.
If you run "dep ensure" again before actually importing it, it will disappear from Gopkg.lock and vendor/.

ただ、Gopkg.toml には記載されています

[[constraint]]
  name = "github.com/astaxie/beego"
  version = "1.9.0"

この状態でインストールして確認してみましょう

  • dep ensure
  • dep status

しても先ほどと結果は変わらないです
このように dep はコード内で使用しているパッケージだけを vendor` 配下にインストールしてくれるようです

ちなみに dep で追加したけど使用されていないパッケージは

  • /Users/hawksnowlog/go/pkg/dep/sources/https---github.com-astaxie-beego/

配下にあるようです

最後に

go 純正のパッケージ管理ツール dep を使ってみました
昔は toml ファイルではなく Json ファイルで管理していたようです
dep を使用するには golang のバージョンも 1.8 以上が必要になります

dep は import で参照しているライブラリを管理しているリポジトリにアクセスできる必要があります
今回は Github 上で公開されているライブラリだったので特に問題ないですが例えばプライベートなリポジトリや IP などでアクセス制限をしているライブラリに関しては dep を実行するサーバからもアクセスできる必要があるのでご注いください

参考サイト

2017年10月11日水曜日

VMware VIC の 1.2.1 を使ってみた

概要

VMware VIC の 1.2.1 GA がリリースされていたので試してみました
そのうち正式版がリリースされると思うのでそれを待っても良かったのですが触ってみました

環境

  • vic-machine v.1.2.1-13858-c3db65f
  • docker 17.03.0-ce
  • Ubuntu 16.04
  • vCenter Server 5.5.0

vic-machine コマンドのインストール

  • wget https://storage.googleapis.com/vic-engine-releases/vic_1.2.1.tar.gz

各種コマンド検証

create

./vic-machine-linux create \
--target 192.168.100.101/dc \
--user "vc-user" \
--password "vc-pass" \
--compute-resource cluster \
--image-store datastore2 \
--bridge-network "dvs-for-vch" \
--public-network "VM Network" \
--no-tlsverify --force

特に追加になってそうなオプションはなさそう
--name を指定しないと「virtual-container-host」という名前で vApp が作成され、その配下に VM が作成されます

delete

./vic-machine-linux delete \
--target 192.168.100.101/dc \
--user "vc-user" \
--password "vc-pass" \
--compute-resource cluster \
--name virtual-container-host \
--thumbprint "37:1D:..."

こちらも特になし
--name オプションを指定しないと「virtual-container-host」を削除しにいきます

ls

./vic-machine-linux ls \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--thumbprint "37:1D:..."

こちらも特になし

inspect

./vic-machine-linux inspect -\
-target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--thumbprint "37:1D:..."

--name の指定が必須ではなくなったようです
指定しない場合は「virtual-container-host」に対して実行します

また今回からか不明なのですが ./vic-machine-linux inspect config というコマンドが追加されており、これを使うと create 時のオプションを確認することができます

debug

./vic-machine-linux debug \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--enable-ssh --rootpw password \
--thumbprint "37:1D:..."

こちらも特になし
--name がない場合は「virtual-container-host」に対して実行します

update

./vic-machine-linux update firewall \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--deny \
--thumbprint "37:1D:..."

こちらも特になし
firewall しか操作できないのとこのコマンドは ESXi に対して実行するコマンドなのでいろいろと変更したほうが良いと思っているんですが変わらないですね、、、、
--deny--allow にすることもできます

upgrade

./vic-machine-linux upgrade \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--name virtual-container-host \
--appliance-iso ./appliance.iso \
--bootstrap-iso ./bootstrap.iso \
--thumbprint "37:1D:..."

今回は 1.1.1 -> 1.2.1 でやってみましたが問題なく行えました
ping を投げ続けてみましたが切断っぽい挙動が 2 回ほどありました

64 bytes from 192.168.200.100: icmp_seq=37 ttl=64 time=0.833 ms
64 bytes from 192.168.200.100: icmp_seq=38 ttl=64 time=17.0 ms
64 bytes from 192.168.200.100: icmp_seq=39 ttl=64 time=0.223 ms
64 bytes from 192.168.200.100: icmp_seq=40 ttl=64 time=0.301 ms
64 bytes from 192.168.200.100: icmp_seq=41 ttl=64 time=0.296 ms
64 bytes from 192.168.200.100: icmp_seq=42 ttl=64 time=0.318 ms
64 bytes from 192.168.200.100: icmp_seq=43 ttl=64 time=0.331 ms
64 bytes from 192.168.200.100: icmp_seq=44 ttl=64 time=8.29 ms
64 bytes from 192.168.200.100: icmp_seq=45 ttl=64 time=0.251 ms

今回は検証していませんが 0.8 や 0.9 から 1.2.1 に upgrade できるのかも気になりました

configure

おそらく新規で追加になったコマンドです
これで作成後の VCH に対していろいろと変更を入れられるようになりました

./vic-machine-linux configure \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--ops-user administrator@vsphere.local \
--ops-password adminpass \
--thumbprint "37:1D:..."

ops-user と ops-password を変更します
このユーザとパスワードを使って VCH から vCenter に対して API を発行してコンテナ VM を作成します

./vic-machine-linux configure \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--volume-store datastore2/directory:label \
--thumbprint "37:1D:..."

volume-store を追加します
ここで指定したvolume-store 上に docker volume で作成したデータが作成されます

./vic-machine-linux configure \
--target "192.168.100.101/dc" \
--user "vc-user" \
--password "vc-pass" \
--compute-resource "cluster" \
--dns-server 8.8.8.8 \
--thumbprint "37:1D:..."

VCH 上に DNS サーバを変更します
デフォルトだと public-network 上にある DHCP から教えてもらえる DNS が設定されています
それ以外にしたい場合は dns-server オプションで変更できます

他にも

  • 証明書の更新
  • レジストリの設定を変更
  • コンテナ専用ネットワークの変更
  • VCH から外に出るときのプロキシの設定
  • ログレベルの変更
  • メモリとCPU のアロケートサイズの変更

などができたりします
詳しくは configure --help してみると良いと思います

その他

  • version
  • help

docker コマンド検証

一番の特徴は exec が使えるようになっている点です

  • docker -H 192.168.200.100:2375 exec -it 7f4398f4c2d9 /bin/bash

それ以外のコマンドに関してはこれまで通り使えます
docker-compose も対応しています

  • docker-compose -H 192.168.200.100:2375 up -d

当然ですが、イメージは Docker hub で公開していなければありません (registry の設定を VCH にしていれば別)

ただ、swarm コマンドに現在もサポートされていません
おそらく今後のバージョンでも swarm はサポートされないと思います

最後に

VIC の 1.2.1 を試してみました
基本的なことしか試していないのですべてのエンハンス内容を網羅しているわけではありませんのでご注意を

それでも exec が使えるようになっていたり作成後の VCH に対して変更を加えられている点は嬉しいエンハンスかなと思います

個人的には vic-machine-linux コマンドの方法で VCH の操作ができるようになると嬉しいなと思いました (API)

参考サイト

2017年10月10日火曜日

MailClark 使ってみた

概要

前回 Slack の無料プランで slackbot を使ってメールの通知を受け取る方法を紹介しました
直接コメントがあったのですが MailClark という便利なアプリがあるとのことなので使ってみました

環境

  • macOS X 10.12.6
  • Slack App 2.8.0

MailClark アプリの追加

まずアプリを追加します
https://mailclark.ai/ にアクセスして「Add to Slack」を選択します
mailclark0.png

するとチームに対してアプリを追加する画面になるのでアプリに与える権限を確認して「Authorize」を選択します
mailclark1.png

すると Slack App 側に MailClark アプリから追加されたよという通知が来ます
mailclark2.png

とりあえずこれでアプリの追加は完了です

メールアドレスを取得する

次に MailClark 専用の転送アドレスを取得します
先ほどの画面でプルダウンにはチャネルが選択できるようになっています
まず、MailClark アプリを追加したいチャネルを選択しましょう (今回は #general を選択しました)

するとチャネル側に MailClark が追加されたよという通知が届きます
mailclark3.png

そして「Email」「Twitter」「Facebook」と並んでいるボタンから「Email」を選択しましょう
すると「general@team-kaka.mailclark.ai」というアドレスが払い出されます
このメールアドレスのフォーマットは「チャネル名@チーム名.mailclark.ai」になります

動作確認

そのまま「Receive a test email」を選択してみましょう
先ほど発行されたアドレスにテストメールが送信されチャネルにもメールの通知が届くと思います
mailclark4.png

ちなみに払い出されたアドレスに対して Gmail から送信してみたところ問題なく通知が届きました
mailclark5.png

最後に

Slack でメール通知を受け取れる MailClark を使ってみました

そのまま Slack App 上で返信することもでき「Reply」を選択すると対話形式でメールの返信を行うことができます
無料でここまで使えるのはかなり便利かなと思います

Incomming Web Hook などとは違い Integration ではなくアプリになります
権限などを与える必要がありますがそこまで気にならないと思います