blog.monophile.net

コンピュータのこととかのメモ。

山本 一彰 | Takaaki Yamamoto

東京工業大学において計算機科学と応用数学を学び、 情報科学芸術大学院大学[IAMAS]においてメディア表現を専攻し修了。 2015年にコンビネータ論理を基に計算完備な計算手法 "論理珠算"を開発し、 それを含む体系である"算道"を構成した。 その成果により、 第19回 文化庁メディア芸術祭 アート部門 新人賞 (文部科学大臣賞) を2016年に受賞。 現在はインフラエンジニアとして生計をたててている。

技術

各種システムの設計/構築/運用を承ります。

Configuration Management Ansible, Terraform, cloud-init
Cloud Platform AWS, Azure, GCP, Openstack
Openstack Keystone, Glance, Cinder(Ceph), Neutron(VLAN), Nova(QEMU), Horizon
Virtualization QEMU+KVM, LXD/LXC, Docker
OS Ubuntu, Debian GNU/Linux, CentOS, ...
Storage Ceph, GlusterFS, ZFS, btrfs, ...
Networks Tunnel(IPSec, L2TP, VXLAN, GRE), WirelessAP, ...
DB MySQL, MariaDB(Galera Cluster), MongoDB
Mail postfix, dovecot
WebApps WordPress, GitLab, MatterMost, Redmine, RainLoop, ...
Monitoring Nagios, Munin
Misc certbot, dnsmasq, ...

技術(習得中)

Orchestration Kubernetes
Openstack swift, manila, trove
OS CoreOS(Container Linux), Vyatta(VyOS), ...
Networks IPv6, BGP(quagga, calico), flannel, fan, ...
DB/KVS Redis, etcd
Monitoring Prometheus, Zabbix
DNS CoreDNS, PowerDNS
Misc MAAS, Blockchain

投稿

graph-easyで有向グラフのアスキーアートを描いてみる

概要

簡単なフローチャートとかネットワーク図とかをドキュメントに載せたいが、 画像だと大げさだったので、アスキーアートにしたかった。 graph-easyというのを使えばできるみたいだったので、ためしたみた。

graph-easyをインストール

↓はUbuntu16.04でインストールする場合。

$ sudo apt install libgraph-easy-perl

(例) 計算の過程を表す図

graph-easyは標準入力からデータを受け取るので、 「入力(input)を受け取り計算(calculation)して出力(output)する図」は↓のようにすればよい。

$ echo '[input] -> { label: calculation } [output]' | graph-easy

すると↓の出力が得られる。

+-------+  calculation   +--------+
| input | -------------> | output |
+-------+                +--------+

(例) 4つの物理NICをボンディングして仮想ブリッジに接続した図

「4つの物理NICをボンディングして仮想ブリッジに接続した場合」 のLinux内のネットワークインターフェースの図を描いた例。 少しコードが長くなるので、↓を interfaces.txt として保存する。

[eth1] { size: 1,1 }
[eth2] { size: 1,1; origin: eth1; offset: 0,1; }
[eth3] { size: 1,1; origin: eth1; offset: 0,2; }
[eth4] { size: 1,1; origin: eth1; offset: 0,3; }
[bond] { size: 1,4; origin: eth1; offset: 3,0; }

(bonding:
  [eth1] -> { label: LACP } [bond]
  [eth2] -> { label: LACP } [bond]
  [eth3] -> { label: LACP } [bond]
  [eth4] -> { label: LACP } [bond]
)

[br]    { origin: bond; offset: 0,2; }
[br.10] { origin: br; offset: 0,1; label: br.10 (192.168.10.xx/24); }
[br.20] { origin: br; offset: 0,2; label: br.20 (192.168.20.xx/24); }
[br.30] { origin: br; offset: 0,3; label: br.30 (192.168.30.xx/24); }

(bridge:
  [br], [br.10], [br.20], [br.30]
)

[bond] -> [br]

そして↓を実行する。

$ cat interfaces.txt | graph-easy

すると↓の出力が得られる。

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
' bonding:                                               '
'                                                        '
' +--------+      LACP      +--------------------------+ '
' |  eth1  | -------------> |                          | '
' +--------+                |                          | '
' +--------+      LACP      |                          | '
' |  eth2  | -------------> |                          | '
' +--------+                |           bond           | '
' +--------+      LACP      |                          | '
' |  eth3  | -------------> |                          | '
' +--------+                |                          | '
' +--------+      LACP      |                          | '
' |  eth4  | -------------> |                          | '
' +--------+                +--------------------------+ '
'                                                        '
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
                              |
                              |
                              v
                          + - - - - - - - - - - - - - - -+
                          ' bridge:                      '
                          '                              '
                          ' +--------------------------+ '
                          ' |            br            | '
                          ' +--------------------------+ '
                          ' +--------------------------+ '
                          ' | br.10 (192.168.10.xx/24) | '
                          ' +--------------------------+ '
                          ' +--------------------------+ '
                          ' | br.20 (192.168.20.xx/24) | '
                          ' +--------------------------+ '
                          ' +--------------------------+ '
                          ' | br.30 (192.168.30.xx/24) | '
                          ' +--------------------------+ '
                          '                              '
                          + - - - - - - - - - - - - - - -+

めでたしめでたし。

参考

cronの代わりにsystemdのtimerで定期実行を定義してみる

概要

UNIX環境で定期的に処理を実行する場合は一般的にcronを使う。 しかし、cronを使うとログのことに気を遣うのが嫌だった。 (ログの置き場所とか、ログのローテーションとか…。) systemdだとjournaldが一括してログを管理してくれて便利そうだったので、試してみた。 (journaldの設定は /etc/systemd/journald.conf を編集すればよい。)

今回は5秒毎くらいに“hello”を標準出力する処理を実装してみる。 試した環境はUbuntu16.04。

systemd.timer

systemd.timerを使うためには最低2つのファイルが必要になる。 一つは XXXXX.service という処理そのものを定義するファイルで、 もう一つは XXXXX.service をどのタイミングで実行するかを定義する XXXXX.timer というファイル。 XXXXXはserviceとtimerで同じでも異なっていてもいいが、 わかりやすくするために同じの方が良いと思う。 異なっている場合は[Timer]のセクションで明示的にUnit=の指定が必要になる。

マニュアルは↓でみれる。

$ man systemd.timer

わかりやすかったのは↓のwiki。

echo@.service

/lib/systemd/system/echo@.service を↓のように記述する。

[Unit]
Description = echo service

[Service]
Type = oneshot
ExecStart = /bin/echo %i

↑のサービスは↓を実行すると “/bin/echo hoge” が実行される。

$ sudo systemctl start echo@hoge.service

つまり、echo@AAAA.service のAAAAが%iに代入されて実行される。

echo@.timer

上記で定義したサービス echo@.service を2+5n秒毎(誤差2秒)に実行するecho@.timerを定義する。

/lib/systemd/system/echo@.timer を↓のように記述する。

[Unit]
Description = echo@ timer
Wants = multi-user.target
After = multi-user.target

[Timer]
OnCalendar = *-*-* *:*:2/5
RandomizedDelaySec = 2s
Unit = echo@%i.service

[Install]
WantedBy = timers.target

.timer でも .service と同じように@と%iでの置換ができる。

タイマーを起動する

↓で再起動後に自動的に echo@hello.timer が起動するように設定する。

$ sudo systemctl enable echo@hello.timer
Created symlink from /etc/systemd/system/timers.target.wants/echo@hello.timer to /lib/systemd/system/echo@.timer.

↓でecho@hello.timerを起動する。

$ sudo systemctl start echo@hello.timer

するとecho@hello.timerの状態は↓になる。

$ sudo systemctl status echo@hello.timer
● echo@hello.timer - echo@ timer
   Loaded: loaded (/lib/systemd/system/echo@.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Sat 2018-01-13 20:46:59 JST; 16s ago

Jan 13 20:46:59 timer01 systemd[1]: Started echo@ timer.

↓でだいたい5秒ごとくらいに echo@hello.service が動いていることが確認できる。

$ sudo journalctl -u echo@hello
-- Logs begin at Sat 2018-01-13 20:44:19 JST, end at Sat 2018-01-13 20:48:29 JST. --
Jan 13 20:47:16 timer01 systemd[1]: Starting echo service...
Jan 13 20:47:16 timer01 echo[2198]: hello
Jan 13 20:47:16 timer01 systemd[1]: Started echo service.
Jan 13 20:47:33 timer01 systemd[1]: Starting echo service...
Jan 13 20:47:33 timer01 echo[2213]: hello
Jan 13 20:47:33 timer01 systemd[1]: Started echo service.
Jan 13 20:47:50 timer01 systemd[1]: Starting echo service...
Jan 13 20:47:50 timer01 echo[2214]: hello
Jan 13 20:47:50 timer01 systemd[1]: Started echo service.

(おまけ) 定義されているtimerを確認する

起動したてのUbuntu16.04のtimerの状態は↓で確認できる。

$ systemctl list-timers --all
NEXT                         LEFT          LAST PASSED UNIT                         ACTIVATES
Sat 2018-01-13 18:56:24 JST  10min left    n/a  n/a    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sat 2018-01-13 21:27:14 JST  2h 41min left n/a  n/a    snapd.refresh.timer          snapd.refresh.service
Sun 2018-01-14 11:59:07 JST  17h left      n/a  n/a    apt-daily.timer              apt-daily.service
Sun 2018-01-14 15:00:37 JST  20h left      n/a  n/a    apt-daily-upgrade.timer      apt-daily-upgrade.service
n/a                          n/a           n/a  n/a    snapd.snap-repair.timer      snapd.snap-repair.service
n/a                          n/a           n/a  n/a    ureadahead-stop.timer        ureadahead-stop.service

6 timers listed.

(おまけ) サービスの依存関係

systemdはサービスの依存関係を細かく設定できるが、 ユーザレベルで動く処理はmulti-user.targetに依存するように指定しておけば良いと思う。 詳しくは↓を参照。

参考

socatでtapインターフェースを作成して認証も暗号化もしないVPN

概要

socatでTUN/TAPインターフェースを扱えるらしく、 UDPで転送すれば簡単なVPNが構成できそうだったので、やってみた。 認証も暗号化も行わない。 想定する環境は↓。

サーバ クライアント
OS Linux Linux
UDPで接続するIP 192.168.1.1 192.168.1.2
tap1のIP 10.0.0.1/24 10.0.0.2/24

サーバ側

サーバ側で↓を行うとUDPの1194番ポートでListenされる。

$ sudo socat udp-listen:1194,reuseaddr,range=192.168.1.2/32 tun:10.0.0.1/24,tun-type=tap,tun-name=tap1,iff-up,iff-promisc

一応↑ではrangeオプションでクライアントのIPからのみ許可するように設定しているが、 セキュリティ的にはよくはない。

そして、この段階ではまだサーバ側にはtap1インターフェースはできていないはず。

クライアント側

サーバ192.168.1.1:1194につなぎに行くように↓を行う。

$ sudo socat udp:192.168.1.1:1194 tun:10.0.0.2/24,tun-type=tap,tun-name=tap1,iff-up,iff-promisc

するとクライアント側にtap1インターフェースが作成された。

$ ip link show tap1
56: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether ce:2d:c2:a5:12:f0 brd ff:ff:ff:ff:ff:ff promiscuity 1

IPアドレス10.0.0.2/24も付加されている。

$ ip addr show tap1
56: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether ce:2d:c2:a5:12:f0 brd ff:ff:ff:ff:ff:ff promiscuity 1
    tun
    inet 10.0.0.2/24 brd 10.0.0.255 scope global tap1
       valid_lft forever preferred_lft forever

pingをクライアントからサーバへ打つ

この状態でpingをクライアント側からサーバ側10.0.0.1へ打ってみるとpingが返ってくる。

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.20 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.750 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.748 ms

そして、サーバ側にtap1インターフェースが作成されていることがわかる↓。

$ ip addr show tap1
39: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether ee:fe:01:71:e7:87 brd ff:ff:ff:ff:ff:ff promiscuity 1
    tun
    inet 10.0.0.1/24 brd 10.0.0.255 scope global tap1
       valid_lft forever preferred_lft forever

MTUの調整

上記で作成されたtap1インターフェースのMTUをサーバ側とクライアント側の両方で設定しておく。

Layer byte
IP 20
UDP 8
Ethernet 18

tapデバイスはイーサネットのフレームも含むため、 L3までに含まれるの各種ヘッダの量は↑である。 したがって、VPNを張りたい経路のMTUが1500の場合、 tap1に設定されるべきMTUは(1500 - 20 - 8 - 18) => 1454と計算できる。

$ sudo ip link set dev tap1 mtu 1454

備考

TUN/TAPのうちTAPにしたかったのは仮想ブリッジに接続したかったからだが、 仮想ブリッジの作成まで記事に含めるのは冗長な気がしたので、 tap1インターフェースに直接IPを振った。

ちなみに、socatはopensslも使えるため暗号化できそうだが、 残念ながらTCPをバインドしてしまって、UDPでは不可能だった。 一方で、openssl s_serverでDTLSを指定するとUDPをバインドすることは確認できたので、 そのうちsocatも対応してくれそうな気がする。

参考

LXDで使用するvethインターフェースの名前を指定して起動する

概要

LXDでコンテナを立ち上げると、ホスト側とコンテナ側にvethペアが作られる。 このときコンテナ側にできるインターフェースの名前はプロファイルで eth0 などに指定できるが、 ホスト側にできるインターフェースの名前はコンテナ毎に違う名前にしなければならないため、 単一のプロファイルでは指定できない。 (指定できるが複数のコンテナを立ち上げたときにエラーが発生する。) 指定しない場合はランダムに vethXXXXXX のようなインターフェースが作成される。

ホスト側のvethインターフェースの名前を指定できると、 iptablesのphysdevオプションでフィルタリングがしやすくなるため、設定したかった。 そこで、コンテナ起動時に指定する方法とコンテナ毎に個別にプロファイルを作成する2つの方法を試してみた。

defaultプロファイルによってコンテナを立ち上げた場合

通常defaultプロファイルは↓のようになっていると思われる。

$ lxc profile show default
config: {}
description: ""
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default

この状態でコンテナx01を立ち上げる。

$ lxc launch ubuntu:x x01
Creating x01
Starting x01

この場合、x01にはeth0が作成された。

$ lxc exec x03 -- /sbin/ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
33: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:08:11:45 brd ff:ff:ff:ff:ff:ff link-netnsid 0

そして、ホスト側にはvethdf49293aというインターフェースができた。

$ /sbin/ip link show dev vethdf49293a
24: vethdf49293a@if23: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master lxdbr state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
   link/ether e6:26:35:5a:f6:72 brd ff:ff:ff:ff:ff:ff link-netnsid 1

コンテナ起動時に指定する方法

プロファイルはdefaultのままで、コンテナ起動時に volatile.eth0.host_name を設定。

$ lxc launch ubuntu:x x02 -c volatile.eth0.host_name=veth-x02

するとホスト側に veth-x02 というインターフェースが作成された。

$ /sbin/ip link show dev veth-x02
30: veth-x02@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr state UP mode DEFAULT group default qlen 1000
    link/ether fe:62:1b:c3:20:1e brd ff:ff:ff:ff:ff:ff link-netnsid 3

プロファイルを個別に作る方法

プロファイルをdefaultから複製し、 devices.eth0.host_name に veth-x03 を設定したプロファイルx03を用意し、 プロファイルx03を指定してコンテナを起動する。

$ lxc profile copy default x03
$ lxc profile device set x03 eth0 host_name veth-x03
$ lxc launch ubuntu:x x03 -p x03

するとホスト側に veth-x03 インターフェースが作成された。

$ /sbin/ip link show dev veth-x03
34: veth-x03@if33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr state UP mode DEFAULT group default qlen 1000

めでたし、めでたし。

参考

DockerのプライベートレジストリをWebUI(docker-registry-web)とともに使ってみる

概要

Docker Swarmを使うためにDockerのプライベートレジストリを立てた。 レジストリの中を閲覧したり削除したりするのにWebUIがあると便利そうだな、 と思って調べてみたら良さそうなの↓があったので使ってみた。

Docker Swarmを初期化する。

使ったDockerは17.09。

$ docker --version
Docker version 17.09.1-ce, build 19e2cf6

↓でDocker Swarmを初期化する。

$ docker swarm init

docker-compose.registry.yml

  • プライベートレジストリはSwarmのマネージャノードで立ち上げる。
  • プライベートレジストリには http://localhost:5000/ でアクセスできるようにする。
  • WebUIには http://localhost:5001/ でアクセスできるようにする。
  • レジストリの閲覧だけでなく削除もできるようにする。

上記の要件を満たすように、 ↓ docker-compose.registry.yml を用意する。

version: '3.4'

networks:
  registry:
    driver: overlay

volumes:
  registry:
    driver: local

services:
  registry:
    image: registry:2
    ports:
    - target:    5000
      published: 5000
      protocol:  tcp
      mode:      ingress
    volumes:
    - registry:/var/lib/registry
    deploy:
      placement:
        constraints:
        - node.role == manager
    environment:
    - REGISTRY_STORAGE_DELETE_ENABLED=true

  registry-web:
    image: hyper/docker-registry-web
    ports:
    - target:    8080
      published: 5001
      protocol:  tcp
      mode:      ingress
    environment:
    - REGISTRY_URL=http://registry:5000/v2
    - REGISTRY_NAME=registry:5000
    - REGISTRY_READONLY=false

環境変数の設定については↓を参照するとよい。

プライベートレジストリとWebUIを立ち上げる

↓でプライベートレジストリとWebUIを立ち上げる。

$ docker deploy -c docker-compose.registry.yml registry
Creating network registry_default
Creating service registry_registry-web
Creating service registry_registry

↓で立ち上がったことが確認できる。

$ docker service ls | tr -s " " | column -ts " "
ID            NAME                   MODE        REPLICAS  IMAGE                             PORTS
oit2xuizkhe9  registry_registry      replicated  1/1       registry:2                        *:5000->5000/tcp
rcko6ppvy4zg  registry_registry-web  replicated  1/1       hyper/docker-registry-web:latest  *:5001->8080/tcp

↓のように空の応答がレジストリサーバから返ってくればOK。

$ curl localhost:5000/v2/
{}

さらに↓でWebUIにアクセスできるはず。 (まだ何も入れていないので、もちろん空っぽ。)

Ubuntuの公式イメージをローカルレジストリにpushしてみる

↓でUbuntu公式イメージを取ってくる。

$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
50aff78429b1: Already exists
f6d82e297bce: Already exists
275abb2c8a6f: Already exists
9f15a39356d6: Already exists
fc0342a94c89: Already exists
Digest: sha256:ec0e4e8bf2c1178e025099eed57c566959bb408c6b478c284c1683bc4298b683
Status: Downloaded newer image for ubuntu:latest

↓取ってきたイメージに localhost:5000/ubuntu:latest というタグをつける。

$ docker image tag ubuntu:latest localhost:5000/ubuntu:latest

↓タグを付けたイメージをプライベートリポジトリにpushする。

$ docker image push localhost:5000/ubuntu:latest
The push refers to a repository [localhost:5000/ubuntu]
f17fc24fb8d0: Pushed
6458f770d435: Pushed
5a876f8f1a3d: Pushed
d2f8c05d353b: Pushed
48e0baf45d4d: Pushed
latest: digest: sha256:f871d0805ee3ce1c52b0608108dbdf1b447a34d22d5c7278a3a9dd78fc12c663 size: 1357

この状態でWebUIをみると↓のようにアップロードしたイメージを見ることができ、 さらに削除も可能。

めでたし、めでたし。