Dockerデータ量とDockerFileの学習

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

https://ost..com

データボリュームとは
データボリュームは、ホストマシン内のディレクトリまたはファイルです。データボリュームの設計目的は、コンテナーのライフサイクルから完全に独立したデータの永続性です。したがって、コンテナが削除されても、Docker はマウントされたデータボリュームを削除しません。コンテナディレクトリとデータボリュームディレクトリがバインドされると、相手側への変更が即座に同期されます。データボリュームは複数のコンテナーによって同時にマウントすることができ、コンテナーも複数のデータボリュームとともにマウントできます。
データボリュームはコンテナー間で共有および再利用でき、ローカルとコンテナー間のデータ転送がより効率的になります。
データボリュームへの変更はすぐに有効になり、コンテナー内とローカルディレクトリの両方で変更できます。
データボリュームの更新はイメージに影響を与えず、データとアプリケーションを分離できます。
ボリュームは、コンテナーが使用しなくなるまで存続します。

実際、コンテナとホストが互いに分離されているため、前回の記事で説明したポートマッピングと非常によく似ていることは理解しにくいことではありません。ポートマッピングは、2 つの分離されたエンティティ間にチャネルを構築し、通信を共有できるようにします。データボリュームについても同様ですが、コンテナの停止によってデータボリュームが消えることはありません。コンテナまたはホストがバインドされている限り、データボリュームの内容は失われません。

データ量

1. ホストディレクトリにマウントするための直接コマンド

1. nginxをテストする

 docker run -v ホストディレクトリ: コンテナディレクトリ
docker run -d -v ホストディレクトリアドレス: / usr / share / nginx / html -p 8080 : 80 --name nginx -music -volume nginx

2 つのディレクトリがマウントされると、ディレクトリを共有するのと同じになります。どちら側が変更ディレクトリの内容を送信しても、内容は変更されます。こうすることで、ホスト側のディレクトリを操作するだけで、コンテナ内のディレクトリもそれに応じて変更されます。前回の記事で行ったcp操作と同様に保存しておき、バージョンアップが必要な時はホストマシン上で操作するだけで済みます。次に、nginx でテストし、独自にカスタマイズした Web ページをマウントします。

ここで、私自身の Web ページは /var/www/html に配置されます。次に、nginx コンテナ内の html フォルダーにマウントする必要があります。

実行されており、アクセス可能であることがわかります。 Web ページが機能するかどうか確認してみましょう。

はい、問題ありません。ここでは、docker examine container id を通じて詳細情報を表示することもできます。

ここでマウントが成功したことがわかります。 -v を使用すると、ローカルディレクトリの Web ページをコンテナーに簡単に配置できることがわかります。この時点で、2 つのディレクトリは実際に同じディレクトリを共有していると言えます。このコンテナーを削除しても、内部の内容は保持されます。

将来的に新しいバージョンを変更したりリリースしたりするには、サーバー上で変更するだけで済みます。コンテナは自動的に同期されます。コンテナが削除されない限り、停止状態か実行状態かに関係なく、自動的に同期されます。

2. MySQLをテストする

デモにはmysql:5.7バージョンを使用します。まず、docker pull mysql:5.7 を実行します。もちろん、まずは公式サイトに行って確認します。やはり、問い合わせや勉強のために公式サイトに直接アクセスすることをお勧めします。

ただし、マウントディレクトリの管理を容易にするために、ここでコマンドを変更する必要があります。

 docker run -d -v / home / mysql / conf : /etc/ mysql / conf 。 d -v / home / mysql / data : /var/ lib / mysql - e MYSQL_ROOT_PASSWORD = root - p 3310 : 3306 -- name mysql01 mysql : 5.7 前の記事を読んだ後では、このコマンドを理解するのは難しくないと思います。
 -d舞台裏
-p ポートマッピング
-v ボリュームマウント
- eEnvironment 構成
--名前

次に、接続されているかどうかをテストしてみましょう。

成功したことがわかります！ Navicat にテーブルを追加して、サーバー上に存在するかどうかを確認しましょう。

このようにして、MySQL コンテナのデータ永続化が完了しました。コンテナを削除しても、データベース内のデータは保持されます。

2. 匿名マウントと名前付きマウント

 匿名マウントや名前付きマウントも簡単に理解できます。匿名とは名前が付けられないことを意味し、名前付きとは特定の名前が付けられることを意味します。
 docker run -d -v / usr / share / nginx / html -p 8080 : 80 --name nginx01 nginx ( 名前は指定されず、匿名マウントの場合はコンテナ内のパスのみが書き込まれます)
 docker run -d -v Aasee : / usr/ share / nginx / html -p 8080 : 80 --name nginx02 nginx (コンテナ内の指定された名前とパスはマウント名です)
 docker run -d -v ホストパス: コンテナパス-p 8080 : 80 --name nginx -volume nginx ( ホストの指定されたディレクトリに直接マウントします)

一つずつ紹介しましょう。ここでは、ポート 8080 で実行しているため、-P を使用してポートをランダムに指定します。

匿名

docker volume ls を使用してデータボリュームリストを表示し、docker inspect [volumename] を使用してボリューム情報を表示できます。

詳細な使用パラメータについては、--help を参照してください。

 docker コンテナ ID を検査する

名前

 docker コンテナ ID ビューの検査

もう1つだけ付け加えておきます。

この写真を見れば簡単に理解できます。通常は名前でマウントすることをお勧めします。

 読み取り専用に設定: docker run -d -v ホストディレクトリアドレス: / usr / share / nginx / html : ro -p 8080 : 80 -- name
 nginx - 音楽- ボリュームnginx

3. データボリュームコンテナ

コンテナがホストと通信できるのと同様に、コンテナ同士も通信できます。親コンテナはデータボリュームコンテナです。コンテナとホストがデータボリュームを通じてファイルを共有できることはすでにわかっているので、当然コンテナもデータボリュームを通じてファイルを共有できます。

 -- volumes - コンテナ間でデータを共有するためのコマンド。
 docker run -it --name 子コンテナ名--volumes - from 親コンテナ名イメージ名/ bin / bash

ここではデモンストレーションに nginx を使用します。まず、データボリュームを親コンテナとしてコンテナを起動します。 docker01と呼ぶことにします

 docker run -d --name docker01 -P -v volume01 : / home / volume01 nginx

最初のコンテナの準備ができました。2 番目のコンテナを作成しましょう。

 docker run -it --name docker02 --volumes - from docker01 nginx / bin / bash

ホームディレクトリに移動して、volume01 フォルダーがすでに存在するかどうかを確認できます。

ここで新しいファイルを作成し、helloDocker.py をタッチして、docker01 に移動して共有されているかどうかを確認します。

成功したことがわかります。

Dockerファイル

DockerFile: イメージの生成方法と必要なファイルおよびその他の構成を定義するビルドファイル。
DockerImages: DockerFile を通じてレイヤーごとに生成される最終イメージ。最終的にリリースされ稼働している製品
DockerContainer: コンテナはイメージ上で実行されるサービスであり、書き込み可能なレイヤーでもあります。

以下は、私が見つけた、よく使用される Docker コマンドの 2 つの簡単な図です。コマンドの詳しい紹介をじっくりご覧いただけます。

ENTRYPOINT と CMD の機能説明はほぼ同じですが、それでも違いがあることがわかります。 CMD コマンドは最後のコマンドを実行し、ENTRYPOINT コマンドが追加されます。

そこで、ここでは DockerFile を記述してそれらの違いを説明します。

 [ root @ VM - 0 - 3 - centos ~ ]# cd dockerFile /
 [ root @ VM - 0 - 3 - centos dockerFile ]# vim docker - test - cmd
 [ root @ VM - 0 - 3 - centos dockerFile ]# cat docker - test - cmd
 Centos より
コマンド[ "ls" , "-a" ]

このようにして、非常にシンプルな dockerfile を作成しました。つまり、このイメージを実行すると、自動的に ls -a が実行されます。次に、ビルドコマンドを使用してイメージを作成します。

 docker build -f docker - test - cmd -t test01 - cmd 。

これで作成できました。実行して試してみてください。

ここで、実行コマンドの後に -l を追加します。理論的には、-l を追加すると、実行時にこのイメージによって実行されるコマンドは ls -a -l になるはずですよね?試してみましょう。

エラーが報告されていることがわかります。これはなぜでしょうか?前述のように、CMD コマンドは最後の項目のみを実行するため、実行時にコマンド -l を追加すると、実際のイメージの実行時に実行されるコマンド -l が ls -a に置き換わり、centos は -l の意味を認識できなくなります。 ENTRYPOINT を追加できます。この場合、エントリポイントはコマンド ls -a -l を実行できます。ここでは説明しません。

Tomcatイメージを作成する

まず、いくつかのインストールパッケージを準備する必要があります。公式サイト、jdk ダウンロード、tomcat ダウンロードで検索できます。

ダウンロード後、xftp を使用してアップロードするだけです。

次に、Dockerfile ファイルを書きます。

 centos から: centos7
 メンテナーAasee < [email protected] >
 readme.txt / usr / local / readme.txt をコピーする
#圧縮されたパッケージをインポートすると自動的に解凍されます
Apache - Tomcat - 9.0.63.tar.gz / usr / local / を追加します
jdk - 8u333 - linux - x64.tar.gz / usr / local / を追加します
#vimをインストールする
yum -y install vim を実行します。
 #作業ディレクトリを設定する
ENV MYPATH / usr / ローカル
ワークディレクトリ$MYPATH
 #jdk 環境設定
ENV JAVA_HOME / usr / local / jdk1.8.0_333
 ENV CLASSPATH $JAVA_HOME / lib / dt.jar : $ JAVA_HOME / lib / tools.jar
 #tomcat 環境設定
ENV CATALINA_HOME / usr / local / apache - tomcat - 9.0.63
 ENV CATALINA_BASH /usr/local/apache-tomcat-9.0.63
 #パス環境を構成する
環境変数 PATH $PATH : $JAVA_HOME / bin : $CATALINA_HOME / lib : $CATALINA_HOME / bin
 #ポートを公開する
エクスポーズ8080
 #Tomcatを起動してログを出力する
CMD /usr/local/apache-tomcat-9.0.63/bin/startup.sh && tail -F /usr/local/apache-tomcat-9.0.63/logs/catalina.out

公式に推奨されている名前である Dockerfile と名付けました。したがって、ファイルを指定するために -f を使用する必要はありません。 docker buildで直接作成できます
docker build -t 名前。

次に実行します

docker run -d -p 9090:8080 --name aaseetomcat -v /root/dockerFile/tomcat/test:/usr/local/apache-tomcat-9.0.63/webapps/test -v /root/dockerFile/tomcat/tomcatlogs/:/usr/local/apache-tomcat-9.0.63/logs aasee-tomcat01 を実行します。
これは私のコマンドであり、必要に応じて変更できます。これを読めば、ほとんどのコマンドは誰でも理解できると思います。

正常に実行され、マウントされていることがわかります。詳しくはページをご覧ください。

ログも閲覧可能です。

次に、docker inspect container id を使用して、ボリュームデータが正常にバインドされているかどうかを確認します。

tomcatlogs 内のディレクトリが正常にマウントされているかどうかを確認しましょう。

成功したことがわかります。

次に、彼が試すためのカスタム Web ページを作成します。 webapps/test をボリューム経由でマウントしているため、ホストマシンのテストディレクトリで直接変更を加えることができます。同時に、2 つのディレクトリが正常にマウントされているかどうかを逆に確認することもできます。

ウェブ

 < ? xml バージョン= "1.0" エンコーディング= "UTF-8" ? >
 < ウェブアプリxmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance "
 xmlns = "http://java.sun.com/xml/ns/javaee"
 xsi : スキーマの場所= "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
 バージョン= "3.0" >
 </web-app>

インデックス

 < ! DOCTYPE html >
 <html>  
 < ヘッド>
 < メタ文字セット= "utf-8" >
 <title> こんにちは世界</title>
 </head>
 < 本体の背景色= "F6F3D6" >
 <!-- HTML で世界に挨拶しましょう! -->
 < h1 align = "center" > こんにちは世界< / / /h1>
 < p align = "center" > Aasee - Docker < / /p>
 </body>
 </html>

次に、ページの効果を見てみましょう。

わかりました。

リポジトリにプッシュする

画像を作成した後、それを他の人に使用してもらうにはどうすればよいでしょうか?方法は2つあります。 1つはローカルでパッケージ化して他の人に送信すること、もう1つは公式のDockerリポジトリや、Alibaba CloudやTencent Cloudなどの大手企業の公式リポジトリにアップロードすることです。ただし、公式のDockerリポジトリノードは海外にあるため、速度は良いときもあれば悪いときもあり、操作も同様です。ここでは Alibaba Cloud を例に挙げます (Tencent Cloud でも同様の操作が行われます)。

まず、Alibaba Cloudにログインします。

コンテナイメージサービスを直接検索します。個人的なテストでは、個人バージョンを使用できます。次に、プロンプトに従ってコマンドスペースを作成し、イメージリポジトリを作成します。ローカルリポジトリを選択すると、プッシュチュートリアルが表示されます。

これらの内容は、ご自身で読んでみてください。正式な命令は非常に詳細です。公式コマンドに従って、イメージを公式ウェアハウスに簡単にプッシュできます。