プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

AndroidStudio のインストール (Windows環境)

いままで、Androidの開発は、Windows ホスト上の Ubuntu で eclipse+ADT でやってました(わざわざこんなことしてるのは、仕事単位で開発環境をいろいろと切り替えられるようにと、開発環境をいろいろといじって不安定になったときスナップショットで巻き戻してリカバーすることを可能にするためです)。

いい加減、AndroidStudio に移行したいなと思いつつも、お客さんとの絡みもあり、延び延びになってました。が、最近になってやっと AndroidStudio に移行できることになったので、やったと思い、Ubuntu上で環境を作ってみたら、これがなんと!話にならないぐらい遅くて、まあ、仕事で使い物になりません。

というわけで、当面は、ホストOS側のWindows上にAndroidStudioでの開発環境を作って対応することにしたので、環境構築についてメモにまとめておきます。 なお、(仮想マシンの)ubuntu上でのAndroidStudio開発構築についても、あきらめてはいないので、後日再トライしてみたいと思います。

インストール準備

AndroidStudio のインストールページ を見ても、あまり詳しく書いてありません。JDKも必要なのに、それすら(明確には)表記されてないです。

ということで、AndroidStudio のインストール準備として次のものをインストールしました。なお、OSは、Windows10 (64bit) です。

どちらもデフォルト設定でのインストールです。Java はインストール後、環境変数に JAVA_HOME を追加しておきます。

インストール

インストール準備ができたら、AndroidStudioのインストールです。これは特に問題もなく画面の指示に従ってインストールすれば終わります。

インストールが終わったら、プロジェクトの新規作成を行ってみます。これも画面の指示に従って選択していけば、問題なく完了し、AndroidStudioが立ち上がります。 仮想マシン上で試したときは、このときの初回ビルドがいつまでたっても終わらなかったのですが、今回の場合サクッと終わって、快適です。

VCSの有効化

Git を使うには、AndroidStudio を開いた状態で、メニューの『VCS』→『Enable Version Control Integration』 を選択します。バージョン管理システムの選択画面が表示されるので、gitを選択すると、gitリポジトリが、AndroidStudioプロジェクトのルートに作成されます(つまり、プロジェクト単位で作業を行う必要があります)。

この点は、eclipseと違いますね。eclipseの場合、プロジェクトのディレクトリと同じディレクトリにリポジトリを作るのは推奨されていませんでした。

ちなみに、当初は、AndroidStudio自体にgitのクライアント機能が含まれると思っていたのですが、gitインストール前だと、このメニューを選択してもエラーになります。おかしいな、と思ったら、ご自分の環境にgitがインストールされているか確認してください。

既存eclipseプロジェクトのインポート

既存eclipseプロジェクトのインポートもやってみます。移行手順も示されているので、その通りに作業するだけです。

  1. メニューの『File』→『New』→『Import Project』を選択します。
  2. インポート元のeclipseプロジェクトを指定します。この際、AndroidManifest.xmlが存在するディレクトリを指定してください。
  3. あとは、そのまま画面の指示に従えば、インポート処理が行われます。
  4. インポート後、いくつかエラーができることがあります。手元のプロジェクトの場合、下記のエラーなどがありました

    • gradle/wrapper.properties 内のバージョン番号の修正
  5. エラー修正後、ビルドに成功すれば、まあ、インポート成功です。

あとは、インポートした場合は、.gitignoreが存在していないので、適当な .gitignore を作成してgitにコミットすれば作業完了です。

(参考) インポートについてはこれなど詳しかったです

Android StudioにEclipseで作成したAndroidプロジェクトをインポートする - Narrow Escape

はてなブログに移行しました (2/2)

前の記事に引き続き、ここからは実際の移行作業について、メモを残したいと思います。

主な流れは、

Joomla! -> Wordpress -> はてなブログ

です。

以下、バージョン情報です。

  • Joomla! 3.6.2
  • Wordpress 4.5.3
  • FG Joomla to WordPress 3.15.3

Wordpress の立ち上げ

まず、Joomla!のコンテンツをWordpressに移行するため、Joomla!を運用しているのと同じサーバーでWordpressを立ち上げます。 森ソフトは、さくらインターネットで運用しているのですが、さくらインターネットのレンタルサーバーには、クイックインストールという機能があり、Wordpressはそちらで簡単にセットアップできるようです。

help.sakura.ad.jp

手順通りにすれば、問題なくWordpressが立ち上がりました。

Joomla! サイトのコンテンツをWordpressに移行

次は、Wordpressの管理画面に入り、『プラグイン』から『新規追加』を選択します。プラグインの検索で、『FG Joomla to Wordpress』を探すと、すぐに見つかります。

f:id:junichim:20160826101110p:plain

問題なくインストールができれば、プラグインを有効にします。 プラグインが有効になったら、『プラグイン』→『FG Joomla to WordPress』の『import』を選択して、インポートを開始します。

インポート作業は、画面に従ってオプションを指定するだけです。 Joomla!のサイトおよびデータベースへの接続情報を正しく入力しておきます。『Test the database connection』を実行して正しく接続できることを確認しておいてください。

その他のオプションとしては、

  • Automatic removal : チェックを入れる(インポート前のコンテンツをすべて削除するため)
  • Import introtext : to the content を選択
  • Archived post : not imported を選択
  • Medias : Force media import. Keep unchecked except if you had previously some media download issues. : チェックを入れる

としました(他はデフォルトだったはずです)。

これで準備ができましたので、『Start/Resume the import』ボタンを押すとインポートが始まります。 問題なくインポートが完了したら、画面の一番下にある『Modify internal links』ボタンを実行して、内部リンクを更新しておきます。

画像もインポートしてくれるんで、非常にありがたいです。

なお、このプラグインを利用した際に、若干注意するべき点がありました。こちらにまとめてありますので、気になる方はお読みください。

Wordpress のコンテンツをはてなブログにインポート

さて、無事にJoomla!のコンテンツをWordpressにインポートできれば、次は、Wordpressのコンテンツをエクスポートします。 管理画面から『ツール』→『エクスポート』とすすみ、『すべてのコンテンツ』を選択して、『エクスポートファイルをダウンロード』とすると、コンテンツの内容がファイルにエクスポートされます。あ、エクスポート前に、不要な記事やカテゴリ・タグなどがあれば、消しておきます。

次に、エクスポートしたファイルを、はてなブログ側の『インポート』で指定すれば、記事のインポートは完了です!インポートの形式として、WordPress形式を指定してください。 はてなの場合、記事にインポートに続き、画像のインポートをしてくれます。これは、インポート元のサイトから画像のURLを使って、記事内の画像をすべてコピーして、はてなフォトライフに保存してくれるというものです。これは素晴らしいですね!

なお、この際、下記の点に気を付けてください。

  • 元サイトにアクセスできないと画像のインポートができません
  • 一度インポート後、インポートをやり直したい時があると思います。そのとき、『インポートの削除』を実行すると、記事は削除されますが、画像は削除されません。なので、引き続き同じサイトからインポートすると同じ画像が保存されることになります。

後者のような場合は、再インポート前に、一旦、はてなフォトライフに移り、インポートした画像を手作業で削除したほうが良いかもしれません。なお、はてなフォトライフ側には、『使用中の画像をチェックする』とか『未使用の画像をチェックする』のような機能はないので、あとから作業しようとすると結構大変そうな予感がしました。

これで、基本的にはインポートができるのですが、残念ながら、これですべて完了とはなりません。 いくつかの点については、手作業で対応する必要があります。今回の移行作業で行った部分を以下に書いておきます。

SyntaxHighLighterの導入

元々、コードの表示には、SyntaxHighlighterを利用した、Joomla!のプラグインを使っていました。はてなブログのシンタックスハイライト機能を使ってもよかったのですが、既存の記事に対する修正が不要になるので、Syntax Highlighter を使うことにしました。

Syntax Highlighter の使い方は、ネットを調べるといくつか出てきます。

はてなblogでsyntaxhighlighter.autoloaderをつかってC#ソースコードをきれいに表示させる方法 - kaz16a's blog

SyntaxHighlighterのautoloaderの使い方 Ver 3.0 | Asterlist

はてなブログの場合、『デザイン』を開き、『カスタマイズ』(スパナの画像)タブを選択し、『サイドバー』を選択します。 『モジュールを追加』をクリックし、『HTML』を選択します。その内部に、Syntax Highlighter を使うための設定を記述します。 今回は下記の様な、Autoloaderを使う設定にしています。








なお、jsファイルやcssは自分が利用可能な適当なサーバーに配置するのがおすすめです。ちなみに、

http://alexgorbatchev.com/SyntaxHighlighter/hosting.html

を見ると、公式にホストされたものもありますが、きっと負荷も高いでしょうからあくまでもご参考までに。 これで、コードのハイライト表示は完了です。

画像以外のファイル置き場

はてなブログですが、画像は、はてなフォトライフに保存されますが、それ以外のソースコードのファイルやその他各種のファイルは、アップロードすることができません。

調べてみると、はてなブログのproであれば、はてなダイアリープラスが利用でき、そちらに任意のファイルをアップロードする機能があるので、それを使うことも可能です。

crunk.hateblo.jp

ですが、ちょっと試してみましたが、なんとなくいまいち。要は、はてなダイアリーはアップロード先としてだけ使いたくて、公開する必要もないのですが、公開設定にしないとリンク先が正しく表示されません。 まあ、元々の目的が違うんでしょうね、きっと。

ということで、dropboxに公開用のファイルを保存しておき、共有リンクでダウンロード可能としました。 なお、dropboxに置いたファイルをscript等で使う場合(.jsファイルを読み込むとか)は、リンクURLのパラメータでdl=1を与えるように変更します。

How do I force a file or folder to download or render on dropbox.com? - Dropbox のヘルプ - Dropbox

このようにしないとダウンロードが始まらないため、scriptファイル等を読み込めなくなります。

内部リンクの修正

さて、実はこれが一番手間がかかりました。 はてなブログでは、Wordpressのコンテンツのインポートはしてくれるのですが、同一サイト内の記事間の内部リンクの修正はやってくれません。そのため、ある記事内で別の記事を参照していたりすると、すべてインポート元(この場合は、Wordpressのサイト)を指してしまいます。

まあ、昔の記事で修正する意味がどれだけあるかは難しいところですが、一応過去の資産と考えて、修正しました。

一応、リンク切れについては、

リンクチェッカー(リンク切れチェックツール) dead-link-checker.com

などを使ってチェックできるので、これでエラーになった箇所で、かつインポート元を指しているものについて、一つずつ確認して、手作業での手直しになりました。

※本当は、一旦、はてなブログにインポートして、記事のURLがどう変化するかを把握して、Wordpressからエクスポートしたxmlファイルをスクリプトで処理するほうがいいんだと思いますが、今回は力技に逃げました。

URLの自動リンクを停止

はてなブログでは、URLが書かれていると、自動でリンクを張ってくれます。 通常は非常に便利なのですが、これが邪魔になるときもあります。

通常のURLの場合

通常の場合の自動リンクの抑制方法は、下記にあるように、URLの前後を [] で囲めばよいようです。

自動リンクを止める(自動リンク停止記法) - はてなダイアリーのヘルプ

hapilaki.hateblo.jp

preタグ内の場合

Syntax Highlighterを使っていると、preタグ内にURLを記述する、という場面が多く出てくると思います。 何もしなければ、このpreタグ内のURLに対しても、リンクが張られてしまいます。ま、それが正しく表示されれば別にいいのですが、preタグ内のためか、<a href="・・・ なんて、文字列が見えるので、いただけません。 また、preタグ内のため、前述の [] を使った方法も正しく動作しません。

この場合の回避方法も、すでに確立されているようで、

altere5.hateblo.jp

にあるように、data-unlink 属性を追記すれば、避けることができるそうです。

mimeTex を復活

はてなブログでは、LaTeX 記法による数式表示が使えるようです。 森ソフトのサイトでは、Joomla!のアップデートに伴い、mimeTexのプラグインが使えなくなっていたので、はてなブログ用の記法を使って書き直しました。 とはいっても、記事1つだけなんですけどね。

終わりに

ここまでやれば、移行作業はほぼ終わりです。たぶん、新しいブログを運用していくと、改善しないといけない点も出てくるでしょうが、とりあえずOKとします。 しばらく様子をみて、問題なさそうなら、元サイトの記事のクローズとリダイレクト設定を行いたいと思います。

(参考)FG Joomla to Wordpress 使用上の注意点について

改行文字

普通にインポートすると、preタグ内のコードが1文につながってしまうという問題がありました。 Joomla! 側のデータベースで、記事本文を格納しているのが、 (prefix)_content テーブルの introtext カラムでしたので、これらの手掛かりに、該当部分を探すと、

        public function process_content($content, $post_media) {

            if ( !empty($content) ) {
                $content = str_replace(array("\r", "\n"), array('', ' '), $content);
                                                                                                                                                              
                // Replace page breaks
                $content = preg_replace("#]*?)class=\"system-pagebreak\"(.*?)/>#", "", $content);
                                                                                                                                                              
                // Replace media URLs with the new URLs
                $content = $this->process_content_media_links($content, $post_media);

                // Replace audio and video links
                $content = $this->process_audio_video_links($content);
                                                                                                                                                              
                // For importing backslashes
                $content = addslashes($content);
            }                                                                                                                                                 
                                                                                                                                                              
            return $content;
        }

となっており、改行コードを空白で置き換えていることがわかります。

今回の場合、Wordpressのコンテンツとして扱う分に、何か支障があるかもしれませんが、最終的にはてなブログで思ったように取り込めればよいと考え、かなり乱暴ですが、この部分の処理をコメントアウトしてからインポート処理を行うことで、preタグ内のコードがすべてつながってしまうという事態を避けることができました。

画像ファイルコピー失敗時の原因調査について

最初、FG Joomla to WordPress を使ってインポートしようとしたら、記事のインポートは問題なかったのですが、画像のインポートにことごとく失敗していました。 こんな感じのエラーメッセージが出ていました。

f:id:junichim:20160826224705p:plain

結局のところ原因は、作業をしていたサイトが、特定のIPアドレスからの接続のみを受け付ける設定となっており、自分自身のIPでの接続を許可していなかったためでした。

この原因の探り方を参考に書いておきます。 まず、

https://wordpress.org/support/topic/plugin-fg-joomla-to-wordpress-media-does-not-copy

にあるように、copy関数呼び出しでエラーメッセージが抑制されていそうなので、これを知りたいと思い、該当部分を探すと、今回使ったバージョンだと、

wp-content/plugins/fg-joomla-to-wordpress/admin/class-fg-joomla-to-wordpress-admin.php

の1813行に、

if ( ! @$this->remote_copy($old_filename, $new_full_filename) ) {
    $error = error_get_last();
    $error_message = $error['message'];
    $this->display_admin_error("Can't copy $old_filename to $new_full_filename : $error_message");
    return false;
}                                                                                                                                                 

という記述があり、コピー時のエラーメッセージが抑制されていました。 これを、

if ( ! $this->remote_copy($old_filename, $new_full_filename) ) {

のようにエラー解除すると、エラーメッセージとエラーの発生行を知ることができます。

今回の場合は、エラー発生時に表示された該当行付近を見ると、

            $response = wp_remote_get($url, array(
                'timeout'     => $this->plugin_options['timeout'],
            )); // Uses WordPress HTTP API
                                                                                                                                                              
            if ( is_wp_error($response) ) {                                                                                                                   
                trigger_error($response->get_error_message(), E_USER_WARNING);
                return false;
            } elseif ( $response['response']['code'] != 200 ) {
                trigger_error($response['response']['message'], E_USER_WARNING);
                return false;
            } else {                                                                                                                                          
                file_put_contents($path, wp_remote_retrieve_body($response));
                return true;
            }

となっており、レスポンスステータスが200以外(若干のデバッグ文も加えたところ、403でした)となっているが判明し、そこから、IPアドレスを制限していることを思い出しました。

ご参考までに。

はてなブログに移行しました (1/2)

元々、日々の仕事で気になったことや調べたことをまとめた技術メモ的なものを残すのに、ブログは日付で管理している印象が強くて、技術のメモ書きなどある程度長期的な情報を貯めていくのに、どうなんだろうかと思ってました。なので、当初は、森ソフトのサイトで『技術メモ』として書いてました。

でも、ある時期から、

  • 結局のところ技術ネタだから、永続的な内容というわけでもないのと、
  • 『技術メモ』と題していたため、技術ネタ以外のことを自由に書きづらい

ことがあり、ちょっと不満を持っていました。そんな経緯の末、若干時間ができたので、思い切って、はてなブログに移行することにしました。 ここでは、その顛末についてまとめておきます。

Joomla! を使っていた経緯

元々、森ソフトのサイトは、Joomla!で作成しています。これを選んだ経緯は、そんなに大した理由もなく、

  • 当時使っていたレンタルサーバーのPHPだったかMySQLだったかが、Wordpressの動作要件を満たしていなかったのと
  • 知り合いが使っていた

という2点でした。

実際に使いはじめてみると、だんだんいろいろとわかってきて、Joomla!は(比較的)規模の大きい、多言語サイトなどを作るに向いており、ブログやちょっとしたサイトならWordpressのほうが向いていそうだとなりました。また、Joolma!は残念ながら日本語の情報が少なく、何か問題があっても、日本語ではなかなか情報が見つけられないという面もあります。

そんななか

Joomla! じゃぱん - Joomla! JAPAN

のサイト(日本語化プロジェクトのサイト)は最新版に対しても非常に素早い対応をしているので、頭が下がります。

まあ、そんなこんなで、Joomla!のサイト中に、ブログとは銘打っていませんが、ブログのような形で技術メモを貯めていたので、よりわかりやすくブログとして移行することになりました。

ちなみに、もうちょっと補足すると、Joomla!でもブログのような形で記事を書けますが(現に書いていましたが)、標準の機能だと、いわゆる一般的なブログほど自由に記事にアクセスできない、という側面があります。また、タグなどもあるのですがタグが導入される前から使っていたため、途中から使うには使いにくいなどという側面もありました。ま、半分はこんな理由ですが、もう半分は新しいのを使ってみたい、というのもあります。

移行先の選択肢

移行先の選択肢としては、いくつか候補がありました

  1. Joomla! にプラグイン等を追加して、ブログに仕立てる
  2. 現在のサイト全体をWordpressに移行する
  3. ブログ用の Wordpress を立ち上げる
  4. ブログサービスを利用する

あたりです。

元サイトでJoomla!を使っていたので、まず第1案について検討しました。確かに、Joomla!のブログ用にエクステンションも多数あり、若干のお金を支払えばそれなりに質のよさそうなものも手に入りそうでした。しかし、これらのうちいくつかを試してみたところ、一つの投稿に対して、Joolma!本体の記事とブログ用の記事の2つが存在するような造りになっており、どうもこれが気に入りません。 全てのエクステンションを試したわけではないですが、人気で上位に表示されているもの複数がこのような感じだったので、望み薄かなと思います。

次に、現在のサイトをWordpressに移行する案ですが、これも心惹かれませんでした。まあ、特にという理由もないのですが、ブログ部分だけでなく、サイト全体の作り直しになるので、若干手間がかかるかな、という理由です。

3番目のブログ用のWordpressを立ち上げる案ですが、考えてみるとこれもなしでした。既存サイトをJoomla!で運用して、ブログをWordpressで運用という形そのものはよくあると思います。でも、自分で2つのシステムを管理する手間を考えると、今後、Wordpressで仕事したいとでも思ってるならともかく、特に積極的な理由がないなら、ま、やめたほうが良いですね。

ということで、結局残ったのが、4番目のブログサービスを利用するという案でした。これも悩ましくて、数あるブログサービスから、どこを使うかが問題になります。

ブログサービスの選定

特に選定基準もないのですが、まあ、メジャーどころで、

あたりに絞って、詳しく調べてみました。 先に、結論を書いておくと、独自ドメインを使いたかったので、はてなブログのPro版を使うということにしました。

はてなブログ

Joomla!からの移行で採り得る方法は、

Joomla! -> Wordpress -> はてなブログ

という経緯をたどる方法です。

この場合、一時的なWordpressサイトを立ち上げ、FG Joomla to Wordpressというプラグインを使うと、Joomla!側のコンテンツをWordpressにインポートできそうです。 一旦、Wordpressに移行できれば、エクスポート機能を使って出力したものを、はてなブログ側でインポートできます。

あと、独自ドメインを使うには、有料版のpro版にしないといけないということです。数年単位で継続して利用するだろうから、これに関しては2年契約で問題ないと思うので、月額換算で600円となり、金額的にもそれほど不都合というわけではありません。

ただ、支払方法が、はてなポイントという謎なシステムを経由しないと行けないのが、ちょっと気になります。自動継続時にはてなポイントの残額がないと、解約扱いになる、とかあるくせに、はてなポイントの有効期間が一年間なので、2年契約の自動更新用にポイントを自動補充することもできず、なんだこれは?という印象です。 ま、この手のものは利用期限が近付いたら、通知メールぐらい来るだろうと勝手に推測して、良しとしました。

素直にクレジットカードで決済してくれるなら、きっと利用者も増えるのに、もったいないなと感じてます。もっとも、はてなの日記によると、将来的には廃止の方向のようですので、安心しましたが、さっさとなくしてほしいものです。

Blogger

Joomla!(ないしWordpress)からBloggerへ移行する方法を調べてみたのですが、これがなかなか情報が見つかりません。いくつか見つけたのですが、基本的に古くて、今現在の有効かどうかわかりません。

http://www.15minutemondays.com/2015/01/26/moving-wordpress-blogger/ http://google.about.com/od/googleblogger/a/How-To-Move-Your-Blog-From-Wordpress-To-Blogger.htm

あと、それらの手順でも指摘されている、一番のネックが、画像のインポートが自動ではできなくて、すべて自分でで作業で貼りなおさないと行けなさそうでした。これは、今回のような既存のコンテンツを移行するには、ちょっとハードルが高すぎます。

ということで、移行先は、はてなブログということになりました。 実際の移行作業は

blog.mori-soft.com

にまとめます。

3.4.x -> 3.6.x へのアップデート

本サイトのJoomla! を 3.4.8 から 3.6.2 にアップデートしました。

普通だと、『コンポーネント』→『Joomla!の更新』を行えば、それで終わりなんですが、キャッシュをクリアしても、なぜか表示される更新対象のバージョンが 3.6.0 しか出てず、 3.6.2 が表示されませんでした。ちょっと気になったので、アップデート手順をとか情報を調べたら、注意が必要そうだったので、メモにまとめておきます。

ちなみに、表示されなかった原因は、多分、更新のオプション設定だったようです(下記を参照)。

 

こちらのページの『Setting Ipdate Server』の部分にオプションの意味が書いてあります(図入りなのでわかりやすい)。

https://docs.joomla.org/J3.x:Updating_Joomla_(Update_Method)

日本語はこちらにありますが、図がなかったので、最初オプションの内容の説明の意味がが分かりませんでした (><)。

https://docs.joomla.org/J3.x:Updating_from_an_existing_version/ja

 

3.6.xへのアップデート手順

こちらのダウンロードページ(下記ページのリンク元)に注記があるのですが、3.6.1にアップデートするときに注意が必要だそうです。

https://www.joomla.org/announcements/release-news/5666-the-joomla-3-6-1-update.html

 

実際の作業はこのページにある説明に従って作業をします。簡単に書くと、

  1. 『コンポーネント』→『Joomla!の更新』を使って、3.6.0 にアップデートします
  2. 『エクステンション』→『管理』→『アップデート』を選択し、表示される『Joomla! Update Component Update』 の更新を行います。今回の場合、3.6.0 から 3.6.1 に事前に上げておくことになります。
  3. 『コンポーネント』→『Joomla!の更新』を使って、3.6.2 にアップデートします

 

日本語サイトのほうには、上記注意点へのリンクがないようなので、気にしなくてもいいのかもしれませんが、ま、試していないのでなんとも言えませんが。。。

http://joomla.jp/news/release-news.html

 

いずれにせよ、ご参考までに。

今更ながらdocker試してみました

cartoDB をサーバーにインストールして試したいと思い、いろいろと調べていたらdockerのイメージがあるらしいということがわかりました。インストール手順とか眺めても、結構面倒そうだったので、最初のお試しとしてこれを利用しない手はないでしょう。

ということで、まずは、興味ありながらも手を出せていなかったdockerを今更ながら試してみることにしました。といっても、dockerの解説記事やチュートリアルはすでにネット上にたくさんあるので、ここでは参考にさせていただいた記事『いまさら聞けないDocker入門@IT』を元に、個人的に躓いた点などをメモ的にまとめておきたいと思います。

 

インストール

dockerをインストールして試す手ごろな環境がないか探してみたところ、古いノートPCにLubuntu(14.04 LTS, 32bit)を入れていたので、それで試してみることにしました。インストールは、記事中にもあるように

sudo apt-get install docker.io

で問題なく完了しました。ただし、すでにシンボリックリンクは最初から貼られていました。

 

コンテナの実行

実は、ここが一番はまりました。記事によると

docker pull ubuntu
docker run -it --name test ubuntu /bin/bash

で最新のUbuntuのイメージをダウンロードして、それを実行するということでしたが、なぜか

mor@lenovo:~$ docker run -it --name test ubuntu /bin/bash
exec format error
FATA[0000] Error response from daemon: Cannot start container 9bd88c529a26a934e661b55a242078d0fa4f224b665a521687388b8af3cf3598: [8] System error: exec format error 
mor@lenovo:~$ 

というエラーが表示されて、実行できませんでした。

途方にくれながら、ググってみると、ホストOSが32bitの場合、コンテナのイメージも32bitである必要がありそうです。

http://d.hatena.ne.jp/rougeref/20150724

http://stackoverflow.com/questions/29072605/can-not-start-docker-on-lubuntu-cannot-start-container-exec-format-error

 

ということで、32bitイメージを取得して再度試してみました。

docker pull 32bit/ubuntu:14.04
docker run -it --name test1 32bit/ubuntu:14.04 /bin/bash

おぉ、問題なく動作しました。なお、イメージ取得時にタグ名をお忘れなく。

 

Dockerfileを試す

基本的には記事にあるとおりに作業すればよいのですが、

FROM 32bit/ubuntu:14.04
MAINTAINER mor
RUN apt-get update
RUN apt-get -y install nginx
ADD index.html /usr/share/nginx/html/

のように若干調整が必要でした。docker build を実行時にいくつかエラーが表示されていたのですが、まあ、動いていたので今回は気にしないことにしておきます。

 

あと、こちらのページのコラム記事に nsenter を使って、動作中のコンテナに接続する方法が紹介されています。しかし、残念ながら32bit版のLubuntuでは、こちらの記事の方法(dockerイメージによるインストール方法)は使えませんでした。さて、困ったと思っていたところ、dockerのバージョンアップに伴い、動作中のコンテナに接続してコマンドを実行する機能が追加されていました。

http://agekuno.hatenablog.com/entry/2014/10/18/010128

 

試してみるとこんな感じでした。

mor@lenovo:~$ docker exec --help

Usage: docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

Run a command in a running container

  -d, --detach=false         Detached mode: run command in the background
  --help=false               Print usage
  -i, --interactive=false    Keep STDIN open even if not attached
  -t, --tty=false            Allocate a pseudo-TTY
mor@lenovo:~$ 
mor@lenovo:~$ docker exec -it 0bfb /bin/bash
root@0bfb951cf79a:/# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2268   528 ?        Ss   15:38   0:00 /bin/sh -c /usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf
root         7  0.0  0.2  14900  3180 ?        S    15:38   0:00 nginx: master process /usr/sbin/nginx -g daemon off; -c /etc/nginx/nginx.conf
www-data     8  0.0  0.0  15044  1396 ?        S    15:38   0:00 nginx: worker process                                  
www-data     9  0.0  0.0  15044  1396 ?        S    15:38   0:00 nginx: worker process                                  
www-data    10  0.0  0.0  15044  1396 ?        S    15:38   0:00 nginx: worker process                                  
www-data    11  0.0  0.0  15044  1396 ?        S    15:38   0:00 nginx: worker process                                  
root        18  1.0  0.1   3544  1708 ?        Ss   15:39   0:00 /bin/bash
root        32  0.0  0.0   3144   976 ?        R+   15:39   0:00 ps aux
root@0bfb951cf79a:/# exit
exit
mor@lenovo:~$ 

これを使えば、パッケージのインストールなどしなくても一発でコンテナの様子を調べられます。便利!

 

Docker Hub の利用

解説記事の最後はDocker Hub を使ってみるということです。こちらも試してみました。

Docker Hub のアカウント登録で、GitHubのアカウントも使えるとあったのですが、今回試した際は見つけることができませんでした。なので、アカウントを新たに登録して、ログインしてみます。

docker push

でリポジトリに追加できました。なお、dockerの場合、『リポジトリ』がイメージ名に対応しているようです。

pushコマンドで追加した場合、何もしなければpublicリポジトリになるようです。これをprivateに切り替えるためには、リポジトリの詳細画面を開いて、タブメニューのSettingsを選択して、『Visibility Settings』でprivateにすればOKのようです。しかし、無料枠だとprivateリポジトリが1つだけなので、なかなか難しいところです。

 

なお、今回は Automated Build は試しませんでした。

 

Dockerをどう使うか?

触ってみた感触だと、テスト的にあれこれするには非常に便利そうに感じてます。まずはいろんな環境を手軽に作ったりするのに使う感じになりそうかな。

ネットの記事をあれこれ読むと、dockerを利用してサーバー運用とかもできそうですが、結局データをどう保存しておくのかとか、コンテナ同士のやりとりをどうするのか、といった面がまだ見えていません。

でも、Dockerfile によってサーバーの設定を記述できるなどは非常に魅力的です。ま、もっとも、Chefとかのツールを使ってもいいんじゃないか思うので、そのあたりの違いもちょっと見えていない面があります。

これを機に、少しDockerに触ってみようと思います。