【MicrosoftAzure】自習書シリーズをやってみる①(~リソースグループ作成~)
MicrosoftAzureには、自習書シリーズという立派な教育ドキュメントがあり、 しかも無料でダウンロード可能。MicrosoftAzureの学習をするにあたり、 それらを利用しない手はないため、まずは、それらの内容をやってみることに。
Download Microsoft Azure 自習書一式 from Official Microsoft Download Center
上記のダウンロード一式の中には、いろいろなドキュメントがあるものの、 内容的に、下記のドキュメントの内容を試すことを前提に、Powershellの環境を整えたため、 下記ドキュメントを使用することに。
「Azure 自習書シリーズ コマンドラインによる仮想マシンの構成と操作」(以下、「自習書シリーズ」)
以下は、上記ドキュメントを使用し、いろいろトライした際の学習記。
目次
- 目次
- 学習目標とする構成
- リソースグループとは
- 「New-AzureRmResourceGroup」コマンドによるリソースグループの作成
- 「New-AzureRmResourceGroup」コマンドの実行
- 「Get-AzureRmResourceGroup」でのリソースグループの確認
学習目標とする構成
「自習書シリーズ」に掲載されている 下記の構成の完成が、当面の学習の目標。
※「Azure 自習書シリーズ コマンドラインによる仮想マシンの構成と操作」より引用。
リソースグループとは
複数のリソースを論理的にまとめたもので、 リソースグループを削除すると、リソースグループ内の すべてのリソースを一括して削除するようなことができる。 1つのリソー社1つのリソースグループのみに属することができ、 Powershellでは、「New-AzureRmResourceGroup」コマンドで、 リソースグループを作成することができる。
※下記書籍では、P196ページにリソースグループに関しての説明がされていた。
ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築
- 作者: 横山哲也
- 出版社/メーカー: 日経BP社
- 発売日: 2015/09/10
- メディア: 単行本
- この商品を含むブログ (1件) を見る
概念的には、下記のような感じか・・
※「Azure 自習書シリーズ コマンドラインによる仮想マシンの構成と操作」より引用。
「New-AzureRmResourceGroup」コマンドによるリソースグループの作成
「自習書シリーズ」に丁寧な解説があるが、 「New-AzureRmResourceGroup」の必須パラメータは下記の通り。
- Location・・・仮想マシンを作成する地域を入力
- Name・・・リソース グループ名を入力。
ここでは、「自習書シリーズ」に記載のとおり、 下記のパラメータ設定で、リソースグループを作成した。
- Location・・・AW-RG
- Name・・・japanwest
「New-AzureRmResourceGroup」コマンドの実行
以下の通り、New-AzureRmResourceGroupでリソースグループを作成する。
$rg = "AW-RG" $location = "japanwest" New-AzureRmResourceGroup -Location $location -Name $rg
以下の通り、、ProvisioningStatus が 「Succeeded」になっていることを確認する。
(出力結果) ResourceGroupName : AW-RG Location : japanwest ProvisioningState : Succeeded Tags : ResourceId : /subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/AW-RG
「Get-AzureRmResourceGroup」でのリソースグループの確認
以下の通り、Get-AzureRmResourceGroupでリソースグループが作成されたことを確認できる。
Get-AzureRmResourceGroup -Name AW-RG
【MicrosoftAzure】PowerShellを使えるようにする。
下記で、MicrosoftAzureでアカウントを作成したため、 続いて、PowerShellからAzureを管理操作するための環境整備の 備忘録。
目次
Powershellモジュールのダウンロード&インストール
まず、Powershellモジュール(WindowsAzurePowershellGet.3f.3f.3fnew.exe)を ダウンロードするため、下記サイトにアクセスし、
[ダウンロード]を選択し、
PowerShellの「Windowsのインストール」をクリック。(以下の赤枠の箇所をクリック)
[インストール]を押下する。
[同意する]を押下する。
インストールが始まる
[完了]を押下する。
PowershellからAzureに接続する。
PoswershellからAzureに接続してみるため、 Poswershellを「管理者として実行」で起動する。
以下のコマンドを実行する。
PS C:\WINDOWS\system32> Login-AzureRmAccount
下記の画面が起動するので、Azureのアカウントとパスワードを入力し、サインインする
サインインすると、サブスクリプション情報などが表示される。
以下のコマンドで、Azureモジュールのヘルプ情報を取得てみる。
PS C:\WINDOWS\system32> Get-Help AzureRM
PowershellからのAzureへの自動ログイン(管理証明書による認証)
証明書を利用し、PowershellからAzureへ自動ログインできるようにする。
管理証明書による認証は、サブスクリプション情報を一度ダウンロードしてインポートする。 再度操作する必要はないため、一度この方法で設定しておけば、スクリプトなどの自動化が 行いやすくなる。
以下のコマンドを実行する。
PS C:\WINDOWS\system32> Get-AzurePublishSettingsFile
ブラウザが起動するので、Microsoft アカウントでサインインする。
サブスクリプションファイルのダウンロード画面が表示されるので、任意の場所にファイルを保存
Import-AzurePublishSettingsFile コマンドで、保存したサブスクリプションファイルを インポートします。 ここでは、C:\無料試用版-11-5-2016-credentials.publishsettingsにサブスクリプションファイルを保存したものとして 以下を実行する。
※保存したファイルが第三者の手に渡ると、Azure を自由に操作されてしまいますので注意する。
PS C:\WINDOWS\system32> Import-AzurePublishSettingsFile -PublishSettingsFile 'C:\無料試用版-11-5-2016-credentials.publishsettings'
上記コマンドで、インポートしたファイルは、「%UserProfile%\"AppData\Roaming\Windows Azure Powershell"\AzureProfile.json」に保存される模様。
【MicrosoftAzure】アカウントを作成してみる(2016年11月時点)
2016年8月ごろ、無料枠を使用し、MicrosoftAzureの学習を行おうと思い立ち、試してみたが、 アカウント作成の時点で、うまくいかなかったのは、下記記事のとおり。
時間ができたので、改めてMicrosoftAzureのアカウントを作成し、無料枠でAzureをいろいろ試して みようと思ったため、その備忘録。
試す内容は、下記書籍に基づきやってみたいのだが、
ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築
- 作者: 横山哲也
- 出版社/メーカー: 日経BP社
- 発売日: 2015/09/10
- メディア: 単行本
- この商品を含むブログ (1件) を見る
アカウント作成ができないことには、何も始まらないので、 改めて、アカウント作成にトライ。
まずは、あらかじめMicrosoftアカウントを作成しておく(自分は@hotmail.comにアカウントを作った)
次に、下記サイトに行き、
下記のページに遷移する。
[無料で始める]をクリックする。
作成したアカウントとパスワードを求められるので、 入力しログインすると、下記の画面に遷移するので、 名前などを入力する。
電話による本人確認画面で、電話番号を入力し、 [テキストメッセージを受信]を選ぶ。
入力した電話番号和手に、テキストメッセージとして任意の番号が 通知されるので、入力する。
次に、カード情報の入力を行う。
次に、[サインアップ]する。
次に、下記をクリックすると・・
晴れて、Azureの管理ポータルが開き、操作可能となる。
8月の時点で、なざうまくいかなかったのか不思議なぐらい、 あっさりうまくできたが、何はともあれ、こちらのアカウント(無料枠)を利用し、 MicrosoftAcureを勉強していくことに。
【書評】野村克也の「弱者の兵法」
- 作者: 野村克也
- 出版社/メーカー: アスペクト
- 発売日: 2009/07/24
- メディア: 単行本
- 購入: 2人 クリック: 51回
- この商品を含むブログ (14件) を見る
2009年当時、楽天の監督時代の本であるが、野村監督の組織論や、 人材育成論について、書かれた本。
野村監督といえば、「野村再生工場」の通り、古くは、南海時代の江本孟紀、門田博光、 ヤクルト時代の小早川毅彦、最近では、楽天、山崎武司など ベテラン選手の再生を見事に成功させたことはあまりにも有名であるが、 とりわけ、江夏豊の再生についての部分が野球ファンには、堪らない。
野球が分業制となる時代を早くから、見据え江夏豊をクローザ―転向を 迫った話は有名であるが、そのほかの下記の口説き文句が書いてある。
(本書より)
「南海に来い」という言葉は口にしない。 江夏に、”南海で野村と一緒に野球をやろう”と思わせよう。 江夏は、超一流の選手である。野球を愛しているし、 深く広く学びたいという欲求も人一倍持っている。 そして、理解も非常に深い。そこをくすぐる話題を振れば、 絶対に私を信頼し、なびいてくるはずだと思ったのである。 また江夏は正義感が強く、自尊心のの高い性格であることも知っていた。 そこで、前年のシーズンで、江夏が広島戦で、 衣笠をカウント2-3から空振り三振に仕留め、 三塁に走ってきたセカンドランナーを刺してダブルプレーに とったプレーを引き合いに出し、 「あの、2-3からの1球わざとボール球をなげたろう。」(野村) 「どうしてわかったんですか?そんなこといわれたの、はじめてですよ」(江夏) 「一度でいいから、お前と野球をやってみたいもんだ。お前が投げて、 俺が受ける。これは芸術になるぞ」(野村) 江夏はニヤリとしただけだったが、それはOKの意思表示に違いなかった。 事実それからほどなくして、江夏は南海への移籍を承諾したのである。
以前、有名な「江夏の21球」の回顧番組で、 時の広島古葉監督が江夏がマウンドにいるのにもかかわらず、 ブルペンに投手を用意させたことに対して、
「江夏のプライドを考えたら、絶対にできない」
というようなことを野村監督は言っていたが、緻密な理論のもさることながら、 こういった人間学に優れているところが、名将たる所以だろう。
これは、野村監督そのものが、テスト生から三冠王そして、監督という、 一番下から、トップになったという稀有の経歴があればこそだろう。
それから、一流の監督の条件としては、以下のとおりのようだ。 (詳しくは、本書を参考にされたい)
(本書より)
* 優勝回数 * 人望 * 度量(器) * 風格 * 言葉 * 判断力と決断力 * 知識
上記に「人気」が入っていないことが興味深い。
また、本書の「弱者の兵法」とは、とどのつまり 「無形の力」をうまくつかうことのようだ。本書では、
(本書より)
無形の力」とは、文字通り「かたちにならない力」、 すなわち「目に見えない力」のことを指す。 具体的にいえば、 「分析」、「観察」、「洞察」、「判断」、「決断」、「記憶」 としてまとめられようか。
これは、「野村ID野球」という言葉で凝縮されてしまうのかもしれないが、 それらに対する要求度の高さがスコアラーに対しての要求度の高さにも表れている。
(本書より)
ヤクルトの監督に就任したとき、スコアラーから届けられるデータの ほとんどはパーセンテージで示した数字だった。 例えば、このピッチャーの投げる球種はストレートが何パーセント、 カーブが何パーセントといったように・・・。それをみて私は言った。 「そんなものは、テレビ局にでもくれてやれ!」 無形の力を活かすために必要なデータとは、「統計」ではない。 具体的でなくてはならないのだ。 具体的にいえば、 「12種類あるボールカウントごと」、 「そのピッチャーはどういうボールを投げてくるか」、 「ストレートは何球まで続けるか」、 「どういう状況でキャッチャーのサインに首を振ったか」、 バッターなら 「大きな空振りやホームラン級のファールの後、どういうバッティングをしたか」、 「甘いストレートを見逃したとき、次のボールにどういう反応を示したか」 といったような情報である。 いわば、心理に関するものなのだ。
深い。いまでこそ、当たり前のスコアラ分析をこの精度で、 およそ25~30年前にやっていたことに、先進性を感じる。
そして、野村監督のチーム・組織作りの根底にあるもの、強さの根底にあるものは、 下記のものと言えると思う。
(本書より)
ヤクルト時代でも、阪神でも楽天でも私は、 選手たちに優位感を植え付けることに腐心してきた。 選手が「自分たちは他のチームより、進んだ野球をしている。」 という意識を持つことは、非常に大切だからである。
巨人V9時代、、森監督の西武時代、野村ヤクルト時代、などある程度、 長く繁栄したチームに共通しているのは、こういった「他所と違う」と いった選手たちのメンタリティーがあったように思える。
このいわば、「勝者のメンタリティー」は、プロ野球に限らず 、サッカーでいえば、現在のFCバルセロナなど他のスポーツにも共通して言えることで、 ひいてはサラリーマンの組織論にも共通していえるこだと思える。
このように、理論的かつ合理的な考えを持つ野村監督をして、 人材育成・コーチングの基本は、「愛情」という非常に感情的なものであることも 非常に興味深い。
監督に最も大切なことは何か。一言でいえばそれは愛情だと思っています。
野村本の中でもおすすめの一冊である。
「AWS-CLIで試すLambdaでのHelloWorld!」を試す
AWS Lambdaを試してみたいと思っていたところ、 AWS CLIを使ってAWS Lambdaを体験してみるのに、ちょうどいい記事があったため、
上記記事をもろパクリで、AWS Lambdaを試して際の備忘録。
目次
- 目次
- ユースケース
- 構成
- S3バケットの作成
- Lambda Exec Roleの作成
- Lambdaの設定
- イベントを明示的に発行させる。
- S3の設定をする
- S3にファイルをアップロードし、イベントを発行する。
- 最後に作成した設定を削除する。
ユースケース
- ユースケースは、上記記事にある通り、主に下記のとおり。
- AWS CLIを使ってAWS Lambdaを設定する。
- Lambdaで Hello World Lambda! という出力をCloudWatchLogsに出力
構成
(構成図)
S3バケットの作成
まずは、バケットを作成します。作成するS3バケットのリージョンは 上記記事のとおり、「us-east-1」 とする。 mylab-lambda-test となっている部分は適当に変更する。
[root@Linux ~]# aws s3 mb s3://mylab-lambda-test --region us-east-1 make_bucket: s3://mylab-lambda-test/ [root@Linux ~]#
作成されたことを確認
[root@Linux ~]# aws s3 ls --region us-east-1 |grep lambda 2016-10-30 01:42:29 mylab-lambda-test [root@Linux ~]#
上記記事のとおり、コマンド実行。(nullの意味はよく分からない)
[root@Linux ~]# aws s3api get-bucket-location --bucket mylab-lambda-test { "LocationConstraint": null } [root@Linux ~]#
Lambda Exec Roleの作成
Lambdaで処理を実行する際にCloudWatchLogsにログを出力するためのLambdaExecRoleする。
[root@Linux aws]# cat role-policy.json { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Principal": { "Service": "lambda.amazonaws.com" }, "Effect": "Allow", "Sid": "" } ] } [root@Linux aws]#
作成後、以下のCLIでロールを作成する。
[root@Linux aws]# aws iam create-role --role-name hello_exec_role --assume-role-policy-document file://role-policy.json { "Role": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Sid": "", "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" } } ] }, "RoleId": "xxxxxxxxxxxxxxxxxx", "CreateDate": "2016-10-29T16:49:41.478Z", "RoleName": "hello_exec_role", "Path": "/", "Arn": "arn:aws:iam::999999999999:role/hello_exec_role" } } [root@Linux aws]#
作成されたロールを確認する。
[root@Linux aws]# aws iam get-role --role-name hello_exec_role
また、後の行程で利用するロールのARN「下記「999999999999」の個所」)を確認する。
[root@Linux aws]# aws iam get-role --role-name hello_exec_role |jq -r .'Role.Arn' arn:aws:iam::999999999999:role/hello_exec_role [root@Linux aws]#
CloudWatchLogsへの書き込みを行う権限を付与する。(LambdaではCloudWatchLogsにログ情報を記載) 最初からAWS側で用意してあるポリシーがあるようなので、今回はそれを利用するため、下記コマンドで確認。
[root@Linux aws]# aws iam get-policy --policy-arn "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess" { "Policy": { "PolicyName": "CloudWatchLogsFullAccess", "Description": "Provides full access to CloudWatch Logs", "CreateDate": "2015-02-06T18:40:02Z", "AttachmentCount": 0, "IsAttachable": true, "PolicyId": "xxxxxxxxxxxxxxxxxxx", "DefaultVersionId": "v1", "Path": "/", "Arn": "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess", "UpdateDate": "2015-02-06T18:40:02Z" } } [root@Linux aws]#
先述のロールに上記ポリシーを付与する。
[root@Linux aws]# aws iam attach-role-policy --role-name hello_exec_role --policy-arn "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess" [root@Linux aws]#
確認する。(先ほど付与したポリシーが表示されることを確認)
[root@Linux aws]# aws iam list-attached-role-policies --role-name hello_exec_role { "AttachedPolicies": [ { "PolicyName": "CloudWatchLogsFullAccess", "PolicyArn": "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess" } ] } [root@Linux aws]#
Lambdaの設定
続いて、Lambdaの設定する。 最初に Lambda に機能を追加する。先述の記事そのままのコードを追加する。
[root@Linux aws]# cat index.js console.log('Loading function'); exports.handler = function(event, context) { console.log('value1 =', event.key1); console.log('value2 =', event.key2); console.log('value3 =', event.key3); console.log('hello world!'); context.succeed(event.key1); // Echo back the first key value // context.fail('Something went wrong'); }; [root@Linux aws]#
上記はzip圧縮する。
[root@Linux aws]# zip -r HelloWorld.zip index.js adding: index.js (deflated 47%) [root@Linux aws]# [root@Linux aws]# ls -l HelloWorld.zip -rw-r--r-- 1 root root 351 10月 30 01:56 2016 HelloWorld.zip [root@Linux aws]#
LamdaFunctionを作成する。 --role には先ほど作成したRoleのARN(「下記「999999999999」の個所」)を指定する。
[root@Linux aws]# aws lambda create-function \ > --function-name hello_function \ > --runtime nodejs \ > --role arn:aws:iam::999999999999:role/hello_exec_role \ > --handler index.handler \ > --zip-file fileb://HelloWorld.zip \ > --region us-east-1 { "CodeSha256": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Malc=", "FunctionName": "hello_function", "CodeSize": 351, "MemorySize": 128, "FunctionArn": "arn:aws:lambda:us-east-1:999999999999:function:hello_function", "Version": "$LATEST", "Role": "arn:aws:iam::999999999999:role/hello_exec_role", "Timeout": 3, "LastModified": "2016-10-29T16:57:33.995+0000", "Handler": "index.handler", "Runtime": "nodejs", "Description": "" } [root@Linux aws]#
確認する。
[root@Linux aws]# aws lambda get-function --function-name hello_function --region us-east-1 { "Code": { "RepositoryType": "S3", "Location": "https://prod-04-2014-tasks.s3.amazonaws.com/snapshots/812517560171/hello_function-4ae7c455-9bc4-4e96-8c0d-7463b41392b3?X-Amz-Security-Token=FQoDYXdzEDEaDIanV7oOQ5we%2BLkdvCK3A5h76yiKfc72ECqG6XhXe53l4RGqmX2bPtiXWsxuBfhH%2FK0cxoYi3KSB3YvpgJpc7bckdc1UwUm62x0uXqaS1GYxVYXpzQl1LPxneQiA3SF6cwfBneLj%2FLFqKPVVCLok%2BL0qt7xu9dS8ZHEFL42sk%2BcCsNIgnw5OzICsN%2BIcQ9XA%2BtmHEeOw%2Fw1LemS5P%2FBzw7vF4WOjy3JQl7Y2Es313STb0ILto5ZmuHuI1tRBCWNfPv3yuBrwj%2FEjIfSX0AEqMIMxwO%2FjlKMo7IVmMkD1QUPgu%2BENgt0lmfqZ0Zy9PXg74wOs9Jhprmws5tnUABspI9L%2B3NlcM1YSpOGo%2FMUUWwzyjXCC44Kl4Ir3ECb4NQpyvClzESGSoG1JL%2F1EsROd3Mi4fpuDBiTrREAEyBg08XuUEXfpVXjXz%2FpyAoZhVE4KiuZp7r8p4d%2BVfBCexIb4sQVWCvfoMjANENa9kQbbDi5S54hz7RPwT71Akk8s6%2FbLKMWmPdgKj8kZrW0r0xirD%2B%2Fi%2FmBiCDMd1SFtQ6TbGnkrkNK9yTBfb%2FJuRkHY2ST80jnU63dmkeN0CJEextWCpclBRUk0n10owovTwAU%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20161029T165800Z&X-Amz-SignedHeaders=host&X-Amz-Expires=600&X-Amz-Credential=ASIAJJ2IKKNCV4NGIF3A%2F20161029%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=9ccdfd59ed3445203b7b320cec9d73d0d2ab18e5584f94aa29e79789a2546473" }, "Configuration": { "Version": "$LATEST", "CodeSha256": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Malc=", "FunctionName": "hello_function", "MemorySize": 128, "CodeSize": 351, "FunctionArn": "arn:aws:lambda:us-east-1:999999999999:function:hello_function", "Handler": "index.handler", "Role": "arn:aws:iam::999999999999:role/hello_exec_role", "Timeout": 3, "LastModified": "2016-10-29T16:57:33.995+0000", "Runtime": "nodejs", "Description": "" } } [root@Linux aws]#
あとで、利用するARNを「下記「999999999999」の個所」)確認する。
[root@Linux aws]# aws lambda get-function --function-name hello_function --region us-east-1 |jq -r .'Configuration.FunctionArn' arn:aws:lambda:us-east-1:999999999999:function:hello_function [root@Linux aws]#
イベントを明示的に発行させる。
上記記事のとおり、イベントを明示的に発行するため、以下のファイルを保存する。 なお、 mylab-lambda-test というバケット名の箇所は適宜自分の作成したバケット名に変更する。
[root@Linux aws]# cat input.txt { "Records":[ { "eventVersion":"2.0", "eventSource":"aws:s3", "awsRegion":"us-west-2", "eventTime":"1970-01-01T00:00:00.000Z", "eventName":"ObjectCreated:Put", "userIdentity":{ "principalId":"xxxxxxxxxxxxxxx" }, "requestParameters":{ "sourceIPAddress":"127.0.0.1" }, "responseElements":{ "x-amz-request-id":"xxxxxxxxxxxxxxx", "x-amz-id-2":"xxxxxxxxxxxxxxx/xxxxxxxxxxxxxxx/xxxxxxxxxxxxxxx" }, "s3":{ "s3SchemaVersion":"1.0", "configurationId":"testConfigRule", "bucket":{ "name":"mylab-lambda-test", "ownerIdentity":{ "principalId":"xxxxxxxxxxxxxxx" }, "arn":"arn:aws:s3:::mylab-lambda-test" }, "object":{ "key":"HappyFace.jpg", "size":1024, "eTag":"xxxxxxxxxxxxxxx", "versionId":"xxxxxxxxxxxxxxx.xxxxxxxxxxxxxxx" } } } ] } [root@Linux aws]#
以下で実行する。
$aws lambda invoke --invocation-type Event --function-name hello_function --region us-east-1 --payload file://input.txt outputfile.txt { "StatusCode": 202 }
ログ出力されていることを確認する。
[root@Linux aws]# aws logs describe-log-streams --log-group-name /aws/lambda/hello_function --region us-east-1 { "logStreams": [ { "firstEventTimestamp": 1477760612319, "lastEventTimestamp": 1477760892171, "creationTime": 1477760612236, "uploadSequenceToken": "49558049102621580872441351977558681473346750801996953826", "logStreamName": "2016/10/29/[$LATEST]f11d2581b1174061a6bcec5415008bdf", "lastIngestionTime": 1477760907296, "arn": "arn:aws:logs:us-east-1:812517560171:log-group:/aws/lambda/hello_function:log-stream:2016/10/29/[$LATEST]f11d2581b1174061a6bcec5415008bdf", "storedBytes": 0 } ] } [root@Linux aws]#
S3の設定をする
以下のコマンドを実行する。hello_functionのlambda:InvokeFunctionにS3の権限を付与する。 statement-id には任意の名称を指定し、ARNは arn:aws:s3:::{bucket_name} の形式で指定する。 ※ここら辺はよくわからないので、先述の記事をいままで通りパクる。
[root@Linux aws]# aws lambda add-permission --function-name hello_function --region us-east-1 --statement-id s3_mylab-lambda-test --action "lambda:InvokeFunction" --principal s3.amazonaws.com --source-arn "arn:aws:s3:::mylab-lambda-test" { "Statement": "{\"Sid\":\"s3_mylab-lambda-test\",\"Resource\":\"arn:aws:lambda:us-east-1:812517560171:function:hello_function\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"s3.amazonaws.com\"},\"Action\":[\"lambda:InvokeFunction\"],\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:s3:::mylab-lambda-test\"}}}" } [root@Linux aws]#
確認する。
[root@Linux aws]# aws lambda get-policy --function-name hello_function --region us-east-1 { "Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"default\",\"Statement\":[{\"Sid\":\"s3_mylab-lambda-test\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"s3.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-east-1:812517560171:function:hello_function\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:s3:::mylab-lambda-test\"}}}]}" } [root@Linux aws]#
S3側にもイベントを追加するために、追加したいイベントJSONを作成する。
LambdaFunctionのARN(「下記「999999999999」の個所」)を指定し、 Id には任意の文字列を指定し、Events 内にイベントのタイミング ((下記例ではObjectが作成された時)を設定する。
[root@Linux aws]# cat event.json { "LambdaFunctionConfigurations": [ { "LambdaFunctionArn": "arn:aws:lambda:us-east-1:999999999999:function:hello_function", "Id": "lambda-hello", "Events": [ "s3:ObjectCreated:*" ] } ] } [root@Linux aws]#
以下を実行してS3の対象バケットにイベントを設定。
[root@Linux aws]# aws s3api put-bucket-notification-configuration --bucket mylab-lambda-test --region us-east-1 --notification-configuration file://event.json [root@Linux aws]#
設定を確認。
[root@Linux aws]# aws s3api get-bucket-notification --bucket mylab-lambda-test --region us-east-1 { "CloudFunctionConfiguration": { "CloudFunction": "arn:aws:lambda:us-east-1:8888888888888:function:hello_function", "Events": [ "s3:ObjectCreated:*" ], "Id": "lambda-hello", "Event": "s3:ObjectCreated:*" } } [root@Linux aws]#
S3にファイルをアップロードし、イベントを発行する。
実際にS3にファイルをputする。
[root@Linux aws]# aws s3 cp event.json s3://mylab-lambda-test --region us-east-1 upload: ./event.json to s3://mylab-lambda-test/event.json [root@Linux aws]#
lambdaが実行されたことをログで確認する。
最初に確認した際は、ResourceNotFoundExceptionエラーが発生したため、
[root@Linux aws]# aws logs get-log-events --log-group-name "/aws/lambda/demo_func" --log-stream-name "2016/10/29/[$LATEST]f11d2581b1174061a6bcec5415008bdf" An error occurred (ResourceNotFoundException) when calling the GetLogEvents operation: The specified log group does not exist. [root@Linux aws]#
以下の記事を参考にして、--log-stream-name の引数を ' (シングルクォート) で囲んだうえで、 ログを確認し、ログが出力されていることを確認する。
[root@Linux aws]# aws logs get-log-events --log-group-name "/aws/lambda/hello_function" --log-stream-name '2016/10/29/[$LATEST]9d7808a222dc4c48b2520e66dc2c0d90' --region us-east-1 { "nextForwardToken": "f/32955208848878810726028768378655453483555694011301167109", "events": [ { "ingestionTime": 1477762546397, "timestamp": 1477762546380, "message": "2016-10-29T17:35:46.380Z\t1fab1ae4-9dfe-11e6-90e5-6d0b1489607e\tLoading function\n" }, { "ingestionTime": 1477762561482, "timestamp": 1477762546381, "message": "START RequestId: 1fab1ae4-9dfe-11e6-90e5-6d0b1489607e Version: $LATEST\n" }, { "ingestionTime": 1477762561482, "timestamp": 1477762546388, "message": "2016-10-29T17:35:46.388Z\t1fab1ae4-9dfe-11e6-90e5-6d0b1489607e\tvalue1 = undefined\n" }, { "ingestionTime": 1477762561482, "timestamp": 1477762546388, "message": "2016-10-29T17:35:46.388Z\t1fab1ae4-9dfe-11e6-90e5-6d0b1489607e\tvalue2 = undefined\n" }, { "ingestionTime": 1477762561482, "timestamp": 1477762546388, "message": "2016-10-29T17:35:46.388Z\t1fab1ae4-9dfe-11e6-90e5-6d0b1489607e\tvalue3 = undefined\n" }, { "ingestionTime": 1477762561482, "timestamp": 1477762546388, "message": "REPORT RequestId: 1fab1ae4-9dfe-11e6-90e5-6d0b1489607e\tDuration: 7.49 ms\tBilled Duration: 100 ms \tMemory Size: 128 MB\tMax Memory Used: 27 MB\t\n" } ], "nextBackwardToken": "b/32955206010752172289830483475910265610675480239467724800" } [root@Linux aws]#
最後に作成した設定を削除する。
lambda関連
[root@Linux aws]# aws lambda delete-function --function-name hello_function --region us-east-1
iam関連
[root@Linux aws]# aws iam detach-role-policy --role-name hello_exec_role --policy-arn "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess" [root@Linux aws]# aws iam delete-role --role-name hello_exec_role
s3関連
[root@Linux aws]# aws s3 rm s3://mylab-lambda-test --recursive --region us-east-1 delete: s3://mylab-lambda-test/event.json delete: s3://mylab-lambda-test/input.txt [root@Linux aws]# aws s3 rb s3://mylab-lambda-test --region us-east-1 remove_bucket: s3://mylab-lambda-test/ [root@Linux aws]#
WindowsServer2016(ServerCore)にリモートからPowershellで接続する。
下記で、インストールおよび初期設定したWindowsServer2016(ServerCore)にリモートからPowershellで接続する。
検証環境
検証環境は、下記の前提に基づく。
- Windows10にインストールされたHyper-vホストに仮想マシンを作成する。
- 作成した仮想マシンにWindowsServer2016 Technical Preview 5 をインストールする。
- インストール際は、ISOを利用し、新規インストールする。
- ServerCoreモードでインストールし、GUIはインストールしない。
- ServerCoreモードでインストール後は、極力Powershellで初期セットアップを行う。
※以降の手順は、検証のための手順のため、公式の手順などではないです。
やること
ここでは、以下の作業を実施する。
- Powerhshellからリモート接続できるように、WindowsServer2016(ServerCore)側の設定を行う。
- WindowsServer2016(ServerCore)に対して、Powershellでリモート接続できるように、クライアント側(接続する側)の設定を行う。
参考サイト
http://hensa40.cutegirl.jp/archives/677
Powerhshellからリモート接続できるようする。
WindowsServer2016(ServerCore)上で、以下を実施して、 リモートからPowershellで接続できるようにEnable-PSRemotingを実行する。
PS C:\Users\Administrator\Documents> Enable-PSRemoting
次に、まずは、ローカルホストに対してリモート接続できるか下記のコマンドで確認する。
PS C:\Users\Administrator\Documents>Enter-PSSession -ComputerName localhost
リモート側(接続する側)のホスト設定
WindowsServer2016(ServerCore)に対して、リモートでPowershellの接続を行うため、 リモート側(接続する側(ここでは、Hyper-vホストであるWindows10側))に接続先に 対するリモート接続設定を行う。
ここでは、WindowsServer2016(ServerCore)である「192.168.3.16」へ 「Administrator」で接続を下記コマンドで行う。
PS C:\WINDOWS\system32> Enter-PSSession -ComputerName 192.168.3.16 -Credential Administrator
コマンド実行後、Administratorのパスワードの入力を行うダイアログが表示されるので、 パスワードを入力する。入力が完了すると。。。
下記のようにリモート接続先(ここでは「192.168.3.16」)に接続され、 プロンプト表示も下記のように変わる。
[192.168.3.16]: PS C:\Users\Administrator\Documents>
【以下実行例】
WindowsServer2016(ServerCore)にPowershellで初期設定する。
下記で、インストールしたWindowsServer2016(ServerCore)に初期設定を行う。
インストールしたWindowsServer2016は、ServerCoreモードでインストールしたため、 DOSプロンプトから、Powershellを起動し、Powershellコマンドベースの初期設定を行う。
検証環境
検証環境は、下記の前提に基づく。
- Windows10にインストールされたHyper-vホストに仮想マシンを作成する。
- 作成した仮想マシンにWindowsServer2016 Technical Preview 5 をインストールする。
- インストール際は、ISOを利用し、新規インストールする。
- ServerCoreモードでインストールし、GUIはインストールしない。
- ServerCoreモードでインストール後は、極力Powershellで初期セットアップを行う。
※以降の手順は、検証のための手順のため、公式の手順などではないです。
やること
以下の作業をPowershellで実施する。
Powershellの起動
下記のとおり、DOSプロンプト上でPowershellを起動し、以降の作業を実施する。
C:\Users\Administrator>powershell Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS C:\Users\Administrator>
コンピュータ名の変更
Rename-Computerコマンドで、コンピュータ名を変更する。
PS C:\Users\Administrator> Rename-Computer wind2016 警告: 変更は、コンピューター WIN-2V3T40SPO6L の再起動後に有効になります。 PS C:\Users\Administrator>
IPアドレスの設定
まずは、Get-NetAdapterコマンドで、該当するインターフェースの番号を取得する。
PS C:\Users\Administrator> Get-NetAdapter Name InterfaceDescription ifIndex Status MacAddress LinkSpeed ---- -------------------- ------- ------ ---------- --------- イーサネット Microsoft Hyper-V Network Adapter 2 Up 00-15-5D-03-04-0E 100 Mbps
その後、New-NetIPAddressでIPアドレスを設定する。
PS C:\Users\Administrator> New-NetIPAddress -InterfaceIndex 2 -IPAddress "192.168.3.16" -AddressFamily IPv4 -PrefixLength 24 -DefaultGateway "192.168.3.1"
- 設定した主なオプションは下記のとおり。
- InterfaceIndex:前出で取得したインターフェースID
- IPAddress:設定するIPアドレス
- AddressFamily:IPアドレスのレベル(ここではIPv4)
- PrefixLength:サブネットマスク
- DefaultGateway:デフォルトゲートウェイ
IP v6の無効化
次に、IP v6を無効化する。 まずは、Get-NetAdapterbindingで現在のネットワークアダプタの設定一覧を表示する。
PS C:\Users\Administrator> Get-NetAdapterbinding
次に、Disable-NetAdapterBindingでIP v6を無効化する。
Disable-NetAdapterBinding -InterfaceAlias "イーサネット" -ComponentID ms_tcpip6
最後に、Get-NetAdapterbindingで現在のネットワークアダプタの設定一覧を改めて表示する。
PS C:\Users\Administrator> Get-NetAdapterbinding
【Disable-NetAdapterBinding実行例】
WindowsFirewallの無効化
セキュリティ的に推奨はされないが、一旦WindowsFirewallを無効化する。 まずは、下記で、一括無効化し、
PS C:\Users\Administrator> Get-NetFirewallProfile | Set-NetFirewallProfile -Enabled false
下記で、状態を確認する。
PS C:\Users\Administrator> Get-NetFirewallProfile Name : Domain Enabled : False DefaultInboundAction : NotConfigured DefaultOutboundAction : NotConfigured AllowInboundRules : NotConfigured AllowLocalFirewallRules : NotConfigured AllowLocalIPsecRules : NotConfigured AllowUserApps : NotConfigured AllowUserPorts : NotConfigured AllowUnicastResponseToMulticast : NotConfigured NotifyOnListen : False EnableStealthModeForIPsec : NotConfigured LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log LogMaxSizeKilobytes : 4096 LogAllowed : False LogBlocked : False LogIgnored : NotConfigured DisabledInterfaceAliases : {NotConfigured} Name : Private Enabled : False DefaultInboundAction : NotConfigured DefaultOutboundAction : NotConfigured AllowInboundRules : NotConfigured AllowLocalFirewallRules : NotConfigured AllowLocalIPsecRules : NotConfigured AllowUserApps : NotConfigured AllowUserPorts : NotConfigured AllowUnicastResponseToMulticast : NotConfigured NotifyOnListen : False EnableStealthModeForIPsec : NotConfigured LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log LogMaxSizeKilobytes : 4096 LogAllowed : False LogBlocked : False LogIgnored : NotConfigured DisabledInterfaceAliases : {NotConfigured} Name : Public Enabled : False DefaultInboundAction : NotConfigured DefaultOutboundAction : NotConfigured AllowInboundRules : NotConfigured AllowLocalFirewallRules : NotConfigured AllowLocalIPsecRules : NotConfigured AllowUserApps : NotConfigured AllowUserPorts : NotConfigured AllowUnicastResponseToMulticast : NotConfigured NotifyOnListen : False EnableStealthModeForIPsec : NotConfigured LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log LogMaxSizeKilobytes : 4096 LogAllowed : False LogBlocked : False LogIgnored : NotConfigured DisabledInterfaceAliases : {NotConfigured}
OSの再起動
最後に、OSを再起動し、これまでの設定を反映させる。
PS C:\Users\Administrator> Restart-Computer