記事ディレクトリ
1. 環境の準備
dockerがインストールされているか確認する
[root@localhost /]# docker -v
Docker version 1.13.1, build 7d71120/1.13.1
[root@localhost /]# systemctl status docker #查看docker Engine 的状态
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since 六 2023-07-29 22:49:00 CST; 7h ago
Docs: http://docs.docker.com
Main PID: 967 (dockerd-current)
Tasks: 155
Memory: 285.3M
CGroup: /system.slice/docker.service
............
1.使用するjarパッケージプロジェクトを準備する
/opt/ ディレクトリの下に docker ディレクトリを作成します:
Idea の Maven によってパッケージ化された実行可能プロジェクトの jar パッケージをサーバーの /opt/docker ディレクトリにアップロードします。プロジェクトの
yml 構成ファイルのサービス ポートは 8096 です。
2. 対応する Dockerfile を作成します
ビルド プロジェクト イメージを記述するために使用されるファイル名は、サフィックスのない Dockerfile である必要があり、ファイル名を任意に付けることはできません。それ以外の場合は、ビルド時に Dockerfile が見つからないというメッセージが表示されます。
# 基础镜像，也叫父镜像，因为jar的运行依赖于JDK或Jre,这里使用只拥有运行环境的Jre，减少最终生成的镜像的大小。
FROM openjdk:8u212-jre
# 维护者
MAINTAINER ssccxx
# 在宿主机的 /var/lib/docker目录下的volumes目录里会创建一个临时文件随机名称的目录将这个目录下的_data 链接到容器内的 /tmp
VOLUME /tmp #会自动在容器内的根目录下生成此tmp目录
# 将项目的jar添加到镜像中，并修改名称为myapp.jar，这里默认添加到容器的根目录下(即默认的工作目录)。
ADD platform-customer-post.jar myapp.jar
# 在构建镜像时会执行RUN 命令 ，这里的 touch /myapp.jar 不起作用，因为上方的ADD里已经使根目录下有同名的文件。这里的touch就不会再生效了。
RUN bash -c 'touch /myapp.jar'
# ENTRYPOINT 是 在容器运行时自动执行的命令，也就是启动容器内的项目服务
ENTRYPOINT ["java","-jar","/myapp.jar"]
# 声明, 此容器内的服务监听端口应该为8096，这里的EXPOSE只是声明，方便之后的维护者一目了然可以知道容器内的服务的监听端口。
EXPOSE 8096
注: 上記の Dockerfile の命令にある FROM、ADD、および RUN はすべて、イメージのビルド時に実行されます。そして、ENTRYPOINT、VOLUME、EXPOSEは
コンテナの実行中に実行されます。
3. 鏡像を構築する
[root@localhost docker]# ll
总用量 79156
-rw-r--r-- 1 root root 178 7月 30 01:36 Dockerfile
-rw-r--r-- 1 root root 81049868 7月 29 23:02 platform-customer-post.jar
[root@localhost docker]# docker build --no-cache -t micro-server:v1.0 .
说明:build はビルド コマンド -t です。repository:tag (つまり、ウェアハウス名:tag タグ。これら 2 つはミラー イメージを決定できるため) を指定する必要があります。
repository name must be lowercase: カスタム ウェアハウス名に大文字が含まれている場合は、プロンプトが表示されます。すべて小文字に変更します。
--no-cache: 以前のビルドに存在したイメージ キャッシュがビルド時に使用されないことを示します。通常、これは追加されます。追加しないと、Docker エンジン キャッシュ内のビルドされたイメージを使用することができ、
イメージ ID の重複や競合が発生します。
現在の /opt/docker ディレクトリに名前付き Dockerfile がない場合。Dockerfile ファイルが見つからないというメッセージが表示されます。
重点最後の . はコンテキスト パスを示します。これは、docker build コマンドが実行される現在の場所 (opt/docker ディレクトリ) です。
docker の実行モードが C/S であるためです。ローカル マシンは C (クライアント)、Docker エンジンは S (サーバー) です。Docker は 1 つのマシン上に存在し、Docker エンジン、つまり
対応するサーバーは別のマシン上に存在する場合があります。Docker クライアントの CLI コマンドを介して Docker エンジンにビルド情報を送信します。実際のビルド プロセスは
Docker エンジンの下で完了するため、現時点ではローカル ファイルを使用できません (たとえば、次の場合にプラットフォームを使用する必要があります)。ここでビルドします。-customer-post.jar ファイル)。
これには、ローカル マシンの指定されたディレクトリ内のファイルをパッケージ化し、Docker エンジンに提供して使用する必要があります。現在使用している仮想マシンのデモ環境は、C/S がすべて同じマシン上にあります
。しかし、このプロセスを経る必要があります。/opt/docker/ ディレクトリ内のコンテンツはパッケージ化され、使用するためにエンジンに送信されるため、Docker エンジンは ADD コマンドを実行するときにコピーする必要があります。
platform-customer-post.jar をイメージに追加すると、パッケージ化されたコンテンツから見つけることができます。すべてのビルドが完了し、最終イメージが生成されると、Docker エンジンはパッケージ化されて送信されたコンテンツを自動的にクリーンアップします
。
注意注: 不要なファイルはまとめてパッケージ化されて Docker エンジンに送信されるため、コンテキスト パスに不要なファイルを置かないでください。ファイルが多すぎると処理が遅くなります。
如果：构建时使用: docker build . --no-cache=true 命令 ，没有指定 生成的镜像的 repository:tag ，会产生悬虚镜像。
<none>一時停止ミラーイメージ:リポジトリとタグの両方のミラーイメージであり、
実質的な意味はありません。ディスク領域を解放するために削除できます
[root@localhost docker]# docker images -f dangling=true #查询出全部的本地悬虚镜像
[root@localhost docker]# docker image prune #删除所有悬虚镜像
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y #键入y表示删除所有悬虚镜
docker イメージを使用して、ビルドされたイメージが存在するかどうかを確認します。
4. イメージを実行します
イメージからコンテナインスタンスを生成する
- docker create --name コンテナインスタンス名 -p host port: コンテナ内のサービスのポートイメージ ID
说明: docker create コマンドは、指定されたイメージ ID に対応するイメージを使用してコンテナを作成しますが、コンテナ インスタンス:docker ps -aすべてのコンテナ (実行中、
停止したコンテナを含む) を表示し、docker start コンテナ ID またはコンテナ名とともに使用します。 - docker run -d --name コンテナインスタンス名 -p ホストポート: コンテナ内のサービスのポート ミラー ID
说明: docker run コマンドは、指定されたイメージ ID に対応するイメージに基づいてコンテナを作成し、生成されたコンテナを実行しますインスタンスを直接実行します。-d はコンテナをバックグラウンドで実行することを意味します。それ以外の場合は、
コンテンツをコンソールに出力します。
说明: –name コンテナー名を指定しないでください。システムはコンテナー名 (形容詞とアンダースコアを付けた名前) を自動的に生成します。--name 属性の配置に注意してください。
说明: docker start コマンド。既存のコンテナにのみ使用でき、コンテナの作成や起動には使用できません。
推荐 使用 docker run 这个命令。docker create を使用するときにホスト ポートがすでに占有されているかどうかを確認する際に問題があるため、実行時にのみ確認されます。
[root@localhost _data]# docker run -d --name xiaohai -p 8090:8096 79bcb7a73dd2
fdb21e089157e0080ecf26585f5ac174f3e56c056f4d341d838387d048debc5e #执行成功后，会返回容器实例id的完整部分。
[root@localhost _data]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fdb21e089157 79bcb7a73dd2 "java -jar /myapp.jar" 2 seconds ago Up 2 seconds 0.0.0.0:8090->8096/tcp xiaohai
说明:
CONTAINER ID: コンテナインスタンス ID
IMAGE: ミラー ID
COMMAND: コンテナの起動時にコンテナ内で自動的に実行されるコマンド
CREATED: コンテナが作成されてから現在までの過去の時間
PORTS: ホストからコンテナへのマッピングとプロトコルを示します。コンテナ内のアプリケーション ポート
NAMES: コンテナ インスタンス名
同じイメージによると、同じホスト上に複数のコンテナ インスタンスを作成できます。コンテナはコンテナから直接分離されており、同じサービス ポートが競合することはありません。ホスト上のポートが一貫していないことを確認してください。外部的には、ホスト ip:host ポート/アプリケーション サービス インターフェイスをリクエストすることにより、ポート マッピング関係に従って、対応するコンテナ内のサービスに転送されます。
5. サービスが正常かどうかをテストする
[root@localhost _data]#curl http://localhost:8090/v3/api/client/v1/captchaImage
コンテナー ログを確認します。
docker logs -f コンテナー ID を実行すると、
リクエストが受信されたことがわかり、コンテナー内のサービスが正常であることがわかります。
说明：コンテナーの起動に失敗した場合、またはサービスが正常であるかどうかは、 docker logs -f コンテナー ID を使用して対応するログを表示できます。
6. ポートの説明
1. アプリケーション サービス構成ファイル内のホスト ポート、EXPOSE ポート、およびサービス ポート。この３人の関係性。
まず、Dockerfile 構成ファイルで宣言されている EXPOSE ポートについて説明します。実際、これは後でこの構成ファイルを保守する人のためのものです。EXPOSE ポートが実行されると、
ポートは実際には監視されません。これは、アプリケーション サービスがリッスンするポートがこれであることを意味します。特定のコンテナ アプリケーション サービス ポートは、コンテナ内のサービスが開始されるときのポート (つまり、アプリケーション サービス構成ファイル内のサービス ポート) です。Dockerfile に EXPOSE ポートを書き込まなくても、まったく効果がありません。後で他の担当者がメンテナンスするのが不便です。
一般に、EXPOSE ポートは、アプリケーション サービス構成ファイルのサービス ポートと一致している必要があります。これにより、他の担当者は、将来 Dockerfile を読み取ることでコンテナ内のアプリケーション サービスのポート番号を知ることができます
。
2. ポートマッピングの説明。-p ホスト ポート: コンテナ アプリケーション サービス ポート (アプリケーション サービス構成ファイル内のサービス ポート)。
このポート マッピングが構成されていない場合はどうなりますか。その影響は、コンテナ内のサービスにアクセスする方法が 2 つしかないことです。1. ホスト マシンで、
コンテナ IP: コンテナ内のアプリケーション サービスのポートを介してアクセスします。2. コンテナに入り、コンテナ IP またはローカルホスト (コンテナ内のアプリケーション サービスのポート) を介してアクセスします。
このポート マッピングが構成されている場合、どのような利点がありますか。利点は、localhost またはホストの ip:host ポートを介してホスト上でアクセスできることです。外部マシンのホスト ip:host ポートにアクセスすることで、コンテナ内のアプリケーション サービスに間接的にアクセスすることもできます
。つまり、外部ネットワークがコンテナ内のサービスにアクセスするのに便利です。
说明: ここで言うホスト マシンとは、コンテナを実行しているノード マシンを指します。このノード マシンは、VMware を通じてインストールされた仮想マシンまたはその他の物理マシンです。
ここでのデモンストレーション環境は、物理マシンが VMware Station がインストールされた Windows システム マシンと、VMware Station を通じてインストールされた仮想マシンです。コンテナーはこの仮想
マシン上で実行されます。前述のコンテナ ホストはこの仮想マシンです。私の物理マシンではありません。
7. コンテナに入る
[root@localhost _data]# docker exec -it fdb21e089157 /bin/bash #-it后 是容器实例id /bin/bash指的是进入容器后，打开一个bash终端 #构建镜像时没有指定工作目录，则默认进入容器后的目录为容器内的根目录
root@fdb21e089157:/# ls
bin boot dev etc home lib lib64 media mnt myapp.jar opt proc root run sbin srv sys tmp usr var
#可以看到myapp.jar包就在容器的根目录下，包括挂载点 tmp目录
#查看容器的java环境，可以看到java版本已经 java的安装目录
root@fdb21e089157:/# java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
root@fdb21e089157:/# which java
/usr/local/openjdk-8/bin/java
#也就是我们这个容器内已经有个可执行文件jar包的运行环境了。
root@fdb21e089157:/usr/local/openjdk-8/bin# pwd
/usr/local/openjdk-8/bin
root@fdb21e089157:/usr/local/openjdk-8/bin# ls
clhsdb hsdb java jjs keytool orbd pack200 policytool rmid rmiregistry servertool tnameserv unpack200
#可以看到bin目录下只有java命令，没有 javac，jps等命令。因为我们用的基础镜像为openjdk:8u212-jre。所以么有java的编译等命令。只有运行的命令。而且java 命令也已经是容器内的环境变量了。在容器内的任意目录下都可以执行。所以在容器启动后，在容器内的根目录下 自动执行java -jar xxxx.jar 指令是没有问题的。所以宿主机不需要安装java环境。容器内已经拥有了自己的java环境了。
#容器就像一个精简版的centos或ubuntu,里面只有极少的命令如ls,df，du , 没有ll，vim，netstat,yum等命令。
root@fdb21e089157:/# du -h myapp.jar #可以用这个du -h 文件名 查看文件的大小
78M myapp.jar
8. コンテナを操作するための共通コマンド
1. docker start 容器id #启动已停止的容器
2. docker stop 容器id #停止正在运行的容器
3. docker exec -it 容器id -- bin/bash #进入容器内，注意只有当容器是运行时此命令才有效
4. docker ps #查看正在运行的容器
5. docker ps -a #查看本机所有的容器，包含已停止运行的容器
6. docker logs -f 容器id #查看容器运行及内部服务查看的日志，若容器已被删除，这里的日志也就查不到了，会被跟着容器自动被删除。
7. docker inspect 容器id #查看容器内部组织结构信息，包括容器内的挂载点信息，容器的ip地址信息
8. docker rm 容器id #删除已停止的指定的容器
9. docker rm -f 容器id #删除容器（包括正在运行的容器）
10. docker rm -f $(docker ps -a -q) # 删除所有容器，包括正在运行的容器,所有删除操作 因此，在执行该命令之前，请确保您的所有数据已经保存