NOBODY:PLACE

【メモ】Chefがバージョンアップしてライセンスエラーが出るようになった【#np2020】

「Chef」が100％オープンソースに | OSDN Magazine
設定管理ツール「Chef」を開発する米Chefは4月2日、Chefソフトウェアを完全にオープンソースとして公開することを発表した。ライセンスはApache License 2.0で、商標ポリシーが守られている限りソースコードの使用、配布、収益化に制限を設けないという。　Chefはこれまでコア部分のみがオープンソースとして提供されていたが、今回プロダクトコードのすべてをオープンソースとする。これによりコミュニティの目標とChefの目標を連携させることができ、より良いソフトウェアの構築につながると期待を寄せている。　ライセンスは、Chef Infra、Chef InSpec、Chef Habitatと一貫性のあるApache License 2を採用、商標ポリシーが守られている限り、ソースコードの使用、配布、収益化に制限を設けないとしている。今後、Chefチームが生成するソフトウェアはすべてオープンなリポジトリに入り、ロードマップなどの製品開発プロセスについてもオープンにしていくという。

Chefがオープンソースになった影響なのか、ver.15からライセンスへの同意を設定ファイルに含めないといけなくなったらしく、そのままではエラーが出て動かない。

==> default: Chef Infra Client cannot execute without accepting the license Chef never successfully completed! Any errors should be visible in the output above. Please fix your recipes so that they properly complete.

ドキュメントを読むとvagrantではこう追加せよとあったのでやってみたんだけど……

Accepting the Chef License — Chef Docs
Vagrant This license acceptance can be done via the arguments API:

config.vm.provision "chef_zero" do |chef|
chef.arguments = "--chef-license accept"
end

怒られた。

==> default: /opt/chef/embedded/lib/ruby/gems/2.6.0/gems/mixlib-cli-2.0.3/lib/mixlib/cli.rb:230:in `parse_options’: invalid option: –chef-license (OptionParser::InvalidOption)

「–chef-license」っていうオプションなんか知らねーって言われてるみたい。多分、何かをアップデートしたら動くようになるんだろうなと思いつつ、面倒くさかったのでドキュメントにあったもうひとつの方法「Chefのバージョンを固定する」を試す。

config.vm.provision "chef_zero" do |chef|
chef.version = "14.12.3"
end

無事、vagrant起動。初めからこうしておけばよかったんや…… とはいえ、バージョンアップしないというのもアレなので、そのうち何かしたいと思います。どうしたらいいかわかんないけど。誰か教えてください。

【メモ】ファイルを変更していないはずなのにgit pullでmerge出来ない場合

最近ずっと Ansible の勉強をしています。次に導入するサーバの設定を Ansible で設計・反映させる予定だからなんですが、ぶっちゃけ1台だけのサーバなら直接コマンド入力で設定した方がずっと早いし、Ansible を使う意味は限りなくゼロに近いです。でもまあ最近の環境構築ではこういう技術を使うのがスタンダードだって言うし、身につけておいたらどこかで役立つかも知れないので勉強がてらやってるって感じです。サーバを実際に設定できるようになるのはいつになることやら。で、Ansibleを触っているとよくこの言葉を見掛けます。 「冪等性」 漢字だとわかりづらいですが、「べきとう」というひらがなであればどこかで聞いたことがあると思います。プログラミングでは割と普通に使われる単語です。

冪等 – Wikipedia
数学において、冪等性（べきとうせい、英: idempotence　「巾等性」とも書くが読み方は同じ）は、大雑把に言って、ある操作を1回行っても複数回行っても結果が同じであることをいう概念である。まれに等冪（とうべき）とも

タスクをチケット管理する（物理）

タスク管理のためのツールは色々ありまして、僕自身も業務ではRedmineとGitHubのPRとissueを組み合わせる感じで管理しています。詳細が誰にもわかる形で残るし、関連情報や関連チケットを紐付けたり担当者を明確にしたり期日をはっきりさせたり、あるのとないのとでは大違いです。超便利。ただ、自分自身のちょっとしたタスクという点で言うとちょっと大仰なんですよね。チームで動いていて情報を誰かと共有する必要がある、タスクのサイズが割と大きめである、PCで参照すること前提に情報を記載したいなどの要件があれば便利と言えるんですけど、小さいサイズのタスクを備忘録的に使うのには向いてません。そういうレベルのタスク管理で昔から使われているのが「付箋」で、デスクトップ上に付箋を再現するソフトウェアもたくさんリリースされています。使ってみたこともあるんですが、ウィンドウの下に隠れてしまうのが不便、かつ、ウィンドウの下に隠れない（常に最前面に表示）とそれはそれで邪魔というなんとも微妙な感じがあって、使うのを止めてしまいました。それ以来iPhoneのメモにあるチェックリストを使ったり、試行錯誤していたんですが、最近引き出しの中に昔ながらの「付箋」があることに気付いて使ってみたら、まあなんというか、便利ですよね。細かい情報を記載するのには向いてませんが、

タスクをなるべく小さく分割する
付箋1つに記載するタスクは1つだけ
最小限の動きで見える部分（かつ邪魔にならない場所）に貼っておく
終わったら終わった端から捨てる

というルールを作って運用してみたら、あら便利。年配の方や非技術者の方には「お前今さら何言ってんだ」と言われるかも知れませんが、いやあ、なんでもかんでもデジタルにしたがるもんなんですよ技術者ってのは。確かに検索機能とかリンク機能とか、デジタルじゃないと上手く機能しない機能ってたくさんありますし、便利だとも思うんですけど、アナログで十分って言うこともたまにはありますよね。僕にとってはそれがこれでした。

運用上の注意

ちょっと運用してみて思ったことをざっくりと。

つい付箋にあれこれ書いてしまいがちなのを控える
詳しいことが決まっていない案件は大枠だけ書いておけばOK（上の画像の「Laravel」みたいに）
要件が決まったらそれに合わせてチケットを細かく切る
情報が少ないので付箋だけで完結させるのは不可能。別にドキュメントがあることが前提
終わったら即捨てる。容赦なく捨てる

アナログでいいとはいえ、詳しい情報を残せないのはつらい。そういう意味ではきちんとドキュメントも残して、そこからタスクを切り出す際のUIとしてチケット（物理）があるという感じの捉え方です。今のところGoogleドキュメントに残していますが、情報が増えてきたらGitHubのwikiに移行するかもしれません。以前はPukiwikiをサーバに入れて運用していたこともあるんですけど、なかなかねえ。情報が散乱しがちで、綺麗にまとめるの難しいんですよね。かといって記憶しておくってのは不可能だし。趣味でプログラミングしてる人はこういうのどうしてるんでしょうかね。趣味でもきちんとタスク管理してるのかしら。

【メモ】Vagrant で共有フォルダのマウントに失敗する

試したいことがあって通常使用しているのとは別にテスト用にレポジトリをcloneしてVMを作るということをしたらば、次の様なエラーが。

Vagrantで共有フォルダのマウントに失敗するときの対処方法 – Qiita
Failed to mount folders in Linux guest. This is usually because the “vboxsf” file system is not available. Please verify that the guest additions are properly installed in the guest and can work properly. The command attempted was: （中略） The error output from the last command was: /sbin/mount.vboxsf: mounting failed with the error: No such device

要するに共有フォルダがマウントできない、そもそもvboxsfが見つからんと言われているみたいです。Guest Addtionsがちゃんと読み込まれてないっぽい？上記エントリではプラグイン「vbguest」をインストールしておけば解決してくれると書かれているのですが、僕の環境ではどうも解決してくれない。「解消しない場合」という項目にあったこちらを参照したところ、逆に「vbguest」が問題になるケースがあるとのこと。つまりこう：

vagrant-vbguestプラグインがGuestAdditionsを無効にしてしまう – Qiita
VirtualBoxのバージョンとGAのバージョンが異なるためvbguestプラグインがGAの再ビルドを始める
インストール済みGAが削除される
アクティブなkernelと同じバージョンのkernel-develをインストールしようとするが、より新しいkernelが公開されているのでみつからない
GAのビルドが失敗し、GAが動作しない状態に

なるほど。結局どうしたらいいかっていうと、Guest OSのkernelをアップデートすれば幸せになれるらしいので、次のコマンドを実行。

$ vagrant ssh -c 'sudo yum update -y kernel'
$ vagrant reload

その上で vagrant reload してやると、

正しい kernel-debel を取得する
正常に GuestAddtions が更新される
正常にマウント出来る

という流れで無事起動に成功。軽くハマって余計な時間食っちゃった。とりあえず直って良かったです。感謝。

gettextのmo/poファイルを更新したらApacheを再起動する

サイトを国際化するにあたってgettextを使って、mo/poファイルを作って翻訳を行うということはよくあり、今触っているシステムでもFuelの下で（Fuelのi18nは使わずに）gettextを使って日本語版と英語版の切り替えを実現しています。当然、このファイルは頻繁に更新されるわけですが、ローカルで確認していると更新後にロケールが正しく取得されずに日本語版で英語が表示されてしまうことがよくあります。何度かページ更新したり、時間をおいたりすると直るんですが、ローカルならまだしも本番環境で同じことが起こったら軽く事故ですね。ファイルサイズとかサーバスペックとかでキャッシュ更新タイミングが決まってるのか、運良く本番環境では発生していなかったようですが。

道具へのこだわりとパフォーマンスと

「シンプル志向」と他人の意見を聞くことと

昼間、エンジニアのパートタイムな仕事再開して5ヶ月経ちます。以前は自分が仕切ってやっていた開発ですが、今は自分より全然優秀な（そしてきちんとコミュニケーション能力があり、すぐに結果を出せる）エンジニアが上にいてくれるので、すごく気が楽です。もうね、方針とかコーディング規約とかプロジェクト進行の細則とか、好みちゃうのって思うような小さいところまで全部おまかせにして、それに従うようにしています。僕の好み通りにコーディングしたところで、僕がずっとこの会社にいるわけでもないのでね。それなら、統一性があった方がずっといい。