Mazn.net

一昔前までは、Kubernetesの学習環境を手元に作るには、それなりに手間がかかっていたのですが、Rancherコミュニティが、k3sという ファイルをダウンロードして実行するだけの超軽量シングルバイナリのKubernetesを開発しています。これこれで大変便利なのですが、マルチノード構成の環境を作ろうとすると、複数のサーバやVMを用意する必要があり、それなりのハードウェアリソースが必要となってしまいます。

そこで紹介するのが、k3dというツールです。Dockerコンテナ内でk3sを起動してくれるツールで、超簡単にマルチノード構成のKubernetes環境を用意することができます。

CentOS 7環境で早速使ってみました。Docker (docker-ce-18.09.6-3)が動いている環境を使いました。まずは以下のコマンドを使ってk3dをインストールします

# wget -q -O - https://raw.githubusercontent.com/rancher/k3d/master/install.sh | bash

Kubernetes環境を3ノード構成で起動してみます。

# k3d create --version v0.4.0 --workers 3
2019/05/10 18:18:21 [WARNING] The --version flag will be deprecated soon, please use --image rancher/k3s:<version> instead
2019/05/10 18:18:22 Created cluster network with ID ac530006b151ff97cada685d2acf6106de19b1c31a8eb9efa2e5f5075e925fa6
2019/05/10 18:18:22 Creating cluster [k3s-default]
2019/05/10 18:18:22 Creating server using docker.io/rancher/k3s:v0.4.0…
2019/05/10 18:18:22 Pulling image docker.io/rancher/k3s:v0.4.0…
2019/05/10 18:18:33 Booting 3 workers for cluster k3s-default
Created worker with ID 4e1c813b0adbf615ba1d85175b2df7f0e971de29e1f54f68f029d744d8ab751a
Created worker with ID 9acd162d9e304c06454f5f71754ef020b1455a93a23e399d7ba619a10355a79f
Created worker with ID 814185a6d22409057fb2c22b12ceb585ea10c512b805730892255f5ba47973b0
2019/05/10 18:18:35 SUCCESS: created cluster [k3s-default]
2019/05/10 18:18:35 You can now use the cluster with:

これだけです。超簡単ですね。出来上がった環境を見てみます。

# docker ps
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                    NAMES
814185a6d224        rancher/k3s:v0.4.0   "/bin/k3s agent"         26 minutes ago      Up 26 minutes                                k3d-k3s-default-worker-2
9acd162d9e30        rancher/k3s:v0.4.0   "/bin/k3s agent"         26 minutes ago      Up 26 minutes                                k3d-k3s-default-worker-1
4e1c813b0adb        rancher/k3s:v0.4.0   "/bin/k3s agent"         26 minutes ago      Up 26 minutes                                k3d-k3s-default-worker-0
7d60823ce2a3        rancher/k3s:v0.4.0   "/bin/k3s server --h…"   26 minutes ago      Up 26 minutes       0.0.0.0:6443->6443/tcp   k3d-k3s-default-server

Serverコンテナ1つとAgentコンテナ3つが動いています。KubernetesのMasterと(Worker)ノード相当のものです。

kubectlコマンドを叩いてみましょう。ホストOSにkubectlコマンドがインストールされていなければインストールしておきます。

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1 
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# yum install -y kubectl 

kubectlコマンドの設定ファイルのパスを環境変数に設定します。

# export KUBECONFIG=$(k3d get-kubeconfig)

適当にKubernetesの情報を取得してみます。

kubectl get node -o wide
 NAME                       STATUS   ROLES    AGE   VERSION         INTERNAL-IP   EXTERNAL-IP   OS-IMAGE   KERNEL-VERSION               CONTAINER-RUNTIME
 k3d-k3s-default-server     Ready       42m   v1.14.1-k3s.4   172.18.0.2            Unknown    3.10.0-957.12.1.el7.x86_64   containerd://1.2.5+unknown
 k3d-k3s-default-worker-0   Ready       42m   v1.14.1-k3s.4   172.18.0.3            Unknown    3.10.0-957.12.1.el7.x86_64   containerd://1.2.5+unknown
 k3d-k3s-default-worker-1   Ready       42m   v1.14.1-k3s.4   172.18.0.4            Unknown    3.10.0-957.12.1.el7.x86_64   containerd://1.2.5+unknown
 k3d-k3s-default-worker-2   Ready       42m   v1.14.1-k3s.4   172.18.0.5            Unknown    3.10.0-957.12.1.el7.x86_64   containerd://1.2.5+unknown

# kubectl get all
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.43.0.1            443/TCP   37m

うまく動いてくれてるようです。もう少し環境周りを覗いてみます。Linuxブリッジの状態を確認。

# brctl show
bridge name       bridge id            STP enabled     interfaces
br-ac530006b151   8000.024285c1d37d    no              veth00a8545
                                                       veth3543d6b
                                                       veth88950d4
                                                       vethcc4d242
docker0           8000.024216fe1fb2    no

Dockerコンテナは独自のLinuxブリッジに繋がっているようです。コンテナ内のネットワークインターフェイスを確認。

# docker exec -it k3d-k3s-default-server ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: flannel.1:  mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether 12:28:97:aa:90:e3 brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.0/32 brd 10.42.0.0 scope global flannel.1
       valid_lft forever preferred_lft forever
3: cni0:  mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 2e:f2:26:a8:d2:54 brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.1/24 brd 10.42.0.255 scope global cni0
       valid_lft forever preferred_lft forever
5: eth0@if6:  mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever
6: vethc59d35f5@if3:  mtu 1450 qdisc noqueue master cni0 state UP group default
    link/ether fa:cf:8d:7b:06:bd brd ff:ff:ff:ff:ff:ff link-netns cni-09084b96-eace-4094-11d2-b43d9bd469a4

オーバーレイNWはflannelが動作しています。これはk3sのデフォルトの動作になります。

Nginxを動かしてみます。

# wget https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/deployment.yaml
# kubectl apply -f deployment.yaml
# kubectl get pod -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP          NODE                       NOMINATED NODE   READINESS GATES
nginx-deployment-6dd86d77d-d89sw   1/1     Running   0          89s   10.42.1.4   k3d-k3s-default-worker-0              
nginx-deployment-6dd86d77d-hmqq8   1/1     Running   0          89s   10.42.3.2   k3d-k3s-default-worker-2              

見事複数ノードでPodが動いてくれました。

今回、Dockerコンテナのポートをホストに何もマッピングしていないので、外部からNginxにアクセスするのは面倒ですが、この辺りのリリースノートを見ると、k3sのコンテナ起動時にポートマッピングを設定することもできそうなので、予め使うポートを決めておけばServiceリソースのNodePort使って外部からアクセスすることも可能そうです。

以上、k3dの紹介でした。今後の開発が楽しみですね。

GO 1.12から、公式にmoduleが使えるようになるようなので、一足先に1.12beta2を使って試してみました。

modulesは、go getやglide, depといったGOのパッケージ管理コマンドの代わりとなる公式機能で、1.11まではvgoというコマンドが公式に提供されていましたが、これがgoコマンドにマージされたものになります。
※ vgoの開発リポジトリは2019/3頃(1.12リリース後約1ヶ月)で削除されるようです

ドキュメントは、go helpで見れます。

$ go help modules

moduleの動作は、プロジェクトのトップディレクトリのgo.modというファイルで定義され、この設定ファイルのドキュメントも同様にgo helpで見れます。

$ go help go.mod

試しに適当にディレクトリを作って以下のファイル(modtest.go)を作成します。
このファイルでは、外部パッケージrsc.io/quoteを必要としているのがわかると思います。
※プロジェクトのディクレクトリの場所はGOPATH配下の必要はありません。

package main
 import (
     "fmt"
     "rsc.io/quote"
 )
 func main() {
     fmt.Println(quote.Hello())
 }

単純にgo runを実行すると当然パッケージがないので怒られます。

$ go run modtest.go
 modtest.go:5:5: cannot find package "rsc.io/quote" in any of:
         /home/user/sdk/go1.12beta2/src/rsc.io/quote (from $GOROOT)
         /home/user/go/src/rsc.io/quote (from $GOPATH)

module機能を使うために、go.modファイルを以下のコマンドで作成します。

$ go mod init modtest.go
 go: creating new go.mod: module modtest.go

以下のファイルが作成されました。

$ cat go.mod
 module modtest.go
 go 1.12

この状態で、再度go runすると、ソース内でimportされたパッケージが自動でダンロードされ、以下のように実行結果が表示されます。

$ go run modtest.go
 go: finding rsc.io/quote v1.5.2
 go: downloading rsc.io/quote v1.5.2
 go: extracting rsc.io/quote v1.5.2
 go: finding rsc.io/sampler v1.3.0
 ～省略～
 Ahoy, world!

実行後、go.modは以下に変更されていました。

$ cat go.mod
 module modtest.go
 go 1.12
 require rsc.io/quote v1.5.2 // indirect

今回はrsc.io/quoteだけをimportした単純な例なのでよいのですが、場合によってはダウンロードされたパッケージのバージョンが想定しているバージョンと異なりビルドできなかったり、アプリが動かなかったりします。そのような場合は、require でバージョンを指定してあげましょう。

$ cat go.mod
 module modtest.go
 go 1.12
 require rsc.io/quote v1.5.1 // indirect 

パッケージが多段にimportされていると、自分で指定したバージョンが勝手に書き換わってしまうこともあります(よく理解してない・・)。そのようなときは、replcaseを書いておくとバージョンを固定できるようです。今回は、1.5.2を1.5.0に書き換えてみました。

module modtest.go
 go 1.12
 require rsc.io/quote v1.5.2 // indirect
 replace rsc.io/quote v1.5.2 => rsc.io/quote v1.5.0

実行すると、以下のように新たに1.5.0がダウンロードされ、実行結果が表示されました。

$ go run modtest.go
 go: finding rsc.io/quote v1.5.0
 go: downloading rsc.io/quote v1.5.0
 go: extracting rsc.io/quote v1.5.0
 Ahoy, world!

GO言語1.12がそろそろリリースされるようですが、2/25にリリースされたのでインストールしてみました。
※ 環境はWindows WSL 上のUbuntu 18.04です。

すでに環境にapt-getでGO言語をインストール済みなら、取得は簡単です。

$ go get golang.org/dl/go1.12

これでgo1.12が、$GOPATH/bin (デフォルトは~/go/bin/)にダウンロードされますが、まだ使えません。以下のようにダウンロードしろと言われます。

$ go1.12
 go1.12: not downloaded. Run 'go1.12 download' to install to /home/teo/sdk/go1.12a

言われたとおりに実行します。

$ go1.12 download
 Downloaded 0.0% (15224 / 133223771 bytes) …
 Downloaded 3.2% (4276224 / 133223771 bytes) …
 Downloaded 8.4% (11223040 / 133223771 bytes) …
 Downloaded 14.4% (19152896 / 133223771 bytes) 
～省略 ～
Unpacking /home/mazn/sdk/go1.12/go1.12.linux-amd64.tar.gz …

これで使えるようになりました。

$ go1.12 version
 go version go1.12 linux/amd64

Windows10を使ってるのですが、休止状態から復帰するとなぜかキーボードのリピートがデフォルト値に戻って遅くなってしまう現象に悩まされていましたので、解決方法を調べてみました。

1. レジストリをいじる方法

レジストリエディタで、「HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response」の値を以下のように変更し、Windowsを再起動する。

AutoRepeatDelay：500(初期値は 1000） AutoRepeatRate：16(初期値は500） DelayBeforeAcceptance：0(初期値は1000) Flags：59(初期値 122 )

1. コマンドで修正する

コントロールパネルでキーボード設定を開いて、OKを押すだけで元の設定に戻るのですが、この方法は面倒なので、以下のコマンドを実行するバッチファイルを作って、症状発生時に実行する方法でもよいと思います。

mode con rate=32 delay=0

最近GO言語を勉強していて、ネスト(入れ子)された構造体のフィールドにアクセスする際のことをメモしておきます。

以下のように、中にmydata1をもつ構造体maindataを作ってみます。

package main

import "fmt"

type mydata1 struct {
    a int
    b int
    c int
}

type maindata struct {
    m1 mydata1
    e  int
}

func main() {
    d1 := mydata1{a: 11, b: 12, c: 13}
    mdata := maindata{m1: d1, e: 99}
    fmt.Println(mdata)
    fmt.Println(mdata.m1.a)
    fmt.Println(mdata.m1.b)
    fmt.Println(mdata.m1.c)
    fmt.Println(mdata.e)
}

上記のように、mydata1は、m1というフィールド名で定義されているので、mydata1のa～cにアクセスするには、mdata.m1.X と書く必要があります。上記を実行すると以下のようになります。想定通りですよね。

{{11 12 13} 99}
11
12
13
99

maindata構造体を定義するときに、フィールド名を省略することができるようです。省略すると、以下のようにmaindataのフィールド名を省略し直接mydata1のフィールド名にアクセスできるようです。なお、構造体を初期化する時、フィールド名が無いので型名(mydata1)を使うようです。

package main

import "fmt"

type mydata1 struct {
    a int
    b int
    c int
}

type maindata struct {
    mydata1
    e int
}

func main() {
    d1 := mydata1{a: 11, b: 12, c: 13}
    mdata := maindata{mydata1: d1, e: 99}
    fmt.Println(mdata)
    fmt.Println(mdata.a)
    fmt.Println(mdata.b)
    fmt.Println(mdata.c)
    fmt.Println(mdata.e)
}

これを実行すると以下のようになります。

{{11 12 13} 99}
11
12
13
99

では、以下のように、maindataに、mydata1と同じフィールド名があるとどうなるのでしょうか？

package main

import "fmt"

type mydata1 struct {
    a int
    b int
    c int
}

type maindata struct {
    mydata1
    a int
}

func main() {
    d1 := mydata1{a: 11, b: 12, c: 13}
    mdata := maindata{mydata1: d1, a: 99}
    fmt.Println(mdata)
    fmt.Println(mdata.a)
}

これを実行すると、以下のように、親(ネスト元)のフィールドaの値が優先されるようです。

{{11 12 13} 99}
99

では、ネストする構造体が2つ以上あり、その構造体に同じフィールド名があるとどうなるのでしょうか？やってみます。

import "fmt"

type mydata1 struct {
    a int
    b int
    c int
}

type mydata2 struct {
    a int
    b int
    c int
}

type maindata struct {
    mydata1
    mydata2
    a int
}

func main() {
    d1 := mydata1{a: 11, b: 12, c: 13}
    d2 := mydata2{a: 21, b: 22, c: 23}
    mdata := maindata{mydata1: d1, mydata2: d2, a: 99}
    fmt.Println(mdata)
    fmt.Println(mdata.b)
}

これを実行すると、以下のようにmydata1にもmydata2にもbというフィールドがあって曖昧なため、コンパイル時にエラーになりました。

./main.go:28:19: ambiguous selector mdata.b

なお、上記はmdata.bにアクセスしていますが、mdata.aの場合、親にaというフィールドがあるため、コンパイルエラーにならず、99が表示されます。

以上、GO言語の実験でした。

環境 : GOバージョン 1.11.4 on Linux

-- 2020/9 追記 ----
似たツールとして、crane コマンドについても記事を書きました。
---------------------

Dockerを実行しているサーバがインターネットに接続されていないオフライン環境だと、docker pull ができず困ってしまう場合があります。そのような時、インターネットに繋がっている他の端末でイメージをダウンロードして、それをtarファイルにしてscpやらUSBメモリやら経由でコピーすればいいのですが、DockerイメージダウンロードするためだけにDockerをインストールするのが大袈裟なことがあります。

そのような場合、graboid コマンドを使うと簡単にイメージをDockerなしで手動ダウンロードすることができます。graboid は、GO言語で書かれたコマンドラインツールで、Linuxだけでなく、MacやWindowsにも対応しています。インストール方法は簡単で、GitHub のリリースページにバイナリが公開されているため、これをダウンロードし展開するだけです。

ここではWindowsを例に、試してみたいと思います。

ブラウザから、https://github.com/blacktop/graboid/releases/download/0.14.0/graboid_0.14.0_win_amd64.zip をダウンロードし、ダウンロードしたzipを展開すると、graboid.exe というファイルがでてきます。あとは、コマンドプロンプトを起動し、graboid.exe にDockerHubのイメージを引数で渡すだけです。ここでは、c:\tmp にgraboid.exe があると仮定し、busybox のDockerイメージをダウンロードしてみます。
※ プロキシ使用時は、HTTPS_PROXY 環境変数を定義しておけば良いみたい。

C:\>cd c:\tmp
c:\tmp>graboid.exe busybox:latest
[34m •[0m Initialize Registry [34mdomain[0m=https://index.docker.io [34mimage[0m=library/busybox [34mtag[0m=latest
[34m •[0m getting auth token
[34m •[0m GET CONFIG
[34m •[0m GET LAYERS
716.06 KiB / 716.06 KiB [====================================================] 100.00% 0s
[34m •[0m CREATE manifest.json
[34m •[0m CREATE docker image tarball: library_busybox.tar
[34m •[0m [1mSUCCESS![0m

Windowsのコマンドプロンプトだと、若干表示がおかしいですが、無事ダウンロードできようなので、ファイルを確認します。

c:\tmp>dir
ドライブ C のボリューム ラベルは Windows です


c:\tmp のディレクトリ

2018/09/18 11:02 <DIR> .
2018/09/18 11:02 <DIR> ..
1979/12/31 00:00 5,664,256 graboid.exe
2018/09/18 11:02 734,502 library_busybox.tar
2 個のファイル 6,398,758 バイト
2 個のディレクトリ 38,434,910,208 バイトの空き領域

上記の通り、library_busybox.tar ファイルが生成されました。あとは、これをDockerの動いているサーバにコピーし、インポートすれば作業完了です。

# docker load  < library_busybox.tar

ちなみに、LinuxやCygwinのプロンプトだと、ダウンロード時の表示はこのように綺麗に表示されました。

$ ./graboid.exe busybox:latest
• Initialize Registry domain=https://index.docker.io image=library/busybox tag=latest
• getting auth token
• GET CONFIG
• GET LAYERS
716.06 KiB / 716.06 KiB [====================================================] 100.00% 0s
• CREATE manifest.json
• CREATE docker image tarball: library_busybox.tar
• SUCCESS!

WSL上のLinux (Microsoft Store)からインストールしたUbuntu 18.04は、/mnt/c 配下からCドライブにアクセスできますが、Windows側からアクセスするには、以下のフォルダにアクセスすると見ることができます。

C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs

※ インストールしたUbuntuのバージョンによって、Ubuntu18.04 の文字列が若干変わると思います。

ただ、上記フォルダにExplorerからアクセスすることは推奨されていませんし、Explorerから試しにファイル作成しても、WSL上ではファイルを見ることができませんでした。緊急時の参照用として使う程度に留めておいたほうがよさそうです。

CentOS 7にデフォルトで同梱されているリモートデスクトップクライアント(freerdp)は、変換キーや無変換キーなど一部のキーが使えません。最新のfreerdpではこれが修正されているようなので、入れ替えて使ってみました。

いちからコンパイルするのは面倒なので、バイナリを探していたところ、以下で見つけましたのでこれを使用させていただきます。(使用は自己責任です)

http://yumrepo.tntechs.com/yum-repository/local/centos/tntechs-testing/7/x86_64/

一つづつrpmをダウンロードしてもよいですが、CentOS 7用のリポジトリとして提供してくれているので、/etc/yum.repos.d/tntechs.repo というファイルを作成して、以下を記述します。

[tntechs]
name=tntechs
baseurl=http://yumrepo.tntechs.com/yum-repository/local/centos/tntechs-testing/7/x86_64/
gpgcheck=0

 

これで、yum install freerdp を実行したら、パッケージの依存関係で以下のエラーが出て失敗します。

エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-utils.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-utils.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-channels.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-channels.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-kbd.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-kbd.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-core.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-core.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-codec.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-codec.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-rail.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-rail.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません
エラー: パッケージ: vinagre-3.22.0-9.el7.x86_64 (@anaconda)
要求: libfreerdp-gdi.so.1.0()(64bit)
削除中: freerdp-libs-1.0.2-15.el7.x86_64 (@anaconda)
libfreerdp-gdi.so.1.0()(64bit)
次のものにより更新された: : 2:freerdp-libs-2.0.0-39.20180314gitf8baeb7.el7.tnt.x86_64 (tntechs)
見つかりません

vinagre は、GNOME向けのVNCクライアントらしいですが、私の環境では使ってないので、これを削除したらうまくいきました。

# yum remove vinagre
# yum install freerdp

これでxfreerdpというコマンドが使えるようになりました。

$ xfreerdp /u:mazn /f /v:192.168.0.1

/u:がユーザ名、/f がフルスクリーン、/vが接続先サーバを指定するためのオプションです。毎回コマンドで指定してもよいですが、面倒なので、同じく上記サイトで提供されているremminaというツールもインストールしました。RDPを使いたいので、remminaのrdpプラグインも一緒に入れておきます。

# yum install remmina remmina-plugins-rdp

ここで配布されているremminaですが、RDP接続時にフルスクリーンで接続するオプションが見当たりません。しかし、右Ctrl+f でフルスクリーンにすることができますので、お試しあれ。

最近コンテナ触ってると、どのプロセスがどのネームスペースで動いているのか確認したくなります。コンテナのネームスペースをコンテナ毎に調べてもいいですが、実はpsコマンドで見ることができます。

具体的には、-o オプション使って以下のように実行すれば、ネットワークネームスペースとPID,コマンド等を見ることができます。ちなみにNETNSの数字はinode番号を意味しています。

# ps -e -o netns,pid,cmd
 NETNS PID PPID CMD
4026531957 1 0 /sbin/init splash
4026531957 2 0 [kthreadd]
4026531957 3 2 [ksoftirqd/0]
4026531957 5 2 [kworker/0:0H]
4026531957 7 2 [rcu_sched]
4026531957 8 2 [rcu_bh]
4026531957 9 2 [migration/0]
4026531957 10 2 [watchdog/0]
4026531957 11 2 [watchdog/1]
4026531957 12 2 [migration/1]
4026531957 13 2 [ksoftirqd/1]
4026531957 15 2 [kworker/1:0H]
4026531957 16 2 [kdevtmpfs]
4026531957 17 2 [netns]
4026531957 18 2 [perf]
4026531957 19 2 [khungtaskd]
4026531957 20 2 [writeback]
4026531957 21 2 [ksmd]
～以下略～

 

プロセスツリーみたければ、pstree でも見ることができます。以下はKubernetesが動いている環境で実行した時の例ですが、このようにネームスペース毎にプロセスツリーを表示してくれます。

# pstree -N net
～ 略 ～
[4026532229]
dashboard───7*[{dashboard}]
pause
[4026532441]
pause
bash
[4026532514]
pause
server───6*[{server}]
[4026532580]
pause
dumb-init───nginx-ingress-c─┬─nginx───2*[nginx───32*[{nginx}]]
 └─10*[{nginx-ingress-c}]
[4026532359]
pause
kube-dns───8*[{kube-dns}]
dnsmasq-nanny─┬─dnsmasq
 └─8*[{dnsmasq-nanny}]

 

Lenovo の Trackpointキーボード 0B47208を使っているのですが、デフォルトではFnキーを押さないと F1～F12キーが使えません。これが不便なので、レジストリいじって振る舞いを逆にしました。

対象のレジストリは以下で、これをデフォルトの0から1に変更するだけです。

HKEY_CURRENT_USER\Software\Lenovo\fnlock

変更しただけでは反映されないので、USBを一旦抜き差ししてください。

Windows 10 の WSL 上の Ubuntu 上のアプリでGUI(X)が使えるようにしてみました。

WSLにはGUIを描画する機能がないため、WindowsにXサーバをインストールします。Xサーバは、VcXsrv を使用しました。インストールは簡単なので割愛します。

次に、WSL 上の Ubuntu に X 関連のパッケージをインストールします。rootで作業してください。

# apt-get install build-essential libssl-dev libreadline-dev zlib1g-dev x11-apps x11-utils x11-xserver-utils  fonts-ipafont libxml2-dev libxslt1-dev fontconfig

Windowsのフォントも参照できるようにします。

# ln -s /mnt/c/Windows/Fonts /usr/share/fonts/windows
# fc-cache -fv

 

最後に、VcXsrv を起動し、WSLでVxXsrvの場所を指定します。

# export DISPLAY="localhost:0.0"

 

xeys とか xedit とか起動してみて、無事GUIが表示されれば成功です。

参考 http://estuarine.jp/2017/11/wsl-x-window/

自前のDNSサーバをたてて、ホストを登録してWindowsから登録したホストにpingを飛ばそうとしたら失敗します。

例えば、centos というホスト名を登録したとします。この時、nslookupの結果は以下のようになります。

C:\Users\user1>nslookup centos
サーバー: dns1
Address: 172.16.0.1

名前: centos
Address: 172.16.0.10

 

なのに、ping を打つと以下のようにエラーとなります。

C:\Users\user1>ping centos
ping 要求ではホスト centos が見つかりませんでした。ホスト名を確認してもう一度実行してください。

 

これは、Windowsのネットワークの名前解決の仕様に原因があります。

Windowsは、"." (ドット) を含まないホスト名は、DNSを見に行きません！

つまり、今回登録したホスト名 "centos" に ping を打つ場合、DNS を使いません。その結果、上記のエラーが発生していたようです。

よって、ホスト名に"."をつけるとDNSを見に行ってくれます。

C:\Users\user1>ping centos.
centos [172.16.0.10]に ping を送信しています 32 バイトのデータ:
172.16.0.10 からの応答: バイト数 =32 時間 =3ms TTL=63

 

参考 : https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb457118(v=technet.10)

mosh (mobile shell) は、NWが不安定で接続が切れたり、IP が変わっても接続を維持することがsshです。

主要なLinuxでは、バイナリパッケージがあるので、簡単にインストールできるのですが、cygwin から接続したい場合、cygwin向けのバイナリがないので、自分でコンパイルする必要が出てきます。

コンパイルは、https://gist.github.com/eerohele/2349067 を参考に実施しましたが、最新のcygwinやmoshでは若干異なるので、以下にメモ残します。

使用したバージョンは、mosh-1.3.2 + protobuf-3.5.1です。

まずはcygwinに必要なパッケージですが、私の環境では以下をインストールしました。

gcc-core gcc-c++ make libncurses-devel pkg-config perl boost-build openssl-devel zlib-devel

moshコンパイルに必要なprotobufをコンパイルします。

$ wget https://github.com/google/protobuf/releases/download/v3.5.1/protobuf-all-3.5.1.tar.gz
$ tar zxvf protobuf-all-3.5.1.tar.gz
$ cd protobuf-3.5.1
$ ./configure
$ make
$ make install 
$ cd ..

moshをコンパイルします。

$ wget https://github.com/mobile-shell/mosh/releases/download/mosh-1.3.2/mosh-1.3.2.tar.gz
$ tar zxvf mosh-1.3.2.tar.gz
$ cd mosh-1.3.2
$ ./configure CPFLAGS="-I/usr/include/ncurses" PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
$ make
$ make install

以上で、mosh　コマンドが使えるようになりました。

Linuxサーバ上にdnsmasqで DNSサーバ立てて、自宅内のサーバの名前解決に使おうと思ったが、なぜかWindowsからだと名前解決できません。

具体的には、Linuxの/etc/hosts に以下を追加し、これをdnsmasqで使用したとします。

192.168.0.10  hoge

他のLinuxサーバからだと、dig コマンドで hoge を名前解決できるし、ping hoge で通信もできます。

しかし、Windowsの場合、nslookup hogeで192.168.0.10が回答されるのに、ping hoge とかブラウザのURLで指定すると、そんなホストは存在しないと言われます。

調べたところ、Windows は、ドット "." を含まないホスト名はどうやらDNSサーバに問い合わせに行かない仕様のようです。 つまり、ping hoge. だといけました。

参考 http://tyru.hatenablog.com/entry/20130206/windows_wont_lookup_hostname_without_dot

IE11 から、どうもローカルにあるProxy.pacが読み込まれてないように思って調べてみたら、案の定、デフォルトでは読み込まれない仕様に変わったようです。

従来通り読み込みたい場合は、レジストリエディタで

キー：HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

を開き

値：EnableLegacyAutoProxyFeatures 種類：REG_DWORD データ：1

を作りましょう

CentOS コミュニティはCentOS のクラウドイメージを公式に配布していますが、デフォルトではrootでログインできず、クラウド上でVM作成時にsshキーを登録し、centosユーザでログインする必要があります。rootのパスワードは非公開なので、centosユーザでログイン後、sudo を使ってパスワードを自分で設定すればよいのですが、これだけではssh経由ではログインできません。

ssh経由でrootログインするには以下の設定が必要になります。

1. /root/.ssh/authorized_keysの設定を変更する

authorized_keys には、

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"centos\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAAB ・・・ (以下略)

という設定があるので、先頭からssh-rsaの前までの文字列を削除し、以下のようにします。

ssh-rsa AAAAB ・・・ (以下略)

これで、rootログイン時にcentosユーザでログインしろという警告が消えます。

1. sshサーバの設定を変更する

sshサーバの設定(/etc/ssh/sshd_config)でrootログインが許可されていないので、これを有効にします。

PermitRootLogin yes  # rootログインを許可する設定
PasswordAuthentication yes  # パスワードログインも許可する場合はこれを設定する

あとは、sshdを再起動すれば、rootでログインできるはずです。

# systemctl restart sshd

なお、インスタンス起動時に、centosユーザと同様sshの公開キーはrootユーザにも設定されているので、パスワードなしでログインできるはずです。

1. その他設定

インスタンスのスナップショットをとって、スナップショットからインスタンスを起動すると、1 の設定をまた実施する必要がでてきます。これは、cloudinit というツールがCentOS7のイメージにインストールされており、新しいインスタンス起動時に再度無効化されてしまうのが原因です。

同じテスト環境をスナップショットから複数起動したい場合など、この動作は結構不便なので、設定を無効化する方法を紹介します。

設定は、/etc/cloud/cloud.cfgのdisable_rootを以下のように変更します。

disable_root: 0

この設定をした後に、インスタンスのスナップショットをとれば、スナップショットから新たに起動したインスタンスにすぐにrootログインできます。

なお、これら設定はセキュリティが落ちるため、第三者がアクセスできる環境で使う場合はご注意ください。

RDO を使ってOpenStack Pikeをallinoneでインストールした時のメモ。

基本的に、公式ページを見ながら構築したが、公式手順だと外部ネットワークに繋がらないため、一部修正しています。

まずは、CentOSを最小インストールでインストール。インストール時の言語は失敗を避けるために、とりあえずEnglishにし、IPは固定でインストールしました。詳細は省略。

OSの邪魔なサービスの停止

# systemctl disable firewalld
systemctl stop firewalld
systemctl disable NetworkManager
systemctl stop NetworkManager
systemctl enable network
systemctl start network

公式手順に則って、言語を設定

# echo "LANG=en_US.utf-8" > /etc/environment
echo "LC_ALL=en_US.utf-8" >> /etc/environment

OSをアップデート

# yum update -y

 

ここで一旦OSを再起動。

# shutdown -r now

OpenStack Pikeのリポジトリを追加・有効化

# yum install -y centos-release-openstack-pike
yum-config-manager --enable openstack-pike

Packstackインストール

# yum install -y openstack-packstack

 

packstackの設定ファイル生成。enp4s0はホストのNICを指定しています。passwordは適当に好きなものに変更してもらってOKです。

# packstack --gen-answer-file=/root/answer.txt --default-password=password --ntp-servers=ntp.nict.jp --os-neutron-ovs-bridge-mappings=external:br-ex --os-neutron-ovs-bridge-interfaces=br-ex:enp4s0

 

answerファイルを編集。変更したのは以下の行ぐらいです。

CONFIG_CEILOMETER_INSTALL=n
CONFIG_AODH_INSTALL=n
CONFIG_GNOCCHI_INSTALL=n
CONFIG_CINDER_VOLUMES_SIZE=200G
CONFIG_PROVISION_DEMO=n

 

インストール実行

# packstack --answer-file=/root/answer.txt

 

数十分で完了します。

完了後、ブラウザでホストのIPに接続し、ユーザ"admin"、パスワードは"password"でログインできることを確認します。

ここからは、コマンドで外部ネットワークに接続するための準備をしていきます。openrcファイル読み込み

# source /root/keystonerc_admin

ホストがつながっているNWは、172.16.0.0/16 を前提に、ネットワークを作成します。

# neutron net-create public --provider:network_type flat --provider:physical_network extnet --router:external neutron subnet-create public --name public_subnet --allocation-pool start=172.16.250.1,end=172.16.250.255 --disable-dhcp --gateway 172.160.0.1 172.16.0.0/16

 

ルータを作成し、外部ネットワークにつなぎます。

# neutron router-create router1 --ha False
neutron router-gateway-set router1 public

 

後は、必要に応じてHorizonなりコマンド使って、テナント内にネットワーク作れば完了です。