在Dockerfile所在目录执行
docker build -t 101036213/library/你的镜像名:版本
别忘了最后的点,用来指定Dockerfile的位置
build过程类似这样:
cos@controller ~/Dockerfile/eureka $ docker build -t 101036213/library/test:v10
Sending build context to Docker daemon 7869 MB
Step 1 : FROM 19216816100/jdk8:8u74
---> d84b155276a9
Step 2 : MAINTAINER jingchaosong jingchaosong@tendcloudcom
---> Using cache
---> 369126ee2c40
Step 3 : ADD eureka-server-11-SNAPSHOTjar /root/
---> Using cache
---> cd3facb762b3
Successfully built cd3facb762b3
push镜像
docker push 101036213/library/你的镜像名:版本
如果出现push失败的情况,并且提示需要的登录,请使用以下命令login到私有镜像仓库
docker login 101036213
用户名admin
密码Harbor12345
email可以不填
run容器
直接以daemon方式运行
docker run -d --net=mynet 101036213/library/你的镜像名:版本 命令
--net=mynet是让docker调用我们自己的网络插件来分配IP地址,IP地址从我们自己配置的IP池里获取
查看启动的容器的IP地址可以用以下命令
docker inspect container_id | grep IPAddress
交互方式运行
docker run -it --net=mynet 101036213/library/你的镜像名:版本
docker run的时候可以加很多参数,如容器的资源配额限制、hostname、挂载本地目录、DNS等配置,请参看docker run --help
查看容器状态
查看正在运行的容器的状态
docker ps
查看所有容器(包括已经Exit容器的状态)
docker ps -a
删除容器
docker rm container_id
container_id只需要前几位字符就可以了,只要能够区别不同容器即可,不需要输入全部ID字段
强制删除容器
docker rm -f container_id
删除镜像
docker rmi image_id
进入容器内部
前提是必须是正在运行的容器
docker exec -it container_id /bin/bash
运行exit退出
查看容器详细信息
docker inspect container_id
可以看到容器的配置信息和挂载的本地目录、网络配置、状态等
由于之前写了一篇文章,主要是关于docker 基础的东西。这里说一下,容器编排的事情,因为后面 k8s 会用到这个。
参考 下面这个, 文档特别清晰
Docker Compose gitbook
注意 docker compose 有两个版本 一个是 python 编写的 ( docker-compose ),一个是 go 重写的 叫 compose v2 ( docker compose )命令几乎没有区别,只是 go 的少了 - , 我们用python 版的就行。没什么差别
目标 : 定义和运行多个 Docker 容器的应用, 针对多个容器组,进行一键启动和停止。
具体实现 : docker-composeyml 来定义一组相关联的应用容器为一个项目(project) docker-composeyml 就相当于 dockerfile 的 dockfile
概念
service 服务 , 包含多个运行的容器
project 项目, docker compose 管理的单元
自己跑了一便文档上的例子,确实比较好用哟
内容分别如下:
apppy
Dockerfile
docker-composeyml
运行过程
看一下刚刚启动的容器:
上述命令会自动 帮你构建镜像,并按照配置启动容器组。已经存在镜像,则不会成重新构建,除非 使用 docker-compose build 重新构建服务
停止过程
可以看出,是先停掉容器,然后再删除容器的,也会删除网络。所以必要的数据一定要 挂载到外面做持久化
可以看到不会重复构建镜像,只会创建新的网络和容器
可选的 参数
-f, --file FILE 指定使用的 Compose 模板文件,默认为 docker-composeyml
-p, --project-name NAME 指定项目名称,默认将使用所在目录名称作为项目名
(up 的时候可以,使用 -p 参数修改 默认的 目录名的项目名)
检查 Compose 文件是不是对的,错误的话会有错误信息
停止容器组,依次删除容器和清楚创建的网络
进入指定的容器 ( services 里定义的服务名) 或者直接 docker exec
查看容器组 (只包含 compose 启动的容器)
列出 compose 文件中的镜像
默认会 用不同的颜色 显示 服务组的控制台日志
暂停一个服务容器,和 docker pause 一样的
拉取服务依赖的镜像
推送服务依赖的镜像到 Docker 镜像仓库
重启项目中的服务
所有关联的服务将会自动被启动
这个还是挺有用的,设置服务容器的个数
启动服务
关闭容器
这个命令是最常用的
ymal
一个基本模板
一些可用的配置项 (只说一下,常用的吧)
每个服务都必须通过 image 或者 build ( 使用 Dockerfile) 指令 指定镜像生成的方式
指定dockerfile 路径,相对于 docker-composeymal 文件 相对路径 或者 绝对路径
默认为 dockerfile 的入口命令,你可以用这个覆盖
覆盖默认的规则 : 项目名称 服务名称 序号
如果指定了 这个容器名,就没办法使用 docker-compose scale 命令了,因为多个容器名不能一样
指定当前容器 依赖那个容器(需要先启动)
下面的启动 顺序依次是 redis db web
web 服务不会等待 redis db 「完全启动」之后才启动
暴露端口,但不映射到宿主机
容器健康检查配置
和build 目的一样,指定某个镜像的生成方式
如果本地不存在 会尝试 pull
添加容器描述信息, 和 dockerfile 里面的 labels 一样
和 docker run --network 的一样
设置容器使用的网络
和 docker run -p 一样
HOST:CONTAINER 前面是 宿主机,后面是容器,单个 的话就是暴露容器端口
设置挂在目录
HOST:CONTAINER 宿主机路径/数据卷 : 容器路径
支持相对路径
以及其他命令
domainname, entrypoint, hostname, ipc, mac_address, privileged, read_only, shm_size, restart, stdin_open, tty, user, working_dir
关于 compose 容器间的通信 (使用 服务名 即可)
>
选择 uhopper 定制的一系列hadoop生态镜像来搭建docker集群,这些镜像具体包括:
上述关于端口映射部分,对每个容器端口的说明可 参考
docker-compose up -d
在 /etc/hosts 下配置上述 docker 容器中出现的 hostname,将这些域名都指向本机(宿主机) IP,1921681100 为本机 ip,仅供参考。
core-sitexml 增加指向 namenode 的配置,其中 hdfs://namenode:8020 指向 docker 容器中的 namenode host,因此这里我们需要在 /etc/hosts 中加入此域名,并配置为宿主机 ip
yarn-sitexml
容器技术的核心功能,就是通过约束和修改进程的动态表现,从而为其创造出一个“边界” 。对于 Docker 等大多数 Linux 容器来说, Cgroups 技术 是用来制造约束的主要手段,而 Namespace 技术 则是用来修改进程视图的主要方法。
其实只是 Linux 创建新进程的一个可选参数。我们知道,在 Linux 系统中创建线程的系统调用是 clone(),比如:
这个系统调用就会为我们创建一个新的进程,并且返回它的进程号 pid。而当我们用 clone() 系统调用创建一个新进程时,就可以在参数中指定 CLONE_NEWPID 参数,比如:
这时,新创建的这个进程将会“看到”一个全新的进程空间,在这个进程空间里,它的 PID 是 1。之所以说“看到”,是因为这只是一个“障眼法”,在宿主机真实的进程空间里,这个进程的 PID 还是真实的数值,比如 100。
而 除了 PID Namespace,Linux *** 作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace,用来对各种不同的进程上下文进行“障眼法” *** 作。
比如,Mount Namespace,用于让被隔离进程只看到当前 Namespace 里的挂载点信息;Network Namespace,用于让被隔离进程看到当前 Namespace 里的网络设备和配置。
这,就是 Linux 容器最基本的实现原理了。所以说,容器,其实是一种特殊的进程而已。Namespace 技术实际上修改了应用进程看待整个计算机“视图”,即它的“视线”被 *** 作系统做了限制,只能“看到”某些指定的内容 。
优势:更加的轻量且没有损耗资源。弊端:隔离不彻底
Cgroups(Linux Control Group) 就是 Linux 内核中用来为进程设置资源限制的一个重要功能。它最主要的作用,就是限制一个进程组能够使用的资源上限,包括 CPU、内存、磁盘、网络带宽等等
Cgroups 给用户暴露出来的 *** 作接口是文件系统
比如,向 container 组里的 cfs_quota 文件写入 20 ms(20000 us):
意味着在每 100 ms 的时间里,被该控制组限制的进程只能使用 20 ms 的 CPU 时间,也就是说这个进程只能使用到 20% 的 CPU 带宽。
把被限制的进程的 PID 写入 container 组里的 tasks 文件,上面的设置就会对该进程生效了:
除 CPU 子系统外,Cgroups 的每一项子系统都有其独有的资源限制能力,比如:
Linux Cgroups 的设计还是比较易用的,简单粗暴地理解呢,它就是一个子系统目录加上一组资源限制文件的组合。容器是一个“单进程”模型。
Mount Namespace 修改的,是容器进程对文件系统“挂载点”的认知。Mount Namespace 跟其他 Namespace 的使用略有不同的地方:它对容器进程视图的改变,一定是伴随着挂载 *** 作(mount)才能生效。实际上,Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的,它也是 Linux *** 作系统里的第一个 Namespace。
而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统,就是所谓的“容器镜像”。它还有一个更为专业的名字,叫作:rootfs(根文件系统)。
对 Docker 项目来说,它最核心的原理实际上就是为待创建的用户进程:
rootfs 只是一个 *** 作系统所包含的文件、配置和目录,并不包括 *** 作系统内核。在 Linux *** 作系统中,这两部分是分开存放的, *** 作系统只有在开机启动时才会加载指定版本的内核镜像。
容器的 rootfs 由如下图所示的三部分组成:
第一部分,只读层 :它是这个容器的 rootfs 最下面的五层,对应的正是 ubuntu:latest 镜像的五层,挂载方式都是只读的(ro+wh,即 readonly+whiteout)
这些层,都以增量的方式分别包含了 Ubuntu *** 作系统的一部分
第二部分,可读写层。 (rw)
在没有写入文件之前,这个目录是空的。而一旦在容器里做了写 *** 作,你修改产生的内容就会以增量的方式出现在这个层中。如果要删除AuFS 会在可读写层创建一个 whiteout 文件,把只读层里的文件“遮挡”起来。
专门用来存放你修改 rootfs 后产生的增量,原先的只读层里的内容则不会有任何变化
第三部分,Init 层。
有些文件本来属于只读的 Ubuntu 镜像的一部分,但是用户往往需要在启动容器时写入一些指定的值比如 hostname,所以就需要在可读写层对它们进行修改。可是,这些修改往往只对当前的容器有效,我们并不希望执行 docker commit 时,把这些信息连同可读写层一起提交掉。所以,Docker 做法是,在修改了这些文件之后,以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层,所以是不包含这些内容的。可以参考git ignore的思想。
Dockerfile :
ENTRYPOINT:entrypoint才是正统地用于定义容器启动以后的执行体的,其实我们从名字也可以理解,这个是容器的“入口”。
CMD:cmd给出的是一个容器的默认的可执行体。也就是容器启动以后,默认的执行的命令。如果docker run没有指定任何的执行命令或者dockerfile里面也没有entrypoint,那么,就会使用cmd指定的默认的执行命令执行如果你不额外指定,那么就执行cmd的命令,否则呢?只要你指定了,那么就不会执行cmd,也就是cmd会被覆盖。
docker commit,实际上就是在容器运行起来后,把最上层的“可读写层”,加上原先容器镜像的只读层,打包组成了一个新的镜像。当然,下面这些只读层在宿主机上是共享的,不会占用额外的空间。
而由于使用了联合文件系统,你在容器里对镜像 rootfs 所做的任何修改,都会被 *** 作系统先复制到这个可读写层,然后再修改。这就是所谓的:Copy-on-Write。
一个进程的每种 Linux Namespace,都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件,并且链接到一个真实的 Namespace 文件上。
这也就意味着:一个进程,可以选择加入到某个进程已有的 Namespace 当中,从而达到“进入”这个进程所在容器的目的,这正是 docker exec 的实现原理。
Volume 机制,允许你将宿主机上指定的目录或者文件,挂载到容器里面进行读取和修改 *** 作。
当容器进程被创建之后,尽管开启了 Mount Namespace,但是在它执行 chroot(或者 pivot_root)之前,容器进程一直可以看到宿主机上的整个文件系统。所以在 rootfs 准备好之后,在执行 chroot 之前,把 Volume 指定的宿主机目录(比如 /home 目录),挂载到指定的容器目录(比如 /test 目录)在宿主机上对应的目录(即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test)上,这个 Volume 的挂载工作就完成了。
由于执行这个挂载 *** 作时,“容器进程”已经创建了,也就意味着此时 Mount Namespace 已经开启了。所以,这个挂载事件只在这个容器里可见。你在宿主机上,是看不见容器内部的这个挂载点的。这就 保证了容器的隔离性不会被 Volume 打破 。
而这里要使用到的挂载技术,就是 Linux 的 绑定挂载(bind mount)机制 。它的主要作用就是,允许你将一个目录或者文件,而不是整个设备,挂载到一个指定的目录上。并且,这时你在该挂载点上进行的任何 *** 作,只是发生在被挂载的目录或者文件上,而原挂载点的内容则会被隐藏起来且不受影响。绑定挂载实际上是一个 inode 替换的过程。在 Linux *** 作系统中,inode 可以理解为存放文件内容的“对象”,而 dentry,也叫目录项,就是访问这个 inode 所使用的“指针”。
所以,在一个正确的时机,进行一次绑定挂载,Docker 就可以成功地将一个宿主机上的目录或文件,不动声色地挂载到容器中。
初次安装部署好docker后,大多数镜像可以从DockerHub 提取,但是大多数人都希望自己可以完全自定义一个镜像,那么这里需要一个第三方工具 febootstrap
epel6的源提供febootstrap的RPM包
yum install docker-io febootstrap -y
service docker start
chkconfig docker --level35 on
复制代码
制作CentOS66镜像目录
febootstrap -i yum -i iputils -i iproute -i bash -i vim-minimal -i coreutils -i tar -i net-tools centos6 base <a href=">
容器启动时会有3个和DNS、主机名相关的文件会被覆盖掉,/etc/hosts、/etc/hostname、/etc/resolvconf
Docker容器启动时会从宿主机复制/etc/resolvconf文件到容器,并删除到无法连接的DNS服务器
/etc/hosts文件中只记录容器自身的主机名和ip:
/etc/hostname文件记录容器的主机名:
这里介绍的是skywalking的8X版本的安装,老版本的6x的和他有点不一样
升级elasticsearch版本790,oap版本为810,UI版本为810
docker官网
基础镜像
安装elasticsearch
检查启动情况
创建持久化目录,并重启启动elasticsearch
官网地址
基础镜像
注意事项:SW_STORAGE参数严格区分elasticsearch的版本
docker官网
基础镜像
注意:这里映射的端口为8088,防止端口冲突。
启动ui
在window系统中使用google浏览器访问skywalking-ui界面
docker开发环境数据库要单独一个容器。docker搭建了lnmp环境后,如果需要访问安装在宿主机上的数据库或中间件,是不能直接使用127001这个ip的,这个ip在容器中指向容器自己,那么应该怎么去访问宿主机呢:例如你的docker环境的虚拟IP是19216899100,那么宿主机同样会托管一个和19216899100同网段的虚拟IP,并且会是主IP:192168991,那么就简单了,在容器中访问192168991这个地址就等于访问宿主机,问题解决注意,通过192168991访问宿主机,等于换了一个ip,如果数据库或中间件限制了本机访问或者做了ip段限制,要记得添加192168991到白名单。
以上就是关于如何打包创建镜像和运行Docker容器及常用命全部的内容,包括:如何打包创建镜像和运行Docker容器及常用命、docker compose 内容指导、使用 Docker 搭建 Hadoop 集群 和 Spark On Yarn等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)