DockerでPythonの開発環境を作成してみる その2
今回は、「DockerでPythonの開発環境を作成してみる その2」となります。前回、DockerfileからDockerイメージを作成してコンテナを起動、そしてPythonのスクリプトファイルを実行するところまで環境を作りました。
今回は、ホストのVSCodeからコンテナ上のPythonでデバッグ実行できるようにする環境を構築していきます。
※前回の「DockerでPythonの開発環境を作成してみる その1」から読みたい方は、こちらからどうぞ。
【目次】
- 1. VSCodeへの拡張機能のインストール
- 2. コンテナを起動する
- 3. VSCodeからコンテナに接続
- 4. VSCodeで新規ファイルを追加してみる
- 5. コンテナ側にVSCodeの拡張機能をインストール
- 6. デバッグ実行してみる
- 7. まとめ
- 参考
1. VSCodeへの拡張機能のインストール
まずは、VSCode側の準備として、拡張機能をインストールします。
インストールするのは「Remote - Containers」です。
VSCodeでDockerコンテナ上で動作している開発環境に接続して、あたかもコンテナ上でVSCodeを使っているようにするようなものです。
(あってるかな?)
では、Remote - Containersをインストールしていきます。
①VSCodeの拡張機能の検索バーに「remote」と入力する
②検索バーの下の検索結果に「Remote - Containers」が出てくるのでそれを選択します。
③「Remote - Containers」のインストール画面が開いたら「install」ボタンを押下して、インストールを実施します。
サイドバーに下図のような「Remote - Containers」アイコンが追加されればインストール成功です。
2. コンテナを起動する
前回作成したPythonの開発環境のコンテナを起動します。
前回コンテナを停止していた場合は、コンテナをstartコマンドで起動します。
PS D:\docker\python3> docker container start pythonwork pythonwork
lsコマンドで稼働しているコンテナを確認します。
PS D:\docker\python3> docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 19a1a6291e4d pythondev "/bin/bash" 4 minutes ago Up 8 seconds 8080/tcp pythonwork
3. VSCodeからコンテナに接続
VSCodeのサイドバーの「Remote - Containers」アイコンを選択します。
「Remote - Containers」の画面が開き、リモートコンテナーと書いてある表示領域に先ほど起動したコンテナ「pythonwork」が存在することが確認できます。
接続したいコンテナ名にカーソルを合わせると、コンテナ名の左側に下図のようなアイコンが表示されます。
このアイコンをクリックします。
すると新しいウインドウが開きます。
しばらく待つと新しく開いたVSCodeのウインドウの左下に「Attached Container pythondev(pythonwork)」と表示され、コンテナに接続されたことが確認できました。
次は、マウント先のディレクトリを選択します。
まず、サイドバーの一番上のエクスプローラーアイコンを選択します。
表示されたが画面で「フォルダーを開く」ボタンを押下します。
画面中央にコンテナ側のディレクトリを選択するコンボボックスが表示されます。
コンテナ作成時に作成した「workdir」を選択して「OK 」ボタンを押下します。
マウント側のディレクトリと同じ内容が表示されれば成功です。
4. VSCodeで新規ファイルを追加してみる
VSCode側で新規ファイルを追加してみます。
VSCodeで「新しいファイル」ボタンを押下します。
ファイル名を入力しEnterキーを押下すると、ファイルが作成されてウインドウ右側に作成したファイルが開かれます。
この新規作成したファイル「newTestFile.py」がコンテナ側にも存在することを確認してみます。
下記コマンドでコンテナのbashを起動します。
PS D:\docker\python3> docker container exec -it pythonwork /bin/bash
bashが起動したら、ディレクトリ「workdir」配下のファイルを確認してみます。
root@19a1a6291e4d:/workdir# ls -l total 1 -rwxr-xr-x 1 root root 0 Nov 20 13:39 newTestFile.py -rwxr-xr-x 1 root root 80 Nov 12 13:28 test.py
VSCodeで作成したファイル「newTestFile.py」がコンテナにも存在することが確認できました。
5. コンテナ側にVSCodeの拡張機能をインストール
ローカルでVSCodeにインストールされている拡張機能は、コンテナ側にはインストールされていません。
必要であれば、コンテナ側にも拡張機能をインストールしてください。
コンテナ側に拡張機能をインストールするときは、「install」ボタンが、
「Install in Attached Container コンテナ名(イメージ名)」
に変わります。
6. デバッグ実行してみる
VSCode側からデバッグ実行をしてみます。
先ほど作成した新規Pythonファイルに下記のようなコードを書いて保存します。
def main(): hoge = "hogehoge" print("Hello" + hoge + "World!") if __name__ == "__main__": main()
print文のところにブレイクポイントを追加します。
ウインド上部メニューの「デバッグ」から「デバッグの開始」を選択します。
コマンドパレットが表示されるので「Python File」を選択します。
デバッグ実行が開始され、ブレイクポイントの位置で止まります。
変数の中の値が確認できたり、ステップ実行が可能であることがわかります。
実行し終わると、画面下部のターミナル領域にプログラムの実行結果が表示されました。
7. まとめ
ホストのVSCodeからコンテナ上のPythonでデバッグ実行する環境を作ることができました。また、実際にデバッグ実行をして、ローカルで開発するのと同じ感覚でデバッグができることもわかりました。
これの何がいいかというと、ローカルにPythonをインストールする必要がなくなくなるので、ローカル環境を汚さずに済むということ。
開発環境が不要になったらコンテナを削除すればいいだけなの、とってもお手軽です。
あと、開発環境のコンテナを一つ作って開発メンバに配れば、メンバ全員が全く同じ開発環境で開発可能になります。
長くなりましたが、興味がある方はぜひDockerを使っての開発環境構築お試しあれ。
参考
Webブラウザのアドレスバーについて気付いたこと
普段WebブラウザはFirefoxを使っているのですが、会社ではChromeを使っています。2つのブラウザを使用していて、ふと気が付いたことがあるのでここで紹介してみます。
【目次】
1. ブラウザのアドレスバー
Webブラウザにはアドレスバーと言ってURLの表示領域があります。その領域に表示されるURLがFirefoxとChromeで違うことに気が付きました。
このブログを各ブラウザで表示したときアドレスバーに表示されるURLをみてみると、次のようになります。
画像だと見えにくいかもしれないので表にしてみます。
ブラウザ | 表示されているURL |
---|---|
Firefox | https://ittech-nsnl.hatenablog.com |
Chrome | ittech-nsnl.hatenablog.com |
わかりましたか?
そう。ChromeはURLの「https://」というプロトコル部分が表示されていないんです。
また、このブログのURLにはwwwサブドメインが付いていませんが、wwwサブドメイン付のURLをChromeで表示させると「https://」に加え「www」も表示されませんでした。
ブラウザ | 表示されているURL |
---|---|
Firefox | https://www.watch.impress.co.jp |
Chrome | watch.impress.co.jp |
ちなみに、これらの違いはスマートフォンのChromeブラウザでも同様でした。
2. ChromeでHTTPスキームとwwwサブドメインが表示されない理由
Chromeでは「Chrome 69」から「https:// (http://)」とwwwサブドメインが表示されなくなったらしいです。これはGoogleのセキュリティに関する方針によるもので、HTTPSへの移行を促す目的もありそうです。
GoogleはChromeのセキュリティ インジケーターを将来的になくそうとしているそうです。現在、WebサイトはHTTPSがデファクトスタンダードになってきています。こうした流れの中、ChromeではすべてのWebサイトが安全(HTTPS)であることをデフォルトと扱うと言っています。
つまりGoogleさんが何が言いたいかというと、
「これからはすべてのWebサイトが安全なんだから、セキュリティ インジケーターとかアドレスバーに表示するURLのHTTPSスキームとか不要だよね。だから、無くすよ。」
ってことです。
その過程として、まずは「保護された通信(Secure)」というマークと HTTPS スキームの削除を実施したということです。
3. まとめ
Chromeのアドレスバーの表示について調べてみました。
GoogleがHTTPSのWebサイトがデフォルトだというからには、現在HTTPのままのWebサイトもHTTPSへの移行を余儀なくされるんじゃないのかなと思います。
まだHTTPSへ移行していないWebサイトの管理者の方は、早めにHTTPSへ移行しましょう。
参考
Chrome の進化するセキュリティ インジケーター :
https://developers-jp.googleblog.com/2018/06/evolving-chromes-security-indicators.html
https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
最近熱いJavaScriptについて
JavaScriptはWebサイトでは必須技術となっています。しかし、一時期、JavaScriptはセキュリティ上よくないから設定を無効にしておいたほうが良いと言われていた時もありました。
いろんな紆余曲折があったっぽいJavaScriptについて、最近の動向をまとめてみました。
【目次】
1. JavaScriptとは
JavaScriptはWebページ上で動作するプログラミング言語です。動的にWebページを更新したり、エディットボックスに入力された値のチェックをしたり、計算したりなどなど、Webページ上で多くのことができるスクリプト言語です。
【JavScriptで数値判定を書いた例】
num = 5; if (num < 10) { alert("Small"); } else { alert("Big"); }
2. サーバーサイドで動くJavaScript
JavaScriptはWebブラウザ上でのみ動くプログラミング言語でした。
一般的にWebサイトはフロントエンドはJavaScript、サーバーサイドはPHPやJavaなどで実装していました。そのため、Webサイトを作ろうとすると、複数のプログラミング言語を使用する必要がありました。
しかし、最近はJavaScriptをサーバーサイドでも使えるようになってきています。その代表が「Node.js」です。
Node.jsはMaicrosoftやYahoo!など有名IT企業でも使用されています。
フロントエンドもサーバーサイドもJavaScriptで実装できれば、言語はJavaScriptだけでよいため学習コストも比較的下がりそうな感じです。さらに、JavaScriptしか書いたことのないWebデザイナーの人たちも、サーバーサイド側も書けるようになり効率が良くなるというも注目される理由らしい。
Wikipedia:https://ja.wikipedia.org/wiki/Node.js
3. JavaScriptのフレームワーク
最近はJavaScriptのライブラリやフレームワークを活用して開発するのが主流だそうです。最近の複雑なWebアプリケーションはJavaScriptのフレームワークを使用していることが多いと思います。
JavaScriptをそのまま使って書く時もあると思いますが、ライブラリやフレームワークを使用した方が開発効率も上がるし、便利な機能などを使用できるようになるのはうれしいですね。
4. フレームワークの種類
JavaScriptのフレームワークで有名なものを3つ簡単に紹介します。
React
Facebookが開発を行っているJavaScriptフレームワーク。
SPA(シングルページアプリケーション)やモバイルアプリの開発のベースに使用できる。
Instagram、Skypeなどで使用されているらしい。
Wikipedia:https://ja.wikipedia.org/wiki/React
AngularJS
Googleが開発を行っているJavaScriptフレームワーク。
SPA(シングルページアプリケーション)の開発に向いている。
Wikipedia:https://ja.wikipedia.org/wiki/AngularJS
Vue.js
オープンソースのJavaScriptフレームワーク。
AngularJSなどと比べフレームワークの構造がシンプルで、日本語のドキュメントも充実していて、学習コストが低め。
zozo、LINEなどで使用されているらしい。
Wikipedia:https://ja.wikipedia.org/wiki/Vue.js
5. まとめ
最近のJavaScriptについてまとめてみました。自分はフロントエンドの開発は全然なんですが、これから基本ぐらいは少しづつ勉強していこうと思います。
なんか、簡単なWebアプリが作れるくらいにはなりたいな。
HTTPとHTTPS
今日は、HTTPとHTTPSという2つのプロトコルについて。
Webサイトを見るときに表示されているURLの頭に付いている "HTTP" や "HTTPS" という文字列。(最近のWebブラウザはプロトコル部分が表示されないのもあるけど)
この "HTTP" や "HTTPS" とは何なのかまとめました。
[目次]
1. URL
HTTPを説明する前に、まずはブラウザの上のほうに表示されていたり、入力したりするURL (Uniform Resource Locator)についてみていきます。
URLはインターネット上の住所みたいなもので、下記のような構造になっています。
【http】
プロトコル名
ウェブなら http, https
ファイル転送なら ftp
のように用途によって決まっている。
【ittech-nsnl.hatenablog.com】
ドメイン名(FQDN)。
IPアドレスは数字の羅列で人間にとって覚えにくい。じゃあ人間にとって覚えやす文字列を使おう(文字列には意味を持たせることができるから)ってしたもの。
【sample/src】
フォルダ名。サーバー内でファイルが格納されている場所のパス。
【index.html】
ファイル名。省略可能。
Webをページを開くためのURLの先頭にあるのが、今回説明するHypertext Transfer Protocol = httpです。
2. HTTPとは
HTTP (Hypertext Transfer Protocol ) は、WebブラウザとWebサーバーの間で通信するためのプロトコル(通信のための規約)です。
インターネットの利用環境の違い(OSの違いだったり、利用端末の違いだったり)によって通信方法が異なっていたら不便なので、HTTPという共通の通信規約を定めることで、利用環境が異なっていても同じようにデータ通信できるようになっています。
3. HTTPSとは
HTTPS は、Hypertext Transfer Protocol Secure の略で、文字通りHTTPプロトコルがセキュアになったもの。HTTPによる通信をよりセキュア(安全)に行うためのプロトコルです。
HTTPSでは、SSL/TLS (Secure Socket Layer / Transport Layer Security)というインターネット上でデータを暗号化して、安全に通信を行うためのプロトコルを使用してでHTTP通信を行っています。
4. HTTP と HTTPS の違い
HTTPでは、データ(通信内容)がインターネット上を暗号化などされないまま、素の状態でやり取りされます。そのため、悪い人によってデータの通信途中で改竄や盗聴をされる恐れがあります。(これを中間者攻撃(Man in the middle attack)という)
この改竄や盗聴を防ぐために、HTTPSでは通信内容を暗号化して安全にデータをやり取りできるようにしています。
つまり、HTTPとHTTPSの違いは通信内容を暗号化しているか、していないかの違いというわけです。
しかし、通信内容を暗号化して改竄や盗聴を防いでも、通信相手が信頼できなければ意味がありません。そこで、SSLにはWebページ(通信先のサーバー)の所有者が実在することを証明する仕組みも持っています。この正当な所有者であることを保証するものを、**証明書(SSLサーバー証明)といいます。
上記より、HTTPSの役割としては下記2点がとなります。
- 通信の暗号化
- Webページの運営者が実在すること証明
5. HTTP、HTTPSの現状
最近はHTTPSが標準(というか当たり前)となっています。
GoogleのChromeというWebブラウザでは、HTTPのWebサイトを表示させると警告でるようになっています。
下記は国土交通省のWebサイトですが、HTTPSに対応していないためブラウザのURL欄に警告が表示されています。
HTTPSに対応したWebサイトが増えることで、インターネット上の通信がより安全に行えるようになってきています。
しかし、一部大手サイトや国交省のような公官庁のサイトで、まだHTTPSに対応してないところもあるのが現状です。
6. まとめ
HTTPとHTTPSというプロトコルについてまとめてみました。HTTPリクエストとかまだ説明できてないことはあるけど、今回はここまで。
今回も文字多めですが、みなさんの役に立てていただけると幸いです。
参考
- 戸根 勤 「ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識」 日経BP
- aico, 株式会社ディレクターズ 「小悪魔女子大生のサーバーエンジニア日記」 技術評論社
- SSL/STL総合解説サイト:https://www.sslcerts.jp/
- 国土交通省:http://www.mlit.go.jp/
【Java】Stringクラスの文字列比較
今日はJavaのStringクラスについて。JavaのStringの文字列比較について知らなかったことがあるので紹介します。
[目次]
1. Stringクラスによる文字列比較
Javaにおいて、Stringクラスの文字列比較は「==」ではなく、「equals()メソッド」を使いましょう。なぜなら、「==」は比較対象の二つの文字列変数が同じオブジェクトへの参照かどうかを判定するのに対し、「equals()メソッド」は文字列の内容が一致しているかを判定するからです。
と言われます。
では、下記のプログラムを実行すると、結果はどうなるでしょうか?
public class StringTest { public static void main(String[] args) { String hoge1 = "hogehoge"; String hoge2 = "hogehoge"; if (hoge1 == hoge2) { System.out.println("Equal"); } else { System.out.println("Not Equal"); } } }
結果は、、、
Equal
となります。
なぜかというと、JavaにはString Poolと呼ばれる文字列がJVMによって格納される特別なメモリ領域があるためです。
2. String Pool
String型の変数を作成してそこに文字列リテラルを代入すると、まずString Pool内に同じ文字列が存在しないか検索されます。
そこで同じ文字列が見つかった場合は、その文字列への参照を返します。
見つからなかった場合は、String Poolに文字列を格納して、その参照が返されます。
つまり、上記のプログラムの例ではString Pool内に存在する「hogehoge」という文字列オブジェクトへの参照が、「hoge1」と「hoge2」へ返されるため、「==」で比較したときに同じオブジェクトへの参照と判定されて「Equal」となるということです。
String Pool内で使用された文字列を重複なく管理して、同じ値の文字列がString Poolに存在した場合はそのインスタンスへの参照を返すことで、オブジェクトが無駄に作成されることを防ぐことができるということです。
2.1. immutable(イミュータブル)なクラス
ここで、同じ参照値が使いまわされるとすると、インスタンスの中身が書き換えられてしまった場合の懸念があります。
たとえば、変数Aと変数Bが同じインスタンスへの参照値を保持しているとします。このとき、変数Bからインスタンスの中身を書き換えられてしまうと、変数Aにも影響が出てしまうのでは?ということです。
そしてこれは、immutable(イミュータブル)なクラスが解決します。
イミュータブルなクラスは、オブジェクト自体の値を書き換えられないようになっているクラスなんです。
JavaのStringはイミュータブルなクラスなので、String Poolから参照が返されても、その値を書き換えることは不可能ということです。
3. new String()
Stringクラスは、String Poolに同じ文字列があればその参照が返されると説明しましたが、new String()でStringクラスをインスタンス化したときはString Poolは考慮されません。
new String()でインスタンス化すると、文字列オブジェクトが新規で作成されます。
よって、下記のプログラムを実行すると「No Equal」が表示されます。
public class StringTest { public static void main(String[] args) { String hoge1 = "hogehoge"; String hoge2 = new String("hogehoge"); if (hoge1 == hoge2) { System.out.println("Equal"); } else { System.out.println("Not Equal"); } } }
4. まとめ
JavaのStringクラスの文字列比較ついてまとめてみました。文字だらけで長くなってしまいましたが、Stringの理解の手助けになれば幸いです。
参考
- Java文字列のプール: https://www.codeflow.site/ja/article/java-string-pool
- クラスString : https://docs.oracle.com/javase/jp/8/docs/api/java/lang/String.html
- 谷本心/阪本雄一郎/岡田拓也/秋葉誠/村田健一郎 「Java 本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで」 株式会社技術評論社
- 7-1-1 Stringクラスの特徴
- Joshua Bloch著 「Effective Java 第2版」 丸善出版
- 第2章 項目5 不要なオブジェクトの生成を避ける
DockerでPythonの開発環境を作成してみる その1
タイトルの通り、DockerでPythonの開発環境を作成してみようと思います。最終的にはWindows上のVSCodeからデバッグ実行できる環境を作るのを目指します。
今回はDocker上にPythonの実行環境を作るところまでです。
[目次]
1. Dockerfileを用意する
Dockerでインフラ構成を記述したファイルをDockerfileと呼びます。Dockerfileに記述された構成情報をもとにDockerイメージの生成ができできます。
今回は、DockerfileからDockerイメージを作成してみます。
作成するのはPython3の実行環境とし、作成したDockerfileは下記となります。
【Dockerfile】
# ベースイメージ FROM python:3.5.9 # pipをアップグレード RUN pip install --upgrade pip # 作業ディレクトリ作成 WORKDIR /workdir # ポート EXPOSE 8080
FROM
作成するDockerイメージのベースとなるイメージを指定します。
今回はPythonの公式イメージであるpython:3.5.9をベースに作成します。
RUN
FROMで指定したベースイメージに対してコマンドを実行したいときにRUN命令を使います。
今回はPythonのパッケージ管理ツールであるpipを最新版に更新する処理をRUN命令で記述しています。
WORKDIR
Dockerfileで定義した命令を実行するための作業ディレクトを指定するときにWORKDIR命令を使います。
もし、指定したディレクトリが存在しなければ、新規で作成されます。
今回は、特にWORKDIRに対する命令は実行しませんが、WORKDIR命令によってコンテナ側のルート直下にworkdirという名前の作業ディレクトリを作っています。
EXPOSE
コンテナの公開するポート番号を指定するときに、EXPOSE命令を使用します。
今回は、8080ポートを公開するように指定しています。
2. DockerfileからDockerイメージを作る
作成したDockerfileをbuilコマンドでビルドし、Dockerイメージを作成します。
【ビルド実施前のDockerイメージ一覧】
PS D:\docker\python3> docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu latest cf0f3ca922e0 3 weeks ago 64.2MB mcr.microsoft.com/mssql/server 2017-latest cfe5615bf6a8 5 weeks ago 1.38GB
【ビルド実施】
下記コマンドでビルドを実施します。
docker build -t pythondev .
-t オプションを付けることでDockerイメージの名前を指定します。
今回はDockerfileの置いてあるディレクトリでdocker buileコマンドを実行するので、パスは 「.」で指定してます。
また、Dockerfileのファイル名を「Dockerfile」以外の名称で作成したときは、Dockerfileのファイル名を指定する必要があります。(Dockerfileのファイル名が「Dockerfile」の時は、ファイル名を省略可能。)
【ビルド実行結果】
PS D:\docker\python3> docker build -t pythondev . Sending build context to Docker daemon 2.56kB Step 1/4 : FROM python:3.5.9 3.5.9: Pulling from library/python c7b7d16361e0: Pull complete b7a128769df1: Pull complete 1128949d0793: Pull complete 667692510b70: Pull complete ~ 省略 ~ Successfully built fb9ef271807b Successfully tagged pythondev:latest SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
【ビルド実施後のDockerイメージ一覧】
PS D:\docker\python3> docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE pythondev latest fb9ef271807b About a minute ago 914MB python 3.5.9 c02d3cb0a185 7 days ago 908MB ubuntu latest cf0f3ca922e0 3 weeks ago 64.2MB mcr.microsoft.com/mssql/server 2017-latest cfe5615bf6a8 5 weeks ago 1.38GB
ビルドして作成した「pythondev」がDockerイメージ一覧の中に存在することがわかります。
また、ベースイメージと使用した「python」もDockerイメージとして存在しています。初回のビルド時はDockerリポジトリからベースイメージのダウンロードがされます。2回目以降はベースイメージのダウンロードしないので、Dockerイメージの作成処理のみとなります。
3. コンテナを起動する
作成したDokerイメージからコンテナを起動します。
docker container run -it -v D:\docker\python3\src:/workdir --name pythonwork pythondev /bin/bash
-v オプションを付けることでコンテナとホスト間でディレクトの共有ができます。
上記のコマンドだとホスト側の「D:\docker\python3\src」ディレクトリと、コンテナ側の「/workdir」ディレクトリを共有するように指定します。
【コンテナ起動結果】
PS D:\docker\python3> docker container run -it -v D:\docker\python3\src:/workdir --name pythonwork pythondev /bin/bash root@e7619f49b532:/workdir#
【ホストとコンテナのファイル一覧確認】
ホスト側のディレクトリにファイルが存在しない場合、コンテナ側のディレクトリにもファイルが存在しないことがわかります。
[コンテナ側のディレクトリ]
root@7773bb5fc812:/workdir# ls -l total 0
【ホスト側にファイルを追加した時のファイル一覧確認】
ホスト側のディレクトリにファイルを追加すると、コンテナ側のディレクトリにもファイルが存在(追加)されることがわかります。
[コンテナ側のディレクトリ]
root@7773bb5fc812:/workdir# ls -l total 1 -rwxr-xr-x 1 root root 80 Nov 12 13:28 test.py
4. Pythonのスクリプト実行
起動したコンテナでPythonのスクリプトファイルが実行できることを確認します。
【test.py】
def main(): print("Hello World!") if __name__ == "__main__": main()
/workdirに追加したスクリプトファイル「test.py」をコンテナ上で実行すると、実行結果が表示されることがわかります。
【test.pyの実行結果】
root@e7619f49b532:/workdir# python3 test.py Hello World!
5. まとめ
DockerfileからDockerイメージを作成し、コンテナを起動するところまで実施しました。さらにPythonのスクリプトファイルを実行し、正常にPythonが動作することも確認できました。
次回は、ホストのVSCodeからコンテナ上のPythonでデバッグ実行できるようにする環境を構築しようと思います。
参考
バーチャルホスト(virtual host )とは?
今日はバーチャルホストについて。
[目次]
1. バーチャルホスト(virtual host )
1つのサーバーで複数のドメインを運用するための技術のこと。
バーチャルホストを使うと、1つのサーバーに複数の異なるドメイン名が割り当てられます。そのため、外部からはそれぞれ独立したサーバーであるかのようにみえます。
メリットとしては、サーバーの数を減らし運用のコストを下げることや、IPの有効活用ができるなどが挙げられます。
バーチャルホストには大きく分けて 名前ベースバーチャルホスト と IPベースバーチャルホスト の2つがあります。
1.1. 名前ベースバーチャルホスト
名前ベースバーチャルホストでは、1つのIPアドレスに複数のドメインを割り当てます。
外部からのアクセスでどのバーチャルホストへ向けたアクセスなのかを指定するには、HTTPの場合は要求メッセージ内のHOSTヘッダで対象のホストを指定します。
【HTTPの要求メッセージ例】
GET / HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja Accept-Encoding: ja,en-US;q=0.7,en;q=0.3 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0 Host: www.xxx.zzz ← アクセス対象のホストを指定 Connection: Keep-Alive
1.2. IPベースバーチャルホスト
IPベースバーチャルホストでは、1つのサーバーに複数のIPアドレスを割り振り、それぞれにドメイン名を設定します。
HTTPの要求メッセージ内のHOSTの指定をしなくてもバーチャルホストの区別ができますが、運用したいホストの数だけIPアドレスが必要になります。
2. まとめ
バーチャルホストについてまとめてみました。
レンタルサーバーや小規模サイトなどで使用されいるらしく、意外と身近な技術でした。