読者です 読者をやめる 読者になる 読者になる

basyura's blog

あしたになったらほんきだす。

Docker 入門

docker

ずっと気になっていたのだけどようやく着手。これは便利だ (みんな知ってる)。

「docker」でググって入門を調べてみたりしたのだけど最初から本家を見ればよかった。ただ、2014 年から更新が止まっているようなのだけど Docker入門 は概要を把握しやすくてよかった。

以下、入門手順。

インストール @ Mac

Homebrew を使う方法もあるようなのだけど、本家の mac 版インストーラを使用。ダウンロードして実行するだけ。

入門

Get started に従う。

docker で起動しているコンテナの一覧を表示

$ docker ps

CONTAINER ID        IMAGE     COMMAND                   CREATED             STATUS                PORTS                                    NAMES
185fabcd9c5d        nginx       "nginx -g 'daemon off"   13 minutes ago     Up 11 seconds      0.0.0.0:80->80/tcp, 443/tcp    webserver

起動していないコンテナの一覧も表示

$ docker ps -a

CONTAINER ID   IMAGE        COMMAND                 CREATED         STATUS                     PORTS                         NAMES
185fabcd9c5d   nginx        "nginx -g 'daemon off"  15 minutes ago  Up About a minute          0.0.0.0:80->80/tcp, 443/tcp   webserver
10bc8846eada   hello-world  "/hello"                17 minutes ago  Exited (0) 17 minutes ago   

コンテナを止める

$ docker stop webserver

コンテナを削除す

$ docker rm -f webserver

イメージの一覧を表示 (rm してもイメージは削除されていない)

$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              01f818af747d        6 days ago          181.6 MB
hello-world         latest              c54a2cc56cbb        6 months ago        1.848 kB

イメージを削除する

$ docker rmi nginx

Untagged: nginx:latest
Untagged: nginx@sha256:fab482910aae9630c93bd24fc6fcecb9f9f792c24a8974f5e46d8ad625ac2357
Deleted: sha256:01f818af747d88b4ebca7cdabd0c581e406e0e790be72678d257735fad84a15f
Deleted: sha256:473ebc9bec6f78c39877b6655ff7c464271d36464442ed27b10be957201e364a
Deleted: sha256:1802fbcbaa5e7496944e22a9fd0cb72051515a66e382b7148cf4098a92571221
Deleted: sha256:b6ca02dfe5e62c58dacb1dec16eb42ed35761c15562485f9da9364bb7c90b9b3

ubuntu を入れてみる

Get started に従って使い方が分かったので ↑ を参考に ubuntu を入れてみる。

$ docker pull ubuntu:latest
  → latest を指定しない場合は latest がつく

$ docker run -it --name ubuntu_test ubuntu /bin/bash
  → ubuntu イメージから ubuntu_test という名前でコンテナを作る
  → 名前を指定しない場合は自動で付けられる
  → 指定しない場合は /bin/bash が指定される

$ docker start ubuntu_test
  → イメージの再実行

$ docker exec -i -t ubuntu_test /bin/bash
  → ログイン

centos を入れてみる

ubuntu のインストールで感じがつかめたので勘で centos を入れてみる

$ docker pull centos
  → イメージを取ってくる

$ docker run -it —name centos centos
  → centos のイメージから centos という名前のコンテナをつくる

$ docker start -i centos
  → 対話モードでコンテナを起動

できた。

zsh completion

補完が欲しくなったのでダウンロードしてインストール

まとめ

便利。びっくりするぐらい便利。公式サイトから iso をダウンロードしてきて VMWare に食わせて起動することを考えると何倍も楽。一瞬で作れる。イメージからコンテナを別名で作れるのも楽。VMWare に比べて cpu 使用率が低いのが一番うれしいかも。VMWare の謎 CPU 使用率は結構辛い。Windows もどドッカーンと作れると嬉しいのだけど。VMWare Fusion が windows 10 と相性が悪いのかいつの間にか再起動地獄に陥るので辛い。windows 8 に切り替えて様子見。

さっさと Docker に取り掛かってればアレもコレも楽だったのにと悔やまれるけど、いい感じに入門できた。

2016 年振り返り

git の年だった。

数年使っていた svn から移行。旗振り役として運用案の作成から git の使い方の啓蒙、サポートを行った。あわせて、GitLab の構築とメンテナンス & バージョンアップに啓蒙、サポートも行った。

svn の方が分かりやすくて良かったという人も少なからずいたけど git にして良かったと改心するのは時間の問題と思っている。 git になってレビューがしやすくなったし、ブランチを気軽に作ったり消したりできるのは便利だ。マージは楽になったけどコンフリクト発生時の直し方が課題(複数人でいい感じにコンフリクトを直してからマージしたい)。

cygwin から git for windows に乗り換えた。何年お世話になったか忘れてしまったけどようやく。振り返るとちょうど一年前に cygwin 1.7 から最新に移行していた。

Pro WPF 4.5 in C#: Windows Presentation Foundation in .NET 4.5

Pro WPF 4.5 in C#: Windows Presentation Foundation in .NET 4.5

とある初めての WPF アプリケーション開発で基盤部分を作成。関係各所にアドバイスを頂きつつ継続中。現在はレビューと実装サポートを行っている。いい感じにできあがってきつつあるが諸事情による構成の複雑さがあるのでパフォーマンス面に心配あり。できあがれば社内での風向きがいろいろと変わるのではないかと思っている。

長年使っていた au から離脱。docomo 回線なのだが au 回線の方が安定感や繋がりやすさがあったように思う。それがちょっと気になるぐらいでコスト面で十分に満足。キャリアメールなんていらんかったんや。とは言え代替となっている LINE もホントはあまり使いたくない。便利なのは認める。Gmail ぐらいがちょうどいいんだけどなぁ。

年初に立てた目標

  • 大きめの開発がまた始まるのでいい感じになるようにコミットしていく
  • 環境面の改善に力を入れていく
  • 健康面に気をつける

まぁまぁクリアできたと思う。今年もよく頑張った。

Firefox - Classic Theme Restorer をやめる

firefox

Firefox の UI が変わってから慣れなくて Classic Theme Restorer をずっと使っていたけどやめた。関係あるのかよく分からないけど拡張を使っていると cpu 使用率が上がる。タブをいくつか開いて閉じた後、cpu 使用率が 10% 程度を推移して落ちない。拡張を外すと 3 〜 4% で落ち着く。windows だとそもそも 0 % なんだけどな。noscript を ON にしてると読み込み中のままになっているようなのも気になる。image が取り込めないでいるようだ。乗り換える気はないのだけど Safari はページ読み込みが速くていい。cpu 使用率もほぼ 0% 。Firefox も何も入れなければそうなるのか。なったとしても使いづらくなるので無理だ。

耳栓を変えた

家が大通りに面しているせいもあって夜中の車や電車の音が気になってしまう。寝づらく目が覚めやすい。起きている間は大丈夫。田んぼに囲まれた田舎育ちなので雨の音やカエルの鳴き声は大丈夫なのだけど車の音はダメ。不定期な突発的な音が気になるのかもしれない。

ということで睡眠中は耳栓を使っている。最近 ↓ に切り替えた。

3M ネクスケア イヤープラグ 耳せん フォームタイプ 2セット ケース付き 1100RP

3M ネクスケア イヤープラグ 耳せん フォームタイプ 2セット ケース付き 1100RP

もともとは サイレンシア AB+ を買いだめして長らく使っていたのだけどいつの間にか生産終了していた。遮音性が良くていい製品だったのに残念。

サイレンシア レギュラー 携帯ケース付き

サイレンシア レギュラー 携帯ケース付き

仕方がないのでサイレンシアの別シリーズ(スタンダード?)に切り替え。AB+ に比べると柔らかく遮音性が若干弱い。新品の頃はまだいいのだけど 1 週間もすると遮音性がさらに弱くなる。

ネクスケアは AB+ の様な遮音性があって今のところ満足している。特に問題なさそうであればこのまま乗り換えることにする。

cygwin にさようなら

Cygwinを使おう―Windows上で実現されるUNIX環境

Cygwinを使おう―Windows上で実現されるUNIX環境

プロジェクトが svn から git に移行したのに伴い、cygwin から git for windows に乗り換えて半年以上が経過。cygwin を立ち上げる必要がなくなったので削除。git なら cygwin でも良かったのだけど、git status したときの速度がオプションを指定してもかなり遅かったのでダメだった。

リポジトリとのやりとりは git svn を使っていた。他に使っていた人はいないようだった。メモ帳などの通常のエディタを使っていると vim とは違ってなんとも言えない不安感 (編集が心もとなく、意図せず何かを触ってしまいそう) があるが、同様の不安感が svn にもある。git svn を使うことで心の平穏を保ちつつ数年の開発を乗り越えることができた。

cygwin を使い始めたのがいつ頃だったのかよく覚えてないけど、入社して 1、2 年後に始まったプロジェクトで cygwin を使ってログを tail していたのでまぁまぁの年月お世話になった。使ったと言っても tail するか ruby を実行するかが主だった。

cygwin を使うにあたって大変お世話になったのが cygwin ck 。dos プロンプトで動かすのはいろんな辛さがあったのだけど ck のおかげでとても快適だった。一時配布が止まっていたが再開されたときは歓喜した。現状でも 2013 年から更新は止まっているようだけど。

git for windows に移り zsh にして pacman を使ってパッケージ管理をしている。mintty もいいのだけど ConEmu あたりがタブも使えて便利そうなので移行できないか検討中。

GitLab に初コントリビュートをキメた

git gitlab

GitLab Advent Calendar 2016 - Qiita の 21日目の前エントリ。

GitLab に Merge Request が取り込まれたので初コントリビュートをキメることができた。

  • CE/EE: Fix display hook error message (!7775)

これは Merge Request 取り込み時にサーバサイドの update hook がエラーを返すと応答がなくなる(ように見える)不具合の修正。

背景

仕事プロジェクトで GitLab を社内に設置。コミットログのルール強制やおかしなコミットが入り込まないための判定に update hook を使用。

通常、手元のターミナルから push した際に hook で蹴られると内容がターミナルに表示される。ところが Web 上の Merge Request から Accept Merge でマージした時に update hook で蹴られるとハングしたようになってしまう。

実際にはサーバから失敗した旨の応答が返ってきているのだけどメッセージの表示で失敗する。javascript で UI の書き換えができていないのでエラーメッセージが表示されずグルグル回るインジケータが表示されたままになる。これが処理中のままに見えてしまう。

調査

社内では Merge Request の運用が本格的に始まっていなかったので "そのうち直るだろう” と思っていたのだけどそうでもなかった。自分で直せるか分からないけど見始めてみる。

CentOS 上に yum でインストールしている資源にデバッグログを入れてみるもよく分からない。サーバ側から応答がちゃんと返っていないからだろうと調べていたけど返っているようにみえる。やっぱりよく分からんわと issue を徘徊したところ発見。

コメントを見ると

  • javascript でエラーが出ている
  • 発生箇所が書いてある

そこまで分かればなので、修正することができた。

ついでなので "こうすれば直ると思うよ” と issue にコメントをしてみる。結果的に直し方はちょっと違っていたのだけど、 ここまで書いていれば誰かが反応して一瞬で直るだろうと思っていた。仕事プロジェクトの方では同じ修正を入れたので運用は解決。

MR 登録

1 週間ほど経過を見守っていたのだけど反応が無い。修正が軽微とはいえ困る人は多そうなのに。週末に時間が取れ、ちょうど良いので Merge Request を作ってみることにした。まずは環境づくりから。

mac で環境を作る。

若干ハマったけどドキュメントを読めていないだけだった。コマンド一発で GitLab がローカルで立ち上がり、ユーザー登録からリポジトリの登録、コミットして push までできると感動した。後は Merge Request を作るだけ。

Merge Request を作る際の説明部分にテンプレートが埋め込まれているので、それに沿って記載すれば良い。軽い気持ちであったというか、なんとなく採用されずに他の人が直しちゃいそうだし直し方が間違ってる可能性もありそうなのでテストやライセンスの記述はすっ飛ばして登録した。

この時に issue にコメントした内容ではない正しい直し方に気がついたので改めた。

MR レビュー

数日後に反応がある。まずは、直し方についての指摘。直し方は正しかったがバグ修正に加えて表示方法を変えていることに関してだった。

単純にバグを直すだけだと update hook の結果が h4 タグで表示されてしまう。自分のプロジェクトでもそうだけど、hook が返すメッセージが 1 行で済むケースはあまりなさそう。しかも、ターミナル等で表示することを想定すると html であるはずがなく複数行に渡るプレーンテキストになるだろうと。それで h4 を pre に変えてコミットした。

やり取りの結果、バグと機能修正を分けようということになり、それはそうだと納得してバグ修正のみを適用。表示方法の改善については別の issue が登録された。

a test please.

javascript のテストを書いたことが無いので自信が無かったのだけど、GitLab の中の人がテストについて教えてくれるので頑張ってみる。Google 先生に聞きながら斜め読みしつつ他のテストを参考してみた結果なんとか書けた。

ブラウザを起動してテストを実行していたのだけど terminal から実行できると教えてもらえた。こっちの方が楽だ。

Can you also add a changelog?

GitLab の中の人に changelog の作り方を教えてもらう。CHANGELOG.md とは別に changelog 用のファイルを追加して終了。

テスト

GitLab の環境が非力なのか関係ないところでテストがコケまくる。容量不足的なエラーもちょいちょいでる。最初の push からテストは通っていないので関係無いところでコケてると思っていた。実際そういうところもあったのだけど push する前にした rebase が最新に対してじゃなかったのも一因だった。改めて rebase & push して何回かテストをリトライしたのち見事テスト通過。

LGTM

初めての LGTM をいただく! 無事 8.14.5 でリリースとなった。

まとめ

しょぼい修正ながら MR からリリースまでやった印象。

GitLab チーム優しい!

GitLab の中の人なら半日で MR 作成から修正完了まで終えていたに違いない。それを粘り強く付き合ってくれたので途中から申し訳ない気持ちになりつつも速く終わらせようという前向きな気持になれた。GitLab 社としての方針ではあるだろうけど、沢山ある MR に対して同様の対応を進めるというのはかなりの労力が必要になりそう。

GitHub に対抗できてプライベート環境にデプロイ可能なサービスとしてはありがたいことこの上ない。今後も GitLab をウォッチしつつ可能なら MR を再度キメたい。何事もそうかもしれないが仕事に直接絡むような当事者の位置になると愛着がでるし調べてみようという気になる。

GitLab 便利!