ConoHa の記事一覧

こんにちは。GMOインターネットの斉藤です。今回はLinuxサーバー管理のときに便利に使えるmoshとそれをConoHaで使うコツをご紹介します。 はじめに ConoHaなどのVPSはもちろん、リモートでLinuxサーバーを管理するときによく使われるのはsshではないかと思います。私ももちろんsshは使うのですが、自分で頻繁に使うサーバーについてはmoshを使っています。 MoshはThe mobile shellの略で、sshの置き換えを目指して開発されているソフトウェアで、sshの機能に加えてさまざまな便利機能が追加されています。 Mosh: the mobile shellhttps://mosh.org/ 私はとくにコネクションの自動再接続が気に入って使っています。 moshには接続が切れても自動で再接続してくれる機能があります。ラップトップを閉じてスリープにして、再度開いたときにすでにリモートサーバーへ繋がっている状態になるのです。この間に場所を移動してIPアドレスが変わっても問題ありません。 今でこそステイホームな状況ではありますが、それでもカフェとかでちょっとサーバーのログを見たいこともありますからね（ありますよね？） 。そんなときに非常に有用です。 私はこのmoshの再接続機能とtmuxのセッション管理を併せて使っていて、場所は環境に依存せず、またラップトップの再起動などでも作業環境が保存されるようにしています。 ほかにも優れたローカルエコーはWi-Fiの電波が微妙なところでイライラせずにすみますし、sshと認証メソッドを共有しているので安心して使えるところもメリットでしょうか。 インストールも簡単です。多くのプラットフォームでコマンド1つ叩くだけです。このあたりも素晴らしいですね！ https://mosh.org/#getting ConoHaで安全にmoshを使う さてConoHaには「接続許可ポート」という機能があって、コントロールパネルからVPSへのポート制限することができます。 この設定を「すべて許可」で運用しても問題はありませんが、一般的には使うポートだけを許可するのが良いとされています。サーバー上で意図しないプログラムが動いていた場合などでも、外部からの通信を遮断できるからです。 moshの実際の挙動は、まずsshでサーバーに接続を行い、認証が完了した後にサーバー上でmosh-serverと言うコマンドが実行されてクライアントとの接続が確立します。なので、moshは単体では使えません。必ずsshとセットで使うことになります。 sshは22/tcpを使いますが、moshはそれに加えて60000-61000/udpを使います。上記のスクリーンショットのように、コントロールパネルからsshのポートだけを許可しても、udpを使うmoshは使うことができません。とは言っても「すべて許可」での運用は避けたいものです。 ConoHaにはセキュリティグループと言う機能があって、接続元のIPアドレスやポート番号を使ってパケットフィルタリングを行えます。前述の「接続許可ポート」もこのセキュリティグループを使って実装されています。なので、moshを使うにはセキュリティグループを使って60000-61000/udpを許可してあげればよいのです。 本来セキュリティグループはConoHa APIを使って作業するのですが、結構大変です。なのでここでは拙作のconoha-netというCLIツールを使ってみましょう。簡単に操作できます。 conoha-netやセキュリティグループの仕組みは上の記事で解説しているので興味のある方はご覧ください。ここでは手順のみをご紹介します。 ①conoha-netのインストール これはLinux向けですが、OSXやWindowsのインストール方法もREADME.mdにあります。 curl -sL https://github.com/hironobu-s/conoha-net/releases/download/current/conoha-net-linux.amd64.gz | zcat > conoha-net && chmod +x ./conoha-net ②環境変数の設定 APIの設定については下記URLを参考にしてください。 https://github.com/hironobu-s/conoha-net#1-%E8%AA%8D%E8%A8%BCexport OS_USERNAME="gncu*****"export OS_PASSWORD="********"export OS_AUTH_URL="https://identity.tyo1.conoha.io/v2.0"export OS_TENANT_ID="*******************************" ③VPS一覧を見てみる ./conoha-net listNameTag IPv4 IPv6 SecurityGroupsmy-vps 150.95.***.** 2400:8500:1302:829:***:***:***:*** gncs-ipv6-all, gncs-ipv4-all, default ④moshを通すためのルールを格納するセキュリティグループ（permit-mosh）を作る ./conoha-net create-group permit-mosh ⑤60000-61000/udpを許可するルールをpermit-moshに追加する ./conoha-net create-rule -p 60000-61000 -P udp permit-mosh ⑥permit-moshをVPS(my-vps)にアタッチする ./conoha-net attach -n my-vps permit-mosh ⑦正しく設定されたか確認 permit-moshが追加されていればOK。 ./conoha-net listNameT IPv4 IPv6 SecurityGroupsmy-vps 150.95.***.** 2400:8500:1302:829:***:***:***:*** gncs-ipv6-all, permit-mosh, gncs-ipv4-all, default これでmoshがつながるはずです。 mosh 150.95.***.** それではまた次回、お目にかかりましょう。

こんにちは。GMOインターネットの筬島(@yosajima)です。去る10月20日(土)、ISUCON8の本選が開催されました。ISUCONはLINE株式会社様が主催されているWebアプリケーションのチューニングコンテストで、毎年多くの方が参加する大人気のイベントです。予選はオンラインで行われ、ISUCON8には527チーム、1394名の方がエントリされました。こちらのイベントのサーバ環境にConoHaをご利用いただくということで、弊社のエンジニアも運営に参加しておりました。そして、インフラの準備と運用を担当した貴重な経験を共有させていただこうと思い、インフラの計画→準備→コンテスト当日と時系列に沿った記事にまとめました。 はじめに 今回、参加者の方々からの「ベンチの実行で待たなかった」というご反応を多くいただくことができ、大変嬉しく感じました。ISUCONでは、参加者ごとにチューニング対象のWebアプリケーションサーバが配布される他に、運営側の設備としてアプリケーションに負荷をかけてスコアを出力するベンチサーバが用意されます。 参加者が専用のコントロールパネルからベンチの実行をリクエストすると、ベンチサーバが参加者のアプリケーションに対してベンチマークを実行します。このベンチサーバが全参加者で共有されている場合、参加者からのリクエストはキューイングされ、順次ベンチマークが実行されることになります。ISUCON8では、このベンチマーク実行の待ち時間が大変短かったということで、ご好評を頂けたようです。 たしかに、チューニングコンテストのようなトライアンドエラーを繰り返す場面では、ベンチを素早く実行できることがメリットにつながるかと思います。しかし、このご評価は大変光栄である反面、実は心苦しく感じている部分もあります。というのも、この「ベンチの待ち時間が短い構成」になったのは、ConoHaのエンジニアがISUCONの規模にビビった結果だからです。 本ブログ記事では、このサーバ構成になった経緯を通して、私たちがどれくらいビビっていたのかについて記載したいと思います。 準備 ことのはじまりは、LINE様から3月頃「ConoHaのインフラをISUCONに提供しませんか。」というご提案を頂いたことでした。 弊社としても、あの有名なISUCONに使ってもらえることで、認知度の向上とサーバの使い勝手を実感してもらうチャンスを得られるのでは、という思いがあり、お受けしました。 まずキックオフミーティングが3月5日(月）に開催され、LINE様/DeNA様/カヤック様/弊社が参加しました。LINE様よりまずはISUCONの概要説明をして頂き、毎年パブリッククラウドを提供している会社より、サーバー提供を受けている旨を認識しました。 １．ISUCONの過去の参加推移 【参考】ISUCON参加者数推移ISUCON1　47ISUCON2　68ISUCON3　210 （予選）ISUCON4　507（予選）ISUCON5　761（予選）ISUCON6　887（予選）ISUCON7　1144（予選） ２．ISUCON7のサーバー構成 CPU: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 10コア * 2ソケット = 計20コアMEM: 256GB■ストレージVM毎に20GB(SSD)■ネットワーク物理ネットワークは10Gbps接続チーム内のVM間の帯域は1Gbpsを確保物理は本戦で15台、予選で12台VM数は予選時1400本選では各チーム内のVM間通信は物理ホスト内で閉じるように調整いただいたので、ショートパケットが多く、VM間で1Gbps確保できてれば大丈夫だった。 ３．参加チーム数と1人参加の可否についての決定（仮） このキックオフミーティングの中では、「参加目標人数（参加見込み数）」と「1名参加が可能な事」が決定しました。参加人数上限に関しては後日Slackにて調整後に確定しました。（この段階で500~600チームを上限とすることが大体であるが決まっていた。） また、過去のISUCONの傾向などをカヤック様とDeNA様にヒアリングする機会も得られました。利用言語によって、スケールアップ構成が有利になったり、単体での高速化が有利になる等、非常に有益な情報を得ることができました。 過去の傾向を元に2パターンのVM群を、まずはDeNA様とカヤック様にお渡しして問題を作成をして頂き、最適な構成を選んで頂く事となりました。 1GBプラン(2Core /1GB ) x 32GBプラン(3Core /2GB ) x 2 ４．物理サーバーの早急な手配を実施 この段階では500~600チームが参加する為の物理サーバーが足りない状況であったため、早急に発注処理を進めました。今回のISUCON8用に用意したサーバー台数とスペックは以下の通りです。 DELL EMC PowerEdge R430 * 51台(予備機含む)CPU: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz 10コア * 2ソケット = 計20コア(40Thread)MEM: 128GBSSD: 1TB * 6 (RAID1+0) 上記サーバーを使って、弊社筬島と相澤が過去問での検証等を進めてくれることになりました。 過去問で動作確認（筬島） 最大のビビりポイントは予選問題の規模でした。 チューニングコンテストという性質上、1500のVMが最大の負荷をかけるために設定更新されていくはずです。 公開されていたISUCON7の予選結果を参照し、すべてのチームが最大限の負荷をかけることはないとは予想しつつも、インフラとして高い安定性を実現するためには極限のケースも想定する必要があると考えました。まずはISUCON予選の破壊力を見定める必要がありました。 ISUCON専用ホストサーバの購入が完了して使用可能になったタイミングで、ISUCON7の予選問題を使用して負荷試験を行うことにしました。ISUCON7予選に参加された方々が公開されていた設定内容を参考にさせていただき、ISUCON7予選の上位ランカーと同程度のスコアを出せる状態になったVMをホストサーバに詰め込んで負荷試験を実施しました。 想定以上の通信パケット量に、正直ビビりました。ホストサーバ1台でこの量。。。もし全ホストで同時にこれが起こったら。。。 実際の予選問題が同様のトラフィックを発生させるものであるとは限りませんが、起こる可能性があるとわかった以上、事前に手を打たないわけにはいかないと考えました。 そして、ホストサーバ上でのVMの配置構成を変更することにしました。 変更前 共有のベンチサーバのプールを用意すると仮定して負荷試験。 変更後 当初、ベンチサーバとWebアプリケーションのホストサーバをわけて配置することを想定していましたが、チーム毎に用意したベンチサーバを同一ホストサーバに配置して、ホスト内で通信を閉じることにしました。 結果、ホストサーバから外部に送受信するパケット量を無事に減らすことができました（目盛りの桁が減っています）。 その日、ベンチサーバは全チームで共有するのではなく、チームごとに作成させてもらう方向でお願いすることを、ConoHaインフラエンジニアたちは心に強く誓いました。 合宿 8月上旬、ISUCON運営者合宿に参加させていただきました。 問題を作成されるカヤックの皆様とDeNAの皆様と直接お会いできる場ということで、負荷試験の結果とVMの配置構成について共有する絶好の場と思い、意気込んで行きました。 結果、皆々様、熱心に相談に乗ってくださり、チームごとの影響範囲の分離などのご指摘もいただいたうえで、下図の構成で決定いたしました。 こうして、「ベンチの待ち時間が短い構成」が誕生しました。つまり、各チームがほぼ待ち時間なしでベンチを実行できる構成は、ConoHaのインフラエンジニアがトラフィック量にビビって提案した構成の副産物なのでした。 また、各チームにベンチサーバを用意することでデプロイするVMはチームごとに4つになり、トータルで2108VMに増加し、各VMに接続するネットワークの構成もじゃっかん複雑になりました。 今度はVMのデプロイにビビったConoHaインフラエンジニアは、ツールの作成に精を出し始めました。 （こけるパイプラインにつのる焦り。。。） 予選の準備 予選問題での負荷試験 9月上旬、先日の負荷試験でビビっていたConoHaインフラエンジニアは、予選問題の作成担当であるDeNA様にお願いして「初期状態」と「チューニング済」の問題をご提供頂き、負荷試験を実施しました。 そしてあえなく、チューニング済のVMの負荷試験で新しい問題が発生しました。負荷試験の結果、最適化されたISUCON8の予選問題は、トラフィック量はそれほど出ずDiskへの負荷も軽微でありながら、CPUに高負荷がかかるものであることがわかりました。 発生した事象は、1ホストあたり3チームまでしか同時にベンチを実行できず、4チーム同時に実行すると、スコアが想定通りに出ないというものでした。 ConoHaインフラエンジニアは少し余裕をもって用意していたホストサーバをフル動員し、それでもどうにもならず、DeNA様に状況のご報告とご相談をしました。そして協議の結果、ホストあたり同時にベンチを実行できるチーム数を3に制限し、4チーム目はキューイングするという仕組みをDeNA様に実装いただくことになりました。 DeNA様、その節はご協力をいただきありがとうございました。 予選問題のデプロイ いよいよビビっていた2108VMのデプロイのタイミングがやってきました。 結果的には、事前に準備していたツールとConoHaのOpenStackベース基盤の連携で、心配していたほどの問題は発生しませんでした。作成したのはPythonでAnsibleとSQLiteをくっつけたコマンドラインツールで、チーム単位でVMを作成してネットワークを接続し、IPアドレスやユーザパスワードなどのOS内の設定や、VM間の疎通確認をするというものでした。 デプロイしたVMの情報をCSVにダンプしたり、逆にVM情報をCSVからインポートしてデプロイに使用したりできるのですが、思い返すとエクセルを使ったCSVの集計や加工が一番役立ったように感じます。 エクセルは偉大な発明であると、改めて感じました。デプロイ処理は比較的順調に進み、なんとか1日かけて完了しました。 予選当日 予選の運営 予選は9月15日(土)と16日(日)の二日間行われました。 両日ともそれぞれGMOインターネットから6名ずつLINE様へ伺い、専用の部屋をお借りして待機していました。 サーバ故障やスイッチ故障などの万が一の事態にできるだけスムーズに対応できるよう、サーバ部門やネットワーク部門など、複数の部署からエンジニアを動員しました。また、別動隊として弊社のオフィスにもサーバエンジニアが待機していました。とにかく動員をかけました。 インフラ起因での大規模な競技用VMの異常を検知するため、ホストサーバ用とは別にZabbix 4.0を構築して、Discordに通知して見張っていました。 正直、この二日間は心底ビビっていました。もしCPUの処理が追いつかない状態が続出したら。。。もしホストサーバが故障でもしたら。。。 当日は各チーム8時間という時間制限でチューニングに挑戦します。時間が経過するにつれてスコアがアップしていき、そのたびに恐る恐るホストサーバの負荷状況をチェックしました。 予選二日目のあるホスト。開始時間からだんだん上がっていく負荷 下図は予選をトップで通過したチームの負荷のグラフです。時間経過とともにCPU負荷が上昇していきます。 最初1つのVMで上がっていた負荷が、途中から、利用可能なすべてのVMで上昇していきます。 運営で用意していたベンチサーバも、アプリケーションのチューニングが進むにつれて終盤が大きく上がっています。 やがてすべての競技時間が終了。当日は、18時を過ぎて下がる負荷を見つつ、サーバに「頑張ったね。。。」と声をかけました。 結果的に想定をこえる負荷状況は発生せず、大きなトラブルが発生することもなく予選両日を乗り切ることができました。みるみる上がっていっていた参加者の方々のスコアを思うと、時間制限に助けられたのだと思います。 感想戦 予選終了後、感想戦ということで、予選で使用したVMを一週間延長してご使用いただくことになりました。 「もう少し時間をかけてチャレンジしたい！」と感じられていた参加者の方々が多くいらしていたこともあり、引き続き楽しんで頂けて、インフラを用意した身としても大変嬉しく感じました。 本選の準備 本選問題での負荷試験 予選に参加した527チームのうち、30チームだけが本選へ進むことだできます。サーバインフラを用意する身としては、チーム数が大きく減ったことで心理的には余裕が生まれていました。 ホストサーバも40台以上利用可能な状態であり、チームごとに1ホスト割り当てることができました。しかし、二度経験した負荷試験での衝撃が安心することを許しませんでした。本選問題の作成担当であるカヤック様にお願いをして事前に本選問題を頂き、1ホストの上で1チームだけの負荷試験を実施しました。 結果、初期状態版、チューニング済版ともにまったく問題は発生しませんでした。カヤック様、問題作成の大詰めであったにも関わらず、事前に問題提供のご協力をくださりありがとうございました。 本選問題のデプロイ 予選の準備で使用したデプロイツールが、そのまま本選問題のデプロイにも利用できました。 本選当日 本選は10月20日(土)に行われました。 予選ではエンジニアだけアサインしていたのですが、本選ではConoHaのPR等もさせて頂くお時間があるとのことだったので、GMOインターネットからはエンジニア2名、事業部門2名で伺わせて頂きました。 本選はConoHaの応援団長 このはちゃんもお手伝いしてくれてます もちろん予選で対応して頂いたエンジニアも本選同様、弊社オフィスにて待機して頂き、万が一の事態にできるだけスムーズに対応できるよう、サーバ部門やネットワーク部門など、複数の部署からエンジニアを動員しました。 LINE様オフィスに伺った運営メンバーは会場のセッティングや、来場者の誘導等もお手伝いさせて頂き、こういったプログラミングコンテストを運営する上でのノウハウ等も学ぶことができました。ありがとうございます。 一通りの準備が終わった後は、LINE様から運営部屋を一つ用意して頂いていたので、インフラの監視準備を行いました。 LINE様に伺ったエンジニアは弊社本社待機メンバーと多くやり取りを行い、現地がどのような状況なのか伝える事に注力しました。 せっかくなので本選のサーバーの状態のデータも公開したいと思います。 下記グラフは本選にて優勝したチームのグラフですが、vCPUの使用率が上がっていき、アプリケーションの最適化がされている事が分かります。本選ではチームごとに1ホスト割り当てることができたおかげで、参加者同士でのリソースの取り合い等の影響を受けず、純粋に競い合える環境を提供できていたと思います。 特に開始から終了までインフラに問題もおきず、本選も終えることができた事を嬉しく思います。 さいごに 本選も終わり、全体を振り返ってみると、ビビり続きのISUCON8運営活動でした。 これもISUCONという大規模で、ハイレベルな技術が駆使されるイベントの運営に参加させていただけたゆえであり、お声掛けいただけた941さんを始め、LINE様には大変貴重な経験をさせて頂けたものと感謝いたしております。 カヤックの皆様、DeNAの皆様、問題作成が大変な時期にもかかわらず事前の負荷試験にご協力くださり、ありがとうございました。また、我々のVM配置案など、構成に関する相談に真摯に向き合ってくださり、ありがとうございました。ISUCON8のインフラを安定したものに保つことができたのは、問題作成者様との連携があったからであると感じております。 ConoHaの上で競技を楽しみ、喜んでくださった多くの参加者の方々にもお礼を申し上げます。皆様の有意義なISUCON体験の一助になれたこと、大変嬉しく思っております。 もしこの記事をお読みになって、新しくISUCONにご興味を持たれた方がいらっしゃいましたら、ぜひISUCON9へご参加ください。きっと素晴らしい時間を過ごせると思います。 以上、お読みいただき、ありがとうございました。

GMOインターネットが提供するVPSサービス「ConoHa」のAPIを使って、オリジナルコマンドを使ったサーバー管理方法を3回に渡ってご紹介するレポート。最終回のVol.3では、仮想マシンの作成コマンドについてご紹介します。 はじめに 引き続きConoHaをPowerShellでどうにかすべく、オリジナルコマンドを作成していきましょう。サーバー一覧の取得、サーバーの起動・停止コマンドが完成しているので、今回はサーバー（仮想マシン）の作成コマンドを作成しましょう。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET If($flavorId -eq $null){ $flavors = $result.flavors $objAry = @() ForEach($flavor in $flavors){ $id = $flavor.id $name = $flavor.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry }Else{ Return $result.flavor } } Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Get-cImage(){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/images/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $images = $result.images $objAry = @() ForEach($image in $images){ $id = $image.id $name = $image.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry } Function New-cVM($name, $imageId, $flavorId, $adminPass){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers" $body = @" { "server": { "imageRef" : "$imageId", "flavorRef" : "$flavorId", "adminPass" : "$adminPass", "metadata": { "instance_name_tag": "$name" } } } "@ $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body Return $name } モジュールファイル「PSdeConoHa.psm1」に新しいコマンドを追加していきます。 イメージ一覧の取得 サーバー作成のコマンドの前に、コマンドのパラメーターとして必要となるサーバーイメージIDを取得するコマンドを作成しておきましょう。 API解説ページでcurlコマンドのサンプルコードを見てみましょう。 curl -i -X GET \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/images/detail GETメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するだけなので簡単ですね。 PowerShellのInvoke-RestMethodコマンドで置き換えるとこのようになります。 Function Get-cImage(){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/images/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $images = $result.images $objAry = @() ForEach($image in $images){ $id = $image.id $name = $image.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry } $tokenHeader = Get-cTokenHeader：これまでと同様にトークンヘッダー情報を取得します。 $requestUrl = https://compute.tyo1.conoha.io/v2/$tenantId/images/detail：リクエストURLはこちらです。 $images = $result.images：Invoke-RestMethodコマンドの実行結果imagesの中にイメージの一覧情報が格納されています。 ForEach($image in $images)　～　Return $objAry：それぞれのイメージ情報からイメージIDとイメージ名を抜き出してPSCustomObjectに格納して戻り値としています。 実行すると、すべてのイメージ一覧が表示されます。サーバー作成時にはイメージのIDが必要となるので確認しておきましょう。 PS C:\> Get-cImageID Name-- ----b2e06d42-4c68-4792-87c4-e6faff3c5c0c vmi-drupal-8.4.2-centos-7.4-amd64-20gbae172d73-d16c-42b7-bc32-41b40ca40e63 vmi-drupal-8.4.2-centos-7.4-amd649b70032f-c486-4fd9-9e00-e7899d336406 vmi-minecraft-1.12.2-centos-7.495450a81-8194-4ff2-aab6-4f2595da56bb vmi-centos-7.4-amd64-20gb・・・ プラン一覧の取得 サーバーを作成するコマンドにもう1つ必要なパラメーターとして、プランIDがあります。以前、サーバー情報を取得する「Get-cVM」コマンドを作成した際に「Get-cFlavor」コマンドを作成して、サーバーに割り当てられているプラン情報（CPU、メモリ、HDD）を取得しました。このコマンドをサーバー作成に利用できるプラン一覧を取得できるように修正しましょう。 API解説ページでcurlコマンドのサンプルコードを見てみましょう。 curl -i -X GET \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/flavors 「Get-cFlavor」コマンドでは、URLの最後にサーバーIDを指定することで、割り当てられているプラン情報を取得していましたが、サーバーIDを指定しない場合は、プラン一覧を取得できるようです。「Get-cFlavor」コマンドを以下のように修正します。 Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET If($flavorId -eq $null){ $flavors = $result.flavors $objAry = @() ForEach($flavor in $flavors){ $id = $flavor.id $name = $flavor.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry }Else{ Return $result.flavor } } If($flavorId -eq $null)：flavorIdを指定していない場合はプラン一覧を取得します。 $flavors = $result.flavors：Invoke-RestMethodコマンドの実行結果flavorsの中にプラン一覧が格納されています。 ForEach($flavor in $flavors)　～　Return $objAry：それぞれのプラン情報からプランIDとプラン名を抜き出してPSCustomObjectに格納して戻り値としています。 Return $result.flavor：flavorIdが指定されている場合は、これまで同様該当するプラン情報を戻り値としています。 実行すると、すべてのプラン一覧が表示されます。サーバー作成時にはプランのIDが必要となるので確認しておきましょう。 PS C:\> Get-cFlavorID Name-- ----294639c7-72ba-43a5-8ff2-513c8995b869 g-2gb3aa001cd-95b6-46c9-a91e-e62d6f7f06a3 g-16gb62e8fb4b-6a26-46cd-be13-e5bbf5614d15 g-4gb7eea7469-0d85-4f82-8050-6ae742394681 g-1gb965affd4-d9e8-4ffb-b9a9-624d63e2d83f g-8gba20905c6-3733-46c4-81cc-458c7dca1bae g-32gbc2a97b05-1b4b-4038-bbcb-343201659279 g-64gbd92b02ce-9a4f-4544-8d7f-ae8380bc08e7 g-512mb サーバーの作成 ConoHaのコントールパネルでは、「サーバーの追加」メニューを表示するといくつかの選択項目があり、細かくサーバーの仕様を決めることができるようになっています。 ConoHa コントールパネル API解説ページを見てみましょう。 数多くのパラメーターがありますが、サーバーを作成する場合に必要な最低限の情報としては、X-Auth-Token、tenant_id、imageRef、flavorRef、adminPass　となっています。トークンとテナントIDはこれまで同様なので、イメージID（imageRef）とプランID（flavorRef）、管理者のパスワードが必要となります。イメージIDとプランIDは先ほど作成した「Get-cImage」と「Get-cFlavor」コマンドで確認しておきましょう。さらに、作成するサーバー名を指定しておきたいので、instance_name_tagも設定しておきましょう。 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDimageRefplainimage 参照先。対象 image の UUID を指定flavorRefplainVMプラン(flavor) の UUID を指定adminPass (Optional)plainVMのrootパスワード 詳細は vmのrootパスワードについて を参照key_name (Optional)ssh key nameplainSSHキーを利用する場合に指定するsecurity_groups (Optional)security_groupオブジェクトplainkeyに”name“を、valueにセキュリティグループ名を指定する(以下のRequestJson参照)metadata (Optional)plainmetadata の key:value ペア。instance_name_tag (Optional)Default:VMに紐づくGlobalIPアドレスplainネームタグを入れる際に利用する。文字種：半角英数字、「 - 」、「 _ 」のみを許可。文字数：255文字以下block_device_mapping (Optional)Arraydeviceは１つのみマッピングできるvolume_id (Optional)plainアタッチしたいVolumeのIDを指定するvncKeymap (Optional)plainkeymap 設定user_data (Optional)base64 encode された スタートアップスクリプトplainbase64 encoded Cloud-Init script curlコマンドのサンプルコードを見てみましょう。サーバー名としてinstance_name_tagを使用する場合は、metadata指定時のJSON形式となるので、こちらとなります。 {　　　"server": {　　　　　"imageRef": "1f7bcc63-4a18-4371-85b1-bcdd4301ff31",　　　　　"flavorRef": "b60acd11-3fd5-46e1-9387-aae4737d49aa",　　　　　"adminPass":"72LY2hf38Kf84vCy4sUr",　　　　　"metadata": {　　　　　　　"instance_name_tag": "testtest"　　　　　}　　　}} POSTメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するのでhttps://compute.tyo1.conoha.io/v2/<テナントID>/servers/<サーバー ID>/serversとなります。POSTメソッドで送信するJSON形式のデータは「-d '{"server":・・・」となっている部分で、サーバー作成のパラメーターを指定しています。サーバーの起動コマンドなどと仕組みは同じです。instance_name_tagはmetadateに指定する必要があるので、子要素を追加して指定します。 以上を踏まえてサーバーを作成するコマンドはこのようになります。 Function New-cVM($name, $imageId, $flavorId, $adminPass){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers" $body = @" { "server": { "imageRef" : "$imageId", "flavorRef" : "$flavorId", "adminPass" : "$adminPass", "metadata": { "instance_name_tag": "$name" } } } "@ $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body Return $name } Function New-cVM($name, $imageId, $flavorId, $adminPass)：New-cVMというコマンド名で、引数として、サーバー名、イメージID、プランID、管理者パスワードを指定します。 $body：POSTメソッドで送信するデータをJSON形式の文字列で指定します。必要最低限の情報は、今回はimageRef、flavorRef、adminPassの3つと、instance_name_tagとなります。 $result = Invoke-RestMethod：Invoke-RestMethodコマンドを実行します。 Return $result.server.id：サーバーが作成された場合のサーバー名を戻り値としています。 コマンドを実行してみましょう。 PS C:\> $res = New-cVM "myVM_01" "b2e06d42-4c68-4792-87c4-e6faff3c5c0c" "294639c7-72ba-43a5-8ff2-513c8995b869" "72LY2hf38Kf84vCy4sUr"PS C:\> Get-cVM $resID : 2024b61d-51ae-4c39-b196-4b317493b356Name : myVM_01State : ACTIVEMemory : 2Disk : 50vCPU : 3IPAddress : 150.95.217.10 変数”$res”の中にはNew-cVMの実行結果として、サーバー名が取得できているので、そのままGet-cVMコマンドを使ってサーバーの状態を確認することができます。 コントロールパネルでもサーバーが作成されているのが確認できます。 ConoHa サーバーリスト API解説ページにはこの他にも、「SSHキー指定時」や「追加ディスク指定時」のJSONデータのサンプルが記載されているので、必要に応じてコマンドのパラメーターを変更してより細かい設定でサーバーを作成も可能です。 以上がサーバーの作成コマンドとなります。 ConoHaにはこれまで見てきたような基本的な機能の他にも、様々なことができるAPIが用意されています。全てをPowerShellのコマンドに置き換えるのは大変ですが、自身の必要とする機能を選択してパイプラインやオブジェクトなどPowerShellならではの使いやすさで、ConoHaのサーバー管理を実現してみてはいかがでしょうか。 今後も、時間の許す限りPowerShellでConoHaをどうにかするべく、色々なコマンドを作成していきたいと考えています。 コードサンプルはGitHubにて公開しています。https://github.com/InvokeV/PSdeConoHa

GMOインターネットが提供するVPSサービス「ConoHa」のAPIを使って、オリジナルコマンドを使ったサーバー管理方法を3回に渡ってご紹介するレポート。Vol.2では、モジュールファイルの配置やサーバーの起動と停止コマンドをご紹介します。 モジュールファイルの配置 作成したPowerShellのオリジナルコマンドは、モジュール化して保存しておくことで自動的に読み込まれて利用することができるようになります。PowerShellのモジュールファイルについては以前紹介していますので、ここではモジュールファイルの配置と作成方法だけを簡単に説明することとします。 Hyper-Vで作るコンテナ　新しい仮想マシンの使い方-Vol.3　開発環境を整える “C:\Users\\Documents\WindowsPowerShell\Modules”このフォルダ内に”PSdeConoHa”フォルダを作成します。さらにPSdeConoHaフォルダ内に”PSdeConoHa.psm1”モジュールファイルを作成します。この時、フォルダ名とファイル名は同じにする必要があります。 PowerShell ISEを管理者権限で実行して"C:\Users\\Documents\WindowsPowerShell\Modules\PSdeConoHa\PSdeConoHa.psm1"ファイルを開きます。前回作成した「PSdeConoHa.ps1」の中身をそのままコピーして貼り付けます。適切な値を先頭の$apiUser、$password、$tenantIdに代入して「Remove-Module *」コマンドを実行してモジュールを初期化しておきます。これで、自動的にモジュールが読み込まれてコマンドを利用することができるようになります。モジュールを修正した場合は、再度「Remove-Module *」コマンドを実行するようにします。 前回作成した「Get-cVM」コマンドを実行してみましょう。ConoHa上のサーバー情報が取得できればモジュールの配置は成功です。 コマンドの作成：サーバーの起動 以後は、モジュールファイル「PSdeConoHa.psm1」に新しいコマンドを追加していきます。最終的に作成するのは、今回はここまでです。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET Return $result.flavor } Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 最初に作成するのはサーバーの起動コマンドです。API解説ページを見てみましょう。 必要な情報としては、 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDserver_idServer IDplainサーバーID となっています。 「Userトークン」と「テナントID」はサーバー一覧の取得と同じです。サーバーを特定するための「Server ID」が今回は必要となります。「Server ID」は実は前回作成した「Get-cVM」コマンドですでに取得できるようにしているので、ここから参照するようにします。PowerShellでは他のコマンドで取得した情報をそのまま再利用できるので非常に便利です。 curlコマンドのサンプルコードを見てみましょう。 curl -i -X POST \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \-d '{"os-start": null}' \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/servers/997d6052-4b17-4500-8d41-c08fb9667aae/action 今回はPOSTメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するのでhttps://compute.tyo1.conoha.io/v2/<テナントID>/servers/<サーバー ID>/action　となります。ポイントはPOSTメソッドでJSON形式のデータを送信するということです。curlコマンンドのサンプルで「-d '{"os-start": null}'」となっている部分です。Invoke-RestMethodコマンドではPOSTするデータは「-Body」として取り扱います。$body = '{"os-start": null}' としてJSON形式のデータを変数に格納しておきます。 起動する仮想マシンはConoHaのコントロールパネルであらかじめ停止させておき、Get-cVMコマンドでID（” fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8”）を確認しておきます。 PS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : SHUTOFFMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.*** ここまでの情報をInvoke-RestMethodコマンドで置き換えるとこのようになります。 Function Start-cVM(){　　$serverId = “fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8”　　$tokenHeader = Get-cTokenHeader　　$requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action"　　$body = '{"os-start": null}'Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body} モジュールファイルに書き込みます。一度Remove-Module *　コマンドを実行して再読み込みをしてからテストしてみましょう。停止していた仮想マシンが起動状態になっていれば成功です。 PS C:\> Start-cVMPS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : ACTIVEMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.** ConoHaのREST APIを使ってInvoke-RestMethodコマンドからサーバーを起動することが確認できました。では、PowerShellらしく、コマンドを組み合わせて利用できるように修正していきます。このままではStart-cVMコマンドではサーバーIDを決め打ちして起動しているので、パラメーターを使って、任意のサーバーを起動できるようにしてみましょう。 Function Start-cVM(){　　Param(　　　 $VM ) $serverId = (Get-cVM $VM).ID $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}'Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body} パラメーターを使って、引数として＄VMを定義してサーバー名を指定できるようにしておきます。指定されたサーバー名を元に、Get-cVMを利用して、サーバーIDを取得できるようにしました。コマンドを実行してみましょう。 PS C:\> Start-cVM vps-2017-12-07-21-28PS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : ACTIVEMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.** パラメーターを使うことで使い勝手がよくなりました。さらに、PowerShellのコマンドであれば、パイプラインを利用できるようにしておきたいところです。パイプラインを利用することで、コマンドの実行結果をパラメーターとして受け取ることができるようになるので、コードが簡略化されます。 Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 3 ：パラメーターの値をパイプラインから受け取るには、[Parameter(ValueFromPipeline=$True)]属性を変数にあらかじめ指定しておきます。 5-18 ：パイプラインで渡される値が複数の場合もあるので、すべてに対してProcessブロックで1つずつ処理をしていきます。 6 ：パイプラインでパラメーターに渡される値は文字列だけとは限りません。Get-cVMコマンドの実行結果であれば、PSCustomObject型の場合もあります。柔軟に対応できるようにSwitch文で分岐を作成しておきます。 7-8 ： PSCustomObject型の場合は、$VM変数には各種サーバーのプロパティーが格納されています。サーバーIDは$VM.IDで取得可能です。 14-17 ：String型（文字列）の場合はサーバー名ということで、これを引数としてGet-cVMコマンドを実行してサーバーIDを取得します。 85-88 ：サーバーIDが取得できれば、これまで同様、Invoke-RestMethodコマンドでConoHa APIを使ってサーバーを起動します。 パイプラインを使った場合はこのように一度にサーバーを起動することができます。 PS C:\> Get-cVM vps-2017-10-03-16-52 | Start-cVMPS C:\> Get-cVM vps-2017-10-03-16-52ID : fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8Name : vps-2017-10-03-16-52State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.***.***.** コマンドの作成：サーバーの停止 サーバーの起動ができれば、もちろん停止コマンドも必要です。ConoHaにはサーバーの通常停止と強制停止があり、通常停止はシャットダウン処理、強制停止は電源OFFと同様のものになります。今回はサーバーの通常停止を行います。 API解説ページを見てみましょう。 必要な情報としては、 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDserver_idServer IDplainサーバID となっています。 サーバーの起動を異なるのはPOSTするJSONデータが{"os-stop": null}このようになるだけです。 Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 16 ：Start-cVMからこの部分を変更します。 PS C:\> Get-cVM vps-2017-10-03-16-52 | Stop-cVMPS C:\> Get-cVM vps-2017-10-03-16-52ID : fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8Name : vps-2017-10-03-16-52State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.***.***.** 以上でパイプラインにも対応したConoHaサーバーの起動と停止コマンドが完成です。 次回以降も引き続きPowerShellでConoHaをどうにかするべく、コマンドを作成していきましょう。 コードサンプルはGitHubにて公開しています。https://github.com/InvokeV/PSdeConoHa

GMOインターネットが提供するVPSサービス「ConoHa」のAPIを使って、オリジナルコマンドを使ったサーバー管理方法を3回に渡ってレポートします。Vol.1では、APIを利用するメリットや利用方法をご紹介します。 ConoHaのAPI ConoHaはGMOインターネットが提供するVPSサービスです。初期費用無しでひと月630円から使えます。現時点では残念ながらWindowsはありませんが、豊富なテンプレートイメージと高速SSDで快適サーバーがすぐに利用できるサービスです。 https://www.conoha.jp/ VPSサービス「ConoHa byGMO」 ConoHaのサービス管理はWebで提供されているコントロールパネルから行いますが、独自のプログラムから制御もできるようにAPIが公開されています。 ConoHaのREST API情報 ConoHaのAPIはHTTPSベースのREST APIとなっており、指定されたURL対して、GETやPOSTのリクエストを送ることによってデータのやりとりを行い、利用することができます。実行結果はJSON形式で成形されたデータを受け取ることになります。今回作成するPowerShellのコマンドは、このRESTAPIを利用して作り込んでいきます。 PowrShellからAPIを利用するメリット ConoHaのAPIを利用した場合、結果はすべてJSON形式の文字列として返されることになります。プログラムではこのJSONの文字列を解析して目的の情報を取り出す必要があります。また、取り出した情報も単純な文字列となりますので、これらを使ってなにかアクションをと考えた場合、さらに一工夫が必要となります。PowerShellでは、JSON形式のデータを自動的に解析してオブジェクトとして扱えるPSCustomObjectという便利な機能が用意されています。 例えば、仮想マシン情報をPowerShellからAPIを利用して取得した場合、JSONデータを受け取ると、動的なオブジェクトとしてきちんと分類した状態で格納し、その属性として仮想マシン名や状態、メモリの容量などきちんと名前付された値として取り扱うことができるようになります。オブジェクトとして扱えることで、変数に格納したり、汎用的なPowerShellのコマンドをそのまま利用することも可能となるので、開発効率が格段にアップします。PowerShellはWindowsに標準で搭載されているシェル＆開発言語で、PowerShell ISEというエディタツールもあらかじめインストールされているので、手軽に開発をはじめることができます。 例：ConoHa上の稼働中サーバーを全て停止するコマンドを一行で実行。 Get-cVM | ? State -eq "Active" | Stop-cVM APIを利用するには まずはサービスの申し込みが必要です。ConoHaのTopページ（https://www.conoha.jp/）より申し込みを行っておきましょう。サービスの申し込みが完了すると、コントロールパネルにログインできるようになります。ConoHaのAPIを利用するには、コントロールパネルにログインするためのユーザーアカウントとは別に、APIユーザーの登録が必要です。 まずはAPIユーザーを追加しておきましょう。コントロールパネルの左メニューから「API」を選択し、「追加」ボタンをクリックします。 コントロールパネルからAPIを選択 APIユーザーのパスワードを設定して「保存」ボタンをクリックします。 APIユーザーパスワードを設定 ユーザー名は自動的に割り当てられます。APIのユーザー登録が完了したら、テナント情報のプルダウンを開いてテナントIDとテナント名を確認します。テナント名はAPIのユーザー名と同一になっています。これらの情報はREST APIを利用する時に必要となります。 テナント情報の確認 APIは利用する機能やリージョン（データーセンターの場所）ごとにエンドポイント（URL）が異なります。コード内ではこのエンドポイントを利用することになりますので確認しておきましょう。 エンドポイント情報 ConoHaのAPIの利用方法は、ConoHa API Documentationに記載されています。リクエストデータを送信するURLや必要なパラメーター、Linuxのcurlコマンドで実行する場合のサンプルコードなどが記載されています。PowerShellから利用する場合にも、同様の情報が必要となりますのでこちらを参考にコマンドを作成していきます。 ConoHa API Documantation オリジナルコマンドの作成：Invoke-RestMethodの使い方 今回作成するサンプルコード $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET Return $result.flavor } PowerShellには、REST APIを利用する場合に最適なコマンド「Invoke-RestMethod」が用意されています。コマンドの引数にURLとメソッド（POST、GET）を指定して、送信Dataを指定するだけで、APIからの情報を取得することができます。さらに、JSON形式のデータを自動的にPSCustomObjectに格納してくれるので、JSONの文字列データを解析して目的の情報を取り出すといった文字列操作は必要ありません。 簡単な例として、ConoHaのバージョン情報を取得してみましょう。 リクエストURLは「https://identity.tyo1.conoha.io/v2.0」、メソッドは「POST」となります。Invoke-RestMethodコマンドで実行するとこのようになります。 PS C:\> Invoke-RestMethod "https://identity.tyo1.conoha.io/v2.0" -Method GETversion-------@{status=stable; updated=2015-05-12T09:00:00Z; media-types=System.Object[]; id=v2.0; links=System.Object[]} 実行結果として「version」という見出しの配列（@{〇〇〇}）文字列が表示されています。文字列のように見えますが、すでにPSCustomObjectとして格納されている状態です。 実行結果を$resという変数に格納して、プロパティー値として、「version.id」を表示してみましょう。バージョン情報が取得できました。 PS C:\> $res = Invoke-RestMethod "https://identity.tyo1.conoha.io/v2.0" -Method GET$res.version.idv2.0 APIの実行結果は、元々はJSON形式のデータで送られてきています。JSON形式のデータとして表示し、確認してみましょう。ConvertTo-JSONコマンドで実行結果を変換します。 PS C:\> $res = Invoke-RestMethod "https://identity.tyo1.conoha.io/v2.0" -Method GETPS C:\> ConvertTo-JSON $res{　　"version": {　　　　　　　　　　"status": "stable",　　　　　　　　　　"updated": "2015-05-12T09:00:00Z",　　　　　　　　　　"media-types": [　　　　　　　　　　　　　　　　　　　"@{base=application/json}",　　　　　　　　　　　　　　　　　　　"@{base=application/xml}"　　　　　　　　　　　　　　　　　　],　　　　　　　　　　"id": "v2.0",　　　　　　　　　　"links": [　　　　　　　　　　　　　　　　　"@{href=https://identity.tyo1.conoha.io/v2.0/; rel=self}",　　　　　　　　　　　　　　　　　"@{href=https://www.conoha.jp/docs/; type=text/html; rel=describedby}"　　　　　　　　　　　　　　　]　　　　　　　　　}} APIの解説ページと同じJSONデータが確認できました。 オリジナルコマンドの作成：トークンの取得 先ほどのバージョン情報を取得する場合では必要ありませんでしたが、ConoHaのAPIを利用する場合には、コマンドにトークンと呼ばれる「認証済み」情報を付加して実行する必要があります。トークンは先ほどコントロールパネルで追加したテナント情報（テナントID、APIユーザー、パスワード）を元にREST APIを利用して発行されます。一度発行されたトークンは24時間の有効期限があり、その間であれば繰り返し利用することが可能です。 APIの解説ページを見てみましょう。 必要な情報としては、 ParameterValueStyleDescriptionusernameユーザー名plainユーザー名passwordユーザーパスワードplainユーザーパスワードtenantId (Optional)Tenant IDplainテナントID このようになっています。curlコマンドのサンプルコードを見てみましょう。 curl -i -X POST \-H "Accept: application/json" \-d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"},"tenantId":"487727e3921d44e3bfe7ebb337bf085e"}}' \https://identity.tyo1.conoha.io/v2.0/tokens Invoke-RestMethod コマンドで必要となる情報としては、メソッドの”POST”、「-d」の送信する文字列データ、リクエスト先のURLとなります。 送信する文字列データは '{"auth":{"passwordCredentials":{"username":"<ユーザー名>","password":"<ユーザーパスワード>"},"tenantId":"<テナントID>"}}' となっています。最後の｢\｣マークは改行コードなので省略します。 ここまでの情報をInvoke-RestMethodコマンドで置き換えるとこのようになります。 PS C:\> $apiUser = "gncu12345678"$password = "paSSword123456#$%"$tenantId = "487727e3921d44e3bfe7ebb337bf085e"$body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}'$tokenUrl = “https://identity.tyo1.conoha.io/v2.0/tokens”Invoke-RestMethod $tokenUrl -Method POST -Body $body Invoke-RestMethod $tokenUrl -Method POST -Body $body　：　Invoke-RestMethodコマンドに各設定値を指定して実行します。 ここまでを実行してみましょう。データが取得できていれば成功です。 access------@{token=; serviceCatalog=System.Object[]; user=; metadata=} 取得したトークン情報で必要となるのが、「access.token.id」（トークンID）の値です。トークンIDは他のAPIの機能を利用する場合に、Invoke-RestMethodコマンドのヘッダー情報「-Header」オプションに「@{"X-Auth-Token" = <トークンID>}」としてIDictionary型で指定することで認証済みのリクエストとして実行可能となります。（参考：IDictionaryはキーと値を1つのペアとしたコレクション変数の型。） ここまでをGet-cTokenHeaderという名前で1つのコマンドとしてまとめてみましょう。また、他のコマンドでも利用する可能性がある変数は、コマンドのブロック外で共通変数として定義しておきます。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = “https://identity.tyo1.conoha.io/v2.0/tokens” $token = Invoke-RestMethod $tokenUrl -Method POST -Body $body $tokenId = $token.access.token.id Return @{"X-Auth-Token" = $tokenId} } 実行結果はこのようになります。トークンIDを含んだIDictionary型のヘッダー情報が作成されていれば成功です。 PS C:\> Get-cTokenHeaderName Value---- -----X-Auth-Token 0643af2d2105456690efad28107ed23d 取得したトークンは24時間の有効期限が設定されています。他のAPIを利用する場合に同じトークンIDが利用可能です。パフォーマンンスアップにもつながるので、トークンを再利用するためのロジックを追加しておきましょう。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } 1-3：スクリプト共通で利用する定数として定義しておきます。PowerShellではSet-VariableコマンドのConstantオプションで定数を定義できるのですが、ここは簡易的にしています。 4：Get-cTokenHeaderコマンドで取得したトークン情報を格納しておく変数です。スクリプト内で共通に参照するので、「$script:」オプションを付けています。 10 ：トークンを格納した変数にトークン情報が入っている場合と、空の場合で分岐します。 11 ：トークン情報が入っている場合は、$token.access.token.expire　からトークンの有効期限を取得します。 12 ：トークンの有効期限が終了していた場合は、トークン情報を再取得します。 15 ：トークン情報が空の場合は、トークン情報を取得します。 以上で効率的にトークンの再利用が可能となりました。ここまで作成したコマンドは、スクリプトファイルとして「PSdeConoHa.ps1」という名前で保存しておきましょう。 サーバー一覧の取得 サーバー一覧を取得するコマンドを作成する前に、コントロールパネルからいくつかサーバー（＝仮想マシン）を作成しておきましょう。左メニューから「サーバーの追加」を選択します。”タイプ：VPS”、”リージョン：東京”として、他の項目は任意で指定して作成しておきます。 サーバーの追加 VM一覧詳細取得のAPI解説ページを見てみましょう。 必要な情報としては、以下です。 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idTenant IDURIテナントIDchanges-since (Optional)ISO 8601 dateTime (2016-04-04T17:08Z)query削除されたものを含む、指定時間からのVM一覧image (Optional)queryVMに使用されているイメージIDflavor (Optional)queryVMに使用されているフレーバーIDname (Optional)queryVM名marker (Optional)query表示される最後のUUIDlimit (Optional)queryVMの表示数status (Optional)queryVMの状態 「Style」がqueryとなっている項目はオプションです。必須ではありませんので任意で指定します。必要な項目としては、「Userトークン」と「テナントID」となります。 curlコマンドのサンプルコードを見てみましょう。 curl -i -X GET \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/servers/detail Invoke-RestMethodコマンドで必要となる情報としては、メソッドの”GET”、「-H」のヘッダー情報としてトークン、リクエスト送信先のURLとなります。トークンは先ほど作成した「Get-cTokenHeader」コマンドで取得できます。URLは https://compute.tyo1.conoha.io/v2/<テナントID>/servers/detailとなっています。東京以外のリージョンでサーバーを作成した場合は「compute.tyo1.conoha.io」の部分が異なりますので、コントロールパネルの「エンドポイント」で確認しましょう。 ここまでの情報をInvoke-RestMethodコマンドで置き換えるとこのようになります。 PS C:\> $tokenHeader = Get-cTokenHeader$requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail"Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET 実行してみましょう。データが取得できていれば成功です。 servers-------{@{status=ACTIVE; updated=2017-11-13T02:31:57Z; hostId=6d67cc67c8e7f133bb22ed9ac52a8cc4d1c737595ec28... 実行結果のserversにはConoHa上のすべてのサーバーの詳細な情報が含まれています。試しに以下を実行してみると、仮想マシンの台数分だけ情報が繰り返し表示されます。 PS C:\> $tokenHeader = Get-cTokenHeader$requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail"$result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET$servers = $result.serversForEach($server in $servers){$server}status　　　　　　　　　　　　　　　 : ACTIVEupdated　　　　　　　　　　　　　　 : 2017-11-13T02:31:57ZhostId : 6d67cc67c8e7f133bb22ed9ac52a8cc4d1c737595ec2892c3a7cc8e4OS-EXT-SRV-ATTR:host : cn-a11018.g2.tyo1.v4addresses : @{ext-150-95-150-0-23=System.Object[]}links : {@{href=https://compute.tyo1.conoha.io/v2/07af275f5800401f83d9f1e2913fe37e/servers/a7b8c9c5-b17c-4446-9b06-337d17083bf4; rel=self}, @{href=https://compute.tyo1.conoha.io/07af275f5800401f83d9f1e2913fe37e/servers/a7b8c9c5-b17c-4446-9b06-337d17083bf4; rel=bookmark}}key_name :image : @{id=5a933dc9-c2ec-48d7-98e4-a72d408c9ffb; links=System.Object[]}OS-EXT-STS:task_state :OS-EXT-STS:vm_state : activeOS-EXT-SRV-ATTR:instance_name : tyo1-00118ab8OS-SRV-USG:launched_at : 2017-11-05T07:23:09.000000OS-EXT-SRV-ATTR:hypervisor_hostname : cn-a11018.g2.tyo1.v4flavor : @{id=7eea7469-0d85-4f82-8050-6ae742394681; links=System.Object[]}id : a7b8c9c5-b17c-4446-9b06-337d17083bf4security_groups : {@{name=default}, @{name=gncs-ipv6-all}, @{name=gncs-ipv4-all}}OS-SRV-USG:terminated_at :OS-EXT-AZ:availability_zone : novauser_id : fcdaf312424446acb12adced7b449047name : 150-95-151-89created : 2017-11-05T07:22:59Ztenant_id : 07af275f5800401f83d9f1e2913fe37eOS-DCF:diskConfig : MANUALos-extended-volumes:volumes_attached : {}accessIPv4 :accessIPv6 :progress : 0OS-EXT-STS:power_state : 1config_drive : Truemetadata : @{instance_name_tag=vps- 2017-11-05-16-15; backup_status=active; backup_id=; properties={"vnc_keymap":"ja","hw_video_model":"vga","hw_vif_model":"virtio","hw_disk_bus":"virtio","cdrom_path":""}; backup_set=0}... 情報量が非常に多いため、作成するコマンドではこれらの中から必要な情報を選択して表示することにします。Invoke-RestMethodコマンドの実行結果は元々PSCustomObjectが配列に格納されたものなので、Get-cVMという名前でサーバー一覧情報を取得して抽出するコマンドを作成し、同様にPSCustomObjectが配列に格納された実行結果を返すようにします。 Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET Return $result.flavor } 1-4 ：Paramで定義した変数$Nameはコマンドの引数として利用します。単一のサーバー情報を取得する場合に指定します。 7 ：Invoke-RestMethodコマンドの実行結果を$resultに格納しておきます。 8：サーバー情報は$result.serversで取得します。 10 ：APIから取得したサーバー情報から抽出した情報を格納するための配列を定義します。この配列には一台一台のサーバー情報をPSCustomObjectに格納したものが入ります。 11：サーバーを1台ごとに参照して情報を抽出します。 13 ：$server.metadata.instance_name_tagが、ユーザーがコントロールパネルから見た場合のサーバー名（ネームタグ）となります。 15：$flavorId = $server.flavor.idはサーバーのプラン情報のIDとなります。 16-19 ：Get-cFlavorコマンドを作成して、プラン情報からサーバーのメモリ容量、CPU、ディスクサイズを取得します。 20 ：IPv4のアドレスのみ取得しています。 22-29 ：PSCustomObjectを定義して、取得した情報を「キー：値」のペアとして登録します。 30 ：配列に格納しておきます。 34 ：パラメーターで定義した$Nameに値が入っていた場合は、その名前でフィルタします。 37-38 ：指定された仮想マシンが見つからない場合はエラーを表示します。 40 ：コマンドの実行結果として、配列に格納されたPSCustomObjectを返します。 44 ：flavorIDからサーバーのプランを抽出するためのコマンドを作成します。 46-48 ：tenantIDとflavorIDを指定してAPIからプランを取得します。 コマンドを実行してみましょう。シンプルで分かりやすいサーバー情報が取得できいています。 PS C:\> Get-cVMID : a7b8c9c5-b17c-4446-9b06-337d17083bf4Name : vps-2017-11-05-16-15State : ACTIVEMemory : 1Disk : 50vCPU : 2IPAddress : 150.95.151.89ID : 1e08705e-72a5-423a-b9d6-0783e37c98ecName : vps-2017-10-24-12-29State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.95.184.136ID : fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8Name : vps-2017-10-03-16-52State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.95.156.236 以上のように、ConoHaのREST APIはPowerShellのInvoke-RestMethodコマンドとPSCustomObjectを利用することで、とても使いやすいものとなります。次回以降も引き続きPowerShellでConoHaをどうにかするべく、コマンドを作成していきましょう。また、オリジナルコマンドをさらに使いやすくするためにモジュールとして登録する方法も紹介する予定です。