技術一課の杉村です。2018/12に Amazon Redshift の AUTO VACUUM 機能がリリースされました。
https://aws.amazon.com/jp/about-aws/whats-new/2018/12/amazon-redshift-automatic-vacuum/
Redshift を利用されているお客様がこのリリースを見て、自動で VACUUM が走ることに対してパフォーマンス影響があるかを気にされたことがあり、そのときに調べた内容を遅まきながらもブログにしてみました。

ポイント

• 自動的に VACUUM DELETE が走る
• この機能はユーザによるロードやクエリを極力、邪魔しないようになっている
• 同時リリースで VACUUM 処理がテーブル全体でなく必要なテーブルの一部に実行されるようになった

AUTO VACUUM の仕様

Redshiftではその元となっているPostgreSQLがそうであるように、 UPDATE や DELETE でレコードが変更されても実際にそのデータはすぐに削除されるわけではなく、削除マークが付けられます。削除マークの付いた領域は VACUUM を実行することにより解放しなくては使用できません。RedshiftのVACUUMには FULL 、SORT ONLY 、DELETE ONLY 、REINDEX の4オプションがありますが、今回のアップデートで VACUUM DELETE が自動的に行われるようになりました。
※ちなみに Redshift における VACUUM コマンドのデフォルト動作は VACUUM FULL です。（ SORT + DELETE と同義 ）

VACUUM DELETE は先ほどのように削除マークのついた不要領域を再利用可能状態にする処理であり、またテーブルに対するロック取得もしないためユーザのパフォーマンス体験への影響は限定的といえます。
またユーザ操作（クエリや COPY コマンド等）とバッティングした際は VACUUM は一時停止して、負荷が無いときに再開する仕様になっています。

また今回のアップデートで VACUUM DELETE はテーブルの一部のみに実施されるようになり、かつてカラム数が数百を超える場合にエラーとなった Vacuum Column Limit Exceeded エラーは発生しなくなったようです。

AUTO VACUUM がいつ、どこで走ったか

AUTO VACUUM はバックグラウンドでいつの間にか走っているものなので、基本的に我々ユーザが意識することはありません。
しかし「いつ、どこで AUTO VACUUM が実行されたか」知りたいこともあるかもしれません。

CloudWatch のクラスター別メトリクスで AutoVacuumSpaceFreed というものがあります。
マネジメントコンソールの CloudWatch 画面からはもちろん、 Redshift のコンソールで クラスタ＞「クラスターのパフォーマンス」タブでもこのメトリクスの値を確認することができます。

システムテーブルの STL_VACUUM を確認することで VACUUM DELETE の発生時刻・終了時刻・対象のテーブルID等が確認できます。
リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_VACUUM.html

statusカラムに [VacuumBG] Started Delete Only や [VacuumBG] Finished 等とメッセージが記録されます。

なおテーブルIDとテーブル名の対応につきましては、 SVV_TABLE_INFO システムテーブル等で確認できます。
リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_SVV_TABLE_INFO.html

また他にも STL_QUERY システムテーブルで WHERE querytxt like ‘Vacuum: delete%’ のようにSELECTすることで、VACUUM処理が発行されたかどうかを確認することも可能です。
リファレンス: https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_QUERY.html

なおSTL_*と名の付くログテーブルには2～5日分のログ履歴のみを保持いたしますのでご注意いただき、必要な場合には定期的に他のテーブルにコピーするか、Amazon S3にアンロードいただくなどにてログデータの保存できます。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_intro_STL_tables.html

ディスク容量を管理するため、STL ログテーブルは、ログの使用状況と使用可能なディスク容量に応じて、およそ 2 ～ 5 日分のログ履歴のみを保持します。ログデータを保管するには、定期的に他のテーブルにコピーするか、Amazon S3 にアンロードする必要があります。

こんにちは、技術一課の加藤です。

先々週ごろにLambda上でAWSCLIを動かしてS3 Syncする – サーバーワークスエンジニアブログというブログを書きました。
この記事ではAWS CLIをローカルインストールしてPythonのコード上から呼び出すという実装をしています

ですがそもそもAWS CLIはCLIコマンドで呼び出すもの。Pythonからサブプロセスを切ってコマンドを叩くのはやや冗長な気がします。

ならbashから直接呼ぶ方が中間層がなくてスマートなのでは…？

ということで、カスタムランタイムを使ってbashから直接AWS CLIを呼び出してみることにしました。

前提

今回はカスタムランタイムでAWS CLIを動かすのが主題なので、処理はAQWS CLIのバージョン出力にとどめます。S3 Syncなどしたい場合は、 aws —version の箇所を任意のコードに変更してください。

またカスタムランタイム自体の説明については、公式をご覧ください。
カスタム AWS Lambda ランタイム – AWS Lambda
簡単に言えば、あらゆる言語をLambdaで動かせるよ、というものになります。

手順

AWS CLIをLayerにおき、ハンドラー関数から呼ぶ構成にします。

1. bootstrapファイルを作成
2. bootstrapファイルをLayerとして登録
3. ハンドラー関数を書いたfunction.shファイルを作成
4. Lambdaを作成

bootstrapファイルを作成

bootstrapファイルはカスタムランタイムのエントリポイントとなり、必ず用意する必要があるファイルになります。このファイルでAWS CLIのインストールとメイン関数の呼び出しを行います。

#!/bin/sh

# エラー停止の設定
set -euo pipefail
# tmpフォルダ内にawscliを配置するためHOMEとPATHを設定
export HOME="/tmp"
export PATH="$HOME/.local/bin:$PATH"

# pipをインストール
cd /tmp
curl -sSL https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python get-pip.py --user
# pipを用いてawscliをインストール
pip install awscli --user

# ハンドラー関数を読み込み
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"

# ループ処理
while true
do
  HEADERS="$(mktemp)"
  # イベントを取得
  EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
    # リクエストIDを取得
  REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)

  # ハンドラー関数を実行
  RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")

  # レスポンスを返す
  curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done

bootstrapファイルをLayerとして登録

作成したbootstrapファイルをLayerとして登録します。以下はbashのコマンドになります。

$ chmod 755 bootstrap
$ zip awscli.zip bootstrap
$ aws lambda publish-layer-version --layer-name awscli --zip-file fileb://awscli.zip

ハンドラー関数を書いたfunction.shファイルを作成

次に実際にAWS CLIを使って処理を行うハンドラー関数を作成します。
先述の通り今回はバージョン出力のみを行いますが、実際にはS3 Syncなど行いたい処理をここに書いていくことになります。

function handler () {
    # aws --versionの結果をRESPONSEに格納
  RESPONSE=$(aws --version 2>&1)
  echo $RESPONSE
}

Lambdaを作成

ハンドラー関数を作ったので、Lambdaをデプロイしてみます。
Lambdaの実行用ロールを用意しておいてください。

$ chmod 755 function.zip
$ zip function.zip function.zip
$ aws lambda create-function --function-name lambda-cli \
  --handler function.handler \
  --runtime provided \
  --role <RoleArn> \
  --zip-file fileb://function.zip \
  --layers arn:aws:lambda:ap-northeast-1:<AWSAccountID>:layer:awscli:1

では実行してみます。

$ aws lambda invoke --function-name lambda-cli response.txt
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
$ cat response.txt
aws-cli/1.16.144 Python/2.7.12 Linux/4.14.88-90.76.amzn2.x86_64 botocore/1.12.134

無事、aws cliのバージョンを取得することができました。
他のメソッドも試して遊んでみてください。

AWS コマンドラインインターフェイス

おわりに

前回に引き続き、Lambda上でAWS CLIを呼ぶというややアクロバティックな実装をご紹介しました。

利用場面はかなり限られるとは思いますし、本番稼働するシステムに組み込むのはやや微妙な気がします。
とはいえやってできないものではないことがわかりましたので、もし必要になった場合は参考にしてみてください。

こんにちは、技術3課の城です。
EC2で構築したLinux ServerへのSSHログインの方法について紹介します。
私はWindowsユーザーなので、Windows端末の環境用となります。

必要なもの

• SSHクライアント
  今回はTeratermを利用します。
  下記プロジェクトサイトのダウンロードリンクからインストーラーをダウンロード、実行してインストールします。
  https://ja.osdn.net/projects/ttssh2/

• EC2インスタンスを構築した時に設定したキーペアの秘密鍵([キーペア名].pem)

今回はこちらのEC2インスタンスにログインしてみます。

SSH接続

ホストとサービスの指定

Teratermを起動し、必要情報を記入します。
ホスト欄にIPアドレスを記載、サービスはSSHを選択し、[OK]をクリックします。

known hostsリストへの追加

初回接続時は下記セキュリティ警告が出ますが、[続行]をクリックしてknown hostsリストへ追加します。
※SSHクライアントがサーバーが正しいかどうかを鍵指紋（FingerPrint）による照合を行っていますが、初回でサーバーの登録がないための警告になります。

認証情報の入力

下記認証情報を入力し、[OK]をクリックします。

• ユーザー名
  • 今回はAmazonLinux2のデフォルトユーザーであるec2-userを指定しています。
• RSA/DSA/ECDSA/ED25519鍵を使うにチェック
  • [秘密鍵]をクリックし、キーペアの秘密鍵を選択します。

接続完了

接続できました。

最後に

Linux ServerへのSSHログインの方法について紹介しました。
どなたかの助けになれば幸いです。

こんにちは、技術3課の城です。
初めてAWSでWindows Serverを構築した際にリモートデスクトップのパスワードをどのように取得するか、疑問に思った方は多いのではないでしょうか。
今回はその方法について、紹介いたします。

ログインまでの流れ

おおまかな流れとしては下記となります。
①EC2インスタンス構築
②パスワードの取得
③リモートデスクトップ接続
今回は②にフォーカスして説明します。

必要なもの

EC2インスタンスを構築した時に設定したキーペアの秘密鍵([キーペア名].pem)が必要です。

パスワードの取得

デフォルトのWindows管理者パスワードの取得画面への移行

パスワードを取得したいEC2インスタンスを選択し、[アクション]⇒[Windows パスワードの取得] とクリックします。

秘密鍵の指定

[参照] を選択し、キーペアの秘密鍵を選択して、[開く]をクリックします。
すると、画像の赤枠の欄にキーペアの内容が入力されます。
※またはテキストボックスに、直接、秘密鍵の内容を貼り付けます。

パスワードの復号

パスワードの復号をクリックします。

プライベートIP、ユーザー名、パスワードの情報が表示されます。

こちらの情報を利用してリモートデスクトップ接続を行い、ログインすることが可能です。

最後に

今回は初歩的な内容ですが、意外とつまづきがちなポイントについて紹介しました。
どなたかの助けになれば幸いです。

【参考情報】
https://aws.amazon.com/jp/premiumsupport/knowledge-center/retrieve-windows-admin-password/

はじめに

10連休、皆様どのように過ごされましたでしょうか。子供のときには夏休みの自由研究は億劫でしたが、大人になると時間が取れる時に、普段やらないことに取り組みたくなるものです。
そこで今回、社内で運用されている「さばチップ」の使われ具合をネットワーク構造で可視化してみました。

さばチップについて

さばチップとは、社員同士で感謝の気持ちと合わせて少額の成果給を送り合うシステムです。仕組みとしては、Unipos(ユニポス)というサービスを利用しています。
例えば、以下のように誰かに感謝のメッセージとポイントを送ることができます。

さばチップについては、以下のブログで詳しく紹介されていますので、ご参照ください。
感謝を伝える仕組みを作る。ピアボーナス「さばチップ」プロジェクトとは？

さばチップの運用状況

さて、ネットワークで可視化する前にさばチップがどのくらい社内で使われているか確認してみます。
さばチップは2018年の10月から運用されていますので、今月で約半年少し運用されています。

さばチップが実際にどのくらい使用されているのかグラフ化してみました。

青の棒グラフ（値は左軸）が月ごとのチップ（投稿）数、オレンジの折れ線グラフ（値は右軸）が月ごとにチップを送ったユーザー数です。
チップ数については、最初の2ヶ月は他の月より多かったようですが、ユーザー数は同じくらいの数を推移しています。
サーバーワークスの社員数は以下のページによると140名くらいのようですので、毎月8割～9割の社員は使っているようです。

数字で見るサーバーワークス

こういった仕組みは最初の数ヶ月だけ盛り上がってあとはだんだん使われなくなる傾向もあるように思いますが、サービスの使いやすさ（Slack連携も充実）や運用メンバの努力等も手伝って、継続的に利用されているようです。

ネットワーク可視化してみた

さばチップの送った・受け取ったはタイムラインとして一覧では確認できますが、誰が誰にどのくらい送ったのかを、全体として俯瞰してみるのは難しい状況と思います。そこで、さばチップを誰が誰に送ったか、ネットワーク構造で可視化してみることにしました。
可視化ツールには vis.js を用いました。
これまでのすべてのチップの可視化は数が多すぎて描画的にほぼ不可能だったので、期間を切って実施してみます。

1週間分

2019年4月1日~5日の1週間分をネットワーク可視化してみると以下のようになりました。

いろいろな部署やプロジェクトでチップを送り合っているはずですので、いくつも「島」ができています。
がやはり、その週や人によってチップの送り具合、受け取り具合には傾向があるようで、例えば、この方の場合は、色々な人にチップを送りまくっているため、かなりマメでストイックな筋肉性格とわかります。

また、この方の場合は、色々な方からチップを受け取っているため、様々なプロジェクトで活躍されて感謝されたのかなと思います。

1ヶ月分

試しに4月の1ヶ月分を可視化してみると以下のようになりました。

もはや複雑すぎてよく分かりませんね。

おわりに

さばチップの運用状況をネットワーク構造で可視化してみました。
やはりひと目でわかるような形で可視化するとどの程度使われているのか、わかりますい気がしますね。

ところで、サーバーワークスでは、AWSの運用自動化のサービスとしてCloud Automatorを提供しております、ハンズオンレクチャーを定期開催しております。
こちらもご興味があればご確認頂ければ幸いです（直近では6月25日に開催予定です！）。

こんにちは。3月より技術二課となった伊藤Kです。

最近、こんなインタビューに答えました。
オンプレのインフラエンジニアだった私が、クラウド専業の会社に転職した理由。

タイアップを狙ったわけではないですが、しばらく、
「オンプレのインフラエンジニアだった私が、EC2のWindowsでひっかかったポイント」
がテーマとなる記事を書いていく予定です。
本日は第一弾「Sysprep」について。

EC2のSysprep

え、Sysprepでしょ。Windowsメインのエンジニアなら常識だよね。
「C:\Windows\System32\sysprep」フォルダの「Sysprep.exe」を実行するよね。
オプションは、「/generalize、/shutdown、/oobe」をつけとけばいいでしょ。
そんなふうに考えていた時期が俺にもありました・・・。

EC2のSysprepは専用のサービス（サービスと言いつつツールに近い）「EC2Config」もしくは「EC2Launch」を使用します。
Windows Server 2012 R2 以前のバージョンのOSは「EC2Config」、
Windows Server 2016 以降のバージョンのOSは「EC2Launch」となります。
この記事では、両方の手順を見ていきます。

「EC2Config」によるSysprep

まずは、「EC2Config」によるSysprepです。図のOSはWindows Server 2012 R2です。

OSのスタートメニューのアプリケーション一覧より、「EC2ConfigService Settings」を選択します。

「Image」タブを選択します。

Sysprep後に、「Administrator」ユーザーに割り当たるパスワードのオプションを選択します。
・Random：ランダムなパスワードが割り当てられ、マネジメントコンソールより確認できます。
・Specify：右の入力エリアで入力したパスワードが割り当たります。
・Keep Existing：既に設定されているパスワードをそのまま割り当てます。（が、直後に記載されている「Note」に書かれているように、「Windows Server 2008」以降のOSでは効果がなく、既に設定されているパスワードが消されてしまうため、ほぼ使えません）

というわけで、「Specify」を選択し、右の入力エリアへ新しいパスワードを入力します。

[Shutdown with Sysprep] を選択します。

確認のメッセージが出るので、 [はい] をクリックします。

Sysprepが開始され、自動的にOSシャットダウンします。ここまでくると、オンプレエンジニアにも見慣れたダイアログです。

「EC2Launch」によるSysprep

次に、「EC2Launch」によるSysprepです。図のOSはWindows Server 2016です。

OSのスタートメニューのアプリケーション一覧より、「Ec2LaunchSettings」を選択します。

今度は「General」タブしかありませんね。

設定する項目は「EC2Config」と同じです。「Administrator Password」欄で、
Sysprep後、「Administrator」ユーザーに割り当たるパスワードのオプションを選択します。
・Random：ランダムなパスワードが割り当てられ、マネジメントコンソールより確認できます。
・Specify：右の入力エリアで入力したパスワードが割り当たります。
・Do Nothing：unattend.xml ファイルでパスワードを指定します。unattend.xml でパスワードを指定しない場合、管理者アカウントは無効になります。

図では、「Do Nothing」を選択していますが、別途unattend.xmlをつかう用途がない場合は、SpecifyもしくはRandomが分かりやすいです。

画面一番下の、[Shutdown with Sysprep] を選択します。

Sysprep用Scriptの場所と応答ファイルの場所が表示されます。[Yes]をクリックします。

余談ですが、「EC2Launch」によるSysprepは内部的にPowerShellスクリプトが実行されることで実現されるのですが、それが上記ダイアログから見て取れます。また、応答ファイルを編集して、カスタマイズされたSysprepを実行する場合は、上記パスより対象ファイルが分かります。

参考までに、Unattend.xmlのパスはこちら
C:\ProgramData\Amazon\EC2-Windows\Launch\Sysprep\Unattend.xml

同じく見慣れたダイアログが表示されます。Sysprepが開始されており、自動的にOSシャットダウンします。

その後（共通）

「EC2Config」、「EC2Launch」どちらの手順も実行後はインスタンスが「Sysprep済み、シャットダウン」の状態となるので、
あとは、一般的な使い方としてはシャットダウンされたインスタンスのAMIをそのまま取って、そこからローンチすることで、Sysprep後の状態のマシンを起動して使用します。

おわりに

密かに「令和」投稿第1号を狙ってましたが、さすがはサーバーワークス、しれっと先をこされました。「令和」投稿第3号ぐらいになりそうです。

AWSにおけるInfrastructure as Codeツールと聞いて皆さんは何を思い浮かべるでしょうか？
多くの方はCloudFormationもしくはTerraformあたりを想像するのではないかと思います。

しかし！実は昨年、Pulumiという第三の選択肢がリリースされていました。
このツール、ずっと気になってはいたのですが、GW中にようやく試すことができたのでご紹介します。
何かがきっかけで人気急騰するポテンシャルを秘めたツールだと個人的には思っています。

ツールの概要

Pulumiの特筆すべきところは何と言っても
プログラミング言語で展開リソースの定義を実施できる
ことです。

CloudFormationもTerraformも、実態としてはInfrastructure as Yaml(or JSON）だったわけですが
このツールは正真正銘のInfrastructure as Codeであると言えます。
現在正式に利用ドキュメントが展開されている言語はNode.jsとPythonの2種です。

具体的にどう定義を実施するかというと、展開したい各AWSリソースをインスタンスとしてプログラムファイル内に定義・羅列していくこととなります。
以下はPythonでVPC1つとSubnet1つを定義した例です。このような内容が記されたプログラムファイルをpulumi独自のCLIコマンドで
読み込ませることでリソースを展開することができます。

import pulumi
from pulumi_aws import ec2

vpc = ec2.Vpc('vpc-sample',
    cidr_block='10.0.0.0/16',
    enable_dns_hostnames=True,
    enable_dns_support=True,
    tags={
        'Name': 'vpc-sample',
        'Owner': 'Serverworks'
    }
)

subnet_a = ec2.Subnet('subnet-sample-a',
    availability_zone='ap-northeast-1a',
    cidr_block='10.0.0.0/24',
    vpc_id=vpc.id,
    tags={
        'Name': 'subnet-sample-a',
        'Owner': 'Serverworks'
    }
)

リソースの定義方法についての若干の補足

リソースの定義について上記の例を用いて若干補足しておきましょう。
各インススタンスの第一引数にリソースの固有名称を記した後、
第二引数以降に各AWSリソースに設定するパラメータを記していく形となります。
リソース間の値参照については、Ref・GetAtt関数のような小難しいものを使わずに
上記例の17行目のように{インスタンス}.{属性値}で直感的に参照できるのが地味に嬉しいですね。

Pulumiを用いて生成できるAWSリソース・設定できるパラメータは以下に記述されています。

• Node.jsのリファレンス
• Pythonのリファレンス：
  • 2019年5月8日現在ではPythonドキュメントの記述はそこそこ雑目です。説明が不丁寧な箇所は該当箇所のNode.jsドキュメントを参照するとよいと思われます

追々もっと勉強して正確な差異を把握したいと思いますが、数時間触った限りの印象としては
Terraformのカバー範囲はPulumiのカバー範囲に限りなく近しい（ひょっとしたら同じ？）のように見受けられました。

CloudFormationでカバーしていて、Pulumi・Terraformでカバーできていないリソースというのも当然ながら存在するのですが
以下のような書き方（CloudFormationのStackをPulumi内で定義して更にそのStack内で未対応リソースの定義を書く。Terraformでも使える技ですね）で
実質的には対応できることも確認しました。

import pulumi
from pulumi_aws import cloudformation

ws_cfn_stack = cloudformation.Stack('sample-workspaces-stack',
    name='sample-workspaces',
    template_body="""
        Description: Create WorkSpaces for Pulumi Blog
        Resources:
            ServerworksWorkSpaces:
                Type: "AWS::WorkSpaces::Workspace"
                Properties:
                    BundleId: wsb-xxxxxxxxx
                    DirectoryId: d-xxxxxxxxxx
                    RootVolumeEncryptionEnabled: False
                    Tags:
                        - Key: Name
                          Value: serverworks-workspaces
                        - Key: Owner
                          Value: serverworks
                    UserName: tasai
                    WorkspaceProperties:
                        RunningMode: AUTO_STOP
                        RunningModeAutoStopTimeoutInMinutes: 60
"""
)

また、詳細な紹介は他日に譲りますが、依存関係の定義や削除保護・外部ファイルの参照等
今までの既存ツールで提供していた機能の多くはPulumiでも実現することができます。

導入〜リソース作成までの一連の流れ

次に、せっかくですのでPulumiの導入からリソース作成までの具体的な流れを紹介しようと思います。

Pulumiアカウントのサインアップ・セットアップ

Pulumiの公式サイトにアクセスします。

任意のサインアップ手段を選択します。

上記はメールでのサインアップの場合に表示される画面です。

サインアップ・ログインしたのちの画面で表示される[NEW PROJECT]を押下します。

cloudは[AWS]を、laungageについては任意のプログラミング言語（今回はPythonを前提とした手順とします）を選択して、[NEXT]を押下します。

上記の項目をそれぞれ任意で作成して[CREATE PROJECT]を押下します。

Pulumiトークンの発行

セットアップ作業完了後に上記のような画面に遷移するはずですので、ここから赤枠のユーザー名箇所をクリックする等してユーザのホーム画面に移動します
（https://app.pulumi.com/{ユーザー名}でホーム画面に移動できます）

ホーム画面の[SETTINGS]を、次いで左メニューの[Access Tokens]を、さらに[NEW ACCESS TOKEN]を押下します。

Tokenの概要・用途として適切な説明書きを入力した後に[CREATE]を押下します。

上記の赤枠の部分にTokenが表示されますのでコピーして控えておきます。

Pulumiミドルウェアのインストール

pulumi用のファイルをダウンロード&展開したのちに、適切なPATHを追加してpulumiコマンドを利用可能な状態とします。
公式の導入案内も併せてご確認ください。
本手順以降の手順はLinux環境（Local PCでAmazon Linux2をDockerで起動させた環境）での手順となります。

実行環境側でのPulumiプロジェクトの設定

export PULUMI_ACCESS_TOKEN={手順「Pulumiトークンの発行」にて発行したトークン}にて環境変数としてトークンを設定しておきます。
その後に上記のようにpulumi newコマンドにて先ほど作成したスタックを指定して指定のディレクトリにpulumiのプロジェクトを展開します。

また、上記で表示されている1~4の手順について、2~3の実施（virtualenvの設定）は任意ですが
4については実施します（python用プロジェクトではpulumi newコマンド実施時にrequirements.txtが生成されますがそこに記載されているミドルウェアをインストールする必要があります）。
なお、PulumiによるAWSリソース作成を実行するにはPython3が必要となることに留意してください。

【参考】事前にTokenを環境変数として設定しなかった場合

Token用環境変数を設定しない状況下で、pulumi newコマンドを入力すると上記のように表示されます。
この状況下でEnterを押すと、Pulumiの実行環境にてブラウザが展開されてPulumiサイトにアクセスしてTokenを自動取得できます。
今回の手順では便宜上ブラウザでの手動Token取得をご案内しましたが、ご自身のPC端末へのPulumi導入に関してはCLIベースで行ってしまった方が楽かもしれません。

Pulumiの実行

pulumiのプロジェクトを展開したディレクトリにて、__main__.pyというpythonファイルが保存されていますので
そのファイルを編集してAWS上に展開したいリソースを定義します（今回は冒頭でご紹介した1VPC・1サブネットを展開する
ごく簡単な定義内容をそのまま用います）

その後、pulumi upコマンドを実行します。すると、生成されるリソースについて上記のように照会されますので
問題がなければyesにカーソルを合わせてEnterを押下します。

その後、リソース作成が完了すると上記のように表示されます。

無事、リソースが作成されていることがわかります。
リソースを削除したい場合はpulumi destroyコマンドを実行すればOKです。

また、Pulumiの管理コンソールを見てみますと、上記のように実行履歴を確認できる他

現在Pulumiによって展開されているリソースがあれば、その一覧を確認することもできます。
サービスカテゴリごとにソートも行えるようです。今回はごくごく少量のリソース作成ですが、大量のリソース管理時には便利そうです。
このようにPulumi管理コンソールの使い勝手もなかなか悪くなさそうです。

最後に

新たなInfrastructure as Codeツール候補であるPulumiの概要を紹介しました。
いかにも便利で楽しげなツールなので隙をみてゴリゴリ試して続報を書けるといいなと思います。

Amazon Linux 2では標準のリポジトリにもamazon-linux-extrasにもslコマンドがなくインストールできません

こちらを参考にEPELリポジトリを有効にしてインストールすればOKです。

これでAmazon Linux 2でもslを走らせられます！！！！！！

$ sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ sudo yum install -y sl
$ sl

新しいSQSトリガーのリリースについて

Cloud Automator ではトリガーの一つとしてSQSトリガーを提供しており、運用ジョブの外部システムとの連携や数珠つなぎ等が簡易になり、多くのお客さまにご利用頂いております。

従来のSQSトリガーの課題

しかしながら、従来のSQSトリガーでは以下のような制限がありました。

• SQSキューにメッセージを送信してから実行されるまで最大2分程度要することがある
• 複数の運用ジョブで同一のSQSキューが設定されていると、キューにメッセージが入った場合、実行される運用ジョブはランダムとなる

新しいSQSトリガーについて

上記制限等を解消するため、今回新しいSQSトリガーをリリースいたします。
新しいSQSトリガーでは既存のSQSトリガーと比べ以下のようなメリットがございます。

• キューにメッセージを送信されてから、運用ジョブの実行は即時となる
• 複数の運用ジョブが同一のSQSキューを参照した場合、全ての運用ジョブが実行される

新しいSQSトリガーの詳細についてはこちらのマニュアルもご参照ください。
新しいSQSトリガーにおいては、以下の制限事項がございますため、ご注意ください。

• SQSのキューが標準キューであること
• キューの可視性タイムアウトが30秒以上となっていること

新しいSQSトリガーのご利用方法

新しいSQSトリガーは本日よりどなたでもご利用可能です。
Cloud Automatorのダッシュボード上ではトリガーの選択画面で「SQSトリガー」をご指定ください。

Cloud AutomatorのAPIでは rule_type に sqs_v2 をご指定ください。

### 新しいSQSトリガーのご利用に必要な権限
新しいSQSトリガーのご利用にあたり、従来のSQSトリガーでは必要なかった以下の権限が必要となります。
Cloud Automatorに登録しているAWSアカウント (IAM) に付与されていない場合は、付与頂きますようお願いいたします。

"sqs:AddPermission"
"sqs:RemovePermission"

新しいSQSトリガーに必要な権限の追加設定方法

以下ではサーバーワークスのpieCeをご利用のお客さまの環境を例に設定方法を説明いたします。ただし、環境内容が異なる場合もございますため、適宜読み替えて頂ますようお願いいたします。

AWSマネジメントコンソールにログインし、IAMのページから、Cloud Automatorに登録しているAWSアカウント（IAMユーザー）を選択します。今回の例では「cloudautomator」です。

選択したユーザーの中でSQS関連のポリシーを設定しているポリシーを選択します。今回の例では「caSQS」です。

「ポリシーの編集」を選択します。

ポリシードキュメントに以下2つのポリシーを追加し、「ポリシーの適用」を選択します。

"sqs:AddPermission"
"sqs:RemovePermission"

従来のSQSトリガーの今後の扱いについて

新規ジョブ作成について

従来のSQSトリガーは今後非推奨となりますため、今後新規作成されるジョブは基本的に新しいSQSトリガー（ダッシュボード表記上は「SQSトリガー」）をご利用頂ますようお願いいたします。
従来のSQSトリガーのCloud Automatorのダッシュボード上の表記は以下のように「旧SQSトリガー (非推奨)」となりますので、ご注意ください。

今年度9月末で従来のSQSトリガーを用いたジョブは作成できなくなりますので、ご注意ください。

既存のジョブの移行について

今年度9月末までに移行されなかった従来のSQSトリガーのジョブは、自動で新しいSQSトリガーに移行されますのでご注意ください。
その際、上記ご案内した新しいSQSトリガーの利用に必要な権限がAWSアカウントに付与されていない場合、ジョブの状態が停止となってしまいますため、ご注意ください。

手動での移行方法は以下手順を参照ください。

トリガーの移行方法

従来のSQSトリガーを用いているジョブのジョブ詳細画面を表示すると以下のような画面が表示されます。
赤枠で示している「新SQSトリガーに変更」ボタンを押下すると、新SQSトリガーに変更されます。

正常に変更が完了すると以下のメッセージが表示されます

おわりに

今後のリリース計画については、ロードマップページにて公開しております。
これからもCloud Automatorをよろしくお願いいたします。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

はじめに

　こんにちは、サーバーワークスのこけしの人、坂本（@t_sakam）です。ブログを書くまでがAlexa Day。…のはずでしたが、あっという間に1ヶ月が過ぎてしまいました。
　今回のAlexa Dayではパネルディスカッションに登壇させていただいたのですが、やっぱりAlexaは話がいがあるというか、話すことが尽きなくて楽しかったです！
※実際のパネルディスカッションの様子は、CNETさんのAlexa Dayの記事で触れていただいていたので（記事の下の方）、よろしければ記事の方もご確認くださいませ！

　ということで、Alexa Dayから1ヶ月が過ぎ、令和もスタートしてしまったので今回は当日の感想ではなく「Alexa Dayのおさらいをしてみる」というコンセプトでブログを書いてみたいと思います。Alexa Dayでは役に立つ情報がいっぱいあったので、聞いてきた便利なスキルの開発環境などを実際に試してみて、ブログにしていきたい（連載にしたい）と思います。

CodeStarとCloud9で楽々スキル開発

　今回おさらいしてみる内容は、今回のAlexa Dayの主催者であり、Alexaチャンピオンの伊東さんのセッションの中から！ セッションの中のCodeStarでCloud9を使って開発するのが、めっちゃ便利！というお話が気になっていたので、わたしもAWS CodeStarとAWS Cloud9を使ってAlexaスキルを作ってみたいと思います。
※結論を言ってしまうと、AmazonとAWSのサービスだけを使って、すべての作業をブラウザの中だけでおこなえてしまうので、ほんとに便利でした！

手順

1. CodeStarでプロジェクトを開始する

　まずは、AWSのマネジメントコンソールでCodeStarを選択し「プロジェクトを開始する」ボタンを押して次に進みます。
※2019年4月9日にCloud9が東京リージョンで使えるようになったというニュースがあったのですが、CodeStarの画面からはCloud9の選択がまだできなかったので、今回はバージニアリージョンで作業しています。

2. プロジェクトのテンプレートを選択

　画面左メニューの中の「Alexaスキル」にチェックを入れます。言語はNode.jsかPythonを選べます。いままではPythonを使っていたのですが、今回はNode.jsを選んでみました。

3. プロジェクトの詳細

　プロジェクト名を「hello-kokeshi」にして、画面下の「Amazon開発者アカウントに接続する」ボタンを押します。
※Amazon開発者アカウント=Amazon Developer Serviceのことです。いままではAWSとは別々にログインしていましたが、ここでAWSの方と繋げますね！

4. Amazon Developer Serviceに接続

　ログイン画面が表示されるので、Amazon Developer Serviceのメールアドレスとパスワードを入力します。

　接続できたら「次へ」ボタンを押します。

5. プロジェクトの詳細の確認

　そのまま変更を加えず「プロジェクトを作成する」ボタンを押します。

6. コードの編集方法の選択

　「AWS Cloud9」を選択して「続行」ボタンを押します。

7. AWS Cloud9環境のセットアップ

　今回は推奨インスタンスタイプの中からt2.smallを選択してみました。選択したら「次へ」ボタンを押します。

8. プロジェクトのセットアップ

　プロジェクトのセットアップが開始されます。少しだけ時間がかかるので待ちます。

　セットアップが完了すると「成功！ プロジェクトとIDEはセットアップされ、使用を開始できるようになりました。」というメッセージが表示されます。

9. できあがった環境の確認

1. EC2

　それでは、できあがった環境を確認してみたいと思います。まずは、EC2です。

　先程選択したt2.smallでできています。

2. Lambda

　Lambdaファンクションもできています。

3. スキル

　Amazon Developer Serviceのスキルも「英語（米国）」用ですが、できています。

「ビルド」タブ画面

「公開」タブ画面

　いまは空になっているアイコンをこのあとの手順で変更してこけしのアイコンになるようにしたいと思います。

こけしアイコン（小さなスキルアイコンと大きなスキルアイコン）

10. 「hello node」スキルは完了

　テンプレートのままの英語の「hello node」スキルを作るのみであれば、これだけの手順でスキル作成は完了です。

11. 日本向けにカスタマイズ

　これまでの手順ででできあがった「hello node」スキルにCloud9上で変更を加えて、日本向けにカスタマイズしていきたいと思います。
※今回の手順は「hello node」スキルを日本向けにして「ハローこけし」スキルにするのみの手順ですが、まったく違うスキルを作るときも、まず「hello node」を作ってからカスタマイズする、という手順は同じです。

1. Cloud9を開始する

　CodeStarの画面上の「コーディングを開始」ボタンを押すとCloud9の画面が表示されます。

　画面が表示されるまで少し待ちます。

　表示されました。

2. 「en-US.json」ファイル

　Cloud9の画面左に構造のツリーが表示されます。その中から「en-US.json」ファイルを探して「ja-JP.json」に変更し、中身も日本語に変更します。

デフォルトの英語の状態

日本語に変更したところ

3. 「skill.json」ファイル

　次は「skill.json」ファイルの中身を編集します。このファイルでスキルの設定まわりが変更できます。元の「skill.json」ファイルでは設定されていませんが、今回は完成後にキャプチャで変化がわかるように、スキルのアイコンを設定しておきます。

デフォルトの英語の状態

一部日本語に変更して、こけしのアイコンを設定したところ

4. 「index.js」ファイル

　次は「index.js」ファイルです。こちらも発話の箇所を日本語に変更していきます。

デフォルトの英語の状態

日本語に変更したところ

5. デプロイ

　最後に画面下のコンソールからデプロイします。

git add .
git status
git commit -m "日本語化しました。"
git push

6. 確認

　CodeStarの画面からデプロイ中であることが確認できます。

　上の画面のデプロイ状況が「成功」になれば、完了です。スキルの方の画面を確認してみます。
　さきほど設定したこけしのアイコンがきちんと表示され、スキル名も「ハローこけし」になり、言語も日本語になっていることが確認できました。

7. テスト

　「テスト」タブから簡単な動作確認テストをしてみます。問題なく動くことが確認できました。

「ビルド」タブ画面

「公開」タブ画面

　小さなスキルアイコンも大きなスキルアイコンも両方問題なく設定されています。

　これで完成です。
　

まとめ

　今回は、AWS CodeStarとAWS Cloud9を使ってAlexaスキルを作ってみました！ ブラウザの中だけですべての作業がおこなえるので本当に便利ですよね！

　いや〜、「CodeStar」と「Cloud9」って本当にいいものですね！
　

おまけ

　Alexa Dayの次の日に、たまたま関西方面で「コトコト こけし博 2019」が開催されていたので、行ってきました！
　「コトコトこけし博」は毎年京都で開催されているので、行ったことがなかったのですが（普段は東京のため）、Alexa Dayが神戸で開催されるおかげで行くことができました〜！

今回のアイコンにも使っている「コトコトこけし博」で仕入れたこけし達

　いや〜、「Alexa Day」って本当にいいものですね！

こんにちは、技術一課の加藤です。
今日はAWSのお話を離れ、ちょっとした効率化のお話を。

VPNをONにするのめんどくさい問題

PCからVPNを介してサーバーなどにアクセスを行いたい場面はよくあると思います。
その時、いちいちVPNの設定を開いてConnect/Disconnectを切り替えるのがめんどくさかったんですよね。

SSHをするときにVPNをONにすることが多かったため、ならTerminalからVPNをONにできればいいのでは…？ と思いついたのが始まり。
それ用のシェルスクリプトを書いてみました。

そもそもコマンドでVPNをONにするには

MacにはデフォルトでVPN設定を切り替えできるコマンドが用意されています。

$ scutil --nc start [name] # nameのVPNに接続
$ scutil --nc stop [name] # nameのVPNから切断
$ scutil --nc status [name] # nameのVPNへの接続状態を取得

※なお[name]にはVPNの設定名を書きます

とはいえいちいちこれを打つのもめんどくさいので、bash_profileへ設定を行い、簡単に呼び出せるようにしていきます。

1. エイリアスを貼る

一番簡単なのはエイリアスを貼ることでしょう。
.bash_profileに以下を追加します

alias vpnstart='scutil --nc start [name]'
alias vpnstop='scutil --nc stop [name]'
alias vpnstatus='scutil --nc status [name]'

これで

vpnstart

vpnstop

vpnstatus

2. コマンドを作る

aliasだと物足りない場合はコマンドを作成してしまいましょう。
私はこちらの方法を使いました。

.bash_profileに以下を書き込みます。（ユーザーまたぎで使いたい場合など汎用性を高めたい場合は専用のファイルを作るなど各自工夫をお願いします）

function vpn () {
  OPTIND=1
  if [ -n "$DEFAULT_VPN" ]; then
    local SERVICE="$DEFAULT_VPN"
  fi

  while getopts :n: OPT
  do
    case $OPT in
      "n") SERVICE=$OPTARG;;
      :) echo "[ERROR] option argument is undefined.";return 1;;
      \?) echo "[ERROR] Undefined options.";return 1;;
    esac
  done

  if [ -z "$SERVICE" ]; then
    echo "[ERROR] VPN name is undefined."
    return 1
  fi

  shift $(($OPTIND - 1))

  if [ "$1" = "start" ]; then
    scutil --nc start $SERVICE | head -n 1
    return 0
  fi

  if [ "$1" = "stop" ]; then
    scutil --nc stop $SERVICE | head -n 1
    return 0
  fi

  if [ -n "$1" ]; then
    echo "[ERROR] Invalid argument"
    return 1
  fi

  scutil --nc status $SERVICE | head -n 1
  return 0
}

今回はDEFAULT_VPNという環境変数にセットされた値か、-nオプションで与えた値のどちらかをVPNの設定名として利用します。
普段接続するVPNが決まっている場合は以下のコマンドで設定を.bash_profileに書き込んでください。

$ echo 'DEFAULT_VPN="VPN_NAME" >> ~/.bash_profile

使い方は以下になります。

$ vpn # DEFAULT_VPNの状態取得
$ vpn start # DEFAULT_VPNに接続
$ vpn stop # DEFAULT_VPNに接続

$ vpn -n VPN_NAME # VPN_NAMEの状態取得
$ vpn -n VPN_NAME start # VPN_NAMEに接続
$ vpn -n VPN_NAME stop # VPN_NAMEに接続

自分用途に作ったざっくり仕様なので、利用する際はご自身の責任でお願いします。

ちなみに

実は私、普段bashではなくfishを使っているため、上記のコマンドも実はブログ用にbashコマンドに書き起こしたものだったりします。

fish用のコマンドも下記にさらしておきますので、fish使いの人や、ちょっと気になっているという方はぜひご利用ください。（bashコマンドは急いで書き起こしたので、fishのコマンドと出力などにやや違いがありますがご了承ください。使い方は変わりません。）

function vpn
  argparse -n vpn 'n/name=' -- $argv
  set -l service

  # service name
  if set -lq _flag_name
    set service $_flag_name
  else if set -q DEFAULT_VPN
    set service $DEFAULT_VPN
  else
    echo "pls set \$DEFAULT_VPN or give -n/--name option"
    return 1
  end

  # start / stop
  set length (count $argv)
  if test $length -eq 0
    scutil --nc status $service | head -n 1
  else if contains "start" $argv
    networksetup -connectpppoeservice $service
    echo "connect: "$service
  else if contains "stop" $argv
    scutil --nc stop $service
    echo "disconnect: "$service
  else 
    echo "if you wanna connect/disconnect vpn, pls give start/stop"
    return 1
  end


  return 0
end

S3 + CloudFrontでwebページをホスティングして、バックはAPI Gateway + LambdaでSPAを作りたいってときにAPI GatewayでCORSを有効化する必要があります。

マネコンからですと、ポチポチしてデプロイが必要となり、複数メソッドがあるとそれぞれに設定しないといけず、ちょっとめんどくさいかも。

Serverless FramworkならAPI GatewayのCORS有効化もデプロイと一緒に行えます。

こう書く

こちらの公式ガイドを参考にしました。

以下はサンプルのserverless.ymlの内容です。必要に応じて別のymlファイルからIAMについて書いたり、設定値を読み込ませたりしてください。

service: sample
provider:
  name: aws
  runtime: python3.6
  region: ap-northeast-1
functions:
  sample:
    handler: lambda_handler.main
    events:
      - http:
          path: sample/post
          method: post
          cors: 
            origin: http://localhost:8080
            headers: 
              - Content-Type
              - X-Amz-Date
              - Authorization
              - X-Api-Key
              - X-Amz-Security-Token
              - X-Amz-User-Agent
            allowCredentials: true

説明すると、corsの下で、
originでオリジンを指定。
headersに許可するヘッダーを記載。
allowCredentialsは認証情報がある場合は必要です。なければ省いてください。

デプロイ

sls deployでデプロイした後、コンソールから確認してみます。

OPTIONSメソッドが作成されており、CORSが有効化されてるくさいです。

OPTIONSメソッドの統合レスポンスを確認してみます。

ヘッダーのマッピングが記載されているのが確認できます。

メソッドレスポンスを確認してみます。

レスポンスヘッダーが追加されているのが確認できます。

補足

CORSを有効化する場合、API Gatewayの設定だけでなく、Lambda側でもレスポンスヘッダーに Access-Control-Allow-Origin ・ Access-Control-Allow-Credential をつけてやる必要があります。

例）

response = {
    "statusCode": 200,
    "headers": {
        "Access-Control-Allow-Origin" : "http://localhost:8080",
        "Access-Control-Allow-Credentials": "true"
    },
    "body": "{...}"
}

return response

まとめ

いかがでしたでしょうか。Serverless Frameworkで簡単にCORS有効化ができました。あとは各自でS3にデプロイしたwebページからAPI叩いてみてください。

初めまして、先月より中途入社した技術3課の佐野です。
今回はCloudFrontのキャッシュ削除方法についてご紹介します。

CloudFrontのキャッシュ削除手順

まずはマネージドコンソールにアクセスし、CloudFrontのサービスページにアクセスし、
作成済みのCloudFrontディストリビューションのDistribution IDのリンクをクリックします。

次にInvalidationsタブをクリックし、Create Invalidationsボタンをクリック。

Object Path欄にキャッシュを削除したいオブジェクトを指定します。
すべてのオブジェクトのキャッシュを削除したい場合は /*を入力し、
特定のオブジェクトのキャッシュを削除したい場合、/example/example.htmlなど、対象のオブジェクトのパスを入力します。
入力が完了したら Invalidateをクリックしてください。

Invalidationsタブに画面が戻るので、StatusがIn ProgressからCompletedになれば、キャッシュ削除完了です！

キャッシュ削除の注意点

公式ドキュメントによると、CloudFrontキャッシュ削除（ファイル無効化）は1ヶ月のうち1000回まで無料となっており、これを超えると1つのパスにつき1件ごとに料金が発生します。
キャッシュ削除を自動化する場合は、頻度の設定にご注意ください。

「rootアカウントですら永久にオブジェクトを削除できなくなるような機能がS3に追加されたらしい・・・」

S3オブジェクトロック機能がローンチされた際ちらほらこんな噂が聞かれました。
こうした「rootですら削除できなくなる」「設定中は無期限で削除できなくなる」といった一部機能に関する話題が若干の誤解付きで広まってしまい使いづらい機能と決めつけている人がいかんせん多いように思います。

今回は３ステップに分けて、S3 オブジェクトロックは（ちゃんと使えば）怖くない、
割と使い道はあるということを皆さんにご理解いただくためにこのエントリーを書いてみました。

第１ステップ：オブジェクトロックは怖い機能でないことを理解する

オブジェクトロック機能は既存のS3バケットでは有効化できず、新規作成時に明示的に設定しないと利用することができません。
コンソールでの作成手順でいうと、名前とリージョンを入力した後の[オプションの設定]の段階の[詳細設定]にて設定することができるのですが、有効化しようとした際に表示されるのが下記の画面です。
おっかないですね。「完全に」という文言には圧迫感があり、作成直後にすぐさま削除不可となるような印象を受けます。

ただ、実際はそんなことはありません。
その後も設定を進めてバケットを作成し終えた後のオブジェクトロック設定は以下のような表示になっています。
オブジェクトのロックを設定しうる機能が「完全に有効化」されているだけで、実際にバケットのオブジェクトに対してどの程度の強度・期間でロックをかけるかは別問題。それらの設定は追々することになるということです。

なので機能の有効化自体はあまり身構えずに行っていただければと思います（もちろん、本番利用用のバケットで利用予定もないのにむやみやたらに有効化するのはやめましょう）

第２ステップ：主要機能の概要を理解する

それでは機能有効化後に設定できる「ガバナンスモード」、「コンプライアンスモード」はそれぞれどういった機能なのでしょうか。

概略は以下の通りです。

• ガバナンスモード：オブジェクトが保存されてから指定期間が経過するまでにおいて、特定の権限を持つユーザ以外に対して、バケット内のオブジェクトのバージョンの上書きや削除・ロック設定変更を防ぐことが可能
  • 指定期間内root含めs3:BypassGovernanceModeを持つユーザであれば操作可能
• コンプライアンスモード：オブジェクトが保存されてから指定期間が経過するまでにおいて、バケット内のオブジェクトのバージョンの上書きや削除を一切防ぐことが可能
  • 指定期間内においては、root含めいかなるユーザいかなるシチュエーションでも削除不可能

いずれのモードでも保存されてから指定期間が過ぎれば削除操作は可能となります。無期限に適用されることはないのですね。

保護指定期間は1日から設定可能なため検証時は短めの設定で試用すれば自身の想定と異なる挙動をしてもそうそう困ることはないと思います。

具体的な設定手順としては、[なし]以外の2つのいずれかのモードにチェックをすると
保持期間の入力フォームが出現するためそこで任意の日数を指定して[保存]を押すと

以下のような警告が出ますので、[確認]を押すと設定を有効化できます。
アホみたいに長い日数を指定するのは自重しましょう。

なお、これらのモードとは別に「リーガルホールド」と呼ばれる個々のオブジェクトバージョンに対して適用できる機能も存在します。

このモードはどのモードを有効化している状況下でも（あるいはモードの適用が[なし]の状態でも）オブジェクトのロックを設定できる機能が「完全に有効化」されていさえすればいつでも設定することができます。

リーガルホールドを解除するまで、同機能が設定されたオブジェクトバージョンは無期限で保護されますが、適用の解除はrootではなくs3:PutObjectLegalHoldという権限を持つユーザであれば実行可能なため気軽に試せる機能と言えます。

また、ここでオブジェクトロックの各モードやリーガルホールドを有効化&オブジェクトを保存した後に、オブジェクトを操作した際の
具体的な挙動について以下に整理しておきますので参考にしてください。

• 既存のオブジェクトを新しいファイルにて更新・上書きしようと試みた場合 => 失敗はせず、新しいファイルが最新verとして保存される。既存のオブジェクトは過去のverとして保存される
• 既存のオブジェクトの削除を試みた場合 => 失敗はせず、見かけ上はオブジェクトは削除されたかのように見える（削除マーカが最新Verとして保存される）が、削除操作前のオブジェクトは過去Verとして保存され復旧可能
  • 参考：オブジェクトバージョンの削除について
• 既存のオブジェクトの具体的なバージョンに対して更新や削除を試みた場合 => 失敗する

第３ステップ：MFA Delete機能と比較してオブジェクトロックの長所を理解する

ここまで読み進めていただければ、オブジェクトロックの概要と同機能が極度に危険なものでないことはご理解いただけたかと思います。

ただ、「MFA Deleteって機能があったよね。あれでよくね？」と思われる方が一部にはいらっしゃいそうです。私はむしろオブジェクトロックの利点はMFA Deleteと比較してこそ理解できるのではないかと考えています。

以下にごくごく簡単な比較表を作成してみました。

まず、MFA Deleteに言えることは実装方法が若干面倒であるということです。

rootユーザしか実装できず、この機能を欲するようなユーザはrootをかなりセキュアに管理していることがままある（ex.rootユーザログイン用のMFAデバイスを特定部署の金庫で管理している）ため、実装に躊躇したり手間取ることがありえます。

一方、オブジェクトロックに関しては比較的容易に実装が可能なため、機能概要を把握しているユーザからすればこちらの方が導入するのに便利であると言えるでしょう。

また、ライフサイクルポリシーを設定不可であるということもMFA Deleteのポイントでしょう。

MFA Delete有効化の環境下ではバージョンは削除されず肥大化する一方ですが、オブジェクトロック機能を有効にした環境下では適切な設定を実施さえすれば必要最低限の期間内・容量分だけオブジェクトの保持ができるようになります。

・・・いかがでしょう。他にも比較のポイントはあると思いますが、これらだけでも
CloudTrailの保存先等セキュアな運用を必要とするバケットをはじめとして
そこそこ採用の余地があるような感じはしないでしょうか。

最後に

今回はS3 オブジェクトロックの概要と利点を紹介してみました。今まで同機能を敬遠してたもしくは無視してた方が「ちょっと試してみようかな」と思うきっかけにこの記事がなれば嬉しく思います。

なお、実際に検証する際はバージョニングされたオブジェクトの削除は保護されていなくても若干面倒ですので、少量で展開することをおすすめします。

Cloud Automatorで提供している以下のアクションについて、大阪ローカルリージョンをサポートしましたので、お知らせ致します。

• EC2: AMIをリージョン間でコピー
• RDS: DBスナップショットをリージョン間でコピー

大阪ローカルリージョンについて

昨年2月に、AWSにおいて大阪ローカルリージョンがご利用頂けるようになりました。大阪ローカルリージョンは、AWSでは国内で2番目のリージョンとなり、東京リージョンのバックアップサイトとして非常に重要な位置づけとなっております。

Cloud Automatorにおきましても、大阪ローカルリージョンを利用可能なよう、多数ご要望を頂いておりました。
今回、Cloud Automatorではそのようなご要望にいち早く対応し、お客さまの運用自動化に貢献できますよう、大阪ローカルリージョンを一部サポート致しました。
これにより、例えば、東京リージョンのEC2インスタンスのバックアップイメージ(AMI)を、大阪ローカルリージョンにコピーして保存する、といった運用の自動化が可能になります。

※大阪ローカルリージョンのご利用には、申し込みおよび審査が必要となっております。大阪ローカルリージョンについてはAWSより提供されております以下資料等もご参照ください。

ご利用方法

前提

上述致しました通り、以下2アクションにおいて、大阪ローカルリージョンの利用が可能となりました。

• EC2: AMIをリージョン間でコピー
• RDS: DBスナップショットをリージョン間でコピー

ご利用にあたり、Cloud Automatorに登録するAWSアカウントにおいて大阪ローカルリージョンが利用可能な状態となっている必要がございます。

手順

ジョブ作成時にAWSアカウントを選択するステップで、大阪ローカルリージョンを利用可能なアカウントを選択します。
アクションのパラメータを入力するステップで、大阪ローカルリージョンが表示されますので、大阪ローカルリージョンを選択します。

※以下は「EC2: AMIをリージョン間でコピー」アクションの設定イメージです

終わりに

今後のリリース計画については、ロードマップページにて公開しております。
これからもCloud Automatorをよろしくお願いいたします。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

本日、Cloud Automatorで大阪ローカルリージョンを一部サポートすることを告知させて頂きました。

【Cloud Automator】大阪ローカルリージョンを一部サポート致します！

本記事では、大阪ローカルリージョンを用いて、東京リージョンで取得したAMIを自動で大阪ローカルリージョンにバックアップする方法をご紹介します。

概要

• 任意のトリガーで、東京リージョンでAMIを取得します
• HTTPトリガーでジョブを数珠つなぎし、東京リージョンでAMIを取得した後、自動でAMIを大阪ローカルリージョンにバックアップ（コピー）します
• AMIは東京リージョン/大阪ローカルリージョン両方で、世代管理が実施されます

※HTTPトリガーによるジョブの数珠つなぎについては、以下のマニュアル等をご参照ください。

Webhook後処理：複数のジョブを連続実行する（EC2インスタンスのスケールアップ）

前提

• Cloud Automatorの初期セットアップが完了していること
• 登録するAWSアカウントで大阪ローカルリージョンが使用可能なこと
• AMIを取得するEC2インスタンスが東京リージョンに存在すること

手順

1. 運用ジョブの作成と数珠つなぎ（大阪ローカルリージョンへのAMIのバックアップ）

ジョブの数珠つなぎを行うため、後から実行される大阪ローカルリージョンへAMIをコピーするジョブをまず作成します。
詳細は手順は割愛しますが、ポイントは以下の点です。

• 「トリガー」は「HTTPトリガー」を選択します
• 「コピー先リージョン」に「大阪ローカルリージョン」を選択します
• 「特定のタグがついたイメージ」を選択し、取得/コピーするAMIに付与予定のタグを入力します

2. 運用ジョブの作成（東京リージョンのEC2インスタンスのAMIの取得）

次に東京リージョンでAMIを取得するジョブを作成します。
詳細は手順は割愛しますが、ポイントは以下の点です。

• 「作成したイメージに追加するタグ」で上記で指定したタグを入力します
• 「リソースの終了ステータスをチェックする 」にチェックを入れる（デフォルトでチェックになっていると思います）
• 成功時の「後処理」に、1. のジョブを実行するためのWebhook後処理を入力する

3. 動作確認

以上により、2. で作成したジョブを実行すれば数珠つなぎでジョブが実行されると思います。
2. のジョブを実行し、以下のように大阪ローカルリージョンにAMIがコピーされるところまで確認できれば完了です！

おわりに

本記事では、大阪ローカルリージョンを用いて、東京リージョンで取得したAMIを自動で大阪ローカルリージョンにバックアップする方法をご紹介しました。
是非ご活用ください！

また、サーバーワークスではCloud Automatorのハンズオンレクチャーを定期開催しております。
こちらもご興味があればご確認頂ければ幸いです（直近では6月25日に開催予定です！）。

こんにちわ。クラウドインテグレーション部の森です。
最近、出社する時は一駅前で降りて歩いているので、多少体重が減ってきました。
やはり運動は必要だなと思った今日この頃です。

今回は、Googleカレンダーを使って、主催者変更をやってみます。
ちょっと前に、Googleカレンダーに登録している定期的な予定の主催者をしていたのですが、
次のメンバーに引き継ごうということで、いつもなら次の担当の人に作ってもらって、
自分が作った予定を削除するようなことをしていたのですが、
そんなことをしなくても、主催者変更できるというのを最近知ったので、やり方の説明です。

主催者変更のやり方

１．まずは登録しているカレンダーをクリックします。

２．ポップアップが出ますので、「ペン」のマークをクリックして、編集を行います。

３．編集画面で、右上の「その他の操作」から「主催者を変更」を選択します。

４．「新しい主催者」が出てくるので、次のメンバーのメールアドレスを入力し、右下の「主催者を変更」をクリックします。

５．次のメンバー宛にメールが送付されます。そのメンバーにURLをクリックしてもらいます。

６．カレンダーを確認すると主催者が変更されました。

最後に

サーバーワークスに入ってからGoogleカレンダーをよく使うようになったのですが、
知らない機能で、最近知ってちょっとうれしくなってしまいました。
他にもいろいろ機能があるので徐々に使っていこうかなと思います。

S3のVPC Endpointを作成した場合、アクセス元の対象がPrivateサブネットにあれば弊社Godai Nakamuraのblog(*1)にある通りcurl等を利用してインターネットの任意のサイトへアクセスができないが、S3へはVPC Endpointを作成した事によってアクセス出来るといった確認をするといったシンプルな話で済みます。

しかしPublicサブネットの場合は、デフォルトルート(0.0.0.0/0)がIGWに向いているためIGW経由でもVPC Endpoint経由でもS3へアクセス出来るため上の手法は通用しません。
従って実際にどの経路でアクセスがされたのかを見極めるには少し深い確認をする必要があります。

Publicサブネットのルートテーブルの例 (S3のVPC Endpointの経路設定済み *2)

ytamu@SilverMachine:~$ aws ec2 describe-route-tables --route-table-id=rtb-0b9d6fda75bce0adf --query 'RouteTables[].Routes[]' --output table
-------------------------------------------------------------------------------------------------------------
|                                            DescribeRouteTables                                            |
+----------------------+---------------------------+-------------------------+-------------------+----------+
| DestinationCidrBlock |  DestinationPrefixListId  |        GatewayId        |      Origin       |  State   |
+----------------------+---------------------------+-------------------------+-------------------+----------+
|  10.0.0.0/16         |                           |  local                  |  CreateRouteTable |  active  |
|  0.0.0.0/0           |                           |  igw-01d45a55298df7dad  |  CreateRoute      |  active  |
|                      |  pl-61a54008              |  vpce-0a7e08b0a117fddb5 |  CreateRoute      |  active  |
+----------------------+---------------------------+-------------------------+-------------------+----------+
ytamu@SilverMachine:~$
ytamu@SilverMachine:~$ date;aws ec2 describe-prefix-lists --prefix-list-ids=pl-61a54008
Thu May 16 07:40:22 UTC 2019
{
    "PrefixLists": [
        {
            "Cidrs": [
                "52.219.0.0/20",
                "54.231.224.0/21",
                "52.219.16.0/22",
                "52.219.68.0/22"
            ],
            "PrefixListId": "pl-61a54008",
            "PrefixListName": "com.amazonaws.ap-northeast-1.s3"
        }
    ]
}
ytamu@SilverMachine:~$

このルートテーブルを見た瞬間、S3関連のIPアドレス帯が4つ指定されているのでロンゲストマッチでVPC Endpointに向く(IGWを経由しない)筈だし問題ないであろうと思えたりもしますが、設定後には実際に通信を発生させ動作確認(裏どり)はしておきたいものです。
確認方法の1つの例として、CloudTrailのログから確認するといった手法があるので今回メモ代わりに残します。

これからやる事を一行で纏めると
「当該PublicサブネットにいるEC2インスタンスからS3へ何らかのアクションを実行し、CloudTrailの対象ログにあるCloudTrailEventの内容から経路を判断する」です。

CloudTrailにイベントログとして残りさえすればどのようなオペレーションでも良い筈(*3)ですが、今回は一時的に適当なS3bucketを作成しそのログから経路を確認します。

簡易検証環境の構成はざっくり以下です。

EC2(Amazon Linux2)からS3bucketを作成して削除します。
(膨大な量のCloudTrailのログを追いやすくなるので同時にdateを叩いておくと後に幸せになれます)

# S3bucket作成
[ec2-user@ip-10-0-0-225 ~]$ date;aws s3 mb s3://via-vpce-test
Thu May 16 07:52:32 UTC 2019
make_bucket: via-vpce-test
[ec2-user@ip-10-0-0-225 ~]$

# S3bucket削除 (お掃除が目的)
[ec2-user@ip-10-0-0-225 ~]$ date;aws s3 rb s3://via-vpce-test
Thu May 16 07:52:41 UTC 2019
remove_bucket: via-vpce-test
[ec2-user@ip-10-0-0-225 ~]$

そして、IGW経由となるようルーティングテーブルを設定し直し(VPC EndpointとPublicサブネットの関連づけを外し)、今度は上の内容をS3bucket名: via-igw-testとして再度実施します。(こちらは差分確認しなくて良いなら別にやらなくて良いです)

# S3のVPC Endpointから PublicサブネットのルートテーブルをRemove
ytamu@SilverMachine:~$ aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-0a7e08b0a117fddb5 --remove-route-table-ids=rtb-0b9d6fda75bce0adf --reset-policy
{
    "Return": true
}
ytamu@SilverMachine:~$

実施が完了したらCloudTrailからS3bucketを作成した対象ログを突き止めます。

ytamu@SilverMachine:~$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateBucket

“EventName”: “CreateBucket” ログが対象日時前後で見つかる筈です。
マネージドコンソールを利用して確認(*5)した方が楽だと思われます。
# CloudTrailのログ反映には少々時間がかかるのでまだ出力されていなければ珈琲でも飲みながら待ちましょう。そして参照リージョンを間違え珈琲も冷めてしまう事があるので気をつけましょう。<-自分への戒め

S3bucket作成した対象ログのCloudTrailEventの中身を確認すると以下のような感じになっており
“vpcEndpointId”: “vpce-0a7e08b0a117fddb5” といった今回作成したVPC EndpointのID情報が2箇所見て取れます。
CloudTrailEvent[]の中が JSONのなかにJSONといった感じで人の目に優しくないビジュアルな為、今回はjqコマンドツールを利用して整形しています。
また、不本意ですが色々と伏せた方がよさげな情報がドバドバ出たので一部結果を XXXX といった形で手動で置き換えています。

ytamu@SilverMachine:~$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventId,AttributeValue=3b44035b-5a47-433d-aee4-deb02606ee7c --query 'Events[].CloudTrailEvent[]' --output text |jq
{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "XXXXXXXXXXXXXXXXXXXXX:i-XXXXXXXXXXXXXXXXX",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/S3FullAccess-Role/i-0942293cad73b36c3",
    "accountId": "XXXXXXXXXXXX",
    "accessKeyId": "XXXXXXXXXXXXXXXXXXXX",
    "sessionContext": {
      "attributes": {
        "mfaAuthenticated": "false",
        "creationDate": "2019-05-16T07:28:34Z"
      },
      "sessionIssuer": {
        "type": "Role",
        "principalId": "XXXXXXXXXXXXXXXXXXXXX",
        "arn": "arn:aws:iam::XXXXXXXXXXXX:role/S3FullAccess-Role",
        "accountId": "XXXXXXXXXXXX",
        "userName": "S3FullAccess-Role"
      }
    }
  },
  "eventTime": "2019-05-16T07:52:34Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "CreateBucket",
  "awsRegion": "ap-northeast-1",
  "sourceIPAddress": "10.0.0.225",
  "userAgent": "[aws-cli/1.16.102 Python/2.7.14 Linux/4.14.114-103.97.amzn2.x86_64 botocore/1.12.92]",
  "requestParameters": {
    "CreateBucketConfiguration": {
      "LocationConstraint": "ap-northeast-1",
      "xmlns": "http://s3.amazonaws.com/doc/2006-03-01/"
    },
    "bucketName": "via-vpce-test",
    "host": [
      "via-vpce-test.s3.ap-northeast-1.amazonaws.com"
    ]
  },
  "responseElements": null,
  "additionalEventData": {
    "SignatureVersion": "SigV4",
    "CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
    "AuthenticationMethod": "AuthHeader",
    "vpcEndpointId": "vpce-0a7e08b0a117fddb5"
  },
  "requestID": "XXXXXXXXXXXXXXXX",
  "eventID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "eventType": "AwsApiCall",
  "recipientAccountId": "XXXXXXXXXXXX",
  "vpcEndpointId": "vpce-0a7e08b0a117fddb5"
}
ytamu@SilverMachine:~$

今回、VPCE経由とIGW経由のCloudTrailEventの差分は以下の通りでした。
“vpcEndpointId”の有無の違いだけでなく、
“sourceIPAddress”がVPCE経由の場合はEC2のプライベートIPアドレスであり、IGW経由の場合はAWSのグローバルIPアドレスとなっている事がわかります。

ytamu@SilverMachine:~$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventId,AttributeValue=3b44035b-5a47-433d-aee4-deb02606ee7c --query 'Events[].CloudTrailEvent[]' --output text |jq > /tmp/via-vpce-test
ytamu@SilverMachine:~$ aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventId,AttributeValue=81a05480-c6cd-4168-bca1-0929ce9c637b --query 'Events[].CloudTrailEvent[]' --output text |jq > /tmp/via-igw-test
ytamu@SilverMachine:~$ diff -u /tmp/via-igw-test /tmp/via-vpce-test
--- /tmp/via-igw-test   2019-05-16 22:57:04.000000000 +0900
+++ /tmp/via-vpce-test  2019-05-16 22:56:47.000000000 +0900
@@ -5,11 +5,11 @@
     "principalId": "XXXXXXXXXXXXXXXXXXXX":i-XXXXXXXXXXXXXXXXX",
     "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/S3FullAccess-Role/i-XXXXXXXXXXXXXXXXX",
     "accountId": "XXXXXXXXXXXX",
-    "accessKeyId": "XXXXXXXXXXXXXXXXXXXX",
+    "accessKeyId": "XXXXXXXXXXXXXXXXXXXX",
     "sessionContext": {
       "attributes": {
         "mfaAuthenticated": "false",
-        "creationDate": "2019-05-16T12:51:42Z"
+        "creationDate": "2019-05-16T07:28:34Z"
       },
       "sessionIssuer": {
         "type": "Role",
@@ -20,30 +20,32 @@
       }
     }
   },
-  "eventTime": "2019-05-16T13:33:09Z",
+  "eventTime": "2019-05-16T07:52:34Z",
   "eventSource": "s3.amazonaws.com",
   "eventName": "CreateBucket",
   "awsRegion": "ap-northeast-1",
-  "sourceIPAddress": "54.199.166.59",
+  "sourceIPAddress": "10.0.0.225",
   "userAgent": "[aws-cli/1.16.102 Python/2.7.14 Linux/4.14.114-103.97.amzn2.x86_64 botocore/1.12.92]",
   "requestParameters": {
     "CreateBucketConfiguration": {
       "LocationConstraint": "ap-northeast-1",
       "xmlns": "http://s3.amazonaws.com/doc/2006-03-01/"
     },
-    "bucketName": "via-igw-test",
+    "bucketName": "via-vpce-test",
     "host": [
-      "via-igw-test.s3.ap-northeast-1.amazonaws.com"
+      "via-vpce-test.s3.ap-northeast-1.amazonaws.com"
     ]
   },
   "responseElements": null,
   "additionalEventData": {
     "SignatureVersion": "SigV4",
     "CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
-    "AuthenticationMethod": "AuthHeader"
+    "AuthenticationMethod": "AuthHeader",
+    "vpcEndpointId": "vpce-0a7e08b0a117fddb5"
   },
-  "requestID": "XXXXXXXXXXXXXXXX",
-  "eventID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
+  "requestID": "XXXXXXXXXXXXXXXX",
+  "eventID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
   "eventType": "AwsApiCall",
-  "recipientAccountId": "XXXXXXXXXXXX"
+  "recipientAccountId": "XXXXXXXXXXXX",
+  "vpcEndpointId": "vpce-0a7e08b0a117fddb5"
 }
ytamu@SilverMachine:~$

参考URI

*1…VPC Endpointを使ってS3にアクセスしてみる

VPC Endpointを使ってS3にアクセスしてみる

*2…ゲートウェイ VPC エンドポイント
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpce-gateway.html

*3…AWS CloudTrail を使用して Amazon S3 API コールのログを記録する
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/cloudtrail-logging.html

*4…jq
https://stedolan.github.io/jq/

*5…CloudTrailの基本

CloudTrailの基本

こんにちは。技術二課の伊藤Kです。

サーバーワークスでは、プロジェクト管理ツールとして「Backlog」を使っています。
タスク管理、ファイル共有もできるプロジェクト管理ツールBacklog

今回はこのBacklogの「課題」のステータスを、複数課題一挙に更新できるよう、ステータスを更新するスクリプトを作成します。

背景

Backlogではプロジェクトの課題管理機能として「課題」を1課題＝1チケットとして生成し、各チケット毎に担当者、期限、進捗状況（ステータス）等を管理できます。
通常イメージされる「プロジェクトの課題」について管理している分にはGUI（Webベースの管理画面）からコメントやステータスを記入していけばよいのですが、
中には面倒な卓抜なことを考える人がいて、とある作業（作業Aとします）について、1インスタンスに対し1課題生成して、数百台あるインスタンスについて、作業Aのステータス管理をすることになりました。
「今日、インスタンス30台に対して作業Aが完了したので、対応する30個の課題のステータスを完了にしましょう」
イエッサー、Webブラウザで課題の設定画面を開いて、完了理由のコメントを入力して、ステータスを「完了」に設定して保存、と。
・・・これをあと29回やるのか。

というわけで、スクリプト化します。
Backlog APIが使えるようです。APIを叩くにはやっぱりPythonだな（偏見）。
とにかく早く作れてシンプルに動くことを重視する方針にします。
複雑なロジックを用いて全てを完璧にスクリプト化することは目指さず、多少GUIからの操作も入れて実現させます。

環境

以下の環境を用意します。
・インターネット環境（BacklogのAPIのURLに接続できること）
・Webブラウザで課題の検索画面が開け、検索一覧のデータエクスポートができること
・Pythonが実行できる環境（筆者の実行環境のバージョンはPython 3.7.1）
・Excelのファイルが開ける環境（頑張ればCSVファイルをテキストエディタで開くことで代用可能だが、Excelのほうが見やすい）

前提知識、参考情報

・「課題情報の更新」に関するBacklog API
課題情報の更新 – Backlog Developer API – Nulab
・サーバーワークスエンジニアブログ過去記事
Web APIで繋がる Questetra / Backlog 連携

準備作業

WebブラウザからBacklogにログイン後、以下リンク先の記事に従って、BacklogのAPIキーの情報を取得しておきます。
APIの設定

WebブラウザでBacklogの管理画面にログインした際のURLもひかえておきます。

サンプルスクリプト

サンプルスクリプトを記載します。実際にプロジェクトであったシチュエーション、2パターンです。

サンプル１：コメントを入れ、同時に状態を「完了」にする

課題をクローズしたい場合に、クローズの理由などをコメントに追記し、状態を「完了」に更新します。

sample01.py

#!/usr/bin/env python

import requests
import sys

### 課題各ステータス
apikey = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'   # BacklogのAPIキー
url = "https://hogehoge.backlog.jp/api/v2/issues"   # Backlog API の URL
statusId = 4                          # 設定する状態ID（4:完了, 3:処理済み, 2:処理中, 1:未対応）
comment = '作業完了したのでクローズ'  # 設定するコメント
### ###

# 引数取得
args = sys.argv

# 更新用URL生成
urlreal = url + "/" + args[1]

# Backlog API v2
# APIキー, 状態ID, コメント 
payload = {
        'apiKey': apikey,
        'statusId': statusId,
        'comment': comment,
}
r = requests.patch(urlreal, params=payload)
print(r.text)

「準備作業」で取得した情報もふまえ、「課題各ステータス」部分の記述を更新してください。
Backlog API の URLについては、「https://hogehoge.backlog.jp」までが「準備作業」で確認した「Backlogにログインした際のURL」と共通で、「/api/v2/issues」は固定です。
スクリプト最終行の「print(r.text)」は、レスポンス内容を実行結果として表示させない場合は削除しても問題ありません。
表示させると、エラーだった場合に気づけて便利です。

実行方法

更新したい課題の「課題ID」を引数として、以下のように実行します。

> python sample01.py <課題ID>

ここで、更新したい課題の課題IDをどのように確認するのか。
全てをスクリプト内で完結するならば、課題IDを確認するスクリプトも作り、連携を試みるところです。
しかし、「背景」のセクションで記した通り「スピード重視」の方針で、
以下の通りささっと確認する方法を使います。

まずはBacklogにWebブラウザからログインし、「課題」メニューの検索条件で、更新対象の課題を含む条件で検索し、一覧に更新対象の課題を表示させます。

その状態で、右の「・・・」メニューをクリックし、「Excel」を選択します。

課題一覧がExcel形式でダウンロードされるのでファイルを開くと、更新対象の課題に対する「ID」が確認できます。これが「課題ID」です。

上記「Excel」を選択した手順の途中で、「CSV」を選択するとCSV形式のデータエクスポートも可能ですが、Excelファイルのほうが見やすいです。

課題IDを確認したので、図の例ではスクリプトはこのように実行します。
> python sample01.py 1234567891

対象の課題にコメントが追加され、ステータスも完了となりました。

さて当初のシナリオ、30個の課題を一気に「完了」とする方法ですが、
上記手順で更新対象の課題全ての課題IDを確認し、
コマンドを実行するファイルを作ります。
筆者の環境はWindowsなので、バッチファイルとして作成します。

sample.cmd

python sample01.py 1234567891
python sample01.py 1234567892
 ・
 ・
 ・
python sample01.py 1234567992

このバッチファイルをコマンドプロンプトから実行、めでたく30個の課題の状態が
一気に更新されました。

サンプル２：親課題を変更する

もう一つあったシチュエーション、各「子課題」が所属する「親課題」を一括で変更するパターンです。

sample02.py

#!/usr/bin/env python

import requests
import sys

### 課題各ステータス
apikey = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'   # BacklogのAPIキー
url = "https://hogehoge.backlog.jp/api/v2/issues"   # Backlog API の URL
parentIssueId = 9900099009   # 親課題ID
### ###

# 引数取得
args = sys.argv

# 更新用URL生成
urlreal = url + "/" + args[1]

# Backlog API v2
# APIキー, 状態ID, コメント 
payload = {
        'apiKey': apikey,
        'parentIssueId': parentIssueId,
}
r = requests.patch(urlreal, params=payload)
print(r.text)

親課題を設定する箇所以外はサンプル１と全く同じです。
親課題IDの確認方法も、上記Excelデータダウンロードで、親課題の課題IDを確認すればOKです。

実行方法

実行コマンドもサンプル１と同じく
> python sample02.py <課題ID>
です。

おわりに

後日、課題の一括登録スクリプトについての記事も予定しています。お楽しみに！

AWSのクラウドプラクティショナー認定試験は、日本語・英語・中国語・韓国語で受験可能です。
私は日本人なのですが、中国語を勉強中のため、中国語受験してみました。

受験申し込み

Chinese Mandarin Simplifiedを選択しましょう！

模擬試験

本番受験前に模擬試験も中国語で受けてみました。

模擬試験の結果などの通知も中国語でしっかり届きます。

受験本番

秋葉原の会場で受験してきました。
受付時に「中国語でいいんですか？」等と聞かれるかと思ったのですが、何もありませんでした。
受付の紙には、特に受験言語が書いていなかったかもしれません。

本当に中国語で受験できるか不安になりましたが、試験開始したら中国語が表示され、ホッとしました。
なお、当たり前なんですが、NDAやアンケート的な質問も中国語でした。

結果

スコアレポートも中国語です。

無事に通过できました。