構成情報は、魔法のExcelで管理?

Kompira cloudチームのUI/UX担当、福原です。
WEBサービスのUXと言うと、画面を操作したときの体験だと思っている方も多いでしょう。
でもそれはUXのほんの一部にすぎません。UXとは製品の情報に接したときから使用中、使用後全てを含む包括的な概念になります。 様々な立場で語られることの多いUXですが、実はISOでその概念がちゃんと定義されているのです。

ISO9241-210によれば、UXとは
「製品、システム又はサービスの使用及び/又は使用を想定したことにより生じる個人の知覚と反応」
とされています。

なんだか小難しい言い回しで結局なに?と思いますよね。

つまり、Kompira cloudのUXという観点で考えると、これを使用するユーザが手作業の運用に疲れ果てていて、これをなんとかしたい。検索してみたらKompira cloudの情報を見つけた。 なるほどこんなことができるのかと期待をし、上司を説得して製品を導入し、期待する効果を得ることができ、満足して使用を継続する。(ポジティブに考えすぎですが) この一連の流れ全てがUXだということになります。

ということで、UXデザイナーとして営業に同行し、現場の皆様のお話を聞く機会も多いのですが、
とにかく皆さん本当に大変ですね。

f:id:fukuharax:20181025165316p:plain

IT業界といえど、実は泥臭い手作業が山のように積まれている上に、ミスは許されないという状態。 なかでも、構成情報に関しては管理を自動化されているとおっしゃる企業様には今のところ一社もお目にかかれていません。
「構成管理はどのようにされていますか?」
この質問は数十社にさせて頂きました。
そうすると、必ずと言っていいほど少し苦笑いして、

「実は手作業なんですよね。常に最新かって?いえいえ、そんなことはムリです」

このようにおっしゃいます。

自社に置き換えて考えても、手作業の管理で常に最新状態に保つというのは100%無理と言っても過言ではないと思います。

f:id:fukuharax:20181025165820p:plain

「構成情報?魔法のExcelで管理してますよ」
とユーモアたっぷりにお答えいただいた企業様もいらっしゃいました。

Excelって確かに便利なんです。 とりあえず何か管理するならこんな便利なツールはありません。
ただ、そのデータを確認する人が数人~数十人になったり、各々が更新したりということになると話は別ですし、
何と言っても構成が変わるたびに更新する労力は大変なものです。
実際にお会いしてお話を聞くと、早く皆さんを楽にしてあげたいなあ~と切に思います。
もちろん、現場の課題は構成管理だけではなく、多岐に渡るのでしょう。

運用の担当者の課題を解決するためには、何が必要なんだろう?

UI/UX担当として、日々そんな探求心を元に皆様のお話をお聞きしています。

Azure Container Instancesを利用し、Azure上でよくある構成をセキュアにする

クラウドチームの関戸です。 Azure Container Instancesが9/25にGAしました 。 GAの告知を見ている中で、Virtual Networkへの統合機能がPreviewされていることを知ったため、本記事ではAzure Container InstancesがVirtual Networkに統合されたことにより、Azure上のインフラセットをこれまでよりセキュアする案を思いついたため、その案の検証をしてみます。

さて、Azure上に下図のように、

よくある構成
よくある構成

  • Appサーバ
  • 踏み台サーバ

という構成を組むことは比較的多いのではないでしょうか。 Appサーバは80ポートを通してのみアクセスが可能で、解放されているポートもNetworkSecurityGroupで絞られています。 現実的には、ここにLoadBalancerなどを追加して負荷分散したりしますが、以下では話を単純にするためAppサーバと踏み台サーバに登場人物を絞ります。

このとき、踏み台として利用するサーバに対して、

  • 使うタイミングは少ないのに用意しておかなければならない
  • 使う度に踏み台を起動/終了すると待たされるのが嫌
  • 起動し続けるとして、セキュアな環境構築やID管理が手間
  • 踏み台に対する利用料金が意外とかかる

と様々な不満がありました。

踏み台用のVMを普段は落としておき、使うときだけ起動する、という運用であれば、Appサーバに対する不正なログインの懸念はかなり下がります。 ただし、さきほど挙げたように、このような運用には踏み台用VMの起動のオーバヘッドであったり、不満があった訳です。 結果的に、踏み台用VMは常時起動し続けることになったりし、せっかくのセキュアな構成なのに... と更に不満が出たりしていました。 Azure Container InstancesがVirtual Networkに統合されることによって、上記のような従来型の構成に対する不満をかなり解消できる方法がうまいことAzure上で構成可能になりました。

まず、Azure Container Instancesの(本記事における)利点は起動が高速なこと、に尽きます。 コマンド発行から数秒程度で起動します。

※現状、Virtual Networkに初回デプロイするときは、そこそこ時間がかかってしまってます(10分弱)
※デプロイ済であれば、通常通り数秒程度で起動します

Azure Container Instancesで起動するコンテナを踏み台として利用することで、Virtual Machineの起動/終了に伴う待ち時間をほぼ無くすことができます。 また、Virtual Machineのカスタマイズ(起動後にやったり、カスタムVM Imageを用意したり)は結構手間で動作確認も大変でしたが、Dockerfileの整備をすれば良くなります。 コンテナのため、ローカルでの動作確認も手軽にできます。

さて、Azure Container Instancesを踏み台として利用する場合、下図のような構成になります。

Azure Container Instancesを踏み台利用する構成
Azure Container Instancesを踏み台利用する構成

大きな違いは、踏み台関連のリソースが削除されていることと、Azure Container Instancesが追加されていることです。 他のリソースに差はないため、本筋のサービスに影響を与えずに適用可能です。

図中で、システム管理者はコンテナに対してコンテナにTTYをアタッチすると記載していますが、 こちらのドキュメントにある通り 、現状ではVirtual Networkに接続するコンテナは、同時にPublic IPを持てないためです。

Container groups deployed to a virtual network do not currently support public IP addresses or DNS name labels.

currently と書かれているため、今後に期待ですね。 そのため現状では、sshdを実行し接続することはできませんから、 docker exec 相当の az container exec を使って、リモートシェルを開くことにします。

ではこの構成での、踏み台からAppサーバへのssh接続を、 Azure CLI v2 を利用してやってみます。 サンプルリポジトリ にお試し用のスクリプトをまとめてありますので、試してみたい方はどうぞ。 なお、Azure CLI v2のバージョンは2.0.49です。

#!/bin/bash

git clone https://github.com/fixpoint/azure-container-instances-as-a-bastion
cd azure-container-instances-as-a-bastion

# お試し用のリソースを作成
# Azure Container Instancesはまだいくつかのリージョンでしか利用できないため、westusに作成する
az group create --name aci --location westus
az group deployment create --resource-group aci --template-file ./azure.template.json

# deploymentのoutputsから、Virtual Networkのリソース名を取る
vnet_name="$(az group deployment show --resource-group aci --name azure.template --output tsv --query properties.outputs.vnetName.value)"

# 踏み台用コンテナグループを作成します
# 今回は公式イメージのalpineを利用します、利用中には常駐させるため --command-line でsleepをループさせています
az container create \
    --resource-group aci \
    --name bastion \
    --image library/alpine:3.7 \
    --cpu 1 \
    --memory 0.5 \
    --vnet-name "${vnet_name}" \
    --vnet-address-prefix "10.0.0.0/16" \
    --subnet bastion-subnet \
    --subnet-address-prefix "10.0.1.0/24" \
    --command-line "/bin/sh -c 'while true; do sleep 1s; done'" \
    --restart-policy Never

# 起動したコンテナでシェルを起動します
# 現状、Windowsではaz container execコマンドはうまく動きませんので、LinuxかMacを使ってください
az container exec \
    --resource-group aci \
    --name bastion \
    --exec-command "/bin/sh"

# ここから、踏み台上での操作
# sshにalpineの環境を整えます
apk add --no-cache openssh-client
mkdir ~/.ssh
# サンプルリポジトリのprivate.pemの内容をコピーして持っていってください
vi ~/.ssh/id_rsa
chmod 0400 ~/.ssh/id_rsa

# Appサーバにsshします
# AppサーバのPrivate IPを、Azureポータルから確認しておいてください
# ここでは、10.0.0.4と仮定しています
ssh azure-user@10.0.0.4

# これでAppサーバに接続できました

# ここまで、踏み台上での操作

# 使い終わったため、コンテナを終了させる
az container stop \
    --resource-group aci \
    --name bastion

# お試し用のリソースを削除
# 現在はAzure Container InstancesをVNETに繋げた場合、削除するために一手間必要になります
# https://docs.microsoft.com/ja-jp/azure/container-instances/container-instances-vnet#clean-up-resources
network_profile_id=$(az network profile list --resource-group aci --query [0].id --output tsv)
az network profile delete --id "${network_profile_id}" -y
sal_id=$(az network vnet subnet show --resource-group aci --vnet-name "${vnet_name}" --name bastion-subnet --query id --output tsv)/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default
az resource delete --ids "${sal_id}" --api-version 2018-07-01
az network vnet subnet update --resource-group aci --vnet-name "${vnet_name}" --name bastion-subnet --remove delegations 0
az group delete --name aci --yes

※手元のazがバージョン古い場合は、 docker run --rm -it -v $HOME/.azure:/root/.azure microsoft/azure-cli:latest を利用すると便利です
※Docker Public Imageを起動する場合、例えば docker run nginx:alpine としていた場合は、 az container create --image library/nginx:alpine と、 library/ を付与する必要がありました

他にも色々と利用例は考えられますが、とにかく、Azure Container InstancesからVirtual Networkに接続できるだけで、とても夢が広がるというお話は理解していただけたかと思います。 今後、Virtual NetworkにデプロイしたコンテナにPublic IPを同時に持たせることができれば、よりカジュアルにセキュアにできるのではないでしょうか。

Azure Container Instancesの日本でのGAは、2018年の終わり頃になる予定です。 待ち通しいですね。

攻めの運用、責められない運用

フィックスポイント三角です。

気が付いたら2018年もあと2か月で終わろうとしています。 世の中変化も激しいし、あっという間に過ぎていってしまいますね。

ここ2,3年で採用環境も激変しているようで、 募集しても応募自体がない、応募があっても求める要綱に合致しないので採用に至らないという声をいたるところで聞きます。

経済産業省の調査によると、IT人材は現在でも17.1万人不足しており、2020年には36.9万人不足するそうです。 どうりで、採用が難しいはずですね。

そして、そんな大変な思いをして採用をしても、運用の現場に配属されると、すぐに辞めてしまう人が多いようです! 御社はいかがですか?

運用現場では、常に人が足りてない状態が慢性化しているところが沢山あります。

一方で、ユーザーからは、うちの運用は受け身で困る。もっと積極的に提案して欲しいのに、なんて言う事も聞かれます。

人がいないのにそんなことできるかー! という運用現場のマネージャーさんの声が聞こえてきそうですね。

なんで折角採用した人が辞めちゃうんでしょうか?

・配属されたときにはやる気をもっていても、やるべき事が決まっておりそれ以外の事は全くできない。

・過去の経緯の積み重ねを知らないと対応できず、自分の技術力を発揮できる場がない。

・何らかの活動をして上手くいっても当たり前、失敗するととても怒られる環境。

など、やる気をそぐ要因が次から次へと襲ってくるのが運用の現場です。

そのような環境に慣れてくると、次第に、依頼されないと動かない、依頼されても動きたくないようになってきて ユーザーからは頼りにならないと思われ、やる気のある人は別の職場に行ってしまうという状況になってるのではないでしょうか?

こう言う運用現場の守りのカルチャーを、プロフェッショナルとして、ユーザーにこちらから働き掛け、 システムの品質を高め、効率化を進めていく攻めの運用ができるように変えたい。

やる気のあるエンジニアが働きがいがあり、ユーザーも頼りになる運用チームにしたい。

そこに役に立つサービスを作りたい、そのような思いでKompira cloudをリリースしました。

こんな話をある人にしたところ、運用現場の人は、攻めの運用をしたいと言うより、 責められない運用をしたいと言う気持ちが強いんでは無いの?と言われましたが、、

あなたは攻めの運用か責められない運用かどちらの運用が良いですか?

RPMパッケージのリリースバージョンを取得できるようになりました 他

Kompira cloudについて、以下の内容を含むアップデートを行いました。

RPM系アプリケーション情報を取得する際、リリースバージョンを取得できるようになりました

これまでRPM系パッケージ情報は openssl 1.0.2k のように、バージョンまでを取得していましたが、今回のアップデートによりリリースバージョンまで取得するように変更しました。

取得するパッケージバージョン情報例
変更前 openssl 1.0.2k
変更後 openssl 1.0.2k-12.el7

この変更は、本日以降スキャンしたスナップショットに適用されます。

容量の表示形式を改善しました

メモリ容量やストレージ容量の表示を、これまではKB, MB, GB単位で表示していましたが、KiB, MiB, GiB単位で表示されるようにしました。

メモリ容量表示例
変更前 16.38 GB(17179869 kB)
変更後 16.00 GB(16777216 kB)

この変更は、本日以降スキャンしたスナップショットに適用されます。

その他バグ修正

  • Linux, Windowsからの構成情報取得時、タイムアウトにより情報取得に失敗する問題を改善しました。
  • 削除したネットワークに残っていたノードが、スペース全体で使用しているノードの個数としてカウントされてしまう問題を修正しました。
  • プロフィール情報の変更が即座に反映されない問題を修正しました。

また、あわせて ksocket についても、以下の内容を含むアップデートを行いました。

  • ksocketバージョン
    • ksocket: 1.4.3
    • ksoperations-networks: 1.5.2
  • 一部のAzure VNET上でスキャンが失敗する問題を修正しました。

最新の ksocket はこちらよりダウンロードすることができます。

スキャンするために必要な設定

Kompira cloud Sonarでは、ksocket という連携プログラムを使用することにより、オンプレ環境やクラウド (AWS, Azure) 上の構成情報を収集することができます。この記事では、ksocketによって情報収集される機器側に必要な設定、確認方法について解説します。

スキャン対象の各機器に必要な設定

UNIX/Linux

UNIX/Linuxをスキャンする場合、SSHでのアクセスを有効にする必要があります。

SSHでの接続アカウント情報は、ksocketをインストールしたサーバの /opt/fixpoint/ksocket/etc/ksocket/credentials/ssh 以下にymlファイルを作成することで指定できます。 詳しくは ksocketドキュメント をご覧ください。

Windows

Windowsをスキャンする場合、WinRMでのアクセスを有効にする必要があります。 また、WinRMでのログイン後に詳細情報を取得するため、WMIリソースへのアクセス権限を許可する必要があります。 WinRM 接続の有効化の方法 - Kompira cloud Blog に設定方法を詳しく記載しているので、ご確認ください。

WinRMでの接続アカウント情報は、ksocketをインストールしたサーバの /opt/fixpoint/ksocket/etc/ksocket/credentials/winrm 以下にymlファイルを作成することで指定できます。

ネットワーク機器 (ルータ・スイッチなど)

ネットワーク機器からは、SNMP経由で情報を取得します。 ksocketからSNMP接続ができているか、また必要なMIB情報が取得できているかは以下のコマンドで確認することができます。

Linuxから確認する場合

  • SNMP Agentが動作しているかの確認
(ksocket server) $ snmpget -v 2c -c public 172.16.0.1 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: BUFFALO BS-G3024MR

上記例のような出力が得られない場合やエラーが表示される場合は、「機器側がSNMPに応答しないようになっている」「コミュニティ名が設定と異なっている」などの原因が考えられます。

  • 必要なMIBが取得できるかの確認
(ksocket server) $ snmpbulkwalk -v 2c -c public 172.16.0.1 1.3.6.1.2.1.4.21.1.7
... Next HOP が設定されていれば出力される
(ksocket server) $ snmpbulkwalk -v 2c -c public 172.16.0.1 1.3.6.1.2.1.4.22.1.3
... ARP cache があれば出力される

SNMP Agentは動作している状態で、特定のMIBは取得できないような場合は、設定で制限されている可能性があります。

Windowsから確認する場合

  • SNMP Agentが動作しているかの確認
(PowerShellコンソールを起動)
> $snmp = new-object -ComObject olePrn.OleSNMP
> $snmp.open("172.16.0.1", "public", 2, 1000)
> $snmp.Get(".1.3.6.1.2.1.1.1.0")
EPSONCA929E
  • 必要なMIBが取得できるかの確認
(PowerShellコンソールを起動)
> $snmp = new-object -ComObject olePrn.OleSNMP
> $snmp.open("172.16.0.1", "public", 2, 1000)
> $nexthops = $snmp.GetTree(".1.3.6.1.2.1.4.21.1.7")
> $nexthops[(0..($nexthops.count/2) | ForEach-Object { ,@(0, $_) })]
... Next HOPが設定されていれば出力される

> $arps = $snmp.GetTree(".1.3.6.1.2.1.4.22.1.3")
> $arps[(0..($arps.count/2) | ForEach-Object { ,@(0, $_) })]
... ARP cache があれば出力される

SNMPでの接続アカウント情報は、ksocketをインストールしたサーバの /opt/fixpoint/ksocket/etc/ksocket/credentials/snmp 以下にymlファイルを作成することで指定できます。

スキャン対象機器までの経路上に存在するネットワーク機器の設定について

ksocketは、SNMP接続ができる機器の上記のMIBからNext HOP, ARP cache情報を取得し、それらのIPアドレスに対して情報取得を行う、という処理を繰り返し行います。
例えばksocketとスキャンさせたいWindows機の間に、ネットワーク構成上あるルータが存在したとしましょう。
この時、ksocketはWindows機に対するWinRM接続だけでなく、ルータに対するSNMP接続ができる必要があります。
もしルータをSNMP応答可能であるように設定できない場合は、スキャンオプションの「追加起点アドレス」にWindows機のIPアドレスを入力することで、スキャンさせることができます。

Kompira cloud Sonarのノードとは何か?

この記事ではKompira cloud Sonar におけるノードとは何かをご紹介します。

Kompira cloud Sonar でネットワークのスキャンを行うと、各実行ごとに1つのスナップショットが作成されます。 スナップショットはスキャンした時点のネットワーク・各ホストの状態 (例えば アドレス情報やアドレスに紐づいたホストの持つパッケージ等の各情報) が含まれています。

しかしこのままでは各スナップショットは紐づいておらず、定期的にスキャンを行っていてもネットワークやホストがどのように変遷してきたのかを辿ることができません。 Kompira cloud Sonar ではこれを解決し、ネットワークやホストを追跡し続けるためにノード集積という機能を持っています。

このノードを使い、ネットワーク内の各機器が今どんな状態なのかをすぐに検索・チェックすることができます。 (ノード検索機能については ノードの検索 - Kompira cloud Blog をご覧ください。)

f:id:c255:20181010174435p:plain

f:id:c255:20181010175332p:plain

アドレス・ノードの同一判定

スキャンを跨ぎノードを追跡するため、複数アドレスが単一のノードを指しているのかを調べる必要があります。 これらアドレスが指すノードの同一性判定を、Kompira cloud Sonar では下記のような手法で判定を行っています。 *1

機器例 判定方法
Windows WinRM を用いて取得した Windows シリアル番号の比較
Linux ssh でテンポラリ領域へ乱数ファイル作成・その比較
ネットワーク機器 SNMP を用いて取得した 機器シリアル番号の比較

ノード集積

最新のスナップショットが正常に取得された後に、ノード集積という機能によりアドレスとノードを関連付けます。

  • 最新スナップショット中に既にノードになっているアドレスは存在するか?
    → 存在するならそのノードにアドレスを関連付ける

  • ノードになっていないアドレスは存在するか?
    → 存在するなら新たにノードを作り、それにアドレスを関連付ける

そして、関連付けられたアドレスを元に、ノードパッケージ等の内部情報を更新します。

ノード集積によって関連付けられたスナップショットは『関連するスナップショット』ボタンから見ることができます。

f:id:c255:20181010175724p:plain

*1:判定手法は一例であり、実際には複数の情報を用いた比較等も行っています。 また、今後検出精度向上のため変更する可能性があります。