docker pull registry
Docker エンジンのターミナル設定で
vim /etc/docker/daemon.json
{
"insecure-registries": ["ip网址:5000"],   添加
"registry-mirrors": ["https://05vz3np5.mirror.aliyuncs.com"]
}

systemctl restart docker.service

docker create -it registry /bin/bash

docker ps -a
異常だろう
docker start 
ホストの /data/registry は、マウントコンテナーに /tmp/registry を自動的に作成します。
docker run -d -p 5000:5000 -v /data/registry:/tmp/registry registry
ip url としてマークされた変更: 5000/nginx
docker tag nginx:latest ip网址:5000/nginx
アップロード
docker push ip网址:5000/nginx

The push refers to repository [ip网址:5000/nginx]
プライベートリポジトリのリストを取得する

レジストリのミラーウェアハウスでミラー情報を取得する
curl -XGET http://ip网址:5000/v2/_catalog
プライベートリポジトリのダウンロードをテストする
docker pull ip网址:5000/nginx

2. cgroupのリソース割り当て方法

Docker は cgroup を使用してリソースを制御します
 respones
    request
Docker は Cgroup を使用して、コンテナが使用する CPU、メモリ、ディスクなどのリソースクォータを制御します。これは基本的に、一般的なリソースクォータと使用制御をカバーします。

cgroup は Control Groups の略で、プロセスグループによって使用される物理リソース (CPU、メモリ、ディスク IO など) を制限、記録、および分離するために Linux カーネルによって提供されるメカニズムです。

2007 年、Google はリソース割り当てを制御できるようになりました.オペレーティングシステムカーネルを通じて、アプリケーションのメモリリソース、CPU リソース、ファイルシステムリソースなどの使用を制御します
.cgroup は、リソース制御方法
であり、コンテナ分離の 6 つの名前空間を実現する手段です.

各コンテナはプロセスに相当します

3.CPU使用率の制御

CPU サイクル: 1 秒は 1 サイクルの法則であり、パラメーター値は通常 100000 (CPU 測定単位は秒) です。

このコンテナーに CPU 使用率の 20% を割り当てる必要がある場合、パラメーターを 20000 に設定する必要があります。これは、サイクルごとにこのコンテナーに割り当てられる 0.2 秒に相当します。

CPU は、一度に 1 つのプロセスだけが占有できます。

ストレスツールを使用して CPU とメモリをテストする

Dockerfile を使用して、Centos ベースのストレスツールイメージを作成します。
mkdir /opt/stress

vim /opt/stress/Dockerfile

FROM centos:7
RUN yum install -y wget
RUN wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
RUN yum install -y stress

cd /opt/stress/

docker build -t centos:stress .
次のコマンドを使用してコンテナーを作成します。コマンドの --cpu-shares パラメーター値は、1 vcpu または何 GHz の CPU リソースを取得できるかを保証するものではなく、弾力的な加重値です。
docker run -itd --cpu-shares 100 centos:stress
デフォルトでは、各 Docker コンテナの CPU シェアは 1024 です。単一のコンテナのシェアは無意味です。コンテナーの CPU 重み付けの効果は、複数のコンテナーを同時に実行している場合にのみ明らかになります。
2 つのコンテナ A と B の CPU シェアはそれぞれ 1000 と 500 です.CPU がタイムスライスを割り当てるとき、コンテナ A はコンテナ B よりも 2 倍の CPU タイムスライスを取得するチャンスがあります.
ただし、割り当ての結果は、その時点でのホストや他のコンテナーの実行状態に依存し、コンテナー A が CPU タイムスライスを取得できるという保証はありません。たとえば、コンテナ A のプロセスが常にアイドル状態の場合、コンテナ B はコンテナ A よりも多くの CPU タイムスライスを取得できます。ホスト上で 1 つのコンテナーしか実行されていないなどの極端なケースでは、その CPU シェアが 50 しかなくても、ホスト全体の CPU リソースを独占できます。

1 つのホストで 1 つのコンテナーと 1 つのアプリケーションのみを実行します (コンテナーも仮想化テクノロジです)
1 つのホストで 1 つのアプリケーションを実行します

cgroup は、コンテナーによって割り当てられたリソースが不足している場合、つまり、コンテナーによって使用されるリソースを制限する必要がある場合にのみ有効になります。したがって、CPU シェアのみに基づいてコンテナに割り当てられた CPU リソースの量を決定することはできません.
リソースの割り当て結果は、同時に実行されている他のコンテナの CPU 割り当てと、コンテナ内のプロセスの実行状況に依存します. .
CPU シェアを使用して、コンテナの CPU 使用率の優先度/重みを設定できます。たとえば、2 つのコンテナを起動して実行し、CPU 使用率を表示できます。
docker run -tid --name cpu512 --cpu-shares 512 centos:stress stress -c 10   
容器产生10个子函数进程


docker exec -it f4953c0d7e76 bash  
进入容器使用top查看cpu使用情况

再开启一个容器做比较
docker run -tid --name cpu1024 --cpu-shares 1024 centos:stress stress -c 10


docker exec -it 5590c57d27b0 bash  //进容器使用top对比两个容器的%CPU，比例是1:2

docker stats 查看资源使用

4.CPUサイクル制限

Docker は --cpu-period と --cpu-quota の 2 つのパラメーターを提供して、コンテナーに割り当てることができる CPU クロックサイクルを制御します。
--cpu-period は、コンテナーの CPU 使用率を再割り当てする頻度を指定するために使用されます。
cd /sys/fs/cgroup/cpu/docker容器ID/cpu.cfs_quota_us
ホストはどのようにリソースを提供し、docker コンテナー内のアプリケーションを制御しますか:
CPU → VCPU → ワークステーション環境 (docker 環境内) でプロセスの形で表現される → docker 表現はコンテナーです → Vcpu はコンテナー内のコンテナーを制御します。プロセスの方法→コンテナー内アプリケーションが必要とするのは、サービスプロセスのサポート → ホストカーネル内の cpu は cgroup によって管理できる (リソースを割り当てることによって) → Linux カーネル内の cgroup はアプリケーションを制御および管理できるドッカーコンテナで。

--cpu-quota は、このサイクルでコンテナーを実行するために使用できる時間を指定するために使用されます。
--cpu-shares とは異なり、この構成では絶対値が指定され、コンテナーの CPU リソースの使用が構成された値を超えることはありません。

cpu-period と cpu-quota の単位はマイクロ秒 (μs) です。cpu-period の最小値は 1000 マイクロ秒、最大値は 1 秒 (10^6 μs)、デフォルト値は 0.1 秒 (100000 μs) です。
cpu-quota の値のデフォルトは -1 で、これは制御なしを意味します。cpu-period および cpu-quota パラメータは、通常、組み合わせて使用されます。redis では、永続的な -1 を表すために使用されます

ttl 先生
-1
lrange 先生 0 -1

コンテナープロセスは、1 秒ごとに 0.2 秒間単一の CPU を使用する必要があります。cpu-period を 100000 (つまり 1 秒) に、cpu-quota を 20000 (0.2 秒) に設定できます。
もちろん、マルチコアの場合、コンテナプロセスが 2 つの CPU を完全に占有できるようにする場合は、cpu-period を 10000 (つまり 0.1 秒) に、cpu-quota を 200000 (0.2 秒) に設定できます。

オプション説明

--put= コンテナーが使用できる使用可能な CPU リソースの量を指定します。たとえば、ホストに 2 つの CPU があり、Cpus = "1.5" を設定すると、コンテナーは最大で 1.5 個の CPU へのアクセスを保証します。これは、-cpu-period = "100000" および --cpu-quota = "150000" を設定することと同じです。Docker 1.13 以降で利用できます。

--CPU期間= --pu-quota- で使用される CPU CFS スケジューラサイクルを指定します。デフォルトは 100000 マイクロ秒で、マイクロ秒単位で表されます。ほとんどのユーザーは、この設定をデフォルトから変更しません。Docker 1.13 以降を使用している場合は、代わりに --cpus を使用してください。

--CPU クォータ = コンテナーに CPU CFS クォータを追加します。--cpu-period ごとにコンテナーへの CPU アクセスを許可するマイクロ秒数。つまり、cpu-quota/cpu-period です。Docker 1.13 以降を使用している場合は、代わりに -cpuS を使用してください。

--cpuset-cpus コンテナーが使用できる特定の CPU またはコアを制限します。複数の CPU がある場合にコンテナーが使用できる、コンマ区切りのリストまたはハイフン区切りの CPU の範囲。最初の CPU の番号は 0 です。有効な値は 0 ～ 3 (1 番目、2 番目、3 番目、4 番目の CPU を使用) または 1,3 (2 番目と 4 番目の CPU を使用) です。

--CPU シェアこのフラグをデフォルトの 1024 より大きい値または小さい値に設定して、コンテナーの重みを増減し、ホストの CPU サイクルの割合を増減してアクセスできるようにします。これは、CPU サイクルが制限されている場合にのみ実行されます。多くの CPU サイクルが使用可能な場合、すべてのコンテナーは可能な限り多くの CPU を使用します。そのため、これはソフト制限です。--cpu-shares は、クラスターモードでのコンテナーのスケジューリングを妨げません。コンテナーの CPU リソースに使用可能な CPU サイクルを優先します。特定の CPU アクセス権を保証または保持するものではありません。
docker run -tid --cpu-period 100000 --cpu-quota 200000 centos:stress

docker exec -it 98d2aaa50019 bash
コンテナーのリソース制限パラメーターを照会する

(1) 指定したコンテナディレクトリ内
cat /sys/fs/cgroup/cpu/docker/容器ID/cpu.cfs_period_us

cat /sys/fs/cgroup/cpu/docker/容器ID/cpu.cfs_quota_us
(2) docker inspect コンテナID/コンテナ名を使用
"CpuPeriod": 
 "CpuQuota": 

5. CPU コア制御

マルチコア CPU を搭載したサーバーの場合、Docker は、 --cpuset-cpus パラメーターを使用して、コンテナーが実行される CPU コアを制御することもできます。
これは、複数の CPU を搭載したサーバーに特に役立ち、ハイパフォーマンスコンピューティングを必要とするコンテナーのパフォーマンスを最適化した構成を可能にします。
docker run -tid --name cpu1 --cpuset-cpus 0-1 centos:stress
上記のコマンドを実行するには、ホストがデュアルコアである必要があります。つまり、作成されたコンテナーは 0 コアと 1 コアしか使用できません。最終的に生成された cgroup の CPU コア構成
cat /sys/fs/cgroup/cpuset/docker/
次の手順では、CPU コアをバインドする目的を達成するために、コンテナー内のプロセスと CPU コアの間のバインド関係を確認できます。
docker exec   taskset -c -p 1    
容器内部第一个进程号pid为1被绑定到指定CPU上运行pid 1's current affinity list: 0,1
コンテナの作成時にパラメータを使用してリソース制限を直接指定する

コンテナ作成後、コンテナのリソース制御に対応するホストの
/sys/fs/cgroup/*ファイルを変更し、リソース割り当てを指定

6. CPU クォータ制御パラメータの混合使用

cpuset-cpus パラメーターを使用して、コンテナー A が CPU コア 0 を使用し、コンテナー B が CPU コア 1 のみを使用するように指定します。
ホストでは、これら 2 つのコンテナーのみが対応する CPU コアを使用し、それぞれがすべてのコアリソースを占有しており、cpu シェアは明らかな影響を与えません。

cpuset-cpus および cpuset-mems パラメーターは、マルチコアおよびマルチメモリノードを備えたサーバーでのみ有効であり、実際の物理構成と一致する必要があります。そうしないと、リソース制御の目的を達成できません。

システムに複数の CPU コアがある場合、簡単にテストできるように、cpuset-cpus パラメーターを使用してコンテナーの CPU コアを設定する必要があります。
ホストシステムを 4 コア CPU に変更
docker run -tid --name cpu3 --cpuset-cpus 1 --cpu-shares 512 centos:stress stress -c 1

docker exec -it 84598dfadd34 bash

exit


top   
按1查看每个核心的占用

docker run -tid --name cpu4 --cpuset-cpus 3 --cpu-shares 1024 centos:stress stress -c 1

docker exec -it  bash
上記の centos:stress の画像には、CPU とメモリの負荷をテストするためのストレスツールがインストールされています。2 つのコンテナーのそれぞれで stress -c 1 コマンドを実行すると、システムにランダムな負荷がかかり、1 つのプロセスが生成されます。このプロセスは、リソースが使い果たされるまで、rand によって生成された乱数の平方根を繰り返し計算します。
ホストの CPU 使用率を観察すると、3 番目のコアの使用率は 100% に近く、プロセスのバッチの CPU 使用率は明らかに 2:1 の使用率になっています。

7.メモリ制限

オペレーティングシステムと同様に、コンテナーで使用できるメモリは、物理メモリとスワップの 2 つの部分で構成されます。
Docker は、次の 2 つのパラメーターセットを使用して、使用されるコンテナーメモリの量を制御します。

-m または --memory: 100M、1024M などのメモリ使用制限を設定します。
--memory-swap: メモリ+スワップの使用制限を設定します。
次のコマンドを実行して、コンテナーが最大 200M のメモリと 300M のスワップを使用できるようにします。
＃スワップと物理メモリのハードリミットを行うだけ
docker run -it -m 200M --memory-swap=300M centos:stress
--vm 1: 1 つのメモリワーカースレッドを開始します。
--vm-bytes 280M: スレッドごとに 280M のメモリを割り当てます。
デフォルトでは、コンテナはホスト上のすべての空きメモリを使用できます。CPU の cgroups 構成と同様に、Docker はコンテナーに対応する cgroup 構成ファイルをディレクトリ /sys/fs/cgroup/memory/docker/<コンテナーのフルロング ID>
に自動的に作成します。

ワーカースレッドによって割り当てられたメモリが 300M を超え、割り当てられたメモリが制限を超えた場合、ストレススレッドはエラーを報告し、コンテナーは終了します。
docker run -it -m 200M --memory-swap=300M progrium/stress --vm 1 --vm-bytes 310M

8. ブロック IO の制限

デフォルトでは、すべてのコンテナがディスクを均等に読み書きできます. --blkio-weight パラメータを設定することで、コンテナブロック IO の優先度を変更できます.
--blkio-weight --cpu-shares と同様に、相対的な重み値を設定します。デフォルトは 500 です。
以下の例では、コンテナー A には、コンテナー B の 2 倍のディスクへの読み取りと書き込みの帯域幅があります。
docker run -it --name container_A --blkio-weight 600 centos:stress

cat /sys/fs/cgroup/blkio/blkio.weight

docker run -it --name container_B --blkio-weight 300 centos:stress

cat /sys/fs/cgroup/blkio/blkio.weight

9、bps、および iops の制限

bps は 1 秒あたりのバイト数で、1 秒あたりに読み書きされるデータの量です。
iops は ios per second で、1 秒あたりの IO の数です。
コンテナーの bps と iops は、次のパラメーターで制御できます。

--device-read-bps、デバイスの読み取り bps を制限します。
--device-write-bps、デバイスへの書き込みの bps を制限します。
--device-read-iops、デバイスの読み取り iops を制限します。
--device-write-iops、デバイスへの書き込み iops を制限します。

コンテナーが /dev/sda に書き込む速度を 5 MB/秒に制限します。
docker run -it --device-write-bps /dev/sda:5MB centos:stress

dd if=/dev/zero of=test bs=1M count=1024 oflag=direct   
可以按ctrl+c中断查看
dd コマンドを使用して、コンテナー内のディスクへの書き込み速度をテストします。コンテナーのファイルシステムはホスト /dev/sda にあるため、コンテナーにファイルを書き込むことは、ホスト /dev/sda に書き込むことと同じです。さらに、oflag=direct は、直接 IO を使用してファイルを書き込むように指定しているため、--device-write-bps が有効になります。

結果は、速度制限が約 5MB/s であることを示しています。比較試験として、制限速度を制限しない場合の結果は以下の通り。
docker run -it centos:stress

dd if=/dev/zero of=test bs=1M count=1024 oflag=direct

10. イメージのビルド時にリソース制限を指定する (docker build)

ビルド引数=[]	イメージ作成用の変数を設定する
CPUシェア	CPU 使用量の設定
CPU期間	CPU CFS サイクルを制限する
CPU クォータ	CPU CFS クォータを制限する
cpuset-cpus	使用する CPU ID を指定します
cpuset-mems	使用するメモリ ID を指定します
コンテンツの信頼を無効にする	検証を無視、デフォルトで有効
-f	使用する Dockerfile パスを指定します
力-rm	ミラーのセットアップ中に中間コンテナーを削除する
隔離	コンテナ分離技術を使用
ラベル=[]	画像が使用するメタデータを設定する
-m	メモリの最大値を設定
メモリースワップ	スワップの最大値をメモリ + スワップに設定します。「-1」は無制限のスワップを意味します
キャッシュなし	イメージを作成するプロセスはキャッシュを使用しません
引く	ミラーの新しいバージョンを更新してみてください
静かな、-q	Quiet モード、成功後にミラー ID のみを出力
RM	イメージが正常に設定されたら、中間コンテナーを削除します
shmサイズ	/dev/shm のサイズを設定します。デフォルト値は 64M です
下降	Ulimit 構成
押しつぶす	Dockerfile のすべての操作を 1 つのレイヤーに圧縮する
タグ、-t	イメージの名前とラベル。通常は name:tag または name の形式です。1 つのビルドでイメージに複数のタグを設定できます。
通信網	デフォルトのデフォルト。ビルド中に RUN 命令のネットワークモードを設定する

1. 資源制約の主な種類

1)CPU 权重shares、quota、cpuset
2)磁盘 BPS、TPS限制，指定使用哪个磁盘、磁盘分区
3)内存 -m -swap 内存、交换分区
大部分做的是上限的限制

2.资源限制的几种方式

1)build 构建镜像时，可以指定该镜像的资源限制
2)run 将镜像跑为容器的时候，可以指定容器的资源限制

3)容器启动之后，可以在宿主机对应容器的目录下。修改资源限制，然后重载
/sys/fs/cgroup/*(cpu、blk、mem）/docker/容器ID/→修改对应的资源限制文件参数就可以

3.资源限制的状态查询

1)docker inspect 镜像ID/容器ID
2)直接查看宿主机对应容器ID资源限制的文件
3)docker stats

cgroup 资源 docker 原理之一，namespaces 6个名称空间

十一、 compose部署

Docker Compose配置常用字段

字段

描述

build dockerfile context

指定Dockerfile文件名构建镜像上下文路径

image

指定镜像

command

执行命令，覆盖默认命令

container name

指定容器名称，由于容器名称是唯一的如果指定自定

义名称，则无法scale

deploy

指定部署和运行服务相关配置，只能在Swarm模式使用

environment

添加环境变量

networks

加入网络

ports

暴露容器端口，与-p相同，但端口不能低于60

volumes

挂载宿主机路径或命令卷

restart

重启策略，默认no,always,no-failure,unless-stoped

hostname

容器主机名

Docker Compose常用命令

字段

描述

build

重新构建服务

ps

列出容器

up

创建和启动容器

exec

在容器里面执行命令

scale

指定一个服务容器启动数量

top

显示容器进程

logs

查看容器输出

down

删除容器、网络、数据卷和镜像

stop/start/restart

停止/启动/重启服务

环境部署所有主机安装docker环境(内容为docker基础)
yum install docker-ce -y
下载compose
curl -L https://github.com/docker/compose/releases/download/1.21.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

cp -p docker-compose /usr/local/bin/

chmod +x /usr/local/bin/docker-compose

mkdir /root/compose_nginx

tree ./
./
├── docker-compose.yml        创建模板脚本
├── nginx
   ├── Dockerfile             创建容器脚本
   ├── nginx-1.15.9.tar.gz    复制源码包
└── wwwroot
    └── index.html            站点
vim /root/compose_nginx/docker-compose.yml

version: '3'
services:
  nginx:
    hostname: nginx
    build:
      context: ./nginx
      dockerfile: Dockerfile
    ports:
      - 1216:80
      - 1217:443
    networks:
      - cluster
    volumes:
      - ./wwwroot:/usr/local/nginx/html
networks:
  cluster:
docker-compose -f docker-compose.yml up -d
docker 基础操作/常规操作
1)image 容器的管理命令
2)dockerfile
3)docker 网络
4)docker 私有仓库
registry
harbor

docker-compose→资源编排和管理手段（docker swarm)

Harbor 服务

Harbor被部署为多个Docker 容器，因此可以部署在任何支持Docker 的Linux 发行版

上。(registry 为其核心组件)

Harbor比registry相比好处是: harbor 支持多种功能、图形化界面管理、多用户权限、角色管理机制、安全机制。

服务端主机需要安装Python、 Docker 和Docker Compose。(web 环境支持的是PY语言，故需要安装Python)。

1.下载Harbor 安装程序

wget http:// harbor.orientsoft.cn/habor-1.2.2/harborofline-installer-v1.2.2.tgz
tar zxvf harbor oflie-installer-v1.2.2.tgz -C /usr/local/
2.配置Harbor 参数文件
vim /us/local/harbor/harbor.cfg

第五行  hostname = 主机ip
关于Harbor.cfg 配置文件中有两类参数:所需参数和可选参数

(1)参数

所需参数这些参数需要在配置文件Harbor.cfg 中设置。

如果用户更新它们并运行install.sh 脚本重新安装Harbor,参数将生效。

具体参数

①hostname:用于访问用户界面和reeister 服务。它应该是目标机器的IP 地址或完全限定

的域名(FQDN)。

②ui url _protocol: (http 或https, 默认为http) 用于访问UI和令牌/通知服务的协议。如

果公证处于启用状态，则此参数必须为https。(身份验证时会向Mysql数据库进行比对，

然后授予令牌)

③max_ job_workers: 镜像复制作业线程。

④db_ password: 用于db_ auth的MySQL数据库root用户的密码。

⑤customize_ crt:该属性可设置为打开或关闭，默认打开。打开此属性时，准备脚本创建私钥和根证书，用于生成/验证注册表令牌。

当由外部来源提供密钥和根证书时，将此属性设置为off。

⑥ssl_cert: SSL 证书的路径，仅当协议设置为https 时才应用。

⑦ssl cert_key: SSL 密钥的路径，仅当协议设置为https 时才应用。

⑧secretkey_ path:用于在复制策略中加密或解密远程register 密码的密钥路径。

(2)可选参数

这些参数对于更新是可选的，即用户可以将其保留为默认值,并在启动Harbor 后在Web UI上进行更新。

如果进入Harbor.cfg, 只会在第一次启动 Harbor时生效，随后对这些参数的更新，Harbor.cfg将被忽略。

注意:如果选择通过UI设置这些参数，请确保在启动Harbour后立即执行此操作。具体来

说，必须在注册或在Harbor 中创建任何新用户之前设置所需的auth_mode。当系统中有用户时(除了默认的admin 用户)，auth_mode 不能被修改。具体参数如下:

①Email: Harbor 需要该参数才能向用户发送“密码重置”电子邮件，并且只有在需要该功能

时才需要。

请注意，在默认情况下SSL连接时没有启用。如果SMTP服务器需要SSL,但不支持STARTTLS,那么应该通过设置启用SSLemailssl=TRUE。

②harbour_admin_password: 管理员的初始密码，只在Harbour第-次启动时生效。之后，此

设置将被忽略，并且应UI中设置管理员的密码。

请注意，默认的用户名/密码是admin/Harbor12345 。

③auth mode:使用的认证类型，默认情况下，它是db_auth, 即凭据存储在数据库中。对于

LDAP身份验证(以文件形式验证)，请将其设置为ldap_auth。

④self_registration: 启用/禁用用户注册功能。禁用时，新用户只能由Admin 用户创建，只有

管理员用户可以在Harbour中创建新用户。

注意:当auth_mode设置为ldap_auth时，自注册功能将始终处于禁用状态，并且该标志

被忽略。

⑤Token_ expiration: 由令牌服务创建的令牌的到期时间(分钟)，默认为30分钟。

project_creation. restriction: 用于控制哪些用户有权创建项目的标志。默认情况下，每个人

都可以创建一个项目。

如果将其值设置为“adminonly"，那么只有admin可以创建项目。

⑥verify_remote_cert: 打开或关闭，默认打开。此标志决定了当Harbor与远程register 实例通信时是否验证SSL/TLS 证书。

将此属性设置为off 将绕过SSL/TLS 验证，这在远程实例具有自签名或不可信证书时经常使用。

另外，默认情况下，Harbor 将镜像存储在本地文件系统上。在生产环境中，可以考虑使用其他存储后端而不是本地文件系统，如S3、Openstack Swif、Ceph 等。但需要更新common/templates/egistry/config.yml 文件。

3.启动Harbor
sh /usr/local/harbor/install.sh
打开浏览器输入主机ip即可访问harbor

4.查看Harbor启动镜像

查看镜像
docker images
查看容器
docker ps -a

cd /usr/local/harbor/

docker-compose ps
此时可使用Docker 命令在本地通过127.0.0.1 来登录和推送镜像。默认情况下，

Register服务器在端口80. 上侦听。

登录

docker login -u admin -P Harbor12345 http://127.0.0.1

下载镜像进行测试

docker pull cirros

镜像打标签

docker tag cirros 127.0.0.1/myproject-kgcirros:v1

上传镜像到Harbor

docker push 127.0.0.1/myproject-kgc/cirros:v1

以上操作都是在Harbor 服务器本地操作。如果其他客户端上传镜像到Harbor, 就会报

如下错误。出现这问题的原因Docker Registry 交互默认使用的是HTTPS，但是搭建私有镜

像默认使用的是HTTP 服务，所以与私有镜像交互时出现以下错误。
docker login -u admin -P Harbor12345 http://主机ip

会报错
解决
vim /us/ib/systemd/system/docker.service

ExecStart=/us/bin/dockerd -H fd:// -insecure-registry 主机ip

--containerd=/run/containerd/containerd.sock
systemctl daemon-reload

systemctl restart docker

docker login -u admin -p Harbor12345 http://主机ip

十二、 consul部署

consul 注册中心/注册机

服务器nginx： Nginx 、Consul、 Consul-template
服务器docker： Docker-ce、registrator（自动发现、注册的组件）

template 模板（更新）
registrator（自动发现）
后端每构建出一个容器，会向registrator进行注册，控制consul 完成更新操作，consul会触发consul template模板进行热更新。
核心机制：consul ：自动发现、自动更新，为容器提供服务（添加、删除、生命周期辅助功能）。

1.consul服务器
mkdir /root/consul

cp consul_0.9.2_linux_amd64.zip /root/consul

cd /root/consul

unzip consul_0.9.2_linux_amd64.zip

mv consul /usr/bin


consul agent \
-server \		                  server模式
-bootstrap \	                  前端框架（node.js）
-ui \		                      可被访问的web界面
-data-dir=/var/lib/consul-data \
-bind= \
-client=0.0.0.0 \
-node=consul-server01 &> /var/log/consul.log &

consul agent \
-server \
-bootstrap \
-ui \
-data-dir=/var/lib/consul-data \
-bind= \
-client=0.0.0.0 \
-node=consul-server01 &> /var/log/consul.log &
2.通过httpd api 获取集群信息
curl 127.0.0.1:8500/v1/status/peers        看集群server成员
curl 127.0.0.1:8500/v1/status/leader       集群 Raf leader
curl 127.0.0.1:8500/v1/catalog/services    注册的所有服务
curl 127.0.0.1:8500/v1/catalog/nginx       查看 nginx 服务信息
curl 127.0.0.1:8500/v1/catalog/nodes       集群节点详细信息
3.容器服务自动加入consul集群

(1)安装 Gliderlabs/Registrator

可检查容器运行状态自动注册，还可注销 docker 容器的服务到服务配置中心。
目前支持 Consul、Etcd 和 SkyDNS2。
执行操作：
docker run -d \
--name=registrator \
--net=host \
-v /var/run/docker.sock:/tmp/docker.sock \
--restart=always \
gliderlabs/registrator:latest \
-ip=ip网址 \
consul://ip网址:8500
(2)测试服务发现功能是否正常
docker run -itd -p:83:80 --name test-01 -h test01 nginx
docker run -itd -p:84:80 --name test-02 -h test02 nginx
docker run -itd -p:88:80 --name test-03 -h test03 httpd
docker run -itd -p:89:80 --name test-04 -h test04 httpd
(3)验证 http 和 nginx 服务是否注册到 consul

浏览器输入 http://ip网址:8500，“单击 NODES”，然后单击 “consurl-server01”，会出现 5 个服务.

在consul服务器上查看服务
curl 127.0.0.1:8500/v1/catalog/services
(4)安装 consul-template

Consul-Template 是一个守护进程，用于实时查询 Consul 集群信息，并更新文件系统上任意数量的指定模板，生成配置文件。更新完成以后，可以选择运行 shell 命令执行更新操作，重新加载 Nginx。Consul-Template ，可以查询 Consul 中的服务目录、Key、Key-values 等。
这种强大的抽象功能和查询语言模板可以使 Consul-Template 特别适合动态的创建配置文件。
创建 Apache/Nginx Proxy Balancers、Haproxy Backends

(5)准备 template nginx 模板文件

在consul上操作
vim /root/consul/nginx.ctmpl

upstream http_backend {
  {
    
    {range service "nginx"}}
   server {
    
    {.Address}}:{
    
    {.Port}};    此处引用的变量会指向后端的地址和端口（动态变化）
   {
    
    {end}}
}

server {
  listen 85;
  server_name localhost ip网址;         反向代理的IP地址(前端展示的NG服务的IP)
  access_log /var/log/nginx/kgc.cn-access.log;
  index index.html index.php;
  location / {
    proxy_set_header HOST $host;
    proxy_set_header X-Real-IP $remote_addr;         后端真实IP
    proxy_set_header Client-IP $remote_addr;    
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     转发地址
    proxy_pass http://http_backend;
  }
}
(6)编译安装nginx
yum install gcc pcre-devel zlib-devel -y

tar zxvf nginx-1.12.0.tar.gz  -C /opt

./configure --prefix=/usr/local/nginx

make && make install

ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin
(7)配置 nginx
vim /usr/local/nginx/conf/nginx.conf


http {
     include       mime.types;        默认存在的
     include  vhost/*.conf;           添加虚拟主机目录（consul动态生成的配置文件就会放在这里）
     default_type  application/octet-stream;
创建虚拟主机目录
mkdir /usr/local/nginx/conf/vhost
创建日志文件目录
mkdir /var/log/nginx
启动nginx
usr/local/nginx/sbin/nginx
(8)配置并启动 template
cp consul-template_0.19.3_linux_amd64.zip /root/

unzip consul-template_0.19.3_linux_amd64.zip

mv consul-template /usr/bin/
关联nginx 虚拟目录中的子配置文件操作
consul-template -consul-addr 192.168.226.130:8500 \
-template "/opt/consul/nginx.ctmpl:/usr/local/nginx/conf/vhost/benet.conf:/usr/local/nginx/sbin/nginx -s reload" \
--log-level=info
另外打开一个终端查看生成配置文件
cat /usr/local/nginx/conf/vhost/kgc.conf 
upstream http_backend {
  
   server ip网址:83;
   
   server iP网址:84;
   
}

server {
  listen 83;
  server_name localhost ip网址;
  access_log /var/log/nginx/kgc.cn-access.log;
  index index.html index.php;
  location / {
    proxy_set_header HOST $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Client-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://http_backend;
  }
}
4.增加一个nginx容器节点

增加一个 nginx 容器节点，测试服务发现及配置更新功能
在registrator服务端注册
docker run -itd -p 85:80 --name test-05 -h test05 nginx
查看三台nginx容器日志，请求正常轮询到各个容器节点上
docker logs -f test-01
docker logs -f test-02
docker logs -f test-05

Docker リソースの制限と構成

まずは専用倉庫の開設

2. cgroupのリソース割り当て方法

3.CPU使用率の制御

ストレスツールを使用して CPU とメモリをテストする

4.CPUサイクル制限

コンテナーのリソース制限パラメーターを照会する

(1) 指定したコンテナディレクトリ内

(2) docker inspect コンテナID/コンテナ名を使用

5. CPU コア制御

6. CPU クォータ制御パラメータの混合使用

7.メモリ制限

8. ブロック IO の制限

9、bps、および iops の制限

10. イメージのビルド時にリソース制限を指定する (docker build)

1. 資源制約の主な種類

2.资源限制的几种方式

3.资源限制的状态查询

十一、 compose部署

Harbor 服务

1.下载Harbor 安装程序

2.配置Harbor 参数文件

(1)参数

(2)可选参数

3.启动Harbor

4.查看Harbor启动镜像

十二、 consul部署

1.consul服务器

2.通过httpd api 获取集群信息

3.容器服务自动加入consul集群

(1)安装 Gliderlabs/Registrator

(2)测试服务发现功能是否正常

(3)验证 http 和 nginx 服务是否注册到 consul

(4)安装 consul-template

(5)准备 template nginx 模板文件

(6)编译安装nginx

(7)配置 nginx

4.增加一个nginx容器节点

おすすめ

オプション	説明
--put=	コンテナーが使用できる使用可能な CPU リソースの量を指定します。たとえば、ホストに 2 つの CPU があり、Cpus = "1.5" を設定すると、コンテナーは最大で 1.5 個の CPU へのアクセスを保証します。これは、-cpu-period = "100000" および --cpu-quota = "150000" を設定することと同じです。Docker 1.13 以降で利用できます。
--CPU期間=	--pu-quota- で使用される CPU CFS スケジューラサイクルを指定します。デフォルトは 100000 マイクロ秒で、マイクロ秒単位で表されます。ほとんどのユーザーは、この設定をデフォルトから変更しません。Docker 1.13 以降を使用している場合は、代わりに --cpus を使用してください。
--CPU クォータ =	コンテナーに CPU CFS クォータを追加します。--cpu-period ごとにコンテナーへの CPU アクセスを許可するマイクロ秒数。つまり、cpu-quota/cpu-period です。Docker 1.13 以降を使用している場合は、代わりに -cpuS を使用してください。
--cpuset-cpus	コンテナーが使用できる特定の CPU またはコアを制限します。複数の CPU がある場合にコンテナーが使用できる、コンマ区切りのリストまたはハイフン区切りの CPU の範囲。最初の CPU の番号は 0 です。有効な値は 0 ～ 3 (1 番目、2 番目、3 番目、4 番目の CPU を使用) または 1,3 (2 番目と 4 番目の CPU を使用) です。
--CPU シェア	このフラグをデフォルトの 1024 より大きい値または小さい値に設定して、コンテナーの重みを増減し、ホストの CPU サイクルの割合を増減してアクセスできるようにします。これは、CPU サイクルが制限されている場合にのみ実行されます。多くの CPU サイクルが使用可能な場合、すべてのコンテナーは可能な限り多くの CPU を使用します。そのため、これはソフト制限です。--cpu-shares は、クラスターモードでのコンテナーのスケジューリングを妨げません。コンテナーの CPU リソースに使用可能な CPU サイクルを優先します。特定の CPU アクセス権を保証または保持するものではありません。

字段	描述
build dockerfile context	指定Dockerfile文件名构建镜像上下文路径
image	指定镜像
command	执行命令，覆盖默认命令
container name	指定容器名称，由于容器名称是唯一的如果指定自定义名称，则无法scale
deploy	指定部署和运行服务相关配置，只能在Swarm模式使用
environment	添加环境变量
networks	加入网络
ports	暴露容器端口，与-p相同，但端口不能低于60
volumes	挂载宿主机路径或命令卷
restart	重启策略，默认no,always,no-failure,unless-stoped
hostname	容器主机名

字段	描述
build	重新构建服务
ps	列出容器
up	创建和启动容器
exec	在容器里面执行命令
scale	指定一个服务容器启动数量
top	显示容器进程
logs	查看容器输出
down	删除容器、网络、数据卷和镜像
stop/start/restart	停止/启动/重启服务

Docker リソースの制限と構成

まずは専用倉庫の開設

2. cgroupのリソース割り当て方法

3.CPU使用率の制御

ストレス ツールを使用して CPU とメモリをテストする

4.CPUサイクル制限

コンテナーのリソース制限パラメーターを照会する

(1) 指定したコンテナディレクトリ内

(2) docker inspect コンテナID/コンテナ名を使用

5. CPU コア制御

6. CPU クォータ制御パラメータの混合使用

7.メモリ制限

8. ブロック IO の制限

9、bps、および iops の制限

10. イメージのビルド時にリソース制限を指定する (docker build)

1. 資源制約の主な種類

2.资源限制的几种方式

3.资源限制的状态查询

十一、 compose部署

Harbor 服务

1.下载Harbor 安装程序

2.配置Harbor 参数文件

(1)参数

(2)可选参数

3.启动Harbor

4.查看Harbor启动镜像

十二、 consul部署

1.consul服务器

2.通过httpd api 获取集群信息

3.容器服务自动加入consul集群

(1)安装 Gliderlabs/Registrator

(2)测试服务发现功能是否正常

(3)验证 http 和 nginx 服务是否注册到 consul

(4)安装 consul-template

(5)准备 template nginx 模板文件

(6)编译安装nginx

(7)配置 nginx

4.增加一个nginx容器节点

おすすめ

ストレスツールを使用して CPU とメモリをテストする