要件定義はどうやって正確にするの？

目次 

1. ウォーターフォールプロジェクトの進め方

2. ウォーターフォールプロジェクトで大切なこと

3. 要件定義ってどうやって正確にするの

ウォーターフォールで要件定義は大切

ウォーターフォールで要件定義が大切なのは前の記事で説明した通りです。

でもじゃあ要件定義はどうやって正確にやるのさ？を解説します。

概要

要件定義を正確に行うには、プロジェクトの最初に十分なコミュニケーションを行い、顧客や関係者のニーズを的確に理解することが重要です。以下のステップを踏むと、より正確な要件定義ができる可能性が高まります。

1. 関係者と徹底的なヒアリングを行う

目的: 顧客や関係者が本当に求めていることを引き出すため。

方法:

ヒアリングシートを事前に用意し、具体的な質問を準備する。

使いたい機能だけでなく、解決したい問題や達成したいゴールを明確にする。

利用シーンやターゲットユーザーについても詳しく聞き取る。

2. 現状分析と課題の整理

目的: 顧客が抱える現在の問題や課題を具体的に理解すること。

方法:

顧客の業務プロセスやシステムの現状を把握し、問題点を洗い出す。

ユーザビリティやパフォーマンス、拡張性など、現状で不足している要素を整理する。

顧客の希望が明確に反映されるよう、優先順位をつけたリストを作成する。

3. ユーザー視点で要件を具体化する

目的: 顧客やユーザーにとって必要な機能や使いやすさを明確にする。

方法:

ユーザーが実際にどう操作するかを想定し、ユーザーストーリーやユースケース（利用シナリオ）を作成する。

それぞれのシナリオに沿った要件を洗い出すことで、具体的な機能が見えてきます。

4. 非機能要件の確認

目的: システムの品質面や技術的要件を正確に定めること。

方法:

パフォーマンス要件（レスポンス速度や同時アクセス数など）、セキュリティ要件（アクセス制限やデータ保護など）、運用要件（保守や障害対応など）を具体的に確認。

こうした非機能要件も明確にすることで、後からの変更を防ぐことができます。

5. モックアップやプロトタイプの作成

目的: 実際の画面イメージや操作感を共有し、要件の認識を一致させるため。

方法:

画面のモックアップや、簡易プロトタイプを作成して、顧客に確認してもらう。

これにより、具体的な画面や操作を通じて要件が正確かどうかを検証し、見落としや誤解を防ぐことができます。

6. 要件確認と合意（ドキュメント化）

目的: 要件を明文化し、関係者全員が同じ認識を持つこと。

方法:

要件定義書を作成し、全ての関係者にレビューと確認を依頼する。

署名や承認を得ることで、要件の範囲を確定し、後からの変更リスクを最小化します。

7. スコープ管理

目的: プロジェクトの途中で要件がぶれないようにするため。

方法:

追加要件や変更が必要な場合、必ず影響範囲とコスト、スケジュールを考慮し、関係者の合意を得る。

変更管理のプロセスを事前に設定しておくと、要件定義がずれるリスクを低減できます。

これらのプロセスを丁寧に行うことで、要件定義がより正確で顧客の期待に合ったものとなり、プロジェクトがスムーズに進行しやすくなります。

ポイント さすがに要求が多すぎ・大きすぎで手に余る場合

客「ここにNetflixみたいなサイトがありますよね」

開発「はい」

客「このサイトにYoutube liveやTwitchみたいなLive配信機能をつけてください！」

開発「え！？」

開発「（難易度高過ぎワロタ）」

こういうデカい機能、もしくは難易度は高くなくてもたくさんの要求をもらうことはあります。こういう場合、その要求をフェイズに分け、扱い安いようにしましょう。

例えば「Live機能を追加する」に関しては、例えば元々内部ユーザ（社内の人間）だけに公開（一般には非公開）、有料ユーザだけに動画を公開する機能（非有料ユーザには非公開）があるとしましょう。

この既存機能を使用して次のようにフェイズが分けられます。

フェイズ1 内部ユーザ限定でベータ版Live機能公開

フェイズ2 有料ユーザ限定でLive機能を公開

フェイズ3 全ユーザにLive機能を公開

このとき、仮に新機能であるLive機能に問題があっても、フェイズ1でその問題があぶり出せれば、最終目標であるフェイズ3が始まるまでに修正が可能です。

こういうふうに段階的やり方で進めるとプロジェクトが扱い安くなりますよ。

ウォーターフォールで大切なこと

目次

1. ウォーターフォールプロジェクトの進め方

2. ウォーターフォールプロジェクトで大切なこと

3. 要件定義ってどうやって正確にするの

ウォーターフォールプロジェクトで大切なこと

前の記事でも言いましたが日本では顧客 vs システム会社という構図で開発が進められることが多いです。

そうすると結局ウォーターフォールのほうが色々と都合がよく、なのであえてウォーターフォールの勉強をしていきます。

1. 要件定義の正確さ

なぜ大切か: ウォーターフォールでは、要件定義がプロジェクト全体を決定づけます。要件が正確に定まっていないと、後の設計や開発での変更が難しく、スケジュールにも悪影響を与えるため、最も注意が必要です。

2. スケジュール管理

なぜ大切か: 各フェーズのスケジュールが明確であれば、進捗が管理しやすく、全体のリソースを効率的に使えます。ウォーターフォールでは一つのフェーズが終わらないと次に進めないため、スケジュール通りに進むことが特に重要です。

リスク: スケジュールがずれると全体のプロジェクト期間やコストに大きな影響が出るため、適切な進捗管理とマイルストーンの設定が必要です。

3. 品質管理

なぜ大切か: ウォーターフォールでは、各フェーズが一度完了すると戻るのが難しいため、品質の確認が欠かせません。テストフェーズでの品質確認がスムーズにいくかどうかは、各フェーズでの品質管理にかかっています。

ポイント: フェーズごとに品質基準を設け、問題があれば早めに修正する仕組みが必要です。

4. リスク管理

なぜ大切か: ウォーターフォールは変更が難しいため、予測できるリスクに対して事前に対応策を考えることが重要です。

対策例: 予備の時間を確保する、早期に進捗レビューを行う、トラブルシューティングの計画を用意するなど。

プロジェクトの進め方

目次

1. ウォーターフォールプロジェクトの進め方

2. ウォーターフォールプロジェクトで大切なこと

3. 要件定義ってどうやって正確にするの

はじめに

IT系、特にWeb系のプロジェクトの進め方を書いていきます。

アジャイルとウォーターフォールについて

まずですが日本のIT、ウェブ系はほぼウォーターフォールで進むと言っていいでしょう。

こんな感じでプロジェクトが進んでいきます。

qiitaより引用

https://qiita.com/abcaaa/items/9bb17660d7a1bfffbdbf

日本であまりアジャイル手法は取りません。

でもアメリカではアジャイルのほうが主流です。

日米で主流となっている開発手法が違うわけでですが、原因は、個人的には日米のIT部門のあり方の違いとか雇用環境の違いがあると思います。

1. 雇用環境の違い

日本: 正社員としての長期雇用が一般的であり、プロジェクト単位で人材を流動的に変えるのが難しいため、計画が予めしっかりと組まれたウォーターフォール型の方が管理しやすいとされています。ウォーターフォールは、長期的な計画と細かな管理が必要なプロジェクトに向いており、日本の職場文化にも合致しやすいです。

アメリカ: プロジェクトごとに契約社員やフリーランスが加わることが多く、役割を柔軟に変更することが一般的です。アジャイルのスプリントや短期間での成果物の提出により、柔軟に方向転換できるアプローチが好まれています。

2. IT部門とSIerの違い

日本: 日本のIT部門の多くは外部のSIerに業務を委託しています。SIerは顧客が求める仕様通りにシステムを開発し、納期と予算に合わせて納品する必要があるため、ウォーターフォール型が採用されがちです。このアプローチは、仕様が確定してから設計に入るので、顧客が求める成果を確実に達成しやすいとされています。

アメリカのIT企業: IT部門が社内にあり、直接ビジネス部門と連携するケースが多いため、変化するニーズに即座に対応できるアジャイルの方が適していると考えられます。また、スタートアップ企業も多いため、スピード感や柔軟な開発が重視されます。

3. 開発文化とマネジメントの違い

日本: プロジェクト管理が上位から下位へ一貫して行われることが多く、品質や計画の遵守に強くフォーカスされます。ウォーターフォールのような段階的で予測可能な開発プロセスが、安心感をもたらすと同時に管理も容易にします。

アメリカ: より自律的なチーム編成が一般的で、意思決定もチーム内で柔軟に行われることが多いです。アジャイルのセルフマネジメントやチーム単位での調整は、アメリカの自律志向の文化と合致しやすいといえます。

だから日本はウォーターフォールが多い

上下関係のあまりない環境で内製のアプリケーションを作るなら日本でもアジャイル手法のほうがいいんでしょうね。それなら納期厳守する必要ないしね。

逆にアメリカであっても、外部に顧客がいて納期があり顧客から求められる仕様があるのに関わらず、アジャイル手法を導入して大失敗したケースは、ITではないですが、ボーイングの737max系の開発は一例ではないでしょうか。

参考文献は以下など

https://www.logikalsolutions.com/wordpress/information-technology/did-agile-make-the-737max-fall-from-the-sky/

プロジェクト全体の流れ（ウォーターフォールの場合）

日本の環境でウォーターフォールモデルを採用する場合、以下のようなステップと準備が必要です。

1. 要件定義

目的: プロジェクトの全体像を明確にし、顧客や関係者が求める成果を定義する。

必要なもの:

• 顧客とのヒアリング資料
• 要件定義書（何を実現するか、どのような機能が必要か）
• システムの非機能要件（セキュリティ、パフォーマンス、運用性など）

2. 基本設計

目的: 要件に基づいてシステム全体の構造を設計し、必要な機能を具体的に分解する。

必要なもの:

• システム構成図
• データベース設計書（ER図やスキーマ）
• UI/UXの画面設計（ワイヤーフレームやモックアップ）
• インターフェース仕様書（外部システムやAPIの設計）

3. 詳細設計

目的: 基本設計に基づき、さらに具体的な技術仕様とプログラム構造を設計する。

必要なもの:

• プログラム仕様書
• 詳細なデータフローダイアグラム（DFD）
• エラー処理や例外処理の方針
• テーブル定義書やフィールド設計

4. 開発（コーディング）

目的: 設計を基に実際のプログラムを構築する。

必要なもの:

• コーディング規約とガイドライン
• コードレビューのチェックリスト
• バージョン管理システム（Gitなど）

5. テスト

目的: 開発したシステムが要件通りに動作するか、品質を確保する。

必要なもの:

• テスト計画書
• テストケースおよびテスト項目
• ユニットテスト、結合テスト、システムテスト、受入テストのそれぞれの環境
• テスト結果の記録と評価

6. 運用・保守

目的: システムの稼働後に発生する問題の対応や改善、保守を行う。

必要なもの:

• 運用マニュアル
• 障害時の対応手順書
• サポート窓口とエスカレーションフロー
• システムの保守計画書（アップデート、バグ対応など）

7. プロジェクト管理

各フェーズで進捗を管理し、スケジュールや予算のコントロールを行います。ウォーターフォールは進行が直線的であるため、途中での変更が難しく、進捗の把握やリスク管理が重要です。

必要なもの:

• ガントチャートや進捗管理ツール（MS Projectなど）
• コミュニケーション計画
• リスク管理計画
• 品質管理基準（QMS）

ウォーターフォールモデルでは、計画が事前に固められるため、初期段階での詳細な資料や計画作成が成否を左右します。また、各フェーズで承認を得て進むため、関係者との確認や合意も重要です。

シミュレーションしてみよう

Netflixのような動画配信サイトの動画にチャット機能をつけるケースを例に各ステップのシミュレーションをしてみましょう。

要件定義

担当者: 「動画配信中に視聴者同士がリアルタイムでチャットできる機能を追加しましょう。」

エンジニア: 「対象はライブ配信だけですか？それともオンデマンドにも？」

担当者: 「まずはライブ配信で試して、好評ならオンデマンドにも広げましょう。」

作業見積もりとスケジュール作成

1. 作業見積もり

担当者: 「チャット機能の作業を洗い出して、それぞれの工数を見積もりましょう。」

エンジニア: 「はい、要件定義・設計・開発・テスト・運用までの各ステップに分けて見積もります。」

例:

• 要件定義: 5人日
• 基本設計: 7人日
• 詳細設計: 10人日
• 開発（バックエンド、フロントエンド）: 20人日
• テスト（ユニット、結合、システム）: 15人日
• ドキュメントと最終チェック: 3人日
• 総工数: 60人日

2. スケジュール作成

プロジェクトマネージャー: 「60人日ですね。メンバーは3人、1人が1日8時間とすると約1か月のプロジェクトになります。ガントチャートで全体の流れを見える化しましょう。」

エンジニア: 「了解です。各フェーズの担当とマイルストーンを明確にします。」

例:

第1週: 要件定義、基本設計

第2週: 詳細設計

第3〜4週: 開発

第5週: テスト

第6週: ドキュメント作成と最終確認、リリース準備

スケジュール管理のポイント

マイルストーン設定: 各フェーズ終了時点での進捗確認

リスク管理: 予備の作業時間を確保し、遅延リスクに備える

進捗レビュー: 各週の終わりにチームで進捗状況を確認

基本設計

エンジニア: 「チャット機能はサイドバーに表示する想定で、ユーザー同士のテキストメッセージのやりとりを基本にします。」

デザイナー: 「UIは動画再生画面の右にスライドする感じで出すようにします。タイムラインに沿ったコメントも追加していいですか？」

エンジニア: 「はい、チャットのタイムスタンプを動画の進行に合わせる形ですね。」

詳細設計

エンジニア: 「チャットメッセージはWebSocketを使ってリアルタイムで送受信します。メッセージはデータベースに保存しますが、保存期間は1週間に限定しましょう。」

データベース担当: 「了解。メッセージID、ユーザーID、チャット内容、タイムスタンプでデータを構成します。」

フロントエンド担当: 「チャットUIも完成しました。動画再生と並行してチャットが表示されるようにします。」

開発（コーディング）

エンジニア: 「まずWebSocketの接続部分を実装しました。次に、メッセージをサーバーに送信し、データベースに保存する機能を作ります。」

フロントエンド担当: 「サイドバーのUIは完了です。メッセージ送信ボタンと入力エリアも追加しました。」

エンジニア: 「全体を結合して、リアルタイムにチャットが流れるか確認しましょう。」

テスト

テスト担当: 「複数のユーザーが同時にチャットに参加した際の動作を確認します。問題がなければ次にスパム防止の確認もします。」

エンジニア: 「メッセージが遅延なく表示されるか、異常終了しないかもテストしておいてください。」

運用・保守

サポート担当: 「ユーザーからチャットが流れすぎて追いつかないというフィードバックがありました。スクロール制御を追加できますか？」

エンジニア: 「了解しました。スクロール制御とともに、最新メッセージを追従するオプションも追加して、ユーザーが選べるようにします。」

プロジェクト管理

プロジェクトマネージャー: 「スケジュール通りで進行していますか？」

エンジニア: 「大きな遅延なく、予定通り進んでいます。リリース前の最終テストも問題なしです。」

プロジェクトマネージャー: 「よし、このままローンチして、ユーザーの反応を見ましょう！」

以上のような感じにウェブ系の開発は進みます。

プロジェクト進行時に失敗しがちな点

• 仕様考慮漏れ

「あとから気づいたけどすでにあるチャット機能とUIとか使用感とかが違いすぎると違和感すごくね？ある程度統一感持たせないとだめじゃん。一部やり直してもらわなきゃ！」

→ UIが作り直し、開発工数増、スケジュール遅延に

• 解決の難しいバグの発生

「なぜかチャットを開いたとき5%の確率でページがクラッシュするけどエラーログがなぜか出てなくて原因の見当もつかないよ…。時間をかけて調査しなきゃ！」

→スケジュール遅延に

• 作業見積もりの予想が大幅にずれる

「実際詳しくコードを読んで初めてわかったけど既存コードがアンチパターンのオンパレードで全く開発が進まない…。もう5日も調査と検討で時間使っちゃったよお。」

→スケジュール遅延に

• 既存処理にドキュメントがなく既存の仕様が不明

開発者A「user.status = 0とuser.status = 1っていう2種類のユーザデータがありますけどこれどういう意味のデータですか？」

開発者B「知らないよ。ここの開発を担当したCさんにきいて。」

開発者A「Cさんって今どこにいますか？」

開発者B「先月退職したよ」

開発者A「…」

開発者A「じゃあとりあえずこのデータは無視するか」

→ user.statusの値が原因で本番トラブルになったり影響大のバグの遠因になったりする。

• リリースの失敗

開発者A「いよいよ今日はリリース日だ！」

開発者A「リリースを開始したけど…。なんかエラーがでてるよ！？」

開発者B「あれ？君、リリース手順間違ってない？」

開発者A「本当だ！」

→ 本番システムでトラブル対応発生、リリースやり直し、リリースを別日で調整することになり、スケジュール遅延に。ユーザにも悪影響が。

こうならないために

• 不足の事態が起きてもいいように工数にはバッファ（予備用の余裕の工数）をいれよう

プロジェクトには不確実性が付き物です。不確実性の程度によって工数見積もりにバッファを入れましょう。

開発者の性格もあるので、せっかちな開発者は短めの工数をだすかもしれません。慎重な開発者は長めに工数をだすかもしれません。短い工数見積もりを出しがちな開発者のバッファは多めに、長めの工数を出しがちな開発者のバッファは短めに設定するといいでしょう。

通常はバッファは工数の10-20%ですが、不確実性によっては1.5倍〜2倍にする場合もあります。どれだけ正確に工数がだせるかは開発者の腕の見せ所と言えます。

あまり長すぎてもその分の人件費がかかりますし、かと言って短すぎてもその分プロジェクト炎上もしくは失敗のリスクが高まります。

• リリース手順は予め考えておき、文書化しておこう

どういうコマンドが実行されるべきか？不測の事態が起こったときどうするのか？本番システムを触る作業はスムーズに進められるように予め文書化しておきましょう。

Rest APIチーム、UIチーム、インフラ合同リリースみたいに他部署も関わるリリースの場合、予めそれぞれのチームで合意したリリース作業用の文書を作っておき、可能ならリリースリハーサルもできるとスムーズに進められます。

• 負荷を増やす処理になってないかは開発者に確認する

N+1 select問題やfor loopでinsert/updateを1件ずつするような処理は可能な限り避け、bulk insert/bulk update/bulk upsertで更新、またbulkでselectしてからその結果に対してループするようにしましょう。

• 優先順位をつけて優先順位の高い作業、あるいは今後変更の可能性低い重要な機能から作業を始める

優先順位の高い作業から始めていきましょう。あるいは今後仕様変更が入らないであろう作業から先に始めましょう。

そうやって、

「優先順位高い処理がいつまでたっても終わらない、どうでもいいような処理ばっかり先に作業を終えちゃう」

「どうでもいい作業に仕様変更が入った、あるいはどうでもいい処理の実装自体がなしになった」

「その結果どうでもいい作業でやっていたほとんどすべての作業がやり直しもしくは意味のないものになった」

「優先順位の高い作業は後回しにしてたんでなにも終わってない状態です」

こういう最悪の事態をなるべく避けます。

• まずは概算でいいからスケジュール

とにもかくにもスケジュールです。スケジュールができていないといつ終わってリリースできるのか？遅延しているにしてもどれくらい遅延しているのか？がわかりません。

まず概算でいいからスケジュールを作り、それをもとにプロジェクトを進行させましょう。

• 開発初期でいきなり開発詳細に踏み込むような内容のドキュメントを書くのはやめとけ、実行するSQLの内容を書いちゃうとか

なぜ開発の詳細に踏み込むような内容に触れるようなドキュメントを作るべきではないのかというと、ほぼ間違いなく開発中盤〜終盤で仕様変更や考慮漏れの対応、バグ対応で開発の詳細は大きく変わるからです。

このとき問題になるのはドキュメントで、開発詳細がドキュメントに含まれていると開発詳細が変わるたびに時間をかけて変えることになります。

つまり仕様変更や実装変更のコストが不必要に爆増します。そうすると最終的にプロジェクトが炎上します。どういうドキュメントをどういうタイミングでどういう粒度で残すのかはよく吟味しましょう。

• 正確な判断は正確な理解のもと出されます。開発対象のシステムの理解を深めておきましょう。

プロジェクト中はPM、開発者は様々な判断をスピーディに下す必要があります。ここで正しい判断が下せるかはプロジェクト成功の成否を分けると言ってもいいでしょう。

ここで正しい判断を下すには、開発対象のシステム・機能の深い理解と周辺の知識は不可欠です。

開発対象の機能の理解は読んで字の如くですが、知識は教科書に載っているような知識というより既存システムやその周辺技術の理解というほうがいいかもしれません。

予め開発対象のシステム・機能の理解を深める作業を可能な限りしておきましょう。

海

 

UbuntuでJavaのバージョンを切り替える

OpenJDKのJava8と11をインストールします。

$ sudo apt update
$ sudo apt install openjdk-8-jdk 
$ sudo apt install openjdk-11-jdk 

UbuntuでJavaのバージョンを切り替える場合は以下のように行います。

$ update-java-alternatives --list
java-1.11.0-openjdk-amd64      1111       /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64       1081       /usr/lib/jvm/java-1.8.0-openjdk-amd64
$ sudo update-java-alternatives --set /usr/lib/jvm/java-1.11.0-openjdk-amd64
$ javac -version
javac 11.0.9.1
$ java -version
openjdk version "11.0.9.1" 2020-11-04

 JAVA_HOMEを設定している場合はそれも変更しましょう。

マインドマップのススメ

私は職場でよく複雑な状況に置かれて、よくわからないまま仕事を進めてしまうことがよくあるのですが、こういう仕事の進め方は（予期せぬスケジュール遅れ等の）大事故に繋がります。

そんな理解できない、何をすればいいのかわからない、あーもうわけがわからんという状況を整理するのに有効なのがマインドマップです。

Freemindなら無料で使えます。日本語化できるのかよくわからないですが、英語だとよくわからない場合は日本語版を使うといいでしょう。

マインドマップには断片的な情報しか書かないのであとで読み返すとき・後で誰かに説明するとき時には各ノードの繋がりを意識した論理的な理解が必要になり、脳内でエピソード記憶的な記憶の取り出し・記憶の再構築が求められるので暗記にもいいかもしれません。

メモ取りに関して

メモを取るときに基準にすべきなのは「忘れたら困るかどうか」。
なにか重要かもしれないことを聞いたときに「これを忘れたら後に困るかどうか」を自分自身に聞いてみる。
答えが「別に忘れても困らない」ならメモしなくてよし。
「もし忘れたらあとで困る」のであれば必ずどこかにメモしておくこと。

「覚えていられるかどうか」はメモするかどうかの判断基準にはなりえない。

「これくらいならメモらなくても忘れないでしょ」で結局忘れてあとで大問題になるケースは意外と多い。

あと常にメモを整理した状態に保とうとすると気軽にメモできないので、未整理状態でメモだけ取って後で時間のあるときにメモを整理するほうが効率がいい。

Kubernete（クバネティス、クーべネティス）とは。Kuberneteをローカルで動かしてみる。

前提

以下のLinux環境を使用。Windows環境の人はminikubeインストールのページに一応Windowsに入れる方法も書いてあるので確認してください。

• OS: ubuntu 18.04.2 LTS

Kubernetesとはなにか?

Kubernetesはコンテナオーケストレーションのツールです。Googleによって開発されました。Kubernetesはコンテナ化されたワークロード・サービスを運営するためのプラットフォームツールとも言えます。Wikipediaもわかりやすいので見るといいかも。

Kubernetesとはポータブルで拡張の容易なオープンソースのプラットフォームです。コンテナ化されたワークロード・サービスを運営するためのもので、宣言的な設定とオートメーションの両方を使用します。Kubernetesは大規模で、早い成長を見せているエコシステムが備わっています。Kubernetesのサービス・サポート・ツール等は広く利用可能です。
-- Kubernetes https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

公式のチュートリアル

もしminikubeをインストールしたくなければ、Google公式のチュートリアルがオンラインで利用可能です。こちらからどうぞ。ただし英語版です。日本語版は探したけど2020年5月現在見つからなかったです。

Minikube

さて別にオンラインのチュートリアルは使いたくない、もしくはすでにチュートリアル実行済みで、ローカルで実際にKubernetesを体験したい場合はどうすればいいでしょうか。そんなときに使うのがMinikubeです。Minikubeは公式ページで以下のように説明されています。

MinikubeはKubernetesをローカルで簡単に実行するためのツールです。MinikubeはシングルノードのKubernetesを仮想マシン内で動かします。MinikubeはKubernetesをローカルで試してみたいユーザー、または日々の開発に利用したいユーザーが使うことを意図しています。
-- Kubernetes https://kubernetes.io/docs/setup/learning-environment/minikube/

「Docker（＋コンテナ）」と「Vagrant」を比較

私はVagrantで作る仮想マシンが（簡単に作れるので）好きなのですが、最近はDockerで環境を作るプロジェクトのほうが多くなりました。理由は簡単でDockerで仮想マシンを作るほうが本番デプロイや運用が楽だからです。（以前の私みたいに）「え？どっちも仮想環境を作るためのものでしょ？何が違うの？」という考えの人もいると思います。確かにどちらも仮想環境を作るためのものですがその目的が違います。これはKubernetesのコンテナの理解にも関わるので説明します。

まずVagrantは開発時に使う仮想マシンを作成するためのものです。その目的は「本番環境と大体同じ環境を仮想的に開発用マシンのなかに作る」です。要は本番環境とそっくりな環境を開発者のPCの中に作りたいわけですね。そうやって仮想環境を作り、そのなかで動かしながら開発することで本番デプロイ時に環境差異によって起こる問題を最小限にしようとします。

対してDockerは開発環境でも本番環境でも両方で使うことを意図しています。まずDockerというベースの上で動くコンテナ単位で開発します。例えばApacheもしくはNginx用コンテナ、アプリ用コンテナ、DB(MySQLとか)用コンテナ、というように1コンテナ1プロセスで開発します。開発が終わったら本番環境のDockerでこれらのコンテナを動かすだけです。このように1つの目的で複数コンテナを束ねて使うことをコンテナのオーケストレーションといい、通常はDocker-compose（もしくはKubernetes）を使って実現します。

開発・本番どちらの環境でもDocker上の仮想環境（コンテナ）で動かすことで、環境差異を最小限にしますし、さらにデプロイも開発で使用したDocker imageをDockerhubを経由しそのまま本番環境で使うだけなので簡単にできます。さらに作成したコンテナを別の（Dockerを利用する）プロジェクトで使うなんてことも可能です。この意味でポータブルな環境だということもできます。

ときどきDockerを開発環境でのみ使うプロジェクトもありますが、それはDockerのほうがAnsible+Vagrantより軽いから、あるいは単純にDockerよくわかんないけど話題だから使ってみようぜ等の理由から使っているのでしょう。

「Kubernetes」,「Docker-compose」,「Docker Swarm」を比較

Kubernetesは複数ホスト間でコンテナを起動、互いに接続するためのもので、それらコンテナがクラスターという単位で管理されます。それぞれのノードは仮想マシンもしくは物理的なマシンであり、クラスタ内でワーカーマシンとして機能します。詳しくはこの説明（ただし英語）を参照。

平たく言えば、単一ホストで複数コンテナのオーケストレーションをするのが「Docker-compose」です。複数ホスト間で複数コンテナのオーケストレーションをするのが「Docker Swarm」もしくは「Kubernetes」になります。

以下のスタックオーバーフローが参考になると思います。
What's the difference between docker compose and kubernetes? - stackoverflow

minikubeを使ってみよう

minikubeをインストール

Kubernetes公式のこのページに詳しくわかりやすくminikubeインストール方法が書いてあります。

minikubeとkubectlを使ってみる

このコマンドを実行するとminikubeを起動することができます。ただし「前提」でもいいましたが、筆者はLinux(Ubuntu)環境で実行しているためご注意。

$ minikube start

すると以下のような起動メッセージが表示されます。

さあ「kubectl」をローカルで使用するための準備が整いました。ちなみにKubectlというのはKubernetesクラスターをコントロールするためのコマンドラインツールです。

試しにnginxサービスを作ってみる

kubectlで試しにコンテナイメージ「nginx:1.7.9」を利用してKubernetesクラスターにnginxをデプロイしてみましょう。

最初にマスターノードが動いていることを確認します。

$ kubectl get all 
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   3d7h

動いていることが確認できたらローカル環境のどこかにyamlファイルを作成、以下のように書きます。これらはデプロイとデプロイされるサービス（nginx）を定義するものです。

nginx_deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    name: nginx
spec:
  selector:
    matchLabels:
      name: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

nginx_service.yml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 30080
      name: http
  selector:
    name: nginx

書き終わったら保存して以下のコマンドを実行します。

$ cd (yamlファイルを保存したディレクトリ)
$ kubectl apply -f ./nginx_deploy.yml  -f ./nginx_service.yml

nginxが動いているかブラウザから確認

minikube IPを以下のコマンドで確認しましょう。

$ minikube ip
192.168.99.100

以下のコマンドでポートナンバーを確認します

$ kubectl describe service/nginx
Name:                     nginx
Namespace:                default
Labels:                   name=nginx
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"name":"nginx"},"name":"nginx","namespace":"default"},"spec":{"...
Selector:                 name=nginx
Type:                     NodePort
IP:                       10.111.250.254
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  30080/TCP ####ポートナンバーここ!!!!!!!####
Endpoints:                172.17.0.4:80,172.17.0.5:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

上記で確認したIPアドレス＋ポートナンバーをブラウザに打ち込みます。すると以下のような画面がでてnginxが（yamlで指定したクラスタ内で）起動していることが確認できます。

確認ができたらデプロイとサービスを以下のコマンドで削除することができます。

$ kubectl delete service/nginx deployment.apps/nginx-deployment
$ kubectl get all 

IT系の作業を正確に見積もる

IT系の技術者なのですが作業の見積もりが正確にできなくて困っていました。そこでネットを検索してみるとこんな記事がありました。この記事ではより良い見積もりを作るために次の方法が挙げられていました。

• プロジェクトのステップを進める（要件定義、UI設計まで進めてから見積もる）
  • 変更が発生することも考えられるので定期的に見積もりを更新してプロジェクト内外に周知する必要がある
• その場で回答しない
  • 「今は手が離せないので15分ほしい」のように伝え、整理した後に回答する
• バッファを設ける
  • スケジュールバッファ
  • フィーチャーバッファ
• PERT法を利用する

最後に挙げられているPERT法は次のように見積もります。

• 最良時間
  • 何も問題が起きず、全てがスムーズに進んだときに必要な時間
• 最有力時間
  • 完了する確率が最も高いと思われる時間
• 最悪時間
  • 問題が次々に見つかって最も上手くいかないときに必要な時間

これらの値を次のように計算することで見積もり時間を出します。

（最良時間 + 最有力時間 × 4 + 最悪時間）÷ 6 = 見積もり時間

これを自動計算するものをJavascriptで作りました。

最良時間： 日
最有力時間： 日
最悪時間： 日
見積もり時間： すべての欄に入力してください。

MigrationとBake

Migration（マイグレーション）とはなにか

Migrationとはなんでしょうか。これはDBのテーブルにアクセスするページを追加する際には一番最初に実行するコマンドと言えるくらいによく使うコマンドです。MigrationとはMigrationファイルを実行、DBにテーブルを新規作成（あるいは逆にロールバック）する際に使うコマンドです。

まあこんな説明だけ聞いてもわからないので実際に使ってみましょう。
以下のコマンドを実行します。

$ cd /vagrant/cake
$ bin/cake bake migration CreateProducts name:string description:text created modified

(CakePHP3の解説ページ)

すると「cake/config/Migrations」ディレクトリにMigrationファイルが追加されます。
（このコマンドの実行に失敗する場合はおそらくファイルのパーミッション設定がうまくいっていないものと思われます。共有フォルダ内のエラーを見ながら対処してください）

これがMigrationファイル

このMigrationファイルから新しいテーブルをDB内に作成します。次のコマンドを実行してください。

$ bin/cake migrations migrate

すると新しいテーブルが作成されます。

つまり、流れとしてはまずbin/cake bake migration CreateProducts name:string description:text created modifiedでMigrationファイルを作成、その後にbin/cake migrations migrateコマンドでそのファイルからテーブルを作成するという感じになります。

本当にテーブルができているのか、確認してみます。

$ mysql -uroot -proot
mysql> show databases;
mysql> use test;
mysql> show tables;

すると新しいテーブル「products」が追加されていることが確認できました。Cakephp3ではこのようにテーブルの作成・削除・修正はmigrationファイルを通じて行います。migrationファイルを通じてすることで、migrationファイルを（gitなどで）共有する他のチームメンバーともDBの構造（テーブルの有無や修正内容）を即座に共有することができるのです。

（関係ないけどGitを使う人向けに補足：このためGitを使用する際、ブランチを変更する際にはブランチ変更前に全てmigrationをroll backし、ブランチ変更後にmigrationを再度実行するという操作が必要となります。これをしないとmigrationファイルに記述されていないのにDBにだけ存在するテーブルなどが発生してしまい不具合の原因となります。こういったものはbin/cake migrations statusコマンドで確認することができます。「missing」とあるphinxログが表示されれば、それが迷子になってしまったmigrationファイルに記述されていない修正です）

Bake（ベイク）

次にこのDBのテーブルからViewを作成します。次のコマンドを実行してください。

$ bin/cake bake all products

これは「controller」「 model」「 template」 のすべてを自動で作成しろという意味のコマンドです。もしそれぞれが個別にほしい場合、次のようなコマンドを実行します。

$ bin/cake bake controller products
$ bin/cake bake model products
$ bin/cake bake template products

すると自動的にView（template）やらModelやらが作成されます。

自動作成したページにアクセスしてみましょう。
http://192.168.33.10/cake/products/

これがその自動生成したページであり、データの登録・削除・詳細閲覧など基本的な機能が自動で作られています。

自動生成されたページ

左端に見える「New Products」を押してみてください。するとデータを登録する画面に飛びます。この画面から製品（Product）情報を登録できるようになっているので試してみてください。

さてこのようにCakePHP3のBakeとMigrationを使うとあっという間に、かつバグが入る余地もなく（もちろん私たちの手で改造すればバグが入りこむ可能性がありますが）ウェブサイトを作ることができました。もし「製品の登録・削除・閲覧機能がほしい」というお客さんがいたらすぐその要望に応えることができますね。

また同じようにすることで「顧客管理」ページや「社員管理」ページも追加することができます。あとは見た目をWebデザイナーにでもかっこよくしてもらえば個性も演出できるでしょう。これがCakePHP3を用いたウェブアプリの高速開発です。

結論

Migration（マイグレーション）ってなに？ --- テーブルを作成・編集・削除するため、またそれを他の人に共有するために使います。
Bake（ベイク）ってなに？ --- 指定されたテーブルから基本的な機能（Model, Controller, Template）を自動生成するために使います。


1. vagrantとvirtual box
2. アパッチのインストール
3. MySQLのインストール
4. PHPのインストール
5. CakePHP3のインストール
6. MigrationとBake

CakePHP3 共有フォルダ内のエラー

Vagrantでcakephp3を使用している場合、共有フォルダでエラーがでることがあります。その場合はフォルダのownerをapacheに変えます。

$ sudo chown -R apache:apache /vagrant/cake

Vagrantのバージョンが古いのかよくわかりませんが共有フォルダ内のownerが変更できないことがあります。その場合は一旦仮想マシンを終了、Vagrantfileに以下をそのまま書き加えます。環境に応じて書き換えたりする必要はありません。

config.vm.synced_folder "./", "/vagrant", owner: 'vagrant', group: 'apache', mount_options: ['dmode=777', 'fmode=777']

それで仮想マシンをもういちど起動します。
なおファルダ・ファイルの権限は当該フォルダ内でls -lコマンドを実行することで確認できます。

それでも治らない場合はSE Linuxが悪さをしている可能性があります。
以下のようにSE Linuxをオフにします。

$ sudo getenforce
Enforcing
$ sudo setenforce 0
$ sudo getenforce
Permissive

それで仮想マシンを再起動します。

Mounting failed with the error: No such deviceとかいうエラーがでて共有フォルダーが使えない

Vagrantを使っているとときどき「Mounting failed with the error: No such device.」とかいうエラーがでて共有フォルダーが使えなくなることがあります。以下のようなメッセージです。

mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant

The error output from the command was:

/sbin/mount.vboxsf: mounting failed with the error: No such device

このエラーがでたらとりあえず仮想マシンにssh接続します。このエラーは共有フォルダーのマウントのエラーであって仮想マシンの立ち上げに関するものではありません。なのでこのエラーがでてもssh接続自体はできるのです。

Tera termなどでssh接続したら以下のコマンドを実行します。

$ sudo yum -y install kernel-devel kernel-headers dkms gcc gcc-c++ 
$ sudo /etc/init.d/vboxadd setup

ただしCentOS7以降は「$ sudo /etc/init.d/vboxadd setup」のコマンドはいらないようです。

できたら仮想マシンを再起動します。

vagrant halt
vagrant up

これで共有フォルダーが使えるようになったはずです。確認してみてください。もしそれでも使えない場合は以下のコマンドでカーネルのアップデートをします。

$ sudo yum -y update kernel

それで仮想マシンの再起動をします。

vagrant reload

Linux mintの導入・インストール

Linux mintの導入・インストール

１、Linux mintを配布しているページへ行く。ここ。
２、Linux mintのISOイメージをダウンロード。(１時間〜２時間くらいかかります)
３、ダウンロードしたISOイメージを適当なところに保存。
４、DVD-Rを用意する。多分１００均のやつじゃだめ。ヨドバシカメラとかで4GBくらい入るやつを買ったほうがいい。
５、ImgBurnをダウンロード。これを使って、用意したDVD-RにISOイメージを書き込む。
６、書き込みが成功するとよくわからない明るい音楽が流れる。このLinuxのISO書き込み済みDVD-Rは「ライブDVD」と呼ばれます。
７、電源コードがつながっていること、LANケーブルがつながっていることを確認。書き込み済みのDVD-R（ライブDVD）をセットしたまま再起動、windowsのロゴが出る前にF2を連打してBIOS画面を出す（PCメーカーによって連打するキーは異なるようですが、だいたいF2です。ちなみに私が使用していたのは東芝dynabookですがF2でした）
８、BIOS画面に「Boot」だか「起動」っていうのがあるはず。その画面をだす。ここでCD/DVDドライブの優先度を一番上にする。F5/F6で変えられるようです。

画像引用元：http://okuzawats.com/ubuntu-live-dvd-20150610

９、再起動する。するとDVDのなかのLinux mintが立ち上がります。PCをLinux化したい場合、立ち上げたLinux mintのデスクトップにインストール用のファイルがあるので、それをダブルクリック、そのままLinux mintをインストールしてください。

PHPのインストール

最初にすること

とりあえず現時点でインストール可能なPHPのパッケージのバージョンを確認します。

$ sudo yum list php*

まあおそらくはクッソ古いPHPしかないと思います。以下のコマンドでepelとIUSのリポジトリを利用可能にし、最新のPHPをインストールできるようにします。

CentOS7

$ sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm

CentOS6以前

$ sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ sudo yum install https://centos6.iuscommunity.org/ius-release.rpm

最新版（執筆時点ではphp7.2）が利用可能になりました。とりあえずインストールします。

$ sudo yum -y install php72u php72u-mysqlnd php72u-gd php72u-mbstring php72u-opcache php72u-xml php72u-pecl-xdebug php72u-pdo php72u-devel php72u-json

phpのインストールが終わったらアパッチの再起動をします。
(CentOS7)

$ sudo systemctl restart httpd

(CentOS6以前)

$ sudo service httpd restart

するとphp7.2があなたのサーバーの動いている状態になります。 これを確かめるために適当なテキストファイルを共有フォルダの中に作成し、これをinfo.phpという名前に変えます。拡張子も変えてください。変わらない場合はWindows側で拡張子を表示させる設定を先にしてください。

そしたらinfo.phpの中にこう書きます。そして保存して終了します。

<?php
phpinfo();
?>

こんな感じ。

そしたら仮想サーバーにブラウザからアクセスします。vagrantを使っていてprivate networkの設定になっている場合はhttp://192.168.33.10/info.phpにアクセスすればいいはずです。
以下のように表示されれば成功です。phpは正常に動いています。

ついでにxdebugの設定もしておきましょう。
phpの設定ファイルを開きます。

$ sudo vi /etc/php.ini

その設定ファイルに以下をコピペします。青い部分と赤い部分は環境によって違う可能性があるのでよく確認してからにしてください。

[XDebug]
zend_extension=/usr/lib64/php/modules/xdebug.so
html_errors=on
xdebug.remote_autostart=on
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host="192.168.33.10"
xdebug.remote_port=9000
xdebug.remote_mode=req
xdebug.idekey="netbeans-xdebug"
xdebug.remote_connect_back = On

vi (あるいはvim) の操作法
「a」を押すと編集モードになります。エスケープキー（esc）を押すと編集モードを終了、コマンドモードに戻ります。「?aaa」と入力すると「aaa」という文字列でそのファイルの中を検索し、最初のヒット内容に移動します。「#」をクリックで次のヒット内容に移動します。
何もせずにファイルを閉じるにはコマンドモードで「:q!」を入力します。編集内容を保存してファイルを閉じるには「:wq」を入力します。

赤いxdebug.remote_host="192.168.33.10"があなたの仮想マシンのIPアドレスです。つまりゲストのほうのIPです。Vagrantfileに書かれているIPを書いてください。
青いzend_extension=/usr/lib64/php/modules/xdebug.soにはxdebug.soの場所を書きます。
まずlocateを使えるようにします。CentOS6以前は多分デフォルトで入ってます。

$ sudo install mlocate
$ sudo updatedb

そしてxdebug.soの場所を調べます。

$ sudo locate xdebug.so

もし場所が違うようなら正しく修正してください。

できたらアパッチの再起動をします。

$ sudo systemctl restart httpd

XdebugとNetbeansの設定

さっき作ったinfo.phpを見ると現在なんのパッケージが入っているのか、どういう設定なのかがわかります（ただし見れるのは当然PHP関連のみ）。

これを見るために・・・・

これを作りましたね。

info.phpが動いているのを確認したらIDEであるNetbeansをインストールしましょう。
https://netbeans.org/features/php/

私はNetbeans version 8.2をインストールしました。

インストールが終わったらNetbeansを「管理者として起動」で起動します。
そしたら
File --> New Project
をクリックします。

PHP --> PHP Application with existing sources を選びNextをクリック。

そしたらこんな画面になります。「Browse」からプロジェクトフォルダを選びます。今回は共有フォルダであるMyCentOsフォルダを指定します。つぎにPHPのバージョンを選びます。今回は「7.2」が選択肢になかったので「7.0」にしました。デフォルトエンコーディングには「UTF-8」を選びます。できたらNextをクリック。

「Project URL」にはあなたのプロジェクトのURLを書きます。つまり、さっきのvagrantの仮想サーバーのアドレスhttp://192.168.33.10/ですね。Index Fileにはプロジェクトのindexファイルのパスを書きます。今回はinfo.phpなのでinfo.phpのパスを書きます。そしたら「Finnish」を押します。

そしたら違う画面になるので、プロジェクト名の上で右クリックします。
するとメニューが出るので「Properties」を押します。

そしたら左のメニューから「Run Configuration」を選択し、右のメニューから「Advanced」をクリックします。

するとこのような画面になるので「Sever Path」をダブルクリックします。さらに仮想サーバー内のプロジェクトパスを書きます。今回は共有フォルダ直下に入れているだけなので/vagrantです。「Project Path」にはホスト側のプロジェクトパスを書きます。「...」をクリックしてプロジェクトパスを指定しましょう。今回は共有フォルダ直下に入れているだけなので「C:\MyVM\MyCentOs」です。

全部できたら「OK」を押しましょう。

するとxdebugが動くはずです。行番号をクリックするとブレイクポイント（処理が一時停止する場所）を追加できます。ブレイクポイントを作ったら上のメニューからデバック用の処理開始ボタンを押します。

すると処理がブレイクポイントの場所で止まるはずです。止まったら、その時点の変数の中身などいろいろな情報がわかります。開発には欠かせないものです。このようなプログラムの実行をステップ実行といいます。F7を押すと次の行にうつります。
もし色々すべてうまく行ったなら、右下に「netbeans-xdebug: running」が表示されるはずです。されていない場合は何かがうまく行っていないです。

補足

ファイルの１行目で処理を停止したい場合、 「Stop at First line」にチェックを入れます。

するとファイルの１行目で処理が止まるようになります。慣れてくるとファイルが変わるたびに処理が止まるのがうざく感じるので私はオフにしてます。

もしxdebugがちゃんと動かないなら仮想サーバーのエラーログを確認します。

# less /var/log/httpd/error_log

現在の通信状況を確認する場合はこのコマンドです。

# netstat -an

xdebugはポート80番で動きます。なのでxdebugがちゃんと動いている場合、こんなふうな通信があるはずです。

tcp6       0      0 192.168.33.10:80       192.168.33.2:49901      ESTABLISHED

Netbeansのポートは9000番です。

tcp        0      0 192.168.33.10:52024    192.168.33.2:9000       ESTABLISHED

Netbeansのポート番号は以下から変更可能です。

stackoverflowより引用の図。

Citation from stackoverflow (an answer from Linus Kleen) https://stackoverflow.com/questions/8049776/xdebug-for-remote-server-not-connecting

もし通信がなぜか失敗しているならウイルスソフトかファイアウォールがxdebugとNetbeansの通信をブロックしている可能性が高いです。その場合はファイアウォールやウイルスソフトのブロック履歴を確認してください。

CakePHP3

CakePHP3を使っている場合はRun Configurationを以下のように変えます。「cake」はcakephpアプリの名前ですがもし違う名前を使っているならうまく調整してください。とにかくwebroot内をproject urlとして設定できればOKです。

リンク：
1. vagrantとvirtual box
2. アパッチのインストール
3. MySQLのインストール
4. PHPのインストール
5. CakePHP3のインストール
6. MigrationとBake

MySQLのインストール

今度はMySQLをインストールします。これがないとデータベースが使えません。

とりあえずCentOSにもともと入っているmariaDBを消します。

$ sudo yum remove mariadb-libs
$ sudo rm -rf /var/lib/mysql/

それからMySQLをインストールします。
このサイトからまずMySQLをダウンロードします。
https://dev.mysql.com/downloads/repo/yum/

ダウンロードといってもCentOSでのダウンロードなのでwgetを使います。wgetはなんのことはありません、単になにかをダウンロードしたいときに使うコマンドです。CentOSはGUIではないので「ブラウザを開きクリックでダウンロード」はできないのです。なので代わりにwgetをつかってダウンロードします。

とりあえずCentOS (Linux) version 7用のMySQLを探してwgetでダウンロードします。
ちなみにCentOSはRedHatLinuxのパクリ（というと言葉は悪いですが）OSなのでRedHatLinuxで動くものはたいていCentOSでも動きます。

CentOS version6用のは一個下にありますね。

以下のコマンドを実行してください。するとダウンロードが始まります。終わったらrpm -ivhでインストールします。

CentOS 7
$ wget https://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm 
$ sudo rpm -ivh mysql57-community-release-el7-10.noarch.rpm
$ sudo yum install mysql-server
CentOS 6以前
$ wget https://dev.mysql.com/get/mysql57-community-release-el6-10.noarch.rpm
$ sudo rpm -ivh mysql57-community-release-el6-10.noarch.rpm 
$ sudo yum install mysql-server

するとMySQLがインストールされます。以下のコマンドでMySQLをスタートします。

CentOS7の場合
　$ sudo systemctl start mysqldCentOS6以前の場合
　$ sudo service mysqld start

MySQLのステータスを見るときは以下のコマンドを使います。

CentOS7の場合
　$ sudo systemctl status mysqld
CentOS6以前の場合
　$ sudo service mysqld status

なお、もしなにか間違ってパッケージをインストールしちゃった場合は次のようにrpmからアンインストールします。yumでアンインストールできる場合はyum removeを使います。以下はmysqlをアンインストールする例です。
まずmysqlで検索して正確な名前を調べます。
$ sudo rpm -qa | grep -i mysql
次にその名前を指定してアンインストールコマンドを入力します。
$ sudo rpm -e <正確な名前>

MySQLが仮想マシン起動時に自動的に立ち上がるようにします。
以下のコマンドを実行してください。

CentOS7の場合
　$ sudo systemctl enable mysqld
CentOS6以前の場合
　$ sudo chkconfig mysqld on

とりあえずMySQLのインストールはできましたが、MySQLは初回起動時に設定をする必要があります。次のコマンドを使用して一時パスワードを発行します。

$ sudo grep 'temporary password' /var/log/mysqld.log

赤線部が一時パスワード

それから次のコマンドを使用します。

$ sudo mysql_secure_installation

そしたらパスワードを求められると思うのでさっきの一時パスワードを入力します。そのほかは全部「y」でいいと思いますが、rootにパスワード設定しないとかお好みで設定しても構いません。

rootにパスワードを設定する場合、半角英数字8文字でかつ特殊文字（@など）1字以上、大文字1字以上、小文字1字以上混ぜなきゃいけないパスワードの設定を求められます。これは面倒くさいので4文字かつ変な制約なしにパスワードを設定できるように変えます。

以下のコマンドでMySQLにログインします。

$ mysql -u root -p

ここで以下のSQLを実行することでパスワード設定時のルールが見れます。

mysql> SHOW VARIABLES LIKE 'validate_password%';

これによると現在は「8文字以上、大文字1文字以上、小文字1文字以上、特殊文字@など１文字以上」というルールになっています。

最低4文字以上、他の制約はなしというルールに変えます。

mysql> SET GLOBAL validate_password_length=4;
mysql> SET GLOBAL validate_password_policy=LOW;

さっきと同じSQLを実行するとルールが変わってることがわかります。

新しいrootのパスワードを設定します。とりあえずrootのパスワードは「root」にしておきます。以下のSQLでパスワード変更を行います。

mysql> set password for root@localhost=password('root');

以上でMySQLの設定は終わりです。
MySQLを抜ける場合は以下のコマンドです。

mysql> quit

リンク：
1. vagrantとvirtual box
2. アパッチのインストール
3. MySQLのインストール
4. PHPのインストール
5. CakePHP3のインストール
6. MigrationとBake

アパッチのインストール

1. Apacheのインストール

前回はvagrantとvirtual boxをダウンロード、インストールしました。今回はさらにApacheをインストールして仮想マシンをサーバー化します。とりあえずinfoコマンドをteraterm上で実行してインストール可能なApacheを確認します。

$ yum info httpd

上のようにいろいろな情報が表示されると思います。Nameの部分にhttpdと書いてありますが、これがApacheの名前です。問題なさそうなのでとりあえずApacheをインストールします。

$ sudo yum -y install httpd

するとインストールが始まります。

インストールが始まります。終わるまでしばらくかかるかもしれません。

2. Apache (httpd) をスタートする

Apache（httpd）をスタートするためには以下のコマンドを実行します。パスワードは「vagrant」。
CentOS 7の場合:

$ sudo systemctl start httpd.service

CentOS 6以前:

$ sudo service httpd start

なんかエラーが出て実行できない場合はパスが通っていないのだと思います。なので以下のコマンドを実行します。
CentOS  7の場合:

$ sudo /sbin/systemctl start httpd.service

CentOS 6以前:

$ sudo /sbin/service httpd start

Apacheのステータスを確認するには以下のコマンド。
CentOS 7の場合:

$ sudo systemctl status httpd.service

CentOS 6以前の場合:

$ sudo service httpd status

Apacheを止めるには以下のコマンド。
CentOS  7の場合:

$ systemctl stop httpd.service

CentOS 6以前の場合:

$ service httpd stop

Apacheの再起動には以下のコマンド。
CentOS 7の場合:

$ sudo systemctl restart httpd.service

CentOS 6以前の場合:

$ sudo service httpd restart

3. Apacheが自動的に始まるようにする

仮想マシンがスタートしたら自動的にApacheがスタートするようにするため以下のコマンドを実行します。
CentOS7の場合:

$ sudo systemctl enable httpd.service

CentOS6以前の場合:

$ sudo chkconfig httpd on




4. Apacheが動いていることの確認

Vagrantfileで指定した次のURLにアクセスします。（事前にApacheをスタートしておいてください。）

http://192.168.33.10/

もし仮想マシンとApacheがちゃんと動いていれば次の画面が表示されます。

5. シンボリックリンク

ホストPC内の共有フォルダーにあるものは仮想マシンの/vagrantで共有されます。中に入ってるものがそのまま/var/www/htmlにコピーされれば更新が即座に反映されブラウザからアクセスして更新が確認できたりするので便利です。なのでこれを実現するためにシンボリックリンクを張ります。

$ sudo rm -rf /var/www/html
$ sudo ln -fs /vagrant /var/www/html

これでシンボリックリンクが張れたはず。以下のコマンドを実行して、共有フォルダ内のファイルが表示されれば成功です。

$ ls /var/www/html

この共有フォルダにhello.htmlとかphpファイルとかpythonのファイルをいれることでhttp://192.168.33.10/hello.htmlのようにブラウザからアクセスできるようになります。


リンク：
1. vagrantとvirtual box
2. アパッチのインストール
3. MySQLのインストール
4. PHPのインストール
5. CakePHP3のインストール
6. MigrationとBake

vagrantとvirtual box

vagrantで仮想環境を作って開発環境を整える方法を書きたいと思います。

1. とりあえずvagrantとvirtual boxをダウンロードする

2つとも無料です。

Virtual Box - https://www.virtualbox.org/wiki/Downloads
Vagrant - https://www.vagrantup.com/

ダウンロード、インストールまでしてみてください。

2. 確認

インストールが終わったら以下のコマンドをコマンドプロンプト上で実行します。
（コマンドプロンプトってあの黒いウィンドウです。なんだそれって人はcmdでPC内を検索すると見つかります。）

vagrant -v

ちなみに書籍では以下のようにコマンドが書かれることがありますが

$ vagrant -v

この「$」はスーパーユーザーでない一般ユーザーとしてログインしていることを示しています。ゆえに「$」は入力しなくて構いません。ちなみにスーパーユーザーを示すのは「#」です。こっちは管理者とかが使うものです。

vagrantがきちんとインストールされている場合は下のようにバージョン情報が出ます。

3. 仮想マシン用のフォルダを作る

とりあえずC直下に「MyVM」というフォルダを作ります。

ここに「MyCentOs」というフォルダをさらに作ります。

この「MyCentOs」内に仮想マシンを入れます。コマンドプロンプト上でも同じディレクトリに移動する必要があるので、以下のコマンドを入れます。

$ cd C:\MyVM\MyCentOs

するとコマンドプロンプト上のディレクトリも変わるはずです。

4. Boxをinitする

とりあえずbento/centos-7.3というboxを使ってcentos バージョン7.3の仮想マシンを作ってみます。Bento Boxはこちらで確認できます。Boxというのは仮想マシンを作るための情報が詰まっているいわば種みたいなものです。ここから仮想マシンを作るのです。

以下のコマンドを入力してください。

$ vagrant init bento/centos-7.3

すると以下のようなメッセージがでます。

するとさっきのディレクトリに「Vagrantfile」というファイルができます。

これをメモ帳で開きます。

それでVagrantfileを次のように変えます。

#がいっぱいならんでますが、これは#の右側をコメントアウト（プログラム実行時に無視される）するものです。下の「ici」って書いてあるところの#を消してprivate networkの部分をコメントインします。

（ちなみにiciっていうのはフランス語でここって意味です）

(ちなみにメモ帳よりは「Sublime Text」のほうがずっと使いやすいです)

5. Vagrant up

上記のようにコメントインできたらそれをいったん保存して閉じてください。その後にコマンドプロンプト上でvagrant upと入力、実行します。

vagrant up

それで以下のような感じになったら成功。仮想マシン（Cent OS 7.3）が立ち上がります。こいつは仮想マシン（Cent OS 7.3）なので内部でいくら無茶なプログラム走らせようがめちゃくちゃな設定をしようが、最悪ぶっ壊したとしても代わりの仮想マシンをいくらでも同じように作れます。なので練習や開発に最適なのです。

仮想マシンを止めるときは次のコマンドを使ってください。

vagrant halt

仮想マシンを再起動するときは次のコマンドを使ってください。

vagrant reload




6. SSH接続をする

Windowsを使っている場合、vagrantでSSH接続をするにはTeratermが必要です。
ダウンロードしてインストールしてください。
Teraterm: https://ttssh2.osdn.jp/index.html.en

MacやLinuxを使っている場合はOpen SSHが入っていると思うのでコマンドプロンプト上で

$ vagrant ssh

でssh接続ができると思います。

Teratermを使う場合はこんな風に設定します。

ユーザー名とパスワードは両方とも「vagrant」です。

こんな風になったら接続成功です。

なお、できないという人はおそらくWindowsかアンチウイルスソフトのファイアウォールに接続がブロックされてます。どうしてもできない場合は接続がブロックされていないか、ネットワークのセキュリティを確認してください。

7. Update

SSH接続できたらとりあえずアップデートします。以下のコマンドを使ってください。

$ sudo yum update
$ sudo yum upgrade

なお、vagrantのGuestAdditionsとホストのバージョンが合っていないとフォルダがちゃんとリアルタイムで同期しなくなります。なのでGuestAdditionsとホストのバージョンを自動的に調整してくれる便利なvbguestをインストールします。

コマンドプロンプト上で以下のコマンドを使います。

vagrant plugin install vagrant-vbguest

そしたらコマンドプロンプト上でこういうコマンドが使えるようになります。以下のコマンドはGuestAdditionsとホストのバージョンが合っているかを確認するコマンドです。

vagrant vbguest --status

アップデート（GuestAdditionsとホストのバージョンを合わせたい場合）は以下のコマンドを使います。

vagrant vbguest

Mounting failed with the error: No such deviceとかいうエラーがでて共有フォルダーが使えない場合

おまけ centos/7

Boxの初期化にbento/centos-7.3を使いました。

$ vagrant init bento/centos-7.3

こいつの代わりにcentos/7を使ってBoxを初期化することもできます。

$ vagrant init centos/7

centos/7はより安定した動作が期待できます。 ただし、もしこれを使う場合はprivate_keyを使ったログインをする必要があります。private_keyの場所はここです。

C:\vagrant\centos\.vagrant\machines\default\virtualbox

centos/7を使う場合、さらにこの１文をVagrantfileに追加してください。
config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

centos/7の場合、SELinuxのせいでPHPファイルの実行ができない場合があるので以下のコマンドでSELinuxを一時的に無効にします。

$ sudo yum install policycoreutils-python
$ sudo semanage permissive -a httpd_t

リンク：
1. vagrantとvirtual box
2. アパッチのインストール
3. MySQLのインストール
4. PHPのインストール
5. CakePHP3のインストール
6. MigrationとBake