分类目录归档:云运维

增加、删除node

删除node14

#ansible-playbook r.move.node14.yml -k \
-e docker_bin_dir=”/usr/bin” \
-e kube_network_plugin=”calico-rr”

#kubectl delete node node14

#kubectl get nodes node14就删除完毕

 

增加node14

在hosts.ini的nodes部分加上node别名即可,当然的提前ssh-key打通

ansible-playbook -i inventory/sk/hosts.ini scale.yml -b -k

root@node10:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node10 Ready master 20h v1.9.5+coreos.0
node11 Ready node 3d v1.9.5+coreos.0
node12 Ready node 3d v1.9.5+coreos.0
node13 Ready node 3d v1.9.5+coreos.0
node14 Ready node 36s v1.9.5+coreos.0

关于Kubernetes Master高可用的一些策略

Kubernetes高可用也许是完成了初步的技术评估,打算将生产环境迁移进Kubernetes集群之前普遍面临的问题。 为了减少因为服务器当机引起的业务中断,生产环境中的业务系统往往已经做好了高可用,而当引入Kubernetes这一套新的集群管理系统之后, 服务器不再是单一的个体,位于中央位置的Kubernetes Master一旦中断服务,将导致所有Node节点均不可控,有可能造成严重的事故。

总体来讲这是一个被多次讨论,但暂时没有形成统一解决方案的话题。今天主要介绍一些Kubernetes Master高可用的策略,供大家参考。

一个小目标

高可用是复杂的系统工程。出于篇幅的考虑以及能力的限制,今天我们先关注一个小目标:所有的Kubernetes Master服务器没有单点故障,任何一台服务器当机均不影响Kubernetes的正常工作。

实现这一目标带来的直接收益是我们可以在不影响业务正常运行的前提下实现所有服务器的滚动升级,有助于完成系统组件升级以及安全补丁的下发。

为了实现没有单点故障的目标,需要为以下几个组件建立高可用方案:

这些组件的关系可参考下面这张集群架构示意图。 继续阅读

Docker网络方案-Calico

  • Calico,基于BGP协议的路由方案,支持很细致的ACL控制,对混合云亲和度比较高。

Calico是一个纯3层的数据中心网络方案,而且无缝集成像OpenStack这种IaaS云架构,能够提供可控的VM、容器、裸机之间的IP通信。通过将整个互联网的可扩展IP网络原则压缩到数据中心级别,Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGP route reflector来完成。

这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。 继续阅读

kubernetes中创建secret

在k8s的集群里面,我们需要批量下发dep jobs到k8s的node上,由于node上我们通过play-books进行初始安装k8s-proxy后,hub信息都是空。不信任私我们的HUB(harbor)。

在k8s中,我们需要建立secret,然后在后续的运维部署任务中使用他。

建立secrset如下:

参数
kubectl create secret docker-registry NAME –docker-username=user –docker-password=password –docker-email=email
exp:
master@root#kubectl create secret docker-registry sk-hub –docker-server=hub.sklinux.com –docker-username=sk –docker-password=passwordjiushipassword –docker-email=sklinux@qq.com

FEK日志采集展示平台

整体架构
image
filebeat介绍
“Filebeat是一个日志文件托运工具,在你的服务器上安装客户端后,filebeat会监控日志目录或者指定的日志文件,追踪读取这些文件(追踪文件的变化,不停的读),并且转发这些信息到elasticsearch或者logstarsh中存放。
以下是filebeat的工作流程:当你开启filebeat程序的时候,它会启动一个或多个探测器(prospectors)去检测你指定的日志目录或文件,对于探测器找出的每一个日志文件,filebeat启动收割进程(harvester),每一个收割进程读取一个日志文件的新内容,并发送这些新的日志数据到处理程序(spooler),处理程序会集合这些事件,最后filebeat会发送集合的数据到你指定的地点。
(个人理解,filebeat是一个轻量级的logstash,当你需要收集信息的机器配置或资源并不是特别多时,使用filebeat来收集日志。日常使用中,filebeat十分稳定,笔者没遇到过宕机。)”
部署过程:
1.elasticsearch集群准备
a.download es5
b.配置es5配置文件
c.启动es5集群
2.filebeat
3.kibana
结果:
filebeat

继续阅读

安全的linux沙盒限制日志用户行为规范

限制用户登录后只能访问某个文件夹比如logs,不能看到核心配置文件

1.创建chroot环境
2.修改sshd文件
3.搬移某个文件夹到chroot文件夹
4.系统层链接回去

a.拷贝chroot所需要的文件到chroot文件夹
b.创建普通用户loguser
c.修改sshd文件

Match User loguser
ChrootDirectory /home/chroot/

docker + swarm 集群

Swarm是Docker公司在2014年12月初新发布的容器管理工具。和Swarm一起发布的Docker管理工具还有Machine以及Compose。Swarm是一套较为简单的工具,用以管理Docker集群,使得Docker集群暴露给用户时相当于一个虚拟的整体。Swarm使用标准的Docker API接口作为其前端访问入口。

继续阅读

docker迁移

Docker是如何工作的(简单说明)

Docker是基于镜像的。镜像类似于已经包含了文件、配置和安装好的程序的虚拟机镜像。同样的,你可以像启动虚拟机一样启动多个镜像实例。运行中的镜像称为容器。你可以修改容器(比如删除一个文件),但这些修改不会影响到镜像。不过,你使用docker commit <container-id> <image-name>命令可以把一个正在运行的容器变成一个新的镜像。

举个例子:

    # 像Docker官方的hello world例子一样,拉取一个叫busybox的镜像
    sudo docker pull busybox

    # 查看本地已经有哪些镜像
    # 我们可以看到busybox
    sudo docker images

    # 现在让我们来修改下busybox镜像的容器
    # 这次,我们创建一个文件夹
    sudo docker run busybox mkdir /home/test

    # 让我们再看看我们有哪些镜像了。
    # 注意每条命令执行后容器都会停止
    # 可以看到有一个busybox容器
    sudo docker ps -a

    # 现在,可以提交修改了。
    # 提交后会看到一个新的镜像busybox-1
    #  <CONTAINER ID> 是刚刚修改容器后得到的ID
    sudo docker commit <CONTAINER ID> busybox-1

    # 再看看我们有哪些镜像。
    # 我们现在同时有busybox和busybox-1镜像了。
    sudo docker images

    # 我们执行以下命令,看看这两个镜像有什么不同
    sudo docker run busybox [ -d /home/test ] && echo 'Directory found' || echo 'Directory not found'
    sudo docker run busybox-1 [ -d /home/test ] && echo 'Directory found' || echo 'Directory not found'

现在,我们有两个不同的镜像了(busybox和busybox-1),还有一个通过修改busybox容器得来的容器(多了一个/home/test文件夹)。下面来看看,是如何持久化这些修改的。

导出(Export)

Export命令用于持久化容器(不是镜像)。所以,我们就需要通过以下方法得到容器ID:

    sudo docker ps -a

接着执行导出:

    sudo docker export <CONTAINER ID> > /home/export.tar

最后的结果是一个2.7MB大小的Tar文件(比使用save命令稍微小些)。

保存(Save)

Save命令用于持久化镜像(不是容器)。所以,我们就需要通过以下方法得到镜像名称:

    sudo docker images

接着执行保存:

    sudo docker save busybox-1 > /home/save.tar

最后的结果是一个2.8MB大小的Tar文件(比使用export命令稍微大些)。

它们之间的不同

现在我们创建了两个Tar文件,让我们来看看它们是什么。首先做一下小清理——把所有的容器和镜像都删除:

    # 查看所有的容器
    sudo docker ps -a

    # 删除它们
    sudo docker rm <CONTAINER ID>

    # 查看所有的镜像
    sudo docker images

    # 删除它们
    sudo docker rmi busybox-1
    sudo docker rmi busybox

译注:可以使用 docker rm $(docker ps -q -a) 一次性删除所有的容器,docker rmi $(docker images -q) 一次性删除所有的镜像。

现在开始导入刚刚导出的容器:

    # 导入export.tar文件
    cat /home/export.tar | sudo docker import - busybox-1-export:latest

    # 查看镜像
    sudo docker images

    # 检查是否导入成功,就是启动一个新容器,检查里面是否存在/home/test目录(是存在的)
    sudo docker run busybox-1-export [ -d /home/test ] && echo 'Directory found' || echo 'Directory not found'

使用类似的步骤导入镜像:

    # 导入save.tar文件
    docker load < /home/save.tar

    # 查看镜像
    sudo docker images

    # 检查是否导入成功,就是启动一个新容器,检查里面是否存在/home/test目录(是存在的)
    sudo docker run busybox-1 [ -d /home/test ] && echo 'Directory found' || echo 'Directory not found'

那,它们之间到底存在什么不同呢?我们发现导出后的版本会比原来的版本稍微小一些。那是因为导出后,会丢失历史和元数据。执行下面的命令就知道了:

    # 显示镜像的所有层(layer)
    sudo docker images --tree

执行命令,显示下面的内容。正你看到的,导出后再导入(exported-imported)的镜像会丢失所有的历史,而保存后再加载(saveed-loaded)的镜像没有丢失历史和层(layer)。这意味着使用导出后再导入的方式,你将无法回滚到之前的层(layer),同时,使用保存后再加载的方式持久化整个镜像,就可以做到层回滚(可以执行docker tag <LAYER ID> <IMAGE NAME>来回滚之前的层)。

    vagrant@ubuntu-13:~$ sudo docker images --tree
    ├─f502877df6a1 Virtual Size: 2.489 MB Tags: busybox-1-export:latest
    └─511136ea3c5a Virtual Size: 0 B
      └─bf747efa0e2f Virtual Size: 0 B
        └─48e5f45168b9 Virtual Size: 2.489 MB
          └─769b9341d937 Virtual Size: 2.489 MB
            └─227516d93162 Virtual Size: 2.489 MB Tags: busybox-1:latest
good luck!


1. 备份容器

首先,为了备份Docker中的容器,我们会想看看我们想要备份的容器列表。要达成该目的,我们需要在我们运行着Docker引擎,并已创建了容器的Linux机器中运行 docker ps 命令。

  1. # docker ps

Docker Containers List

Docker Containers List

在此之后,我们要选择我们想要备份的容器,然后去创建该容器的快照。我们可以使用 docker commit 命令来创建快照。

  1. # docker commit -p 30b8f18f20b4 container-backup

Docker Commit

Docker Commit

该命令会生成一个作为Docker镜像的容器快照,我们可以通过运行 docker images 命令来查看Docker镜像,如下。

  1. # docker images

Docker Images

Docker Images

正如我们所看见的,上面做的快照已经作为Docker镜像保存了。现在,为了备份该快照,我们有两个选择,一个是我们可以登录进Docker注册中心,并推送该镜像;另一个是我们可以将Docker镜像打包成tar包备份,以供今后使用。

如果我们想要在Docker注册中心上传或备份镜像,我们只需要运行 docker login 命令来登录进Docker注册中心,然后推送所需的镜像即可。

  1. # docker login

Docker Login

Docker Login

  1. # docker tag a25ddfec4d2a arunpyasi/container-backup:test
  2. # docker push arunpyasi/container-backup

Docker Push

Docker Push

如果我们不想备份到docker注册中心,而是想要将此镜像保存在本地机器中,以供日后使用,那么我们可以将其作为tar包备份。要完成该操作,我们需要运行以下 docker save 命令。

  1. # docker save -o ~/container-backup.tar container-backup

taking tarball backup

taking tarball backup

要验证tar包是否已经生成,我们只需要在保存tar包的目录中运行 ls 命令即可。

2. 恢复容器

接下来,在我们成功备份了我们的Docker容器后,我们现在来恢复这些制作了Docker镜像快照的容器。如果我们已经在注册中心推送了这些Docker镜像,那么我们仅仅需要把那个Docker镜像拖回并直接运行即可。

  1. # docker pull arunpyasi/container-backup:test

Docker Pull

Docker Pull

但是,如果我们将这些Docker镜像作为tar包文件备份到了本地,那么我们只要使用 docker load 命令,后面加上tar包的备份路径,就可以加载该Docker镜像了。

  1. # docker load -i ~/container-backup.tar

现在,为了确保这些Docker镜像已经加载成功,我们来运行 docker images 命令。

  1. # docker images

在镜像被加载后,我们将用加载的镜像去运行Docker容器。

  1. # docker run -d -p 80:80 container-backup

Restoring Docker Tarball

Restoring Docker Tarball

3. 迁移Docker容器

迁移容器同时涉及到了上面两个操作,备份和恢复。我们可以将任何一个Docker容器从一台机器迁移到另一台机器。在迁移过程中,首先我们将把容器备份为Docker镜像快照。然后,该Docker镜像或者是被推送到了Docker注册中心,或者被作为tar包文件保存到了本地。如果我们将镜像推送到了Docker注册中心,我们简单地从任何我们想要的机器上使用 docker run 命令来恢复并运行该容器。但是,如果我们将镜像打包成tar包备份到了本地,我们只需要拷贝或移动该镜像到我们想要的机器上,加载该镜像并运行需要的容器即可。

 

oracle in docker

Oracle 11g Enterprise Edition Database Docker Image

A Docker image for Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 based on an Oracle Linux 7.1 image.

Build Image

Due to legal restrictions this image is not available on the Docker Hub. However, with some time and patience you may build it yourself.

Build

Download the following zip files from Oracle Tech Net and put them in the ‘oracle-11g/installation_files/’ folder:

  • linux.x64_11gR2_database_1of2.zip
  • linux.x64_11gR2_database_2of2.zip

Finally, from the ‘oracle-11g’ folder simply run:

$ docker build -t ufoscout/oracle-11g .

The build process could take long tiem to run; so, it is now the moment to have break and drink some good coffee…

Run

Due to Docker limitations this image must be run with the “privileged” flag. This is due to the amount of available memory on/dev/shm which is limited to 64MB (see #2606). This is not sufficient to meet Oracle’s MEMORY_TARGET minimum requirements.

Please note that this limitation has been removed in Docker 1.10.

Create a new container running an Oracle 12c database:

$ docker run --privileged -d ufoscout/oracle-11g

Inspect

You can connect as SYSDBA with the following statement:

$ docker exec -ti containerName sudo -u oracle -i bash -c "sqlplus / AS SYSDBA"

This is particularly useful, if you don’t want to expose any ports and solely rely on linking containers with each other directly.

elasticSearch之Docker部署

客户的es要部署上线生产环境,由于生产环境全部是基于docker部署,所以ES也不例外。

前置条件: 服务器:3台 16G+ 8核+ 200G空间+

网络:千兆内网交换

由于我们的客户服务器都是高配256G内存22T sas raid 10阵列 40核cpu,所以硬件条件足以满足。

部署方式:docker集群

网络模式:host模式

最小工作集群:3节点

前端接入:haproxy:9300

实例如下:

 

docker run -it -d
–name $nodeName
–net=host
–oom-kill-disable=true
-e ES_HEAP_SIZE=”$ES_HEAP_SIZE”
-v $datadir:/data/elasticsearch/data
-v $logdir:/data/elasticsearch/logs
“$image”
–node.name “$nodeName”
–cluster.name $clusterName
–network.publish_host $localIP
–transport.tcp.port $tranPort
–http.port $httpPort
–discovery.zen.ping.multicast.enabled “false”
–discovery.zen.ping.unicast.hosts “10.0.0.1:9300″,”10.0.0.2:9300″,”10.0.0.3:9300″
–index.cache.field.max_size “10000mb”
–index.cache.filter.max_size “10000mb”
–index.cache.field.expire “60m”
–index.cache.field.type “soft”
–indices.cache.filter.size “50%”
–index.cache.filter.expire “60m”
–Des.index.store.type “memory”
–threadpool.search.size “61″