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レポジトリは動いた。

SiteGuard WP Pluginのログイン画面変更でエラー

先日移行してきたwordpressのサイトにもともとは言っていたSiteGuard WP Plugin(サイトガード WP プラグイン)のログイン画面を変更しようとしたがうまく動作しなかったのでその対処メモ

事象は新しく指定されたログインページを見ようとしても404エラーになるというもの。

 

 

元々以下のような設定が.htaccessにあったけれども

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

SiteGuardでログイン画面を変更しようとしたところ以下のものが既存の設定の下に追記された。

#==== SITEGUARD_RENAME_LOGIN_SETTINGS_START
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^wp-signup\.php 404-siteguard [L]
RewriteRule ^wp-activate\.php 404-siteguard [L]
RewriteRule ^login_nnnnn(.*)$ wp-login.php$1 [L]
</IfModule>
#==== SITEGUARD_RENAME_LOGIN_SETTINGS_END
#SITEGUARD_PLUGIN_SETTINGS_END

 

まとめるとこんな感じ

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

#==== SITEGUARD_RENAME_LOGIN_SETTINGS_START
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^wp-signup\.php 404-siteguard [L]
RewriteRule ^wp-activate\.php 404-siteguard [L]
RewriteRule ^login_nnnnn(.*)$ wp-login.php$1 [L]
</IfModule>
#==== SITEGUARD_RENAME_LOGIN_SETTINGS_END
#SITEGUARD_PLUGIN_SETTINGS_END

青字/斜体のファイルとディレクトリがなければindex.phpに飛せという指定が先に来てしまい、新たに指定されたURLがlogin_nnnnnならば〜という処理まで到達していない。

#==== SITEGUARD_RENAME_LOGIN_SETTINGS_START
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^wp-signup\.php 404-siteguard [L]
RewriteRule ^wp-activate\.php 404-siteguard [L]
RewriteRule ^login_nnnnn(.*)$ wp-login.php$1 [L]
</IfModule>
#==== SITEGUARD_RENAME_LOGIN_SETTINGS_END
#SITEGUARD_PLUGIN_SETTINGS_END

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

上下を入れ替えたら取り敢えず動作させたけどプラグインの正しい想定は不明。
一緒に以下のタグも自動生成されたいたからこの間に青字のWordPressでよく見る設定を入れておくのが想定なのかな?

# BEGIN WordPress
# END WordPress

osclassをリバースプロキシでSSL化した環境で動かす

先日、クライマーがセッション仲間募集する用のマッチングサイトをつくろうと思いOsclassをdockerでインストールした。で、SSL化をletsencrypt-nginx-proxy-companionでしたのだけど、そのままだとOsclassが生成するリンク先がhttpになってしまいCSSやらがうまくよ見込めなかったのでその対処メモ。

 

基本は以下のものを使用。

https://hub.docker.com/r/bitnami/osclass/

GitHubにもあるのでクローンした方が楽。

https://github.com/bitnami/bitnami-docker-osclass

version: '2'
services:
mariadb:
image: 'bitnami/mariadb:latest'
environment:
- MARIADB_USER=bn_osclass
- MARIADB_DATABASE=bitnami_osclass
- ALLOW_EMPTY_PASSWORD=yes
volumes:
- 'mariadb_data:/bitnami'
networks:
- default

osclass:
image: 'bitnami/osclass:latest'
environment:
- MARIADB_HOST=mariadb
- MARIADB_PORT_NUMBER=3306
- OSCLASS_HOST=boltomo.bouldering-climbing.kyoto
- OSCLASS_DATABASE_USER=bn_osclass
- OSCLASS_DATABASE_NAME=bitnami_osclass
- OSCLASS_USERNAME=huga
- OSCLASS_PASSWORD=hoge
- ALLOW_EMPTY_PASSWORD=yes
- VIRTUAL_HOST=boltomo.bouldering-climbing.kyoto
- LETSENCRYPT_HOST=boltomo.bouldering-climbing.kyoto
- LETSENCRYPT_EMAIL=hoge@fuga.com
labels:
kompose.service.type: nodeport
ports:
- '80' #443は削除
depends_on:
- mariadb
volumes:
- 'osclass_data:/bitnami'
networks:
- default
- mydcproxy_default

volumes:
mariadb_data:
driver: local
osclass_data:
driver: local



networks:
mydcproxy_default:
external: true

 

VIRTUAL_HOST=boltomo.bouldering-climbing.kyoto – LETSENCRYPT_HOST=boltomo.bouldering-climbing.kyoto – LETSENCRYPT_EMAIL=hoge@fuga.com

letsencrypt-nginx-proxy-companion用の設定。

リバースプロキシはいろいろな所から呼ばれるので別のdocker-composeになっていてそのネットワーク名がmydcproxy_defaultとしているので外部ネットワークとして
networks: – default – mydcproxy_defaultとかnetworks: mydcproxy_default: external: trueとかを指定している。

(参考)
http://tech.quartetcom.co.jp/2017/04/11/multiple-ssl-apps-on-one-docker-host/

 

青字の- OSCLASS_USERNAME=huga – OSCLASS_PASSWORD=hoge は実際には設定していないけどコピペしてデフォルトID/Passで走らせることがないようにhttps://hub.docker.com/r/bitnami/osclass/みて追記。(動かしていないのでコケるかもしれない)

で、本題のそのまま動かすとOsclassの動くコンテナはリバースプロキシの後ろでhttpで動いており、生成されるリンク先がhttpになってしまう。

一応、以下のように設定ファイルを直接変更して動いた。

docker exec -it boltomo_osclass_1 /bin/bash

cd /opt/bitnami/osclass/
sed -e ‘s/http/https/g’ config.php

define(‘WEB_PATH’, ‘https://boltomo.bouldering-climbing.kyoto/’);

 

dockerfile作って自動化した方がいいけど、Osclassの使い勝手が要件に対して微妙だったのでこれ以上の作業はせずに修了。

X-Forwarded-Protoとかは試していないけどもっとおしゃれな解決法はあるかもしれない。

OSMCのインストールでちょっと手間取った

CentOS7で公式のOSMCサイトからyumレポジトリを取得しOSMCをインストール

インストーラー起動しようとしたら、なんか立ち上がらない

sudo view /var/log/messages

Jun 28 19:52:37 localhost osmcinstaller.desktop: sudo: 端末 (tty) が存在せず、パ
スワードを尋ねる (askpass) プログラムが指定されていません

普段遣いのユーザはパスワードなしsudoで運用しているのでだめっぽい。
パスワードなしで対処している例が多いけど、気持ち悪いのでsudoでインストーラーを起動。

sudo /usr/bin/osmcinstaller

ぺちぺち、画面に従ってUSBにインストールしようとしたけど、unmountできないとか言われてエラー終了しイメージができなかった。
普段遣いのユーザのGUIでている状態でUSBさしているので、権限があかんぽい。
通常のユーザでumountしたのちsudoでmountしたらOKだった。

Raspberry Piがfstabの編集ミスしたら起動しなくなった(他端末でマウントして復旧)

HDDの自動マウント設定をミスってしまったら、Raspberry Pi(Raspbian)がEmergency modeになって正常起動しなくなってしまった。
状況としてはこちらと同じ。

microSDの(windowsからもみれる)boot直下のcmdline.txtにinit=/bin/sh追記して起動しろというのを試したけど状況変わらず。

ファイル直接編集したらいいじゃんということでWindowsからいじろうとしたけど/etc/fstabのあるパーティションはext4。なのでWindowsからはいじれなかった。
Linuxマシンでマウントして編集できた。

dockerで起動したdnsmasqとvagrant(libvirtd)のdnsmasqがport競合

dockerでdnsmasqを手軽に起動しようとしたら53番がすでにうまっていた。
なにで使っていたっけとみてみるとvagrant(libvirtd)が内部で使用する用のdnsmasqがすでに立ち上がっていた。

ググってみたところhostで直接dnsmasqを立てているときの解決法はでてきた。

起動準を気にしないでお異様にlibvirt側の設定からリッスン(バインド?)するのを絞って(+docker側でも絞って)競合しないようにしたいけど、上の解決策が公式にあるってことは、libvirtの設定でlibvirtのdnsmasqをいじるのは難しいのかな?libvirtのdnsmasq.confは自動生成だから直接これを変わっていいものでもなさそうだし。

最近はdockerばっかでvagrant触ることもほとんどないのでとりあえず止めとくか。。。

データサルベージ

先日飲みながらNASを触っていたら間違ってデータを全削除しかけてしまった。
一部データを残して削除されてしまい、フォーマットもxfsで自力復旧も困難だったので、リカバリソフトで復旧してみた。
結果的には9割がた復旧。

使ったのはEaseUS Data Recovery Wizard Professional 11.9というソフト。

公式ページはこちら

NASのディスクをUSBの外付けHDDにさしてスキャンして待つこと3日。時間はかかったけど、だいたい復活しました。

最初の表示は残り8時間(3Tのディスク)でしたが、時間がたつごとに終了時間が伸びて行ってました。めんどくさがらずにSATAに刺したら早かったかもしれない。