2020年2月2日日曜日 時刻: 22:26

ContOS8 StumpWM & Emacs 26.3


このエントリーをはてなブックマークに追加


気分を変えるために StumpWM を久々に動かしてみた。
StumpWM は Common Lisp で記述されたシンプルなウインドマネージャーで、タイル型と呼ばれるウインドマネージャーです。キーボードを中心に操作を行い、Emacs と相性が良いです。

xrdp で動かす場合の導入のメモを残しておきます。roswellのおかげですごく簡単になっています。

続きを読む >>>
2 コメント ラベル: ,

2019年11月30日土曜日 時刻: 23:47

ものぐさ playbook


このエントリーをはてなブックマークに追加


ちょっとした一発処理を Ansible で流そうとした時に、YAMLの Block Scalars(| とか > とか) と Jinja2 を組み合わせると１ファイルでいろんな処理が流せるようになるので便利です。

- hosts: localhost
  connection: local
  gather_facts: no
  vars:
    flag: false
    nodes:
      - 192.168.1.11
      - 192.168.1.12
      - 192.168.1.13
    private_key_path: /root/keypair.pem
  tasks:

    - shell: >-
        {% if flag %}
        echo "flag=true"
        {% else %}
        echo "flag=false"
        {% endif %}
      register: ret

    - debug: var=ret.stdout

    - copy:
        content: |
          [web]
          {% for i in nodes %}
          node-{{ loop.index }} ansible_host={{ i }}
          {% endfor %}
          
          [all:vars]
          ansible_user=centos
          ansible_ssh_private_key_file={{ private_key_path }}
        dest: result.txt

実行するとこんな感じ

$ ansible-playbook block_scalar.yml

PLAY [localhost] *********************************************************

TASK [shell] *************************************************************
changed: [localhost]

TASK [debug] *************************************************************
ok: [localhost] => {
    "ret.stdout": "flag=false"
}

TASK [copy] **************************************************************
changed: [localhost]

PLAY RECAP ***************************************************************
localhost : ok=3  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0


$ cat result.txt
[web]
node-1 ansible_host=192.168.1.11
node-2 ansible_host=192.168.1.12
node-3 ansible_host=192.168.1.13

[all:vars]
ansible_user=centos
ansible_ssh_private_key_file=/root/keypair.pem
1 コメント ラベル:

2019年10月14日月曜日 時刻: 5:27

"WARNING: Setting locale failed" with CentOS8 on Docker


このエントリーをはてなブックマークに追加


To fix:
dnf install -y glibc-all-langpacks

こんだけ。
0 コメント ラベル: ,

2018年12月11日火曜日 時刻: 13:09

uri モジュール


このエントリーをはてなブックマークに追加


Ansible には get_url というモジュールがあります。これは指定したURLを取得してターゲットホスト上に保存する機能をもち、ファイルのダウンロードなどに使われます。

似たようなモジュールでより汎用的なものとして uri があります。これはREST APIを叩いたり、WEBの動作確認など様々な使い方ができます。いわゆる curl コマンドのAnsibleモジュール版といっても良いでしょう。汎用HTTPリクエスト機能とも言いかえられるかもしれません。

このモジュールは shell などと同じく、冪等性を考慮していない汎用コマンド系なのでその点は注意が必要です。

公式のサンプルを少し見てみましょう。

続きを読む >>>
0 コメント ラベル:

時刻: 12:44

Assertモジュールによる「テスト、確認の自動化」とTAP(Test Anything Protocol)


このエントリーをはてなブックマークに追加


本記事は以下の12日目の記事です。ノウハウの塊です。
https://qiita.com/advent-calendar/2018/ansibleblogger

こっちもおすすめです。
https://qiita.com/advent-calendar/2018/ansible

Ansibleの「自動化の確かさ」ををテストするノウハウも最近ちらほらと出始めました。

このあたりの記事はとても参考になります。

- コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは
- Molecule入門
- Ansible Playbook の CI をまわす
- GitLab CIでAnsibleの自作モジュールのCIをやってみる

Moleculeはとても良いです。Roleのテストの方向性が固まって来た感があります。インフラCI実践ガイドで取り上げたかったですが、執筆の構想をしたときにはそれほどメジャーではなかったので見送りました（入れておけばよかった・・・

インフラにおけるAnsibleのテストはこんな感じで整理できます。

(1)Role単品のテスト
(2)Roleを組み合わせときのテスト
(3)出来上がった結果を確認するテスト
(4)上記が時間経過や周辺環境の変更があっても動くのかを確認するテスト

(1)はMoleculeでほぼ十分です。(4)に関しては(1, 2, 3)に対してマトリックスを組んでのテストになります。

(2)は現状では少々悩ましいです。問題が出やすいところでもあります。特にチームで開発した場合には、単品のロールとしては完璧でも、組み合わせると矛盾がでるケースがあるからです。Moleculeだけでできるのかもうちょっと研究が必要。

(3)はインテグレーションテストやシステムテストに相当するテストです。ここはテストのシナリオを書いて、独自で実装する必要があります。いわゆるブラックボックステストとして非機能要件やシステムの振る舞いを確認する必要があります。

前置きは長くなりましたが、Ansibleでなにかを確認したいとき、そこで活躍するのが assert モジュールです。
https://docs.ansible.com/ansible/latest/modules/assert_module.html

続きを読む >>>
0 コメント ラベル:

2018年11月30日金曜日 時刻: 18:19

手軽にAnsibleを試しながら勉強する方法


このエントリーをはてなブックマークに追加


Ansible Advent Calendar 2018 の1日目です。

最初に宣伝させてください。
Software Design 2018年12月号のAnsible特集に寄稿しました。Ansibleの入門からネットワーク機器管理、Tower/AWX、CIの触りまで幅広いテーマを扱っています。Ansible漫画も付属しているので、頑固な上司の机に忍ばせてAnsibleを理解させるたりと活用できると思います。




さて、Ansibleの勉強方法ですが、一番いいのは実際に手を動かすことです。書籍や記事もたくさんありますが、やはり手を動かして実際にAnsibleを動かしてみると、何ができて何ができないのか、Ansibleで自動化するために何をする必要があるのかを実感することができます。その後で様々な書籍や記事で基礎固めや実践的な知識を入手するのが良い方法です。
しかし、Ansible自身のインストールは簡単なのですが、実際に動かすためには自動化の対象となるノードを準備したりとやや手間がかかるのも事実です。

ということで、もっと簡単にAnsibleを体験してもらうために、ブラウザだけあればAnsibleがいろいろ試せる環境をKatacoda上に作成しました。Katacodaは受講者がブラウザだけで完結するハンズオンコースを実装できるSaaSサービスです。特にコンテナ関連のコースが充実しており、ここ最近注目を集めております。自分でコースを実装することも可能ですので、そちらを利用してAnsibleの入門コースを作成してみましたので使ってみてください。

続きを読む >>>
1 コメント ラベル: ,

2018年2月4日日曜日 時刻: 16:14

Hyper-V (Win10) で Nested する


このエントリーをはてなブックマークに追加


意味のわからないタイトルですが、ようは kvm on CentOS on hyper-v とか、virtualbox on windows on hyper-v とかをします。

ここを参考。
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

1. Hypter-V を有効にして仮想マシンを作成する

2. 起動する前に、PowerShellを管理者モードで起動して以下を実行
Set-VMProcessor -VMName <vmname> -ExposeVirtualizationExtensions $true

<vmname> のところには自分がつけた仮想マシンの名前を入れます。

以上。簡単ですね。

以下の画像は 母艦のWin10上の Hyper-V で CentOS7 を起動して、その CentOS の中で VirtualBox(vagrant) を起動しています。
2 コメント ラベル:

2017年12月25日月曜日 時刻: 0:00

Ansible: include の代わりに使う import_xxx, include_yyy とは


このエントリーをはてなブックマークに追加


この記事は Ansible Advent Calendar 2017 の一部です。

ここ数年、Advent Calendar の季節くらいしか記事を書かなくなってしまいました。もうちょっとアウトプットしたいのですが、色々手を出しすぎてなかなか時間が取れないのが悩みです。

さて、Ansible 2.4 をお使いの方は、以下のような警告をみたことがある方もいると思います。

[DEPRECATION WARNING]: The use of 'include' for tasks has been deprecated. Use 'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: include is kept for backwards compatibility but usage is discouraged. The module documentation details page may explain more about this rationale.. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

この警告は「include が廃止されるので別の方法に切り替えてね」というメッセージです。
include は Playbook や Task の再利用において重要な機能であるため、多くの方が include は当たり前の様に使っていると思います。

今回はこの変更点に触れていきたいと思います。


include モジュールは 2.8 で廃止予定

これはモジュールの解説ページにも記載されていますが、include は2.8をめどに完全に削除される予定になっています。
http://docs.ansible.com/ansible/latest/include_module.html

＊ include は実際にはモジュールではなく Ansible 本体の機能です。モジュールっぽく取り扱った方が説明が平易なため、ここでは include モジュールと表現していきます。


では代わりに何を使うかというと、

|-----------------+-----------------------------------+---------|
| module          | description                       | version |
|-----------------+-----------------------------------+---------|
| import_playbook | import a playbook.                |     2.4 |
| import_role     | Import a role into a play         |     2.4 |
| include_role    | Load and execute a role           |     2.2 |
| import_tasks    | import a task list.               |     2.4 |
| include_tasks   | dynamically include a task list.  |     2.4 |
|-----------------+-----------------------------------+---------|

になります。これらの違いは後に説明します。


どのような問題が include モジュールにはあったのか？

include モジュールは他のPlaybookやTaskを呼び出すことができますが、呼び出されるコンテキストによって挙動が変わるように実装されていました。特に2.0以降で include には Dynamic と Static という考え方も追加され、更にそれを特定条件で抑制したり有効にしたりと include の挙動が複雑化していました。

Dynamic と Static については去年のAnsible Advent Calendar 2016 「AnsibleのDynamic IncludeとStatic Include」で解説されています。

その結果、特に include のネストが深くなった際に予期せぬ動作が発生してしまうケースが報告されるようになりました(2.3で顕在化)。そのため、複雑化した include の動作を分解して、利用者が状況に応じて Dynamic と Static を使い分けるようにしよう、と今回の変更が行われたというのが経緯になります。


include_xxx, import_yyy の違い

こちらに詳しい説明があります。
https://docs.ansible.com/ansible/2.4/playbooks_reuse.html
https://docs.ansible.com/ansible/2.4/playbooks_reuse_includes.html

また、挙動の詳細に関しては先のブログでも例題付きで解説されていますので、ここではポイントのみを解説します。

import_yyy モジュール
Static
Playbookの読み込み時に一緒にimport先が読み込まれます（先読み）

include_xxx モジュール
Dynamic
Playbookの実行時に include 箇所まで処理が来た時にinclude先が読み込まれます（後読み）

role に関しては2.3より前では常に Static でしたが、2.3で追加された include_role でタスク内から Dynamic に呼び出す事が可能になっています。


具体的にどう使い分けるのか？

今までは include がいい感じに判断してくれていたので、あまり意識する必要はありませんでしたが、今後は幾つかのケースにおいては利用者がきっちりと使い分ける必要がでてきます。ここではその使い分けを意識するケースを紹介していきます。


■ループ系の処理と組み合わせる場合は include_yyy (Dynamic) しか使えない
おそらくこれが一番大きな点になります。
これらのループ処理と一緒に使う場合は、include_yyy しか使えません。
http://docs.ansible.com/ansible/latest/playbooks_loops.html


■変数化したファイル名を指定する場合には include_yyy (Dynamic) しか使えない
import_xxx はPlaybookの実行前に読み込みが行われるので変数の値は使えません。
これは先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。


■include_yyy した先のタグやタスクを取得することができない
例えば、import_xxx した場合は --list-tag で import_xxx の先のタグを表示し、指定することができますが、include_yyy ではできません。
これも先読み(Static)、後読み(Dynamic)の違いのわかりやすいケースです。


■nofify で include_yyy (Dynamic) の handler を認識できない。
Dynamicに指定されたファイルは実行時まで読み込まれないので「ハンドラーがない」とエラーになります。


まとめ

これから新しいPlaybookを書く場合には「includeは使わない」という事を覚えておけばあまり問題にならないと思います。import_xxx/include_yyy の使い方を間違えるとだいたいはエラーになるからです。

厄介なのは新旧のPlaybookが混在し include/import_xxx/include_yyy が入り乱れている場合です。
改修が難しい場合には、Ansibleのバージョンを固定して切り離した環境として使い捨てにしてしまうの1つの手です。
Ansible は利用者の増加に伴い、急速に機能・モジュールの拡充が進んでいます。バージョン固定すると新しいモジュールも使えなくなってしまうので、このあたりはバランスをどう取るかが課題です。

もし、今後のバージョンアップを含めてAnsibleを末永く使っていこうと計画している場合は、これを機にCI環境を整備して、Playbookの鮮度を保っていくという取り組みも有効です。


Ansible は目の前の作業を自動化するにはおそらく最も簡単な方法の一つです。ぜひ作業を自動化して得られた時間で、より自動化を活用するための「仕組み」も一緒に考えてみてください。

それでは皆様、来年もよい自動化を。
4 コメント ラベル:

2016年12月24日土曜日 時刻: 23:58

Make an IT infrastructure engineer great again


このエントリーをはてなブックマークに追加


こちらの24日目の記事なります。


今冬人気のドラマでこんなセリフがありました。
この前か後か忘れましたが「インフラエンジニアはいないと困るでしょう」というセリフもあったような気がします。たしかリストラの話の流れだったと思います。
この部分について、自分の思うところを書いてみようと思います。
確かにインフラエンジニアはいないと困るのですが、しかし「今までみたいなインフラエンジニア」はそのうちいなくても誰も困らなくなる、ってのが実際のところだと思います。

インフラエンジニアの置かれた状況は業種業態によって異なりますが、多くの環境ではインフラエンジニアの価値は下がり続けていると私は考えているからです。
ITインフラの優劣がビジネスに直結・大きな影響を与える通信キャリアや大規模なWEBやコンテンツサービスプロバイダーなどの例外も存在していますが、大多数を占める旧態然としたいわゆる企業の情シスに所属するインフラエンジニアやSIerのインフラエンジニアの価値は間違いなく低下の傾向であり、このままではいずれその価値は限りなくゼロ、むしろ企業にとっては経済的にマイナスの存在（お荷物）になるのでは、と器具しています。

この記事では、「なぜインフラエンジニアの価値が低下しているのか？」という点と「これからのインフラエンジニアはどうすべきなのか？」について自分の考えを整理してみようと思います。

続きを読む >>>
0 コメント ラベル:

2016年9月26日月曜日 時刻: 18:20

[改訂新版]プロのためのLinuxシステム構築・運用技術 (Software Design plus)


このエントリーをはてなブックマークに追加




@enakai00 さんが5年前に執筆された書籍の改訂版です。
現在主流のRHEL7系向けに書き直されています。

なんとなく仕事や趣味でLinuxを使っている人が、「プロ」と呼ばれるレベルに到達するために押さえておくべきポイントを実際の操作例や著者の体験を通した業務の経験をもとに解説されています。

章構成は こちら から確認できます。

クラウドやコンテナの活用に伴い、インフラエンジニアだけでなくアプリエンジニアもLinuxに触れる機会が増えています。
普段なんとなく使っているLinuxを深掘りして学習することは、クラウドやコンテナを一歩進んで活用するためにも役立ちます。

ちなみに、この本の内容は @enakai00 さんと私が担当している こちら と こちら の講義に大部分が組み込まれています(改定前の内容です

講義は OpenStack を題材にしたクラウド基盤の基礎コースですが、クラウドの裏側を理解するにはLinuxの知識が必要不可欠であるためです。
仕事でOpenStack等のクラウドの裏側に触れる機会のある方にもこの本の内容は有益(むしろ必須)です。

電子版もあります。
0 コメント ラベル: , ,

2016年9月8日木曜日 時刻: 16:15

docker コンテナのMTUを変更する - Changing container MTU on docker


このエントリーをはてなブックマークに追加


dockerd の起動オプションに --mtu xxxx をつけると、ブリッジ docker0 とコンテナに接続されるvethのMTUを変更できる。

you put the option "--mtu xxx" on dockerd option, you can change docker0/veth MTU on docker.



MTUを変更するには、/etc/sysconfig/docker-network に "-mtu" を記述しておけばオーケー。

In order to change the MTU, you write "--mtu" into the file "/etc/sysconfig/docker-network".



# vim /etc/sysconfig/docker-network

DOCKER_NETWORK_OPTIONS="--mtu=1400"


# reboot


# ps -ef |grep docker
root      2019     1  0 Sep06 ?        00:00:13 /usr/bin/docker-current daemon --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --mtu=1400


# ip link | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT
7: veth845af41@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master docker0 state UP mode DEFAULT
9: vethab65786@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master docker0 state UP mode DEFAULT
11: veth7ae7d07@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master docker0 state UP mode DEFAULT
0 コメント ラベル:

2016年7月26日火曜日 時刻: 0:45

JTF2016 にて（なぜか）孫子の話をしてきました


このエントリーをはてなブックマークに追加


July Tech Festa 2016 にて『今エンジニアに最も必要なものは「戦略」である！孫子に学ぶ本質のつかみ方』と題して発表させていただきました。

Tech Festaなのに戦略？孫子？？と思われる方もいるかもしれません（私もそう思わないでもありません）が、実はエンジニアにこそ「戦略」は重要なのです。
激変しつつあるIT業界で働く方には、何となく自分の取り組みにモヤモヤしたものを持っている方も多かったのか、予想外に多くの方に聞いていただけて大変うれしかったです。

発表に使った資料はこちら（詰め込みすぎて後半の時間が足りませんでした）


本発表で参考にした書籍からおすすめを紹介します。

戦略・戦術の解説のために使った「戦略の階層」はこちらの書籍に詳しく書かれています。


「芸の絶対化」の危険性など、先の大戦から日本人が陥りやすい失敗・思い込みなどがこちらで解説されています。


「エレベーターの待ち時間問題」の抜粋元です。名著ですが既に絶版です。図書館や工学系大学の図書館で読むことができます。


そして孫子です。孫子は解説含めてもかなり短い本ですので、ぜひ一読してみてください。その前に、一度「戦略」について理解していると、より深く孫子が理解出来ると思います。



ぜひ、自分なりの戦略を立ててみてください。
0 コメント ラベル: ,

2016年6月26日日曜日 時刻: 12:45

OpenStack/Heatによるオーケストレーション入門


このエントリーをはてなブックマークに追加


OpenStackユーザ会の第28回勉強会のネタです。


前回の完全版のネタになります。このネタは私が大学で担当している講義資料から抜粋しています（ほとんどそのまま

演習つきなので、興味があれば以下を見ながら試してみてください。
https://etherpad.openstack.org/p/r.16d9199da6f662084a2362e58d6d18e5


今回の勉強会の中で、実環境でHeatを使う際のいくつかの注意事項を述べたのでまとめておきます。

Heat「だけ」で全部やらない

これにつきます。
HeatはOpenStack上のリソースを配置、操作するだけならば他のツールに比べても優れています。記法はシンプルで操作方法もかなり単純です。しかし、OpenStackの外にあるものや、OpenStack上に作成されたインスタンス中を操作しようとすると途端に難易度が上がってきます（頑張ればできなくはない）

一昔前であれば、学習コスト等を謳い文句にして、1つのツールを徹底的に使いこなして細かな末端までカバーするのが良い、という宣伝がされていましたが、現在はこういうアプローチはあまりされません。
そのツールが得意なことだけをそのツールにやらせて、足りない部分はそこが得意な別のツールでカバーする、「ツールチェイン」のアプローチが一般的になってきています。

例えばOpenStack上のリソースを作成するのにはHeatを使い、作成されたインスタンスの設定はAnsibleで行う、といったようなやり方です。
Ansibleは汎用的な環境化で手順を自動化することが可能ですので、OpenStack上のリソースを作成して、そのリソースの起動を保証するといった事も出来なくはないのですが、やや複雑なプレイブックを書く必要が出てきます。
そこで、得意なリソースの作成と保証の部分をHeatにまかせて、Heatが作成したスタックの外部出力値を、Ansibleのダイナミックインベトリへ渡すといったやり方をすることで、結果として全体をシンプルにすることが可能になるのです。

ここではHeat + Ansibleの例をあげていますが、他の場合でも同様です。
皆様も自分の環境に合わせて、最適なツールチェーンを模索してみましょう。
0 コメント ラベル:

2016年2月15日月曜日 時刻: 21:03

CLML.LAPACK-ENVIRONMENT::DYNAMIC-HEAP-SPACE-TOO-SMALL


このエントリーをはてなブックマークに追加


SBCLで機械学習パッケージのCLMLを導入しようとすると、以下のエラーが出る場合があります。
When you try to install CLML on SBCL, you might encounter the blow problem.

COMMON-LISP:SIMPLE-TYPE-ERROR : CLML.LAPACK-ENVIRONMENT::DYNAMIC-HEAP-SPACE-TOO-SMALL does not designate a condition class.

この理由は実行環境のメモリ不足です。
This reason is too small memory size of lisp execution environment.

以下で解決できます。
The solution is below:

$ sbcl --dynamic-space-size 4gb

デフォルトでSBCLは1GBです。これは、CLMLをコンパイルするには少なすぎます。
Default SBCL memory size is 1gb . It's too small to compile CLML on SBCL.
2 コメント ラベル: ,

2016年1月12日火曜日 時刻: 1:19

ThinkPad X1 Carbon Gen3 + Fedora23


このエントリーをはてなブックマークに追加


こんな記事を書いたのに、またThinkPadを買ってしまった・・・。米沢産なので安心？（●｀ε´●）
実際、今回のThinkPadはほとんどトラブルは無いです。実はもう半年くらい使ってます。



ということで、X1 Carbon Gen3 をFedoraで使ってみた感想。

続きを読む >>>
0 コメント ラベル: , ,

2015年12月24日木曜日 時刻: 15:24

Hot の書き方（前編）


このエントリーをはてなブックマークに追加


OpenStack Advent Calendar 2015 ネタ。

ホントはHotでマルチノードOpenStack環境を作るところまで解説したかったのですが、HOTが巨大になりすぎて解説までかけませんでした。
続きはそのうちもう少し練り込んだHOTと合わせて追記して公開します。

ということで、今回はHeatテンプレート（通称HOT）の基本部分の解説をました。

それではみなさん、良いお年を。
0 コメント ラベル: ,

2015年11月14日土曜日 時刻: 21:37

中央区のいいプロバイダないですか


このエントリーをはてなブックマークに追加


ここ半年くらい回線が遅過ぎて困ってます。
平日の夜、土日祝日はこんなスピードしか出ません。
------ BNRスピードテスト (ダウンロード速度) ------
測定サイト： http://www.musen-lan.com/speed/ Ver5.6001
測定日時： 2015/11/14 21:25:02
回線/ISP/地域： 
--------------------------------------------------
1.NTTPC(WebARENA)1： 112.08Kbps (13.88KB/sec)
2.NTTPC(WebARENA)2： 143.83Kbps (17.97KB/sec)
推定転送速度： 143.83Kbps (17.97KB/sec)

------ BNRスピードテスト (ダウンロード速度) ------
測定サイト： http://www.musen-lan.com/speed/ Ver5.6001
測定日時： 2015/11/14 21:44:14
回線/ISP/地域： 
--------------------------------------------------
1.NTTPC(WebARENA)1： 112.26Kbps (14.02KB/sec)
2.NTTPC(WebARENA)2： 174.18Kbps (21.65KB/sec)
推定転送速度： 174.18Kbps (21.65KB/sec)

pingも頻繁に応答がなくなり、15年前に東北で引いてたケーブルTVがやってたネットより遅いし安定しません。
動画見れば再生に追いつかず頻繁にロード待ちになり、ネトゲは常時ラグラグでまともに遊べない。
迂闊に容量大きめのiOSアプリをアップデートすると、1,2時間は終わりません。

朝方は40MB/secくらい出ているので機器の故障ということはないとは思います。
実ははじめは機器の故障かと思って壊れてもいないA-Termを最新型に買い換えてしまいました。

もし東京の中央区・江東区でおすすめのプロバイダあれば教えて下さい。
今は光のマンションタイプです。
0 コメント ラベル:

時刻: 14:51

Open vSwitch ブリッジインターフェースのMACアドレスを固定する


このエントリーをはてなブックマークに追加


久々に更新です。ネタはあるのですが忙しくてなかなかアウトプットできてませんでした。

タイトルの通り、Open vSwitch で作成するブリッジのMACアドレスを固定化します。通常はOVSが適当に割り当てます。
インターフェース作成後に、以下の感じでデバイスと与えたいMACアドレスを指定します。

$ ovs-vsctl set bridge br-ex other-config:hwaddr=92:c3:28:4c:09:45

これはOpenStack上のインスタンスでいろいろ実験したい時に便利です。

通常OpenStackのNeutronの論理ポートは接続先の仮想マシンに割り当てたIPアドレスとMACアドレス以外の通信を許可しません。そのためブリッジデバイスやらをインスタンス上で作ってもそのままでは通信することができません。

そこで、このコマンドでMACを固定化した上で、Neutronの allowed-address-pairs という機能を使い以下のように、論理ポートに対して特定のIP/MACの組み合わせを許可する設定を入れ込むことで、かなり自由な通信を行うことが可能になります。


特定IP指定や、
$ neutron port-update $PORTID00 \
  --allowed-address-pairs type=dict list=true mac_address=fa:16:3e:0c:6d:89,ip_address=172.16.100.99


CIDR指定が可能です。
neutron port-update $PORTID00 \
  --allowed-address-pairs type=dict list=true mac_address=fa:16:3e:0c:6d:89,ip_address=172.16.100.0/24
0 コメント ラベル: ,

2014年12月25日木曜日 時刻: 21:57

OpenStack/CloudStack/Eucalyptusが教えてくれること


このエントリーをはてなブックマークに追加


今年最後のカレンダーネタです。
http://www.adventar.org/calendars/602
http://www.adventar.org/calendars/547


OpenStackやCloudStack、Eucalyptusといった、いわゆるクラウド基盤ソフトウェアを技術的に学習することで得られるものは多々あります。

ビジネス的には、自社のサービス基盤の効率化への活用だったり、SIビジネスを展開する材料にしたりできます。これらを習得する過程で、基礎的なLinux/Unixに関する技術も習得できるようになるため、エンジニアとって有用な教材であるといえます。さらに、構築したクラウド基盤上でどのようにシステムを構築し、運用するのか、という視点を持つことで、従来とは異なった、「クラウドネイティブ」なシステムデザインしていくきっかけにもなるとも思います。

このように様々なことが学習できる優秀な教材でもあるクラウド基盤ソフトウェアでありますが、中でも抑えておくべきポイントとして「抽象化」の考え方があります。


抽象化（ちゅうしょうか、英: Abstraction、独: Abstraktion）とは、思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は無視する方法である。反対に、ある要素を特に抜き出して、これを無視したり、切り捨てる意味もあり、この用法については捨象するという。従って、抽象と捨象は盾の両面といえる。
Wikipedia より

この観点でこちらに記事を書きました。
http://www.atmarkit.co.jp/ait/articles/1412/12/news016.html

その他の関連記事はこちら（宣伝）
http://www.atmarkit.co.jp/ait/subtop/features/kwd/openstack.html

OpenStackやEucalyptus、そしてCloudStackは多岐にわたるITインフラ（サーバー、ネットワーク、ストレージ）を抽象化し、より大量の計算リソースを素早く、簡単に扱えるようにしてくれます。

この流れは計算機の正当な進化に沿ったものであると言えます。計算機の世界は抽象化の層を積み重ね今日に至っており、OpenStackはその抽象化の層をまた1つ追加しようとしています。そして計算機のビジネスは抽象化の一番外側にいる層が現実世界との接点となり、ビジネスが発生するポイントになります。だからこそ、多くのITベンダーがOpenStackに注目し、こぞって開発に参画し、次世代のビジネスを主導権を取ろうと勝負しています。

クラウド基盤ソフトウェアを学習するとき、あるいはビジネスでの活用を検討するときには、この抽象化の意味を良く考える必要があります。一体、何のためにこの層が必要だったのか？この意味を考え、理解すれば自ずと、クラウド基盤ソフトウェアの正しい活用方法というものがわかるはずです。



来年から大学でクラウド基盤ソフトウェアに関する講義を持つ予定ですが、学生の皆様には表層的な「使い方」ではなく、こういった計算機の本質的な考え方を伝えていければと考えています。

それではまた来年もよろしくお願いします。
0 コメント ラベル:

2014年12月21日日曜日 時刻: 23:36

民明書房刊「クラウドの歴史」より


このエントリーをはてなブックマークに追加


今日は皆様に我が国における、クラウドの歴史について少し紹介させてください。

おぷすたや
あゝおぷすたや
おぷすたや

この句は、江戸時代中期に詠まれたものであると伝えられている。
信越地方の藩主の嫡男が、出島で見かけた”おぷすた”なるものに心を奪われ、思わず口にしてしまったものを偶然に通りかかった魚拓職人が記録し、現代に至る。

それまでは幕府の定めた”くらうど”しか使えなかった諸藩は、このおぷすたに大変な関心を示し、皆がこぞって利用するようになった。
幕府のくらうどは、”くらうど”といいながら、利用するには専門の職人が要求書を書面で送る必要があり、実際に使えるようになるまで、1周間以上待たねばならず、時には1ヶ月以上も待たされる時もあったという。

このような状況に不満が蓄積されていた背景もあり、おぷすたは国内で爆発的に普及した。
ただ利用するだけではなく、足りない機能をみんなで開発し、いかに自分の藩が素晴らしい貢献をするかを競い合い、いつしか貢献度に応じて藩の格付けまでされるようになった。
また、当時は通信手段も乏しく、隣の藩と連絡を取るために街道の整備が急速に進み、これが後の東海道となり、日ノ本の経済を活性化させる要因ともなっていく。

しかし、この状況を面白くないと思った幕府は、禁おぷすた令を発して、諸藩のおぷすたへの取り組みを禁止した。
後の世に言う、「仮想環境憐れみの令」である。

曰く

・仮想マシンはペットのように可愛がらねばならん。
・それにオープンソースなどサポートがなくて使えない
・もし何かあったら誰が保証するんだ

というのが幕府の言い分であった。
当然、多くの人がこの考え方に反発した。中でも強硬に反発したのが大塩平蜂郎であった。大塩は元幕府の役人であったが、幕府のくらうどに対する考え方が我慢できず出奔した経緯を持つ。大塩は幕府に対して、

「1時間後に仮想環境を100台用意しろ」
「俺が寝ているときに負荷が上がったら、勝手に仮想環境を増強しろ」

などと無理難題を要求した。当然これに対応できない幕府は要求を無視するが、これに怒った大塩によって引き起こされたのが有名な「大塩平蜂郎の乱」であるのはあまりにも有名である。

この後も、幕府はなんとかおぷすたの勢力を抑えこもうとするが、一度広がったおぷすたの考え方は市場に浸透し、既に国内から一掃するのは不可能であった。幕府内にも反発する勢力が日に日に増大し、最後には幕府が折れることで、一連の騒動は幕を閉じる。

そしてその後、誰もが自由に使えるおぷすたは大いに広がり、江戸後期には様々なコンテンツビジネスがおぷすた上で展開され、江戸の住民を多いに楽しませたという。














ちなみに全部フィクションであることは言うまでもない（ http://www.adventar.org/calendars/602 )
0 コメント ラベル:
登録: 投稿 (Atom)