ようへいの日々精進XP

よかろうもん

2016 年 07 月 03 月（日）

日々

tl;dr

うっかりしていたら 7 月になっていた。

朝

そういうことなのかと納得。

  • 暑くならないうちにジョギングに行ったけど暑かった

昼

  • 遅い朝ごはんを食べる
  • 朝ごはん後、本を読もうとソファーに横になったら stop インスタンス（昼寝）してた
  • 覚醒してジョギングシューズを買いに行くが、在庫が無かったので取り寄せ
  • イオンモール香椎浜に車で向かう途中、道路を逆走してコンビニに入っていく BMW が怖かった
  • イオンモール香椎浜で 31 アイスクリームを食べる（ダブルを注文したらトリプルというサービスを享受）

夜

  • ハッカソン的なイベントに参加予定なので、一緒に参加するチームメンバーと会話
  • ソファーでダラダラ

〆

  • 福岡で車を運転する際はホントに気をつけた方が良い

Infrataster の DNS プラグインメモ

infrataster 超メモ 雑なメモ

tl;dr

加齢と共に目視チェックが辛くなってきた年寄りインフラエンジニアには Infrataster がうってつけだと思って、Infrataster の DNS プラグインを使ってみたのでメモ。

Infrataster と Infrataster の DNS プラグイン

memo

試した環境

% sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G19a

% bundle exec gem list | grep infrataster
infrataster (0.3.2)
infrataster-plugin-dns (0.0.2)

準備

こちらを参考にさせて頂いて準備。

  • Gemfile
source 'https://rubygems.org'
gem 'infrataster-plugin-dns'
  • bundle install
bundle install --path vendor/bundle
  • spec/spec_helper.rb
require "infrataster/rspec"
require "infrataster-plugin-dns"

Infrataster::Server.define(
  :dns01,
  "8.8.8.8"
)

Infrataster::Server.define(
  :dns02,
  "8.8.4.4"
)

spec ファイル

  • spec/inokara-com_spec.rb
require "spec_helper"

%w(dns01 dns02).each do |dns|

  # こんな書き方するのが正しいのか判らないけど
  describe server(dns.to_sym) do
    describe dns("inokara.com") do
      it { is_expected.to have_dns.with_type("NS").and_domainname(/dns.ne.jp/) }
    end

    %w(
      kome.inokara.com
    ).each do |domain|
      describe dns(domain) do
        it { is_expected.to have_entry.with_type("CNAME").and_domainname(/s3-website-ap-northeast-1/) }
      end
    end
  end

end
  • spec/test-inokara-com_spec.rb
require "spec_helper"

%w(dns01 dns02).each do |dns|

  # こんな書き方するのが正しいのか判らないけど
  describe server(dns.to_sym) do
    describe dns("test.inokara.com") do
      it { is_expected.to have_dns.with_type("NS").and_domainname(/awsdns/) }
    end
 
    %w(
      pm25.test.inokara.com
    ).each do |domain|
      describe dns(domain) do
        it { is_expected.to have_entry.with_type("A").and_address(/54.231/) }
      end
    end
  end

end

テスト

  • run
bundle exec rspec spec
  • output
server 'dns01'
  dns 'inokara.com'
    should have the correct dns entries with {:type=>"NS", :domainname=>/dns.ne.jp/}
  dns 'kome.inokara.com'
    should have the correct dns entries with {:type=>"CNAME", :domainname=>/s3-website-ap-northeast-1/}

server 'dns02'
  dns 'inokara.com'
    should have the correct dns entries with {:type=>"NS", :domainname=>/dns.ne.jp/}
  dns 'kome.inokara.com'
    should have the correct dns entries with {:type=>"CNAME", :domainname=>/s3-website-ap-northeast-1/}

server 'dns01'
  dns 'test.inokara.com'
    should have the correct dns entries with {:type=>"NS", :domainname=>/awsdns/}
  dns 'pm25.test.inokara.com'
    should have the correct dns entries with {:type=>"A", :address=>/54.231/}

server 'dns02'
  dns 'test.inokara.com'
    should have the correct dns entries with {:type=>"NS", :domainname=>/awsdns/}
  dns 'pm25.test.inokara.com'
    should have the correct dns entries with {:type=>"A", :address=>/54.231/}

Finished in 0.59681 seconds (files took 1.07 seconds to load)
8 examples, 0 failures

いい感じ。

ということで

DNS 移行時際のテスト等に非常に有効だと思う。また、プロジェクト終盤に疲弊した状態にはこのような（シェルスクリプトだってイイと思う）機械的な確認の方が安全なのは言うまでも無い。特に自分のような年寄りが関わっている場合にはなおさら。

素敵なインフラテストライフを。

Jenkins CLI で Jenkins プラグインをインストールしたメモ

jenkins 雑なメモ

tl;dr

Jenkins の練習していたら CLI で操作出来るとのことなので、Jenkins プラグインを CLI 利用してインストールしてみたメモ。

メモ

試した環境

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty

$ java -jar jenkins-cli.jar -s http://localhost:8080 version                                                                                                               
1.651.3

参考

CLI をダウンロード

wget http://localhost:8080/jnlpJars/jenkins-cli.jar

ヘルプ

java -jar jenkins-cli.jar -s http://localhost:8080 help

以下のように出力される。

  add-job-to-view
    Adds jobs to view.
  build
    Builds a job, and optionally waits until its completion.
  cancel-quiet-down
    Cancel the effect of the "quiet-down" command.
  clear-queue
    Clears the build queue.
  connect-node
    Reconnect to a node.
  console
    Retrieves console output of a build.
  copy-job
    Copies a job.

(snip)

  update-view
    Updates the view definition XML from stdin. The opposite of the get-view command.
  version
    Outputs the current version.
  wait-node-offline
    Wait for a node to become offline.
  wait-node-online
    Wait for a node to become online.
  who-am-i
    Reports your credential and permissions.

前後してしまうが、CLI は以下のように実行する。

java -jar jenkins-cli.jar [-s JENKINS_URL] command [options...] [arguments...]

プラグインのインストール

インストールしたいプラグイン。

以下のように実行する。

java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin github
java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin build-pipeline-plugin
java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin docker-build-publish

尚、引数として指定するプラグインの名前は Plugins ページから辿れる個々のプラグインページで確認するプラグイン ID を指定する。

f:id:inokara:20160702085300p:plain

プラグインのインストール後は Jenkins プロセスを再起動して設定を反映させる。

プラグインで何が出来そうか

適当に利用出来るオプションを叩いてみた。

  • バージョンを確認
$ java -jar jenkins-cli.jar -s http://localhost:8080 version
1.651.3
  • ジョブの一覧を取得
$ java -jar jenkins-cli.jar -s http://localhost:8080 list-jobs
Docker_Build_Push
Serverspec_Handson
  • ジョブの詳細を取得
$ java -jar jenkins-cli.jar -s http://localhost:8080 get-job Docker_Build_Push

以下のように出力される。

<?xml version='1.0' encoding='UTF-8'?>
<project>
  <actions/>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties/>
  <scm class="hudson.scm.NullSCM"/>
  <canRoam>true</canRoam>
  <disabled>false</disabled>
  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
  <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
  <triggers/>
  <concurrentBuild>false</concurrentBuild>
  <builders>

(snip)

  </builders>
  <publishers/>
  <buildWrappers/>
</project>
  • Jenkins の再起動
$ java -jar jenkins-cli.jar -s http://localhost:8080 restart

セキュアにアクセス

あくまでも試してみた感じだと Jenkins CLI でセキュアに Jenkins にアクセスしたい場合には以下を設定したほうが良さそう。

  • セキュリティを有効化（グローバルセキュリティの設定）
  • アクセス制御で「ユーザー情報」を環境に応じて設定（今回は「Jenkins のユーザーデータベース」を選択した）
  • 同じくアクセス制御の「権限管理」において「ログイン済みユーザーに許可」を選択

尚、上記の設定を行った場合、Jenkins のジョブの詳細（get-job コマンド）等は以下のように利用出来なくなる。

$ java -jar jenkins-cli.jar -s http://localhost:8080 get-job Docker_Build_Push

ERROR: anonymous is missing the Job/ExtendedRead permission

これを解決するには Jenkins に Jenkins CLI を実行するユーザーの公開鍵を Jenkins 上のユーザーに登録することで利用出来るようになる。

f:id:inokara:20160702085019p:plain

上記を設定した後に get-job コマンドを実行すると以下のようにジョブの詳細を確認することが出来る。

$ java -jar jenkins-cli.jar -s http://localhost:8080 get-job Docker_Build_Push
<?xml version='1.0' encoding='UTF-8'?>
<project>
  <actions/>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties/>
  <scm class="hudson.scm.NullSCM"/>
  <canRoam>true</canRoam>
  <disabled>false</disabled>
  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
  <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
  <triggers/>
  <concurrentBuild>false</concurrentBuild>
  <builders>

(snip)

  </builders>
  <publishers/>
  <buildWrappers/>
</project>

以上

素敵な Jenkins ライフをお送り下さいmm

2016 年 06 月 26 月（日）

tl;dr

久し振りの晴れ空。

朝

昼

  • 納豆うどんを作って食べる
  • CircleCI 上で Serverspec の Docker バックエンドを使ったテストがイバラの道だった（CircleCI で利用する Docker コンテナに対しては docker exec が利用出来ない）
  • 結局、色々とやりたいことがあったのにソファでダラダラ過ごしてしまう

夜

  • ギョーザを焼く、美味しかった

〆

  • ギョーザがとても美味しかった

2016 年 06 月 25 月（土）

tl;dr

変な天気が続く。

朝

  • 7 時前に目が覚める
  • 昨晩の夕食の片付けをボチボチ
  • 来月の勉強会の資料を作成、一旦 fix させる（修正等あれば対応する）

昼

  • ジョギング（香椎浜 2 周）
  • ジョギングシューズの左足先がスレてゴム底がめくれてきているので買い替えを検討したい
  • 遅い昼ごはん、奥さんの英気を養う為にうなぎ（自分は白飯にうなぎのタレのみ）

夜

  • Jenkins の使い方をイマイチ理解出来ていないので弄ってブログに纏めた

〆

眠い。

Serverspec と Infrataster でテストした Docker コンテナイメージを Jenkins を介して Amazon ECR に push する考察

serverspec infrataster jenkins aws ECR 雑な考察 Docker

tl;dr

ニーズがあるかどうか解らないけど...Jenkins を触ってみたくて試してみた。Jenkins の Amazon ECR プラグインとの出会いに身震いした。

参考

図

やったことを一枚の絵にすると...

こんな感じ。

f:id:inokara:20160625193046p:plain

実際に動いている画面

f:id:inokara:20160625193614p:plain

サンプル

github.com

このサンプルでは以下のようなテストを行う。

  • Serverspec の Docker バックエンド（厳密に言えば Specinfra の Docker バックエンド）を利用してコンテナに対して Docker API を介してテスト
  • 合わせて Infrataster と Docker API を利用してコンテナ内に立ち上げた Apache に対して振る舞いのテスト

事前にやったこと

サマリ

  1. Jenkins の導入
  2. Jenkins ユーザーで Docker API を叩けるようにする
  3. 各種 Jenkins プラグインの導入（後述）
  4. GitHub に Jenkins の Jenkins (GitHub plugin) にて URL を設定する（後述）
  5. IAM ユーザーの払い出して Amazon ECR にリポジトリを作成
  6. IAM ユーザーのクレデンシャル情報を Jenkins の「認証情報」に設定
  7. ECR に push するジョブ（ジョブ (2)）を作成
  8. ジョブ (2) にリポジトリ作成時に払いだされたレジストリ URL を Jenkins の Amazon ECR 用プラグインに設定する（後述）
  9. Serverspec と Infrataster でコンテナをテストするジョブ（ジョブ (1)）を作成（後述）
  10. ジョブ (2)のビルドトリガにジョブ (1) を指定する（後述）
  11. ジョブ (2)の Amazon ECR 用プラグインに Build Context と Dockerfile Path を指定する（後述）
  12. Build Pipeline の View を作成する（後述）

各種 Jenkins プラグインの導入

以下のプラグインを順不同でインストール。（※ 以下のプラグイン以外でも依存関係で関連するプラグインがインストールされる）

GitHub に Jenkins の Jenkins (GitHub plugin) にて URL を設定する

対象となる GitHub リポジトリの設定で Jenkins (GitHub plugin) を追加して Jenkins の Webhook URL を設定する。

f:id:inokara:20160625195221p:plain

尚、Jenkins の Webhook を設定する際に GitHub 側の IP アドレスを制限したい場合には以下のように API を実行して GitHub 側の IP アドレスを確認することが出来る。（Webhook の接続元は hooks キーの値を利用した）

curl -s https://api.github.com/meta

リポジトリ作成時に払いだされたレジストリ URL を Jenkins の Amazon ECR 用プラグインに設定する

ビルドにて Docker Build and Publish を選択すると以下のようにレジストリの情報等を入力出来るようになる。

f:id:inokara:20160625195911p:plain

Registry credentials では 事前に Jenkins の「認証情報」に登録しておいた IAM ユーザーの設定を利用する。

Serverspec と Infrataster でコンテナをテストするジョブ（ジョブ (1)）を作成

PATH="/var/lib/jenkins/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
cd /var/lib/jenkins/workspace/$JOB_NAME
bundle install
bundle exec rspec spec/docker_*_spec.rb

ジョブ (2)のビルドトリガにジョブ (1) を指定する

ビルドトリガにて「他のプロジェクトの後にビルド」を選択して、対象プロジェクトからジョブ (1) を選択する。

f:id:inokara:20160625200913p:plain

ジョブ(2)の Amazon ECR 用プラグインに Build Context と Dockerfile Path を指定する

ジョブ (1) の workspace に展開されている Dockerfile を利用してコンテナをビルドしたいので Build Context と Dockerfile Path を下図のように指定する。

f:id:inokara:20160625200925p:plain

Build Pipeline の View を作成する

特に難しいことは無く、Build Pipeline Plugin 導入後に Jenkins のダッシュボードの Job 一覧にある ＋ をクリックして作成する。

f:id:inokara:20160625193614p:plain

後は...

手元で Dockerfile を修正、spec ファイルを修正して push すれば Jenkins 先生がテストを走らせて、テストが合格であれば Dockerfile からコンテナイメージをビルドして Amazon ECR に push するという継続的デリバリー的な何かが動き始める。（これを継続的デリバリーと言うのかは解らないけど...）

そして、以下のように Amazon ECR のリポジトリにコンテナイメージが push されている。

f:id:inokara:20160625210720p:plain

また、Slack なんか絡めるとビルドの成功、失敗も以下のように通知してくれてナウい感じなるんぢゃないかと思ったり。

f:id:inokara:20160625203311p:plain

自戒を込めて、勉強会の資料は事前に用意しておきたい

雑感

tl;dr

勉強会の資料作りをしながら、頭によぎったことをダンプする。

勉強会で発表する意味

hb.matsumoto-r.jp

上記のブログ記事を読ませて頂いて、とても心動かされたし、自分の中でモヤモヤした迷いが吹っ切れた気がした。

ということで、発表の機会を得ることで、以下のような効果があると考えている。

  • 聞いてくださる人に理解してもらう為に、話す方はより理解を深めなければらない #=> 結果、勉強する必要がある
  • 同様に「もやっ」と理解していた知識や経験を整理する機会となる

もちろん、時間的な制約もあり完璧には理解を深めたり、情報の整理をすることは難しいが、その「きっかけ」が得られるという意味でとても有意義なことだと考えている。

資料は出来るだけ直前ではなく余裕を持って事前に

当たり前のことかもしれないけど、発表資料は余裕を持って事前に用意するようにしたい。

事前に用意出来ることで読みなおしや、最新情報への対応等も行いやすく、資料自体のクオリティもきっと上がるはずだし、それが聞いてくれる方々への敬意であると考えている。そして、様々な事情で残念ながら、資料が間に合わない、間に合っていないことはネタではなく反省点として次の勉強会に生かすべきだと思う。

繰り返しになるけど、当たり前のことなのかもしれないけど、自戒を込めて文字に起こしてみた。

ということで

日々精進。

2016 年 06 月 24 月（金）

日々 ま、いいか

tl;dr

昨日の日記だけど。

朝

  • 体が重だるいので汗をかけば軽くなるんぢゃないかと思ってジョギング（香椎浜を 2 周）
  • 結局、体の重だるさは抜けなかった
  • 10 時前に始業

昼

  • 詳しくは書けないけど、チームメンバーもさることながら、会社にはエンジニアとして優秀な人が多い
  • すげー会社に置いてもらってるなと毎回思う
  • 置いてかれないようにしたいけど、多分、置いてかれてる...

夜

  • 奥さんが仕事に行き始めたので掃除、洗濯、たまに夕飯作り等の比重が大きくなってきているけど、ま、いいか
  • 家事は仕事で一息いれるタイミングにささっと片付けているのでクオリティは低い、ま、いいか

〆

  • ま、いいか