项目需求: 实现Harbor的HTTPS高可用,由于Harbor 服务器配置不高,直接做HTTPS对上传下载镜像时,若docker客户端多时,会非常慢,为了提高harbor的效率,采用以下方式来解决.拓扑图: 1. 先生成证书 这里我直接使用脚本生成,若手动制作,可参考网上教程. https://github.com/zhang75656/shell-tools/blob/master/gencret.sh 若要使用此脚本,需要事先安装openssl.[注意:我测试环境是ubuntu,若是Cen

我们有给客户搭建私有容器仓库的需求.开源的私有容器registry可供选择的不多,除了docker官方的distribution之外,比较知名的是VMware China出品的Harbor,我们选择了harbor. harbor在docker distribution的基础上增加了一些安全.访问控制.管理的功能以满足企业对于镜像仓库的需求.harbor以docker-compose的规范形式组织各个组件,并通过docker-compose工具进行启停. 不过,harbor默认的安装配置是针对si

之前介绍Harbor私有仓库的安装和使用,这里重点说下Harbor高可用集群方案的部署,目前主要有两种主流的Harbor高可用集群方案:1)双主复制:2)多harbor实例共享后端存储. 一.Harbor双主复制高可用集群 1)主从同步harbor官方默认提供主从复制的方案来解决镜像同步问题,通过复制的方式,我们可以实时将测试环境harbor仓库的镜像同步到生产环境harbor,类似于如下流程: 在实际生产运维的中,往往需要把镜像发布到几十或上百台集群节点上.这时,单个Registry已经无法满

目录 一.理论概述 什么是harbor harbor要解决的问题 有了docker自带的registry为什么还要用harbor harbor的架构组件 Harbor工作原理 二.部署harbor及其主从复制 环境 三.总结 报错 一.理论概述 什么是harbor Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器,可以用来构建企业内部的Docker镜像仓库. harbor是基于docker registry进行了相应的企业级扩展,从而获得了更加广泛的应用,新特性包括

之前介绍Harbor私有仓库的安装和使用,这里重点说下Harbor高可用集群方案的部署,目前主要有两种主流的Harbor高可用集群方案:1)双主复制:2)多harbor实例共享后端存储. 一.Harbor双主复制高可用集群 1)主从同步harbor官方默认提供主从复制的方案来解决镜像同步问题,通过复制的方式,我们可以实时将测试环境harbor仓库的镜像同步到生产环境harbor,类似于如下流程: 在实际生产运维的中,往往需要把镜像发布到几十或上百台集群节点上.这时,单个Registry已经无法满

一 多Harbor高可用介绍 共享后端存储是一种比较标准的方案,将多个Harbor实例共享同一个后端存储,任何一个实例持久化到存储的镜像,都可被其他实例中读取.通过前置LB组件,如Keepalived,可以分流到不同的实例中去处理,从而实现负载均衡,也避免了单点故障,其架构图如下: 方案说明: 共享存储:Harbor的后端存储目前支持AWS S3.Openstack Swift, Ceph等,本实验环境采用NFS: 共享Session:harbor默认session会存放在redis中,可将re

目录 说明 双主复制 主从同步 双主复制说明 多harbor实例共享后端存储 方案说明 环境说明 配置说明 安装redis和mysql 导入registry数据库 配置harbor 挂载nfs目录 修改harbor.cfg配置 修改docker-compose.yml配置 说明 在上一篇企业级镜像管理系统Harbor中,我们简要说明了单机版本harbor的配置.然而这种单机部署显然无法满足在生产中需求,必须要保证应用的高可用性. 目前有两种主流的方案来解决这个问题: 双主复制 多harbor实例

前言 本文Harbor高可用依照Harbor官网部署,主要思路如下,大家可以根据具体情况选择搭建. 部署Postgresql高可用集群.(本文选用Stolon进行管理,请查看文章<kubernetes下Stolon部署高可用Postgresql>) 部署redis高可用集群.(本文选用Helm对redis进行高可用部署,请查看文章<kubernetes部署高可用redis>,该文以整理好redis编排文件可直接使用) 部署Harbor高可用集群.(本文主要阐述Harbor的高可用部

高可用Harbor搭建 思路及介绍 Harbor官方有推出主从架构和双主架构来实现Harbor的高可用及数据备份.   一.主从架构:  说白了,就是往一台Harbor仓库中push镜像,然后再通过这台Harbor分散下发至所有的从Harbor,类似下图: 这个方法保证了数据的冗余性,但是仍然解决不了Harbor主节点的单点问题,当业务量足够大时,甚至会引起主节点崩溃.   二.双主架构: 双主复制就是两套Harbor的数据互相同步,来保证数据的一致性,然后两套Harbor的前端再挂一层负载,来

基于上一篇部署完成了企业级仓库harbor的部署,今天我们来聊聊什么是harbor的高可用 Harbor 支持基于策略的 Docker 镜像复制功能,这类似于 MySQL 的主从同步,其可以实现不同的数据中心.不同的运行环境之间同步镜像,并提供友好的管理界面,大大简化了实际运维中的镜像管理工作,已经有用很多互联网公司使用harbor 搭建内网 docker 仓库的案例,并且还有实现了双向复制的案列,本文将实现单向复制的部署: 1 1.准备机器 2 #我这边直接复用上一篇的10.0.0.110,再

高可用harbor集群搭建 一.安装部署 1.节点角色 角色 数量 名称 备注 harbor主节点 2 harbor-1 harbor-2 双主模式 haproxy 2 HA-1 HA-2 需要通过keepalived绑定vip Redis 高可用集群 redis harbor组件,本地启动或远程配置 postgresql 高可用集群 postgres harbor组件,本地启动或远程配置 ceph 高可用集群 ceph harbor组件 2.离线安装 1.下载离线源码包解压至harbor-1

harbor架构 下载地址https://github.com/goharbor/harbor/ 高可用架构 解压压缩包 tar -xvf harbor-offline-installer-v1.10.3.tgz 进入harbor目录修改配置文件 执行sh install.sh安装harbor 通过nginx进行负载实现高可用 user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run

1.Docker namespace 1.1 namespace介绍 namespace是Linux提供的用于分离进程树.网络接口.挂载点以及进程间通信等资源的方法.可以使运行在同一台机器上的不同服务能做到完全隔离,就像运行在多台不同的机器上一样. 当Docker创建一个容器时,它会创建新的以上六种NameSpace的实例,然后把容器中的所有进程放到这些NameSpace之中,使得容器这个父进程只对自己的子进程有感知,而对于宿主机其他进程一无所知,从而产生一种它就是一个独立的系统的"错觉&quo

生产环境搭建高可用Harbor(包括恢复演练实操) 前言 因资源成本问题,本Harbor高可用架构为最小开销方案,如果资源充足,可以将PG.Redis全部使用使用云厂商集群模式. 同时为了配置简单,并没用使用keepalived与heartbeat等高可用开源组件. 准备工作 阿里云SLB 阿里云ECS 共享存储 Redis 最小实例SLB 2c4g 俩台 阿里云NFS 阿里云Redis 操作系统为Ubuntu18.04,在俩台ECS上搭建主从PG,如果不想用阿里云redis,也可以使用ECS搭

文章转载自:https://blog.csdn.net/networken/article/details/119704025 harbor高可用简介 harbor目前有两种主流的高可用方案: 多harbor实例共享后端存储 双主复制,harbor自带的镜像复制功能 双主复制架构在遇到大镜像时有同步延迟,并且一个实例故障后需要手动重新开启复制策略才能再次同步. 下面以阿里云环境为例,使用两台ECS实例+NFS后端共享存储方式部署高可用harbor,整体架构图如下: 该方案需要注意以下几点: 1.

前言 这篇写好一段时间了,一直也没发布上来,今天稍微整理下了交下作业,部分内容偷懒引用了一些别人的内容.使用Jenkins做持续集成/持续交付,当业务达到一定规模的时候,Jenkins本身就很容易成为整条流水线的瓶颈,各个业务端都依靠Jenkins,部署Jenkins服务时如何保障服务的高可用变得尤为重要.以微医为例,目前Jenkins的业务承载量:>1,000 Build Jobs,>5,000 Buils/Day,光依靠单master已经无法承载高并发的性能压力,瓶颈来自多方面,不仅仅是J

写在前面:  1. 该文章部署方式为二进制部署. 2. 版本信息 k8s 1.7.6,etcd 3.2.9 3. 高可用部分 etcd做高可用集群.kube-apiserver 为无状态服务使用haproxy做负载均衡,kube-controller-manager和kube-scheduler使用自身的选举功能,无需考虑高可用问题. 环境说明: 本环境中网络说明,宿主机及node网段为192.168.1.x/24,service cluster网段为172.16.x.x/16 ,pod网段为1

在公司,使用dns切换,可能会比keepalived+haproxy,更精简的易维护. 毕竟,高可用只是偶尔切换,不是时时切换. 且dns解析在自己可控时,更不会影响k8s线上使用了. (部分代码,由于担心太冗长,已使用xxx代替,这些xxx完全可以自己生成的) 使用步骤如下: 先在每个master上安装etcd,运行如下命令: sh k8s.sh k8s.xxx.com.cn etcd 等每个master上的etcd安装好之后,运行如下命令: sh k8s.sh k8s.xxx.com.cn

一.Breeze简介 Breeze 项目是深圳睿云智合所开源的Kubernetes 图形化部署工具,大大简化了Kubernetes 部署的步骤,其最大亮点在于支持全离线环境的部署,且不需要FQ获取 Google 的相应资源包,尤其适合某些不便访问互联网的服务器场景.详细资料请阅读官方文档(项目地址https://github.com/wise2c-devops/breeze ) 二.环境准备 1.系统环境 #主机名称需要符合DNS命名规则,另外Harbor为必须组件,详细信息请参考官方文档 2.

Breeze项目是深圳睿云智合所开源的Kubernetes图形化部署工具,大大简化了Kubernetes部署的步骤,其最大亮点在于支持全离线环境的部署,且不需要FQ获取Google的相应资源包,尤其适合某些不便访问互联网的服务器场景. (项目地址 https://github.com/wise2c-devops/breeze ) 转载于https://mp.weixin.qq.com/s?__biz=MzI5ODQ2MzI3NQ==&mid=2247485466&idx=1&sn=