コーソル DatabaseエンジニアのBlog へようこそ

コーソル DatabaseエンジニアのBlogでは、 コーソル所属のDatabaseエンジニアである 渡部と守田がOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。

コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス(コンサルティング、設計、構築など)、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。


コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。

hiring.png

コーソルについて知るためには・・・

エンジニアのスキル向上を支援する各種施策については・・・

コーソルのエンジニアの多くが従事する、「Oracle Database サポートエンジニアの仕事」の利点について知るためには・・・。

コーソルで働くことに興味を持たれた方は・・・

2018年12月13日

OCIオブジェクトストレージの論理構造とURL

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の13日目のエントリです。

領域の管理や事実上バックアップを必要としないオブジェクトストレージは、クラウドならではの本当に便利な機能です。 当然ながら、Oracle Cloud Infrastructure(以下OCI)にもオブジェクトストレージは用意されています。

OCIオブジェクトストレージの概要および特徴は以下の通りです。

1213_objstr01.png

OCIオブジェクトストレージの論理構造とURLの関係は以下の通りです。

1213_objstr02.png

論理構造における特徴を以下にまとめます。

  • 名前空間→バケット→オブジェクトという階層構造となっています。
  • バケットは特定のリージョンに存在
  • バケット名はリージョンと名前空間内で一意
    • AWS S3ではバケット名はグローバルで一意である必要がありました。これはバケット名を決める際に大きな制約になるため、OCIオブジェクトストレージの仕様はS3よりも適切であると考えます。
  • 名前空間はテナントに対応
    • 名前空間文字列はグローバルで一意
    • 名前空間文字列は変更不可
  • バケットはコンパートメントを用いて区分可能(リージョンには依存しない)

2018年12月12日

インスタンスプリンシパル (AWS IAMロールの代替)

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の12日目のエントリです。

Oracle Cloud Infrastructure(以下OCI)で認証および認可(権限)の役割を担うIAMの構成要素は以下の通りです。

1212_instprncpl01.png

ここで注意いただきたいのは、AWSで存在していたIAMロールがないという点です。 AWSのIAMロールにはいくつかの役割がありますが、最もよく使われる種類および使用形態は、EC2インスタンスに権限を委任するIAMロールだと思います。

このIAMロールを使うと、EC2インスタンスに認証のための秘密情報を保管する必要がなく非常に便利です。私も多くの用途で使用しています。これがOCIで使えないとなると非常に困るのですが・・・ 大丈夫です。代替となる機能、いや、より便利な機能として「動的グループ」と「インスタンスプリンシパル」があります。

1212_instprncpl02.png

1212_instprncpl03.png

動的グループとインスタンスプリンシパルを用いて権限を付与する方法の利点は、 権限を付与する対象となるインスタンスをルールベースで柔軟に指定できることです。

権限を付与するインスタンスをいちいち指定する必要がないため、インスタンスが多数ある環境では非常に便利です。

インスタンスプリンシパルを構成する手順

インスタンスプリンシパルを構成するには、権限を付与するインスタンスの条件を指定したマッチングルールを もつ動的グループを作成し、その動的グループに必要な権限を付与します。

1212_instprncpl04.png

1212_instprncpl05.png

マッチングルールの条件には、コンパートメントID、インスタンスID、タグを指定できますが、 柔軟性の観点からタグを基本的に使用することになるでしょう。

たとえば、あるコンパートメント内のタグtag1=val1のインスタンスを動的グループに含めるマッチングルールは以下のように書けます。

All {instance.compartment.id='ocidv1:compartment:oc1:phx:oc1:phx:...,', tag.mytags.tag1.value='val1'}}

インスタンスプリンシパルの枠組みは、条件ベースで対象インスタンスを指定できる点で柔軟性に富み、とても良いと思います。 ただ、現状だと、どのインスタンスがマッチングルールの条件に合致しているかを確認する方法がないため、 この方法が提供されるとさらに使いやすくなると思います。

また、Amazon EC2 の IAM ロールの場合と異なり、明示的にインスタンスプリンシパル認可を有効にする必要がある点に注意してください。

2018年12月11日

ポリシーステートメントのWHERE句

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の11日目のエントリです。

前日のエントリで、ポリシーステートメントの構文("Allow"の構文)を示しましたが、実はWHERE句に関する説明を割愛していました。

1210_iam02.png

WHERE句を使用しなくてもポリシーステートメント("Allow"文)を作成できますが、 WHERE句を使用せずにsubject / verb / resource-type / locationを使用するだけでは、操作許可の条件指定は比較的粒度の粗い制御にとどまります。 WHERE句を使用すると、subject / verb / resource-type / locationの指定に加えて、より粒度の細かい操作許可の条件指定を行なうことができるようになります。

1211_iam_pol_where01.png

WHERE句には条件を指定しますが、条件を満たす操作の実行が許可されます。 条件には変数を含めます。

1211_iam_pol_where02.png

以下に変数を用いたポリシーステートメントの例を示します。

# バケット一覧表示とBucketAの読み込み+ダウンロードを許可
Allow group ObjectReaders to read objects in compartment ABC
  where target.bucket.name='BucketA'

# バケット一覧表示とBucketAへのオブジェクトアップロードとオブジェクト一覧表示を許可
Allow group ObjectWriters to manage objects in compartment ABC
  where all { target.bucket.name='BucketA', 
              any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

# Administratorsグループ以外のグループのメンバーシップを管理を許可 
Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'

# ホーム リージョンがPhoenixのグループ メンバーだけが、IAMリソースを管理を許可
Allow group Phoenix-Admins to manage all-resources in tenancy where request.region='phx'

2018年12月10日

OCI IAMによる権限制御の概観

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の10日目のエントリです。

データベースなどと同様に、Oracle Cloud Infrastructure(以下OCI)でも役割の異なる複数のユーザーが、同一の環境(OCIではテナント)を使用します。このため、ユーザーの権限制御が必要です。以下にOCIの権限制御の概観を示します。

1210_iam01.png

特徴は以下の通りです。

  • ポリシーで権限を付与する
    • 1つのポリシーには1つ以上のステートメント("Allow ...")が含まれる
  • 権限を付与する対象はIAMグループ
    • 1つのIAMグループには複数のIAMユーザーを含むことができる
    • IAMユーザーに直接ポリシーを適用し、権限を付与することはできない
  • 実行可能な操作の内容は、操作レベル+リソースタイプで定義する(上記例ではmanage + instances)
  • 権限付与の適用範囲はコンパートメントを用いて限定できる

IAMユーザーにポリシーを適用できないのが、AWSと異なります。これは、昨今のセキュリティのベストプラクティスをふまえたものと思われます。(Oracle Databaseにおい て、ユーザーに直接権限を付与するのではなく、ロール経由で権限を付与することが推奨されるのと同じ考え)

ポリシーステートメントの構文("Allow"の構文)を以下に示します。

1210_iam02.png

特徴は以下の通りです。

  • 許可されるアクションに対応する"動詞"が4種類に限定されている
    • いたずらにアクションの種類を増やすと、理解と設計が困難になることを危惧しての設計と思われます。
  • "in compartment <コンパート名>"で権限の有効範囲を限定できる
    • 権限の有効範囲を全コンパートメント(=テナント全体)にしたい場合は"in tenancy"を指定する

若干細かい話ですが、管理コンソールにおけるポリシーの見え方がグループと同列である点には少し注意が必要です。

AWSでは、グループに対する属性的な形でポリシーが位置づけられているような、管理コンソールの画面設計になっています。

しかし、OCIではそのようには設計されていません。すなわち、グループを選択して詳細を確認しても、そのグループに適用されたポリシーを確認することはできません。 おそらく概念モデルとしては、ポリシーがグループの配下にある以下のような形ではなく、

グループ
  └ ポリシー ──→ リソース

ポリシーがグループとリソースの仲立ちをする以下のような形でとらえるべきなのでしょう。

グループ  ── ポリシー ─→ リソース

1210_iam04.png

2018年12月 9日

OCIセキュリティリストのステートフルルールとステートレスルール

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の9日目のエントリです。

8日目のエントリでも触れましたが、OCIのファイアウォール機能はステートフルとステートレスの両方に対応しています。 このステートフルとステートレスの概念はクラウド特有のものではなく、ファイアウォール機能一般の概念なのですが、あまり見通しのよい説明が世の中にないようであるため、ここでふれておきたいと思います。

1209_seclist01.png

ファイアウォールのステートフルルールとは

1209_seclist02.png

  • ステートフルルールは、ルールが許可する方向に設定されたコネクション内の通信を許可するルールです。
  • コネクション内ではコネクションの方向と同じ方向のパケット(行き方向のパケット)と、逆の方向のパケット(戻り方向のパケット)が送受信されるが、ステートフルルールでは、これら両方を許可します。
  • 戻り方向のパケットを許可するルールを設定する必要がなく使いやすいため、一般にステートフルルールが使用されるケースが多い

ファイアウォールのステートレスルールとは

1209_seclist03.png

  • ステートレスルールは、単純に指定した向きのパケット通信を許可するルールです。(コネクションは一切意識しません)
  • 戻り方向のパケットは自動的に許可されません。そもそも、コネクションという概念がないため、(コネクション内の)戻り方向のパケットという概念もありません。
  • 通常の通信プロトコルでは行きパケットと戻りパケットが行き来することで処理が進むため、行きパケットのみ通信許可されても処理が機能しません。戻りパケットも通信許可する必要があります。
  • ステートレスルールは使いにくいため、ステートフルルールで特段の問題がない限り、ステートフルルールを使用すべきです。

2018年12月 8日

OCIとAWSのネットワークの構成要素を比較する

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の8日目のエントリです。

これまでに何度か書いていますが、Oracle Cloud Infrastructure(以下OCI)の構成要素はAWSに類似しています。 ネットワークの構成要素について、OCIとAWSを比較した表を以下に示します。

1208_network_arch_comparison.png

主な構成はOCIとAWSでほぼ役割が同じですが、いくつか違う点があります。

  • AWSのファイアウォール機能は、ステートフルなタイプとステートレスなタイプで、異なる種類の機能を使用するが、OCIのファイアウォール機能はステートフルとステートレスの両方に対応している
  • パブリックIPアドレスの付与設定が異なる。OCIの方が、パブリックIPアドレスを付与するために必要な設定項目が多い。(むやみにパブリックIPアドレスを付与される事態を避けることを狙っている?)

また、参考のためVCN関連の図を以下に記載しておきます。

1208_vcn01.png

1208_vcn02.png

1208_vcn03.png

2018年12月 7日

Computeインスタンスのメタデータ

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の7日目のエントリです。

AWSのEC2インスタンス内部から http://169.254.169.254 にアクセスするとメタデータと呼ばれる インスタンス自身に関する管理情報を取得できます。

$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/

OCIのComputeインスタンスでも、同様の機能を利用できます。ただ、メタデータのリファレンスはない?(調べましたが見つかりませんでした)

# curl http://169.254.169.254/opc/v1/instance/
{
  "availabilityDomain" : "YORN:US-ASHBURN-AD-1",
  "faultDomain" : "FAULT-DOMAIN-2",
  "compartmentId" : "ocid1.compartment.oc1..aaa<略>gqa",
  "displayName" : "instance-20181127-0939",
  "id" : "ocid1.instance.oc1.iad.abu<略>dfq",
  "image" : "ocid1.image.oc1.iad.aaa<略>diq",
  "metadata" : {
    "ssh_authorized_keys" : "ssh-rsa AAA<略>w== rywatabe@rywatabe-t460s",
    "user_data" : "dW5<略>mVk"
  },
  "region" : "iad",
  "canonicalRegionName" : "us-ashburn-1",
  "shape" : "VM.Standard2.1",
  "state" : "Running",
  "timeCreated" : 1543279265705
}

残念ながらOCIのComputeインスタンスのメタデータは、得られるちょっと情報が少ない気がします。 個人的にAWSでよく使うので、OCIでもIPアドレス関連の情報は取れるようにしてほしい :-)

ただ、

で紹介されているoci-metadataコマンドでは、http://169.254.169.254/opc/v1/instance/ で得られる 以上の情報が表示されている・・・ どういう仕組みなのか、後で調べたいと思います。 :-)

2018年12月 6日

Computeインスタンスのコンソールへのアクセス

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の6日目のエントリです。

私が抱いているAWS EC2のへの不満の1つは、VMのコンソールにアクセスする機能が弱いことです。

セキュリティ強化のため、iptablesなどゲストOS側でファイアウォールの設定を変更するケースがありますが、 万が一設定をミスすると、ゲストOSにアクセスできなくなる場合があります。 VMのコンソールにアクセスできれば問題を解決することは容易ですが、 アクセスできないとディスクの付け替えなど面倒な手段に頼らざるを得ません。

OCIにはコンソールにアクセスする方法が2つ用意されています。

  • シリアルコンソールアクセス
  • VNCコンソールアクセス

ただし、あらかじめ構成が必要です。 手順はマニュアルなどに詳しく説明されていますが、 概要は以下の通りです。

  • OCIの管理コンソールで、該当Computeインスタンスに対して、"Console Connections"を作成する
    • このとき、sshの公開鍵を登録する
    • "Console Connections"の実体は、踏み台サーバ(instance-console.XXX.oraclecloud.com、オラクル管理と思われる)へのssh接続+踏み台設定と思われる
  • OCIの管理コンソールから確認できる踏み台サーバへのProxyCommandが指定されたsshコマンドを実行する
    • シリアルコンソールアクセスの場合: このsshコマンド実行による接続でコンソールへアクセスできる
    • VNCコンソールアクセスの場合: このsshコマンド実行により、ローカルフォワードによるポート転送が有効となる
  • (VNCコンソールアクセスの場合) localhost:5900を指定してVNCクライアントを実行する。ローカルフォワードによるポート転送により、ComputeインスタンスのVNCコンソールに接続される

なお、若干細かいですが、コンソールアクセスの注意点は以下の通りです。

  • パスワード認証を構成しておく必要があります。(メンテナンスモードなど特殊な起動モードの場合を除く)
  • 当然ですが、シリアルコンソールアクセスでログアウトしても、シリアルコンソールのsshセッションは継続します。この場合はsshクライアントを終了する必要があります。
    • マニュアルにも記載がありますが、OpenSSLのsshクライアントでは[ENTER]→[~]→[.]キーを押すと、sshクライアントを終了できます(知らなかった!)

https://euske.github.io/openssh-jman/ssh.html

-e エスケープ文字
仮想端末を使うセッションにおけるエスケープ文字を指定します(デフォルトは ~ )。エスケープ文字は行頭に来たときのみ認識されます。エスケープ文字のあとにドット . がきた場合その接続は閉じられ、control-Z がきた場合にはその接続はサスペンドされます。

シリアルコンソール接続時の画面キャプチャ

ssh_console.png

VNCコンソール接続時の画面キャプチャ

vnc_console (1).png

vnc_console (2).png

vnc_console (3).png

参考

2018年12月 5日

ブロックボリュームのアタッチメントタイプ

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の5日目のエントリです。

Oracle Cloud Infrastructure(以下OCI)のつくりはAWSに非常に似ているため、AWSのVPCを理解していればさほど苦労なくComputeインスタンス(VM、AWSにおけるEC2インスタンス)を作成できるはずです。

ただ、いくつか異なる部分もあります。個人的に驚いたのはVMにブロックボリュームを追加する際にiSCSIを使用して接続することです。正確には、iSCSIを使用した接続と、AWSのEBSに類似した準仮想化での接続の2つがあるのですが、性能の観点からiSCSI経由の接続が推奨されています。

正直言って、iSCSIを使用した接続方式の使い勝手はイマイチなのですが、オラクルがこの方式を推奨するのには性能面で明白なアドバンテージがあるのでしょう。(個人的な経験ですが、AWSではEBSの性能に苦しむケースが多いため、OCIではこのようなことがないことを期待しています)

iSCSIを使用してブロックボリュームを接続する手順は以下の通りです。

  1. ブロックボリュームをアタッチするComputeインスタンスは作成済みとする
  2. ブロックボリュームを作成する。このときボリュームサイズおよび配置先となる可用性ドメインを指定する
  3. Computeインスタンスにブロックボリュームをアタッチする
  4. このときアタッチメントタイプを指定する
  5. (アタッチメントタイプがiSCSIの場合)ComputeインスタンスでiSCSI接続用コマンドを実行する
    実行すべきiSCSI接続用コマンドは管理コンソールから確認可能

1205_iscsi_command.png

2018年12月 4日

OCID - OCIリソースの識別子

渡部です。これは、 (全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の4日目のエントリです。

OCIの構成要素であるリソースにはOCIDと呼ばれる識別子が付与されています。

1204_ocid.png

OCIのWeb管理コンソールのみを使用して管理操作を行う場合は、さほどOCIDを意識する必要はありませんが、 OCI CLIと呼ばれるコマンドラインの管理ツールを使用してOCIの管理操作を行う場合は、OCIDを意識する 必要がでてきます。

以下にOCI CLIを使用してIAMユーザーのOCIDを取得し、取得したOCIDを使用して、 IAMユーザーに対して操作(グループへの参加)を行う例を示します。 (OCI CLIについては後ほど触れる予定です)

$ # ユーザーを一覧表示
$ oci iam user list --all -c ${TENANT_OCID} --query "data[*].{id:id, name:name}" --output=table
+------------------------------------------------------------------------------+-----------------------+
| id                                                                           | name                  |
+------------------------------------------------------------------------------+-----------------------+
| ocid1.user.oc1..aaaaaaaa7zi...<略>.......................................ixa | admin01               |
| ocid1.user.oc1..aaaaaaaax2o...<略>.......................................f4q | noprivs01             |
+------------------------------------------------------------------------------+-----------------------+
$ # グループを一覧表示
$ oci iam group list --all -c ${TENANT_OCID} --query "data[*].{id:id, name:name}" --output=table
+-------------------------------------------------------------------------------+-----------------------+
| id                                                                            | name                  |
+-------------------------------------------------------------------------------+-----------------------+
| ocid1.group.oc1..aaaaaaaauqb...<略>.......................................u3q | Administrators        |
| ocid1.group.oc1..aaaaaaaazzp...<略>.......................................6oa | testgroup01           |
+-------------------------------------------------------------------------------+-----------------------+
$ # グループにユーザーを追加
$ GROUP_OCID=ocid1.group.oc1..aaaaaaaauqb...<略>.......................................u3q
$ USER_OCID=ocid1.user.oc1..aaaaaaaa7zi...<略>.......................................ixa
$ oci iam group add-user --user-id=${USER_OCID} --group-id=${GROUP_OCID}
{
  "data": {
    "compartment-id": "ocid1.tenancy.oc1..aaaaaaaa6sl...<略>.......................................faa",
    "group-id": "ocid1.group.oc1..aaaaaaaauqb...<略>.......................................u3q",
    "id": "ocid1.groupmembership.oc1..aaaaaaaad54...<略>.......................................c4q",
    "inactive-status": null,
    "lifecycle-state": "ACTIVE",
    "time-created": "2018-11-29T03:35:41.252000+00:00",
    "user-id": "ocid1.user.oc1..aaaaaaaa7zi...<略>.......................................ixa"
  },
  "etag": "1e079d4cf2d7b7553157b3ab67ec10b22f204317"
}

このようなOCIDですが、いかんせん長すぎる気がしませんか?

ただ、AWSで(おそらくリソースIDの桁不足により)リソースIDが8桁から17桁に拡張された例があります。 あとからこのような羽目になるぐらいなら、あらかじめ長くして置いたほうが良かろう・・・という判断なのかもしれません。

なお、OCIの管理コンソールにおけるOCIDの表示はうまく工夫されています。 デフォルトとではOCIを短縮表示して邪魔にならないようにしつつ、 "Show"リンクをクリックするとフル表示になります。 また、"Copy"リンクをクリックするとOCIDがクリップボードにコピーされます。

1204_ocid_show.png

1204_ocid_copy.png

投稿内容は個人の意見であり、所属企業・部門見解を代表するものではありません。

プロフィール

Ryota WATABE / 渡部 亮太

100x100.jpg

  • Oracle ACE
  • AWS Certified Solutions Architect - Associate
  • ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

Norio Morita / 守田 典男

Norio Morita

  • 新しもの好きな Oracle Fighter。
  • 保有資格 : ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数