Lancard.com http://www.lancard.com/ Lancard.com 新着情報とスタッフブログのRSS(RSS 2.0) <![CDATA[年末年始営業のご案内]]> http://www.lancard.com/news/archives/58 Wed, 28 Dec 2016 10:00:00 +0900 http://www.lancard.com/news/archives/58 誠に勝手ながら、弊社の年末年始の営業は、下記のとおりとさせていただきます。
皆様にはご迷惑をお掛けしますが、何卒ご容赦願います。
 
今年一年ご愛顧を賜りまして大変感謝申し上げますとともに、皆様のご多幸をお祈りいたします 。
 
年内営業   2016年12月28日 18:00まで
年始営業   2017年1月4日   9:00より
 
緊急のトラブルの際は対応いたしますのでご連絡ください。

 

]]>
誠に勝手ながら、弊社の年末年始の営業は、下記のとおりとさせていただきます。
皆様にはご迷惑をお掛けしますが、何卒ご容赦願います。
 
今年一年ご愛顧を賜りまして大変感謝申し上げますとともに、皆様のご多幸をお祈りいたします 。
 
年内営業   2016年12月28日 18:00まで
年始営業   2017年1月4日   9:00より
 
緊急のトラブルの際は対応いたしますのでご連絡ください。

 

]]>
<![CDATA[何故 git rebase は駄目で git pull –rebase はいいのか]]> http://www.lancard.com/blog/2016/11/07/git-rebase-and-pull-rebase/ Mon, 07 Nov 2016 09:12:22 +0900 http://www.lancard.com/blog/?p=4648 git pull –rebase は便利ですが、rebase と言えば git rebase、これが割と敬遠されがちな声を聞くので –rebase オプションなんて本当に使っていいのか心配になることもあるかと思います。

私も普段は便利に git pull –rebase していますが、ふと git rebase の解説記事をみかけると毎度不安になりこの二つの仕組みを調べてしまうので、いっそのことまとめてしまうことにしました。

git rebase

以下のような状態のリポジトリがあったとします。

git-rebase-flow-rebase1

一番上はリモートの master、下 2 つはローカルで master と作業用 branch です。例えばローカルでブランチを作成して作業し、それを master に rebase する前に pull したところ、リモートの master に更新があった場合等ですね。

この状態で master ブランチから rebase-branch に対し rebase を行ってしまうと以下のような状態になります。

git-rebase-flow-rebase2

ブランチでのコミットがリモートから取得したコミットより手前に挿入される為、リモートに既にあるコミットのハッシュが変わってしまいます。ローカルとリモートが一致しない為 push 出来ないのですが、ここでよく分からず曖昧に git push -f をやると末代まで恨まれることとなります。

これが一般的に git rebase が敬遠される理由でしょう。

git pull –rebase

では git pull –rebase とは一体何なのか。以下のような状況を考えます。

git-rebase-flow-pull-rebase1

登場人物は 2 人、リモートの master ブランチとローカルの master ブランチです。ローカル master にコミットがありますが、リモート master にその手前に反映されるコミットがある場合です。

git-rebase-flow-pull-rebase2

その状態から git pull –rebase するとこのようになります。リモートの更新がローカルのコミットの手前に反映され、ローカルのコミットのハッシュが変わってしまいました。

git-rebase-flow-pull-rebase3

しかしハッシュが変わったコミットはまだリモートに存在していません。なのでここで push してもコンフリクトは発生せず、問題にならないというわけです。

ここで –rebase オプションの何が便利かというと、マージコミットが発生しないことです。pull してコンフリクトしない場合というのは結構多いですが、通常はその際にもマージコミットは発生してしまいます(ローカルでのコミットが無い等で fast forward マージになる場合を除く)。複数人が開発するプロジェクトで、各個人のローカルリポジトリの pull 状況を残したマージコミットは大半の場合不要でしょう。

補足

git pull –rebase が危険なケース(多分少ない)

こういうことを書くと結局よく分からなくなるのでは…と思いつつ、簡潔に。リモートリポジトリを複数持つリポジトリでは注意が必要です。仕組みは git rebase の項のローカルリポジトリをリモートリポジトリに置き替えて考えると分かり易いです。登場人物が 3 人以上になると危険ですね。

但しこの場合も push しようとするとリジェクトされるので、push -f さえしなければとにかく安心と考えることも出来ます。

git pull –rebase がコンフリクトした場合

こういった場合は git rebase –abort 又は git reset –hard HEAD して、通常の git pull を行いマージコミットを作成してもいいかもしれません。コンフリクトした場合の rebase 操作がややこしいというのもありますが、「コンフリクトをどのように解消したかを明確に残す」という意味でマージコミットを作成する意義がある為です。

但し pull した場合の空のマージコミットがリポジトリに大量に含まれている場合、この意味のあるマージコミットが埋もれてしまいます。git pull –rebase 運用を徹底するか、コンフリクト解消のマージコミットはコミットメッセージを明確に記載する等の工夫をしましょう。


Facebooktwittergoogle_pluslinkedintumblrmail]]>
<![CDATA[実行されたJenkinsFileはReplayから確認できる]]> http://www.lancard.com/blog/2016/09/23/%E5%AE%9F%E8%A1%8C%E3%81%95%E3%82%8C%E3%81%9Fjenkinsfile%E3%81%AFreplay%E3%81%8B%E3%82%89%E7%A2%BA%E8%AA%8D%E3%81%A7%E3%81%8D%E3%82%8B/ Fri, 23 Sep 2016 17:58:42 +0900 http://www.lancard.com/blog/?p=4617 muraveです。

なうなやんぐなのでPipelineでJenkinsFileを使ってビルドについてもソースコード管理したいわけですが、他チームのJenkinsFileを参考にしたいときにJenkins上から内容が確認できないと、お願いしてJenkinsfileを送ってもらうという悲しいことになったり(実際に発生)。

Jenkins上から確認できるように出来ないものかとプラグインを探したり、ファイルは残っていたのでそれを参照できるようにできないかいろいろ試したりしていました。

しかし、そんな事をしなくても内容をみることができる方法がみつかったのでした。

まぁ、答えはタイトルに書いちゃってますが、こんなん予想できませんわー。

一部マスクしますが、キャプチャを貼っておきますね。

cursor_%e3%81%a8_replay__26__jenkins_

スクリプトを参照する場合は間違ってRunしないように注意ですね。

Facebooktwittergoogle_pluslinkedintumblrmail]]>
<![CDATA[JenkinsのwithCredentialsでユーザー名とパスワードを扱えるのかを確認したいだけだった]]> http://www.lancard.com/blog/2016/09/07/jenkins%E3%81%AEwithcredentials%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E5%90%8D%E3%81%A8%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%82%92%E6%89%B1%E3%81%88%E3%82%8B%E3%81%AE%E3%81%8B/ Wed, 07 Sep 2016 11:49:05 +0900 http://www.lancard.com/blog/?p=4603 muraveです。

なうなやんぐはPipelineでJenkinsFileを使ってビルドについてもソースコード管理ですよねー、ということで試してみているんですが、ユーザー名やパスワードをJenkinsFile内に書くわけにはいかないわけで。

方法を探してみたところ withCredentials でどうにか出来そうでした。

Fetch a userid and password from a Credential object in a Pipeline job.

ここを見ながらザックリと Pipeline script なジョブを作成して動作を確認しようとしたところ、少々ハマリました。

テスト用にユーザー名test、パスワードpassword、credentialsIdがtestの認証情報を作成しています。

node {
    stage 'withCredentials Test'
    withCredentials([[$class: 'UsernamePasswordMultiBinding', 
            credentialsId: 'test',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {

        sh 'echo uname=$USERNAME pwd=$PASSWORD'
    }
}

これを実行したログを確認すると

[credential_****] Running shell script
+ echo uname=**** pwd=****

みたいな表示。うーん。何か権限的に引っかかってるのか、表示が潰されているだけなのかがわかりません。

結論を先に言うとユーザー名、パスワードについて表示を****で潰すようになっているようです。
あとで気づいたのですが[credential_****]のところもジョブ名がcredential_testなのでユーザー名であるtestが潰されているのでした。

ではユーザー名、パスワードが本当に取れているのかをどのように確認したのか?ですが次のような Pipeline script を作成しました。

node {
    stage 'withCredentials Test'
    def uname   //withCredentials外にUSERNAMEを持ち出す為に使用
    withCredentials([[$class: 'UsernamePasswordMultiBinding', 
            credentialsId: 'test',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {

        sh 'echo uname=$USERNAME pwd=$PASSWORD > idpw.txt'
        sh 'pwd'    //ワークスペースの位置確認をしたかったのだが、しかし

        println(env.USERNAME)   //groovyでの扱い
        uname = env.USERNAME    //withCredentials外にUSERNAMEを持ち出す
    }

    stage 'withCredentialsの外で出力'
    println(uname)

    stage 'ワークスペースの位置確認'
    sh 'pwd'
}

実際に行ったのはidpw.txtファイルにリダイレクトして内容を確認でしたが、その際の謎動作の説明のための処理や、その後にログ上で確認できないかな?と思ってやってみたことも混ぜてあります。

ログから抜粋してまとめると以下のようになります。

Entering stage withCredentials Test
Proceeding

[credential_****] Running shell script
+ echo uname=**** pwd=****

[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****

****


Entering stage withCredentialsの外で出力
Proceeding
test


Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test

idpw.txtの位置が知りたくてpwdしているのですがwithCredentialsのブロック内で実行すると

[credential_****] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_****

と、ユーザー名のtestと同じだったために一部マスキングされてしまっています。まぁ、大体の位置は予想がついたのでidpw.txtを探して内容確認はできたわけですが(ちゃんとユーザー名、パスワードが出力されていました)。

最後にブロック外でpwdしてみるとちゃんと

Entering stage ワークスペースの位置確認
Proceeding
[credential_test] Running shell script
+ pwd
/var/jenkins_home/workspace/credential_test

と出力されているのがわかります。

ログだけでの動作確認ですがブロック外ならマスキングされないのがわかったのでuname変数を定義して外に持ちだしてやればいいかな〜と

Entering stage withCredentialsの外で出力
Proceeding
test

やはりマスキングされずに出力されました。動作の確認はできましたが、これは通常はやってはいけないパターンですね。

以上です。

Facebooktwittergoogle_pluslinkedintumblrmail]]>
<![CDATA[Dockerのデータボリュームをバックアップ・リストア]]> http://www.lancard.com/blog/2016/09/06/docker%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%83%9C%E3%83%AA%E3%83%A5%E3%83%BC%E3%83%A0%E3%82%92%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%83%BB%E3%83%AA%E3%82%B9%E3%83%88%E3%82%A2/ Tue, 06 Sep 2016 11:58:37 +0900 http://www.lancard.com/blog/?p=4599 現状試しているのはローカルストレージドライバでのデータボリュームの場合ですが、コンテナでバインドして扱うのが常道な感じです。

データ・ボリュームのバックアップ・修復・移行
http://docs.docker.jp/engine/userguide/dockervolumes.html#id9

に書いてあるやり方ですね。

jenkins-masterというコンテナの /var/jenkins_home をバックアップ・リストアする例をあげます。

バックアップ

$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine tar czvf /backup/alp.tar.gz -C /var jenkins_home

リストア

$ docker run --rm -u root --volumes-from jenkins-master -v $(pwd):/backup alpine sh -c "rm -rf /var/jenkins_home/* && cd /var && tar xzvf /backup/alp.tar.gz"

念のためユーザーにrootを指定し、Alpine Linuxで実行しています。バックアップ時、相対ディレクトリ指定のためtarの-Cオプションを使用しています。展開時はゴミファイルが残るのが嫌だったのでリストア対象ディレクトリ内を全て削除してから展開していますが、削除はしないほうが安全かもしれません。

以上です。

データボリュームコンテナについての蛇足
データ永続化のために別途データボリュームコンテナを作成している場合でもローカルストレージなデータボリュームを使用していれば同じこと、docker save や docker export でバックアップというわけにはいかないようです。残念。

Facebooktwittergoogle_pluslinkedintumblrmail]]>