ネットワーク遅延

ネットワーク遅延について理解が曖昧だったのでおさらいしました。

調べ方

測定したいサーバのいずれかからpingコマンドを使って調べます。

gceのインスタンスからヤフージャパンとyahooを測定します。

$ ping -c 2 www.yahoo.co.jp
PING ***.jp (***.***.***.***): 56 data bytes
64 bytes from 183.79.248.252: icmp_seq=0 ttl=51 time=132.073 ms
64 bytes from 183.79.248.252: icmp_seq=1 ttl=51 time=131.703 ms
--- edge.g.yimg.jp ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 131.703/131.888/132.073/0.185 ms
$ ping -c 2 www.yahoo.com
PING ***.jp (***.***.***.***): 56 data bytes
64 bytes from 98.139.180.181: icmp_seq=0 ttl=48 time=29.914 ms
64 bytes from 98.139.180.181: icmp_seq=1 ttl=48 time=29.397 ms
--- atsv2-fp.wg1.b.yahoo.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.397/29.655/29.914/0.259 ms
$ 

各サイトは、単なるサンプルなので以降は、サンプル１、サンプル２とします。

読み方

最初の1行目で送信先IPアドレスとデータ部が56バイトのパケットを送信していることがわかります。パケットサイズは、-sオプションで指定が可能です。

-cで指定した回数送信が試みられます。1パケット1行の結果が表示されます。56バイトのデータ部と8バイトのヘッダで計64バイトのパケットが送信されます。time=がRTTです。

RTT（round-trip time）は、パケットを送信して応答があるまでの時間です。

最後の２行は、パケットロスの発生とRTTの統計情報がでます。

スループット

パケットの最大サイズとRTTからネットワークのスループットが分かります。論理的に最大で送信できるデータ量を把握したり、複数の測定結果を比較することで性能差や改善を確認するといったことができるようになります。

パケットの最大サイズ

ifconfigで対象のNICを指定してパケットの最大サイズを確認できます。例えば、下記のようにするとeth0のMTUを見ることでパケットの最大サイズが1,460バイトであることがわかります。

$ ifconfig eth0 | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1460  Metric:1
$ 

スループット

最初のサンプル１とサンプル２のRTTを使ってスループットを計算します。

計算	サンプル１	サンプル２
1秒間に送信できるパケット数	1,000ミリ秒÷131.888≒7.6回	1,000ミリ秒÷29.655≒33.7回
1秒間に送信できる最大サイズ（バイト／秒）	1,460バイト✕7.6回≒11,070バイト／秒	1,460バイト✕33.7≒49,233バイト
1秒間に送信できる最大ビット（ビット／秒）	11,070✕8ビット≒88,560ビット／秒	49,233✕8ビット≒393,863ビット
スループット	88,560÷1024≒86Kbps	393,863÷1024≒385Kbps

データ送信にかかる時間を計算する

スループットと送信データサイズから送信にかかる時間を計算します。

サンプル１のスループットで1GBのデータを送信するのにかかる時間です。

計算	サンプル１の計算式
データサイズ	8,589,934,592ビット＝1GB✕1024✕1024✕1024✕8ビット
回線速度	88,064bps≒86Kbps✕1024
転送時間	8,589,934,592bit÷88,064bit✕伝送効率

転送効率が100%だったとしても27時間くらいかかります。

実測値から転送効率を計算する

実際にデータ送信にかかった時間から転送効率を計算します。

サンプル１のスループットで1GBのデータを送信するのに40時間かかった場合の転送効率です。

計算	サンプル１の計算式
送信時間	144,000秒 = 40時間✕60分✕60秒
データサイズ	8,589,934,592ビット＝1GB✕1024✕1024✕1024✕8ビット
回線速度	88,064bps≒86Kbps✕1024
転送速度	59,652bps = 8,589,934,592ビット÷144,000秒
転送効率	0.677≒59,652bps÷88,064bps

このケースでは、転送効率は、67.7%となります。

gitで過去のコミットを書き換える

gitの最初のcommitにパスワードを書き込んでpushしたとします。さらに、しばらくcommit/pushを繰り返したとします。

下記の手順でパスワードを全てマスクした文字に書き換える事ができますが、cloneして作業している人すべてに影響がでるので作業前には関係者への連絡と準備が必須です。

事前確認

ブランチがクリーンなことを確認します。

$ git status
ブランチ master
nothing to commit, working tree clean
$

下記のようにpasswordが含まれているファイルをを確認します。

$ git grep password
file.txt:password
$

書き換え

filter-branchの--tree-filterオプションで各コミットに実行するコマンドを指定します。 確認したfile.txtをsedで書き換えます。

$ git filter-branch -f --tree-filter "sed -i -e 's/password/mask/' file.txt" HEAD
Rewrite c5974de297ec5360d0dfce499abccc3073ba0211 (2/2) (0 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten
$

確認

下記の通りpasswordは、消えて…

$ git grep password
$

maskになっています。

$ git grep mask
file.txt:mask
$

以上

pythonの開発環境その２

以前にdirenvとvirtualenvでpythonの開発環境を作る手順を書きました。

ksaito11.hatenablog.com

pythonzを使うとpythonのバージョンも選択できるようになります。

前提パッケージ

ubuntu17.04に下記の前提パッケー時をインストールします。

$ apt-get install -y \
            build-essential \
            zlib1g-dev \
            libbz2-dev \
            libssl-dev \
            libreadline-dev \
            libncurses5-dev \
            libsqlite3-dev \
            libgdbm-dev \
            libdb-dev \
            libexpat-dev \
            libpcap-dev \
            liblzma-dev \
            libpcre3-dev \
            curl \
            python-pip \
            virtualenv

pythonzのインストール

pythonzのREADME.mdの手順をansibleのplaybookにしました。

$ cat python.yml
---
- name: python develop environment
  hosts: all
  tasks:
    - name: pythonzのインストール確認
      stat: path="{{ ansible_user_dir }}/.pythonz/etc/bashrc"
      register: stat
    - name: pythonzのインストール
      shell: curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash
      when: not stat.stat.exists
    - name: pythonzの設定
      lineinfile:
        dest: "{{ ansible_user_dir }}/.bashrc"
        state: present
        line: "[[ -s $HOME/.pythonz/etc/bashrc ]] && source $HOME/.pythonz/etc/bashrc"
$ ansible-playbook python.yml -c local

pythonのインストール

使いたいバージョンのpythonをインストールします。

$ pythonz install 3.5.0

direnvの設定

direnvの設定は、前回の記事を参照下さい。

direnvに使いたいバージョンを

$ direnv edit .
$ cat .envrc
layout python $(pythonz locate 3.5.0)
$

これで、使いたいバージョンのpythonを利用することが出来ます。

$ cd tmp
direnv: loading .envrc
direnv: export +VIRTUAL_ENV ~PATH
(0)18:31:05 ksaito@dind$ python --version
Python 3.5.0
$

pipのパッケージも環境毎に独立した物になります。

$ pip list --format=columns
Package       Version
------------- -------
appdirs       1.4.3
boto          2.46.1
packaging     16.8
pip           9.0.1
pkg-resources 0.0.0
setuptools    35.0.2
six           1.10.0
wheel         0.29.0
$

プロキシの設定する

プロキシ環境下では、プロキシサーバを設定しないとインターネットに接続できません。 環境変数に設定する場所は、/etc/environmentや/etc/profile.dだったり、$HOMEの各種シェルの.profileと、いろいろな場所で設定できます。 yumやaptといったコマンド毎にも設定場所があり、正しく設定されているか非常に不安になります。

さらに、各種仮想環境やコンテナ環境で、設定場所や反映されるタイミングがいろいろなので整理が必要です。

下記の方針を墨守します。

• GitにコミットするDockerfileや設定ファイルにプロキシサーバを直書きしない
• プロキシの設定をシンプルに保ち、（最終的には）ansibleのplay bookにする
• 一度に沢山考えすぎない…

OS

設定は、/etc/environmentにすることで利用するログインシェルによらず、OS全体で設定できる。

docker build

docker buildでは、--build-argに環境変数を参照して設定する。

makeを使った場合、下記で実行環境に設定されたプロキシ設定を利用できる。

$ grep BUILD_OPTS Makefile
BUILD_OPTS=--build-arg http_proxy=$(shell echo $$http_proxy) --build-arg https_proxy=$(shell echo $$https_proxy) --build-arg no_proxy=$(shell echo $$no_proxy)
        docker build -t $(NAME) $(BUILD_OPTS) .
$ make -nB
docker build -t docker-bp --build-arg http_proxy=http://proxy.co.jp:8080 --build-arg https_proxy=http://proxy.co.jp:8080 --build-arg no_proxy= .
touch build
$

続きは、また今度…

以上

systemdのサービスをansible-playbookのhandlersでうまく記述する方法

ansible-playbookのhandlersでserviceを使ってサービスをリスタート出来ますが、systemdのサービスを再起動しようとしてもエラーになります。

systemdは、設定変更時にsystemctl daemin-reloadを実行してからサービスを再起動する必要があるためです。

下記の例は、systemdで起動するdocker daemonの例です。

handlersに、shellを使ってsystemctl daemin-reloadするハンドラとserviceを使ってリスタートするハンドラを定義します。

notifyで、２つのハンドラを順番に呼び出すことで正しくサービスを再起動してくれます。

tasks:
    - block:
        - name: create docker daemon systemd directory
          file:
            path: "/etc/systemd/system/docker.service.d"
            state: directory
            owner: root
            group: root
            mode: "u=rwx,g=rx,o=rx"
        - name: setup docker daemon proxy
          template:
            src: "{{ item }}.j2"
            dest: "/etc/systemd/system/docker.service.d/{{ item }}"
            owner: root
            group: root
            mode: "u=rw,g=r,o=r"
          notify:
            - daemon reload
            - restart docker
          with_items:
            - 50-http-proxy.conf
      when: http_proxy != ""

  handlers:
    - name: daemon reload
      shell: systemctl daemon-reload
    - name: restart docker
      service: name=docker state=restarted

docker runすると/bin/bash: /bin/bash: cannot execute binary fileが出る場合の対処

コンテナのデバッグで下記のコマンドをよく使います。

$ docker run -it --rm <イメージ> /bin/sh

zabbixのオフシャルイメージの幾つかで下記のようなエラーがでてしばらく悩みました。

$ docker run -it --rm zabbix/zabbix-agent:alpine-3.2-latest /bin/sh
/bin/sh: /bin/sh: cannot execute binary file
$

次のように実行することでエラーを回避出来ます。

$ docker run -it --rm zabbix/zabbix-agent:alpine-3.2-latest -i
bash-4.3#

原因と再現手順

オフシャルイメージのDockerfileを見ると、ENTRYPOINTとCMDは、下記のように書かれています。

$ tail -3 Dockerfile
ENTRYPOINT ["/bin/bash"]

CMD ["/run_zabbix_component.sh", "agentd", "none"]
$

5. CMD and ENTRYPOINT better togetherにENTRYPOINTとCMDを併用することでコンテナ化したバイナリのアプリケーションをENTRYPOINTに指定して、CMDにデフォルトの振る舞いに必要なオプションを指定するというベストプラクティスが紹介されています。

今回のケースでは、ENTRYPOINTに/bin/bashが指定されていることで引数に指定した/bin/bashをシェルスクリプトと想定して実行しようとしたためにエラーとなりました。

再現してみると下記のようなことが発生していることになります。-iオプションは、bashの対話的な起動オプションでCMDに指定されたシェルを無効にするためのワークアラウンドです。

$ docker run -it --rm zabbix/zabbix-agent:alpine-3.2-latest /bin/bash
/bin/bash: /bin/bash: cannot execute binary file
$ docker run -it --rm zabbix/zabbix-agent:alpine-3.2-latest -i
bash-4.3# /bin/bash /bin/bash
/bin/bash: /bin/bash: cannot execute binary file
bash-4.3#

ENTRYPOINTにシェル以外のバイナリが指定されているコンテナの場合は、下記のような別解で対応します。

$ docker run --entrypoint /bin/sh -it --rm zabbix/zabbix-agent:alpine-3.2-latest
/var/lib/zabbix #

これで、Dockerfileの設定にかかわらず内容を確認できるようになりました。

s3cmd syncでシンボリックリンクのコピー

s3cmd syncで下記のようなシンボリックリンクをコピーすると無限に深いディレクトリを作り続けます。（何れどこかでエラーになると思いますが…）

$ ls -l .fcpcache
lrwxr-xr-x@ 1 user  staff  1  3 11 16:40 .fcpcache -> .
$