Macのターミナルの起動が遅すぎてつらかったので対処した

個人で使用しているMacも会社で使用しているMacもターミナルの起動に10秒くらいかかって、わりとストレスがたまる感じだったので対処方法を調べました。

標準のTerminalもiTermも同様に重たく、 zsh が起動に時間が掛かっているのを疑ったのですが、 oh-my-zsh などは使っていませんし、プロファイルを取ってみても一瞬で起動しているようでした。

起動時のターミナルのタイトルバーをよく見ると、 zsh の呼び出し元になっている login コマンドで時間が掛かっていました。

対処方法

あたりをつけて調べた所、すぐに同様の事象で困ってる人の記事を見つけました。

totem3.hatenablog.jp

asl というのは Apple System Log の略らしく、このログから最終ログイン日時を検索したりしているようなのですが、これが重いと読み込みに時間が掛かるようです。 この記事を参考に、

$ sudo rm -rf /var/log/asl/*.asl
$ sudo rm -rf /private/var/log/asl/*.asl

したあとに再起動すると、一瞬で起動するようになりました。

めでたしめでたし👏

Ansibleで牛が表示されるのをやめたい

きっかけ

久しぶりにAnsibleでサーバを構築していたのですが、なんかいつもと表示が違う…

f:id:kuro_m88:20160415203825p:plain

動物っぽいような…牛ですね。 そして、なんとなくこの出力、見覚えがあります。 cowsay コマンドだ!

$ cowsay "hello world"

_____________
< hello world >
 -------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

調べてみた

誰かのいたずらかと思ってplaybookを見てみたのですが、playbookを見ても特に異常はなく、なんなんだと悩んで調べてみると…

support.ansible.com

If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, or set an environment variable

cowsay コマンドがインストールされている場合は幸せになれる出力をしてくれるらしいです()

プロフェッショナルな cow-free な環境な場合は cowsay をアンインストールするか、 export ANSIBLE_NOCOWS=1 して環境変数cowsay を使わない事を宣言する必要があるようです。

対処

なんで手元の環境に cowsay コマンドが入っていたのかは分かりませんが、僕はプロフェッショナルな cow-free な環境なので

f:id:kuro_m88:20160415204057p:plain

ANSIBLE_NOCOWS=1 という環境変数を設定して実行することでいつもの出力に戻すことができました。

LXDで作ったコンテナをcloud-initで初期化してみる

LXD2.0がもうすぐリリースされますね!

LXDでコンテナが簡単に作れるようになったらコンテナ生成時にsshログインするための公開鍵を設定したり、任意のスクリプトを走らせたりしたくなりますよね。

調べてみたところ、LXDはcloud-initに対応していたようなので、試してみます。

実験環境

Ubuntu 15.10とLXD 2.0.0.rc8 です。

ubuntu@dev01:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=wily
DISTRIB_DESCRIPTION="Ubuntu 15.10"

ubuntu@dev01:~$ lxd --version
2.0.0.rc8

cloud-initの設定ファイルを作る

ドキュメントを見ながらcloud-initの設定ファイルを作ってみました。

Cloud config examples — Cloud-Init 0.7.7 documentation

#cloud-config

hostname: cloud-container

users:
  - name: user01
    shell: /bin/bash
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDRqP+9+b3ZHoXYyXo+V3g1K8AR+dBgYPUVdTieTtnLh2FPfKp9lGe9sLQcTDiWCiBvU9iUvx3m42gvzHeYht/SPjzske4ushSwS7wbz761dMyM9HL3jjmH8iIj/gyrARkBOUQj5e9TVvPtX8xfJOegHcxR/MssQsTlWcDdBsR0rV+DJAglMM11Rei5H46ZebYX8HCfg5BrYZlQtXJkHFNaMW59XlwL3Pk7i48MkHvApo8+2MHWU7gPSoo4guFl4G9M5BrRTpxiZbpnPkjxW+YX8u7UVZLR1OE0KgZeNUJK84dXq1cOAMWfM/6n5gPlGSUhGCoOGTinv3OCLGExvbrV ubuntu@dev01
    sudo: ALL=(ALL) NOPASSWD:ALL
  - user02
  - user03

runcmd:
  - [sh, -c, "echo 'hello world!' > /tmp/hello.txt"]

ホームディレクトリに cloud-init-config.yml という名前で保存しました。

設定項目としては、上から順に

  • ホスト名を cloud-container に設定する
  • ユーザ user01, user02, user03 を作成する
    • user01 は、シェルを bash に設定し、sshログイン用の 公開鍵 を設定、sudo 権限も付与する
  • /tmp/hello.txt を作成し、hello world! と書き込む

コンテナを作成する

作るだけで、まだ起動はしません。

ubuntu@dev01:~$ lxc init ubuntu:14.04 container
Creating container

ubuntu@dev01:~$ lxc list
+-----------+---------+-------------------+------+------------+-----------+
|   NAME    |  STATE  |       IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-----------+---------+-------------------+------+------------+-----------+
| container | STOPPED |                   |      | PERSISTENT | 0         |
+-----------+---------+-------------------+------+------------+-----------+

コンテナにcloud-initの設定をする

作成した設定ファイルの内容を流し込みます。

ubuntu@dev01:~$ ls
cloud-init-config.yml

ubuntu@dev01:~$ lxc config set container user.user-data - < cloud-init-config.yml

コンテナを起動する

ubuntu@dev01:~$ lxc start container

ubuntu@dev01:~$ lxc list
+-----------+---------+-------------------+------+------------+-----------+
|   NAME    |  STATE  |       IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-----------+---------+-------------------+------+------------+-----------+
| container | RUNNING | 10.0.3.251 (eth0) |      | PERSISTENT | 0         |
+-----------+---------+-------------------+------+------------+-----------+

確認

user01 を作成し、公開鍵を設定したので、sshができるようになっているはずです。

ubuntu@dev01:~$ lxc list
+-----------+---------+-------------------+------+------------+-----------+
|   NAME    |  STATE  |       IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-----------+---------+-------------------+------+------------+-----------+
| container | RUNNING | 10.0.3.251 (eth0) |      | PERSISTENT | 0         |
+-----------+---------+-------------------+------+------------+-----------+

ubuntu@dev01:~$ ssh user01@10.0.3.251

The authenticity of host '10.0.3.251 (10.0.3.251)' can't be established.
ECDSA key fingerprint is SHA256:hrredNI9D1T5QX12WC6McqxBGwl4+b1neq7g7KP5wCE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.3.251' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 4.2.0-34-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Tue Apr  5 11:52:16 UTC 2016

  System load:    0.0       Memory usage: 0%   Users logged in: 0
  Usage of /home: unknown   Swap usage:   0%

  => There were exceptions while processing one or more plugins. See
     /var/log/landscape/sysinfo.log for more information.

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.



The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

user01@cloud-container:~$
user01@cloud-container:~$ sudo su
sudo: unable to resolve host cloud-container
root@cloud-container:/home/user01#

ログインでき、sudoも成功しました。ホスト名も設定できていますね。

ユーザ一 user02, user03 も作成できたか確認します。

user01@cloud-container:~$ cat /etc/passwd | grep user
user03:x:1000:1000::/home/user03:
user02:x:1001:1001::/home/user02:
user01:x:1002:1002::/home/user01:/bin/bash

最後に、hello.txt が作成できたか確認します。

user01@cloud-container:~$ cat /tmp/hello.txt
hello world!

完璧ですね!

まとめ

LXDが標準でcloud-initに対応してくれているおかげでとっても簡単にコンテナの初期化ができました!

LXD最高!

参考

askubuntu.com

AWSのAvailability Zoneとロケーションの関係

シンプルなんだけど面白かったのでまとめました。

AZ(アベイラビリティーゾーン)とは

ご存知の方も多いと思いますが、AWS(EC2)のロケーションは、リージョンとアベイラビリティーゾーンという概念があります。

リージョンというのは、 東京バージニアサンパウロ などです。最近だと ソウル も追加されました。

アベイラビリティーゾーンというのは、同一リージョン内の独立したロケーションの単位(データセンターを想定するとだいたいあってる)で、 アベイラビリティーゾーン間の距離は「近距離」(数キロ〜数十キロらしい)にあるそうです。

参考: http://www.atmarkit.co.jp/ait/articles/1411/20/news106.html

AWSのドキュメントの図を引用するとこんな感じ。 f:id:kuro_m88:20160113123004p:plain http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

素朴な疑問

たとえば、東京リージョンであれば、 ap-northeast-1a , ap-northeast-1b , ap-northeast-1c 3つのAZがあります。
ここで疑問に思うのが「(冗長化構成を取らない場合) とりあえず ap-northeast-1aインスタンス立てそうだし、 ap-northeast-1a ばっかり選択されてAZごとのリソースの使用状況が偏るんじゃないか」ってことです。
僕だったらとりあえず1台立てるなら 1a を使ってますし、同じことを考えてる人が何百万人と居ると大変です。

シンプルな解決方法

ドキュメントをよく読んでみました。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

リソースがリージョンの複数のアベイラビリティーゾーンに分散されるようにするため、アベイラビリティーゾーンは各アカウントの識別子に個別にマップされます。たとえば、あるアカウントのアベイラビリティーゾーンは別のアカウントのus-east-1aアベイラビリティーゾーンと同じ場所にはない可能性がありますus-east-1a。

実はAZの識別子と実際のAZのロケーションの対応関係はAWSアカウントによって違う可能性があるようです。

この事を知っていると、以下のような疑問にも納得が行きます。

Tokyoリージョンにて、Regional data transferが計上されない現象について

異なるAZの間(ap-northeast-1aとap-northeast-1b)でプライベートIPアドレスを用いたTCP通信を行い、5GBのデータを送信しましたが、送信側アカウントにも受信側アカウントにもregional data transferの課金が生じません。これは正常な動作となりますでしょうか? https://forums.aws.amazon.com/thread.jspa?messageID=273850

単純ですが一番効果的な解決方法ですね!

追記 (2018/12/29)

AZ名と実際のAZのロケーションはAWSアカウントによって対応が違う場合があるのは変わっていませんが、AZ名とは別にAZ IDというものがリリースされました。これは実際のロケーションと対応していて、東京リージョンだと、 apne-az1 のようなフォーマットのようです。AZ IDを見れば異なるアカウント間の接続の際に同じロケーションで接続してレイテンシを抑えることができそうですね。

docs.aws.amazon.com