「WACATE 2019夏 ～納期半端ないって～」初参加の記録
お疲れ様です。前回の記事からだいぶ期間が空いてしまいました。。
2019/06/15(土)- 16(日) の2日間、テスト業界では名の知れたワークショップ WACATE に初参加してきました。
ので、感想なぞを徒然なるままに書き連ねてみたいと思います。
- はじめに(求めているものが違う方はそっ閉じ推奨です)
- 前日譚はビビりまくり
- 開始はちょっと過剰気味な緊張風味
- チームのポリシーを決めるのは「いいね！」
- 昼食は会話に夢中になりすぎて
- グループワークは奇跡のバランス
- 後日譚は「次」へつながる感情を添えて
- 個人の振り返りもちゃんとやったよ！
- 感想
はじめに(求めているものが違う方はそっ閉じ推奨です)
本記事は テストのワークショップ WACATE に参加した際の感想だったり日記だったりに近いものです。
すごく濃密に技術漬けな 2 日間でしたが、この記事では技術的なことには触れない予定なのでご容赦願います。
「WACATE とは」とか「WACATE で使われた資料を見たい！」という方は以下の記事で丁寧にまとめてくださっているのでご参考までに。
ということで私は徒然なるままに思ったことなどを書いていきたいと思います。
前日譚はビビりまくり
なんとかポジぺを書ききり提出したものの、人見知り＆緊張しいがどうしても治らない私は、内心ビビっていました。
そして大方の予想通り(?)、前日に盛大に風邪を引くという大失態。
さらに当日は豪雨。なかなかに憂鬱な気分で電車に乗り込むのでした。(幸先が残念過ぎた。)
開始はちょっと過剰気味な緊張風味
まずは自己紹介タイム。
お隣の方が、Twitter でよくお見掛けする有名人だったので嬉しさ反面早速緊張して、だいぶ事故紹介気味になりました。
ここで学んだ定番の質問は「犬派か猫派か？」。便利だなー。
私調べだと、今のところ 7:3 で猫派優勢です。かわいいは正義。(だが私は犬派。犬かわいいじゃん。)
その後、席替えをして 2 回目の自己紹介。そっちはばっちりでした。
実行委員の方もこれを見越して自己紹介は二部構成にしたそうです。
(術中にはまったー。ありがとうございます！)
チームのポリシーを決めるのは「いいね！」
班分けされたグループごとに「どのようなグループにしていきたいか、そのために何をするか」を話し合うコンテンツがありました。
各人がネタを出し合い、議論しながら取捨選択していくのですが、挙がったネタの中で「共感する発言には『いいね！』をしよう」という意見があり、特に印象に残っています。
すぐに取り組める決め事って大事。
このネタですが「いいっすね！」など多段活用をいくつ作れるかといった遊びにも発展していくほど盛り上がり 私たちのグループの雰囲気を(良い方向に)向かわせる切っ掛けになってくれたと思います。
昼食は会話に夢中になりすぎて
1日目は海鮮丼、2日目は三種のカレー。おいしかったです。()
初日は、 ちょうど正面になった方と会話を楽しみつつのお食事。
この方は2 回目参加で、グループワークではファシリテートを担当してくださった人なのですが
話を聞くと、QA ではなくWeb 側の開発チームリーダーとのことでした。
ご本人はエンジニア気質とのことですが、チームの課題意識を突き詰めた結果、 開発ポリシー作ったり、チーム作りを進めたり、とまさにマネージャなお仕事をなさってるようでした。
かっこいいなぁと思いつつ、会話の中で開発者と QA で使う言葉や考え方に関して同じ部分、異なっている部分をそれぞれ感じたのを覚えています。 ちなみに最近、職場で開発者とプロジェクト内容以外でも会話する機会が増えたのですが、この体験のおかげです。
なお、途中から話に夢中になりすぎて食べるのが遅くなり、回りのメンバーを待たせることになったのは内緒です。 (グループの方々ごめんなさい。)
2日目はカレーです。 ライス, ターメリックライス、ナン、そしてマホロバ名物三種のカレー。 カレーの食べ方でクラシフィケーションツリー作る、というアイデアがあったのですが面白いですね。
ターメリックライスと甘いカレーの組み合わせは苦手だからこれはナシね！とかわがままを言う役をやりたいです笑
グループワークは奇跡のバランス
ここは別記事にまとめたいと思っているのですが、これだけはお酒の勢いで書いておきたい。
今回グループワークは非常にスムーズに進んだのですが、この件を後日自社の先輩に話すと大変驚かれました。
というのも、若手が集まるとやはり主張が強めで、ファシリテータが強制力を以て場を無理やり導くケースが多いからだそう。
そこで私はスムーズに進んだ理由を考えていたのですが、ふと思い当たったことがありました。 ファシリテータしか決めてないのに、自然と以下のように役割が分かれていたなぁ、と。
- 確実に議論を前に進めるも、苦手な分野は有識者にしっかり託すファシリテータ
- QA の知見を活かし、知見の浅い人も巻き込みながらテストプロジェクト(グループワーク)をリードする方
- チームの雰囲気をより良い雰囲気に導くモチベータ
- 状況に応じて議論を止めて、紙に書き出すことで全体の認識合わせを図る気配り上手さん
- 決めるところをしっかり決める発表者な方
- 私は誰?（何やってたっけか。)
そしてこれはきっと他のメンバーも共通認識で「これはこの人に任せておけば大丈夫、自分は自分の役割に注力しよう」 という信頼感があったのはないかと思います。各々の得意なことが奇跡的にかみ合ったというか。
実際にはお仕事上において、暗黙的な共通認識の上で物事を進めてしまうのは危険だけど
このグループワークのような感覚は、ずっと覚えていたい得難い経験だったように思います。
そして何より楽しかった。
後日譚は「次」へつながる感情を添えて
前日譚におけるビビり具合は杞憂に終わり、大変楽しいイベントになりました。 初参加の方が全体の 7 割位いらっしゃいましたし、慣れている方も優しい方ばかりなので、今二の足踏んでいる方にも是非煽rおススメしたいイベントです。
個人的には分科会をうまく回せなかったという課題も持ち帰れましたので、そこは次回に生かす、ということで。
また、帰りの電車が同じグループの方と一緒で、色々な話をして別れ際に再会を約束しました。 テスト業界で働いていれば再会の機会は間違いなくあるでしょうし、その日のために社外へ出ていき研鑽を積むことをモチベーションの一つとするのも、アリなんじゃないかな、と。
個人の振り返りもちゃんとやったよ！
オープニングセッションのコンテンツの一つに「WACATE」を通じて自身への課題を設定する、というものがありました。 そこで私は「テスト計画の立て方を学び、自身の業務に持ち帰る」という目標を設定しました。 せっかくなのでこの記事で振り返りたいと思います。
(経緯を書くと長くなりそうなので飛ばして結論に入ります。
基調講演はアイスブレイクから内容までステキすぎましたし、引き込まれる講演でした。)
結論としてテスト計画の立て方として以下の考えを持つようになりました。
テスト計画を立てるためには、色んなリスク(プロジェクトリスク、ビジネスリスク、プロダクトリスクなどなど)を分析し、 リスクの度合いを念頭におき「やること」「やらないこと」を定義し、進め方の ストーリーを構築し、関係者と共通認識を持っておくべき事項を書き出す。 その結果がテスト計画になるのかな、というのが現在の認識です。(文章が冗長。。) ただ、毎回必要になる情報はきっとあるので、そこは形式化しておこうね。(毎回ゼロから書くのは無駄なので。)
自身の考えが合っているかどうかは別として、翌日からのアクションプランが立てられたのことを以て目標は達成できた、 と言い切りたい。 そして、引き続き学びを継続しつつ明日から生かしていくのです。
感想
実は私、現在のプロジェクトがしんどすぎて、ちょっとテストが嫌いになりかけていました。
が、WACATE が終わった後は勉強してスキルを磨いていこうという思いが強くなっていました。
これが WACATE で得られる大きな成果のひとつなのかなぁという考えを抱いています。
何かしら改善のアイデアがあったり、次に打ちたい手があると仕事のモチベーションは高まっていくものだー、という こともありますし、そのための気づきを得る機会としても素晴らしいワークショップだったと思います。
最後になりましたが、実行委員の皆様、イベント参加を勧めてくださった皆様大変有意義な時間をありがとうございました。
(ここは間違っているぞ、などご指摘等ありましたらお手数ですがご教示のほどお願いいたします。)
#ssmjp 2018年7月を聴講してきた記録
運よく抽選で当選したので、7/24 に#ssmjp の７月会を聴講してきました。
業務で、ネットワークインフラに触れる機会が多かったので関連する勉強会で自身の不足している要素を見つけたかったのが、主な理由です。
この勉強会は connpass で参加募集しているのですが、倍率 2 倍強で、人気のある勉強会となっています。
同僚が抽選から漏れてしまったのですが、とても参加したがっていたので、せめてこちらの記事にメモを残そうかと思います。
前説 @tigerszkさん
- 通称「ささみの会」
- もともとはインフラ運用の勉強会
- 「アウトプットしないのは知的な便秘」
- ネタは何でもOK 「お風呂洗剤の話」をした方もいらっしゃった
- Slack に 50 チャンネルあり。HP からリンク
DNS Summer Day 2018報告ー海賊版ブロッキング問題を中心にー 石田さん
- DNS Summer Day 2018 の開催報告
「CloudFormation と FaaS のはざま - Kubernetes の設計思想を探る - 」 @koyhogeさん
- インフラ運用の視点では巨大な yml は避けたいよね。
- コンテナ+オーケストレーションが熱い
- OS 実行イメージの単位で分離
- 最近流行っているのは Docker + Kubernetes(k8s) 読み方はくーばんてぃす。元ネタは スタートレック。Borg
- イミュータブル。一度作ったら、変更しない。変更せずに新しいものを作る思想。
- 宣言的設定。あまったものは減らす、などあるべき物を定義する。
- 自己回復する。コンテナが死んだら別のコンテナを自動で立ち上げる。
- サービスの OSS 基盤として標準になりつつある。
質疑応答
- kubernetes はサポートが短くてどんどん先に行く思想と聞いている。
- インフラ屋さんが手を出したとして、例えば3年後に変化についていけるものなのか。
- 変化が速いというか仕様が頻繁に変更するという話はあるが、3年後なら大丈夫では。
『続 運用自動化、不都合な真実 ～ なぜコスト削減目的で運用自動化してはいけないのか』@tcshさん
- AWS クラウドフォーメーションの人
- 運用自動化で「工数削減いうな」 -「運用工数」が増えても価値が上がればいいのでは。
- 運用工数の削減ではなく、効率化すべき
- なぜ「コスト(OPEX)削減目的」がダメなのか。
- 絶対的削減。キャッシュアウトの削減。
- それ以外にできることがないときにやるもの。
- 経営危機の際には有効
- 現場の能力と選択肢も同時に削減されていく。「運用価値」の削減スパイラル。
- 相対的削減。費用対効果の改善である。
- 工数は増えるが、費用対効果も増える。
- リソースを何も変えずに改善するのは「無理」
- まずは「納期」を改善すると、目に見やすいので存在感を得やすい。
- コスト削減を要求されたときは、「納期短縮」して条件闘争を。
『マインドフルネスのススメ』@_keihinoさん
- IOT とか PoC の方。
- 調身、調息、調念
- ストレスフルな日常に瞑想を。
- (全員参加型で瞑想していたのと、ひたすら笑っていたのでメモとれず。)
- スピリチュアルな光景
『OPNsenseをUTMに入れて使う』@Alice_Youさん
- NXG150 という UMT に OPNsenseを入れて使うという事例の紹介
- @infra_imouto の中の人
- 同人サークル Alicesystem
- ネットワーク系同人誌書き
- NXG150でたいていの OS が動く。
- SEILx86 の動作も確認
- C94 で postfix の入門本を出すかも。
- OPNsenseって？
『「DNS浸透いうな」と言うけれど…』@goto_ipv6さん
浸透ってどこに？
- アプリケーション？
- いつまでキャッシュする？アプリ側で考えないといけないので、浸透するような実装はなさそう？
- web ブラウザへ浸透？
- OS へ浸透？
- フルリゾルバ？
- インタラクティブな問い合わせをする。
- キャッシュを持つことがおおい。
- だがしかし要求を受けないと保持されないので「浸透」ではない
- ネガティブキャッシュによって、情報を保持しているのに応答しない。よって、「浸透」ではない。
- 権威サーバ
- ドメインに関しての情報しか持たない。ゾーン転送を制御することもできる。よって「浸透しない」
- ルートサーバ
- (するわけない)
- 既存の権威サーバが新しいサーバへの切り替え手順を間違えると、「DNS が浸透しない」状態となる
- 移譲元への変更申請と、権威サーバに対するドメイン名の変更は別。
- レジストリとレジストラの話。
- 利用しているアプリがに他人の情報が浸透してきてたら怖くないですか？
- 浸透先なんてそもそもいない。 -「浸透」を待たなくても、フルリゾルバになりきって dig で interative な問い合わせをしてみましょう。
- ネガティブキャッシュなどに関しては先生の資料で説明しているので、読んでください。
資料
感想
DNS のふるまいを中心に話していただいた「浸透」回りの話は大体理解できた一方、「Kubernetes」あたりで話された近年のトレンド回りの話題に弱いことに気づきました。
もう少し、アンテナを広げていろいろな新しいツールに手を出してみようとおもった。
一方、非常に興味深かったのが、運用自動化に関しての講話で言及されていた「絶対的削減」と「相対的削減」の違いは、普遍的な仕事に通ずるところがあると思っていて、長期的なキャッシュアウトを減らしたいのであれば、その取り組みを行う上で短期的なオーバーヘッドは許容せねば、かならずどこかにひずみを生じさせてしまい、状況次第では組織の弱体化につながりかねない、というのは同じかなと。
「工数削減とは、キャッシュアウトを減らすことではなく、効率化であるべき」を考えの中心においてみたいと思います。
外出先から操作できるサーバ構築環境を検討してみた
サーバ関連を自由にいじれる環境が欲しくなったので、「やりたいこと」「実現するための方法」選択肢に関して考えたので、せっかくだから記事に残しておきます。
やりたいこと
今回、自由にいじれる環境が欲しくなった経緯としては、自身の勉強用途でもあるのだが、知人と DNS サーバの勉強をする機会を得たという事情もあったりします。
その知人は現時点ではDNS まわりの知識に明るくないので、サーバを弄れる環境くらいは用意しておこうかな、と思ったというわけなのです。
では、そのためにユースケースや、必要な要件をまとめてみる
ユースケース
一般開放された会議室や、cafe から該当の環境に アクセスして、環境上に構築した DNS サーバを操作する。
とりあえずこれで。 次に要件を上げてみる。
要件
- 外出先から操作できること
- DNS サーバ(など)を自由に構築できること
- 自分以外(のPC)からアクセスできること
とりあえずこれで。 次に方法を考える。思いついたのは、物理的にやる方法と仮想的にやる方法
物理的にやる方法
会社のすごい人から ラズベリーパイ使うと簡単かも、と伺ったこともあり、物理的に自宅にネットワーク構築して
外部からアクセスする方法を考えてみた。
ハード面
材料を上げてみた。
- ラズベリーパイ
- 制作キット(「Pi-Top（パイトップ）」というのがあるらしい) 安い。ほかにもあるかもしれないが、コレにすることになったら、ちゃんと調べる。
ソフト面
OS はLinux で。CentOS 6系列が使いなれているのでこれにすると思う。FreeBSD も使ってみたいけど。
Windows のツールを使う必要がでてきたら、そのときライセンス買う。
DNS サーバソフトウェアは悪名高き(?)BIND 確定。脆弱性のお祭りをきっと体験したくなるので。
ほかには必要に応じて、 Apache とか Sendmail とか。
ネットワーク
自由に使えるグローバル IP が一つあれば、ルータかまして snapt すればなんとかなる。
が、ここで問題が。。。自宅は故あって、固定回線を引いていないので、グローバル IP が準備できない。
したがって、運用するなら固定回線を契約する必要がある。
運用
サーバは基本落としておくとして、OS は(少なくとも使う予定のある日は)常時稼働を想定。
結論
ラズベリーパイを組み立てるのが楽しそうだが、グローバル IP を用意するのがネック。
仮想的にやる方法
思いついたのはクラウドサービスの利用。サーバ立てたり、操作したりしたいので、Iaas。
ハード面
仮想なので、該当の Iaas にお任せ。
ソフト面
OS は CentOS があれば良い。が、後々のことを考えると Windows も選択肢に残したいので、ここは要チェック。 サーバソフトウェアは自分で入れるので、考慮しない。
ネットワーク
クラウドサービスなので、サーバ側は特に支障ないはず。一般公開は想定していないので、ACL はかけられるようにしたい。
ただ、利用したい環境のひとつからAWS へアクセスできない、という情報があったので、クライアント側のネットワークは検討せねばならなそう。 最終手段として、スマホのテザリングでアクセスはアリなので、最低限使うポート= 22, 53, 80 ,25 ,110 位は出口を要確認。
また、ここで気づいたのだがテザリング で AP を立てる方法だと、アクセス元 IP がキャリアの施設のグローバル IP になってしまい、IP アドレス指定の ACL では、自身以外からのアクセス制限をかけられない疑惑が。。
まぁ、SSH でのアクセスを想定しているので、ログインを公開鍵認証にして、BIND のリゾルバ機能を無効にしておけば、権限昇格の脆弱性を突かれない限りセキュリティは大丈夫かな。(私的利用だし)
運用
クラウドサービスなら管理コンソールがあるはずなので、使うとき以外は落としておく。
結論
今回は、クラウドサービスを使う方向でまずはやってみる。
上記のページを読んでみたところ、候補は以下のどれかにしたいと考えた。
- Amazon Web Services (AWS)
- さくらクラウド
- Windows Azure
- NTT Communications Cloudn
私的利用なので、 ポイントは最小構成での費用と最低限のセキュリティ。
今のところは、使ったことのある AWS が最有力で、最近個人的に耳にする機会がある Azure が次点。
以上、眠いので、アカウント登録は明日。おやすみなさい。
開発者向けの社外セミナーに参加して感想をメモしただけの記事
手元のメモじゃ絶対埋もれるので、忘れないうちにブログに書く。 それだけの記事です。しかも推敲なしの殴り書き型。
メモとるときはフォーマットを用意しておくこと
自分がやりやすいと思うのは以下の3 部構成
- 発表内容をメモする領域
- 自分の考えやアイディアをメモする領域
- 疑問点をメモする領域
「この考え方、ちょっと弄ったら業務にこう適用できるんじゃないか？」というアイデアは即メモる。
翌日まで覚えていられる保証はないので、必ずメモる。
自分の場合は発表内容のメモと混ぜると埋もれてしまうので、ちゃんと見出しを作って領域を分けておきたいのである
疑問点をメモする領域は、登壇者に質問するためのメモを書くところ。
ポイントは持ち帰って調べれば解決できそうな疑問と、今聞かないと迷宮入りするだろう質問を区別して
後者から優先的に質問出来るように書くこと。迷宮入りするモノにはなぜなぜ系の疑問が多い気がする。
自分にできることはなんでしたっけ
開発経験が無い自分は、周囲を「なるほど」と唸らせる知見ををお出しするのは
やはり難しいのだけども参加するには何かしたいなーと思ってやったことがある。
それは「質疑応答で一番最初に質問する」こと
小学生か！と突っ込みたくなるが、一応意図はある
- アホな質問だろうが、口火を切ると後の人が続きやすくなる。
割と少人数セミナーだったからなのか、意外と最初の質問までに時間がかかったし(自分も躊躇した) - 質問は登壇者もうれしい。はず。
セミナーで知見を頂いたのだから、こちらが出来るお礼の示し方はなんだろう、の一つの形だと思う。 - 目立つ。
懇親会に出て分かったことだが登壇者の方からは「最初に質問してくれた人」で
覚えて頂くことができるので、こころなし懇談会でお話を伺いやすくなる。気がする。
懇親会は「キーワード」の宝庫
懇親会に出て人脈づくりをーという話をよく聞きますが、それ以外にも
得るモノがあるな、という感想。
登壇者以外にも参加者がいて、参加者の数だけ知見があって、お話を伺うと
自分の知らないキーワードがちりばめられている。
帰宅後に調べておけば、懇親会に出席しなかった場合と比べて
何かしらの課題解決で採れる選択肢が一つ増える。ことになる。
まとめ？
しっかり目的意識を持って参加する人からは怒られそうだけども、
あえて言ってみると、「参加するだけでも得るものはある」
今後も継続して参加しようね、という自分を激励するための言葉でもある。
新入社員が書くような記事になってしまったが、これまでやってこなかったの
だから仕方ない。
継続すること、振り返ること、改善すること。
(おしまい)
【雑記】自動化というツールはどのような動機で選択されるのだろう
本記事の趣旨
最近テスト業界で盛り上がりを見せているという「AI」 だったり「自動化」というキーワード。 「テスト自動化」というビジネスではなく、業務効率改善の取組の一環ではあるが、 かかわる機会が出てきそうなので簡単に頭の整理をしてみたいと思いました。
自動化を試みる動機って？
「どんな取組も動機・目的を強く意識したうえで進めるのが大事」なので情報を集める前に このようなキーワードがどんなシーンで使われるのか、思いつく限りで挙げてみます。
| 動機 | 説明 |
|---|---|
| コスト削減 | 単純な作業などを自動化することで、該当作業にかかる人的コストを削減する。 |
| 納期短縮 | 人間が一日に作業できる作業量は決まっているので、終わらない作業を夜間などに自動実行させることで納期を短縮する。 |
| 開発物品質向上 | 期間や工数等の事情により行えない(回帰)テスト等を自動化しておくことで、より多くテストを行え、開発物の品質向上につながる |
| テスト品質向上 | 専門的なスキルを必要とする難しいテストを、自動化しておくことでオペレーションミス等による「テストが期待通りに実行されないリスク」を防止する。 |
| 安全性の向上 | 人間が行うと危険な作業を機械に肩代わりしてもらうことで、作業者の安全を確保する。これも自動化だと思う。 |
得てして、自動化するための作業は手動で操作するより手間も時間もかかり、「納期短縮」を行える ケースは稀だと思う。ここでは、単純な操作の反復作業なんかを簡単なスクリプトで動かすイメージ。
「コスト削減」は、人的コストを削減することで、利益率向上を期するマネージャ層が選択しそうなイメージ。 あくまでイメージ。自動化作業にかけたコスト回収にどの程度の期間を要するのがポイントだと思う。
「開発物品質向上」は回帰テストを毎サイクル走らせることで、影響範囲の分析時に想定されなかった不具合を 検出できれば、その効果にひとまずは胸を張れる。
上記のようなことをまずは簡単な所からだなーとか、どんな動機で取り組むのか、身に着けるべきスキルは どんな物があるのかに思いを馳せています。 そして、職場で現在流行している「とあるDNS の本」を読む作業に戻る。
ノウハウのアウトプットというより日記になってしまった。 今、頭の整理をしたことで、いざ話をする必要がある時に、きっと今より整理して話せる。それも大事。
(おしまい)
【雑記】くだらない話①
とある日の疲労困憊な仕事帰りのとある会話~~~~
とあるツイートをめぐる会話
A.「ねぇねぇ、このツイートどう思う？」
最近の女子高生はDNSを使いこなしているらしく、電車の中で「アドレス渡されたんだけど、逆に引くわ！」と言っていた。
(とある方のツイートを引用)
B.「...(2秒考える)。ｗｗｗｗｗ。」
A.「そのアドレスじゃないというｗ」
B.「しかしメールアドレスを逆引きしたら、何返すんだろうなｗ電話番号とか？
A.「うーん、そもそも左辺だと @ 込みの文字書けないしな。」
B.「もう TXT しかないんじゃね？右辺なら書けるし。」
例: yamada.hanako.jk IN TXT "XXX-XXXX-XXXX" "hogehoge@example.jp"
A.「なるほど。ドメイン名を自分の名前にしておいて、連絡先はTXT 引いてねってナンパしてきた人に渡す感じ？」
B.「そうそう。ってその返しをした時点で、ナンパしてきた男が逆に引くわｗ」
A.「また逆に引くのか！それはもういいよ！」
おしまい
総括
- ツイートした人のセンスがずば抜けてる
- 身に着けた知識で、冗談言えるようになると楽しくなるよね
- 酒の勢いで記事を書いた。後悔はしていない
- 3 日後くらいに読み直して、恥ずかしくなって頭抱えるやつ
- 会話内容を既にだいぶ忘れたので、少し脚色が含まれます
【VirtualBox】ホストOSからゲストOS へ ping が通らないときの確認ポイント - その 1
この度、環境が変わりお勉強の場所がなくなってしまったので、GW の休み中 ローカルに仮想で CentOS を立てました。
その際に、なぜか ホストOS-ゲストOS間で ping が通らず、ネットワーク設定を弄りまわすことになったので、 次回のために確認ポイントを残しておこうと思います。
VirtualBox の設定作業にはコチラを参照させていただきました。
構築環境情報
- ホストOS: Windows10
- ゲストOS: CentOS6.9
- ネットワーク設定: よくある構成
- アダプタ1: NAT(ゲスト OSからのインターネットアクセス用)
- アダプタ2: ホストオンリーアダプタ(ホストOS-ゲストOS 間通信用)
ポイント1. [ケーブル接続]にチェックが入っているか
まず、例によって OSI 参照モデルの下(物理層)から見ていきます。
仮想といえど、ちゃんとネットワークケーブルの接続有無を決める設定が用意されているようで、
下記画像の赤枠部分が該当の設定箇所になっているようです。
もし外れていた場合には、忘れずにチェックしておきます。
なお、画像の設定画面は、ホストOS 側のVirtualBox マネージャから設定ボタンを押下することで表示できます。
コメント
ということで、短いですが続きはまた次回に。 その後、MACアドレスを揃えて、interface を上げて、 GW のアドレス決めて、IP を割り振るところまでやったので 4 記事構成くらいに分割して書いていきたいなーと思います。
