在本文中,我们将详细介绍dockerstack实践的各个方面,并为您提供关于docker-stack的相关解答,同时,我们也将为您带来关于167dockerdocker构建nginx容器系列问题doc
在本文中,我们将详细介绍docker stack实践的各个方面,并为您提供关于docker-stack的相关解答,同时,我们也将为您带来关于167 docker docker构建nginx容器系列问题 docker registry docker run docker toolbo、35. docker swarm dockerStack 部署 投票应用、Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包、docker compose VS docker stack的有用知识。
本文目录一览:- docker stack实践(docker-stack)
- 167 docker docker构建nginx容器系列问题 docker registry docker run docker toolbo
- 35. docker swarm dockerStack 部署 投票应用
- Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包
- docker compose VS docker stack
docker stack实践(docker-stack)
stacks
1. 可以在docker-compose.yml中增加多个services
docker engine 1.12新特性
1. 内置服务编排机制:目前有Docker Swarm、Kubernetes以及Mesos在内的多种编排框架,Docker Engine如今迎来了内置编排机制
2. Service:分布式负载均衡服务
3. 零配置安全性:节点之间通信内容验证、授权、加密
4. Docker Stack与分布式应用捆绑包DAB
普通容器和docker stack区别
单个应用方式: Dockerfile -> 镜像 -> 容器(docker run) ---非集群
多个应用管理方式: docker-compose ---非集群
分布式负载均衡服务方式: docker service create/update ---集群
分布式负载均衡服务管理方式:Docker Compose -> 分布式应用捆绑包 -> Docker Stack ---集群
通过compose文件生成dab并创建stack过程
docker service ls --filter name=redis --quiet | wc -l
docker-compose --file docker-compose.yml bundle
docker deploy --file page-hit-counter.dab page-hit-counter
docker service ls
【docker stack命令】
根据compose文件或bundle文件创建stack
docker stack deploy --compose-file docker-compose.yml vossibility
docker stack deploy --bundle-file vossibility-stack.dab vossibility
列出所有stack
docker stack ls
列出stack中所有任务
docker stack ps
删除stack
docker stack rm
列出stack中所有服务
docker stack services stack-name
【自动集群负载均衡】
Docker Service负责保持应用的“理想状态”。例如,理想状态是确保特定服务有二套容器与之对应且持续运行。如果移除某个容器,而非服务,则该服务会自动重启一个容器,如果整个节点挂了,则会自动到集群中开启另一个节点。所以如果要删除某个服务,必须 docker service rm ** 或 docker stack rm **
例如:
docker rm -f abf8703ed713 ----删除正在运行的容器
docker service ls ----能看到容器删除后又重启了一个
167 docker docker构建nginx容器系列问题 docker registry docker run docker toolbo
background : 最近为小伙伴们筹划docker系列的技术分享,研究了一会docker相关技术, 在此记录一下构建nginx容器时候的坑
1.nginx服务器根目录问题
docker 官方镜像提供的nginx基于debian/jessie平台,其文件结构和ubuntu中的nginx中并不相同
eg:
run一个niginx容器
<span>//80端口被占用,so...</span> $ sudo docker run <span>-it</span><span>-p</span><span>800</span>:<span>800</span> nginx $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES <span>1801</span>a32aab54 nginx <span>"nginx -g ''daemon off"</span><span>2</span> minutes ago Up <span>2</span> minutes <span>80</span>/tcp, <span>443</span>/tcp, <span>0.0</span><span>.0</span><span>.0</span>:<span>800</span><span>-></span><span>800</span>/tcp berserk_kare
进入容器内部
<span>$ </span>sudo docker exec -it <span>1801</span>a32aab54 /bin/bash root<span>@1801a32aab54</span><span>:/</span><span># </span>
查看nginx目录
<span># cd /etc/nginx/</span> conf<span>.d</span>/ koi-utf mime<span>.types</span> nginx<span>.conf</span> uwsgi_params fastcgi_params koi-win modules/ scgi_params win-utf
可以看到不仅没有熟悉的 /sites-available,也没有 /sites-enabled
继续查看nginx配置
<span># cat /conf.d/default.conf</span><span>server</span> { listen <span>80</span>; server_name localhost; <span>#charset koi8-r;</span><span>#access_log /var/log/nginx/log/host.access.log main;</span> location / { root /usr/share/nginx/html; <span>index</span><span>index</span>.html <span>index</span>.htm; } <span>#error_page 404 /404.html;</span><span># redirect server error pages to the static page /50x.html</span><span>#</span> error_page <span>500</span><span>502</span><span>503</span><span>504</span> /<span>50</span>x.html; location = /<span>50</span>x.html { root /usr/share/nginx/html; } <span>#...省略php-fpm配置,好长..</span> }
根目录配置: root /usr/share/nginx/html;
测试
<span># cd /usr/share/nginx/html</span><span># touch index.html</span><span># echo "test nginx in docker" >index.html</span>
php-fpm配置相关
'').addClass(''pre-numbering'').hide(); $(this).addClass(''has-numbering'').parent().append($numbering); for (i = 1; i '').text(i)); }; $numbering.fadeIn(1700); }); });以上就介绍了167 docker docker构建nginx容器系列问题,包括了docker,nginx方面的内容,希望对PHP教程有兴趣的朋友有所帮助。
35. docker swarm dockerStack 部署 投票应用
1. 编写 docker-compose.yml
# docker-compose.yml
version: "3"
services:
redis:
image: redis:alpine
ports:
- "6379"
networks:
- frontend
deploy:
replicas: 2
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
db:
image: postgres:9.4
volumes:
- db-data:/var/lib/postgresql/data
networks:
- backend
deploy:
placement:
constraints: [node.role == manager]
vote:
image: dockersamples/examplevotingapp_vote:before
ports:
- 5000:80
networks:
- frontend
depends_on:
- redis
deploy:
replicas: 2
update_config:
parallelism: 2
restart_policy:
condition: on-failure
result:
image: dockersamples/examplevotingapp_result:before
ports:
- 5001:80
networks:
- backend
depends_on:
- db
deploy:
replicas: 1
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
worker:
image: dockersamples/examplevotingapp_worker
networks:
- frontend
- backend
deploy:
mode: replicated
replicas: 1
labels: [APP=VOTING]
restart_policy:
condition: on-failure
delay: 10s
max_attempts: 3
window: 120s
placement:
constraints: [node.role == manager]
visualizer:
image: dockersamples/visualizer:stable
ports:
- "8080:8080"
stop_grace_period: 1m30s
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
deploy:
placement:
constraints: [node.role == manager]
networks:
frontend:
backend:
volumes:
db-data:
2. 启动 service 并 查看 service 的状态
docker stack deploy vote -c=docker-compose.yml
docker stack ls
docker stack services vote
docker stack ps vote
3. 对 vote_vote service 进行拓展
docker service stack scale vote_vote=3
4. 访问
访问 192.168.205.10:5000 进行投票
访问 192.168.205.10:5001 查看投票情况
访问 192.168.205.10:8080 查看容器 部署情况
Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包
在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。
Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。
下面首先来看各项新的功能特性:
内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。
Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。
零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。
Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。
截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。
镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。
感兴趣的朋友可以前往 docker.com/dab 了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:
Dockerfile -> 镜像 -> 容器
Docker Compose -> 分布式应用捆绑包 -> Docker Stack
下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。
需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。
利用Docker Compose创建一个分布式应用捆绑包
Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:
docker-compose bundle --help
Generate a Docker bundle from the Compose file.
Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.
Usage: bundle [options]
Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".
现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:
version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
-8091:8091
-8092:8092
-8093:8093
-11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
-db
environment:
-COUCHBASE_URI=db
ports:
-8080:8080
此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。 利用它生成一个应用捆绑包:
docker-compose bundle
WARNING: Unsupported key ''depends_on'' in services.web - ignoring
WARNING: Unsupported key ''container_name'' in services.db - ignoring
Wrote bundle to hellojavaee.dsb
depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。
container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:
{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}
此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。
在Docker中进行Swarm Mode初始化
正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:
docker swarm --help
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm
Run ''docker swarm COMMAND --help'' for more information on a command.
在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:
docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.
关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。
docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]
从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。
部署Docker Stack
利用docker deploy命令创建一个stack:
docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web
下面来看各服务列表:
docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c
在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl
WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。
自我修复Docker Service
Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:
docker rm -f abf8703ed713
请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
结果显示新容器已经启动完成。检查WildFly服务:
docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]
Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。
进行应用验证
下面检查该应用是否已经成功部署:
curl http://localhost:30004/books/resources/book
[{"books":0}]
为该应用添加新的book:
再次验证该book:
curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]
欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。
docker compose VS docker stack
docker 在 1.12 的时候引入了 swarm mode,其中有个 stack 命令,看起来两者的功能差不多,但还有一点差异的:
docker compose:
compose 是 fig 演变而来,python 脚本,需要单独安装,compose 可以 build image,compose 需要单独安装,compose 更多是 dev 环境使用。
docker stack:
stack 被集成进 docker 原生 CLI,go 编写,不支持 build image。stack 更适合 docker cloud 环境,用来管理集群。
一个 stack 是一组 services 的集合,它可以使你的 app 运行在指定的环境,一个 stack 文件是一个 YAML 文件,YAML 文件中定义了一个或者多个 services,和 docker-compose.yml 文件很相似,但是和 compose 又有一点小扩展。两者虽然都使用 compose.yml 文件,但是里面的命令有一丢丢的差别,stack 只支持 swarm 模式下使用,只支持 compose V3 格式。
stack 配置项
image 该image用来部署该service,这是唯一强制的key
autodestroy 当service被stop的时候,container应该是否被终止。默认是no,可以有no, on-success, always三种
autoredeploy 当image在updated的时候,service的container是否应该被自动重新部署,默认是false
cap_add, cap_drop 增加或者删除容器的acp能力,可以通过man 7 capabilities来查看具体的能力
cgroup_parent 指定一个可选的父cgroup
command 覆盖image中的command指令
deployment_strategy 容器在node上的分布,默认是emptiest_node,可以是emptiest_node, high_availability, every_node三种。
devices device mapping列表,和docker client使用--device效果一样
dns 自定义dns server,可以是一个地址,也可以是多个列表地址
dns_search 自定义DNS search domains
environment 一个环境变量列表,会被增加到service的环境变量中,这里的定义会覆盖image中的环境变量定义。
expose 暴露端口,但是不会发布到host上,它只是可以在你的nodes上可以访问
extra_hosts 增加hostname映射,和docker client的--add-host效果一样
labels 增加container的元数据。
links 连接到其他service上
net 设置网络模式,默认只支持bridge和host模式
pid 设置pid模式,
ports 暴露端口,格式是HOST:CONTAINER,或者只指定container的端口,这样会在host上选择一个随机的端口
privileged 是否开启container和docker engine一样的权限,默认是false
restart 当service被stop的时候是否重启container,默认是no,可以是no, on-failure, always
roles 一个docker api的roles列表
security_opt 覆盖container的默认 labeling scheme
sequential_deployment 容器是否被应该逐一启动和扩展,默认是false
tags 标明部署tags,用来选择nodes,以确定container运行在那个nodes
target_num_containers 该service默认运行的container副本数,默认是1
volumes 挂载的路径,格式是HOST:CONTAINER,或者HOST:CONTAINER:ro,指定访问模式
volumes_from 从另一个service挂载所有的volumes
#和docker run共同的key
working_dir: /app
entrypoint: /app/entrypoint.sh
user: root
hostname: foo
domainname: foo.com
mac_address: 02:42:ac:11:65:43
cpu_shares: 512
cpuset: 0,1
mem_limit: 100000m
memswap_limit: 200000m
privileged: true
read_only: true
stdin_open: true
tty: true
stack 不支持的配置项:build external_links env_file
关于docker stack实践和docker-stack的问题就给大家分享到这里,感谢你花时间阅读本站内容,更多关于167 docker docker构建nginx容器系列问题 docker registry docker run docker toolbo、35. docker swarm dockerStack 部署 投票应用、Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包、docker compose VS docker stack等相关知识的信息别忘了在本站进行查找喔。
本文标签: