1、依次点击:“我的电脑”-(右键)“属性”-“高级系统设置”-“环境变量”,弹出Windows的“环境变量”配置卡。

2、新建系统变量Java_Home,其路径为jdk的安装路径

3、新建系统变量path,如果已存在就对其进行编辑-编辑文本,将将引号里面的全部复制“%Java_Home%\bin;%Java_Home%\jre\bin;”,到“变量值”栏的最前面

变量作用:用javac将源码编译成.class文件, 在调用java 命令让程序执行.

4、新建系统变量CLASSPATH(变量名大小写不影响,但是java_home的名字要注意其在变量值栏是否一致)“.;%Java_Home%\bin;%Java_Home%\lib\dt.jar;%Java_Home%\lib\tools.jar”

变量作用–告诉java虚拟机所有的可执行文件.class都在哪
  它的值也是由目录组成,它的作用在于告诉Java执行环境,在哪些目录下可以找到所要执行的Java程序所需要的类或者包

5、确认保存后进行验证,打开cmd命令栏,依次且分别输入java,javac,java -version查看结果,成功会有显示相关信息,最后查看版本确认是否一致

发表于wei, liu | 留下评论

JAVA虚拟机

Java虚拟机就是二进制字节码的运行环境,负责装载字节码到其内部,解释/编译为对应平台上的机器指令执行。每一条Java指令,Java虚拟机规范中都有详细定义,如怎么取操作数,怎么处理操作数,处理结果放在哪里。

  • 特点

一次编译,到处运行

自动内存管理

自动垃圾回收功能

发表在 java基础 | 留下评论

mysql服务安装和启动

1、首先打开下载好的安装包,对指定对象修改,名字不一致需改成my.ini,data目录需要删除

使用文本编辑类工具对配置进行修改

主要修改对象为basedir和datadir,用法如上
basedir = mysql解压目录路径
datadir = mysql解压目录\data

3、如jdk安装方法类似,计算机—>系统属性—>高级系统配置—>环境变量,新建系统变量,path变量添加%MYSQL_HOME%\bin

3、系统管理员身份打开命令行窗口,cd打开mysql执行文件目录

mysqld –initialize –user=mysql –console 初始化

mysqld -install 安装服务

net start mysql 启动服务

确保cd进入目录内部,启动服务成功后进入数据库修改密码
发表在 java | 留下评论

java语言的特点

特点一:面向对象,两个基本概念:类,对象 三大特性:封装,继承,多态

特点二:健壮性

特点三:跨平台性

保留字: goto const

发表在 nginx的配置文件 | 留下评论

Kubernetes 组件

Master 组件

Master组件提供集群的管理控制中心。

Master组件可以在集群中任何节点上运行。但是为了简单起见,通常在一台VM/机器上启动所有Master组件,并且不会在此VM/机器上运行用户容器。

kube-apiserver

kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。

ETCD

etcd是Kubernetes提供默认的存储系统,保存所有集群数据,使用时需要为etcd数据提供备份计划

kube-controller-manager

kube-controller-manager运行管理控制器,它们是集群中处理常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成单个二进制文件,并在单个进程中运行。

这些控制器包括:

  • 节点(Node)控制器
  • 副本(Replication)控制器:负责维护系统中每个副本中的pod。
  • 端点(Endpoints)控制器:填充Endpoints对象(即连接Services&Pods)。
  • Service Account和Token控制器:为新的Namespace 创建默认帐户访问API Token。

cloud-controller-manager

云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的,目前还是Alpha的功能。

云控制器管理器仅运行云提供商特定的(controller loops)控制器循环。可以通过将--cloud-provider flag设置为external启动kube-controller-manager ,来禁用控制器循环。

cloud-controller-manager 具体功能:

  • 节点(Node)控制器
  • 路由(Route)控制器
  • Service控制器
  • 卷(Volume)控制器

kube-scheduler

kube-scheduler 监视新创建没有分配到NodePod,为Pod选择一个Node。

插件 addons

插件(addon)是实现集群pod和Services功能的 。Pod由Deployments,ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。

DNS

虽然不严格要求使用插件,但Kubernetes集群都应该具有集群 DNS。

群集 DNS是一个DNS服务器,能够为 Kubernetes services提供 DNS记录。

由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。

用户界面

kube-ui提供集群状态基础信息查看

容器资源监测

容器资源监控提供一个UI浏览监控数据。

Cluster-level Logging

Cluster-level logging,负责保存容器日志,搜索/查看日志。

节点(Node)组件

节点组件运行在Node,提供Kubernetes运行时环境,以及维护Pod。

kubelet

kubelet是主要的节点代理,它会监视已分配给节点的pod,具体功能:

  • 安装Pod所需的volume。
  • 下载Pod的Secrets。
  • Pod中运行的 docker(或experimentally,rkt)容器。
  • 定期执行容器健康检查。
  • Reports the status of the pod back to the rest of the system, by creating a mirror pod if necessary.
  • Reports the status of the node back to the rest of the system.

kube-proxy

kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。

docker

docker用于运行容器。

RKT

rkt运行容器,作为docker工具的替代方案。

supervisord

supervisord是一个轻量级的监控系统,用于保障kubelet和docker运行。

fluentd

fluentd是一个守护进程,可提供cluster-level logging.。

发表在 Kubernetes | 留下评论

Kubernetes 架构

Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的workflows 和更高级的自动化任务。
Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。
Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

Borg简介

Borg是谷歌内部的大规模集群管理系统,负责对谷歌内部很多核心服务的调度和管理。Borg的目的是让用户能够不必操心资源管理的问题,让他们专注于自己的核心业务,并且做到跨多个数据中心的资源利用率最大化。

Borg主要由BorgMaster、Borglet、borgcfg和Scheduler组成,如下图所示

  • BorgMaster是整个集群的大脑,负责维护整个集群的状态,并将数据持久化到Paxos存储中;
  • Scheduer负责任务的调度,根据应用的特点将其调度到具体的机器上去;
  • Borglet负责真正运行任务(在容器中);
  • borgcfg是Borg的命令行工具,用于跟Borg系统交互,一般通过一个配置文件来提交任务。

Kubernetes架构

Kubernetes借鉴了Borg的设计理念,比如Pod、Service、Labels和单Pod单IP等。Kubernetes的整体架构跟Borg非常像,如下图所示

Kubernetes主要由以下几个核心组件组成:

  • etcd保存了整个集群的状态;
  • apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
  • controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
  • scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
  • kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;
  • Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
  • kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;

除了核心组件,还有一些推荐的Add-ons:

  • kube-dns负责为整个集群提供DNS服务
  • Ingress Controller为服务提供外网入口
  • Heapster提供资源监控
  • Dashboard提供GUI
  • Federation提供跨可用区的集群
  • Fluentd-elasticsearch提供集群日志采集、存储与查询

分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构,如下图所示

  • 核心层:Kubernetes最核心的功能,对外提供API构建高层的应用,对内提供插件式应用执行环境
  • 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)
  • 管理层:系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)
  • 接口层:kubectl命令行工具、客户端SDK以及集群联邦
  • 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
    • Kubernetes外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
    • Kubernetes内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
发表在 Kubernetes | 留下评论

Kubernetes(一)

Kubernetes是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

通过Kubernetes你可以:

  • 快速部署应用
  • 快速扩展应用
  • 无缝对接新的应用功能
  • 节省资源,优化硬件资源的使用

我们的目标是促进完善组件和工具的生态系统,以减轻应用程序在公有云或私有云中运行的负担。

Kubernetes 特点

  • 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)
  • 可扩展: 模块化, 插件化, 可挂载, 可组合
  • 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展

Kubernetes是Google 2014年创建管理的,是Google 10多年大规模容器管理技术Borg的开源版本。

为什么要使用容器?

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新/回滚等操作,当然也可以通过创建虚机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。

容器优势总结:

  • 快速创建/部署应用:与VM虚拟机相比,容器镜像的创建更加容易。
  • 持续开发、集成和部署:提供可靠且频繁的容器镜像构建/部署,并使用快速和简单的回滚(由于镜像不可变性)。
  • 开发和运行相分离:在build或者release阶段创建容器镜像,使得应用和基础设施解耦。
  • 开发,测试和生产环境一致性:在本地或外网(生产环境)运行的一致性。
  • 云平台或其他操作系统:可以在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine或其它任何环境中运行。
  • Loosely coupled,分布式,弹性,微服务化:应用程序分为更小的、独立的部件,可以动态部署和管理。
  • 资源隔离
  • 资源利用:更高效

使用Kubernetes能做什么?

可以在物理或虚拟机的Kubernetes集群上运行容器化应用,Kubernetes能提供一个以“容器为中心的基础架构”,满足在生产环境中运行应用的一些常见需求,如:

Kubernetes不是什么?

Kubernetes并不是传统的PaaS(平台即服务)系统。

  • Kubernetes不限制支持应用的类型,不限制应用框架。不限制受支持的语言runtimes (例如, Java, Python, Ruby),满足12-factor applications 。不区分 “apps” 或者“services”。 Kubernetes支持不同负载应用,包括有状态、无状态、数据处理类型的应用。只要这个应用可以在容器里运行,那么就能很好的运行在Kubernetes上。
  • Kubernetes不提供中间件(如message buses)、数据处理框架(如Spark)、数据库(如Mysql)或者集群存储系统(如Ceph)作为内置服务。但这些应用都可以运行在Kubernetes上面。
  • Kubernetes不部署源码不编译应用。持续集成的 (CI)工作流方面,不同的用户有不同的需求和偏好的区域,因此,我们提供分层的 CI工作流,但并不定义它应该如何工作。
  • Kubernetes允许用户选择自己的日志、监控和报警系统。
  • Kubernetes不提供或授权一个全面的应用程序配置 语言/系统(例如,jsonnet)。
  • Kubernetes不提供任何机器配置、维护、管理或者自修复系统。

另一方面,大量的Paas系统都可以运行在Kubernetes上,比如Openshift、Deis、Gondor。可以构建自己的Paas平台,与自己选择的CI系统集成。

由于Kubernetes运行在应用级别而不是硬件级,因此提供了普通的Paas平台提供的一些通用功能,比如部署,扩展,负载均衡,日志,监控等。这些默认功能是可选的。

另外,Kubernetes不仅仅是一个“编排系统”;它消除了编排的需要。“编排”的定义是指执行一个预定的工作流:先执行A,之B,然C。相反,Kubernetes由一组独立的可组合控制进程组成。怎么样从A到C并不重要,达到目的就好。当然集中控制也是必不可少,方法更像排舞的过程。这使得系统更加易用、强大、弹性和可扩展。

Kubernetes是什么意思?K8S?

Kubernetes的名字来自希腊语,意思是“舵手” 或 “领航员”K8s是将8个字母“ubernete”替换为“8”的缩写。

发表在 Kubernetes | 留下评论

docker中的Nginx与Keepalived

高可用:两台业务系统启动着相同的服务,如果有一台故障,另一台自动接管,我们将将这个称之为高可用;

Keekpalived工作原理:通过vrrp协议实现的

安装:yum install keepalived -y
默认日志存放位置:/var/log/messages

下载完成之后,就先配置好keepalived

vi /etc/keepalived/keepalived.conf

首先你要了解keepalived.conf中配置项的含义是什么?我在这里就放我们需要配置的一些配置项稍作解释

MASTER配置

! Configuration File for keepalived

global_defs { ##全局定义
   router_id KEEPALIVED_MASTER ##你的路由id
   vrrp_skip_check_adv_addr
   vrrp_strict  #严格遵守vvrp协议的意思,建议注释掉,可能会访问不了vip 
   vrrp_garp_interval 0
   vrrp_gna_interval 0
 }
 vrrp_instance VI_1 { #实例1
    state MASTER #主服务器
    interface eth0 #网卡
    virtual_router_id 51  #虚拟路由id
    priority 100 #优先级 MASTE建议100 backup建议比MASTE低 80,70,90都可
    advert_int 1 #间隔时间
    
    authentication { #验证 主和副的配置这儿都一致
        auth_type PASS 
        auth_pass 1111
    }
    virtual_ipaddress { #这里配置的是你的虚拟IP,也就是VIP
       172.17.0.15
    }
}      


以下是BACKUP配置,和上面差不多

 ! Configuration File for keepalived
    global_defs {
    router_id KEEPALIVED_BACKUP #改这
   vrrp_skip_check_adv_addr
   vrrp_strict  
   vrrp_garp_interval 0
   vrrp_gna_interval 0
 } 
 vrrp_instance VI_1 { 
    state BACKUP  #这里也要改
    interface eth0 
    virtual_router_id 51 
    priority 80  #这里要比MASTE小
    advert_int 1 
    
  authentication { #保持一致
        auth_type PASS 
        auth_pass 1111
    }
    virtual_ipaddress { 
       172.17.0.16
    }
}        

以上配置完毕后退出,需要配置hosts文件

vi /etc/hosts
#做一个解析, 将 127.0.0.1 KEEPALIVED_MASTER 加入,backup一致操作

此时keepalived已经配置好了,重点来了。

#启动
systemctl start keepalived
#检查
systemctl status keepalived
#你会发现状态是 RUN,如果过几秒钟你再次检查,则是stop。如果你的没有这问题请略过

奉上我的解决方案与解决的思路

  • 首先去看看报错的log文件,去看看日志中报的是什么错。
  • 我发现默认存放日志文件的地址没有,/var/log/messages 并没有。
  • 那就自己手动设置,将keepalived的存放路径修改

修改keepalived日志路径

vim  /etc/sysconfig/keepalived  将文件的这一行 KEEPALIVED_OPTIONS="-D" 修改为      KEEPALIVED_OPTIONS="-D -d -S 0"
vim /etc/rsyslog.conf   ##如果容器中没有,请自己下载此服务
#在文件的最后添加一行
local0.*     /var/log/keepalived.log
重启rsyslog服务  systemctl restart  rsyslog  
重启keepalived服务,日志会打印到/var/log/keepalived.log

这样就比较明了了,这个错误说的是:IPVS:不能初始化IPVS:协议不可用,原因是ip_vs模块系统默认没有自动加载,可以通过lsmod | grep ip_vs 命令查看一下,如果没有任何输出则表示ip_vs模块并没有被内核加载,得手动加载modprobe ip_vsmodprobe ip_vs_wrr

解决办法

首先你必须得先安装ipvsadm

yum install ipvsadm
#执行
ipvsadm

#如果你执行后报错,如以下
IPVS: Can't initialize ipvs: Protocol not available
Can't initialize ipvs: Protocol not available
Are you sure that IP Virtual Server is built in the kernel or as module?

那还有最后一步,就是在宿主机中,也一样执行ipvsadm,然后再去容器中执行

执行ipvsadm,出现以下就成功了

然后就去restart keepalived。VIP就有了,也就是keepalived没有自杀了

如图所示,nginx1是master,nginx2是backup,当stop nginx1中的keepalived,vip就漂移到了nginx2中。

发表在 nginx的配置文件 | 2条评论

Docker-Compose

简介

Compose 项目是 Docker 官方的开源项目,负责实现对 Docker 容器集群的快速编排。从功能上看,跟 OpenStack 中的 Heat 十分类似。

其代码目前在 https://github.com/docker/compose 上开源。

Compose 定位是 「定义和运行多个 Docker 容器的应用(Defining and running multi-container Docker applications)」,其前身是开源项目 Fig。

通过第一部分中的介绍,我们知道使用一个 Dockerfile 模板文件,可以让用户很方便的定义一个单独的应用容器。然而,在日常工作中,经常会碰到需要多个容器相互配合来完成某项任务的情况。例如要实现一个 Web 项目,除了 Web 服务容器本身,往往还需要再加上后端的数据库服务容器,甚至还包括负载均衡容器等。

Compose 恰好满足了这样的需求。它允许用户通过一个单独的 docker-compose.yml 模板文件(YAML 格式)来定义一组相关联的应用容器为一个项目(project)。

Compose 中有两个重要的概念:

  • 服务 (service):一个应用的容器,实际上可以包括若干运行相同镜像的容器实例。
  • 项目 (project):由一组关联的应用容器组成的一个完整业务单元,在 docker-compose.yml 文件中定义。

Compose 的默认管理对象是项目,通过子命令对项目中的一组容器进行便捷地生命周期管理。

Compose 项目由 Python 编写,实现上调用了 Docker 服务提供的 API 来对容器进行管理。因此,只要所操作的平台支持 Docker API,就可以在其上利用 Compose 来进行编排管理。

命令说明

对于 Compose 来说,大部分命令的对象既可以是项目本身,也可以指定为项目中的服务或者容器。如果没有特别的说明,命令对象将是项目,这意味着项目中所有的服务都会受到命令影响。

执行 docker-compose [COMMAND] --help 或者 docker-compose help [COMMAND] 可以查看具体某个命令的使用格式。

docker-compose 命令的基本的使用格式是

docker-compose [-f=<arg>...] [options] [COMMAND] [ARGS...]

命令选项

-f, --file FILE 指定使用的 Compose 模板文件,默认为 docker-compose.yml,可以多次指定。

-p, --project-name NAME 指定项目名称,默认将使用所在目录名称作为项目名。

--x-networking 使用 Docker 的可拔插网络后端特性

--x-network-driver DRIVER 指定网络后端的驱动,默认为 bridge

--verbose 输出更多调试信息。

-v, --version 打印版本并退出。

命令使用说明

build

格式为 docker-compose build [options] [SERVICE...]

构建(重新构建)项目中的服务容器。

服务容器一旦构建后,将会带上一个标记名,例如对于 web 项目中的一个 db 容器,可能是 web_db。

可以随时在项目目录下运行 docker-compose build 来重新构建服务。

选项包括:

  • --force-rm 删除构建过程中的临时容器。
  • --no-cache 构建镜像过程中不使用 cache(这将加长构建过程)。
  • --pull 始终尝试通过 pull 来获取更新版本的镜像。

config

验证 Compose 文件格式是否正确,若正确则显示配置,若格式错误显示错误原因。

down

此命令将会停止 up 命令所启动的容器,并移除网络

exec

进入指定的容器。

help

获得一个命令的帮助。

images

列出 Compose 文件中包含的镜像。

kill

格式为 docker-compose kill [options] [SERVICE...]

通过发送 SIGKILL 信号来强制停止服务容器。

支持通过 -s 参数来指定发送的信号,例如通过如下指令发送 SIGINT 信号。

$ docker-compose kill -s SIGINT

logs

格式为 docker-compose logs [options] [SERVICE...]

查看服务容器的输出。默认情况下,docker-compose 将对不同的服务输出使用不同的颜色来区分。可以通过 --no-color 来关闭颜色。

该命令在调试问题的时候十分有用。

pause

格式为 docker-compose pause [SERVICE...]

暂停一个服务容器。

port

格式为 docker-compose port [options] SERVICE PRIVATE_PORT

打印某个容器端口所映射的公共端口。

选项:

  • --protocol=proto 指定端口协议,tcp(默认值)或者 udp。
  • --index=index 如果同一服务存在多个容器,指定命令对象容器的序号(默认为 1)。

ps

格式为 docker-compose ps [options] [SERVICE...]

列出项目中目前的所有容器。

选项:

  • -q 只打印容器的 ID 信息。

pull

格式为 docker-compose pull [options] [SERVICE...]

拉取服务依赖的镜像。

选项:

  • --ignore-pull-failures 忽略拉取镜像过程中的错误。

push

推送服务依赖的镜像到 Docker 镜像仓库。

restart

格式为 docker-compose restart [options] [SERVICE...]

重启项目中的服务。

选项:

  • -t, --timeout TIMEOUT 指定重启前停止容器的超时(默认为 10 秒)。

rm

格式为 docker-compose rm [options] [SERVICE...]

删除所有(停止状态的)服务容器。推荐先执行 docker-compose stop 命令来停止容器。

选项:

  • -f, --force 强制直接删除,包括非停止状态的容器。一般尽量不要使用该选项。
  • -v 删除容器所挂载的数据卷。

run

格式为 docker-compose run [options] [-p PORT...] [-e KEY=VAL...] SERVICE [COMMAND] [ARGS...]

在指定服务上执行一个命令。

例如:

$ docker-compose run ubuntu ping docker.com

将会启动一个 ubuntu 服务容器,并执行 ping docker.com 命令。

默认情况下,如果存在关联,则所有关联的服务将会自动被启动,除非这些服务已经在运行中。

该命令类似启动容器后运行指定的命令,相关卷、链接等等都将会按照配置自动创建。

两个不同点:

  • 给定命令将会覆盖原有的自动运行命令;
  • 不会自动创建端口,以避免冲突。

如果不希望自动启动关联的容器,可以使用 --no-deps 选项,例如

$ docker-compose run --no-deps web python manage.py shell

将不会启动 web 容器所关联的其它容器。

选项:

  • -d 后台运行容器。
  • --name NAME 为容器指定一个名字。
  • --entrypoint CMD 覆盖默认的容器启动指令。
  • -e KEY=VAL 设置环境变量值,可多次使用选项来设置多个环境变量。
  • -u, --user="" 指定运行容器的用户名或者 uid。
  • --no-deps 不自动启动关联的服务容器。
  • --rm 运行命令后自动删除容器,d 模式下将忽略。
  • -p, --publish=[] 映射容器端口到本地主机。
  • --service-ports 配置服务端口并映射到本地主机。
  • -T 不分配伪 tty,意味着依赖 tty 的指令将无法运行。

scale

格式为 docker-compose scale [options] [SERVICE=NUM...]

设置指定服务运行的容器个数。

通过 service=num 的参数来设置数量。例如:

$ docker-compose scale web=3 db=2

将启动 3 个容器运行 web 服务,2 个容器运行 db 服务。

一般的,当指定数目多于该服务当前实际运行容器,将新创建并启动容器;反之,将停止容器。

选项:

  • -t, --timeout TIMEOUT 停止容器时候的超时(默认为 10 秒)。

start

格式为 docker-compose start [SERVICE...]

启动已经存在的服务容器。

stop

格式为 docker-compose stop [options] [SERVICE...]

停止已经处于运行状态的容器,但不删除它。通过 docker-compose start 可以再次启动这些容器。

选项:

  • -t, --timeout TIMEOUT 停止容器时候的超时(默认为 10 秒)。

top

查看各个服务容器内运行的进程。

unpause

格式为 docker-compose unpause [SERVICE...]

恢复处于暂停状态中的服务。

up

格式为 docker-compose up [options] [SERVICE...]

该命令十分强大,它将尝试自动完成包括构建镜像,(重新)创建服务,启动服务,并关联服务相关容器的一系列操作。

链接的服务都将会被自动启动,除非已经处于运行状态。

可以说,大部分时候都可以直接通过该命令来启动一个项目。

默认情况,docker-compose up 启动的容器都在前台,控制台将会同时打印所有容器的输出信息,可以很方便进行调试。

当通过 Ctrl-C 停止命令时,所有容器将会停止。

如果使用 docker-compose up -d,将会在后台启动并运行所有的容器。一般推荐生产环境下使用该选项。

默认情况,如果服务容器已经存在,docker-compose up 将会尝试停止容器,然后重新创建(保持使用 volumes-from 挂载的卷),以保证新启动的服务匹配 docker-compose.yml 文件的最新内容。如果用户不希望容器被停止并重新创建,可以使用 docker-compose up --no-recreate。这样将只会启动处于停止状态的容器,而忽略已经运行的服务。如果用户只想重新部署某个服务,可以使用 docker-compose up --no-deps -d <SERVICE_NAME> 来重新创建服务并后台停止旧服务,启动新服务,并不会影响到其所依赖的服务。

选项:

  • -d 在后台运行服务容器。
  • --no-color 不使用颜色来区分不同的服务的控制台输出。
  • --no-deps 不启动服务所链接的容器。
  • --force-recreate 强制重新创建容器,不能与 --no-recreate 同时使用。
  • --no-recreate 如果容器已经存在了,则不重新创建,不能与 --force-recreate 同时使用。
  • --no-build 不自动构建缺失的服务镜像。
  • -t, --timeout TIMEOUT 停止容器时候的超时(默认为 10 秒)。

version

格式为 docker-compose version

打印版本信息。

Compose 模板文件

version: '2' 
services:   
  nginx:      
   image: nginx:v1  
   restart: always  
   ports:         
    - "8099:80"
   volumes:  
    - ./nginx-test/nginx.conf:/etc/nginx/nginx.conf

volumes

数据卷所挂载路径设置。可以设置为宿主机路径(HOST:CONTAINER)或者数据卷名称(VOLUME:CONTAINER),并且可以设置访问模式 (HOST:CONTAINER:ro)。该指令中路径支持相对路径。

volumes:
 - /var/lib/mysql
 - cache/:/tmp/cache
 - ~/configs:/etc/configs/:ro

如果路径为数据卷名称,必须在文件中配置数据卷。

version: "3"

services:
  my_src:
    image: mysql:8.0
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

image

指定为镜像名称或镜像 ID。如果镜像在本地不存在,Compose 将会尝试拉取这个镜像。

image: ubuntu
image: orchardup/postgresql
image: a4bc65fd
发表在 docker容器 | 留下评论

Nginx的配置文件

找到/etc/nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
   
 upstream tyyz {
	server 192.168.30.31:8080 weight=2;
	server 192.168.30.31:8081 weight=1;
}
	


    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

 server {
        listen       80;
        server_name  www.tyyz.com;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location =/ {
	rewrite .* http://www.tyyz.com/uc;
} 
        location / {
       
            proxy_pass   http://tyyz; 
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
    include /etc/nginx/conf.d/*.conf;
}

发表在 nginx的配置文件 | 留下评论