旅するえんじにあ - Engineers to Travel -

旅するエンジニアの気まま備忘録

【Linux】anyenvで各envを管理

Linux

さて平日の仕事を一時的に休止して毎日カフェでPCをいじる日々です。

今日は前から構築時に使っているanyenvについてです。

日頃いくつかの言語を使うのですが、プロジェクトによってバージョンは違うわけで 統一するのも難しいですよね。 そこで言語ごとにバージョンを管理する~env等を使っているのですが、それも複数出てきて 管理が面倒だったりします。 そんなときのanyenvです。~envを更にまとめて管理してくれる便利なツールです。

これを使えば各言語のenvを管理して更に**envから言語バージョンを管理できるというものです。

では早速インストールです。

# git clone https://github.com/riywo/anyenv ~/.anyenv

そこからbin以下にpathを通します。 それによって~envコマンドが使用可能になります。

# export PATH="$HOME/.anyenv/bin:$PATH"
# eval "$(anyenv init -)"

そこからshellをリフレッシュです。

# exec $SHELL -l

これでanyenvが使用できるようになりました。 どんなenvが使えるのかを確認してみましょう。

# anyenv install -l
Available **envs:
  Renv
  crenv
  denv
  erlenv
  exenv
  goenv
  hsenv
  jenv
  luaenv
  ndenv
  nenv
  nodenv
  phpenv
  plenv
  pyenv
  rbenv
  sbtenv
  scalaenv
  swiftenv

更にプラグインをインストールしてanyenvをupdateできるようにします。

# mkdir -p $(anyenv root)/plugins
# git clone https://github.com/znz/anyenv-update.git $(anyenv root)/plugins/anyenv-update

これでanyenvのupdateが可能になります。

# anyenv update

上記を実行するとupdateが実行されます。

# anyenv update
Updating 'anyenv'...
Updating 'anyenv/anyenv-update'...

各~envのインストールは以下の通りです。

今回は直近必要だったphpenvをインストールします。

# anyenv install phpenv
# exec $SHELL -l

あとは~envを使うときと同じように使うことができます。

anyenvの削除については初期に作った.anyenv自体を削除すればOKです。 色々と面倒なバージョン管理がこれで楽になりますね。

どこかでphpenvの使い方等をできればと思います。

【Mac】切れやすいWi-fiに自動で再接続するshell

mac shell

久々すぎる更新です。

某企業のグループ会社を数年回ってお世話になってたのですが、ついにそこを辞め、完全にフリーとなり 1ヶ月ほど旅に出ていました。

さて、今回は帰ってきてからカフェでWi2へ接続してプログラムやサーバをいじっているわけですがなにせ切れる。 接続してから安定しないのです。 接続してもすぐに切れてしまう。 数秒から数分ごとに切れてしまうため、Macから再接続するのですが、いちいちWi-fiを切って再度入れるという無駄な作業をするわけです。

接続を安定させるためにネットワークの環境設定にネットワーク環境を追加すると良いという記事もあるのですが それでも変わらない場合泣き寝入りするしかないのですが せめてもWi-fiの再接続を自動化できればと思い、簡単なShellスクリプトを書いてみました。

とにかく切れる事象を少しでも軽減させたいだけなので、簡易的且つ雑なものですが。

要はWi2に接続しているが、外部へ接続できているかの死活監視みたいなものです。

サーバでもありがちなのですが、サーバが死んだら接続ができなくなるため それを事前に知りたい場合pingコマンドを使って接続ができているかを確認し、接続できない場合はアラートメールを送るというものの簡易版です。

仕組みとしてはpingを打って実行結果を見てエラーであればつなぎ直しを行う。 これだけです。

さっそくコードです。

#!/bin/sh

while true
do

/sbin/ping -W 3 -t 1 google.com>/dev/null

if [ $? -ne 0 ]; then

    echo "retry"

    networksetup -setairportpower en0 off

    networksetup -setairportpower en0 on

    echo "done"

    sleep 1

fi

echo "OK"

sleep 1

done

ちょっとインデントがおかしいですが、ささっとくんだものでご愛嬌汗

内容としては簡単ですね。 とにかく無限ループさせて、pingを打ちます。 その時にタイムアウトを1秒に設定、1回のみ検査します。

そこから実行した内容が成功していなければnetworksetupコマンドを発行してsetairportpowerをoffにしてからonにするというものです。

接続するまでに多少の時間がかかるのでsleepを入れています。 今のところ2秒以内に接続が完了するので、次pingを打つまでに多少の余裕を持たせています。

echoで再接続時及び繋がっているときはOKが出ています。ここは可視化したいだけなので不要ですね。

Youtubeとかであればストリーミングである程度見れるので、数秒のロスであれば再接続し直してくれて問題なく見れます。 ダウンロードとかも一時停止してくれてそこから再接続してくれるので普段使う感じでなんとか使えています。

にしても月額300円とはいえ接続が切れるのはいただけないですね・・・ 回線も細いっていうのもあるのですが。。。

贅沢は言えないですが、とにかくこれで根本解決とはいかないものの、自動接続してくれるので手間はなくなったかなと。

いいサービスがこれから出てくれればいいんだけどなぁ。

【MySQL】 createしようとしたらエラー Can't create table

MySQL

最近は作るだけの仕事をしていたり、前に作った資産についての質問がきたりで 特に新しい事ができていません。 pull型のDeploy等の仕組みを作ったりしてたのですが、それは今後書いていきます。

さて、今のProjectではMigrationにstandalone-migrationsを使っているのですが それもPHP製のPhinxに変えたいなぁと思いつつ。

そんな中テストデータを何度も入れたり消したりするのにmigrationを繰り返していた時 Can't create table と言われ、急にmigrationができなくなってしまいました。

実際には

 Can't create database 'hoge_database' (errno: 28): CREATE DATABASE `hoge_database` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_general_ci`

みたいな感じです。

手前の作業でpull型のDeployについていろいろやってはいたのですが migrationとは関係ないことをしていたくらいで原因がよくわかりませんでしたが 調べてみると容量が原因でした。

dfコマンドで確認してみると

[root@localhost migrations]# df
Filesystem           1K-blocks     Used Available Use% Mounted on
/dev/mapper/VolGroup-lv_root
                      51475068 48902376         0 100% /
tmpfs                   961152        0    961152   0% /dev/shm
/dev/sda1               487652    57576    404476  13% /boot
/dev/mapper/VolGroup-lv_home
                     249210780   235868 236309056   1% /home

まぁ容量がないわけで。 結局原因は色々な調査をするのにMysql側で設定したquery logと 色んなソースをチェックしていた各Projectの.git/object/packでした。

Totalで40G近くを食いつぶしてたわけで。 ログと不要なソースを削除することによってmigrationができるようになりました。

面倒くさがってlogrotateしてなかったのが原因ですね。

あと、virtual box 自体の容量が少し少なすぎました。 単一Projectなら問題ないだろうと思ってたのですが、複数ものProjectに色んなツールを使って検証をしていたので そこも原因ですね。

virtualboxの容量拡張とlogrotateでも書いていこうかと思います。

【MySQL】 MySQLインストール後、起動に失敗する

MySQL Linux

ひょんなことからGCPで新しい環境を構築することになり（といっても昔で言うLAMP環境のようなもの） PHPやらNginx、MySQLをインストールしているのですが どうしてもMySQLのStartで[FAILED]になってしまう。

MySQLもyumで入れているし、何か指定が必要だったのかとか考えたのですが 推測で物事を進めると良いことがないのでまずはlogを確認します。

するとserviceを立ち上げた時のログの中にERRORが見受けられました。

/var/log/mysqld.log

2016-11-29 11:08:39 1958 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2016-11-29 11:08:39 1958 [ERROR] Plugin 'InnoDB' init function returned error.
2016-11-29 11:08:39 1958 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-11-29 11:08:39 1958 [ERROR] Unknown/unsupported storage engine: InnoDB
2016-11-29 11:08:39 1958 [ERROR] Aborting

Cannot allocate memory for the buffer pool. よくあるやーつです。

実はGCPの環境については f1-micro（vCPU x 1、メモリ 0.6 GB） という要は最低スペックで作られているので、メモリも600Mちょっとしかなかったのです。

freeコマンドでSWAP領域を確認してみると

# free
             total       used       free     shared    buffers     cached
Mem:        604380     159344     445036        156       2260      19948
-/+ buffers/cache:     137136     467244
Swap:            0          0          0

案の定SWAP領域がありませんでした。

ということで、SWAP領域を作ります。

# dd if=/dev/zero of=/swapfile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 26.8912 s, 39.9 MB/s

次にSWAP領域を有効にします。

# mkswap /swapfile
# swapon /swapfile

これでMySQLが起動できるようになるはずです。

【python】 pythonのバージョンアップ 2.6系から2.7系へ

python

Google Cloud Platformってもう最近でもないんですが すごく便利なものが出てきましたね。 AWSのS3みたいなものなんでしょうか。 使ったことないのですがね・・・

さてGoogle Cloud Strageを使おうと色々と設定し、shellを書いたり 自動化したりを進めていたんですが、少し時間がかかってしまい 久々にいじってるのですが(別途この辺は書く予定です) バージョンを確認すると

[root@localhost deploy]# gsutil version
Warning: You are running Python 2.6, which stopped receiving security
patches as of October 2013. gsutil will stop supporting Python 2.6 on
September 1, 2016. Please update your Python installation to 2.7 to
ensure compatibility with future gsutil versions.gsutil version: 4.19

どうやらpythonのバージョンが古いようで、8月いっぱいでサポート止めるよとのことです。 そのため、2.6系から2.7系にアップデートが必要なのです。

はいはい、わかりましたそれではアップデートしましょうと 簡単にいくわけにはいかないなぁと。

なぜかと言うと今使っている環境はCentOSなんですが とてもお世話になっているyumコマンド このコマンドpython製なんです。

同じ2系だから互換性はあると思うのですが 本当に大丈夫なのか。

yumに関しては/usr/bin/yumをエディタで開いて 1行目のpythonバージョン指定とかすればいいような気がするんですが その他のpythonは大丈夫なんだろうか。 そういったところで危ないっていう人もいるのですが、調べるとそれだけで設定して問題がない人がいるようなのでその設定で一回様子を見ようと思います。

さて現在インストールされているpythonのバージョンは

# python --version
Python 2.6.6

ちょっと古いようですね。 現時点での2系最新バージョンは2.7.9です。 まずはソースを落としていきます。

# cd /usr/local/src
# curl -O https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tgz

次に解凍していきます。 余談ですが、解凍というはオジサンらしいです。展開が正しい言い方なのかな。

# tar zxf Python-2.7.9.tgz

さて展開したところでインストールしていきます。

# cd Python-2.7.9
# ./configure
# make && make altinstall

コンパイルが終わるとpythonファイルができています。 バージョンを確認してみましょう。

# /usr/local/src/Python-2.7.9/python --version
Python 2.7.9

バージョン上がってますね。 これをbinに入れていくのですが、既に/usr/bin/以下には既にpythonがいると思います。 注意はこれがシンボリックリンクになっていないかってところでしょうか。

一旦現行バージョンをバックアップして置き換えていきます。

# mv /usr/bin/python /usr/bin/python2.6.6

次に先ほどmakeしたpythonを置き換えていきます。

# cp /usr/local/src/Python-2.7.9/python /usr/bin/python

さてこれで完了と思いきや、冒頭に話したyumの部分ですね。

# vim /usr/bin/yum

#!/usr/bin/python
↓
#!/usr/bin/python2.6.6

これでOKです。 ここに関しては賛否両論あるので、python関係で何かおかしかったら思い出すようにしましょう笑 因みに上記のyumの書き換えをしないとyumが使えなくなるので気をつけましょう。

【Jenkins】 Jenkins権限設定のミスによりログインができなくなった

CI環境 Jenkins

最近はDeployやらCI環境の構築やらを少しやらせてもらっています。 CIといえばJenkinsですね。 あの紳士なくしてCI環境はと言われるくらいです。

さてそんなJenkinsのバージョンアップ等やっていたのですが グローバルセキュリティの設定を誤って設定してしまった為に、閉めkinsになって どのユーザでログインしても「全体/Read パーミッションがありません。」のようなエラーで鬼kinsになる・・・

要は権限管理を間違えて保存すると、どのユーザでも設定のし直しができなくなる。 要は完全に閉め出されるわけです。

そうなった時の対処法です。 もちろんJenkins Wikiにも対応方法が載っています。

Disable security - Jenkins - Jenkins Wiki

せめてそうなった場合とかってどうしようもなくなるし、そうなることを望む人は少ないと思うので 何か警告とか出してもいいような気がするんだけど・・・

まずはJenkinsを停止させます。

service jenkins stop

もしくは

/etc/init.d/jenkins stop

次にconfig.xmlを編集します。

JENKINS_HOMEは各インストール時に設定していると思いますが デフォルトだと/var/lib/jenkinsがJENKINS_HOMEになっていると思います。

編集の前に何かあったらアレなので、バックアップをとっておきましょう。

config.xmlを編集します。

ここはtrueになっているのでfalseに書き換えます。

更に以下2つのタグ内及びタグ自体を削除します。

Jenkinsを再起動します。

久々に鬼kinsを見ました。 さぁまた権限設定に戻るかなぁ。

【PHP】 PHP製のDeploy tool deployerでdeployを試す

deploy php

最近はMySQL partitionのPHPUnitテストとか記事にもならないようなニッチなことをやっていたわけで。 PHPUnitでpartition削除とかDBテストでできればいいのにとか思いつつ、ゴリゴリ書いてたわけで。

ちょっと息抜きに。

Capistranoでdeployをすることが多かったのですが、PHP製のDeployも試してみようと思って Deployerを使ってみたので、簡単に紹介したいと思います。

その前に今回作った簡単な環境ですが VirtualBoxを2つ立ち上げ、Linuxのlocal環境を2つ用意しました。

192.168.56.10 <--------> 192.168.56.11

192.168.56.10 こちらのサーバをWEBサーバに見立て、deploy先とします。

192.168.56.11 こちらのサーバをdeployサーバとし、deploy元とします。

なので、deployツールを192.168.56.11にインストールしていきます。

deployerインストール

composerのように

wget http://deployer.org/deployer.phar

こんな感じでdeployer.pharをDownloadします。

mv deployer.phar /usr/local/bin/dep

こんな感じでbinへ突っ込んでcommandで使えるようにします。

composerでインストールすることも可能です。

今回は新しいサーバにペロッとインストールしてさくっとdeployしてみたかったのでcomposerではなく、直接ダウンロードしました。

ソースを確認したい場合は以下にてcloneするなりして確認しましょう。 https://github.com/deployphp/deployer

ここからディレクトリを自分で作っていきます。

deployer 設定

自分が作ったディレクトリは以下の通りです。

deploy
├── config
│   ├── parameters.yml
│   └── servers.yml
├── console
└── deploy.php

parameters.ymlファイルとconsleディレクトリは空でいいので作成だけしておくものらしいです。 まず、deployというディレクトリに必要なファイルをまとめることにしました。

1つずつ見ていきます。

servers.yml

localhost:
    host: 192.168.56.10
    port: 22
    user: root
    identity_file:
        public_key: ~/.ssh/id_rsa.pub
        private_key: ~/.ssh/id_rsa
        password: ''
    stage: localhost
    deploy_path: /tmp/project
    branch: master

192.168.56.10、192.168.56.11双方で鍵認証できるように 双方のauthorized_keysを作成し、鍵認証でsshできるようにしておいてください。

因みに今回はid_rsaにはPassword設定はしていません。

ここにはそれぞれサーバ毎の設定を書いていきます。 ここで注意しなきゃいけないのはidentity_fileのpassword部分です。 設定の仕方がさらっと調べただけでは出てこなく、passwordを設定項目に含まない場合 deployの度にパスワードをきかれます。 しかも、実際には鍵認証ができているので空エンターで処理が続行されるのです。

どうすればいいのかわからずに結局build前のソースを読んで解決したのですが、納得いかないです・・・

細かくは書きませんが、設定値の情報はBuilder.phpで実行されるようです。 identityFileを設定した場合は必ずパスワードチェックが走るのです。

因みにidentityFileで指定するpublic_keyとprivate_keyはデフォルト ~/.ssh/id_rsa.pub ~/.ssh/id_rsa となっているので、同じであれば特に設定しなくてもOKです。

stageはコマンドでの引数でEnvironment用にlocalhostとしました deploy_pathはdeploy先(192.168.56.10)のどこにdeployするかのpathです。

これで設定ファイルの記述は完了です。

次にdeploy.phpを記述していきます。

<?php
require 'recipe/composer.php';
serverList('config/servers.yml');
set('repository', 'git@git.example.jp:/xxx.git');

これだけになります。

deployer 実行

早速実行してみましょう。

[root@localhost deploy]# dep deploy localhost
✔ Executing task deploy:prepare
✔ Executing task deploy:release
✔ Executing task deploy:update_code
✔ Executing task deploy:shared
✔ Executing task deploy:vendors
✔ Executing task deploy:symlink
✔ Executing task cleanup
➤ Executing task success
Successfully deployed!
✔ Ok

こんな感じでdeployが完了します。

流れとしては

  • ssh接続
  • リリースディレクトリ作成
  • gitからのcheckout or clone
  • sharedに移すファイルがある場合はファイルもしくはディレクトリを移動 ※これはset('shared_dirs', [application/logs, directory/path]);のような形でsharedディレクトリに退避できる。
  • composer installを実行
  • deployしたディレクトリにシンボリックリンクを貼る
  • 世代管理数を超えるリリースディレクトリ以下のソースを削除する
  • suucessfully deployed!を表示

早速192.168.56.10側のdeploy_pathに指定した/tmp/projectを確認してみると

drwxr-xr-x   4 root root 4096  5月 27 10:31 2016 .
drwxrwxrwt. 11 root root 4096  5月 27 10:31 2016 ..
lrwxrwxrwx   1 root root   36  5月 27 10:31 2016 current -> /tmp/project/releases/20160527011759
drwxr-xr-x   5 root root 4096  5月 27 10:31 2016 releases
drwxr-xr-x   2 root root 4096  5月 26 13:04 2016 shared

見たことあるような感じでdeployされていますね。

何度かdeployしてみたのですが releaseを見る限り

drwxr-xr-x 5 root root 4096  5月 27 10:31 2016 .
drwxr-xr-x 4 root root 4096  5月 27 10:31 2016 ..
drwxr-xr-x 8 root root 4096  5月 26 19:42 2016 20160526102859
drwxr-xr-x 8 root root 4096  5月 26 20:05 2016 20160526105235
drwxr-xr-x 8 root root 4096  5月 27 10:31 2016 20160527011759

デフォルトで3世代管理されているようですね。

ここの世代管理を変更する場合は

deploy.phpに

set('keep_releases', 5);

keep_releasesの値を設定してあげると変更されます。

以後、deployerがCapistranoと同様に使えるのかを少しずつ追っていきたいと思います。