MinEMemO
【Netlify】従量課金制について

2023-02-26

はじめに 基本無料だが以下の範囲に限るようです。 帯域幅が1か月に100GBまで ビルドできる時間が1か月に300分まで Netlify 価格のページ https://www.netlify.com/pricing/?_ga=2.257123211.1889317529.1677054191-99578306.1677054191#teams 帯域幅とは 「どのくらいユーザーにページを表示できるか」というような数値 帯域幅やビルドの利用時間はNetlifyのTOPで見ることができます。 帯域幅やビルドの利用時間確認画面 ※和訳表示の画像です。 ※開発初期でビルドしまくってた時期の画像です。 ※状況によると思いますが、100GBは10万PVでも大丈夫な数値だそうです。 無料枠超えたらいくら? 早々超えないと思いますが、2023/02時点では以下のようになっているようです。 帯域幅 100GB あたり 55 ドル ビルド時間 500分 あたり 7 ドル 55ドルは高いですね・・ 円安などの影響でしょうか。 万が一超えそうな場合は、スタータープランからプロ版に月額$ 19に加入するのが良さそうです。 プロ版は以下の感じ。 帯域幅 1TB/月 ビルド時間 25,000 分/月 請求を防ぐには? ヘルプページに以下の記載がありました。 「機能をまったく使用しないことを除いて、従量制の機能の使用に制限を設定する方法はありません」 =サイトを削除するしかないみたいです。 Netlify ヘルプのページ https://docs.netlify.com/accounts-and-billing/billing-faq/ クレジットカードを入力しないとどうなりますか? 利用段階で支払情報を登録してない人が大半だと思いますが、支払い通知が来るみたいです。 そのあと、支払いが無い場合は請求通知が続くようです。 早々超えないと思いますが、超えたときはプロに移行か、しっかり支払うのが良いですね。 Netlify ヘルプのページ クレジットカードを入力しないとどうなりますか? その他 個人的にヘルプページを眺めてたら気になった点を簡単に書いておきます。 英語読めないので間違いもあるかもしれません。 現在の使用量が下位レベルの制限を超えている場合、従量制機能の下位レベルにダウングレードすることはできません。(強制的にアップグレードされるということみたいです。) Netlify ヘルプのページ https://docs.netlify.com/accounts-and-billing/billing-faq/ 早々超えないと思いますが、自動課金はNetlifyのデメリットの1つになりそうです。 もし超えたら月2000円くらいのプロ版に入るのが良さそうです。 こうなると毎年およそ一万円前後のレンタルサーバーを借りたほうがよくはなるのか・・
本ブログで記事作成時に使えるパーツについて

2023-02-15

はじめに 当ブログはGatsby.jsをカスタマイズしてつくられています。 この記事ではこのブログで記事を書く時に使えるパーツを紹介します。 Front Matter(記事の設定値) マークダウンファイルの 1行目 から記載します。 一番上の「---」が1行目じゃないとエラーになります。 FrontMatter ---title: 'ブログの書き方' #記事のタイトルdate: '2023-02-15' #作成日update_at: '2023-02-15' #更新日 無いとエラーになるので更新日ないときはdateと揃えてください。slug: 'read-me' #url ファイル名と合わせてくださいhero_image: '../images/gatsby-icon.png' #アイキャッチ画像tags: ["その他","マニュアル"] #タグ カテゴリとして使ってもOK--- 目次 h2~h4で書かれた項目を自動で目次として掲載します。 ※この記事のTOPの目次が作成されます。 HTML+Markdown < div class = " toc-title " > 目次 </ div > \```toc\```※\はなくていいです ボックスパーツ 参考 本文 HTML < div class = " boxparts ref " > < div class = " title " > </ div > 本文 </ div > POINT 本文 HTML < div class = " boxparts point " > < div class = " title " > </ div > 本文 </ div > MEMO 本文 HTML < div class = " boxparts memo " > < div class = " title " > </ div > 本文 </ div > 注意 本文 HTML < div class = " boxparts caution " > < div class = " title " > </ div > 本文 </ div > コードブロック javascript console . log ( '' ) ; \```javasctrpt:title=javasctrptconsole.log('');\```※\はなくていいです マークダウンファイルでの画像読み込み 「./src/images/posts」フォルダに画像格納 以下のようにマークダウン形式で読み込み MarkDown ! [ 画像の説明文 ]( ../images/posts/ファイル名.png ) ※HTMLのimgタグでもOK プロフィール画像+吹き出し ここにセリフを書く HTML < div class = " balloon " > < div class = " icon " > </ div > < div class = " talk " > ここにセリフを書く </ div > </ div > ※このパーツの画像はプロフィール画像が反映します。
【プロジェクト管理】ツールの保守運用に必要なドキュメントの概要

2022-12-20

はじめに ドキュメント管理がされておらず、仕様がわからないツールの対応ばかりをしてきました。 そんな対応はとてもつらく、どうすればこういった辛さを軽減できるのか。 と思い、まずドキュメント管理から、独学ですがUdemyでひとまず学びました。 その内容を個人のメモのために記載しています。 規模も大きく様々なやり方、考え方があるので、あくまで参考程度にして頂ければ幸いです。 手を動かして学ぶITプロジェクトの資料作成!システム開発のドキュメンテーション技術と成果物テンプレート https://www.udemy.com/course/it-yugtl/ なお、ドキュメントの記載方法やFMTはチームごとに違うと思います。 表形式、リスト、図、フローチャートなどなどありますが、結果きちんと記載、確認、共有できれば良いので、どんなドキュメントがあればいいのか?も含めてドキュメント作成、運用しやすいものを選定することは必要だと思います。 0から始める場合に、一番いいのはUdemyの講座の原本やチーム内にある原本から作成を始めることだとおもいます。 プロジェクト計画書 このプロジェクトの目的や背景、ルールなどを記載する。 今後知らない人が確認するときに、プロジェクト開始時の意向や全体像がわかるので方針が決めやすくなると思います。 目的・背景 プロジェクトの目的・背景を記載しておく。 どんな意向があったのかがわかるので、今後知らない人が引き継ぐときに作業方針を決めやすくなります。 本プロジェクトのスコープ 全体の登場人物と流れを記載して、このプロジェクトではここまでを見ます。 という責任範囲を明記する。 きちんと責任範囲を定義することで、仕事の対応範囲を明確にします ソリューション(解決方法) 何を使って何を解決するかを記載する。 この時点では一旦アイデアでもOKで、もし決まってるならそれを記載する。 改善方法をざっくりでもリスト化することで、解決したい課題などがわかるので、具体的な手段のたたき台になる マスタースケジュール ガントチャート的に全体のおおまかなスケジュールを記載する この時点は、おおまかだが、仕様確定のタイミングを決めておくのが大切 タスク・成果物一覧 作りたいツールからタスク、作らないといけないドキュメントの一覧を記載する。 タスクの大枠のカテゴリである「要件定義、設計、移行・運用計画、環境構築・開発、テスト」などに各タスク紐づけて書き、それを各書類の利用用途と合わせて書いておくのが良さそうです。 プロジェクト体制 チーム単位でどこまで何をやるか。という責任範囲をきめて記載しておく。 これがないと収集つかなくなるので大切。リーダーまで決めておくとなお良い。 だれに確認するかなどが分からない時に、チーム単位で責任範囲を確認したりできる。 プロジェクトのルール プロジェクト全体をどう進めるかを可視化し、流れを明確化します。 進捗・課題管理を何でするかの概要。 定例MTGの参加チーム、スケジュール、議題の概要。 MTGで課題があった際のチーム連携の流れ、作業方法の流れ などを記載しておきます。 メール件名とかこまごましたのもあるが、必要なものだけかけばOK 特に定例MTGなどの進捗確認方法が大事。 品質管理方針 ドキュメントでもなんでも成果物に対して、誰がチェックを行い、どう品質を保つのか。というルールを書く。 またどういうものがチェック時にひっかかてるのかを把握すると、全体での認識、共有が深まるのでチェック結果の集計が大切とのこと。 ここで正確な成果物できることで、プロジェクトの想定がより安全になる 要件定義 業務のフロー、それを実現するために必要な機能などを書きだし、設計に必要な情報を可視化します。 業務フロー 実際の業務内容をフローチャート形式にして流れや業務を把握し、課題も記載する。 業務単位の箱ができ可視化することで、現在と将来の箱の数がの増減などが見え、業務の効率化が見えるし、システムの箱が増えたらコストが増えるのでどうするか。 などの指標になります。 業務フローがあっているかは運用チームに確認が必要だが、箱の数の増減でフロー効率化が見込めるか。は自分でチェックができます。 基本的に現在のフロー、将来のフローとそれぞれ記載します。 業務フローをもとに作られる、または紐づく主な資料 業務要件一覧 機能要件一覧 総合テストコンディション・シナリオ定義書 運用作業一覧 業務用件一覧 業務フローの業務内容詳細を表で書き業務の要件の一覧を作成する。 フローと揃うことで、流れ+各業務の概要が整理できます。 以下のようなものを軸に記載します。 業務名 業務概要 担当 変更区分(変更、廃止、同じなのか) 新旧の差異があるならそれも並べて記載 新フローの業務は機能要件をIDで紐づけたらわかりやすい また、業務用件と機能要件など、他資料と関連付けた方が良い場合は、IDなどで紐づけて記載するといいです。 業務用件一覧をもとに作られる、または紐づく主な資料 業務フロー 機能要件一覧 画面遷移図 総合テストコンディション・シナリオ定義書 機能要件一覧 業務を実現するために必要な機能をリスト化した資料。 将来の新業務フローを見ながら実現するために必要な機能をリストで一旦書きだします。 以下のようにかき分けもするそうです。 FitGap分析前:ただの必要機能リスト FitGap分析後:必要機能リストを実際のツールに寄せて、グルーピングし整理したもの 「FitGap分析前」では「画面、処理、IF」などおおまかな区分わけまでしておくといいみたいです。 書きだした後は業務用件一覧の新ツール関連機能と紐づけると、どの業務にどの機能が使われるのかが、わかるようになります。 ※IF=インタフェース=外部連携のシステムのこと 機能要件一覧をもとに作られる、または紐づく主な資料 業務用件一覧 機能配置図 テーブル一覧 画面遷移図 画面項目定義書 処理概要定義書 単体テストコンディション定義書 機能配置図 機能要件を参考にどんなシステム(環境)でどうつながっているのか?フローで記載する。 例)Web、メールサーバがそれぞれあり、それがどういうシステムと繋がってるのか?など これがあることで、システムの全体像がつかめます。 また、現在と今後がかけると比較もできていいそうです。 機能配置図をもとに作られる、または紐づく主な資料 テスト計画書 結合テストコンディション・シナリオ定義書 インタフェース(IF)一覧 どんな外部システムとどんなタイミングで連携するのか どんなプロトコルで接続する、データ形式でやりとりするのかなどを書きだす。 このIF一覧をもとにその担当とやりとりするので、システムを漏らさずに記載するのが必要。 なお、この値を~みたいな細かいことは後の設計で記載するので、システムの概要くらいの内容でいいとのこと。 インタフェース(IF)一覧をもとに作られる、または紐づく主な資料 IF項目定義書 機能要件一覧 ライセンス一覧 外部ツールなど契約が必要なものをまとめる。 時間がかかる契約もあるので、キチンと記載する。 開発用のPCとかそういうもの含めて調達しないといけないものを記載する。 非機能要件も考慮しないといけないとのこと テーブル一覧 自分たちが作成、利用するデータベースのテーブルを対象に表で概要を記載する。 作成、利用しないテーブルはキリがないし、そのテーブルが変更になったら資料も修正しないといけなくなるので書かなくていい。 正確な情報にすることが大切。 テーブル一覧をもとに作られる、または紐づく主な資料 テーブル項目定義書 ER図 ER図 データベースのテーブルの関係性を示す図を作成する。 ER図は以下から押さえておくとOK 〇:0 |:1の関係 三本線:多の関係 いろんな作成ツールもありますし、さらなる詳細は必要に応じて調べてみてください。 画面遷移図 業務用件、機能要件作成後に新フローに沿ってフローで作成する画面の遷移図 ER図と画面構成図があれば開発ボリュームはある程度図れるとのこと。 なお、既存の仕組みをそのまま使う場合は作成必須ではない。 非機能要件 業務フローに必要な機能以外の要件を書きだす。 通常時、障害時、セキュリティ、メンテナンス、運用、保守などなどかなりたくさんの項目があり、広範囲で想定しないと書けないので、作成難易度はかなり高い印象でした。 また、これも業務やチームに寄って内容や形式が異なりそうなので、既存フォーマットがある場合はそれに沿って作成。 ない場合はIPAなどを参考に基礎を作成するのが良さそうな印象でした。 システム構築の上流工程強化(非機能要求グレード) ※参考ファイル 「06_活用シート.xls」 (非機能要求グレード本体(日本語版) の一括DL(zip)をDLすると入ってます) 設計 要件定義からツールを作成するための資料を作成します。 設計書を作成すれば、あとは開発するだけでOK。という状態にすることが理想。 IF項目定義書 要件定義で決めたIF一覧から、どんなURL?どんな項目?といったものを決める。 リクエスト、レスポンスの値について記載するが、これはDBのテーブル構造と同じ内容になるはずなので、きちんと決めておくのが良い。 テーブル項目定義書 要件定義で作成したテーブル一覧のテーブルごとのカラム情報などの詳細を記載する 既存の物や把握できないものは記載せずに、作成する分だけ記載するという判断でもOK。 正確な情報を記載することが大切。 テーブル項目定義書をもとに作られる、または紐づく主な資料 テーブル項目定義書 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける 画面項目定義書 機能要件一覧から作成した画面とその構成、処理、項目の詳細情報を記載する。 画面の処理や仕様が分かればOKなので、以下のような情報を記載します。 既存画面がある場合は画面のキャプチャー画像 新規画面の場合は簡単な図形で画面のパーツ構成が分かるように記載 画面の遷移元、遷移先 画面項目(テーブル項目定義書と同じように書く) 処理概要として、この画面の処理の内容、トリガー、リクエスト、エラーなどを記載 ※処理概要は別ファイルの「処理概要定義書」に記載してもOK これを見て画面ごとに構成、処理の内容が分かるようにすることが大切。 画面項目定義書をもとに作られる、または紐づく主な資料 機能要件一覧 単体テストコンディション定義書 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける 処理概要定義書 ※画面項目定義書に書けない処理を記載する 標準パラメータ定義書 クラウドシステムやパッケージの機能を使う場合に作成する。 利用に際して設定した項目の値を記載し、今後のために情報を残しておく。 処理概要定義書 機能要件一覧のIDと紐づけて、機能詳細を記載する。 画面項目定義書で処理概要もあるが、どっちかにかけばOK 分かりやすさ重視。プログラム書くときに仕様がわかりやすいように記載する。 主に以下が分かれば良さそうです。 トリガー リクエスト、レスポンス 処理内容 エラー これを見て処理の内容が分かるようにすることが大切。 処理概要定義書をもとに作られる、または紐づく主な資料 単体テストコンディション定義書 機能要件一覧 コード定義書 ※データ名を数値などで管理する場合にその情報を記載するドキュメント ※利用ヵ所を把握するために、どのカラムがどのコードIDなのか紐づける コード定義書 データベースやプログラム内の値をコードで管理する場合に記載する。 データをコードで管理する事で名前の変更に耐えれるが、ぱっと見わからなくなるので設計書にかいておく 使われる場所がわからないといけないので、テーブル項目定義書、画面項目定義書でIDでつながるように紐づけて書いてあげるのも大事。 コード定義書をもとに作られる、または紐づく主な資料 テーブル項目定義書 画面項目定義書 環境設定定義書 インフラ情報を管理するために必要な情報を記載する。 環境構築時に設定した値を記載し、今後確認できるようにしておく。 テスト 設計書から作成したツールのテストをする場合に必要なドキュメント。 ポイントはプログラムからつくるのではなく、ドキュメントから作成するという点。 ドキュメントにプログラムを合わせていくのが大切です。 テスト計画書 テスト全体の概要などを記載します。 主に以下の内容を記載します。 テストスコープの定義 機能配置図から機能ごとにどんなテストをするのか?を記載します。 フローチャートで単体、結合、統合などを色分けで書くとわかりやすいです。 なお、テストは以下のようなものがあります。 単体テスト 設計書に定義した機能がすべて正常に実装されていることを確認する。 設計書に定義した処理の全パターンを網羅すること 結合テスト IFなど連携先のINとOUTにある機能が、互いに整合のとれた設計になっていることを確認する IF定義書に定義したデータパターンを流通するテストを実施 総合テスト 業務フロー、および業務一覧に定義した業務がすべて行えることを確認する 受入テスト 総合テストと同じようなことを依頼元で行う 開始条件と完了条件 単体テスト、結合テスト、統合テスト、受入テストの開始条件と完了条件を表で記載する。 例えば単体テストの条件なら以下のようなものがあります。 開始条件:全ての開発が終わっている 完了条件:定義した条件をすべてクリアした、不具合の発生頻度が収束した。 基本的に前段階の作業が完全に終わっている、定義した条件をすべてクリアしている、ある程度の期間利用し、不具合の発生件数が収束してきている。というのが基本的な条件になると思います。 テスト実施スケジュール テスト期間とその間の移行リハーサルのスケジュールを記載する。 各フェーズでの重要な条件となることの完了予定も記載しておくのが大事。 また移行リハーサルを統合テスト前に行う。 移行とはデータの移行など旧→新へ移行するときの作業のこと。 障害管理プロセス 障害が発生した際の担当の流れを記載する。 誰が何をするのか?がフローでわかればOK。 テスト実施体制 今回のテストにかかわるチームの関係性が分かるように記載する。 テスト期間中の情報連携 テスト期間中の定例MTGなどどういったサイクル、議題、目標で行うのかを記載しておく 単体テストコンディション定義書 機能単位のテストの条件を書き出し作業用のリストを作成する。 機能要件一覧、画面項目定義書、処理概要定義書を軸に項目、処理機能ごとに記載する。 通常?異常? 必須?必須じゃない? 登録、削除、更新はできるか テストに使うデータ など各処理とテストデータを記載していきます。 またテスト時の入力値は最小値と最大値や、機能の条件をが満たせるのが良い。 なお、インタフェース(外部連携)機能は結合テストでするので、ここはあくまで今見てるツールの動作だけでいいOKです。 IFが完成してない場合は、スタブ(値だけ返す仮のインタフェース)を簡単に作成しておく また最大のポイントはプログラムをみて設計書をつくらないこと。 設計書から作成し、設計書どおりに動いてるか複数回数日に分けて確認する。 単体テストコンディション定義書をもとに作られる、または紐づく主な資料 機能要件一覧 画面項目定義書 処理概要定義書 結合テストコンディション・シナリオ定義書 単体テストと違い、複数の処理を組み合わせたテストです。 そのため複数項目を経てOKとなることが多いです。 テストを行うためのテストシナリオ(操作手順ごとにテスト項目を並べたもの)を機能配置図、機能要件一覧を基準に作成します。 コンディションシートで項目を網羅的に書きだし、シナリオシートでそれを体系的記載します。 1つのシナリオで全部しようとすると書けないので、1つずつ書いて、いくつかシナリオを分けて作成します。 入力値などサンプルデータの作り方は単体テストと同じ感じです。 結合テストコンディション・シナリオ定義書をもとに作られる、または紐づく主な資料 機能配置図 機能要件一覧 総合テストコンディション・シナリオ定義書 将来の業務フロー全体を通すテスト、すべての業務用件が実施できるか確認する 業務フローの数だけ、シナリオもできます。 気付けないことがあるので、データは本番に近いのが良いです。 また総合テストでプログラムのバグがでるのはかなりまずいことなので、それがないように前段階のテストはしっかりしておきたい。 出るべきバグは設計や仕様で漏れていたそもそも想定されていないこと。 総合テストコンディション・シナリオ定義書をもとに作られる、または紐づく主な資料 業務用件一覧 業務フロー 障害一覧 テストの結果を表でまとめて記載する。 まとめることで一日あたりの障害数が減ってるかみれたりするし、書く人、直す人が作業しやすくなる。 どのフェーズ?(単体?結合?統合?) 事象 どの段階?(要件?設計?など) 原因 解決方法 などを書いておくと良いです。 障害一覧をもとに作られる、または紐づく主な資料 単体テストコンディション定義書 結合テストコンディション・シナリオ定義書 総合テストコンディション・シナリオ定義書 移行計画 旧システムから新システムに移行する。 または新システムを導入する方法を正確に記載する。 移行計画書 旧システムから新システムに移行、または新システムを導入する方法の計画書。 主に「業務、システム、データ」のカテゴリで流れ、移行方法、懸念事項を把握しながら記載します。 また新規システムだけならいいが、旧システムが絡む場合、移行するデータの選別、仕様を把握+データの不整合が起こらないように慎重に決めないといけないので、 かなり慎重に計画を作成する必要があるので、移行手順を作成し、総合テスト前に移行リハーサルを行うことは必須になります。 移行計画書として作成する主な内容は以下の通りです。 移行方針の概要 業務、システム、データで何をどうして、どう移行するのかの概要 業務上やデータの整合性を保てるような方針にする。 移行対象データ一覧 移行すべきデータをすべて確認し、移行方針、移行方法を記載する 移行スケジュール 移行全体のスケジュール。 結合テストの段階で調査、手順書の作成を行い、総合テストの前に移行リハーサルをするようなスケジュールが良い 移行体制 移行にかかわるチームを記載する 移行手順書 移行計画を実行するために、いつまでに、どういうやりかたで進めるのかを見ただけでできる状態にまとめておく。 旧システムから引き継いで移行する場合は特に複雑化するので、総合テストの前に本番と同じ移行作業をリハーサルしながら作成する。 もっといえば何時何分~何時何分でこの作業をおこなう。というのも書いておいた方が良いみたいです。 テストコンディションと同じように誰が何をしたがわかるようにリストで作成する 運用計画 システム完成後の運用の作業の一覧やマニュアルを作成する 運用作業一覧 システム完成後の運用の作業の一覧を記載する。 例えば、ユーザ登録、削除、障害対応、仕様変更(追加開発)などがあり、項目としては作業項目、頻度、作業概要などを表で記載する。 運用作業マニュアル 運用の作業一覧の業務を見ただけでできるようにする。 定期作業は特に開発できない人たちにやってもらうこともあるので、詳細に手順を記載しておく必要があります。 ドキュメントをみて運用作業、ドキュメント更新ということを徹底する。 なお、運用という枠に開発の改修なども入る場合もあるそうなので、その場合は開発が仕様を把握できるようにドキュメント管理を行うといいと思います。 障害報告書 障害が起こったときにその原因→解決方法をを記載していく。 難しい+スピードが必要な作業で限られた人しかできないので、原因→解決方法を簡潔に記載しておくことで、今後誰でもできるように、または解決しやすくする。 主に以下の内容を残すと良さそうです。 発生事象 発生原因 影響範囲 暫定対応 根本的な原因 本格対応 プロジェクト管理 プロジェクトを管理するための方法、ドキュメントを作成する。 WBS 全部のタスクについて、だれが何をいつからいつで行うのか+進捗がわかるものように管理しておくことをWBSという。 案件が始まるときに作成し、要件定義が決まったらブラッシュアップするのがいいみたいです。 チームによってさまざまだと思うが、ガントチャート的なフォーマットが多いと思います。Backlogなどのツールもあるのでそういったものを使うケースもあると思います。 TODO・課題一覧 WBSの漏れなどの問題、誰かに聞かないとわからないことなどが起こったらそれ課題として表に記載していく。 TODO(やればおわること)や課題(予想されるリスク、懸念)を記載し事前に認識しておくことで事故を防ぎます。 レビューシート 成果物のレビューを表で残す。 成果物のチェックレビューを残すことで、間違いが多いものなどの傾向を知ることができる さいごに 学んだ感想としては、この書類があり、きちんと見る方法、更新方法を教えていければ、仕様の引継ぎ把握は格段にしやすくなるのではないかと感じました。 一方でドキュメントの量がとても多く、整合性を保つ難しさも感じたので、プロジェクトチーム全体でどれだけ意識をたかめてドキュメントの見方の説明、作成、更新していけるか。が非常に難しく、大変なことだと思いました。 ひとりでは作成できないので、繋ぎ、まとめ役、各専門家の連携は必要だと思います。 またどちらにしてもプログラム内にはちゃんと実装背景、理由などコードから読み取れないことをコメントで残しておくことも必須だと感じました。 率直に量が多い!!大変だ!! 開発より時間をかけるというのもうなずけます。 目次だけでも見るの大変ですが、全体をつかみたいときは目次見てください。 今回勉強して一番響いた言葉は 「プログラムからドキュメントを作成しない。ドキュメントにプログラムをあわせる」 でした。 本当大事。
【Docker】よく使うコマンド

2022-10-26

はじめに Dockerで個人的によく使うコマンドを目的別に記載します。 基本的にDockerのコマンドではなく、docker compose のコマンドを利用しています。 最初は**「コンテナ起動~停止」**だけ使えればいいと思います。 自分でDocker構築したり、その他情報がしりたくなったら他のコマンドが必要になる感じです。 どのコマンドも cd で docker-compose.yml があるフォルダに移動して、行うことは共通になります。 別記事でDockerで以下の環境を作成するチュートリアル記事も書いてますので、よかったら見てみてください。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認 【Docker】#6 LaravelのDB設定、確認 【Docker】#7 phpMyAdmin表示確認 【Docker】#8 できてる環境の確認 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 コンテナ起動~停止 普段一番使うコマンドです。 Dockerの設定ファイルが出来たらあとは環境を起動、停止して開発をすすめるという流れになるので、基本的にこれしか使わなくなります。 ※コマンドじゃなくても、Docker Desktopアプリでもスタート、停止できます。 1.コンテナ起動 以下のコマンドを実行するとコンテナが起動します。 docker-compose up -d ※このコマンドはビルド( docker-compose build )+スタート( docker-compose start )を行っています。 ※ -d はバックグラウンド実行になり、コマンドプロンプトの占有を防ぐためのオプションです docker-compose up 2.コンテナ停止 稼働中のコンテナを停止します。 docker-compose stop ※コンテナの削除はしません。 ※docker-compose start または docker-compose up で再起動できます ちなみに筆者的には stopより down(コンテナ、イメージ削除+停止)が良い と思っています 。 docker-compose down 理由は下の「注意」を参考にしてください。 ■「docker-compose stop」ではなく「docker-compose down」を使う理由 複数の環境を切り替えて使う場合、サービス名やポートの重複、キャッシュなどで、 うまく起動しなくなる場合があります 。 その場合は「docker system prune」で全体のお掃除をして解消も出来ますが、別環境をup(起動)するたびに全てインストールしなおしなので、初回起動時に めちゃくちゃ時間がかかります 。 また、別環境使うときに以前使ってた、もしくは影響してる環境を覚えてない場合は、それを探してdownしないといけなくなります。 なので、筆者としては基本的にstopするときは常に「docker-compose down」を使ったほうが良いと思っています。 docker-compose stop(公式) docker-compose down(ページ内アンカー) 起動しているコンテナの一覧を確認 今起動しているコンテナを確認したい場合は以下のコマンドで確認できます。 docker-compose ps ※コマンドじゃなくても、Docker Desktopアプリでも確認できます。 ※起動していないコンテナも確認したい場合は -a オプションを使います。 docker-compose ps コンテナ内でコマンドを実行したい docker-compose exec サービス名 実行したいコマンド ※このコマンドは docker exec と同じです ※ -it オプションでコンテナの中の環境に入って、対話モードでコマンドできるようにできます。抜けるときはexitでOKです。 例)コンテナ内で bash (コマンドプロンプトの一種)を起動して、MySQLに接続するコマンド $ docker-compose exec DBのサービス名 bash[db]:/$ mysql -u ユーザ名 -p// パスワードを求められるので入力//データベース指定[db] mysql> use database;//テーブル表示[db] mysql> show tables; docker-compose exec イメージからコンテナ(環境)を作り直したい 1.今いるディレクトリに対してイメージ、コンテナの削除 Dockerの設定ファイルを書き直したり、イメージをつくりなおして再度コンテナを起動したい場合は、よく以下のコマンドを使い削除します。 docker-compose down↓docker-compose up -d --build ※ --build:コンテナを開始前にイメージを構築する docker-compose down キャッシュ等でうまく更新できない場合は「docker-compose down --rmi all --remove-orphans」で綺麗にしてから「docker-compose up -d」をすると解決すると思います。 docker-compose down --rmi all --remove-orphans このコマンドを使うことで、Docker内のキャッシュなどの影響で起こるよくわからないエラーなども回避しつつ、再構築ができます。 要約すると以下のことを行います。 今いるディレクトリに対してコンテナ停止、削除、ネットワーク、イメージ、未定義のコンテナを削除してきれいにする 各オプションなどについて↓ docker-compose down は docker-compose up で作成したコンテナとネットワークを停止、削除 –rmi all オプションで全イメージを削除 –remove-orphans オプションでComposeファイルで定義していないサービス用のコンテナも削除 「docker system prune」との違いについて このコマンドはディレクトリ関係なく、使われてないイメージ、コンテナ、ネットワークを削除(prune)するコマンドです。 Docker全体に対するお掃除という感じです。 ■ボリュームについて ※いつか別記事移行するかも… Dockerはメモリ上で動くため、コンテナを削除した時点で作業した内容が消えてしまいます。 そのためボリュームという機能をつかってファイルやDBの情報を永続化し消えないようにします。 主に以下のような用語があります。それぞれ利用します。 ・バインドマウント ローカルのファイルをコンテナ側を同期(マウント)します(=コンテナに変更を自動反映) ※作業ファイルはローカルに残ります 削除タイミングは自分でフォルダを消すときになります。 ・名前付きボリューム DBのデータなどを残したいときに使います。 Docker内で保持されるので、一見するとどこに行ったかわからなくなりますが、Docker Desktop アプリや docker volume ls コマンドで確認できます。 削除タイミングは docker-compose down や docker system prune で ボリュームオプションを指定したタイミング です。 ※匿名ボリュームというのもありますが、基本的に名前付きがつかわれます。 ボリュームの実際の書き方は以下のdocker-compose.ymlのコメントを参考にしてください。 docker-compose.ymlを作成 ボリュームはしれっとたまっていくので定期的にお掃除する必要があります。 作業データがいらなくなったときに、以下どちらを使い用途に応じて削除するといいと思います。 1. 今いるディレクトリに対してコンテナ停止、削除、ネットワーク、イメージ、ボリューム、未定義のコンテナを削除する docker-compose down --rmi all --volumes --remove-orphans 2. ディレクトリ関係なく、起動していない、ボリューム、イメージ、コンテナ、ネットワークを削除(prune)する docker system prune --volumesまたはdocker volume prune 2.コンテナ再起動 docker-compose up -d 【おまけ】その他のコマンド 必要になったときに見てください。 基本は上記の内容で事足りると思います。 コンテナ停止 docker-compose stop コンテナ削除 docker-compose rm ※起動しているコンテナは削除できません コンテナ再起動 docker-compose restart 今あるイメージを確認 docker images ※docker compose ではなく docker のコマンド 対象のイメージを削除 docker rmi イメージ名 or イメージID ※docker compose ではなく docker のコマンド ※コンテナがあるイメージは削除できません ※強制削除もあるが今回はなし docker-compose.ymlで管理されているサービス1つを指定してコマンドを実行する docker-compose run サービス名 コマンド ※ビルド前でも実行可能なコマンド。一時的にコンテナ作成してコマンドを実行できる 例) docker-composeのvolumeでフレームワークのフォルダが事前に必要な場合に 先にフレームワークのインストールだけしておく際などに使える。 フォルダが先にないとエラーが出たりする この記事でLaravelをインストールするときに使ってます。 2.Laravelのインストールコマンドを実行 Docker コンテナの詳細情報確認 docker inspect コンテナ指定 ※docker compose ではなく docker のコマンド ※よくみるのは mount :どこのvolumeをマウントしてるか config:だれがもってるかとか、環境変数とか、Cmdとか network setting:コンテナのUPAddress(ホストからつなげるIP)の確認もできる ※IPは docker-compose ps のコンテナ一覧でみることが多いです イメージの履歴を確認 docker history イメージ名:タグ ※docker compose ではなく docker のコマンド ※他人が作ったイメージの更新履歴を知りたいときに使う Dockerコンテナのログを出力 docker logs コンテナ指定 ※docker compose ではなく docker のコマンド ※アクセスログ、不明な停止の原因を確認した時に使う ※リアルタイム監視でログをだすにはオプション -f を使います。 作業中をリアルタイムで追えるようになります Docker 全体のお掃除 docker system prune ※docker compose ではなく docker のコマンド ディレクトリ関係なく、イメージ、コンテナ、ネットワークを削除(prune)する ボリュームはデフォルトでは削除されないため、–volumes フラグを使う必要があります。 ※使用中のものは消されないのでstopしないといけない ※docker compose ではなく docker のコマンド ※オプション -a 既存のコンテナ~使われていないイメージすべてを削除する なぜかイメージが消えない時はこれ。全部消えるので注意 使用していない Docker オブジェクトの削除(prune) さいごに 正直自分のためのメモでもある!おまけは覚えなくていいし、困ったら見てください。 ちなみにdockerコマンドとdocker-composeコマンドは同じことができるコマンドがあったりするので、好きな方を使うでOKです。
【Docker】#8 出来てる環境の確認

2022-10-25

はじめに 今回業務で開発環境を作る際に共有できるノウハウが存在しないチームだったので、展開できる方法を検討し、Dockerが最適だと判断し個人で勉強しチームに展開まで行いました。 この通りやれば環境を再現してローカルで使える!というところまで、まとめたので時間がある限りブログに残そうかと思っています。 今回は第八回目です。 前回はphpMyAdmin表示確認を行いました。 これだけの環境を構築できるものを作成したと思うと、自分よくやった!ってなりますね。 しかもシェアしやすい!! 確認するものは多いですが、やることは楽なので、コマンドになれるついでに確認してみてください。 過去の手順は前回の記事を参考にしてみてください。 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認 【Docker】#6 LaravelのDB設定、確認 【Docker】#7 phpMyAdmin表示確認 作成する環境は以下の通りです。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 参考にした教材は以下です。 こちらがなかったらここまで実現できなかったと思います。 ありがとうございます。 駆け出しエンジニアのためのDocker入門 DockerでPHP(Laravel)+ nginx + MySQLのLEMP環境を構築する なお、私自身はインフラ専門家ではないので、インフラの各種機能の設定値は深堀していません。 本気で事業で使う場合はインフラの専門家の方にDockerファイルを作成+本番環境での運用を想定してもらい、それを作業者は起動、運用するだけ、という風にするのが理想だと思います。 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 現在の作業フォルダ 前回までに作成した以下のフォルダが作業ディレクトリになります。 参考までに記載しておきます。 nginx_mysql_laravel/    TOPフォルダ。名前はコンテナ起動前(環境構築前)なら自由に変更可能├── laravel    Laravelのソースコードが置かれるフォルダ=実作業フォルダ├── docker    dockerの設定ファイルや環境設定ファイルを置くフォルダ。│                 ここの配下のフォルダ名を変える場合、│                 Dockerfileとかdocker-compose.ymlでパスの修正が必要です│ ├── php    phpコンテナ(phpの環境構築設定ファイル)│ │ ├── DockerfilephpのDockerfile│ │ └── php.iniphp設定ファイル環境立ち上げるときにコンテナにコピーされます│ ├── mysql     MySQLコンテナ(MySQLの環境構築設定ファイル)│ │ ├── DockerfileMySQLのDockerfile│ │ └── my.confmysql 設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── nginx    nginxコンテナ(nginxの環境構築設定ファイル)│ │ ├── DockerfilenginxのDockerfile│ │ └── default.confnginx設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── phpmyadminphpMyAdminのデータが永続化される場所└── docker-compose.yml全コンテナの一括管理をするDockerの設定ファイル 1.コンテナを起動し環境を立ち上げる 各コマンドを実行してバージョンなどを確認していきます。 作業前に、Docker Desktopアプリを起動し、「docker-compose up -d」でコンテナを起動し環境を立ち上げておいてください。 分からない場合は前回の記事を参考にしてください。 docker-compose.ymlからコンテナを起動 2.phpのバージョン確認 今回はPHP 8.0.23になっていると思います。 以下を実行し、インストールしたバージョンが返ってきたらOKです。 docker-compose exec php php -v docker-compose exec php php -v について docker-compose execはDockerの仮想環境に対してコマンドを実行するコマンドです。 「docker-compose exec サービス名 実行したいコマンド 」 という風に記載して使います。 サービス名は docker-compese.yml に記載されているサービス名です。 3.Composerのバージョン確認 今回はComposer version 2.4.1になっていると思います。 以下を実行し、インストールしたバージョンが返ってきたらOKです。 docker-compose exec php composer -v 4.gitのバージョン確認 特にバージョン指定はしてないので、以下を実行し、バージョンが返ってきたらOKです。 この記事を作成しているときは git version 2.30.2 が返ってきてました。 docker-compose exec php git --version 5.インストール済の拡張機能の一覧 docker\php\Dockerfile の RUN で install しているパッケージ名が表示されます。 沢山表示されるので、完全には把握してませんが、install部分に記載されているパッケージ名があればいいかな。くらいで確認しています。 docker-compose exec php php -m 6.php.iniがコピー出来ているか確認 phpの設定ファイルがコピーできているか確認します。 ローカルからコピーされた、コンテナにあるphp.iniの内容が表示されればOKです。 1.phpのコンテナ内でbashを起動 phpのコンテナ内でコマンドを実行できるようにします。 docker-compose exec php bash 2.catコマンドでコンテナ内のphp.iniを表示 cat /usr/local/etc/php/php.ini 7.nginxのバージョン確認 今回はnginx/1.22.0になっていると思います。 以下を実行し、インストールしたバージョンが返ってきたらOKです。 docker-compose exec nginx nginx -v 8.mysqlのバージョンを確認 今回はmysql Ver 8.0.30になっていると思います。 以下を実行し、インストールしたバージョンが返ってきたらOKです。 docker compose exec mysql mysql -V 9.Laravelのバージョン確認 今回はLaravel Framework 6.20.44(PHP 8.0.23 に対する Laravel6 の最新)になっていると思います。 以下を実行し、インストールしたバージョンが返ってきたらOKです。 docker compose exec php php artisan -v 10.phpmyadminのバージョン確認 phpMyAdminのTOPページ(HOME)でバージョン情報を確認できます。 アクセス方法は「 【Docker】#7 phpMyAdmin表示確認 」を参考にしてください。 latestなので、最新が入るようになっています。 11.nodejsのバージョンを確認 docker\php\Dockerfile の apt-get installでインストールしてますが、バージョン指定していません。 安定版の最新が入ると思いますが、詳細は個々で確認をお願いします。 記事作成時点では 7.5.2 になっていました。 docker compose exec php node -v 12.npmのバージョンを確認 docker\php\Dockerfile の apt-get installでインストールしてますが、バージョン指定していません。 安定版の最新が入ると思いますが、詳細は個々で確認をお願いします。 記事作成時点では v12.22.12 になっていました。 docker compose exec php npm -v さいごに 本シリーズはこれで完了です。 本当にお疲れ様でした。 私自身もまだすべてを把握しているわけではないですが、特に問題なく使えています。 いきなりすべて把握するのは難しいので、分かる範囲で動かして検証しながら、知識を深めるようにしています。 後日、よく使うDockerコマンドの記事を書けたらいいなと思っています。 皆さまがうまくいくことを祈っています。 ローカル環境つくって、シェアするだけでもこんなに大変なので、本当エンジニアの労働環境、待遇が日本全体で見直されますように…!( ;∀;) エンジニア問わず技術職の待遇を見直さないと日本は終わると思います・・・ 特にアニメやゲーム!エンタメ大事です( ;∀;)
【Docker】#7 phpMyAdmin表示確認

2022-10-24

はじめに 今回業務で開発環境を作る際に共有できるノウハウが存在しないチームだったので、展開できる方法を検討し、Dockerが最適だと判断し個人で勉強しチームに展開まで行いました。 この通りやれば環境を再現してローカルで使える!というところまで、まとめたので時間がある限りブログに残そうかと思っています。 今回は第七回目です。 前回はLaravelのDB設定、動作確認を行いました。 過去の手順は前回の記事を参考にしてみてください。 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認 【Docker】#6 LaravelのDB設定、確認 作成する環境は以下の通りです。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 参考にした教材は以下です。 こちらがなかったらここまで実現できなかったと思います。 ありがとうございます。 駆け出しエンジニアのためのDocker入門 DockerでPHP(Laravel)+ nginx + MySQLのLEMP環境を構築する なお、私自身はインフラ専門家ではないので、インフラの各種機能の設定値は深堀していません。 本気で事業で使う場合はインフラの専門家の方にDockerファイルを作成+本番環境での運用を想定してもらい、それを作業者は起動、運用するだけ、という風にするのが理想だと思います。 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 現在の作業フォルダ 前回までに作成した以下のフォルダが作業ディレクトリになります。 参考までに記載しておきます。 nginx_mysql_laravel/    TOPフォルダ。名前はコンテナ起動前(環境構築前)なら自由に変更可能├── laravel    Laravelのソースコードが置かれるフォルダ=実作業フォルダ├── docker    dockerの設定ファイルや環境設定ファイルを置くフォルダ。│                 ここの配下のフォルダ名を変える場合、│                 Dockerfileとかdocker-compose.ymlでパスの修正が必要です│ ├── php    phpコンテナ(phpの環境構築設定ファイル)│ │ ├── DockerfilephpのDockerfile│ │ └── php.iniphp設定ファイル環境立ち上げるときにコンテナにコピーされます│ ├── mysql     MySQLコンテナ(MySQLの環境構築設定ファイル)│ │ ├── DockerfileMySQLのDockerfile│ │ └── my.confmysql 設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── nginx    nginxコンテナ(nginxの環境構築設定ファイル)│ │ ├── DockerfilenginxのDockerfile│ │ └── default.confnginx設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── phpmyadminphpMyAdminのデータが永続化される場所└── docker-compose.yml全コンテナの一括管理をするDockerの設定ファイル 1.phpMyAdmin表示確認 今回は以下のURLにアクセスし、phpMyAdminが表示できればOKです。 http://localhost:8080/ ログイン情報は以下の通りです。 ユーザ名:root パスワード:password この値は docker-compose.yml のサービス名 phpmyadminの PMA_USER 、PMA_PASSWORD に設定されてる値になります。 アクセスする前に… 前回同様 docker-compose up -d をしてコンテナを起動し環境を立ち上げておいてください。 分からない場合は前回の記事を参考にしてください。 docker-compose.ymlからコンテナを起動 「接続できません。設定が無効です。」みたいなエラーがでた場合 キャッシュの影響などでうまくいかないことがあります。 そういったときは以下のコマンドを実行する事で解決できます。 イメージの更新が反映しない時などもこちらで解決することが多いです。 1. Docker内で現在起動してない、イメージ、コンテナ、ネットワーク、キャッシュを削除(prune)する docker system prune 2. 再度環境を起動する docker-compose up -d なぜ8080? docker-compose.yml の サービス名 phpmyadmin の ports を 8080:80と記載しているからです。 コンテナの80番ポートをローカルの8080番ポートで表示するという意味になります。(ポートフォワーディング) ちなみに8080の部分は使われていないポート番号であれば、なんでも大丈夫です。 さいごに 今回はこれで完了です。 次回は8!いよいよ最後!「出来てる環境の確認」を行います。 本シリーズの全体の流れとしては、大きく以下のようになっています。 Docker Desktopインストール ローカルに作業フォルダを作成 Dockerの設定ファイルを作成 Laravelをコマンドでインストール dockerでコンテナ(機能)を起動+Laravel表示確認 LaravelのDB設定、確認 phpMyAdmin表示確認 出来てる環境の確認 自分でなんとか勉強して、実践してまとめてきましたが、なかなか難しいですよね。 わからないときも焦らずにやるのが大事だと思います。 無理せずに頑張っていきましょう
【Docker】#6 LaravelのDB設定、確認

2022-10-22

はじめに 今回業務で開発環境を作る際に共有できるノウハウが存在しないチームだったので、展開できる方法を検討し、Dockerが最適だと判断し個人で勉強しチームに展開まで行いました。 この通りやれば環境を再現してローカルで使える!というところまで、まとめたので時間がある限りブログに残そうかと思っています。 今回は第六回目です。 前回Laravelの表示確認ができたので、次はLaravelのDB設定、確認を行います。 過去の手順は前回の記事を参考にしてみてください。 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認 作成する環境は以下の通りです。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 参考にした教材は以下です。 こちらがなかったらここまで実現できなかったと思います。 ありがとうございます。 駆け出しエンジニアのためのDocker入門 DockerでPHP(Laravel)+ nginx + MySQLのLEMP環境を構築する なお、私自身はインフラ専門家ではないので、インフラの各種機能の設定値は深堀していません。 本気で事業で使う場合はインフラの専門家の方にDockerファイルを作成+本番環境での運用を想定してもらい、それを作業者は起動、運用するだけ、という風にするのが理想だと思います。 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 現在の作業フォルダ 前回までに作成した以下のフォルダが作業ディレクトリになります。 参考までに記載しておきます。 nginx_mysql_laravel/    TOPフォルダ。名前はコンテナ起動前(環境構築前)なら自由に変更可能├── laravel    Laravelのソースコードが置かれるフォルダ=実作業フォルダ├── docker    dockerの設定ファイルや環境設定ファイルを置くフォルダ。│                 ここの配下のフォルダ名を変える場合、│                 Dockerfileとかdocker-compose.ymlでパスの修正が必要です│ ├── php    phpコンテナ(phpの環境構築設定ファイル)│ │ ├── DockerfilephpのDockerfile│ │ └── php.iniphp設定ファイル環境立ち上げるときにコンテナにコピーされます│ ├── mysql     MySQLコンテナ(MySQLの環境構築設定ファイル)│ │ ├── DockerfileMySQLのDockerfile│ │ └── my.confmysql 設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── nginx    nginxコンテナ(nginxの環境構築設定ファイル)│ │ ├── DockerfilenginxのDockerfile│ │ └── default.confnginx設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── phpmyadminphpMyAdminのデータが永続化される場所└── docker-compose.yml全コンテナの一括管理をするDockerの設定ファイル 1.Laravelの設定ファイルでMySQLの設定値を変更する LaravelのTOPにある「.env」ファイルを開き以下の値を各変数に設定してください 念のため例として1を書くと「DB_HOST=mysql」という風になります。 1.DB_HOST mysql ※docker-compese.ymlのDBのサービス名。今回はmysqlになります。 ※dockerで立ち上げてるのでdocker-compese.ymlのDBのサービス名が自動でコンテナの内部IPに変換されてつながる仕組みです 2.DB_DATABASE database ※docker-compese.ymlのMYSQL_DATABASEで設定した値です。 3.DB_USERNAME user ※docker-compese.ymlのMYSQL_USERで設定した値です 4.DB_PASSWORD password ※docker-compese.ymlのMYSQL_PASSWORDで設定した値です。 2.LaravelでDBに繋がるか確認 Dockerのコマンドでコンテナの中に入り、その中でLaravelのコマンド実行し、DBが動いているか確認します。 1.コンテナ内のLaravelにコマンドではいる docker exec -it php bash ※bashを起動します ※ -it はインタラクティブモード(対話モード)で動かすオプションです 2.php artisan migrateが動くか確認 php artisan migrateはDB操作のLaravelのコマンドです。 なので、これでエラーが出なければOKということになります。 1.テーブル生成 php artisan migrate 2. テーブル削除 php artisan migrate:rollback さいごに 今回はこれで完了です。 次回は7「phpMyAdmin表示確認」を行います。 全体の流れとしては、大きく以下のようになっています。 Docker Desktopインストール ローカルに作業フォルダを作成 Dockerの設定ファイルを作成 Laravelをコマンドでインストール dockerでコンテナ(機能)を起動+Laravel表示確認 LaravelのDB設定、確認 phpMyAdmin表示確認 出来てる環境の確認 今回はここでおわりです。 ようやく終わりが近づいてきましたね。 作ってしまうときだけの手順なので、ぜひ最後まで頑張りましょう! 一回作ってしまえば、運用が簡単にできます!
【Docker】#5 dockerでコンテナ(機能)を起動+Laravel表示確認

2022-10-20

はじめに 今回業務で開発環境を作る際に共有できるノウハウが存在しないチームだったので、展開できる方法を検討し、Dockerが最適だと判断し個人で勉強しチームに展開まで行いました。 この通りやれば環境を再現してローカルで使える!というところまで、まとめたので時間がある限りブログに残そうかと思っています。 今回は第五回目です。 dockerでコンテナ(機能)を起動+Laravelの表示確認します。 Dockerfileや各種設定ファイル、そもそもDocker、Laravelのインストールが終わってない方は前回の記事を参考にしてみてください。 [【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール](../ 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 【Docker】#4 Laravelをコマンドでインストール 作成する環境は以下の通りです。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 参考にした教材は以下です。 こちらがなかったらここまで実現できなかったと思います。 ありがとうございます。 駆け出しエンジニアのためのDocker入門 DockerでPHP(Laravel)+ nginx + MySQLのLEMP環境を構築する なお、私自身はインフラ専門家ではないので、インフラの各種機能の設定値は深堀していません。 本気で事業で使う場合はインフラの専門家の方にDockerファイルを作成+本番環境での運用を想定してもらい、それを作業者は起動、運用するだけ、という風にするのが理想だと思います。 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 現在の作業フォルダ 前回までに作成した以下のフォルダが作業ディレクトリになります。 参考までに記載しておきます。 nginx_mysql_laravel/    TOPフォルダ。名前はコンテナ起動前(環境構築前)なら自由に変更可能├── laravel    Laravelのソースコードが置かれるフォルダ=実作業フォルダ├── docker    dockerの設定ファイルや環境設定ファイルを置くフォルダ。│                 ここの配下のフォルダ名を変える場合、│                 Dockerfileとかdocker-compose.ymlでパスの修正が必要です│ ├── php    phpコンテナ(phpの環境構築設定ファイル)│ │ ├── DockerfilephpのDockerfile│ │ └── php.iniphp設定ファイル環境立ち上げるときにコンテナにコピーされます│ ├── mysql     MySQLコンテナ(MySQLの環境構築設定ファイル)│ │ ├── DockerfileMySQLのDockerfile│ │ └── my.confmysql 設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── nginx    nginxコンテナ(nginxの環境構築設定ファイル)│ │ ├── DockerfilenginxのDockerfile│ │ └── default.confnginx設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── phpmyadminphpMyAdminのデータが永続化される場所└── docker-compose.yml全コンテナの一括管理をするDockerの設定ファイル 1.docker-compose.ymlからコンテナを起動 1.Docker Desktop アプリを起動 Dockerを使うには、Docker Desktop アプリを起動する必要があります。 アプリを起動してください。 Docker Desktop アプリってなんだっけ?という方は最初の記事を見てみてください。 最初にインストールしたアプリです。 Docker Desktopインストール 2.作業ディレクトリに移動 docker-compose.ymlがあるフォルダにコマンドで移動します。 cd ローカルフォルダのパス 3.Dockerコンテナを起動 Dockerのコンテナを起動し環境起動します。 ※初回はキャッシュがないので時間かかります。 ※ -dはコマンドプロンプトが占有されないように、バックグラウンドで実行するためのオプションです。 docker-compose up -d ■イメージ名の命名規則について 今は分からなくてもよいですが以下のようになっています。 {プロジェクトのフォルダ名}_{サービス名}となり、imageよりbuildのサービス名が優先される イメージ名って何になるんだろ?って思ったときに参考にしてください。 Docker DesktopのImageの画面でも確認ができます。 2.Laravelの表示確認 docker-compese.ymlのportsで指定したポート番号でアクセスします。 今回はnginxのportsで8081:80と記載してるので以下のURLになります。 http://localhost:8081 ■Laravelでパーミッションエラーが出る場合は以下を実行してください。 ・docker-compose exec php chmod -R 0777 bootstrap ・docker-compose exec php chmod -R 0777 storage ※dockerのコンテナ(php)にはいり、パーミッションを変更しています。phpはdocker-compese.yml記載のサービス名のことです。 さいごに 今回はこれで完了です。 次回は6「LaravelのDB設定、確認」を行います。 全体の流れとしては、大きく以下のようになっています。 Docker Desktopインストール ローカルに作業フォルダを作成 Dockerの設定ファイルを作成 Laravelをコマンドでインストール dockerでコンテナ(機能)を起動+Laravel表示確認 LaravelのDB設定、確認 phpMyAdmin表示確認 出来てる環境の確認 今回はここでおわりです。 Dockerはコンテナ?イメージ?Dockerfile?docker-compose.yml?などの役割が頭に入ってくると理解しやすくなりますが、 そこも慣れなので、焦らずにやっていきましょう。
【Docker】#4 Laravelをコマンドでインストール

2022-10-19

はじめに 今回業務で開発環境を作る際に共有できるノウハウが存在しないチームだったので、展開できる方法を検討し、Dockerが最適だと判断し個人で勉強しチームに展開まで行いました。 この通りやれば環境を再現してローカルで使える!というところまで、まとめたので時間がある限りブログに残そうかと思っています。 今回は第四回目です。 Laravel 6 をコマンドでインストールします。 Dockerfileや各種設定ファイル、そもそもDockerのインストールが終わってない方は前回の記事を参考にしてみてください。 【Docker】#1 はじめに+Dockerとは+Docker Desktopインストール 【Docker】#2 ローカル(ホスト)に作業フォルダを作成 【Docker】#3 Dockerfile+docker-compose.yml+各設定ファイルの設置 作成する環境は以下の通りです。 windows pc php 8.0.23 composer 2.4.1 nginx 1.22.0 MySQL 8.0.30 Laravel 6.20.44 phpMyAdmin最新 参考にした教材は以下です。 こちらがなかったらここまで実現できなかったと思います。 ありがとうございます。 駆け出しエンジニアのためのDocker入門 DockerでPHP(Laravel)+ nginx + MySQLのLEMP環境を構築する なお、私自身はインフラ専門家ではないので、インフラの各種機能の設定値は深堀していません。 本気で事業で使う場合はインフラの専門家の方にDockerファイルを作成+本番環境での運用を想定してもらい、それを作業者は起動、運用するだけ、という風にするのが理想だと思います。 用語 先によく出てくる用語だけ記載しておきます。 作業中にわからなくなったら見てください。 ホストOS 作業側のパソコン。ローカルともいう Dockerfile イメージをビルドで作るためのDockerの設定ファイル イメージ コンテナを作成するためにDockerfileからビルドで作成されたもの。 Dockerhubで配布されている公式のイメージもある。 ビルド Dockerfileからイメージを作成する事 コンテナ イメージから作成された各機能のこと。 サービスとも呼ばれる。 このコンテナの集まりで環境が構築される docker-compose 複数のコンテナを一気に作成したりできる一元管理機能。 Dockerを使う場合実質必須になります。 docker-compose.yml 複数のコンテナを一気に作成、起動したりできるdocker-composeの一元管理ファイル。 docker-composeをインストールしてdocker-compose.ymlを作成してdocker composeコマンドで実行して利用します。 現在の作業フォルダ 前回までに作成した以下のフォルダが作業ディレクトリになります。 参考までに記載しておきます。 nginx_mysql_laravel/    TOPフォルダ。名前はコンテナ起動前(環境構築前)なら自由に変更可能├── laravel    Laravelのソースコードが置かれるフォルダ=実作業フォルダ├── docker    dockerの設定ファイルや環境設定ファイルを置くフォルダ。│                 ここの配下のフォルダ名を変える場合、│                 Dockerfileとかdocker-compose.ymlでパスの修正が必要です│ ├── php    phpコンテナ(phpの環境構築設定ファイル)│ │ ├── DockerfilephpのDockerfile│ │ └── php.iniphp設定ファイル環境立ち上げるときにコンテナにコピーされます│ ├── mysql     MySQLコンテナ(MySQLの環境構築設定ファイル)│ │ ├── DockerfileMySQLのDockerfile│ │ └── my.confmysql 設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── nginx    nginxコンテナ(nginxの環境構築設定ファイル)│ │ ├── DockerfilenginxのDockerfile│ │ └── default.confnginx設定ファイル環境立ち上げるときにコンテナにコピーされます│ └── phpmyadminphpMyAdminのデータが永続化される場所└── docker-compose.yml全コンテナの一括管理をするDockerの設定ファイル Laravelをコマンドでインストール 1.作業ディレクトリに移動 docker-compose.ymlがあるフォルダにコマンドで移動します。 cd ローカルフォルダのパス 2.Laravelのインストールコマンドを実行 LaravelのComposerのcreate-projectコマンドを使いインストールします。 なお、dockerの機能を使って一時的にcomposerが使える状態にしてるので、docker-compose runというコマンドも使っています。 ※そのため先にDockerの設定ファイルは作っておく必要があります。 ちょっと時間かかるのでしばらく待ち、Application key set successfully.が表示されたらインストール完了です。 docker-compose run php composer create-project --prefer-dist laravel/laravel . "6.*" 本当はDockerfileやdocker-compese.ymlで一括で入れたい気もするのですが、ソースがコンテナにしかないとかlocalhostからアクセスできないなどの事象がおこるので、別に入れるようにしています。 インストール先はdocker-compose.ymlのvolumesで設定されたパスになります。 今回はサービス名phpのvolumesの./laravel/:/appになります。 よくわからない時はdocker-compose.ymlを見てみてください。 ※ローカル:./laravel 配下 ※コンテナ:/app 配下 流れとしてはコンテナのapp配下にインストールされたLaravelのファイルがローカルの./laravel 配下にバインド(同期みたいなこと)されるということになります。 ■エラーについて 1.Project directory “フォルダ名” is not empty. Laravelインストール先のフォルダ空じゃないのときに出るエラーです。 2.failed to solve: rpc error: code = Unknown desc Dockerfileなどのインストールにかかわるパスの指定が間違っていないかを確認してください。 さいごに 今回はこれで完了です。 次回は5「dockerでコンテナ(機能)を起動+Laravel表示確認」を行います。 全体の流れとしては、大きく以下のようになっています。 Docker Desktopインストール ローカルに作業フォルダを作成 Dockerの設定ファイルを作成 Laravelをコマンドでインストール dockerでコンテナ(機能)を起動+Laravel表示確認 LaravelのDB設定、確認 phpMyAdmin表示確認 出来てる環境の確認 今回はここでおわりです。 Dockerはコンテナ?イメージ?Dockerfile?docker-compose.yml?などの役割が頭に入ってくると理解しやすくなりますが、 そこも慣れなので、焦らずにやっていきましょう。
profile_icon
taka
プログラマー
いつでも転職希望の業務経験7年目(2023時点)のエンジニアです。 仕事の合間にすこしずつ転職活動はしていますが、条件が合う場合ぜひTwitterなどでご連絡頂けると嬉しいです。 希望条件は基本的に残業は1日x1h程度。収入は一旦現状維持。 ある程度で構わないので、保守運用が管理されていて、精神的に安心して働ける環境が良いです。 経験言語はHTML、CSS、javascript、PHP、MySQL、Docker、Vuejs、Laravel このブログは完全に自作で静的ジェネレータで作りました。 この範囲で言えば React.js Gatsby.js GraphQLも経験があります。 最近はAIがどう社会に受け入れられ、日常になっていくのかの行く末が気になっています。 今までの人生で一番変化を感じて不思議な感覚です。