読書メモ：Effective Java 第3版 項目45 ストリームを注意して使う

はじめに

Effective Java 第3版を読んだら勇気が湧いてくることが書いてあったのでメモ。

「項目45 ストリームを注意して使う」に勇気が湧いてくること書いてある

P207に以下のコードがあります。

        try (Stream<String> words = Files.lines(dictionary)) {
            words.collect(groupingBy(word -> word.chars().sorted()
                    .collect(StringBuilder::new,
                            (sb, c) -> sb.append((char) c),
                            StringBuilder::append).toString()))
                    .values().stream()
                        .filter(group -> group.size() >= minGroupSize)
                        .map(group->group.size() + ":"+ group)
                        .forEach(System.out::println);

        }

そして、そのコードの下には以下の一文が。

このコードを読むのが難しいと思っても、心配しないでください。

引用した個所を読んで、ストリームAPIを使う勇気が湧いてきました。
関数型言語苦手でこういうのを読むの苦手だったんですが、それでも良いんだ。

読書メモ：いちばんやさしいGit&GitHubの教本

はじめに

「いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)」を読みました。
「この本凄いな！」と思ったので、自分のためにメモを残します。

凄いところ

表紙の「知識ゼロでも大丈夫！」に全力で取り組んでいる

本書を読む前は、「表紙のキャッチコピーは『バージョン管理システムを使ったことなくても大丈夫です』という程度の意味だろう」と思っていました。
しかし、そういうことではなかったです。

なんと、以下も本書の内容に含まれているのです。

• ターミナルの起動方法
• ディレクトリの概念

「著者は本気だ。本気で『知識ゼロでも大丈夫』を目指している……」と私は感じました。

バージョン管理システムの説明についても、他のシステムとの比較の話は一切登場しません。
比較したほうが説明しやすい箇所もあるかと思うのですが、「知識ゼロ」を標榜している本書は、そんな手法は採ってません。

惜しみなく図を使って説明している

私が最初Gitを触った時は「コミットするとステージングエリアに移動するらしいが、ステージングエリアって何？？」と結構混乱しました。
本書は、図を惜しみなく使っているため凄くわかりやすいです。

余談ですが、ステージングエリアの話題が初めて登場するChapter1(P022)に、以下の一言があります。

しかし、もし難しいと感じた場合は、先にChapter 2以降を読み進め、あとから戻ってくるという読み方をしてもかまいません。

詰まって先に進めなくなる人が居ないように配慮されているのです。
なんて優しい本なんだ……。

Githubも取り上げているのが素晴らしい

昔、「トピックブランチを作って開発するものらしい」と知った時は次のように思いました。
「Gitがトピックごとにブランチを分けて開発しやすいように作られているのはわかった。でも、レビュー→修正→マージの作業、結局面倒じゃないか。これ、便利なのかな…」って。

私が「Gitいいじゃん！」って思ったのはGitHubクローンに触れて、Pull Requestを使ってからです。

本書は、ブランチをつくったあとPull Requestを作成するという流れで説明されています。
この流れで説明されていれば、「面倒そう…」なんて感想をもつことなく、「なるほどー。良いね！」って思うに違いありません。
Githubも取り上げたのは、素晴らしいと思いました。

さいごに

「私がGitを勉強し始めた時にこの本があれば良かったのに」と思いました。

Kubespray + Vagrant で遊ぶ時の注意点

はじめに

　Kubespray + Vagrant でごにょごにょ遊んでいたのですが、使う際のコツが少しあったのでメモ。

環境

• Vagrant 2.1.2
• Kubespray commit hash:f1e348ab9592e8bc87e5ce70492a78f73666aa44

vagrant haltは使わない

　「vagrant halt」を実行すると、「vagrant up」後、Kubernetesが使えません。
　どうやら、Kubernetesに必要なコンポーネントに自動起動が仕込まれていないようです。

　「vagrant halt」の代わりに「vagrant suspend」を使用したほうが無難です。

vagrantで起動するOS、何度やっても起動しないものもあるので頑張りすぎない

　Vagrantfileを読むといくつかOSを選べます。
　しかし、試してみたらcoreos-stableは私の環境では何度やってもうまくいかず……。
　試してみるのを諦めました。

　CoreOSはバージョンアップ早いですからね。そういうこともあるのかもしれません。

さいごに

　Kubespray + vagrantの情報、日本語だとそんなに見つからないんですよね。
　遊ぶのであれば、自らちょっとずつ探っていかねば。

「Software Design 2018年3月号」をみてkubesprayをインストールしてみた

はじめに

　「Software Design 2018年3月号」が出版されて随分たちました。今更kubesprayのインストールを試してみたら、気になった点・気づいた点がありましたので、メモ。

環境

• Lununtu 16.04 (VMWare Player 14.1.2上で起動)
• VirtualBox 5.2.14
• Vagrant 2.1.2
• Ansible 2.4.2.0
• Jinja2 2.10
• netaddr 0.7.19
• kubespray commit hash:f1e348ab9592e8bc87e5ce70492a78f73666aa44

気になった点・気づいた点

記事で扱っているkubesprayのバージョンの記載

　「Software Design 2018年3月号」のP82に、kubesprayのcommit hashが記載されています。「なぜtagの名前を記載しないんだろう？」と疑問に思いました。

　kubesprayのリポジトリをみてみたところ、tagを打つ間隔がわりとまちまちですので新しい情報を記事に取り入れようとして、tagからソースを取得しなかったのではないかと思われます。

　比較的最近のtagについて、対象となったコミットの日付を調べてみましたところ、以下のようになっていました。

• v2.5.0…2018/4/16
• v2.4.0…2018/2/1
• v2.3.0…2017/10/27
• v2.2.1…2017/9/27

P82のinventory/group_vars/k8s-cluster.ymlの所在

　inventoryの直下には、group_varsは存在しません。
　代わり(?)に、local/group_varsとsample/group_varsが存在します。
　「これはどっちを使えばいいのだろう？」と疑問に思いました。

　sampleの方を使うのだと私は判断しました。
　判断理由は、GitHub - kubernetes-incubator/kubespray: Setup a kubernetes clusterの説明で、sampleをコピーして設定変更しているためです。

使用するVagrantとVirtualBoxのバージョン

　記事に記載されているバージョンのVagrantとVirtualBoxを使用したところ、何度もタイムアウトしました。
　これは私の環境が貧弱なためと思われます。
　検証時点で最新のバージョンを使用したところ改善されましたので、タイムアウトで苦しむ場合は、バージョンを変えてみるとよいかもしれません。

P83の「kubectl_localhost: true」を有効にした場合のkubectlの配置場所

　inventory/inventory名/artifactsに配置されます。
　私の場合inventory/sample/artifactsですね。

VMWare Player 上のLununtuという環境について

　私は普段Windowsを使用しているので、VMWare Player 上のLununtuに環境を作ったのですが…。
　これはあまりお勧めしません。環境構築中、何度もタイムアウトに悩まされました。
　 私がi5-3320Mという2012年頃発売のCPUを使っているのも原因の一つかと思います。

デフォルトで作成される仮想マシンについて

以下のスペックの仮想マシンが3台作成されました。

項目	値
プロセッサー数	1
メモリ	2048MB
ストレージ	60GB(作成直後の割り当ては、4G程度)

さいごに

　久しぶりにi5-3320Mの限界を強く感じました。

一台の物理PCに「Docker for Windows Desktop with integrated Kubernetes」と「Minikube」の実験環境を作りたい

はじめに

　結構検討に時間を要したので、件名の件について構成をメモ。

構成

以下が構成です。

補足：Hyper-VとVMWare Playerは、HyperV-Switchで切り替えて使用します。

検討したこと

一つのOSに、「Docker for Windows Desktop with integrated Kubernetes」と「Minikube」を同居させるか？

　以下について冴えたアイデアが出なかったので、別々のOSにインストールすることにしました。

• 「Docker for Windows Desktop with integrated Kubernetes」でインストールされたdockerコマンド、kubectlコマンドと、Minikube用にインストールしたdockerコマンド、kubectlコマンドの切り替え方法。

　環境変数の切り替えという案は浮かびましたが、「私は切り替えミスしそうだ」と思いそれは採用しませんでした。

仮想化ソフトに何を使用するか？

　「仮想化の入れ子」を今回実現する必要があります。
　私はVMWare Playerを採用しました。「Intel VT-x/EPT または AMD-V/RVI を仮想化」を有効にすることで、「仮想化の入れ子」が可能なことが机上調査で分かったためです。

VMware Playerで起動する仮想マシンのスペックをどうするべきか？

　これは事前には情報を見つけられず、適当に決めました。

　構築してみた結果を踏まえますと、以下のスペックが無難であると思われます。

名前	色
コア数	2以上
メモリ	2GB(Minikue用仮想マシン用)+α。VMWare PlayerでLubuntuを動かす場合、3GB以上が無難だと思います。
ディスク	20GB(Minikue用仮想マシン用)+α。VMWare PlayerでLubuntuの場合40GB以上が無難だと思います。

　以下に、Minikubeを起動した状態のVMWare Playerのスクリーンショットを、参考のために示します。

参考

• Nested Virtualization を使って仮想マシン上で Vagrant する - 部屋の中にも一年
• Minikubeを使ってローカル環境にKubernetes環境を用意する ｜ Developers.IO
• GitHub - kubernetes/minikube: Run Kubernetes locally

さいごに

　まとめると大したことはやっていない感じがありますが、結構時間かかってしまった…。

Lubuntu 18.04で「Failed to connect to lvmetad. Falling back to device scanning.」って表示される

はじめに

　VirtualBoxにLubuntu 18.04をインストールしたら、OS起動時に件名のエラーが出力されます。
　原因だと思われる事象をディスカッションしているページを見つけたのでメモ。

環境

• VirtualBox 5.2.12 r122591
  • Lubuntu 18.04 64bit

見つけたページ

　以下が見つけたページです。

• Bug #1768230 “Long time booting : Failed to connect to lvmetad. ...” : Bugs : initramfs-tools package : Ubuntu

さいごに

　ページを読むと、Ubuntu 18.10.4で治ったらしいです。
　Lubuntu 18.04に反映されるのは、いつの日か……。

「Docker for Windows Desktop with integrated Kubernetes」の仮想マシンの使用メモリ

はじめに

　「Kubernetesを有効にした状態のDocker for Windows Desktopの仮想マシンって、どの程度メモリを使っているんだろう？」と思って調べたのでメモ。

環境

• Windows 10 Pro
• Docker 18.05.0-ce-win67

仮想マシンへの割り当てメモリ（と、ついでにその他リソースの割り当て）

調査方法

　「「Kubernetesを有効にした状態のDocker for Windows Desktop」を起動し、Hyper-V マネージャで仮想マシンの設定を確認します。

調査結果

　以下の通りでした。

リソース	値
メモリ	2048MB
プロセッサ	2コア
ハードドライブ	60GB (インストール直後に実際使用されているのは、7GB少々)

実際に使用しているメモリ

調査方法

　以下のサイトを参考にしたDockerコンテナを作成し、freeコマンドで調査しました。
　qiita.com

調査結果

　以下が調査結果です。
　約1G使うんですね。

> docker run -it --privileged --pid=host hostenter /bin/sh
/ # free -m
             total       used       free     shared    buffers     cached
Mem:          1980       1888         91         11         43        722
-/+ buffers/cache:       1121        858
Swap:         2047          6       2041

さいごに

　疑問に思っていたことが分かってちょっとすっきりです。