月別アーカイブ: 2018年10月

awscliを使えるJenkinsの(Docker)agent

Jenkinsのpipelineからawscliを使えるエージェントを呼び出して使おうと思ったら結構てまどったのでそのメモ。

環境

その時の最新

CentOS Linux release 7.5.1804 (Core) DockerのHostマシン
Jenkins 2.138.1
Pipeline 2.5
Pipeline: SCM Step 2.6
Git plugin 3.9.1
docker-machine version 0.11.0, build 5b27455
DOCKER v18.06.1-ce

awscliの入ったイメージ

こちら
dockerfileにあるユーザ名は任意で良いけれども、uid/gidはDockerのユーザが基本的に1000なので1000にあわせておかないとややこしい。

Jenkinsfile

pipeline {
	agent none
    
	stages{
		stage('コピーフェーズ') {
			agent {
				docker {
			  		image 'kyoshitake/awscli'
             		args '-v /path/to/.awsconfの親:/home/ciuser:rw -e HOME=/home/ciuser'
             	}
			}
			
			steps {
				sh 'echo コピーフェーズ'
				sh 'aws s3 ls lwo > /home/ciuser/hoge.txt'
				sh 'echo 試験でls'
			}
		}
    }
}

agentに作ったイメージを指定。

hostにawsの認証ファイルを配置しておき、認証情報ファイルのあるディレクトリ(.aws)の親ディレクトリをマウント(/home/hoge/.awsとあるとすると/home/hogeをマウント)。なお、環境変数等で指定してもOKのはずだが試してはいない。

ハマリポイントとしてjenkinsのagentとして動かす場合は明示的にホームディレクトリを(環境変数で)指定しないと”/”がホームディレクトリになった。
明示的にホームを指定するのでawscliのイメージで指定したユーザの/home/ciuserに拘らず任意の名前でOKのはず。(なのでawscliのユーザ名と一致させる必要もないはず。)

Jenkins

Docker-compose

version: '3'
services:
jenkins:
build: ./jenkins
restart: always
container_name: jenkins
environment:
VIRTUAL_HOST: hoge.huga.co.jp
VIRTUAL_PORT: 8080
LETSENCRYPT_HOST: hoge.huga.co.jp
LETSENCRYPT_EMAIL: kitamura@epea.co.jp
volumes:
- jenkins_data:/var/jenkins_home
- /var/run/docker.sock:/var/run/docker.sock
- /etc/localtime:/etc/localtime:ro
- /ci:/ci:ro
networks:
- default
- proxy_default

data:
image: busybox
volumes:
- jenkins_data:/var/jenkins_home

volumes:
jenkins_data:

volumesにある/var/run/docker.sock:/var/run/docker.sockでJenkinsイメージのhostにあるDockerを使用。
/ci:/ci:roはjenkinsが読み込みたいファイル類の置き場(このブログだと関係ないはず)

dockerhubにあるnginx-proxyとletsencrypt-nginx-proxy-companionでssl化していてnetworksにあるproxy_defaultはそちらのネットワーク。

取消線入れてあるところは、多分無くても動くはずの今回のブログでは必須では無い物。(だが、自分の環境ではそれでやっていて最低限の設定は確認していないのでのせておく。)

Dockerfile

FROM jenkins/jenkins:lts
USER root
RUN apt-get update && apt-get install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg2 \
software-properties-common
RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
RUN apt-key fingerprint 0EBFCD88
RUN add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"
RUN apt-get update && apt-get install -y docker-ce

ARG DOCKER_GID=991
RUN groupmod -g ${DOCKER_GID} docker && adduser jenkins docker

RUN mkdir -p /ci

USER jenkins

公式のJenkinsイメージにdockerをインストールしたもの。

gidはhostのJenkinsユーザに合わせたもの。多分docker-machineでいれたら991になっていると思うが、各自で要確認。

 

 

取得してしばらくしたドメインがDNS_PROBE_FINISHED_NXDOMAIN

TwitterにWordpressのサイトを立ち上げて少し立ったサイトがDNS_PROBE_FINISHED_NXDOMAINでつながらないという事象で困っているクライマーがいました。

ブログのネタついでに切り分けしたので、切り分け方法と解消方法をメモしときます。

DNS_PROBE_FINISHED_NXDOMAINとは

インターネットのアドレスのドメイン部分(https://www.rocher.kyoto.jp/arbr/〜のwww.rocher.kyoto.jp部分)はどのサーバ(インターネットの向うの機械)かを表していて、管理は数字(ipアドレス)メインで行われています。

で、ざくっと雰囲気で説明すると、ドメインの文字が実際にはどの数字かを教えてくれるシステムがあってそれをDNSといいます。そのDNSにドメインのIPを教えてと自分の端末(PC/スマホetc)からサーバに接続しようと自動で質問したけどその答えが得られないときに発生するのがDNS_PROBE_FINISHED_NXDOMAINというエラーです。

結構あたる解決策

ドメインをお名前comなりムームードメインなりで取得したと思いますが、期限内にメールアドレスの認証をきちんとしていないとそのドメインのDNS機能を停止させられます。

ドメインを取得してしばらく経った後に、使えていたドメインが止まってしまったら認証漏れの可能性が高いです。

「【重要】~ ドメイン 情報認証のお願い」みたいなメールが来ていると思うのでそいつに従って手続きをしたら、通常数10分ほどで復活します。

切り分け

きちんと調べてから治したい人向けの切り分けです。(そもそもお名前comなりの管理画面にログインしたら分かり易い警告でているかもしれません。)

自分の端末の問題かつなげているDNSがおかしいかの切り分けが必要です。

確実ではないですが、自分の端末がおかしいか確かめるために違うwifiの友達なりにおかしいURLを送って、同じブラウザで同じエラーが出るか確かめてもらうのが手軽です。

同じエラーが出なかったら自分の端末側の問題が大きいですが、ここでは取り扱いません。(ほかを再度ぐぐってください)

で、他の人もおかしかったらDNS側の問題の可能性が高いです。
whoisというコマンドで調べられます(オンラインだとこことかですが、管理アドレスによってどこで調べ直せと管理先URLを教えられてもう一度調べ直しになります。

で、そこで「Domain Status」という処がclientHoldというものになっていたらメールアドレスの認証エラーです。

clientHoldの理由には認証のメールに返信していなかった以外にも、登録した個人情報が怪しまれた場合もありますがそちらはレアケースなのでそうなってしまったら、サポートに連絡するしか無いと思います。

追記

ピンバックはできるだけ対応するので、参考になったらリンクはっていただけるとありがたいです

Rasberry PIで電子工作

しばらく放置していますが、玄関ブザーにメール通知機能を付けたりしようと思いRasberry PIで電子工作をはじめました。

まだ、全然進んでいませんがハマリポイントをメモしときます。

ジャンパーワイヤー

始に、GPIOと繋げるジャンパーワイヤーがオス-メスなので都会に住んでいないと近場の店では売っていないことが多いです。これは素直にネットで買うと良いと思います。

 

きちんと、電気が通っているかの確認でテスターとかもあった方が良いと思いますが、壊れたおもちゃからはがしてきたモーターとかで最初は十分代用が效くと思います。
オモチャに付いていたLEDで代用しようとすると電流が多すぎたりで結構壊れることが多いです。どうしてもそれしかないという時は、直列にLEDつなげて、様子をみながら少しずつ減らしていけばなんとかなるかと。

pyenv

とりあえずpythonの資料が多いからpyenv入れとこうかと気軽にインストールしたくなります。ただし、マシンパワーが非力なのでインストールに時間がかかります。一晩以上はかかるので時間ある時にインストールしておくのがよいです。

pythonのバージョン

ライブラリ類は結構バージョン違いで動かないです。ネットからinputを受け取らない箇所はまずは素直にサンプルのバージョンで作った方が幸せになれる気がします。

開発マシン

Rasberry PIで直接開発をするとスペックが低いので色々辛いです。電源on/offに直結する以外の機能は別マシンで試してからRasberry PIに載せた方がいいかもしれません。

DockerHubでの自動ビルドが複数回走ってしまう(未解決)

理由)
BitBucketのレポジトリへのpushをトリガーにDockerHubでイメージを自動ビルドする際に、Bitbucketで各Dockerfileで個別にレポジトリを持ちたくなかった。

結果)
ビルドが複数回走ってうまくいかない

内容)
一つのBitbucket側のレポジトリに複数のDockerfileをディレクトリを分て管理。そして、Bitbhcket側でDockerfileのあるパスを指定しビルドをする形態をとりたかった。現時点では、イメージできはするけど一回のpushでビルドが複数回走ってしまう。

Bitbucket側はこんな感じ
https://bitbucket.org/YoshitakeKitamura/dockerfiles/src/master/

DockerhubではレポジトリとDockerfileのパスを指定

git add --all
git commit -m test
git push

で複数ビルドが走っている。

ビルド回数は1+dockerfileの数回?(mavenというdockerfileのディレクトリとawscliというものがある)

 

これからシンプルに1イメージ1レポジトリを試してみるけど、これだとやっぱり発生するかも
1イメージ1レポジトリは動いた。