3 way merge editor とは

3 way merge editor は次の 3 つの画面を使って従来の方法よりも効率的に競合の解決を行うエディターです:

• 現在のブランチの更新内容と競合部分が表示される画面
• 現在のブランチにマージするブランチの更新内容と競合部分が表示される画面
• 競合の解決を行う画面

3 way merge editor と inline editor の比較

従来の競合の解決方法で使っているエディターは inline editor と呼ばれています。

3 way merge editor

• 競合の解決を支援するための機能が充実しているので、慣れれば効率的に競合の解決を行うことができます。
  • 互いに同じ行を更新した場合でも、
    変更が単語レベルで重なっていない限り、自動的に両方の更新を統合して解決できます。
• エディター自体の機能を把握する必要があります。
  • この記事を執筆時点 (November 2022 (version 1.74)) では、
    Visual Studio Code 公式の解説はありません。
  • inline editor よりも新しく導入された機能なので、不具合が発生する可能性が inline editor よりも高く、
    競合の解決が続けられない場合は inline editor に切り替えて競合を解決する必要があります。

inline editor

• エディター自体の機能がシンプルで憶えるのが楽です。
• 競合の解決のための機能が充実していないので、競合を解決するのが面倒です。
  • 1 文字でも互いに同じ行を更新していると、自力で両方の更新を統合して解決する必要があります。
    (差分を一望する別タブを開くことはできます)

競合の解決のための画面を開こう

ここからは、実際に 3 way merge editor を使って競合の解決を行っていきます。

手順

1.
Git のマージを行い、競合が発生している状態で、Visual Studio Code を開きます。

2.
画面左 [Activity Bar] の [Source Control] のアイコンをクリックすると、
[Side Bar] の [MERGE CHANGES] という欄に競合があるファイルが表示されるので、
クリックします。
すると、inline editor が表示されるので、
下部に表示される [Resolve in Merge Editor] ボタンをクリックすると、3 way merge editor が表示されます。

競合の解決作業のすすめかた

改めて、画面の役割を説明します。
まず、画面の上半分 (Incoming と Current) は確認用の表示で、編集できません。
そして、画面の下半分 (Result) は編集用の画面になっています。

画面上半分にそれぞれのブランチの編集内容が表示されるので、
画面下半分の編集用画面を、「競合を解決した状態」に編集していきます。
画面下半分は、ほぼ通常時と同様に操作でき、
すべての言語機能 (診断、ブレークポイント、テストを含む) を使用できます。

編集が競合している行は、画面の上半分では文字列がハイライトして表示され、
その中でもう一方と異なる部分は特に明るく表示されています。
マージする上で参考になるかもしれません。

各画面右端のスクロールバーに
ファイル全体の中の競合が発生している箇所が表示されます。

この表示は、後述する、競合を解決するための操作をしていくと消えていきます。
すべての競合発生箇所を示す表示をなくすことを目標に、競合を解決していきます。

すべての競合の解決が終わったら、画面下部 [Complete Merge] ボタンをクリックすると
行った編集をファイルに保存して、Git 上で更新内容をステージします。
すべての競合が解決されていない状態で [Complete Merge] ボタンをクリックすると
警告ダイアログが表示されます。

競合を解決してみよう

競合を解決する上で最も基本的な考え方は、
「どちらか一方が正しいわけではない」
ということです。

双方にそれぞれの編集意図があるので、
双方の編集意図を汲んだマージを行う必要があります。
相手の編集意図がコミットメッセージや編集内容から読み取れなければ
相手に連絡をとって編集意図を確認してマージしましょう。

この例では、競合した行が更新された編集履歴である
「営業時間の変更」と「キャッチコピーの追加」の
両方の意図を汲んだマージを行う必要があります。

手順

1. 競合部分を解決します

画面上部の競合部分で、Incoming Current どちら側でもよいので、[Accept Combination] をクリックします。

すると、画面下部の競合部分が変更され、競合発生箇所を示す表示が灰色に変化します。

両方の編集内容が反映されていることを確認します:

未知との出会いを応援する 勉強会カフェ 「First Knowledge」 オープン！ 営業時間：平日 07:00〜13:00, 18:00〜23:00 / 土日祝 07:30〜21:00

2. ファイルを保存してステージします

画面下部 [Complete Merge] ボタンをクリックします。

すると、行った編集がファイルに保存され、
画面左 [Activity Bar] の [Source Control] を確認すると更新内容がステージされています。

3. マージをコミットします

画面右側 [Side Bar] (表示内容が [Source Control] の状態) で [✔Commit] ボタンをクリックしてコミットします。

これでマージが完了しました。

結果を確認してみよう

HTML ファイルをブラウザで表示すると次のようになっています。

ログは次のようになっています:

これでプッシュできるようになりました。
成功するはずです。

以上でプロジェクトの編集履歴の競合の解消が完了しました。

競合を解決するときの選択肢

この記事を執筆している 2023-01-02 時点では、
3 way merge editor の競合部分の機能を使って次のことができます:

3 way merge editor を使って競合を解決するときは、
できる限りエディターの機能を使って解決を行うようにすると楽です。

最初から 3 way merge editor を開きたいとき

競合の解決のために 3 way merge editor を開くとき、
競合しているファイルをクリックして inline editor を開いてから、3 way merge editor を開きました。

これを、最初から 3 way merge editor を開くようにするには、Visual Studio Code の設定を変更します。

Visual Studio Code のメニューバーで
[File (ファイル)] → [Preference (ユーザー設定)] →[settings (設定)] をクリック。
(ショートカット: [Ctrl + ,])

すると設定画面が開きます。

設定画面上部の [Serch Settings (設定の検索)] に “git.mergeEditor” と入力し、
表示されたチェックボックス: [Git: MergeEditor] にチェックを入れます。

すると、次回から画面左 [Activity Bar] の [Source Control] で競合しているファイルをクリックすると、
最初から 3 way merge editor が開きます。

この設定のまま inline editor を開きたいとき

競合しているファイルを右クリック → [Open File (ファイルを開く)] で開けます。

3 way merge editor が初期状態で有効でない経緯

3 way merge editor は July 2022 (version 1.70) のときに初期状態で有効になりましたが、
ユーザーからのフィードバックを確認したところ従来の方法の方が好評だったため、
September 2022 (version 1.72) の段階で再度無効となりました。

参考:
Change default git conflict experience to be the inline editor · Issue #160806 · microsoft/vscode

ただし、当時は 3 way merge editor の UI が今ほど洗練されておらず、不具合も多い状態でした。

The post 【Git】Visual Studio Code で競合を解決しよう (3 way merge editor) first appeared on ultra code.

この記事では、
WSL 2 を利用したコンテナー内開発において
権限をどう設定するべきかについて解説します。

WSL 2 を利用したコンテナー内開発での権限の問題

初期状態では、
WSL 2 のファイルシステムを開発用コンテナーに bind mount すると、
多くの場合、コンテナー内で作成したファイルが
ホストの WSL 2 や Windows 側で操作できなくなってしまいます。

これは、権限が次のようになりやすいためです:

コンテナー側のユーザー権限について知っておくべきこと

• コンテナー内は root 権限を前提に設計されていることが多いです
  • そのため、Visual Studio Code のコンテナー内開発で作ったファイルは所有者が root になります
• 公開されているイメージには、
  コンテナー内にユーザーや権限に関する意図的な設計がある場合もあります
  • 例
    • Nginx 公式イメージにおける www-data ユーザー
    • MySQL 公式イメージにおける mysql ユーザー
• コンテナーを実行するときに実行ユーザーを指定する方法もあります
  • Compose ファイルの “user” キーなど
  • しかし、あまり実用的ではありません
    • 今度はコンテナーが設計通りに動作しない問題を解決しなくてはならなくなります
      • コンテナー内が既定のユーザー権限を前提にした設計になっていることが多いため

ホスト側のユーザー権限について知っておくべきこと

• ホスト側の WSL 2 Linux ディストリビューションは
  初期設定では、UID 1000 のユーザーとして操作することになります
  • UID 1000 は Linux ディストリビューションの初期設定時に作成されたユーザーです
• Windows のエクスプローラーからの操作も、この UID 1000 のユーザーの扱いとなります
  • Windows 側からコピーや移動して持ってきたファイルも
    UID 1000 のユーザーが所有者となります

Docker 公式のベストプラクティス

Docker の公式ドキュメントでは、
権限を気にする必要があったり、ファイル・フォルダーを追加更新削除する場合、
bind mount ではなく volume を使うことを推奨しています。

ただし、同時に各所で
「bind mount は開発環境に適しています」
とも記載されています。

One case where it is appropriate to use bind mounts is during development

Where and how to persist application data | Docker development best practices | Docker Documentation

参考:

• Manage data in Docker | Docker Documentation
• Where and how to persist application data | Docker development best practices | Docker Documentation

volume を使う場合、インポートやエクスポートの処理を自作することになり、
開発の開始と終了時にこれらの処理を実行する必要があります。

参考: Use volumes | Docker Documentation

Visual Studio Code のベストプラクティス

Visual Studio Code の公式ドキュメントでは、
ユーザーと権限に関するいくつかの対策が記載されています。

中でも、新たに root 以外の実行ユーザーを作ることは
開発環境だけでなく本番環境にとっても
セキュリティー的に望ましいと解説されています。

参考: Adding a non-root user to your dev container | dvanced Container Configuration

Running your application as a non-root user is recommended
even in production (since it is more secure),
so this is a good idea even if you’re reusing an existing Dockerfile.

Creating a non-root user | Advanced Container Configuration

ただし、次のような課題もあります:

• 開発者同士でホスト側の UID を合わせる必要があります
• コンテナー内にユーザー ID を作成してから利用開始する必要があるため
  公開されている Docker イメージを、そのまますぐ利用することができなくなります
• 公開されている Docker イメージのユーザー権限の設計を変えることになります

WSL 2 を隔離してデフォルトユーザーを root にする

WSL 2 のデフォルトユーザーを root にすると、権限の煩雑さから解放されます。
セキュリティー的にはあまり望ましくありませんが、
次のことを考慮すると、Docker を利用する上においては、リスクは変わってないと言えます。

• WSL 2 にする前の Docker Desktop も権限的にほぼ同様の状態であること
• いずれにしてもコンテナーが root で動作していること

ただ、WSL 2 上で操作を誤ると、
権限が強いために重要なファイルを削除してしまう、といったことも考えられます。

参考: Windows 10の「WSL」の自動マウントやfstabによるマウント処理をwsl.confファイルで制御する：Tech TIPS – ＠IT

これを防ぐため、WSL 2 側からの Windows へのアクセスは
読み取り専用にしておくことをお奨めします。

どうやって WSL 2 のデフォルトユーザーを root にするの？

既存の Linux ディストリビューションの設定を変更する場合

1. root のパスワードを設定します

対象の Linux ディストリビューションのターミナルを起動し、
次のように入力します:

# ユーザーを root に切り替え
y-shinoda $ sudo su -
# パスワードを設定
root $ passwd

参考: Set up WSL (Ubuntu) on Windows 10 Pro | 東京大学 佐々木淳 研究室 沿岸環境学 海岸工学 環境水工学 水環境学

2. デフォルトユーザーを root に変更します

Windows PowerShell を管理者権限で起動し、
次のコマンドを実行します:

<Linux ディストリビューション名> config --default-user root

例: Ubuntu の場合:

ubuntu config --default-user root

参考: ubuntu 14.04 – How to sign into “root” account by default on Windows Subsystem for Linux Bash terminal – Super User

新規 Linux ディストリビューションを設定する場合

少なくとも、Ubuntu は Windows へのインストール直後に
次の手順でデフォルトユーザーを root にできます。

1.
Microsoft Store から Windows に Ubuntu をインストールし終わったら、
Ubuntu を起動し、ターミナル上でインストール処理の完了を待ちます。

2.
インストール処理が完了し、”Enter new UNIX username:” と表示されたら
一旦、ターミナルを閉じます。

3.
再度 Ubuntu を起動すると、デフォルトユーザーが root になっています。

どうやって WSL 2 側から Windows へのアクセスを読み取り専用にするの？

WSL 2 の Linux ファイルシステム上の /etc/wsl.conf に
次の内容のファイルを作成します:

[automount]
options="metadata,umask=22,fmask=11,ro"

そして Windows を再起動します。

すると、Linux ファイルシステムで開いたシェルからは、
権限の表示は書き込み可能の表示でも、
実際に書き込みを行うと読み込み専用のファイルシステムであるエラーが発生します:

$ ls -la /mnt/c/Users/public/workspace
total 0
drwxr-xr-x 1 root root 4096 Oct 14 11:44 .
drwxr-xr-x 1 root root 4096 Oct 14 11:44 ..
-rwxr--r-- 1 root root    0 Oct 14 11:44 test1.txt
$ touch /mnt/c/Users/public/workspace/test2.txt
touch: cannot touch '/mnt/c/Users/public/workspace/test2.txt': Read-only file system
$ rm -rf /mnt/c/Users/public/workspace
rm: cannot remove '/mnt/c/Users/public/workspace/test1.txt': Read-only file system

参考:

• Windows 10の「WSL」の自動マウントやfstabによるマウント処理をwsl.confファイルで制御する：Tech TIPS – ＠IT
• 【 mount 】コマンド――ファイルシステムをマウントする：Linux基本コマンドTips（183） – ＠IT
• ＠IT：ファイルシステムを書き込み禁止でマウントし直すには

ちなみに、読み取り専用にするのではなく、マウント自体をやめてみたところ、
Visual Studio Code の WSL リモート開発とコンテナー内開発が動かなくなりました。

Visual Studio Code
Docker returned an error. Make sure the Docker daemon is running.
[OK]

The post 【Docker】 WSL 2 を利用したコンテナー内開発で権限をどう設定するべきか first appeared on ultra code.

中でも、警告表示のための拡張機能を使うことは
特定の記法やプログラミング言語の習得速度に大きく貢献します。

この記事では、まず、英文の作成を例に
警告表示のための拡張機能が習得速度に与える影響を解説し、
その後、特定の記法やプログラミング言語で
警告表示を行うための拡張機能を紹介します。

リモートで開発するための Visual Studio Code 講座 目次にもどる

英文を書いてみよう

まず、新しいフォルダーを作成し、その中で Visual Studio Code を開きます。
フォルダー名は何でも構いません。
この例では “test-vscode-extension” として進めます。

次に、開いた Visual Studio Code で新しいテキストファイルを作成します。
サイドバーの [EXPLORER] にマウスのカーソルを移動すると、
フォルダー名の右側にアイコンが表示されるので、
次のアイコンをクリックします:

すると、ファイル名の入力欄が表示されるので
末尾が “.txt” で終わるファイル名を入力します。
この例では、”test.txt” として進めます。

すると、作成したファイルがエディターで開くので、
次のテキストを入力します:

Visual Studio Code extentions let you add languages, debuggers, and tools
to your installation to support your development workflow.

上記の英文にはスペルミスが含まれています。
スペルミスに気付かずに文書を書き続けて
どこかへ提出したり何かに印刷してしまったりすると
後から修正するのは面倒になっていき、修正するコストもかかります。

そこで、警告表示を行うための拡張機能をインストールしてみましょう。

拡張機能 “Code Spell Checker” をインストールしてみよう

Visual Studio Code 左側のアクティビティバーの拡張機能アイコンクリックし
拡張機能ビューを表示します。

[拡張機能] ビューの上部にある [検索] ボックスに
「Spell」と入力し、
表示された一覧の中から “Code Spell Checker” の [Install] ボタンをクリックします。

インストールが完了すると、
[Install] ボタンが歯車のアイコンの [Manage] ボタンに変わります。

スペルミスを確認してみよう

インストールが完了したら、再度英文をエディターを開いてみましょう。
スペルミスの部分に波線が表示され、
カーソルをあわせると警告メッセージと電球のアイコンが表示されます。

スペルミスを修正したりすることもできます。
電球アイコンをクリックするか、
キーボードからショートカットで Ctrl + . を入力します。
すると、修正候補の文字列などが表示されます。

修正候補の文字列を選択すると、スペルミスが修正され波線が消えます。

ここでは解説しませんが、スペルミスとして検出された単語を辞書に登録して
以降はスペルミスとして検出しないことも可能です。

警告が表示されると嬉しいこと

ここまでの内容から、
エディターに警告が表示されることは次の点で有利です:

• 問題が発生する前に予防的に修正できます
• 自分で気付かなかったり知らなかった情報に遭遇でき、学びを得る機会が増えます

前者は一般的に言われていますが、
実は一般的に言われていない後者が非常に重要です。

このような警告を学びの機会と捉えるか面倒と捉えるかで
1年後の知識水準に大きな差が生まれることになります。

この警告表示の重要性は
プログラミング言語や何かを表現するための記法においてもほぼ同様です。

特定の記法やプログラミング言語で警告表示を行うための拡張機能

ほんの一例ですが、たとえば次のような警告表示のためのの拡張機能があります:

拡張機能は常に新しいものが公開されたり
アップデートで強化されたりしていますので
ここに掲載したものに限らず常に色々探して試してみることをお奨めします。

拡張機能の管理に関する必要最低限の操作は次の記事で解説しています:

参考: どうやって拡張機能を管理するの？

これらの拡張機能の多くは、
「リンター」と呼ばれるツールを
Visual Studio Code から利用できるようにしたものです。

リンターってなに？

リンター (Linter) とは、次のような問題を検出して警告するツールです:

• エラーにつながる可能性のある微妙なプログラミング
• 型破りなコーディング手法

具体的には、例えば次のような問題を検出して警告します:

• 標準的でない文体
• 括弧の欠落
• 初期化されていない変数の使用
• 未定義の変数の使用
• 未定義の関数の呼び出し
• 組み込みの型や関数の再定義の試行
• 他

状況により警告表示が妥当でない場合のために、
基本的には警告を抑制する方法も提供されています。

リンターを使うことで、次のような効果が期待できます:

• エラーが発生する前に予防的に修正できます
• コードをより読みやすく保守しやすくするための標準的な文体を保つことができます
• 自分で気付かなかったり知らなかった情報に遭遇でき、学びを得る機会が増えます

リモートで開発するための Visual Studio Code 講座 目次にもどる

The post 【Visual Studio Code】警告表示のための拡張機能を使って学びの速度を上げよう first appeared on ultra code.

この記事では、拡張機能を検索、インストール、および管理する方法について
最低限知っておくべきポイントに絞って説明します。

参考: Managing Extensions in Visual Studio Code

リモートで開発するための Visual Studio Code 講座 目次にもどる

拡張機能の管理に関する操作

拡張機能ビューから
拡張機能をインストール、無効化、更新、およびアンインストールできます。
Visual Studio Code 左側のアクティビティバーの拡張機能アイコンクリックし
拡張機能ビューを表示します。

初期設定では、拡張機能ビューには、次のビューが表示されます。

• 現在インストールしている拡張機能
• 推奨されているすべての拡張機能

Visual Studio Code をインストールしたタイミングによっては、
初期設定での上記のビューではない可能性もあります。

いずれの場合も、拡張機能ビュー上部の […] をクリック → [Views] で
次の中から選択することができます

拡張機能の詳細の確認

拡張機能の項目をクリックすると、
拡張機能の詳細ページが表示され、詳細を確認できます。

検索

[拡張機能] ビューの上部にある [検索] ボックスに
探している拡張機能、ツール、またはプログラミング言語の名前などを入力します。
たとえば、「markdown」と入力すると、
Markdown に関する拡張機能のリストが表示されます。

ここでは詳しく解説しませんが、
結果をフィルタリングしたり並べ替えることもできます。

参考:

• Extensions view filters | Managing Extensions in Visual Studio Code
• Sorting | Managing Extensions in Visual Studio Code

インストール

拡張機能をインストールするには、[Install] ボタンをクリックします。

インストールが完了すると、
[Install] ボタンが歯車のアイコンの [Manage] ボタンに変わります。

アンインストール

拡張機能をアンインストールするには、
拡張機能の項目の右側にある歯車のボタンをクリックし、
ドロップダウンメニューから [Uninstall] を選択します。

これにより、拡張機能がアンインストールされ、
Visual Studio Code を再読み込みするように求められます。

拡張機能は自動更新されます

Visual Studio Code は拡張機能の更新をチェックし、
自動的に更新をインストールします。

自動更新を無効にすることもできます。

参考:

• Extension auto-update | Managing Extensions in Visual Studio Code
• Update an extension manually | Managing Extensions in Visual Studio Code

リモートで開発するための Visual Studio Code 講座 目次にもどる

The post 【Visual Studio Code】どうやって拡張機能を管理するの？ first appeared on ultra code.

この講座ではPC に直接プログラムの動作環境をセットアップする作業を省くために
Visual Studio Code の必要最低限の基礎知識を習得します。

PC に直接プログラムの動作環境をセットアップすることは非効率的です。

• うまく動かないときに相談するのが大変
• 最終的に動作させたい実行環境で意図した通り動かない
• アプリケーション / ライブラリーが管理しきれなくなる

参考: プログラム開発の準備には仮想環境を使おう

Visual Studio Code を使うと、これらの課題から解放されます。

Visual Studio Code を使うと、どんなことが便利なの？

※ 既に Visual Studio Code を習得するつもりの人は読み飛ばして構いません

• ファイルやプログラムの編集には Visual Studio Code を使おう

Visual Studio Code を使う習慣をつけよう

• どうやって Visual Studio Code を日本語化したらいいの？
• まず Visual Studio Code でファイルを編集してみよう
• 【Visual Studio Code】警告表示のための拡張機能を使って学びの速度を上げよう

PC に言語をインストールせずにプログラム開発しよう

この時点で Docker の基礎知識が必要になります
Docker について必要最小限の知識を次の講座で習得できます:

実用から入る Docker 講座 目次

• PC に言語をインストールせずにプログラム開発しよう

もっと Visual Studio Code を活用したい人のために

本編は以上で完了しました。
ここから先は、より Visual Studio Code を活用するための解説です。

• 【Git】Visual Studio Code で競合を解決しよう
• Visual Studio Code Live Share 拡張機能まとめ

The post リモートで開発するための Visual Studio Code 講座 目次 first appeared on ultra code.

この Docker 講座は、最初は Docker の細かい解説はできる限り省略して
便利な ブラウザアプリのローカル起動やプログラム開発など、
Docker を活用することから入る、即効性・実用性重視の講座です。

ひとつの記事を確認するだけでもすぐに開発に役立つ知見が手に入るでしょう。
最後まで終えると、PC にプログラム言語をインストールしなくても
プログラム開発ができるようになり、開発環境の管理の煩わしさから開放されます。

Docker を開発に使うと、どんなことが便利なの？

※ 既に Docker を習得するつもりの人は読み飛ばして構いません

• 開発のための仮想環境は Docker で作ろう

Docker をセットアップ

• Docker Desktop のシステム要件をどうやって確認したらいいの？

Docker を使って開発しよう

• Docker Desktop で 開発用 Web アプリを起動してみよう
• docker-compose.yml の内容を理解しよう
• PC に言語をインストールせずにプログラム開発しよう

この時点まですすめると、変更履歴を管理したいテキストファイルが増えてきます。
後で、ファイルのどの部分をいつ編集したかわからなくならないよう、
Git が未習得の場合は、ここまですすんだ時点で Git を習得することをお奨めします。
Git についての基礎知識を次の講座で習得できます:

Linux 知識の要らない Git 講座 目次

The post 実用から入る Docker 講座 目次 first appeared on ultra code.

• 開発のための仮想環境は Docker で作ろう
• プログラム開発の準備には仮想環境を使おう
• プログラムの動作環境が違うとどんなことが起こるの？

リモートで開発するための Visual Studio Code 講座 目次にもどる
実用から入る Docker 講座 目次に戻る

エディターのオートコンプリート、デバッグ、リンティングはできるの？

Docker と Visual Studio Code を組み合わせる
Remote Development 拡張機能を使うことで、
PC にプログラム言語やパッケージをインストールしなくても
次のようなことができるようになります:

• オートコンプリート
• デバッグ
• リンティング

仕組みは後ほど解説します。

Remote Development 拡張機能の登場以前は、
たとえ仮想環境を導入していても
PC 側のエディターでこれらの実行を行うために、
PC にもプログラム言語やパッケージをインストールする必要がありました。

Remote Development 拡張機能の登場で、
Docker コンテナー内のプログラム言語のインタプリターを
これらの実行に使えるようになり、
PC にプログラミング言語をインストール必要がなくなりました。

システム要件

次のリンクのシステム要件を満たしていることを確認します:
System requirements | Developing inside a Container using Visual Studio Code Remote Development

Docker Desktop と Visual Studio Code をセットアップしよう

PC に次をインストールします:

• Docker Desktop
• Visual Studio Code
• Remote Development 拡張機能

Docker Desktop については、インストール後に
続いて説明するファイル共有などの設定も確認します。

タスクバーの Docker アイコンを右クリック
→ [Settings] (Windows の場合) または [Preferences] (Mac の場合)をクリック

Windows で WSL2を使用している場合

[General] で、[Use the WSL 2 based engine] にチェックが入っていることと、
[Resources] → [WSL INTEGRATION] で
いずれかのディストリビューションが有効になっていることを確認します。

Windows 且つ WSL 以外の場合

[Resources] → [File Sharing] を開き、
ソースコードを配置しているドライブにチェックが入っていることを確認します。

Docker コンテナー内のフォルダーを Visual Studio Code で開いてみよう

1. Compose ファイルを準備しよう

まず、開発環境の基本となる Compose ファイルを準備します。
すでにプロジェクトで Docker Compose を使っていれば、
既存の Compose ファイルを使うこともできます。
ここでは例として、Python の開発環境を準備する場合を取り上げます。
最小の Compose ファイルの例を示します:

version: "3.8"
services:
  python:
    image: python
    working_dir: /workspace

このとき、なるべく次を満たすようにします:

• コンテナーの作業ディレクトリーが /workspace でないときは
  “working_dir” で /workspace を指定します
  • Visual Studio Code でコンテナーを起動すると、
    初期設定ではプロジェクトのフォルダーが /workspace に bind mount されるため
• “command” に初期化処理がある場合は “entrypoint” に退避します
  • VS Code でコンテナーを起動するとき、既定の設定では別の “command” が上書き設定されるため

また、この例では “image” で python の Docker 公式イメージを指定しています。
他の言語の場合は別のイメージを指定します。
イメージは次の URL から検索することができます。

Explore – Docker Hub

2. 開発コンテナー設定ファイルを追加しよう

Remote Development 拡張機能をインストールしていると、
Visual Studio Code の画面左下に新しいステータスバーの項目が表示されます。
(リモートクィックアクセス)
この項目をクリックすると、Remote-Containers のコマンド一覧が表示されるので、
[Remote-Containers: Add Development Container Configuration Files…] をクリックします。

すると、どのように設定を作成するかを尋ねるメニューが表示されるので、
[From ‘docker-compose.yml’] を選択します:

すると、.devcontainer というフォルダーが作成され、
その中に devcontainer.json と docker-compose.yml が作成されます:

このトレーニングでは、どちらのファイルも初期設定のままで問題ありませんので
全体の理解のために、まずは次の手順に進むことをおすすめします。

それぞれのファイルの役割をまとめておきますので、
確認が必要になった場合にこちらを見返してみてください。

3. コンテナー内で Visual Studio Code を起動しよう

開発コンテナー設定ファイルを追加した状態で、
もう一度 Visual Studio Code の画面左下の [リモートクィックアクセス] をクリックし
Remote-Containers のコマンド一覧が表示します。

すると、今度は
[Remote-Containers: Reopen in Container] が表示されるので、
こちらをクリックします。

すると、Visual Studio Code のウィンドウが開き直され、
コンテナーの構築が開始されます:

初回は少し時間がかかりますが、次回以降はすぐに開けるようになります。

また、Docker Desktop の Dashboard を確認すると、
Visual Studio Code が起動したコンテナーが表示されています:

Visual Studio Code の進捗バーのダイアログが消えたら、
プロジェクトのフォルダー内のファイルが
Visual Studio Code のサイドバーに表示されます。

プログラムを開発してみよう

ターミナルを開いてみましょう。
[Terminal] → [New Terminal]

すると、パネルが開き、ターミナルが表示されます:

先程の Compose ファイルを準備する段階で
“working_dir” で /workspace を指定するなどして
作業ディレクトリーを /workspace にしておくと、
ターミナルからも、すぐにプロジェクトのファイルにアクセスできて便利です:

$ pwd
/workspace
$ ls -la
total 16
drwxr-xr-x 3 root root 4096 Oct  5 04:52 .
drwxr-xr-x 1 root root 4096 Oct  5 05:54 ..
drwxr-xr-x 2 root root 4096 Oct  5 04:52 .devcontainer
-rw-r--r-- 1 root root   81 Oct  5 04:19 docker-compose.yml

このターミナルはコンテナーのシェルに接続されています。
この例は Python の開発環境なので、たとえば Python を実行してみましょう:

$ python --version
Python 3.8.6
$ python
Python 3.8.6 (default, Sep 24 2020, 21:45:12) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("Hello World!")
Hello World!
>>> exit()
$ 

PC にプログラムをインストールせずにプログラム言語を実行することに成功しました！

続いて、ソースコードを作成してみましょう。
サイドバーで test.py という新規ファイルを作成します:

print("Hello World!")

では、実行してみましょう:

$ python test.py
Hello World!

PC にプログラムをインストールせずにプログラムの開発に成功しました！

オートコンプリート、デバッグ、リンティングはどうするの？

このままではオートコンプリート、デバッグ、リンティングなどができません。
Visual Studio Code では、特定のプログラム言語に関する機能は
拡張機能をインストールする必要があります。

注意すべき点として、この、コンテナー内で開発を行う方式の場合は
ほとんどの拡張機能はコンテナー側にインストールする必要があります。

なぜなら、実際にコードを編集しているのは
PC 側の Visual Studio Code ではなく、
コンテナー内にインストールされ起動している
「Visual Studio Code のサーバー」だからです。

そのため、既に PC 側の Visual Studio Code に拡張機能をインストールしている場合でも、
改めて拡張機能をコンテナー側にインストールし直す必要があります。

それでは、拡張機能をインストールしてみましょう。
Visual Studio Code をコンテナー内で開き直していれば、
拡張機能のインストール方法は通常時と同じです。

アクティビティーバーの拡張機能アイコンをクリックして
キーワードで検索します。
今回の例では、”python” で検索するとよいでしょう。
拡張機能のリストが表示されたら、項目をクリックすると
拡張機能の詳細ページが表示され、詳細を確認できます。
インストールする場合は、[Install] ボタンをクリックします。
既に PC 側にインストールされている場合は、
[Install] ボタンの代わりに
[Install in Dev Container: Existing Docker Compose …] ボタンが表示されます。

この例では、Microsoft が提供している Python 拡張機能をインストールしています。

インストールが完了すると、
[Install] ボタンが [Reload Required] ボタンに変わることがあります。
拡張機能を有効化するためには、[Reload Required] ボタンをクリックして
Visual Studio Code を開き直します。

Visual Studio Code が開き直されたら、
エディターで Python ファイルを開き、コードを入力してみましょう。
例えば、”i” と入力すると、次のようにオートコンプリートが表示されます:

このように、プログラム言語毎に必要な拡張機能をインストールすることで
オートコンプリート、デバッグ、リンティングなどができるようになります。

ただし、コンテナーを削除してしまうと、
もう一度拡張機能をインストールし直す必要があります。
これを避けるために、拡張機能を開発コンテナー設定ファイルに登録して
拡張機能のインストールを自動化しましょう。

拡張機能のインストールを自動化しよう

.devcontainer.json を開くと、次のような記述があります:

{
    //---
    // Add the IDs of extensions you want installed when the container is created.
    "extensions": []
    //---
}

この “extensions” に拡張機能の ID を追加すると、
コンテナー起動時に自動的に対象の拡張機能がインストールされるようになります。

拡張機能の ID は次の場所に記載されています:

例えば、Microsoft が提供している Python 拡張機能の場合は
次のように記述します:

{
    //---
    // Add the IDs of extensions you want installed when the container is created.
    "extensions": [
        "ms-python.python"
    ]
    //---
}

また、Visual Studio Code を開発コンテナーではなくローカルで開いているときは
拡張機能の項目を右クリック → [Add to devcontainer.json] で
追加することもできます。

2020-10-06 現在、
この追加方法は Visual Studio Code をコンテナー内で開いているときは
動作しないようです。

参考: Developing inside a Container using Visual Studio Code Remote Development

リモートで開発するための Visual Studio Code 講座 目次にもどる
実用から入る Docker 講座 目次に戻る

The post 【Docker】【Visual Studio Code】 PC に言語をインストールせずにプログラム開発しよう first appeared on ultra code.

サンプルとして、
前回の Docker Desktop のトレーニング記事でコンテナーを実行するのに使った
docker-compose.yml を取り上げます。
前回のトレーニングは 10 分程度なので、より効率よく理解するために
先に前回の記事の内容を体験してみることをお奨めします。

Docker Desktop で 開発用 Web アプリを起動してみよう

docker-compose.yml は YAML 形式で記述されています。
ここでは Docker に関する解説を行っていきますので、
YAML の文法自体の解説については、次の記事を参照してください。

最低限押さえておきたい YAML の読みかた・書きかた

実用から入る Docker 講座 目次に戻る

docker-compose.yml のサンプル

まず、前回の Docker Desktop のトレーニング記事で使った docker-compose.yml に
コメントで注釈を追加したものをお見せします:

version: "3.8"  # この「Compose ファイルの書式のバージョン」
services:       # 「サービス」を定義する項目
  web:            # "web" という名前で「サービス」を定義
    image: adminer  # "adminer" の「イメージ」を使用
    ports:          # ホストの「ポート番号」とコンテナーの「ポート番号」を対応付けを定義します
      - 8080:8080     # ホストの「ポート番号」 8080 とコンテナーの「ポート番号」 8080 を対応付けます
  db:             # "db" という名前で「サービス」を定義
    image: mysql    # "mysql" の「イメージ」を使用
    environment:    # コンテナーに「環境変数」を設定します
      # ↓ "MYSQL_ROOT_PASSWORD" という「環境変数」に "example" という値を設定します
      MYSQL_ROOT_PASSWORD: example

ここで、次の用語が出てきました:

• サービス
• イメージ
• ポート番号
• 環境変数
• Compose ファイルの書式のバージョン

これらを順に解説していきます。

サービスとは

「サービス」は、起動するコンテナーの設定の定義です。

先ほどの docker-compose.yml では
services に web と db が定義されています:

version: "3.8"
services:       # 「サービス」を定義する項目
  web:            # "web" という名前で「サービス」を定義
    image: adminer
    ports:
      - 8080:8080
  db:             # "db" という名前で「サービス」を定義
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

docker-compose up コマンドでは、特に指定しなければ
各サービスからコンテナーを 1 つずつ起動しますが、
複数のコンテナーを起動することもできます。

例えば、
次のコマンドを実行すると、db サービスのコンテナーを 2 つ起動することができます:

docker-compose up -d --scale db=2

実行結果は次のようになります:

イメージとは

イメージは Docker のコンテナーのもととなるものです。
この例では web のサービスでは adminer というイメージを、
db のサービスでは mysql というイメージを指定しています。

version: "3.8"
services:
  web:
    image: adminer  # "adminer" の「イメージ」を使用
    ports:
      - 8080:8080
  db:
    image: mysql    # "mysql" の「イメージ」を使用
    environment:
      MYSQL_ROOT_PASSWORD: example

これらのイメージの情報や使い方は
Docker Hub という Web サイトで確認することができます。

adminer: adminer – Docker Hub
mysql: mysql – Docker Hub

他にも、様々なイメージが公開されており、
このような公開されているイメージを組み合わせて
従来、アプリケーション開発のための環境構築に必要だった時間と労力を
大幅に削減することができるようになります。

公開されているイメージは次のページで検索することができます:

Explore – Docker Hub

ポート番号とは

ポート番号の意味については、次のページの解説を確認してください:

ポート番号ってなに？

docker-compose.yml の ports では、
ホストのポート番号とコンテナーのポート番号を対応付けることができます。
例では、ホストのポート番号 8080 とコンテナーのポート番号 8080 を対応付けています:

version: "3.8"
services:
  web:
    image: adminer
    ports:          # ホストの「ポート番号」とコンテナーの「ポート番号」を対応付けを定義します
      - 8080:8080     # ホストの「ポート番号」 8080 とコンテナーの「ポート番号」 8080 を対応付けます
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

このようにすることで、ホスト、つまり PC 自身のポート番号 8080 に通信を行うと
対応付けたコンテナーのポート番号 8080 に通信を行うことができるようになります。

ブラウザーからコンピューター自身の特定のポート番号にリクエストする方法

前回の Docker Desktop のトレーニング記事で
Dashboard の [CONTAINERS] の [OPEN IN BROWSER] からブラウザーを開いたとき
URL は次のようになっていました:

localhost:8080

“localhost” はコンピューター自身と通信したい場合に利用する特別なアドレスです。

HTTP 通信で 80 以外のポート番号に通信するときは
ドメインの後にコロン (:) を置き、その後に使用するポート番号を続けます。

http://localhost:8080

上記のURLを使用すると、ブラウザはポート番号 80 ではなく、
ポート番号 8080 で接続を待ち受けている Web サービスに接続しようとします。

なぜポート番号 8080 を使うの？

“localhost” を利用した場合、通信内容はネットワークには流れません。
暗号化された https 通信を可能にするためには準備の手順が難解になるので
PC の中で開発を行うときは
暗号化されない代わりに準備が簡単な http 通信で行われることが多いようです。

一般的に http 通信はポート番号 80 が使われますが、
アプリケーション開発などで特定のポート番号を待ち受けるときは
ポート番号 1～1023 の利用を避けてポート番号を選択することが多いです。
(理由は後で解説します。)

8080 がよく利用される理由は、
「8080 は「2 つの 80」であることであるため」(わかりやすさ、憶えやすさ)
とされています。

参考: GRC | Port Authority, for Internet Port 8080

ポート番号 1～1023 の利用を避けてポート番号を選択する理由

これは、インターネットが生まれたときのシステムとサーバーの多くが
主に「UNIX」という OS を基にしていたことに起因しています。

UNIX は、1 ～ 1023 のポート番号については、
管理者権限で実行されているサービスだけが開くことができます。

つまり、 UNIX では管理者権限を持ったユーザーだけが
ポート番号 80 で Web サービスを提供できることになります。

そのため、ポート番号 1024 未満でサービスを実行する権限がない場合、
Web サービスを提供するのに便利なポート番号として 8080 が選択されるようになりました。

参考: GRC | Port Authority, for Internet Port 8080

環境変数とは

環境変数とは、
コンピュータ上で実行される処理がどのように振る舞うかに
影響をあたえることができる変数で、名前と値で定義されます。

service のキーとして設定する場合は、
ホストに対してではなく、起動するコンテナーに対して設定されます:

version: "3.8"
services:
  web:
    image: adminer
    ports:
      - 8080:8080
  db:
    image: mysql
    environment:    # コンテナーに「環境変数」を設定します
      # ↓ "MYSQL_ROOT_PASSWORD" という「環境変数」に "example" という値を設定します
      MYSQL_ROOT_PASSWORD: example

この場合は “MYSQL_ROOT_PASSWORD” という名前で “example” という値を設定しています。

環境変数がどのような影響を与えるかは、イメージ次第ですが、
主要なイメージはドキュメントを確認すると環境変数について解説されています。

前回の Docker Desktop のトレーニング記事で
Adminer からパスワード: “example” でログインしたので
大体想像がついていると思いますが、
MySQL のイメージのドキュメントを確認してみましょう。

mysql – Docker Hub

[How to use this image] の [Environment Variables] を参照すると
次のような記述があります。

MYSQL_ROOT_PASSWORD
This variable is mandatory and specifies the password
that will be set for the MySQL root superuser account.

mysql – Docker Hub

これは、日本語訳で、大体次のような意味です。

この変数は必須であり、
MySQL root 特権ユーザーアカウントに設定されるパスワードを指定します。

Compose ファイルの書式のバージョンとは

「Compose ファイル」ってなに？

docker-compose.yml のように、
サービスなど定義する YAML ファイルのことを「Compose ファイル」と呼びます。

Compose ファイルは、
Docker Desktop に含まれる Docker Compose というアプリケーションによって解釈され、
Docker Compose が、複数のコンテナーの Docker アプリケーションを実行する仕組みになっています。

Compose ファイルのバージョンってなに？

Compose ファイルの中で
最新の記法でサポートされなくなった記法を引き続き使うための機能です。

Compose ファイルでは、Docker Compose の開発が進むにつれて
新しい定義の記法が行えるようになったり、
古い定義の記法がサポートされなくなったりしています。

先ほどの docker-compose.yml では、
2020-07-30 時点で最新の書式バージョンである 3.8 を指定しています:

version: "3.8"  # この「Compose ファイルの書式のバージョン」
services:
  web:
    image: adminer
    ports:
      - 8080:8080
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

Compose ファイルのバージョンはどうして必要なの？

Docker Desktop のバージョンアップを行ったときに
古い記法がサポートされなくなったことが原因で
今まで使えていた Compose ファイルが突然使えなくなると困ります。

そのようなことにならないよう、
Docker Compose では過去の Compose ファイルの書式がサポートされ続けています。

version で過去のバージョンを指定することで、
その Compose ファイルは最新バージョンではサポートされなくなった記法を
引き続き使うことができます。

マイナーバージョンを省略しちゃダメ！

よく Docker を利用した解説記事で次のような定義を目にします:

"version": "3"

この定義はバージョン 3 の最新ではなく、 "3.0" として扱われます。
その結果、3.1 以降のバージョンで追加された機能はサポートされなくなります。

参考:
v2 and v3 Declaration | Compose file versions and upgrading | Docker Documentation
Version 3 | Compose file versions and upgrading | Docker Documentation

When specifying the Compose file version to use, make sure to specify both the major and minor numbers.

v2 and v3 Declaration | Compose file versions and upgrading | Docker Documentation

Compose ファイルのバージョンを指定するときは、
メジャー番号とマイナー番号の両方を指定していることを確認してください。

わからない記法を調べるときは

わからない記法を調べるときは、
次のページ内をブラウザーの検索機能で検索すると良いでしょう:

Compose file version 3 reference | Docker Documentation

実用から入る Docker 講座 目次に戻る

The post docker-compose.yml の内容を理解しよう first appeared on ultra code.

実用から入る Docker 講座 目次に戻る

Docker Desktop Dashboard を開いてみよう

Docker を操作したとき、何が起きるかわかりやすいように
Docker Desktop の Dashboard を開いておきましょう。

常駐している Docker Desktop のアイコンを右クリック → [Dashboard] をクリック:

すると、次のようなウィンドウが開きます:

Docker を使って Web アプリを起動してみよう

いきなりですが、Docker で Web アプリケーションを動かします。

“test-docker” というフォルダーを新規作成し、
“docker-compose.yml” というファイルを新規作成し、次の内容を記述します:

version: "3.8"
services:
  web:
    image: adminer
    ports:
      - 8080:8080
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

このファイルの内容については次の記事で解説しますが、
効率的に理解するために、まずこのトレーニングをすすめることをお奨めします。

そして、ファイルを作成したフォルダーでターミナルを開き、次のコマンドを実行します:

docker-compose up -d

すると、次のような出力が表示されます:

Creating network "test-docker_default" with the default driver
Pulling web (adminer:)...
latest: Pulling from library/adminer
df20fa9351a1: Pull complete
b358d6dbbdff: Pull complete
0232d962484c: Pull complete
0c1d3ac04d2a: Pull complete
b4e4f852df7e: Pull complete
6a973c07b1a7: Pull complete
81925cc0eeeb: Pull complete
4fce6c58c125: Pull complete
56d61120c3e2: Pull complete
81694e37d7e8: Pull complete
63580de12c3c: Pull complete
5483478c2601: Pull complete
d75c0834e7af: Pull complete
b3b3fdd9c555: Pull complete
50a9fb45e1ec: Pull complete
Digest: sha256:dc0bb811b48d861c4e08f7d52db98b51768243a2a3f656edf698a8a9a3bc4dc4
Status: Downloaded newer image for adminer:latest
Pulling db (mysql:)...
latest: Pulling from library/mysql
6ec8c9369e08: Pull complete
177e5de89054: Pull complete
ab6ccb86eb40: Pull complete
e1ee78841235: Pull complete
09cd86ccee56: Pull complete
78bea0594a44: Pull complete
caf5f529ae89: Pull complete
cf0fc09f046d: Pull complete
4ccd5b05a8f6: Pull complete
76d29d8de5d4: Pull complete
8077a91f5d16: Pull complete
922753e827ec: Pull complete
Digest: sha256:fb6a6a26111ba75f9e8487db639bc5721d4431beba4cd668a4e922b8f8b14acc
Status: Downloaded newer image for mysql:latest
Creating test-docker_web_1 ... done
Creating test-docker_db_1  ... done

Dashboard を確認すると、”test-docker” という行が表示されていますので、
行の中心あたりにマウスのカーソルを合わせクリックします:

すると、ログが表示され、左側に [CONTAINERS] という項目が表示されます:

ログに次の内容が表示されるまで待ちます:

db_1 | 2020-07-28T08:41:11.017766Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.21' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server - GPL.

上記のログは 「MySQL」というデータベース・アプリケーションが起動したことを示しています。

確認してみましょう。
[CONTAINERS] 欄の “test-docker_web_1” という行にマウスのカーソルを合わせると
アイコンがいくつか表示されるので、
一番左の [OPEN IN BROWSER] をクリックします:

ブラウザーで Web ページが表示されましたか？:

Dashboardを確認すると、次のようなログが表示されています:

Attaching to test-docker_web_1
 [36mweb_1  | [0m [Tue Jul 28 05:05:06 2020] [::ffff:172.21.0.1]:49264 Accepted
 [36mweb_1  | [0m [Tue Jul 28 05:05:06 2020] [::ffff:172.21.0.1]:49262 Accepted
 [36mweb_1  | [0m [Tue Jul 28 05:05:07 2020] [::ffff:172.21.0.1]:49264 [200]: GET /
 [36mweb_1  | [0m [Tue Jul 28 05:05:07 2020] [::ffff:172.21.0.1]:49264 Closing

URL にアクセスしたので、レスポンスを返す処理が行われていることがわかります。

この Web アプリケーションは Adminer という無料の Web アプリケーションで、
ブラウザー越しにデータベースの管理をすることができます。

Adminer – Database management in a single PHP file

データベースにログインしてみましょう。
ブラウザーに表示されているログインフォームに次のように入力して [ログイン] ボタンをクリックします:

ログインすると、MySQL のデータベースの一覧が表示されます:

ファイルを 1 つ用意してコマンドを 1 つ実行するだけで
web アプリケーションとデータベース・アプリケーションを起動することができました。

用語を覚えよう

コンテナー

Dashboard の [CONTAINERS] に表示された各行を「コンテナー」と言います。
コンテナーは Docker によって構築される仮想環境です。

ホスト

Docker の話題の中では、「コンテナー」との対比として
「Docker を動かしているコンピューター自体」のことを「ホスト」といいます。
Docker Desktop を使っているときは、今使っている PC がホストです。

コンテナーを止めたり動かしたりしてみよう

今、ブラウザーではコンテナーのデータベースアプリケーションにログインしていますが、
それを確認するために、
データベースのコンテナーを止めてブラウザを再読み込みしてみましょう。

Dashboard からコンテナーを止めることができます。
“test-docker_db_1” にマウスのカーソルを合わせると表示されるアイコンの内、
[STOP] をクリックします:

※ “test-docker_web_1” と間違えないように気をつけましょう。

すると、コンテナーがグレーになり、”EXITED (0)” と表示されます。

この状態でブラウザーを再読み込みします。
すると、エラーメッセージが表示され、ログイン画面まで戻されてしまいます:

では、もう一度動かしてみましょう。
Dashboard で “test-docker_db_1” にマウスのカーソルを合わせると表示されるアイコンの内、
[SRART] をクリックします:

すると、再びコンテナーがグリーンになり、”RUNNING” と表示されます:

ブラウザのログインフォームで再度ログインすると
再び MySQL のデータベースの一覧が表示されます:

では、コンテナーを一度に停止してみましょう。
Dashboard 上部のフォルダー名が表示されている部分の右側にあるアイコンの内、
[STOP] をクリックします:

すると、すべてのコンテナーがグレーになり、”EXITED (0)” と表示されます:

この状態でブラウザーを再読み込みすると、
「このサイトにアクセスできません」と表示されます:

先ほどの [STOP] のすぐ左に [START] があることからわかる通り、
すぐにコンテナーを起動することができ、
データベースのデータも保持され続けます。

コンテナーを停止していると、Dashboard に表示され続けます。
もう利用せず、データベースのデータも必要ない場合は
削除した方が Dashboard の見渡しが良くなります。

では、コンテナーをすべて削除してみましょう。
[STOP] のすぐ右にある [DELETE] をクリックします:

すると、コンテナーはすべて削除され、
ディレクトリーが表示されている行も Dashboard からなくなります:

この場合は、
また “docker-compose up -d” コマンドでコンテナーを起動することができますが、
データベースのデータは引き継がれず、新たに初期化されます。

この時点では、実はまだデータベースのデータは失われていませんが、
この時点からデータの回収を行うのは面倒なので
バックアップはコンテナーを削除する前に行うようにしましょう。

アプリケーション開発ではデータを保存する必要はあまりないので、
これだけで十分に役立ってくれることでしょう。

Docker の Dashboard についてさっと確認しました。
次は最初に作成した docker-compose.yml の内容について見てみましょう:

docker-compose.yml の内容を理解しよう

実用から入る Docker 講座 目次に戻る

The post Docker Desktop で 開発用 Web アプリを起動してみよう first appeared on ultra code.

参考: マスタリングTCP/IP　入門編（第6版） | Ohmsha

物理的な機器の外部インターフェースの「ポート」とは別の概念です！

PC やルーターなど、コンピューター機器の外部インターフェースのことも
「ポート」と言いますが、
ここでの「ポート番号」とは、それとは全く別の概念を指しています。
明確に区別するために、この記事では「ポート番号」と表現します。

ポート番号とは

ポート番号とは、
通信を行っている同一のコンピューター内のプログラムを識別するときに利用される番号です。

同一のコンピューターの中でも複数のプログラムが通信を行うことがあります。
例えば、同一のサーバーで次のような通信を同時に待ち受けることもできます:

ポート番号がなかったらどうなるの？

もし、ポート番号がなければ
同時に待ち受けているどちらのプログラムに通信のデータを渡すべきなのか
判断するのが非常に困難になります。

この状態を郵便配達にたとえると、
封筒に記載された宛先が住所だけで、誰宛かの記載がないのと同じ状態です。

封筒を受け取った人は、封筒を誰に渡すべきかを判断するために
封筒を開けて内容などの確認をしなければならなくなります。
大量に通信する上で、このようなことがあっては非効率的です。

ポート番号はどうやって決まるの？

通信方式ごとに利用すべきポート番号が定められています。

これを定めているのは
「IETF」という、誰でも参加可能なインターネット標準化団体です。

IETF | Internet Engineering Task Force

広く使われるポート番号は「well-known ports」と呼ばれ、
次の Web サイトで確認することができます:

Service Name and Transport Protocol Port Number Registry

少なくとも一般に公開するサービス等でこれらのポート番号を別の用途に使うのは
混乱を招く可能性があるため行わないほうが無難です。

ポート番号を意識しなくていいように標準のポート番号を使おう

普段私たちが生活している中ではポート番号を意識しなくても
Web サービスを利用したりメールを送信することができます。

例えば ブラウザーは特に指定しない限り、 URL を入力すると
ドメインが指し示すサーバーのポート番号 443 へ通信します。

メール送信も同様に、メールのアプリケーションは特に指定しない限り
メール送信時にはメール送信サーバーのポート番号 587 への通信を行います。

もしサーバー側が別のポート番号で通信を待ち受けている場合、
ユーザーにサービスを提供するためには
ブラウザーやアプリケーションに対して特殊な設定を行ってもらうことになってしまいます。

サービスを開発するときは
「well-known ports」の標準を守ってポート番号を使うようにすると
ユーザーはポート番号を意識する必要がなくなり、サービスを提供しやすくなります。

The post ポート番号ってなに？ first appeared on ultra code.