git-crecord

はじめに

gitのコミット時に行単位でコミットする部分を選択できるツール git-crecord に４年ぶりにリリースタグが付けられていましたので、 設定方法をメモしておきます。

git-crecordには、

• 部分選択コミット作業に特化
• テキストユーザーインターフェイス(ncursesベースのCUI)
• 操作方法が直感的なので覚えることはほぼなし（習得が簡単！）

という特徴があります。コミット以外の作業もテキストユーザーインターフェイスで行いたい場合は 多機能なtigのほうが便利でしょう。 なお、git-crecordはMercurialの拡張機能であるcrecord(※１)のgit移植版です。

設定

https://github.com/andrewshadura/git-crecord からgitでcloneします。このメモの作成時点では Python 3.6 以降が必要とのことです。

あとは、cloneしたディレクトリにあるgit-crecordがgitから見つけられるようPATHを通すだけです。 すでに、~/.local/bin/にパスが通っているのであれば、 そこにgit-crecordへのリンクを作成するのが最も簡単でしょう。 名前はgit-crecordのままである必要があります。

実行例

gitリポジトリでgit crecordを実行すると、

Select hunks to commit - [x]=selected **=collapsed  c: confirm     
q: abort  arrow keys: move/expand/collapse  space: deselect        
?: help                                                            
[x]    diff --git a/aaa.txt b/a.txt                                
       similarity index 100%                                       
       rename from aaa.txt                                         
       rename to a.txt                                             
                                                                   
___________________________________________________________________
[x]    diff --git a/b.txt b/b.txt                                  
       new file mode 100644                                        
                                                                   
   [x]     @@ -0,0 +1,1 @@                                         
      [x]  +bbb                                                    
___________________________________________________________________
[~]    diff --git a/c.txt b/c.txt                                  
       index 1e2c877..7bd5b45 100644                               
       2 hunks, 3 lines changed                                    
                                                                   
   [~]     @@ -1,3 +1,4 @@                                         
            ccc                                                    
      [x]  -ddd                                                    
      [ ]  +111                                                    
      [x]  +dDd                                                    
            eee                                                    
                                                                   
   [x]     @@ -3,0 +5,1 @@                                         
      [x]  +333                                                    

のような画面が表示されます。使い方はみたままです。 スペースキーでコミットする部分を行単位またはハンク単位、ファイル単位で選択できますので、選んだ後にcキーを押せばコミット処理が開始されます。

補足

(※１) Mercurialの設定ファイルに

[ui]
interface = curses

と書いておけば hg commit -i で使えます。

仮想ファイルシステムをユーザー権限でマウント

準備

libguestfs-toolsが必要ですので、apt等でインストールしておきます。

ファイルシステムの作成

マウントしてアクセスしたいファイルシステムを作成します。ここでは例として、ディレクトリ１個とファイルが２個あるファイルシステムを作ります。

$ mkdir fs
$ echo "abc" > fs/abc.txt
$ mkdir fs/sub
$ echo "cde" > fs/sub/cde.txt
$ tree
.
├── abc.txt
└── sub
    └── cde.txt

1 directory, 2 files
$ virt-make-fs -t ext4 -s +10M fs fs.img

これで、fs.imgにファイルシステムが作成されます。 -t ext4により、ext4でファイルシステムを作成することを指定しています。軽量なものが良ければ、ext2がよいそうです。 -s +10M により、空き容量を10MB付け加えたファイルシステムを作るよう指定しています。

ファイルシステムのマウント

ファイルシステムが作成できましたので、これをマウントしてみます。マウントポイントはmpとします。ルート権限は不要です。

$ mkdir mp
$ guestmount -a fs.img -m /dev/sda mp
$ tree mp
mp
├── abc.txt
├── lost+found
└── sub
    └── cde.txt

2 directories, 2 files

マウントできました。今回作成したイメージの場合、-mオプションは省略できません。

dfで見てもマウントできていることが確認できます。

$ df -h -t fuse
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/fuse         11M  199K  9.1M    3% /home/xxx/yyy/mp

ファイルの書き込みもできますし、もともと用意していたファイルの表示もできます。

$ cd mp
$ echo "xyz" > xyz.txt
$ cat xyz.txt
xyz
$ cat abc.txt
abc
$ cat sub/cde.txt 
cde

ファイルシステムのアンマウント

アンマウントも簡単にできます。

$ guestunmount mp
$ tree mp
mp

0 directories, 0 files

まとめ

仮想ディスクの作成からマウントし、読み書きして、アンマウントするところまで簡単にできました。 この仕組みを使えば、何かデータを処理したい計算機にファイルシステムごとデータを移動したり、 結果を回収したり、バックアップしたりする作業がお手軽にできそうです。

Kubernetesでコンテナ間ssh接続を試してみる

はじめに

Kubernetes (k8s) のPOD間でssh接続できるように設定してみます。

minikubeのインストール

k8sの環境を作るのにminikubeを利用します。
https://minikube.sigs.k8s.io/docs/start/
を参考にインストールします。LinuxとWindows、macOSに対応しているようです。

ここでは、Windowsで試してみます。仮想マシンが必要ですのでVirtualBoxなどをインストールしておきましょう。

インストールが完了したら、クラスタを開始します。

Windowsなのでコマンドプロンプトを開いて、

minikube start

を実行します。

自動的に準備が始まります。最初にいろいろダウンロードしますが、大きいものは、

• VMブートイメージ(minikube-v1.16.0) 212.6MiB
• Kubernetes(v1.20.0) 491MiB

でした。 ダウンロードが完了すると、virtualbox上にVMを作成し始めます。今回実行した環境ではCPUs=2, Memory=6000MB, 20000MBで作成されました。

kubectlが見つからないと言われるので、メッセージに書いてあるとおり、

minikube kubectl --get pods -A

を実行すると、39.52MiBのダウンロードが始まり、完了するとkubectlコマンドを使えるようになります。 上記コマンド自体は

NAMESPACE     NAME                               READY   STATUS    RESTARTS   AGE
kube-system   coredns-74ff55c5b-srhzs            1/1     Running   0          2m35s
kube-system   etcd-minikube                      1/1     Running   0          2m50s
kube-system   kube-apiserver-minikube            1/1     Running   0          2m50s
kube-system   kube-controller-manager-minikube   1/1     Running   0          2m50s
kube-system   kube-proxy-s8wbb                   1/1     Running   0          2m35s
kube-system   kube-scheduler-minikube            1/1     Running   0          2m50s
kube-system   storage-provisioner                1/1     Running   1          2m50s

という出力をします（出力前にコマンドがなかったら自動でダウンロードされるということのようです）。

sshキーの作成

コンテナ内にアクセスできるユーザを制限するため、sshの公開鍵と秘密鍵を作成しておきます。 Linuxではssh-keygenコマンドで作成できます。Windows環境ならWSL1で動作しているLinuxで作成すれば良いでしょう。詳細は省略しますが、ここでは id_rsa_xyz というキーを作成したとして進めます。

Pod上で動作させるDockerイメージの作成

https://minikube.sigs.k8s.io/docs/handbook/pushing/によると、 minikubeにssh接続してDockerのイメージを作るのがもっとも簡単のようです。

minikube ssh

でminikubeのノード内（VirtualBox内の環境）に入ることができます。ただし、コマンドプロンプトから入るとエスケープシーケンスが処理できず、バックスペースで文字の削除すらできません。

WindowsではWSL1が利用できるので、そこから入ることで回避します（WSL1の準備方法は省略）。WSLのターミナルを立ち上げて（ここではwslttyを利用）、同じコマンドを実行すると、今度はエスケープシーケンスの処理が正しくできます。

どのユーザでログインしたのかは、

$ pwd
/home/docker
$ who
docker  pts/0    xxxxxx

で確認できます。接続先のユーザはdockerになっているようです。

c:\Usersが最初からマウントされていて、minikubeのノード内からは/c/Users/...でアクセスできますので、これを使えばホストであるWindowsとファイルのやりとりができます。

このディレクトリに先程作成したsshキーの公開鍵(ここではid_rsa_xyz.pub)をコピーしておきます。

次に、sshサーバを動作させるDockerイメージを作成します。今回はWindows上でsshsrv.dockerファイルを以下の内容で作成します。

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y openssh-server
RUN mkdir /var/run/sshd
RUN useradd -m xyz && echo "xyz:xyz" | chpasswd
RUN mkdir -p /home/xyz/.ssh && chown xyz /home/xyz/.ssh && chmod 700 /home/xyz/.ssh
ADD ./id_rsa_xyz.pub /home/xyz/.ssh/authorized_keys
RUN chown xyz /home/xyz/.ssh/authorized_keys && chmod 600 /home/xyz/.ssh/authorized_keys
RUN bash -c "echo ForwardAgent yes" > ~/.ssh/config
CMD ["/usr/sbin/sshd", "-D"]

sshサーバの設定は
https://qiita.com/YumaInaura/items/1d5c18a9e55484ccad89
http://kotaroito.hatenablog.com/entry/2016/03/07/094423
を参考にしました。

なお、3行目の /var/run/sshd がないと

Missing privilege separation directory: /run/sshd

とメッセージが出てsshdを起動できません。

Dockerイメージを作成します。

docker build -f sshsrv.docker -t sshsrv:v1 .

sshdをコンテナ内で実行してみます。

docker run -d -p 222:22 --name sshsrv sshsrv:v1

-dはコンテナをバックグラウンドで動かすための引数です。付けわすれるとそのターミナルでは操作できなくなります（Ctrl+DもCtrl+Cも効かない ）。--nameで名前を付けておくと、docker psしたときに名前が表示されます。

コンテナ外からsshできるか試してみます。Windowsからアクセスするわけではなく、minikubeのノード内からsshsrvコンテナにアクセスします。 アクセスには秘密鍵かつパーミッションが適切である必要があるので、minikubeのノード内に秘密鍵であるid_rsa_xyzをコピーしてパーミッションも設定しておきます。

cp /c/Users/path/to/id_rsa_xyz ~/.ssh/
chmod 600 ~/.ssh/id_rsa_xyz
ssh-agent bash
ssh-add ~/.ssh/id_rsa_xyz
ssh -p 222 xyz@localhost

とすると、動いているコンテナの中に入ることができます。

動作確認ができましたので、コンテナ内から抜けて、今のコンテナは停止しておきます。

docker kill sshsrv
docker rm sshsrv

あとでコンテナ間接続で使うので、.ssh/configも設定しておきます。

echo "ForwardAgent yes" > ~/.ssh/config
chmod 600 ~/.ssh/config

なお、できあがったイメージの中にsshを使わずに入るには、

docker run --rm -it sshsrv:v1 /bin/bash

を実行すれば中にはいれますが、こちらは今回の目的とは異なりますので使う必要はありません。

k8sで実行

sshサーバを動かすコンテナが準備できましたので、ここではk8s経由で複数のsshサーバを立ててみます。 今回は試しに動作させて見るだけですので、Deploymentを使わずReplicaSetを使ってみます。

まず、k8sに指示するためのsshsrv.yamlファイルを作成します。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sshsrvset
spec:
  selector:
    matchLabels:
      app: sshsrv-template-label
  replicas: 3
  template:
    metadata:
      labels:
        app: sshsrv-template-label
    spec:
      containers:
      - name: sshsrv-template
        image: sshsrv:v1
        ports:
        - containerPort: 22

spec.template.metadata.labels に記述しているapp: sshsrv-template-labelがコンテナのテンプレート名です。

spec.template.spec 以下に、コンテナの設定が記述されています。

spec.template.spec.containers.name がテンプレートそのものの名前で、k8sが立ち上げるコンテナの名前の一部になります。

spec.template.spec.containers.image は前節で作成したDockerイメージの名前で、ここで指定したDockerイメージからコンテナが作成されます。

spec.template.spec.containers.ports のcontainerPort:22はssh接続用のポート番号となります。コメントアウトしてもsshでアクセスできるのでなくても良いのかもしれません。

spec.selector.matchLabels の app: sshsrv-template-labelは spec.template.metadata.labels に記載した内容と同じにします。このラベルを使って、PODに適用するテンプレートを探しているようです。同じyamlファイル中のtemplateが１個だけなら原理的にはtemplateは一意に特定できるので、わざわざlabelを設定する必要はなさそうにも思うのですが、selectorとtemplateの両方を書かないと動作しないので仕方がありません。

spec/replicas の3は、3個同じコンテナを立ち上げることを指示しています。

さて、yamlファイルが準備できましたので、コマンドプロンプトから実行します（WSL1からだとパスが処理できずminikubeを実行できません）。

minikube kubectl -- apply -f sshsrv.yml

minikube sshでminikubeのノード内に入って、docker ps -aを実行すると、

$ docker ps -a
CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS                     PORTS     NAMES
f14472bc0ace   66c4d55614da           "/usr/sbin/sshd -D"      3 minutes ago   Up 3 minutes                         k8s_sshsrv-template_sshsrvset-m8784_
default_48b8f9f7-0c48-4681-957e-96aad5d7ac57_0
8b9c796bc762   66c4d55614da           "/usr/sbin/sshd -D"      3 minutes ago   Up 3 minutes                         k8s_sshsrv-template_sshsrvset-t79pr_
default_72cb56bd-d4d8-42f5-8378-34ef7b6d9a1a_0
97849d1f2fbc   66c4d55614da           "/usr/sbin/sshd -D"      3 minutes ago   Up 3 minutes                         k8s_sshsrv-template_sshsrvset-wgqpr_
default_62c6fcee-26ac-4799-8e3d-59749ef8a3db_0

のような表示が得られます。3つ立ち上がっていることが確認できます。コマンドプロンプトに戻って

minikube kubectl -- get pods -o wide -l app=sshsrv-template-label

を実行すると、k8s上では

NAME              READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
sshsrvset-m8784   1/1     Running   0          3m    172.17.0.5   minikube              
sshsrvset-t79pr   1/1     Running   0          3m    172.17.0.4   minikube              
sshsrvset-wgqpr   1/1     Running   0          3m    172.17.0.3   minikube              

のような名前でコンテナが立ち上がっていることがわかります。IPアドレスも別々に割り振られているので、 minikubeのノード内から

$ ssh xyz@172.17.0.5

のようにすると、コンテナ内に接続できます。

コンテナを止めるには、コマンドプロンプトから

minikube kubectl -- delete replicaset sshsrvset

を実行します。

minikubeのノード内から各コンテナにssh

前節のようにコンテナを立ち上げても、IPアドレスがわからない場合には接続できません。 そこで、ランダム接続にはなってしまいますが、Serviceを作ります。 Serviceをつくると各コンテナに直接接続せず、Serviceで作成したIPアドレスとポートにつなぎにいけば、コンテナのいずれかに接続することができます。

まず、sshd-service.yamlを作成します。

apiVersion: v1
kind: Service
metadata:
  name: sshd-service
spec:
  type: ClusterIP
  selector:
    app: sshsrv-template-label
  ports:
  - protocol: TCP
    port: 22
    targetPort: 22

重要な点は、spec.selectorに書くラベルはReplicaSetのspec.template.metadata.labelsに記載しているラベルということです。 ReplicaSetのmetadata.nameではありません。また、ReplicaSetのyamlにmetadata.labelsの項目を作ってそこにラベルを書いてもそこは検索対象になりません。 なぜ、template側を参照する設計になっているのかは謎です。高度すぎてまるで分かりません。

さて、コマンドプロンプトからServiceを立ち上げます。

minikube kubectl -- apply -f sshd-service.yaml

立ち上げ後、

minikube kubectl -- get service -o wide

を実行すると表示されるsshd-serviceの行のCLUSTER-IPをたたけば、ReplicaSetで立ち上げたコンテナのいずれかにランダム（？）で接続できます。

ssh xyz@xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxxにはCLUSTER-IPに表示されたIPアドレスを入れます。

コンテナの中からさらに

ssh xyz@xxx.xxx.xxx.xxx

を実行すると、同様に接続できます。確証はありませんが、20回試した範囲では、接続先からは自分自身は除かれているようです。 ただし、２段の場合は自分自身に戻ってくることがあります。 コンテナA→コンテナB→コンテナAというパターンはあるが、コンテナA→コンテナAはなさそうということです。

ランダムではなく各ノードの負荷状況を考慮して接続するサーバを選びたいのですが、残念ながら方法がわかりませんでした。

コンテナ内からであれば、IPアドレスではなくドメイン名でアクセスすることもできます。

ssh xyz@sshd-service.default.svc.cluster.local

または、サービス名のみで

ssh xyz@sshd-service

でアクセスすることもできます。コンテナ内で/etc/resolv.confの中身を表示すれば、ドメイン名の解決のための 設定がどのようになっているのかが分かるかと思います。

Serviceの停止は、

minikube kubectl -- delete service sshd-service

で停止できます。

参考

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/ がk8sのAPIリファレンスです。kindがたくさんありますが、各kindがどういう役割のものなのかは、ここには記載されていません。yamlに記載する各フィールドの説明はしっかり記載されていますので、各kindを理解してから読むようにしましょう。

各kindがどういうものなのかはは、https://kubernetes.io/ja/docs/home/の検索窓にkind名を入力して検索すれば説明ページがでてきますので、それを参考にしましょう。

DeploymentとStatefulSetとJobだけはAPIリファレンスに短い解説がありましたので引用します。

• Deployments for stateless persistent apps (e.g. HTTP servers).
• StatefulSets for stateful persistent apps (e.g. databases).
• Jobs for run-to-completion apps (e.g. batch Jobs).

また、Pod, ReplicaSet, Deploymentについては https://blog.a-know.me/entry/2018/08/14/185324#Deploymentに解説記事があります。

kind名はたくさんありますし、一覧と概要説明がないと不便ですので、一部ではありますが一覧を作りました。 各説明文はkubernetes.io/ja/docsからの引用となります(kubernetes.ioのドキュメントのライセンス表記に従い、この一覧のみCC BY 4.0が適用されます)。

Kind	説明
Pod	Pod は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、クラスターで実行されているプロセスを表します。 https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-overview/
Job	Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。また、Jobを使用して複数のPodを並行して実行することもできます。 https://v1-18.docs.kubernetes.io/ja/docs/concepts/workloads/controllers/job/
ReplicaSet	ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。 https://kubernetes.io/ja/docs/concepts/workloads/controllers/replicaset/
Deployment	Deployment はPodとReplicaSetの宣言的なアップデート機能を提供します。Deploymentにおいて 理想的な状態 を記述すると、Deploymentコントローラーは指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ https://qiita.com/tkusumi/items/01cd18c59b742eebdc6a
StatefulSet	StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの順序と一意性を保証します。 Deploymentのように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。 https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/
Service	Podの集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。 KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。 https://kubernetes.io/ja/docs/concepts/services-networking/service/
Secret	KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。 Secretに機密情報を保存することは、それらをPodの定義やコンテナイメージに直接記載するより、安全で柔軟です。 https://kubernetes.io/ja/docs/concepts/secret/configuration/
ConfigMap	ConfigMapは、機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。Podは、環境変数、コマンドライン引数、またはボリューム内の設定ファイルとしてConfigMapを使用できます。 https://kubernetes.io/ja/docs/concepts/configuration/configmap/
Ingress	クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。Ingressは負荷分散、SSL終端、名前ベースの仮想ホスティングの機能を提供します。 https://kubernetes.io/ja/docs/concepts/services-networking/ingress/

VirtualBoxのゲストOSの時刻をNTPで同期させる

VirtualBoxでホストPCがサスペンドするとゲストOSの時刻がサスペンドしていた時間だけずれてしまうことがあります。

そこで、NTPを使って自動的に再設定されるようにしてみます。

ゲストOSが Debian 10 (buster) の場合は、次のようにすると自動設定されるようになります。 なお、ここで説明する方法では、ゲストOSをNTPサーバにはできません。

1. ntpdやchronydが動作しているのであればアンインストールします。
2. /usr/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.confの

   ConditionFileIsExecutable=!/usr/sbin/VBoxService
   

   の行をコメントアウトします（先頭に#を入れます）。
3. systemctl daemon-reloadを実行して、設定を更新します。
4. 最後に、systemd-timesyncd を

   systemctl start systemd-timesyncd

   で開始します。
5. 動作確認は、systemctl status systemd-timesyncdやtimedatectlでできます。

設定後、ホストPCをサスペンドさせ、しばらくしてから復帰させると、これまで通りゲストOSの時刻がずれますが、 しばらく待っていると自動的に正しい時刻に設定されます。