ラベル oss の投稿を表示しています。 すべての投稿を表示
ラベル oss の投稿を表示しています。 すべての投稿を表示

2014年1月1日水曜日

Ansible導入(前編)

2013年からの宿題なのか2014年のお年玉なのか不明だが、確定申告用の領収書類を持ち帰るのを忘れたので大晦日に手持ち無沙汰になっていたのでやってた。後編あるかは不明

Ansibleを使ってできること

  • サーバの構成管理。Chefと同じ目的で使うものという認識
  • 設定として記述したパッケージ・ソフトウェアを簡単に導入できる
  • 冪等性を保ちながらサーバの構築を繰り返し行うことができる(使い方によっては当然冪等性を損なうこともできるけど)

インストール

AnsibleWorksのサイトにあるので参照。たとえば次の方法がある
  • GitHubレポジトリからcloneしてインストール
  • pipインストール
  • yum, apt

ローカルMacにpipが既に入っていたので、pipインストール
$ pip install paramiko PyYAML jinja2 httplib2 
$ sudo pip install ansible

Ansibleで管理対象となるホスト設定を作成

# /etc/ansible/hosts
[experiments]
dev ansible_ssh_port=<ssh port> ansible_ssh_host=<your hostname> ansible_ssh_user=<ssh user>
  • experimentsはAnsible管理のホストをグルーピングしてる
  • devはサーバのニックネーム

Ansibleの動作設定を作成

以降のコマンド実行の際にControlPathが長過ぎて怒られるのを予防。デフォルトは control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r らしいがこれだと長過ぎるみたい。
# /etc/ansible/ansible.cfg
[ssh_connection]
control_path=/tmp/ansible-ssh-%%h-%%p-%%r

テスト

$ /usr/local/share/python/ansible all -m ping
dev | success >> {
    "changed": false,
    "ping": "pong"
}

OKそう。さらにテストしてみる
$ /usr/local/share/python/ansible all -a "/bin/echo hello"
dev | success | rc=0 >>
hello

OKですな

幾つかコマンドサンプル

$ /usr/local/share/python/ansible dev -m copy -a "src=/etc/hosts dest=/tmp/hosts"
#=> ローカルの/etc/hostsをdevの/tmp/へコピー

$ /usr/local/share/python/ansible dev -a "/sbin/reboot" —sudo
#=> devを再起動
$ /usr/local/share/python/ansible -m yum -a 'name=mysql-server state=installed’ dev --sudo#=> devでmysql-serverをyumインストール

しかし、いちいちコマンド打つの面倒くさい。そのため、実行する処理(task)をまとめて記述したもの(Playbook)を使う。

# /etc/ansible/builds_server.yml 
- hosts: experiments
  remote_user: ec2-user
  sudo: no
  tasks:
    - name: test connection
      ping:
    - include: tasks/begins_pkg.yml

# /etc/ansible/tasks/begins_pkg.yml
- name: ensure all packages are at the latest version
  yum: name=* state=latest
  sudo: yes
- name: ensure git is installed
  yum: name=git state=latest
  sudo: yes
- name: ensure apache is running
  service: name=httpd state=started
  sudo: yes

上記を用意した上で、次のコマンドを実行する
$ /usr/local/share/python/ansible-playbook /etc/ansible/builds_server.yml

PLAY [experiments] ************************************************************
GATHERING FACTS ***************************************************************
ok: [dev]
TASK: [test connection] *******************************************************
ok: [dev]
TASK: [ensure all packages are at the latest version] *************************
ok: [dev]
TASK: [ensure git is installed] ***********************************************
ok: [dev]
TASK: [ensure apache is running] **********************************************
ok: [dev]
PLAY RECAP ********************************************************************
dev                        : ok=5    changed=0    unreachable=0    failed=0   

こんな感じで実行結果が出力される。言うまでもないが、

builds_server.ymlで次を記述

  • pingテスト
  • begins_pkg.ymlをインクルード

begins_pkg.ymlで次を記述

  • yum -y update
  • 最新のgitパッケージをyumインストール
  • apacheを起動する(パッケージが無ければインストール)

後編では次のものをする予定
  • EC2イメージからのインスタンスローンチ(Elastic IP貼り付け等も併せて)
  • rbenvベースのrubyインストール


2013年4月27日土曜日

[書評] Trac入門

 真面目な感想とか。

記憶に無いほど昔、前職の同僚が草稿を書いていたので少し見させてもらった。気づいたことや感想を伝えたら最近出版された本を貰った。せっかく頂いた(献本というらしい)のでちゃんと読後の感想を書かねばと思いつつ1つ困ったことがあった。残念ながらTracをちゃんと使った記憶が無いのである。5年以上前に遊びで自宅サーバに入れて触ったことはあった気がするという程度。しかし、Tracはレイアウトというか色合いというか見た目が割と好きな方なので頑張って書いてみたいと思う。

さて、巷にはプロジェクト管理、チケット(課題)管理、バグ管理などを目的とするシステムがあるし、ほとんどの開発者がそうしたものに触っていると思う。しかし、良いツールを使っていてもプロジェクトがうまく回るとは限らない。実際うまくいっていないプロジェクトの方が多いだろう。そうしたなか、こうした入門書で何のためにツールを使っているのかを見直すことには意味があるかもしれない。


Tracを何のために使うか?



  • 基本的なプロジェクト情報の共有
  • マイルストーンの共有
  • 実績の把握
  • テスト状況の把握
  • 課題(チケット)の共有・管理


例としていくつか挙げたが、プロジェクトの状況は常に変化するので常に情報と状況を把握しておくことが重要である。Tracはあくまでその為のツール。


勝手に対象読者を設定



  • 先に挙げた情報をうまく把握できていないと自覚してる人
  • 紙ベースで管理しているがやり方を変えたいと考えている人
  • Excelで管理しているが (ry
  • 迷走している人



本書で得られるもの


話を分かりやすくしようとする為にマンガのストーリもあるので、
こうしたツールに慣れていない人にも利用シーンを想像しやすくなっている。

特に印象に残ったのは、チケット(課題)のフローについての丁寧な説明が
為されていることである。チケットにはデフォルトで5つのステータスがある。


  • new / assigned / accepted / reopened / closed
  • 新規 / アサイン済み / 受け入れ済み / 再開 / クローズ


これらのステータスが、図を使いながら分かりやすく記述されている。
異なるステータスを必要とする場合には新しいステータスを作り、
読者のプロジェクトに合ったフローを作ることができる。
それも深いカスタマイズを必要とせず、設定ベースで簡単に行える。

次に印象に残ったのはGit、CI連携が紹介されている章である。
最近の開発プロジェクトでは分散型ソースコード管理システムを使うことが
多いと思うが、そうした声に応えて加筆されたものと考えられる。


  • Gitの基本的な使い方: リポジトリの作成やブランチの概念
  • GitとTracの連携: 具体的な設定方法
  • TracとJenkinsの連携: JenkinsからTracチケットへのリンク自動作成


内容ではGitやJenkinsの専門書に及ばないものの、
これらのツールの導入を躊躇していた場合には突破口となりうる。

他にも、ガントチャートを使った見える化や
バーンダウンチャートの表示などについての逆引きもあり、
これからTracの導入を考えるプロジェクトには本書をお薦めできる。


その他


Git、Jenkinsとの連携およびベストプラクティスの部分を
もっと厚くした続編があると面白いかもしれないと感じた。

どんな本でも謝辞を目にするとこっちが恥ずかしくなるのは何でだろう。

2012年2月22日水曜日

豆ナイトPresents:続・CI超入門 ~Jenkinsノススメ2~ に参加してきた話

参加を予定していた勉強会が中止になったので、
幸運にも空きがあった標題のイベントに参加してきた。


1. @kohsukekawa 氏による「Jenkinsの導入」

Jenkinsが技術系だけでなく多様な業種の企業で使われている
これにより、多くの現場でCIがいかに有効であるかということが感じられると思う。

テストを書かない傾向が日本では比較的見られる
というのは本当に残念な文化だなと本当に感じる。ただし、今後もっとCIが浸透していくにつれて変わっていくのではないかな。

(CIは)問題があったときの命綱
音で知らせるのとは異なるが、問題があったときに適宜知らせてくれるという点でJenkins (というかCI)は重要であるということ。恒常的に赤になり、意味がなくなることもありがちだけど。

また、「Jenkins導入時にあるとよいもの」として

  • バージョン管理システム (e.g. Subversion, Git)
  • ビルドスクリプト (e.c. build.xml, .bat, Makefile)
  • テストスクリプト
が挙げられた。私が最初に導入した時は、JavaプロジェクトでAntのbuild.xmlを書いて、ソースコードはBitbucketに置いたかな。私も偉そうに言えるほどテストスクリプト書いてないな...

CIを使う利点の1つは、ビルド環境を確認できること
異なるバージョンを開発環境で使っているメンバーがいればビルドエラーになる可能性があるし、ということであった。CIサーバを構築する専門要員というほどではないが、あまり経験ない人に練習がてらビルド環境の構築をしてもらうのも良いなと思った。


2. @tamagawa_ryuji 氏による「Jenkins on Amazon EC2


ビルドの負荷の変動に合わせて自前でHWなどを用意するか?
上記の問いに始まり、EC2の話に突入。最初は何でだろうと思ったけど、確かにマルチ構成プロジェクト (DBにPostgreSQLやMySQLを使ってたりする)で複数の環境で一気にテストを進めたり、負荷が掛かり必要なときにだけスレーブを起動するなど納得できる内容だった。
JenkinsのAmazon EC2 Pluginを使うと、高負荷時にスレーブを自動で起動してビルドするらしい、便利そう。あと、Ubuntu 32ビット版でならとりあえず動くという情報を得られたのはよかった。スレーブ時の起動AMIにはgitなどのツールをインストールしておくことが必要。

セキュリティはどうなのかという点について
Amazon Virtual Private Cloudを使うと社内LANとAmazon DCをIPSecで結ぶことができる。それでも不安な人はAWS Direct Connectを使うと専用接続となるのでもっと安全。私の場合は、そもそも自分で公開環境作るよりはEC2に任せる方がよほど信用できるけど。

おまけ
プレゼントを懸けたクイズググる競争で書籍を頂いた。ありがとうございました。

今年の個人的なテーマがテストとCIなので時間を見て積極的に進めていくつもり。
今日は入門的とはいえ、しっかりした話を聞けたので非常に満足である。
とりあえず会社でもっと使うようにしていかないとな〜

2012年2月20日月曜日

pythonbrewのインストールに少しつまずいた話

pythonbrewをCentOSにインストールしようとした時の話

[root@host ~]# ./pythonbrew-install
Can not get stable-version of pythonbrew.

インストールできない..
そこで、pythonbrew-installの中身を確認

82 STABLE_VERSION=`curl -skL https://github.com/utahta/pythonbrew/raw/master/stable-version.txt`
83 STABLE_VERSION=`trim $STABLE_VERSION`

ここでうまくSTABLE_VERSIONが取れてないのかと思い、シンプルに実行

[root@host ~]# echo `curl -skL https://github.com/utahta/pythonbrew/raw/master/stable-version.txt`

[root@host ~]# 

という訳でやはりstable-version.txtをそもそも取得できていないことが判明。
-sオプションを外して実行

[root@host ~]# curl -kL https://github.com/utahta/pythonbrew/raw/master/stable-version.txtcurl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.


しつこいけど、やはり取れてない。
curlに--insecureオプションを付けてテスト

[root@host ~]# curl --insecure -kL https://github.com/utahta/pythonbrew/raw/master/stable-version.txt1.1
1.1

取れた! ということでpythonbrew-installを変更して実行

[root@host ~]# ./pythonbrew-install
Downloading http://pypi.python.org/packages/source/p/pythonbrew/pythonbrew-1.1.tar.gz
######################################################################## 100.0%
Extracting /usr/local/pythonbrew/dists/pythonbrew-1.1.tar.gz
Installing pythonbrew into /usr/local/pythonbrew

Well-done! Congratulations!

The pythonbrew is installed as:
   
  /usr/local/pythonbrew

After that, exit this shell, start a new one, and install some fresh
pythons:

  pythonbrew install 2.7.2
  pythonbrew install 3.2

For further instructions, run:

  pythonbrew help

The default help messages will popup and tell you what to do!

Enjoy pythonbrew at /usr/local/pythonbrew!!

うまくインストールできた。

おまけ
[root@host ~]# diff pythonbrew-install pythonbrew-install.org 
82c82
< STABLE_VERSION=`curl --insecure -skL https://github.com/utahta/pythonbrew/raw/master/stable-version.txt`
---
> STABLE_VERSION=`curl -skL https://github.com/utahta/pythonbrew/raw/master/stable-version.txt`

2011年11月4日金曜日

[備忘] Struts2 + Spring3をMavenプロジェクト環境で開発する

久々の更新。

本当は使いたくないけどStruts2を使わざるを得ない状況に陥っている。
コードや設定をなるべくの簡素にしたいのでSpring3を組み合わせようと思い
実際に手元で動かしたのでメモ。今回はコマンドベースでなくてEclipseで作業
  • Mavenプロジェクトを作成
    archetypeArtifactIdをmaven-archetype-webappにすることだけ忘れずに。
  • pom.xmlを変更
    必要なコンポーネントを追記する。
  • 
    
            
                org.apache.struts
                struts2-spring-plugin
                2.2.3.1
            
            
                org.apache.struts
                struts2-convention-plugin
                2.2.3.1
            
            
                org.springframework
                org.springframework.beans
                3.0.0.RELEASE
            
            
                org.springframework
                org.springframework.context
                3.0.0.RELEASE
            
            
                org.springframework
                org.springframework.web
                3.0.0.RELEASE
            
            
                org.springframework
                spring-expression
                3.0.6.RELEASE
            
            
                org.springframework
                org.springframework.core
                3.0.0.RELEASE
            
    
    
  • struts.xmlを作成
    actionやらを記述する (アノテーションを使えばこのファイル自体不要な筈)。 今回は1つだけacitonクラス (applicationContext.xmlのBean名)を設定。
  • 
                /success.jsp
                /error.jsp
            
    
  • web.xmlを作成
    ContextParam, Filter, Listenerの設定
  • 
    
            contextConfigLocation/WEB-INF/applicationContext.xml
    
        
            struts2
            org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
        
    
       
            org.springframework.web.context.ContextLoaderListener
        
    
  • applicationContext.xmlを作成
    Beanを設定。actionで設定したクラス
  • 
            
                
            
        
    
  • 動作確認
    http://localhost:8080/Struts2Spring
@mryoshio

2011年7月1日金曜日

チケット管理システム大決戦観戦記

会社で使っているツールとかと比べたいと思い
Shibuya.trac 第12回 - チケット管理システム大決戦 第二弾 - に行ってきた。
仕事を早々に切り上げて大森まで行った。往路で雨降らず本当によかった。


スライドは後でSlideShareで見られるとのことなのでとりあえず話を聞く方に集中した。
Tracは思ったとおり大体なんでもできる。
  • 複数プロジェクトが作られないというのは誤解。関連する複数プロジェクトを作られないというのが正しい表現
  • 行儀の悪いプラグインもあるので注意
  • SQLでレポート自由にできるけど....
  • TracがもしRubyで(ry
というあたりが記憶に残っている。最後の項目には少し物悲しくなった。


Redmineに関してはカスタムタグ作るとそれがうざいとかやっぱりそういうのが出たかーという感じ。でもRoRだとかプラグイン作りたいとかRuby勉強したいとかそういう理由で皆使うものなのか、意外に。会社で一番使ってる人に今日の話聞いてほしかったな。


JIRAはAlfrescoやLiferayでも使われており、
サーバに入れて試したいなと思っていたところだったので、
今日の話を聞いて改めて使ってみるかと思った。
  • やろうと思えばワークフローをGUIで作成可能 (私は作りたくないけど)
  • Javaなので割とうちの人は見られるのでは
  • 有償でもとりあえず¥1,000から始められる。
あたりに惹かれてるかな。
単に仕事で最も接しているBTSだから見慣れているというのが一番大きいかも。
ここは私だけかもしれない、同意してくれる同僚が少なさそう。


Backlogは開発者以外でも使いやすそうなのは良さそう。
金額も抑えて導入できるし選択肢の一つにはなりえると思う。
プランによって使える機能も違うし今後の機能拡張に期待。
Git対応あたりはあった方が良い気がする。


二部の開発プロセスの話も参加した甲斐あったなー。
  • やっぱり付箋は使う
  • あまり分からない人向けにExcelまたはそれっぽい見た目を用意
  • お客さんにチケット状況 (開発状況)を公開
は納得。付箋というか手でささっと書いたりする動作や貼り付ける感触が大事なのかな。


とりあえずJIRAを早くサーバに入れて試してしまいたい。
あと、スイーツが美味しかった。名前チェックしとけば良かった。

スタッフやパネリストの皆さんに感謝。楽しいイベントだった。

2011年5月4日水曜日

Liferayのソースコンパイル

Liferayのソースからのコンパイル方法メモ


  1. Tomcatをダウンロードして展開
  2. LiferayのソースをSVNからチェックアウト
  3. チェックアウトしたツリーのトップディレクトリに移動
  4. app.server.<user>.propertiesを、次の内容で作成
    app.server.type=tomcat
    app.server.parent.dir=<Tomcatトップディレクトリの1つ上のパス>
    app.server.tomcat.version=6.0
    app.server.tomcat.dir=${app.server.parent.dir}/<Tomcatトップディレクトリ>
    app.server.tomcat.classes.global.dir=${app.server.tomcat.dir}/lib
    app.server.tomcat.lib.endorsed.dir=${app.server.tomcat.dir}/lib/ext
    app.server.tomcat.lib.global.dir=${app.server.tomcat.dir}/lib/ext
    app.server.tomcat.lib.support.dir=${app.server.tomcat.dir}/lib/ext
    app.server.tomcat.support.dir=${app.server.tomcat.dir}/lib/ext
    app.server.tomcat.zip.name=liferay-portal-tomcat-6.0-6-branch.zip
  5. ant startを実行
  6. ant deployを実行

これでTomcatを起動すればLiferayへログインできるようになる。
初期ログインは、次の内容で行う。
email: test@liferay.com
password: liferay


以上

Alfresco 3.4 CEのインストール手順

Alfresco 3.4からTomcatバンドル版が提供されなくなったので
Tomcatへ載せる方法をメモ

ダウンロード

  •  alfresco-community-3.4.zip
    •   http://wiki.alfresco.com/wiki/Community_file_list_3.4.c
  • ランゲージパック]
    • http://forge.alfresco.com/frs/?group_id=13



ダウンロードファイルの展開
$ cd /tmp
$ unzip alfresco-community-3.4.zip
$ tar xvzf apache-tomcat-6.0.29.tar.gz


Tomcatの用意とalfrescoファイルの統合
$ cd /opt/alfresco/
$ mv apache-tomcat-6.0.29 com34 && cd com34
$ mv -v /tmp/bin/* ./bin/
$ mv -v /tmp/web-server/conf/* ./conf/
$ mv -v /tmp/web-server/lib/mysql-connector-java-5.1.13-bin.jar  ./lib/
$ mv -v /tmp/web-server/shared ./
$ mv -v /tmp/web-server/webapps/* ./webapps/


DB接続の設定
$ mv -v shared/classes/alfresco-global.properties.sample shared/classes/alfresco-global.properties
$ vi shared/classes/alfresco-global.properties
# DB接続ユーザ/パスワード
db.username=alfresco
db.password=alfresco
# alfrescoデータディレクトリ設定
dir.root=/opt/alfresco/com34/alf_data
# mysql接続設定
db.driver=org.gjt.mm.mysql.Driver
db.url=jdbc:mysql://localhost/alf_com34useUnicode=yes&characterEncoding=UTF-8

DBの作成
mysql> create database alf_com34 character set utf8;
mysql> grant all on alf_com34.* to alfresco@localhost;

ランゲージパックの展開
$ cd shared/classes/alfresco/messages/
$ unzip /tmp/V3.4_ja_JP_03.zip
$ cd .. && unzip /tmp/V3.4_Share_ja_JP_02.zip
$ mv site-webscripts web-extension
JVMオプションの設定
$ cd /opt/alfresco/com34/
$ vi ./bin/catalina.sh
L.86あたりに追加
export JAVA_OPTS='-Xms1024m -Xmx1024m -Xss1024k -XX:MaxPermSize=256m -XX:NewSize=256m -server'

alfrescoの起動
$ ./bin/startup.sh


以上
Top