SQL ServerのDBアカウントの権限管理を考える

■はじめに

SQL Severのアカウントを作成するときに、適切なアカウント管理をしたいと改めて権限管理について考えてみました。システム監査が行われるような企業では、必ずアカウント管理は問われる部分ですのでしっかりしていきたいものです。

本記事の想定環境

・MW: SQL Server 2017

■現状と課題

SQL Serverのアカウントは大きく、インスタンス範囲で権限を与える「サーバレベルのロール」と、データベース事に権限を管理する「データベースレベルのロール」の2種類があります。大きくサーバレベルのロールで一定の権限を制御し、データベースレベルのロールで複数あるデータベースについて細かく権限を制御する思想と読み取れます。

ただし、データベースレベルのロールは細かく権限が管理されていることから、1インスタンス上に複数のデータベースが作成されるような設計のサーバを運用する場合、規模にもよりますが下記2つの負担がどのシステム運用担当へかかるのかと思います。

• アカウント管理にかかわるサービス要求数が多いこと
• ユーザごとに細かい権限のリクエストがあり、一つずつ設定するのは手間がかかること

これらの負担に対しデフォルトの権限で管理している場合は、大体のユーザに必要以上のsys_admin権限や、db_owner権限を付与してしまいがちです。（やっちゃいけませんが）
強い権限があるとユーザはなんでもできてしまうので、オペレーションミスや悪意を持ったユーザにアカウントを乗っ取られたときのリスクは大きいです。そのため、最小権限でかつ簡易に管理できる解決策はないものかと考えていました。

■解決策

安直に考えた解決案は下記2つです。

1. アカウント管理システムを導入する

きめ細かいアカウント管理を行えるシステムを導入する。
アカウント管理システムを導入することで、申請書に基づいて自動でアカウント管理をしてくれることと、細かい権限が選択できることで上記2つの課題を解決することができると考えました。
ただし内製の場合、SQL Serverのエディション事に権限と機能が異なることと、これからの新バージョンが出来上がるたびにメンテナンスを行わないといけません。そのため、規模に応じて外部ソフトウェアを購入を検討してもいいかもしれません。
また、大きな会社だと会社としての内製のアカウント管理システムがあり、それが希望するDB製品に対応しておらず対応予定もないという悲しい結末に当たるかもしれません…

2. アカウントのロールを作成する

SQL Serverは「サーバレベルのロール」および「データベースレベルのロール」を作成することができます。
どのようなロールがあり、どのような権限があるとどのようなコマンドなどが実行できるかは、下記ポスターに一覧化されているので見ていただけるとわかりやすいかと思います。

aka.ms ※ダウンロードしておくのおすすめです。

どちらを作成するべきか？は組織の規模と、データベースの管理思想によって異なるためどちらがいいかは一概に言えません。個人的な意見としては、複数のインスタンスをまとめて管理しているときに、各インスタンス内のデータベース事に「データベースレベルのロール」を作成するのは面倒と感じてしまいます。そのため、アカウント発行先のチームごとに、「サーバレベルのロール」で大枠の権限を付与し、それでも制御できないかゆいところを「データベースレベルのロール」で補完する設計が管理上も楽になるのではないかと考えています。

■結論

会社の規模等により状況は異なりますが、個人的にはシステムで管理するのが一番楽と考えています。しかし、予算などの理由から難しい場合はロールで管理するで十分と考えています。ただし、ロールを作成して運用していたのち、システムを導入するとなった場合、独自のロールをインポートできるかどうか、インポートできない場合はどうするかは要件定義の時にしっかりと検討していただきたい点です。

■終わりに

アカウント管理はシステム運用開始してから、システム運用終了までずっと付きまとう業務です。この業務をどこまで楽にできるようにしておくかで、システム運用後のランニングコストに響いてきますので、導入時に検討していただく価値はあると思っています。

SQL Serverは「アプリケーションロール」というロールもあるようです。ただ、今までずっとSQL Serverの面倒を見てきましたが、「アプリケーションロール」を設定したいというサービス要求などは全くありませんでした。この機能をうまく使うベストプラクティスは謎です。ただ、このロールを使わなくても「サーバレベルのロール」および「データベースレベルのロール」で十分なため深く考えないようにします。詳しい方でこんな時に使うと便利だよなど知見があれば教えていただきたいです。

■参考

毎度ながらマイクロソフト様のドキュメントを参考にしています。

• データベース エンジンの権限の概要 - SQL Server | Microsoft Docs

• https://aka.ms/sql-permissions-poster

番組表アプリの作成を検討した結果：没

今日は番組表みたいなカレンダーアプリがあったら便利なのではないか？ということで草案をぱっと考えていましたが、あまり効果がでなさそうだったのでその没案をまとまりなくグダグダと書き連ねたいと思います。

■はじめに（動機）

日本にはN〇Kや民放が多く存在します。そして各放送局それぞれが番組表を持っています。
またそれだけではなく最近はWebの番組も増えてきており、Youtubeやニコニコ生放送などの番組も充実しています。
そのため、新聞に記載されているテレビ番組表だけでは足りないのではないか？というのがきっかけです。

■必要な機能について

個人的にあったらいいのではないかと検討した機能は下記となります。

• 自分の好きな番組をかき集めたマイカレンダー機能
  番組を登録してカレンダーに反映するし表示する機能

• リマインダー機能
  時間になったらpush通知してくれる機能

これぐらいシンプルでも十分じゃないかと思いました。

■実現方法について

好きな番組の情報（番組名、日時）をカレンダーに登録し、日時が近くなったらpush通知するだけです。
ただ、工夫が必要だと思った点は、カレンダーの登録機能です。ユーザが手入力ですべて入れるのはとても面倒です。そのため、下記機能も必要かなと追加で考えました。　

• 番組表を見れて好きな番組を選択するだけにする
  この機能の実現には、各放送局のテレビ番組表をスクレイピングして作成する。もしくは、すでにテレビ番組表のデータを配信しているAPIを探してそれを呼び出すなどの選択肢があります。スクレイピングするにしても100局以上のサイトを個別に解析してメンテナンスするのは大変そうです…

■没にした理由は下記3つです。

・家電への連携機能の検討が必要

今の時代はレコーダーなどが優秀なので、気になったテレビ番組は簡単に録画して後から見れるようになりました。
そのため、それらの家電への連携機能がないと実用性が少ないのではないかと感じました。

・Webの番組を選択する方法の難しさ

これが課題にぶち当たりました。youtubeなどではチャンネル登録しておけばその情報が手に入ります。ただ、チャンネル登録していないと何も情報が入りません。そのうえ放送されるコンテンツの数に制限はありません。そのため手で入力せざるを得ないのではないかと思った次第です。

・Googleカレンダーがすでに優秀

これ専用のアプリを作るまでもなく、Googleカレンダーがとても優秀なことです。メールしたらカレンダーに反映したり、リマインダー機能があるのでこんなアプリを作らずとも困ることはない点です。そのあたりは差別化がとても難しいです。

■おわりに（結論）

単純なアプリもなかなか作ろうと思ったときに費用対効果を考えると手がでなくなってしまいました。

最近知ったのですが、私は東京にずっといるのでテレビ番組のチャンネルはたくさんあるもんだと思っていました。ただ、都道府県によっては民放が数局しかないところもあるそうです。そういった地域の方々がWeb番組などをたくさんみているんでしょうか。見逃し配信サイトとかで見ている人達の都道府県のデータを取ったら何か面白いことできそうです。

また、最近は見逃した番組もあとからインターネットで簡単に見れる時代になりました。そんな中でリアルタイムで見たいテレビ番組って何があるだろうか？って考えたときに思いつくのは、音楽のライブ、スポーツなどかと思いました。どちらも共通するのは生中継であることがポイントで、どうなるかわからない結果を共有しながら楽しむところにリアルタイムでみたいと感じるポイントがあるのかなと個人的に思いました。

SQL Server 2017で可用性グループにDBを追加する際の備忘録

可用性グループの構築の仕方がなしにいきなりDBを追加する際の備忘録となってしまいました。おいおい可用性グループの構築の仕方も作成したいと思います。

■はじめに

Microsoft様のサイトに事前チェックリストがあるのでそれを見ればいいのですが、可用性グループに追加するときに躓いた点がありましたので忘れずに記録しておきます。

■既存の可用性グループにDBを追加する際の備忘録

とりあえず下記が大事です。

1. 追加するデータベースのログレベルは「完全」となっていること
2. 追加するデータベースの完全バックアップを取得していること
3. 可用性グループを構成するノードすべてが正常な状態であること
4. セカンダリレプリカのDBでは「RESTORE WITH NORECOVERY」でバックアップファイルからDBを復元し、
   「可用性グループへの結合」を選択する。

ここまで終わってやっと可用性グループに追加でき状態が同期済みになりました。慣れるまで少し大変そうです。

■おわりに

運用時の制限はかかってしまうけれど、それ以上の効果があると期待しているので可用性グループを触って覚えるは継続していきたいと思います。記事の内容に誤りなどありましたら、コメントで教えて頂けると助かります。

■参考

下記ページに記載がありました。 *

可用性グループの前提条件、制限事項、推奨事項 - SQL Server Always On | Microsoft Docs

SQL Serverの高可用性を考える

SQL Serverを用いたシステム構成を考えるために学習したのでまとめたいと思います。

■はじめに

高可用性をなぜ実現するのか。というのが最近の私の頭の隅から離れない質問です。 個人的にはこの質問についての回答がスムーズにでるシステムと、そうでないシステムがあります。回答がスムーズなシステムは停止したときの影響が大きすぎるということ、そうでないものは影響はあるがある程度許容されるものとなります。後者については私の個人的な意見のため、システム担当からは重要だ！って言われるのですが、その重要性の物差しは人それぞれなのが難しいです。

そんなこんなでSQL Server 2016を用いた高可用性のパターンとメリットデメリットを考えていきたいと思います。こちらの記事はオンプレミスの環境を想定していますので、Azuruなどには当てはまらない点があるかもしれません。

■SQL Serverの高可用性のパターン

SQL Serverの高可用性を実現する手法は下記2パターンについて勉強したことをまとめたいと思います。

• Always on 可用性グループ ( Availability Group：AG )
• Always on フェイルオーバー クラスター インスタンス ( Failover Cluster Instance：FCI )

・Always on 可用性グループ ( Availability Group：AG )

SQL Server 2012以降で登場した機能となります。特徴は複数台のノードでクラスタを構成した際、プライマリのノードからセカンダリレプリカのノードに対してデータの同期を行うことで、各ノードのローカルディスクにデータが保存される仕組みとなっています。ただ、この仕組みを実現するうえでは、ノード間のデータ同期が必要になってくるため性能は出にくい構成となってしまいます。Enterpriseエディションでは3台以上でクラスタ構成を組むことも可能とのことです。イメージ図としては下記となります。

図1: Always on 可用性グループのイメージ図

プライマリノードに障害が発生した場合は、セカンダリレプリカにフェイルオーバー（セカンダリのノードがプライマリに昇格）し機能を継続して提供します。プライマリにアクセスする処理は、リスナーに対してアクセスしていればプライマリが変更になった際に最新のプライマリに対してアクセスします。また、クラスタに参加するノードにて投票を行っており、クラスタを構成するノードの半数以上に障害が発生した場合は、処理を停止する仕組みとなっています。

図2: Always on 可用性グループの障害時の様子

運転面では、masterやmsdbなどは可用性グループで同期されないため各ノードにアカウント等を整備する必要があることと、データベースを追加した場合は可用性グループを再構成しないとレプリカが作成されないためメンテナンス作業は気を付ける必要があります。

・Always on フェイルオーバー クラスター インスタンス ( Failover Cluster Instance：FCI )

SQL Server 2008 R2以前のSQL Serverでおなじみの高可用性の実現パターンとなります。私もこのタイプの高可用性のサーバのメンテナンスをしてきました。特徴としては2台のアクティブ/パッシブ構成のクラスタを作成し、クラスタリソースの共有ディスク上にデータベースファイルを格納することで、障害時に共有ディスク毎パッシブのノードに移動させることで稼働を続ける方式となります。このタイプは共有ディスクを有することから、共有ディスクが単一障害点となってしまう潜在的な問題があります。ただ、構成はシンプルのため運用もしやすいメリットを感じています。

図3: フェイルオーバー クラスター インスタンスのイメージ図

障害時はアクティブのノードからパッシブのノードにクラスタリソースが移動して機能を継続します。

図4: フェイルオーバー クラスター インスタンスの障害時の様子

こちらの構成は、masterやmsdbもクラスタリソース配下にあるので、アカウントやデータベースの操作はアクティブ系で操作した内容がフェイルオーバー後も継続するのでメンテナンスは簡単です。

■メリットとデメリット

先ほどの二つの高可用性の実現方法について表にまとめます。

項目	可用性グループ	フェイルオーバー クラスター インスタンス
WSFCを構成する必要がある	〇	〇
共有ディスクを必要とする	×	〇
単一障害点が存在する	×	〇
メンテナンスが容易である	△	〇
性能が出にくい	〇	△

性能が出にくいについてはノード間の読み書きによるものがあるので、一概に性能がでないというわけではないので注意してください。FCIでも共有ディスクが他のアプリケーションが高IOPSを発生させていたら性能が出ないこともありますので、環境によるところが大きいです。

■終わりに

性能よりも耐障害性を重要視されるため、個人的には可用性グループを推したいと思っています。ただ性能が出にくいという点があるため、十分に性能検証を行ってから商用のリリースを計画したいところです。Virtual boxで可用性グループを構築し機能検証していきたいと思います。

■参考

アイコンは「さくらのアイコンセット」を利用させていただきました。また、Microsoft様の参考ページを列挙します。

• システム構成図やプレゼンテーション資料などで自由に使える「さくらのアイコンセット」を公開いたしました。 | さくらのナレッジ

• SQL Server のディザスター リカバリー - SQL Server | Microsoft Docs
• Always On 可用性グループとは - SQL Server Always On | Microsoft Docs
• Windows Server フェールオーバー クラスターと SQL Server - SQL Server Always On | Microsoft Docs

SQL Server 2008 R2のサポート終了からアップグレードを考える

いままでSQL Serverは2008 R2までしか触ったことがなかったのですが、この度SQL ServerのEOSLのお仕事が発生しそうなのでブログにまとめていきます。この記事が多くの人の参考になったら幸いです。

■はじめに

まず直近サポート終了を迎える製品とサポート終了日を改めて確認しましょう。

製品名	リリース日	メインストリーム サポート終了日	延長サポート終了日
Windows Server 2008	2008年5月6日	2015年1月13日	2020年1月14日
Windows Server 2008 R2	2009年10月22日	2015年1月13日	2020年1月14日
SQL Server 2008	2008年11月7日	2014年7月8日	2019年7月9日
SQL Server 2008 R2	2010年7月20日	2014年7月8日	2019年7月9日

このようになっており、SQL Server 2008およびSQL Server 2008 R2については今年の7月で、Windows Server 2008およびWindows Server 2008 R2については、来年1月で延長サポートが終了します。
延長サポートが終了すると、プレミアサポートに問い合わせても有意義な回答が得られなくなるため、障害が発生した場合に根本原因の解決などが難しくなります。また、基本的にセキュリティパッチの配布も終了するため、セキュリティリスクを抱えてしまいます。

そこで、まずはアップグレードを行う場合の製品は何があるのか、何を考えないといけないのかまとめていきたいと思います。Windows系にアップグレードする話になりますのでご了承ください。

■アップグレード後の製品選定

アップグレードする対象のWindows系のライフサイクルを確認します。

製品名	リリース日	メインストリーム サポート終了日	延長サポート終了日
Windows Server 2012	2012年10月30日	2018年10月9日	2023年10月10日
Windows Server 2012 R2	2013年11月25日	2018年10月9日	2023年10月10日
Windows Server 2016	2016年10月15日	2022年1月11日	2027年1月12日
Windows Server 2019	2018年11月13日	2024年1月9日	2029年1月9日
SQL Server 2012	2012年5月20日	2017年7月11日	2022年7月12日
SQL Server 2014	2014年6月5日	2019年7月9日	2024年7月9日
SQL Server 2016	2016年6月1日	2021年7月13日	2026年7月14日
SQL Server 2017	2017年9月29日	2022年10月11日	2027年10月12日

どの製品を選んでも東京オリンピックは超えられそうですね。製品選定の時は下記3つの視点で製品を提案しています。それぞれ書いていきたいと思います。

1. お客様が何年継続して利用しようとしているか

お客様へのヒアリングによりますが、SQL Server 2008/SQL Server 2008 R2の場合10年程度使い続けてEOSLを迎えているため、この先もなんだかんだで長く使い続けるのではないかと個人的には思います。そのため、一つ先のバージョンだと再びEOSLを迎えてしまう可能性がありますので、最新もしくはその1つ前の安定している製品を選びたい。この視点からだと…

• OS: Windows Server 2008/Windows Server 2008 R2 ⇒ Windows Server 2016
• DB: SQL Server 2008/SQL Server 2008 R2 ⇒ SQL Server 2016

を提案します。もちろんお客様から製品の要望があった場合はその製品で考えますし、お客様の中長期的なIT戦略も考慮が必要です。

2. 改修コストはお客様の見積もりの範囲に収まりそうかどうか

改修コストの見積もり方は経験から算出していることが多いと思いますので割愛します。気を付けるポイントを記載していきます。

• OSにインストールしているアプリケーションを継続利用できるかどうか。
  あるあるですが特にWindows Server 2008は32ビットのOSも存在するため、対象サーバのインストールソフトウェア一覧から対応有無を確認することが必要です。製品によってはライセンスの買替えが必要となる場合があります。

• DBへの接続ドライバーは問題ないか。
  MicrosoftのページにSQL Serverのドライバーのページがありますので確認をしてください。例えばJDBCではSQL Server 2017に対応しているドライバーはJRE 1.8以降となっているため、お客様のアプリケーションがJRE 1.8未満の場合はJavaのバージョンアップが必要になる可能性があります。

3. 必要な機能が実装されているかどうか

最後はリリース後の運用なども考えた際に必要な機能が実装されているかどうかを確認してください。先の改修コストにもかかってきますが、SQL Serverの場合は、EnterpriseエディションとStandardエディションで利用できる機能が異なってきます。また、SQL Server 2016からはデータベースミラーリングが非推奨となり、Standardエディションでも2台のAlways on 可用性グループを構築できるようになるなど機能ももちろん追加されています。この辺りは自習書などが参考になります。

■その他：Azureへの移行

オンプレミスの環境からAzureに移行すると3年間はセキュリティ更新プログラムを無償提供していただけるそうです。これを機にAzureへの移行も一つの手段です。ただ3年間なので3年以内に再度対応を考えないといけません。

■おわりに

今から延長サポート終了までになんとかして！っていう駆け込みのお客様は多いかも知れません。きちんと工期と工数を確保し、十分に検証してからリリースできるスケジュールを立てさせてくれるお客様の案件を選びましょう。
記事に誤りなどありましたらコメントにてご指摘お願いします。

■参考文献

参考になるMicrosoft様のページを張っておきますので参照ください。

• SQL Server 2008 と Windows Server 2008 のサポート終了に伴う新たな選択肢のお知らせ | ブログ | Microsoft Azure

• Microsoftライフサイクルポリシー
• SQL Server — 価格とライセンス | マイクロソフト

• Microsoft SQL データベースの接続ライブラリ - SQL Server | Microsoft Docs

• Microsoft SQL Server 用 JDBC Driver のサポート表 - SQL Server | Microsoft Docs

• SQL Server 2017 の各エディションとサポートされている機能 - SQL Server | Microsoft Docs

VirtualBoxでAnsible環境を整える-Ansible環境実験編

前回投稿してから間が空いてしまいましたが最後のAnsibleの実験に移りたいと思います。
ここではAnsible環境の構築から、Ansibleを使ってwgetのインストールまで出来たらいいなと思っています。

■記事の最終目標

最終的なゴールはAnsibleの実験がしたいので3つゲストOSを構築していきたいと思います。記事の構成としては1つの記事だと長くなりそうなので下記構成で作っていきたいと思います。

• 構成設計編
• VirtualBox操作編
• Ansible環境実験編

■Ansible環境の準備

ansibleはyumでインストールしていきます。

%yum install ansible
%ansible --version

ansibleの2.4.2.0がインストールできました。

■ansibleコマンドのテスト

この段階で下記のようにansibleコマンドを実行してみるとエラーとなりました。

%ansible 10.0.2.5 -m ping

どうやらhostファイルにIPの記載がないとansibleは実行できないように制御されているようです。 そのため、直下にhostlistというファイル名で下記内容のファイルを作成します。

10.0.2.5
10.0.2.7

このインベントリファイルを読み込むようにして実行してみます。

%ansible -i hostlist 10.0.2.5 -m ping

またまたエラーとなりました。ansibleを実行するには対象サーバと認証を行う必要があるとのことで、ssh-key genとssh-copy-idを用いて認証するようにします。

%sshkey-gen
%ssh-copy-id 10.0.2.5
%ssh-copy-id 10.0.2.7

これでやっとpingが成功するようになりました。

%ansible -i hostlist 10.0.2.5 -m ping

実行結果は下記のようになりました

10.0.2.5 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

■Playbookの作成と実行

wgetのコマンドを各サーバにインストールするplaybookを下記に作成しました。

- hosts:  all
  tasks: 
    - name: wget command
      yum:
        name: wget

このplaybookを実行してみます。

%ansible-playbook -i hostlist wget.yml

エラーなく実行されたので、ターゲットのサーバにログインしwgetコマンドを確認してみます。

which wget

/bin/wgetに存在することが確認できました。またyum historyでyumのインストール履歴を見てみたのですが、どうやらansibleでインストールされるとhistoryには出てこないようでした。

■まとめ

rootですべて操作するのはよろしくないのでアカウントの制御はどこかで実施が必要そうです。参考に記載したサイトをもとに権限回りなど整理したいと思います。最後はやっつけ感満載なので、必要になった時に再度勉強していきたいと思います。

おわりに

記事を書きながら操作しているので、後続の過程でうまくいかなかった時は内容を修正することがありますのでご容赦ください。また、内容に誤りなどありましたらコメントにてご指摘お願いします。

■参考

これらの記事がとても参考になりました。製作者の皆様に感謝です。

• Ansibleのインストールとサンプルコードの実行 | Think IT（シンクイット）
• Best Practices — Ansible Documentation
• CentOS7でユーザーを作成しSSH接続を行う - Qiita

VirtualBoxでAnsible環境を整える-VirtualBox操作編

先の記事で検討した構成に沿うようにVirtualBoxを操作していきたいと思います。

■記事の最終目標

最終的なゴールはAnsibleの実験がしたいので3つゲストOSを構築していきたいと思います。記事の構成としては1つの記事だと長くなりそうなので下記構成で作っていきたいと思います。

• 構成設計編
• VirtualBox操作編
• Ansible環境実験編

■はじめに

VirtualBoxを含め今回の環境は下記となります。VirtualBoxのインストール方法などはいろいろな方がまとめてくださっているので、そちらの記事をご覧ください。 また、今回3台ゲストOSを作成しますが、1台を作成した後はクローン機能を用いて1台目のVMイメージから2台目、3台目を作っていきたいと思います。

■環境

• ホストOS: Windows 10 home 64bit
• VirtualBox: 6.0.6

〇NATネットワークの作成

最初にNATネットワークを作成していきます。VirtualBox マネージャーから作成します。 マネージャー画面にある「環境設定(P)」を押下します。

環境設定ウィンドウから「ネットワーク」を選択し、画面右側のネットワークカードのようなアイコンを押下します。

先の手順でNATネットワークが作成できました。作成したNATネットワークの詳細を確認するためにダブルクリックします。

ネットワーク名は特に考えていなかったのでデフォルトのまま変更しないようにします。ネットワークCIDRは設計図通りになっていること、ネットワークオプションでDHCPのサポートにチェックを入れます。IPv6は今回利用しませんのでチェックなしのままにしておきます。

〇CentOSの仮想マシンの作成-1台目

仮想マシンを作成していきます。新規で仮想マシンを作成するときは、VirtualBox マネージャーから「新規(N)」をクリックします。

今回はエキスパートモードで設定をしていきます。そのためウィンドウ下部の「エキスパートモード(E)」を選択した画面で入力していきます。まずは仮想マシンの設定です。構成設計で定義した名前にし、マシンフォルダーにVMのファイルを配置するフォルダーを指定します。タイプとバージョンについては、今回CentOSのマシンを作成するので、タイプはLinux、タイプはRed Hat(64bit)を選択します。サーバのスペックについては、ホストOSのスペックによりけりですが最小構成にし、ウィンドウ下部の「作成」をクリックします。

次に仮想ハードディスクの作成です。ファイルサイズはディスクに余裕があるので20GBを設定します。ハードディスクのファイルタイプなどは変更せずにそのままウィンドウ下部「作成」の作成をクリックします。VMDKファイルってVMWare用のフォーマットな記憶があるので、ここでイメージを作ってVMWareの環境にそのまま持っていけるのでしょうか。

ここまで出来たらウィンドウは閉じてVirtualBoxマネージャーの画面に戻りました。 作成した仮想マシンの設定をしていきます。作成した仮想マシンを選択し「設定(S)」をクリックします。

ネットワークの設定がデフォルトだと「NAT」になっていると思うので、これを先に作成したNATネットワークに変更して、「OK」をクリックします。

仮想マシンを起動します。VirtualBox マネージャーから「起動（T）」をクリックします。

初回起動時は起動ハードディスクを選択するウィンドウが表示されます。フォルダのアイコンをクリックして、CentOSのサイトからダウンロードしてきたisoファイルを選択して「起動」をクリックします。

画面キャプチャが取れなかったのですが、CentOSのisoファイルから何するか選択する画面が出てくるので、「Install CentOS 7」を選択します。ここからはCentOSのインストール設定なので画面キャプチャなどはなく、淡々と描きパラメータシートに従ってインストールしていきます。その際ネットワークとホスト名のネットワーク構成情報は念のため画面キャプチャを取得しておきます。インストールが完了すると再起動を行います。VirtualBoxの画面をクリックするとカーソルが仮想マシン上に移ってしまいホストOSに戻ってきません。Windows OSではデフォルトで右側のCtrlキーを押下することでホストOSの操作ができるようになりますので覚えておくこと必須です。

CentOSパラメータシート

項目	設定値
言語	日本語(日本)
日付と時刻(T)	アジア/東京 タイムゾーン
キーボード(K)	日本語
言語サポート(L)	日本語(日本)
インストールソース	ローカルメディア
ソフトウェアの選択-ベース環境	インフラストラクチャーサーバー
ソフトウェアの選択-選択した環境のアドオン	☑ 開発ツール
インストール先	ローカルの標準ディスク ATA VBOX HARDDISK
KDUMP	☑kdumpを有効にする
KDUMP-Kdumpメモリー予約	自動
ネットワークとホスト名-ホスト名(H)	ansiblecontrol
ネットワークとホスト名-enp0s3	オン
SECURITY POLICY	プロファイル未選択
ROOTパスワード(R)	任意のパスワードを設定
ユーザーの作成(U)	ユーザは作成されません

再起動が完了したら、先ほど作成したrootアカウントでログインできるはずです。ログインできたらインストールまでは問題なく完了です。

〇CentOSの仮想マシンの作成-2台目, 3台目

先ほど作成したVMイメージをもとに2台目、3台目を構築していきます。1台目のVMイメージを静的な状態にしたいこととクローンした後にサーバのIPアドレスとホスト名がバッティングするので、1台目のVMが起動しているようでしたらshutdownします。shutdownが完了したらVirtualBox マネージャーからクローンを作成する仮想マシンを右クリックし、出てきたメニューから「クローン(O)」を選択しクリックします。

先ほどと同じくエキスパートモードで設定を行います。名前は構成設計通りに「CentOS01」とし、パスはクローンした仮想ファイルを配置する任意のフォルダを選択します。クローンのタイプはディスクに余裕があるので、「すべてをクローン(F)」、スナップショットは「現在のマシンの状態(M)」を選択します。追加オプションのMACアドレスのポリシーについては、MACアドレスは重複しないようにしたいので、「すべてのネットワークアダプターでMACアドレスを生成」を選択します。今回クローン元と同じドライブに配置するので追加オプションは何もチェックしないまま、「クローン」をクリックします。

無事にクローンが完了するとクローンして作成した仮想マシンが表示されます。このマシンを起動します。

サーバにログインするとホスト名とipアドレスがクローン元と一緒なので、ホスト名を下記コマンドで変更して再起動します。ipアドレスはDHCP設定で固定化できないので時間があったら固定したいと思います。

% nmtui
% reboot

OS再起動後にhostnameコマンドでホスト名が変わっていれば完了です。同様にもう一台クローンを作成します。

〇ポートフォワーディング設定

ここまでで3台の仮想マシンが作成できました。Ansible管理用サーバにホストOSからssh接続できるようにポートフォワーディング設定を行います。ポートフォワーディングはNATネットワークに設定します。NATネットワーク作成時と同様に「環境設定」>「ネットワーク」＞NATネットワークを選択し、詳細ウィンドウで「ポートフォワーディング」をクリックします。

画面右側の緑の十字のボタンをクリックし、ホストOSのIPアドレスと、ゲストOSのIPアドレスを確認してルールを記載し、「OK」をクリックします。

ホストOSからTeraTermで自身のIPアドレスの22番ポートに接続すると、対象のゲストOSへssh接続することができました。ここまででひとまずVirtualBox操作編は終了とします。IPアドレスの固定化ができていないのが残念ですが、一度きりの環境の構築はできました。

おわりに

記事を書きながら操作しているので、後続の過程でうまくいかなかった時は内容を修正することがありますのでご容赦ください。また、内容に誤りなどありましたらコメントにてご指摘お願いします。

■参考

これらの記事がとても参考になりました。製作者の皆様に感謝です。

• VirtualBoxのネットワーク設定についてまとめてみた | watobako
• VirtualBoxのNATとホストオンリーアダプターによるネットワーク設定のベストプラクティス！〜安全かつ快適な開発ができるようにする〜 - Qiita