image: php:7.1.1

pipelines:
  default:
    - step:
        script:
          - ls -la ~/.ssh
          - cat ~/.ssh/config
  branches:
    staging:
      - step:
          script:
            - apt-get update
            - apt-get install ssh -y
            - curl -LO https://deployer.org/deployer.phar
            - chmod +x deployer.phar
            - ./deployer.phar -f=./front/deployer/deploy.php deploy staging -v
            - ./deployer.phar -f=./admin/deployer/deploy.php deploy staging -v

Errors

私が見たエラーたちです。

Deployerのバージョンが上がっていた

[Error] Call to undefined function Deployer\server()                           
 #0                                                                             
 phar:///opt/atlassian/pipelines/agent/build/deployer.phar/src/Deployer.php(309)
 : require()                                                                    
~~                    
 require('phar:///opt/atl...')                                                  
 #5 {main}

ﾊｧ?　という感じのエラーが吐かれて意味不明だったのですが、何のことはなくDeployerのバージョンが上がった際に破壊的な変更がいい感じに行われていただけでした。

さすがメジャーバージョンアップデート、後方互換なんて一切気にしてないぜ。

Servers to Hosts server($name, $hostname) to host($hostname)

ssh コマンドがインストールされていない

[Deployer\Exception\InitializationException]  
Failed to initialize ssh multiplexing

の様なエラーが出たんですね。 image の選定がイケてないのかもしれませんが、Deployerを動かすんだから、とPHPのビルド向けの php:7.1.1 を指定したら、ssh コマンドがインストールされていないようでした。

ssh コマンドのインストールを宣言して回避しました。なお apt-get の update を行っておかないと install には失敗するようです。

別にエラーではないのですが、Pipelinesのビルド時にはリポジトリの設定で指定したSSHキーが以下のように配置されているみたいです。これによってSSHコマンドのデフォルトに指定した鍵が使用されます。

ls -la ~/.ssh
total 16
drwxr-xr-x. 2 root root 4096 May 26 17:31 .
drwx------. 1 root root 4096 May 26 17:31 ..
-rw-------. 1 root root   56 May 26 17:31 config
-rw-r--r--. 1 root root 1606 May 26 17:31 known_hosts

cat ~/.ssh/config
IdentityFile /opt/atlassian/pipelines/agent/data/id_rsa

known_hosts

にBitbucketが入っていなくて、リモートマシンでの git clone が失敗していました。

他

いろいろダメだった気がしますが忘れました。

コスト

こんなところでしょうか。

Deployerの実行自体は基本的には以下の3行のスクリプトで行えるので、後はプロジェクトの事情に応じて周辺設定、宣言を適宜行っていけばいいと思います。

            - curl -LO https://deployer.org/deployer.phar
            - chmod +x deployer.phar
            - ./deployer.phar deploy

正直PipelinesでDeployerするのにかけた時間と毎回コマンドを手で叩く時間の総計では、前者の方が長い結果になる気がするのですが、叩かなくてよくなる、というのはいいですね。

Bitbucket Server（Stash）にもくっついてこないかなぁ？標準添付だと何かと便利そうなのだけれどコンテナを実行できる環境とかないと無理だし、ないかな。欲しいんだけどなぁ。

そんな感じでした。

2017-02-05

さくらのクラウドオブジェクトストレージにAWS SDK for .NETで接続する

雑記 .NET Tips

ときに、素直にはいかなかったのでメモを残しておく。

さくらのクラウドオブジェクトストレージのバージョンは記事の日時現在、 SDKのバージョンは 3.3.5.3 だった。

“AWSSDK.S3”: “3.3.5.3”

概ね以下のような記述で接続できるクライアントを構成できた。

endpoint: https://b.sakurastorage.jp/
key: アクセスキーID
secret: シークレットアクセスキー

// デフォルトの AWS4 に対応していないのでv2を使う様に設定する
AWSConfigsS3.UseSignatureVersion4 = false;
client = new AmazonS3Client(
    new BasicAWSCredentials(key, secret),
    new AmazonS3Config()
    {
        ServiceURL = endpoint,
        // XXX この設定は間違っているか無視される
        SignatureMethod = SigningAlgorithm.HmacSHA1,
        SignatureVersion = "2"
    });

記事現在の AWS SDK for .NET に関するドキュメントはバージョン3ではなく2で書かれていて、そこではシグネチャの既定のバージョンは2なようだ。

そのため、逆に4を有効にするような案内が載っていたりするが、罠なので気を付ける。

AWS SDK、CLI、Explorer の使用 - Amazon Simple Storage Service

S3 クライアントを作成する前に、コードに以下を追加します. AWSConfigs.S3UseSignatureVersion4 = true;

逆や。

これに限らず、もろもろのバージョンは後から不一致に気が付くとなかなか切ない思いになる。

巡察艦ゴースロスの個室で主計修技館の規則を読んでいたジント君の気分を垣間見た。

2017-01-27

KUSANAGIユーザグループ東京第1回勉強会

イベント雑記

KUSANAGIユーザグループ東京第1回勉強会 - connpass に参加してきた。

kusanagi-ug-tokyo.connpass.com

一応KUSANAGIユーザーだし、前々から少し記事書いている通り興味のあるプロダクト？　なので、どういう人達が作ったり使ってりしているのか興味もあったので丁度よかった。

だいたい空気はこんな感じだったようだ。

#kusanagiug since:2017-01-25 until:2017-01-28 - Twitter Search

作ってる人らと多少話して、ああいうエッジが効いたものになっている理由がなんとなくわかった気がする。

アンテナを全く貼っていない恥ずかしい自分にとっては、ユーザーグループのページとフォーラムが開設していた事を知れたのも良かった。

LAMPやWordPressに関するノウハウを色々持っている人らが主催、関係しているので、その辺に興味がある場合は悪くないユーザーグループ＆勉強会なのではなかろうか。（当然、KUSANAGI使いましょう、と営業は受けるが）

活用していくうえでぶちあたった課題には、中の人が丁寧に回答していてくれた。

中の人……そう、ユーザグループ勉強会とはいいながら、5/6が関係者という、初期にはありがちな感じもする状態だった。 UGとしてそれはどうなんだ？　という感じもするので、今後は多少なりとも自分も発信したいなぁ。と思った次第。

なんか思ったら脊髄反射でツイートしたり、なんぼかこのBlogに書いたりしちゃってるので、特にスライドを用意するようなことが貯まらない可能性は高い。がまぁ、その辺は流れで機会があればと思う。

そんな感じ。

追記。

一番盛り上がってたのは、勉強会の日程を間違えた方が、ビデオ通話で「ごめんなさい」してたところでした。

2016-12-21

KUSANAGI(というかWordPress)をGoogleDriveにバックアップする

雑記 Tips

人として、VPSの外にバックアップを取りたかったので取った。

別にどこにとっても良かったのだけれど、なんとなくGoogleDriveにした。

ぐぐったらLinuxで便利に使えるクライアントが出てきた。

takuya-1st.hatenablog.jp

インストールと認証は済ませておく。

バックアップ用のディレクトリを作る。

# gdrive upload --recursive /home/kusanagi/bkup/
Creating directory bkup

作ったディレクトリのIDを確認する。

# gdrive list
Id                                             Name                 Type   Size       Created
idstring                   bkup                 dir               2016-12-21 hh:mm:ss
.
.
.

適当にバックアップして同期アップロードする。

#!/bin/bash

gdriveid="idstring"
bkversion=`date +%u`
bkdir="/home/kusanagi/bkup/"
wpdir="/home/kusanagi/hoge_html"
sitebkfile="${bkdir}wp-${bkversion}.tar.gz"
dbbkfile="${bkdir}db-${bkversion}.sql.gz"

rm $sitebkfile
rm $dbbkfile

mkdir -p $bkdir
tar czf $sitebkfile $wpdir

 mysqldump -u root -ppassword dbname | gzip -c > $dbbkfile

/usr/local/bin/gdrive-linux-x64 sync upload $bkdir $gdriveid

CRON仕込む。

# crontab -l
07 03 08 */2 * /usr/bin/kusanagi update cert hoge_html
30 04 * * * /root/script/backup.sh
# ls /root/script/backup.sh
/root/script/backup.sh

ちゃんと動いているかは数日後に確認する。

眠いので寝る。

なお、もっといい参考ページがたくさんあります。

http://www.yoshihiro.asia/archives/172www.yoshihiro.asia

knowledge.sakura.ad.jp

こけてた

2016/12/23追記。

CRONはうごいていて、バックアップはされていたけれど、GoogleDriveに同期されていなかった。（Dec 23 19:48 は手でスクリプト実行した分）ツールが資格情報見失ってるとかかな。

# ls -l /home/kusanagi/bkup/
total 63972
-rw-r--r-- 1 root root   107650 Dec 21 04:30 db-3.sql.gz
-rw-r--r-- 1 root root   115290 Dec 22 04:30 db-4.sql.gz
-rw-r--r-- 1 root root   117770 Dec 23 19:48 db-5.sql.gz
-rw-r--r-- 1 root root 21700719 Dec 21 04:30 wp-3.tar.gz
-rw-r--r-- 1 root root 21717966 Dec 22 04:30 wp-4.tar.gz
-rw-r--r-- 1 root root 21732399 Dec 23 19:48 wp-5.tar.gz

github.com

多分これかな？

フルパスにしてまた様子を見よう。

2016/12/24 追記。

フルパスにしたらOKだった。（コードスニペット修正済）

CRONでスクリプトを実行した際に、gdriveのファイル名だけ指定して実行していたところ、パスが通っていなかったようだった。フルパスで実行ファイルを指定したところ問題なく完了した。

2016-12-03

ESP8266をリモコンする～204の衝撃～

Arduino IoT

差し出がましくも ESP8266/ESP-wroom-02 Advent Calendar 2016 - Qiita 参加記事です。

長々と書いていますが、要はこのツィートを太らせただけです。サンプルコードは後ろの方に貼っておくので、そこだけ気になる方は飛ばし読みください。

ESP8266で、定数をもとにform内容を送出していると、毎回入力値が初期値になるのがダルかったのだけれど、204番（ノーコンテンツ）を返せばブラウザの内容がそのまま残ってマジ神だった。すげー手抜きできる。
— 光電/7474 (@koudenpa) December 1, 2016

2016-09-25

私とSeasar2

雑記イベント

昨日24日に Seaser Conference 2016 Final が実施された。

event.seasarfoundation.org

Final と銘打っている通り、同形態での開催はもう行わないそうだ。これは Seasar2 が EOL（End of Life）を迎えたことによる。

最初で最後の参加で厚かましくも懇親会、二次会までついて行ってしまった。 Seasar2はこんなにもエネルギーがある人たちが作ったのだなぁ、と話を聞きながら感慨にふけっていた。

Seasar2（というよりは、SAStruts と S2JDBC）には非常にお世話になった。

（Webアプリケーション）フレームワークにはいくつも触れてきた。 Javaに限っても、日本のメーカーが作った独自フレームワーク（完全にオリジナルからStrutsベースまで）や、Spring2、TERASOLUNA（Spring2.5時代）、そしてSAStruts + S2JDBC。

これらはJavaなので、オープンソースでなくとも（建前上NGな場合もあるが）逆コンパイルでソースを見ることができた。

中にはページネートのためにRDBへのクエリ結果を全件セッションの持つような熱いものもあったが、どれもとても勉強になるものだった。

IDEで参照先をたどっていく癖はこの時期についた気がする。

特にSeasar2に触れた際は、そのプロジェクトが請負、自社開発で比較的自由が効いたこともあって色々弄らせてもらった。

Seasar2徹底入門 SAStruts/S2JDBC対応

作者: 竹添直樹
出版社/メーカー: 翔泳社
発売日: 2010/04/20
メディア: 大型本
購入: 10人クリック: 270回
この商品を含むブログ (31件) を見る

このSeasar2徹底入門を片手に、RequestProcessorを弄ってアノテーションベースの権限チェックを行ったことは忘れられない。思えばライブラリをただ使うだけではなく、必要に応じて弄ることを覚えたのはこの時だっただろうか。

DIコンテナやAOPがどういうものなのかや、各フレームワークをどういう風に実システムで使っていけばいいのかなどがしっかりと書かれていて非常に良い本だと思う。

周辺プロジェクトでは Fisshplate が思い出深い。

詳細設計書と実装で同じことを書くのが非常に嫌だったので、JavaDocの実装を差し替えてFisshplateで元受け指定のExcelファイルを書きだすようにしたことがある。個人的には大ヒットだったのだけれど、Excelファイルを直接編集できなくなったので他のメンバーにはとても不評だった。

これらの経験はエンジニアとしての血肉になっている。

今はSIではなくWeb業界にいるのだけれど、何の因果か（面接時にSeasar2の経験があるといったからだと思うけれど）Seasar2を使ったサービスの保守開発にアサインされたりもした。

まだまだSeasar2との付き合いは続きそうだ。

koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

クライアントサーバアプリケーションへの回帰

Bitbucket Pipelines で PHP のプロジェクトを Deployer する

bitbucket-pipelines.yml