AWS CLIで情報を出力しようRDS編(Linux版-その2)

 RDSってどんな製品(エンジン)が利用できるのだろうか。一覧とかだして、確認
することができたらいいな。AWSコンソールから操作すると、もし、何かミスをし
て、他のシステムに影響があったら困るし、課金されても困る。どんなエンジンが
あるかどうかさえ分かれば、いいのに。こんな時には、AWS CLIを使いましょう。

1.現在利用中のRDSの情報を出力しよう!

利用中のRDS一覧を出力する場合は、以下のコマンドを実行します。

aws rds describe-db-instances

画像A RDSの情報
                画像A RDSの情報

json形式で沢山出力されます。

2.現在利用中のRDSで出力する情報を絞り込んでみよう!

オプションのqueryを使用することで絞り込みができます。
以下の例は、ClassとId,Engine,Endpointのアドレスに絞った例です。
トップレベルがDBInstanceで(画像C 階層と項目)DBInstanceIdentifer,
DBInstanceClass,Engineをdict{}に配置し、{EndPoint.Address}を分けて配置
させます。DBinstanceIdentiferと同列に書くと縦長に配置されて出力されます。

aws rds describe-db-instances \
--query "DBInstances[].[{ID:DBInstanceIdentifier,Class:DBInstanceClass,\
Engine:Engine},{Endpoint:Endpoint.Address}]" \
--out table

画像B 項目を絞って出力
               画像B 項目を絞って出力
              画像C 項目と階層

3.利用可能なRDSのEngineとVersion情報を出力しよう!

利用中のリージョンで、利用可能なRDS一覧を見たい場合に以下のコマンドを実行します。

aws rds describe-db-engine-versions

画像D 出力結果
                画像D 出力結果

json形式でどばーっと出力されます

4 出力する情報を絞り込んでみよう!

オプションのqueryを使用することで絞り込みができます。
以下の例はDBParameterGroupFamilyとEngineversionのみに絞ったものです。
DBParameterGroupFamilyが、このDBパラメータグループファミリー互換性のある名前で
EngineVersion が、このエンジンのバージョンです。

aws rds describe-db-engine-versions \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]" \
--out table

画像E FamiryNameとVersion出力
            画像E FamiryNameとVersion出力

queryオプションの設定は以下のようになります 結果は、Json形式で出力されます。
これを踏まえて絞り込む内容を記述します。
トップレベルが、DBEngineVersions[*]. (画像F 階層と項目)
DBEngineVersions[*] .[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]
下の階層(画像C 階層と項目)DBParameterGroupFamily項目)の値と、EngineVersion項目の値を
{key1:value,key2:value}のdict形式でフォーマットして、項目名を出力するようにする

画像F 階層と項目
               画像F 階層と項目

5 RDSのエンジンを指定してそのエンジン情報のみ出力しよう!

5.1 エンジンにaurora-mysqlを指定

aurora-mysqlのみ出力したい場合は、engineにaurora-mysqlを指定します。
更にFamiryNameとVesionのみを出力するようにします。

aws rds describe-db-engine-versions --engine aurora-mysql \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]"\
--out table

画像G RDS aurora-mysql
              画像G RDS aurora-mysql

5.2 エンジンにoracle-eeを指定

oracleの場合は、oracle-eeとoracle-seが利用可能です。–engineオプション にoracle-ee
まで指定する必要があります。

aws ds describe-db-engine-versions --engine oracle-ee \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]"\
--out table

画像H oracle-ee
                画像H oracle-ee

6 VersionUp可能なエンジンを表示しよう!

6.1 MariaDB 10.2.37からバージョンアップ可能なRDS一覧

RDSを利用していると、現在利用しているエンジンのバージョンアップを要求される
ことがあります。どのバージョンにアップしたら良いのか(可能なのか)が
AWS CLIコマンドで確認できます。以下の例はmariadb 10.2.37からバージョンアップ
可能なエンジンの一覧を出力するものです。

echo 'mariadb 10.2.37 up'
aws rds describe-db-engine-versions \
--engine mariadb --engine-version 10.2.37 \
--query "DBEngineVersions[].ValidUpgradeTarget[].[{Des:Description,Auto:AutoUp
grade,Major:IsMajorVersionUpgrade,UpVersion:EngineVersion}]" \
--out table

画像J marriadb 10.2.37からバージョンアップ可能なRDS
     画像J marriadb 10.2.37からバージョンアップ可能なRDS

queryオプションの指定はトップレベルが(画像K 階層と項目)DBEngineVersions 一つ下の
レベルがValidUpgradeTargetそこを全て見るのでDBEngineVersions[*].ValidUpgradeTarget[*]
その下の項目(画像L 指定項目)、Description,AutoUpgrade,IsMajorverVersion,EngineVersion
をDict形式で指定する

画像K 階層と項目
                 画像K 階層と項目
画像L 指定項目
                 画像L 指定項目

6.2 Oracle-ee 12.1.0.2.v2からバージョンアップ可能なRDS

以下の例はoracle-ee 12.1.0.2.v2からバージョンアップ可能なエンジンの一覧を出力するものです。

echo 'oracle-ee 12.1.0.2.v2 up'
aws rds describe-db-engine-versions \
--engine oracle-ee --engine-version 12.1.0.2.v2 \
--query "DBEngineVersions[].ValidUpgradeTarget[].[{Version:EngineVersion,Auto:
AutoUpgrade,Major:IsMajorVersionUpgrade}]" \
--out table

画像M oracle12.0.1.2V2からバージョンアップ可能なRDS一覧
画像M oracle12.0.1.2.V2からバージョンアップ可能なRDS一覧 (画像を一部加工してます)

7.感想

RDSの情報でニーズがありそうな項目を出力するコマンドを実行してみました。
今利用のバージョンからバージョンアップ可能な物は何があるかは、良く問い合わせがあります。
何かのお役に立てば何よりです。

Linux版その1 EC2の情報出力 https://opt-p.co.jp/blog/aws/post-1633/

Linux版その3 VPCの情報出力 https://opt-p.co.jp/blog/aws/post-2080/

Linux版その4 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/

ストレリチア(極楽鳥花)の新葉がでました!

こんにちは!株式会社オプトプランニングです。

あっという間に桜も終わり、本日は穀雨の雨で少し肌寒く感じますね。

さて、当社の玄関入り口にあるストレリチア(極楽鳥花)という植物に、大きな新葉がつきました!

葉の色が明るくて、まだまだ柔らかいです。植物も春を感じているのでしょうか?!越冬したブルーベリーにも小さな新葉がついています。

ストレリチアは、極楽鳥花という名の通り、極楽鳥のようなオレンジ色の鮮やかな花をつけるそうです。南国風ですね。花を咲かせてくれることを信じて楽しみに待とうと思います!

リリースしてみた<リリース編>

Salesforceでやってみた

はじめに

こんにちは!株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースをやってみようと思います!!

前回までのおさらいと気づき

今までのやってみたこと

前々回 は変更セットの作成を行いました。

そして 前回 は変更セットのアップロードを行い、送信変更セットのアップロード前後の違いを確認しました。

使用環境やリリースの内容については 利用環境と内容 を見てください。

前回のブログアップ後に気づいたこと

今回の本題であるリリースを行う前に、前回のブログアップ後に気づいたことを書いていきたいと思います。

前回、変更セットのアップロード前後の比較・確認を行うために画像を載せていました。
この部分に、前回は全く気づかなかったちょっとした違いがありました。

どこかわかりますか…??

なんと、変更セットコンポーネントの「名前」が違うのです…!!!!!

図1 送信変更セットアップロード前
図1 送信変更セットアップロード前
図2 送信変更セットアップロード後
図2 送信変更セットアップロード後

リリース作業は実務でも行いましたが、アップロード後にコンポーネントの名前が変わることは気づいていませんでした…!!

なので、全てのコンポーネントの名前が変わるのか、特定の種別のコンポーネントだけなのかなどについても不明です…

今回に関しては、アップロード前はAPI参照名が表示されており、アップロード後は表示ラベルが表示されているようです。
(ちなみに、受信変更セットでは表示ラベルが表示されているようです。)

どうしてこのような動作になるか不明ですが、今まで一貫して以下の権限セット1つをコンポーネントに追加して作成した変更セットを使用しています。

図3 権限セット:ユーザのMFA認証
図3 権限セット:ユーザのMFA認証

この件については、なぜこのようなことが起こるのか・他の種類のコンポーネントの時はどうなるのかなど、詳細がわかり次第ブログでご紹介できるように調査を続けていきたいと思います。
(もしかしたら、プロファイル関係の変更セットだったからかな…?と思ったり…)

今回のブログでもコンポーネント名が入った画像が出てきますが、名前が違っても間違いなく同じ変更セットを使用していますので、特に注意書きなどありませんがそのように読み進めていただければと思います。

受信変更セットを確認してみた

初っ端から脱線してしまいましたが、話を戻してリリース作業を再開していきます!!

開発環境で作成した「送信変更セット」はアップロードすることによりリリース環境で「受信変更セット」として受け入れているはずです。

前回は送信変更セットのアップロード完了までの確認を行いましたので、まずはリリース環境の方で受信変更セットの確認から行っていこうと思います!

最初に、リリース環境である「T2Sandbox」にログインし、設定の検索ボックスに「変更セット」と入力して「受信変更セット」を開きます。

受信変更セットを開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

図4 受信変更セット:リソースの理解1
図4 受信変更セット:リソースの理解1
図5 受信変更セット:リソースの理解2
図5 受信変更セット:リソースの理解2

受信変更セットの一覧が表示されます。

「リリース待ちの変更セット」に前回アップロードした変更セットを確認することができます!!

これで、リリース環境に変更セットのアップロードが無事に行われていることの確認ができました。

変更セット名の部分がリンクになっているので、クリックしてしてみましょう。

図6 受信変更セットの一覧
図6 受信変更セットの一覧

すると、変更セットの詳細画面が表示されます。

送信変更セットと違う点として、「ソース組織」があります。
(先ほどの受信変更セット一覧の画面でも確認することができます)
ここでどの環境からアップロードされた変更セットなのかを確認することができます。

また、「有効期限」もあります。
受信変更セットには有効期限が設けられています。
有効期限はアップロード後6か月です。

変更セットをアップロードして半年後にリリースを行うことはないと思いますが…

有効期限が切れると、変更セットは永久に削除されます。

引用:送信変更セットのアップロード(Salesforceヘルプより)

と書かれていますので、後から内容を確認したい時に確認ができない…!ということにならないように気を付ける必要はありそうです。

図7 受信変更セットの詳細画面
図7 受信変更セットの詳細画面

リリースしてみた

受信変更セットを使用してのリリース

受信変更セットの確認も終わりましたので、遂にリリースを行います…!!
ここまで長かった…!!

リリースは受信変更セットから行います。

受信変更セットの一覧を表示させ、先ほど確認した「リリース待ちの変更セット」のアクション欄にある「リリース」をクリックします。

図8 受信変更セットの一覧
図8 受信変更セットの一覧

すると、「変更セットのリリース」画面に移動します。

「テストオプションの選択」にいくつか選択できる項目がありますが、今回は「デフォルト」を選択し、「リリース」をクリックします。

図9 変更セットのリリース
図9 変更セットのリリース

このようなポップアップが立ち上がるので、「OK」をクリックします。

図10 「リリース」クリック後のポップアップ
図10 「リリース」クリック後のポップアップ

リリースが開始され、画面はリリースを行った変更セットの詳細画面に移ります。

変更セットの詳細の上部にさっきまで無かった「開始されたリリース」という強調表示があります。
この表示が、対象の変更セットが現在リリース中であることを表しています。

強調表示部分の「リリース状況」と書かれた部分はリンクになっており、リンク先では対象の変更セットの詳しいリリース状況を確認することができます。

図11 リリース中の受信変更セット詳細画面
図11 リリース中の受信変更セット詳細画面

クリックしてみるとリリース状況の画面に移動しました。

今回は変更セットのコンポーネントが少ないため、リリース状況をみるとすでに「成功」の一覧に表示されていました。

これでリリースは無事に完了です!!!

もしここでなんらかの理由でリリースができなかった場合、「失敗」の一覧に変更セット名が表示され、アクション欄の「詳細を表示」でエラー内容を確認することができます。

また、コンポーネントの数が多かったりApexやVFPがたくさん入っていると検証に時間がかかりますので、その時は気長に待ってみましょう。

図12 リリース状況:成功
図12 リリース状況:成功

リリースの確認

では、今回行ったリリースがちゃんと反映されているか確認してみます。

コンポーネントとして含めた権限セットを確認するため、設定の検索ボックスに「権限セット」と入力して「権限セット」を開きます。

表示される権限セットの一覧に、今回コンポーネントとして含めた「ユーザのMFA認証」が追加されていることが確認でき、ちゃんと変更セットでのリリースができていることがわかりました!!

図13 権限セット一覧
図13 権限セット一覧

リリース後の受信変更セットを確認してみた

受信変更セット一覧

リリースは無事に終わりましたが、リリース後の受信変更セットについても確認しておこうと思います。

まずは受信変更セット一覧の画面です。

リリースが成功すると、対象の変更セットは「リリース済みの変更セット」の欄に移動します。
また、「アップロード日」ではなく「リリース日」が表示されるようになります。

図14 受信変更セット一覧:リリース済みの変更セット
図14 受信変更セット一覧:リリース済みの変更セット

受信変更セット詳細画面

次に、リリース後の受信変更セットの詳細画面を確認してみます。

リリース中にあった強調表示がなくなる代わりに、「リリース履歴」が追加されています。

図15 受信変更セット詳細画面:リソース履歴
図15 受信変更セット詳細画面:リソース履歴

この部分、エラーでリリースが失敗した場合も履歴として追加されていきます。
エラーの場合、「アクション」の「詳細を表示」でエラー内容の詳細を確認することができます。

また、今回は行っていませんが「検証」を行った場合もこの履歴が追加されていきます。

「リリース待ちの変更セット」欄に表示されている変更セットで、この「リリース履歴」にエラーがある場合はリリースを行う前に内容を確認しておく方がいいでしょう。

図16 リリース履歴:失敗あり
図16 リリース履歴:失敗あり
図17 リリース履歴:リリースと検証成功
図17 リリース履歴:リリースと検証成功

リリース履歴には開始時刻と終了時刻が表示されているので、どのぐらいの時間でリリースが完了したか確認することもできます。
(今回のリリースは全く時間がかかっていないことが分かります。)

あとがき

リリースはあっけなく終わってしまいましたが、これで無事に変更セットを使用したリリースを完了することができました。

確認作業は別として、実際のリリースも変更セットの作成が一番比重の大きい作業だと思います。

今回は1つのコンポーネントでしたが、リリースするコンポーネントが増えるにつれエラーも起きやすいので、リリースでエラーがでたら変更セットの作り直し&アップロードの繰り返し…を行っていくことになると思います。

変更セットの作り直しやアップロードのやり直し、使いまわしについて、実際にやってみてこのような使い方をすれば効率がいいかも…?と感じたことがいくつかあるので、近いうちにまとめをブログでアップできればと思います。

では、またお会いしましょう!!

関連記事
リリースしてみた<変更セット作成編>
リリースしてみた<アップロード編>

リリースしてみた<アップロード編>

Salesforceでやってみた

はじめに

こんにちは!株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースに向けて変更セットのアップロードをやってみようと思います!!

前回までのおさらい

前回 は送信変更セットを作成しました。

無事に作成できたのでアップロードを行おうとしたところ、このような画面が出てしまいました。

図1 アップロードエラー画面
図1 アップロードエラー画面

リリースするためには変更セットを作成するだけではできない…!!

ということに気づいたのが前回の変更セット作成編でした。

アップロードの準備をやってみた

アップロードに必要な設定とは

変更セットをアップロードするには、アップロード先の環境(変更セットを受け取る環境)でリリース接続の設定を行う必要があります。

デフォルトの状態では、本番組織・Sandbox問わず全環境で変更セットのアップロードを受け付けていない状態となっています。
そこで、どの環境からの変更セットを受け付けるか受け取る側の環境で設定する必要があります。

変更セットの作成はアップロード先の環境があってもなくてもできますし、リリース接続の設定は変更セットを作成する前に行っても後に行っても問題ありません。

リリース接続の設定を行う

今回は先に変更セットの作成を行ったので、次にアップロード先の「T2Sandbox」でリリース接続の設定を行います。(使用環境などは 前回の使用環境と内容 を参照)

変更セットの作成は「TSandbox」で行っていたので、現在のログインしている環境は「TSandbox」です。
まずは「T2Sandbox」に環境を変えるためログインし直します。
ログイン出来たら、設定の検索ボックスに「リリース」と入力して「リリース設定」を開きます。

リリース設定を開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

図2 リリース設定のリリースの情報1
図2 リリース設定のリリースの情報1
図3 リリース設定のリリースの情報2
図3 リリース設定のリリースの情報2

リリース設定を開くとリリース接続先として組織の一覧が表示されます。
この一覧から、どの環境に対しての変更セットを受け付けるか個別に設定していくことになります。

「TSandbox」からの接続を許可したいので、「TSandbox」の左横にある「編集」をクリックします。

図4 リリース設定画面
図4 リリース設定の組織の一覧

「リリース接続の詳細」画面が開くので、「アップロード認識方向」内の「変更着信を許可」にチェックをつけて「保存」をクリックします。

図5 リリース接続の詳細
図5 リリース接続の詳細

「保存」をクリックすると「リリース設定」の画面に戻ります。

リリース設定画面を見ると、先ほど設定を行った「TSandbox」の右端にある「アップロード認証方向」が変わっていることがわかります。

このような表示になっていれば、リリース接続の設定は完了です。

これで「TSandbox」から「T2Sandbox」へ変更セットをアップロードできるようになりました!!

図6 T2Sandbox上でのアップロード認証方向の確認
図6 T2Sandbox上でのアップロード認証方向の確認

送信側のリリースの設定を確認

アップロードを行う前に、送信側の「TSandbox」のリリース設定を確認してみたいと思います。

「TSandbox」にログイン後、先ほどと同様の手順でリリース設定を開くと、「TSandbox」から「T2Sandbox」に向けて矢印がついていることが確認できます。

アップロード認証方向は現在ログインしている環境を基準に表示されるので、「TSandbox」と「T2Sandbox」で表示のされ方が違いますが認証方向に違いはありません。

次に、組織一覧の中の「T2Sandbox」横の「編集」をクリックして詳細を開いてみます。

図7 TSandbox上でのアップロード認証方向の確認
図7 TSandbox上でのアップロード認証方向の確認

詳細を開くと、すでに「変更送信を受け入れる」にチェックがついていることが確認できます。

こちら、画像では分かりにくいですが「変更送信を受け入れる」のチェックボックスは操作することができないようになっています。
このチェックボックスは対象組織の「変更着信を許可」と連動しているようです。

他組織の受け入れ設定を変更することはできないので、リリース接続の変更を行うときは先ほど「T2Sandbox」を設定したように設定変更したい組織にログインする必要があります。

図8 T2Sandboxのリリース接続の詳細
図8 T2Sandboxのリリース接続の詳細

ちょっと脱線:相互で変更着信を許可してみた

「TSandbox」のリリース設定の確認ができたところで、相互に「変更着信を許可」するとどうなるかやってみます。

図9 T2Sandboxも変更着信を許可
図9 T2Sandboxも変更着信を許可

保存をしてリリース設定画面に戻ってくると、「アップロード認証方向」の矢印が両方向に変わっていました。

それぞれ設定すれば相互にアップロードを許可できることがわかりました。(実際に設定するかは別として)

変更着信の設定は対象組織にログインすれば簡単なので、想定と違う組織にアップロードすることを防ぐためにもどの組織でどのように変更を許可しているかの管理は行わなければならないでしょう。

図10 TSandbox上で相互にアップロード認証を確認
図10 TSandbox上で相互にアップロード認証を確認

変更セットのアップロード再挑戦してみた

変更セットのアップロード:二回目

少し寄り道してしまいましたが、変更セットのアップロードに再挑戦します。

前回 と同様に「アップロード」をクリックすると、対象組織として「T2Sandbox」が表示されるようになりました。

「T2Sandbox」が選ばれていることを確認して、「アップロード」をクリックします。

図11 再アップロード
図11 再アップロード

今回は無事にアップロードができました!!

アップロードを行うのに少し時間がかかる場合がありますが、完了のメールも送られてきますよ。

図12 アップロード成功
図12 アップロード成功

アップロード前後の変更セットの違い

アップロード前後で何が変わるのか詳細画面を見比べてみました。

図13 アップロード前の変更セット詳細画面
図13 アップロード前の変更セット詳細画面
図14 アップロード後の変更セット詳細画面
図14 アップロード後の変更セット詳細画面

アップロード前後で変わることとして

  • 状況の変化
  • 「編集」ボタンの有無
  • 変更セットアップロード履歴の有無
  • 変更セットコンポーネントのアクションの変化

が挙げられます。

状況の変化としては、アップロード前が「オープン」アップロード後が「クローズ」に変化します。

また、アップロードするまではコンポーネントの追加及び削除といった編集を行うことができますが、アップロード後はそれらができなくなり、コンポーネントのアクションが「削除」から「ソースを表示」に変わります。

一番の違いは変更セットアップロード履歴の有無です。
アップロード後はどの組織にいつ誰がアップロードを行ったかという情報が追加されます。

あとがき

リリース接続を行うことで無事にアップロードができました。

後はリリースするだけ…となりましたが、変更セットのアップロードについて掘り下げていたら長くなってしまったので、リリースについては次回に持ち越したいと思います。
また、アップロード関連についてはまだ書き足りないことがあるので近いうちに別で紹介しようと思います。

リリースはあと少しで完了しそうですが、何事もなく進むといいな…

では、またお会いしましょう!!

関連記事
リリースしてみた<変更セット作成編>
リリースしてみた<リリース編>

AWS CLIで情報を出力しようEC2編(Linux版-その1)

1. AWS CLIを利用すると色々なリソース情報が見れます!

AWS EC2をコンソールから作成し、管理するサーバが多くなったら、一覧が欲しいですよね。
コンソールでは、分かり難いし、一覧を管理したい。そこで、AWS CLIコマンドを利用すると
EC2のリソース情報を取得し、且つ、必要な情報に絞って出力するように出来ます。
今回はEC2の情報を出力してみます。

2. まずはAWS CLIをインストールしよう!

Linuxのコンソール画面で以下のコマンドを実行してインストールします

$curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
$unzip awscliv2.zip
$sudo ./aws/install

3. AWS CLIを使ってみよう!

3.1 AWS CLI のバージョンを確認する!

aws --version
aws-cli/2.4.15 Python/3.8.8
 
最新でなかった場合はバージョンアップしましょう
バージョンアップ方法は以下です

3.2 AWS CLIのバージョンアップ方法!

curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update 
aws --version
aws-cli/2.4.29 Python/3.8.8

2022/03/28時点で最新バージョンです
詳しくは、以下を参照 AWS CLI 最新バージョンをインストールまたは更新する https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html

3.3 利用中のリージョンでec2 インスタンスの情報をすべて出力してみよう!

利用中のリージョンに存在するEC2インスタンスのすべての情報を出力するには以下のように記述します SQLの  select * from ec2 みたいなものです

aws ec2 describe-instances

画像A 出力結果
                 画像A 出力結果

Json形式で どばーっと出力されます

3.2 出力する情報を絞りこんでみよう!

上記コマンドでは沢山の情報が出力されるのでqueryオプションを使用して情報を絞り込みます
Sqlの select name,OS from EC2 みたいなものです。EC2名とOSに絞り込みます

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value}]" \
--out table 

画像B 2項目出力
                画像B2項目出力

queryオプションの設定は以下のようになります
Json形式で出力されるので、これを踏まえて絞り込む内容を記述します
まず、Reservations[*].Instances[*]   (画像C 階層) トップレベルがReservations
一つ下の階層がInstances これがリスト[]になっているので、
すべてを対象にする為に、Reservations[*].Instances[*] と指定します
更に下の階層(画像D PlatformDetails項目)の値と、
同じ階層にある(画像E Name項目)Tags:[0]リストの最初の項目Value値 を指定します
.[{OS:PlatformDetails,Name:Tags[0].Value}]
{key1:value,key2:value}のdict形式にフォーマットして、項目名と値を出力するようにする
--out table テーブル形式にすることで見た目が分かり易すくなります

画像C 階層
                  画像C 階層
画像D PlatformDetails項目
              画像D PlatformDetails項目
画像E Name項目
                 画像E Name項目

2.3 出力項目を増やしてみよう!(インスタンスタイプ)

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out table

画像F 3項目出力
                 画像F 3項目出力

追加したqueryオプションの設定は以下のようになります
[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]"
下の階層の (画像G Instancetype項目) の値を追加して、出力するようにする

画像G InstanceType項目
               画像G InstanceType項目

2.5 出力形式をTEXTに変更してみよう!

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out text

画像H Text形式
                 画像H text形式

Text形式で出力して、情報を加工し易くすることが可能になります

4 応用してみよう!

利用可能なインスタンスタイプ、アーキテクチャ、仮想化、プロセッサー、Hypervisorを
出力しよう。インスタンスタイプの変更可否(互換性)を確認したい場合に重宝します。

aws ec2 describe-instance-types \
--query "InstanceTypes[*].[{InstanceType:InstanceType,Hypervisor:Hypervisor, \
CPU:ProcessorInfo.SupportedArchitectures[0], \
Clock_Ghz:ProcessorInfo.SustainedClockSpeedInGhz}]" \
--out table

                 画像I 出力結果

5 感想

query を利用することで、必要な項目を絞ることができました。 jqを利用しても可能ですが、こちらを利用しても、同様のことができそうです。最初は書き方に悩みましたが、pythonのlist[],dict{}を連想すると、分かり易いです。次回はRDSの情報出力についてです。

参考URL AWS CLI の query による絞り込み
https://qiita.com/draco/items/fa09ae0c2f51de9de449

Linux版その2 RDSの情報出力  https://opt-p.co.jp/blog/aws/post-1718/

Linux版その3 VPCの情報出力  https://opt-p.co.jp/blog/aws/post-2080/

Linux版その4 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/

健康保険委員研修会

こんにちは!株式会社オプトプランニングです。

2022年3月11日金曜日、協会けんぽ広島支部様主催、令和3年度の健康保険委員の研修会があり、
当社も委員全員が受講しました。

コロナ禍ということもあり、2年ぶりの開催で、オンラインでの講座となりました。
オンライン会議は、どこでも、もうすっかりおなじみですね。

さて内容は、

①実務研修
②運動講座「かんたん美姿勢YOGA教室」
③メンタルヘルス講座「睡眠のチカラ」

の三部構成で全部で2時間の内容でした。

実務研修の中で筆者の印象に残ったことは、広島県の女性の健康寿命が低く、全国の47都道府県の中で44位で、かなり低いということです。

健康寿命を延ばすには、運動、栄養、早めの受診が必須とのことですが、
何かないと受診をしない県民性が反映しているとのこと。
まずは、個人からですが、何か不調があれば早めの受診を心がけようと感じました。
軽い症状のうちに受診したほうが、治療期間も短く、結果、医療費も抑えられることに繋がるとのことです。

運動講座のヨガ教室では、簡単にできる姿勢に挑戦!
思った以上に体が硬い!先生のポーズには驚きの連続でした!

最後に、メンタルヘルスですが、良質な睡眠は摂取する栄養にも関連するとのこと。
栄養、運動、メンタル、すべてが健康維持に重要な要素ですね。

今回受講した内容は社内報に掲載し、情報を共有し、
健康な会社人としての毎日につなげていきたいと思います!

リリースしてみた<変更セット作成編>

Salesforceでやってみた

はじめに

こんにちは!株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースをやってみようと思います!!

使用環境と内容

今回の使用環境は、先日作成した

  • TSandbox
  • T2Sandbox

以上2つのSandbox環境です。
これらを使用して、Sandbox to Sandbox のリリースを行います。

Salesforceでリリースを行うにはいくつか方法がありますが、今回は変更セットを使用したリリースを行います。

イメージとしてはこんな感じです。

図1 リリースのイメージ図
図1 リリースのイメージ図

内容は、1つの権限セットをリリースするものとなっており、プロファイルは含めません。

変更セットの種類

変更セットには「送信変更セット」と「受信変更セット」の2種類があります。

「送信変更セット」に開発した内容を詰め込んで、リリース組織にアップロードすると、リリース組織上には「受信変更セット」として変更セットがアップロードされます。

少しややこしいですが、送信側と受信側で「変更セット」の名称が変わるのだな、と覚えておけばいいと思います。

図2 リリースのイメージ図2
図2 リリースのイメージ図2

変更セットを作ってみた

送信変更セットの作成

早速変更セットを作成していきます。

TSandbox(開発環境)にログインし、設定の検索ボックスに「変更セット」と入力し、「送信変更セット」をクリックします。

下図のような「リソースの理解」という画面になった場合は下にスクロールして「次へ」をクリックします。

図3 送信変更セット:リソースの理解1
図3 送信変更セット:リソースの理解1
図4 送信変更セット:リソースの理解2
図4 送信変更セット:リソースの理解2

送信変更セットの画面が表示されました。

新規作成したいので「新規」をクリックします。

図5 送信変更セットの画面
図5 送信変更セットの画面

「新規変更セット」が立ち上がるので、ここに変更セットの名前と説明を入力していきます。
(図は2022年2月から必須になった多要素認証(MFA)に関する権限セットをリリースした時のもので、名前や説明欄にはその時の内容を入力しています。)

全て入力ができたら「保存」をクリックします。

図6 新規変更セット編集画面
図6 新規変更セット編集画面

コンポーネントの追加

次は、変更セットにコンポーネントや関係するプロファイルを追加していきます。

名前と説明の保存後、作成した変更セットの詳細画面が表示されるので、「変更セットコンポーネント」にある「追加」をクリックします。

図7 送信変更セット詳細画面
図7 送信変更セット詳細画面

コンポーネント選択画面に移動するので、追加したいコンポーネントの種類を選択します。

今回は権限セットを追加したいので、「コンポーネントの種類」の横にあるボックスをクリックして表示されるリストから「権限セット」を選びます。

図8 コンポーネントの種類クリック前
図8 コンポーネントの種類クリック前
図9 コンポーネントの種類クリック後
図9 コンポーネントの種類クリック後

コンポーネントの種類を選択すると、選択した種類のコンポーネント一覧が表示されます。
先ほど権限セットを選択したので、権限セットのコンポーネント一覧が表示されています。

一覧からリリースしたいコンポーネント名の左にあるボックスにチェックを付けて「変更セットに追加」をクリックします。

図10 コンポネント一覧
図10 コンポネント一覧

これで選択したコンポーネントは追加され、変更セットの詳細画面に戻ります。
ここで戻らない場合(たまに詳細画面に戻らない時がありました)は、左のリストにある「送信変更セット」をクリックしてみて下さい。

変更セットの詳細画面では、無事にコンポーネントが追加されていることが確認できます。

今回のコンポーネントはこの一つだけで関係するプロファイルも無いので、これで変更セットの作成は完了です!!

図11 コンポーネント追加後
図11 コンポーネント追加後

コンポーネント追加時の注意点

無事に変更セットが作成できたところで、私なりのコンポーネント追加時に注意したい点をいくつか挙げていこうと思います。

まず、コンポーネントは複数選択することができますが、一覧が複数ページで構成されていると、別ページに遷移した時点で選択していたコンポーネントは全て選択が解除されます。

コンポーネント一覧が1つのページ内に収まっていれば気にしなくていいです。
しかし、複数ページにまたがっている時は、ページごとに「変更セットに追加」を行う必要があることに注意して下さい。

また、チェックを付けた後にコンポーネントの種類を変更した場合も同様ですので、変更セットの追加はチェックを付けたページごとに行うよう心掛けた方がいいと思います。

もしも間違ったコンポーネントを追加した場合は、アクションにある「削除」でコンポーネントを削除することができますよ。

変更セットをアップロードしてみた

アップロードの実施

少し脱線してしまいましたが、変更セット詳細画面にある「アップロード」をクリックしてアップロードをやってみます。

図12 変更セット詳細のアップロードボタン
図12 変更セット詳細のアップロードボタン

対象組織が…ない?

アップロードをクリックした後、このような画面が出てしまいました。

「アップロード」ボタンはグレーアウトしており、

この組織は、他の組織に変更セットをアップロードする権限がありません。承認については、変更をアップロードする組織のリリース接続管理者にお問い合わせください。

というエラーが表示されています。

図13 アップロードエラー画面
図13 アップロードエラー画面

そうです、リリースは変更セットを作成するだけではできないのです…!

あとがき

送信変更セットを作成することはできましたが、それだけではリリースのためのアップロードができないということがわかりました。

このままではリリースができないため、次回はリリースのための準備を行います…!
(勘のいい方はタイトルで気づかれたかもしれませんね)

それでは、またお会いしましょう!!

関連記事
リリースしてみた<アップロード編>
リリースしてみた<リリース編>

認知症サポーター養成講座

こんにちは!株式会社オプトプランニングです。

突然ですが、皆さんは「認知症サポーター」をご存知でしょうか?

先日、当社はこの養成講座を受講しました。
取り組んでいる健康経営の一環として、またシニア採用戦略における予備知識として、
「健康で働ける時間を長く維持したい」、「若年性認知症について正しい認識を持ちたい」という経緯での受講となりました。

コロナ禍ということもあり、オンライン開催となりましたが、当社には大型画面があります。おかげで大変快適な環境で受講することができましたよ。


はじめに、実際の現場でホームヘルパーとして働かれている講師の方から「認知症とは?」というお話から始まり、「認知症」と「物忘れ」の違いや具体的な症状、そして、認知症の人への対応方法について教えていただきました。

認知症の人への対応で大事なことは、『3つの”ない”』ということでした。

①驚かせない
②急がせない
③自尊心を傷つけない


これは認知症の人だけでなく、子供やお年寄りの方へ接する時にも大変効果的なことだそうです。
普段から心掛けたいですね。


後半は、広島市幟町地域包括支援センターの職員の方から、広島市の認知症ガイドブックをもとにお話を伺いました。
実際、家族が認知症になったらどこに相談していいのか、どのような支援があるのか、など具体的なお話を伺うことができ、いざという時に大変役立つものだと感じました。


高齢化社会の中で、長く健康で、生き生きと働くために、自身の努力はもちろんですが、周りのサポートがあればさらにすばらしいですね。社内にとどまらず、家庭や地域の中でも助け合い、重要なことだと思います。

この度は、正しい知識を専門家の皆様から学ぶことができました。
お互いを思いやる気持ち、社内から広げていきたいです!

本番組織の開発者コンソールは何ができるかやってみた

Salesforceでやってみた

はじめに

こんにちは!株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回はSalesforce本番組織の開発者コンソールは何ができるのかやってみたいと思います。

開発者コンソールとは

開発者コンソールとは、Salesforceが提供する一連のツールを備えた総合開発環境です。
Webベースの開発環境なのでインストールなどの事前準備が不要で、Salesforce組織のアプリケーションの作成やデバッグ、テストなど様々な事が行えます。

そんな開発者コンソールですが、基本的には開発環境であるSandbox上で使用していると思います。
ですが、本番組織でも開発者コンソールを開くことができます。
本番組織とSandboxでできる事の違いがあるのか、違いがあればどんなところかを実際にやってみたいと思います。

本番組織の開発者コンソール

開発者コンソールを開いてみた

本番組織とSandboxで開発者コンソールの開き方に違いはありません。

「⚙」アイコンをクリックすると表示されるポップアップ内にある「開発者コンソール」をクリックすると開発者コンソールは開きます。

ここで「開発者コンソール」が表示されない場合は必要な権限設定が行われていないからかもしれません。
必要権限としては、システム権限の内

  • APIの有効化
  • すべてのデータの参照

の二つです。
この2つが有効になっていないユーザで操作している場合、開発者コンソールの表示はされないので注意してください。

図1 本番組織「⚙」押下後
図1 本番組織「⚙」押下後
図2 Sandbox「⚙」押下後
図2 Sandbox「⚙」押下後

早速、本番組織で開発者コンソールを開いてみましたが、Sandboxで開いた時と違いはありませんでした。

Salesforceにログインした時、Sandboxだと画面上部にSandbox名が表示されますが、そういったものもありません。
違いがなさ過ぎて、同時に開くとどっちがどっちかわからなくなってしまいそうです。

開発者コンソールは別ブラウザで開くので、別組織のものは同時に開かない方がよさそうですね。

図3 本番組織の開発者コンソール
図4 Sandboxの開発者コンソール

Apexを編集してみた

開発者コンソールを無事に開けたので、次は本番組織内にあるApexのファイルを開いて編集してみようと思います。
この時、システム権限として

  • Apex開発

が有効になっているユーザで操作しています。

そもそもApexのファイルを開けるかですが、こちらは問題なく開けました。

編集もできるか試してみます。
赤枠部分をコメントアウトしてみました。

赤枠部分のコメントアウトをすることができました。

次に、編集した内容をSaveしてみますが…

このようなエラーが出てしまいました…

Deployment Failed
Can’t alter metadata in an active org

何度か「Save」を試してみたところ、最初は「Save」をクリックした後エラーが出ていましたが、「Save」をクリックする前から表示されるようになってしまいました。

本番組織ではApexの編集を保存することはできません。

Apexクラスを変更したい時、Salesforce上だけで完結させるためには、Sandbox環境で編集を行い、本番環境に向けて変更セットをアップロード&リリースするしかなさそうです。

ちょっとした変更も例外なく変更セットを使用しなければならない点は要注意です。

クエリエディタを使ってみた

Apexの保存はできませんでしたが、開発者コンソールを開けるということは何かできるはず…

ということで、次はクエリエディタでSOQLクエリの実行を試してみます。

取引先のIDとNameを検索してみましたが、問題なく実行することができました!
本番組織上のデータの検索を行うことはできそうです。

あとがき

今回は本番環境の開発者コンソールでApexの編集とクエリエディタの使用をやってみました。

開発者コンソールは基本的にSandboxで使用するものという位置づけのようなので、本番環境からの使用はあまり期待しないほうがよさそうです。

他の機能についても、今後やってみたで検証できればと思います。

では、またお会いしましょう!!

削除後のデータについての気づき

気づき

はじめに

こんにちは!株式会社オプトプランニングです。
Salesforceでいろいろやってみた中での「ちょっとした気づき」を書いていこうと思います。

Salesforceの削除は、基本的に物理削除ではなく論理削除です。
このことについては多くの先輩方が詳しく説明して下さっているので私からの説明は割愛させていただきます。
論理削除ということで、レコード・カスタム項目・カスタムオブジェクトについて削除した後のデータについて気づいたことを書いていこうと思います。

また、普段Lightning Experienceを利用している場合の内容です。

レコードの削除後

削除後のレコードの行方は?

レコードの削除後、削除したレコードはどこにいくか知っていますか??
削除したレコードは一定期間「ごみ箱」にいます。

間違って削除した!!という時は「ごみ箱」を見てみましょう。

ごみ箱の場所は?

ごみ箱はアプリケーションランチャー内にあります。

左上にあるカラフルな9つの「・」をクリックすると表示されるポップアップの一番下にある「すべて表示」をクリックします。

図1 9つの「・」をクリック後に出現するポップアップ
図1 9つの「・」をクリック後に出現するポップアップ

アプリケーションランチャーが開くので、「すべての項目」を見てみましょう。
「ごみ箱」を見つけることができました。

図2 アプリケーションランチャー内にあるごみ箱
図2 アプリケーションランチャー内にあるごみ箱

削除したレコードはすべてこの「ごみ箱」の中に一定期間保管されています。
間違って削除したレコードはここから復元することができますし、完全に削除することもできます。

図3 ごみ箱の一覧
図3 ごみ箱の一覧

カスタム項目の削除後

削除後のカスタム項目の行方は?

カスタム項目の削除後、削除したカスタム項目はどこに行くか知っていますか??
削除したカスタム項目は一定期間「削除済みの項目」にいます。

間違って削除した!!という時は「削除済みの項目」を見てみましょう。

削除済みの項目の場所は?

削除済みの項目は各オブジェクトの「項目とリレーション」の右上にあります。

削除したカスタム項目は、カスタム項目を作成したオブジェクト詳細の「削除済みの項目」からでしか見ることができないことに注意してください。
レコードとは違い、削除後一か所に集約されているわけではありません。

図4 項目とリレーション右上にある「削除済みの項目」
図4 項目とリレーション右上にある「削除済みの項目」

間違って削除したカスタム項目はここから復元することができますし、完全に削除することもできます。

図5 削除済みの項目の一覧
図5 削除済みの項目の一覧

カスタムオブジェクトの削除後

削除後のカスタムオブジェクトの行方は?

カスタムオブジェクトの削除後、削除したカスタムオブジェクトはどこに行くか知っていますか??
削除したカスタムオブジェクトは一定期間「削除済みオブジェクトリスト」にいます。

間違って削除した!!という時は「削除済みオブジェクトリスト」を見てみましょう。

削除済みオブジェクトリストの場所は?

この「削除済みオブジェクトリスト」ですが、レコードやカスタム項目と違いLightning Experienceでは表示することができません。

ではどうすれば表示できるかというと…

Salesforce Classicだと表示できます!!!

長い道のり

まず、Salesforce Classicに切り替えましょう。

切り替えはプロファイルを参照すると表示される「オプション」内にある「Salesforce Classicに切り替え」をクリックするとできます。

図6 プロファイルからSalesforce Classicに切り替え
図6 プロファイルからSalesforce Classicに切り替え

Salesforce Classicに切り替えるとホーム画面が表示されます。

画面上部にある「設定」をクリックすると、

図7 Salesforce Classicホーム画面
図7 Salesforce Classicホーム画面

次のような設定画面に変わります。

この画面を下にスクロールしていくと左の赤枠部分に「ビルド」が出てくるので、その中の「作成」内に「オブジェクト」があるのでクリックします。

図8 Salesforce Classic設定画面
図8 Salesforce Classic設定画面
図9 「作成」内の「オブジェクト」
図9 「作成」内の「オブジェクト」

カスタムオブジェクトの一覧が表示され、最下部に「削除済みオブジェクト」というのが確認できます。
この「削除済みオブジェクト」ですが、削除したカスタムオブジェクトがない場合、表示されません。

図10 カスタムオブジェクトリスト
図10 カスタムオブジェクトリスト

こちらが探していた「削除済みオブジェクトリスト」です。
やっと見つかりました…!

削除したカスタムオブジェクトはすべてこの「削除済みオブジェクトリスト」の中に一定期間保管されています。
間違って削除したカスタムオブジェクトはここから復元することができますし、完全に削除することもできます。

図11 削除済みオブジェクトリスト
図11 削除済みオブジェクトリスト

おまけ

15日間以上削除されない…?

カスタム項目やカスタムオブジェクトを削除する前、注意事項がかかれたポップアップが出現すると思います。
以下はカスタム項目を削除する前に表示されるものです。

図12 カスタム項目削除時の注意事項
図12 カスタム項目削除時の注意事項

15日を過ぎると、自動的に項目とそのすべてのデータが完全に削除されます。

とありますが…
15日経過後も残っていました~

2021年12月1日に削除した項目が、2022年2月7日の時点で残っていることが確認できます。
約二か月経過していますね!

図13 削除後15日以降も残っていた削除済み項目
図13 削除後15日以降も残っていた削除済み項目

「15日を過ぎると」とありますが、「15日後」ではないのです。
もちろん、15日経過後はいつまでデータが残っているかはわかりませんので、あくまで「こんな事例もあったよ」という参考までに。

もし、15日以上経過後に削除したものを復元したい場合は念のため削除後の各データ保存場所を確認してみたほうがいいかもしれません。

また、15日以上経過していても完全削除されているとは限らない、という点は留意しておいたほうがいいと思います。

念のため復元できるか試したところ、復元できました!!

図14 削除済み項目復元
図14 削除済み項目復元

あとがき

今回きっかけとなったのは、削除したものの復元のためではなく、削除したものの完全削除のためでした。

データが残っている状態だと作業が進まず、完全削除を行おうにも「削除済みオブジェクトリスト」がみつからなかったのです。
私がSalesforceに携わった時には既にLightning Experienceが存在したので、Classicはあまりなじみがないのも原因ですぐに見つけることができませんでした。

プロファイルの設定を行っても一部権限が付与されている場合はSalesforce Classicに切り替えるスイッチャを非表示にできません。
今まで何故だろう?と思っていましたが、まだLightning Experienceで使用できない機能があるからなのだと身をもって体験でき、いい勉強になりました。

カスタムオブジェクトやカスタム項目の作成は近いうちに「やってみた」で書いていこうと思います。

それではまた会いましょう!!