Subscribed unsubscribe Subscribe Subscribe

oinume journal

No programming, no life

Building Vagrant box from VirtualBox OVF

www.packer.io

I realized that Packer can build Vagrant box from VirtualBox OVF file not only from ISO image. Building Vagrant box takes much time to run an installer so I'm very happy to skip the step.

I created Ansible installed Vagrant box from another box to try.

  1. Run 'vagrant box add oinume/ubuntu-14.04-jp'
  2. Downloaded box is stored in ~/.vagrant.d/boxes/oinume-VAGRANTSLASH-ubuntu-14.04-jp/1.0.1/virtualbox and box.ovf is in the directory.
  3. Specify the path of .ovf like below in template.json and run 'packer build template.json'
  4. 'ubuntu-14-04-x64-jp-ansible-virtualbox.box' created.

Ansible: Up and Running

Ansible: Up and Running

RDS(MySQL)のバイナリログはすぐ消えるから注意

これ知らないとハマるかもしれないのでメモ。

docs.aws.amazon.com

に"Amazon RDS normally purges a binary log as soon as possible"とある通り、RDSではバイナリログはすぐ消えてしまう。もし自前でスレーブを立てたりするためにバイナリログをある程度とっておきたい場合は、

call mysql.rds_set_configuration('binlog retention hours', 24);

のプロシージャを実行してバイナリログの保持期間を伸ばすことができる。

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

AnsibleでPlaybook流した時のgit commit hashをファイルに出力したら捗った

「このサーバにどこまでPlaybook流したんだっけ?」みたいなことでよく悩んでいたので、AnsibleのPlaybookが入ったリポジトリのgit commit hashをファイルに出力してそれをサーバーに置くようにしてみた。

こんな感じのアクションをPlaybookに書いて簡単にできた。

- local_action: shell /usr/bin/git show -s --format=%H > /tmp/version.txt
  sudo: False
- copy: src=/tmp/version.txt dest=/var/tmp/version.txt

入門Ansible

入門Ansible

新年の抱負の進捗どうですか?

oinume.hatenablog.com

こんな感じの新年の抱負を書いたのだけど、そろそろ2015年も40%経過したので進捗報告。

Dockerを実戦投入する

進捗ダメです。やっと個人でDockerを使い始めたレベル。

英語でブログエントリーを書く割合を25%にしてみる

この2つは英語でかいて、あとひとつは日本語なので今のところ達成!しかしそもそも激烈にブログ頻度が低下しているのでそっちの方がやばい。

フロントエンド(Web)を頑張る

これは個人的なキャリアの方向転換により諦めました()

Reactive Programmingをちゃんと理解する

これも個人的なキャリアの(ry

アルゴリズムを深く理解する

進捗ダメです... インプットはしてるけどアウトプットをしていないので完全に身になってない。

方向転換

やっぱり自分はサーバサイドエンジニアとして頑張っていこうと思ったので、今後は機械学習とか自然言語処理を頑張っていく所存です。

開発スピードと技術的負債

よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。

理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。

というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作っているのです)