Hulk容器服务的镜像CI解决方案

前言

巧妇难为无米之炊,玩容器,“镜像”就是下锅的米,我们私有云Hulk平台的容器服务,向用户提供UI页面化的一整套的镜像定制、制作、管理、私有镜像仓库的服务,这套服务的背后技术实现,Jenkins算是“引擎”,本文简要介绍这其中的技术方案;

纯手工捣鼓Docker镜像

Docker的镜像,已然成为容器镜像的事实标准,我们的容器服务也是基于Docker构建的;

手工制作Docker镜像时,大概这几步:

1、创建制作镜像的工作目录


  1. # mkdir nginx-19-el6 
  2. # cd nginx-19-el6 

2、可以创建一个子目录,存放要添加到镜像中的配置文件,并组织好目录层次,最后用ADD指令统一添加到镜像中


  1. # mkdir rootfs 
  2. # tree rootfs/ 
  3. rootfs/ 
  4. └── usr 
  5.     └── local 
  6.         └── nginx 
  7.             └── conf 
  8.                 ├── fastcgi.conf 
  9.                 ├── include 
  10.                 │   └── xxx.conf 
  11.                 ├── mime.types 
  12.                 └── nginx.conf 

3、写一个dockerfile


  1. # cat dockerfile 
  2. FROM r.your.domain/admin/centos-68:latest 
  3. RUN yum -y install nginx-1.9.15-5.el6 && yum clean all 
  4. ADD rootfs.tar.gz / 
  5. EXPOSE 80 
  6. ENTRYPOINT ["/usr/local/nginx/sbin/nginx"] 
  7. CMD ["-c", "/usr/local/nginx/conf/nginx.conf", "-g", "daemon off;"] 

4、build镜像


  1. # docker build -t r.your.domain/xxx/nginx-19-el6:01 . 

5、push到镜像仓库


  1. # docker push r.your.domain/xxx/nginx-19-el6:01 

这种纯手工的方式,很明显,由于自动化程度低,工作量较大,尤其是当镜像种类、版本较多以后,而且对于不了解docker命令、dockerfile语法的同学,使用门槛还是比较高哦;

UI页面化、自动化地生产Docker镜像

针对上面提到的效率、使用门槛的问题,简要介绍下我们的解决方案;

在面向用户的功能方面,要解决好下面几个主要问题:

  1. 镜像内容的管理,主要是一些配置文件,比如上面的rootfs目录
  2. dockerfile的定制、自动生成,比如定制RUN、EXPOSE、ENTRYPOINT、CMD
  3. 触发build、push,以及镜像仓库的管理

在后端的技术实现方面,我们采用下面的架构:

镜像内容管理、dockerfile定制生成

UI页面上支持用户管理自己的配置文件(rootfs)、运行的命令(RUN)、入口程序、暴露的端口等,比如:

后台会把这些内容、信息,存储到GitLab;

Jenkins实现自动化生产线

如果用户触发“制作镜像”,会触发一个Jenkins的job,该job从GitLab拉取后,根据一个Jenkinsfile里定义逻辑“制作镜像”;

Jenkinsfile里充分利用了pipeline的语法,把一系列步骤串起来:前期检查、创建tar文件、生成dockerfile、build、push、清理;

下面是一个示例的Jenkinsfile:


  1. #!groovy 
  2.  
  3. pipeline { 
  4.     agent any 
  5.  
  6.     environment { 
  7.        REGISTRY_ACCESS = credentials('xxx') 
  8.     } 
  9.  
  10.     options { 
  11.         timeout(time: 30, unit: 'MINUTES') 
  12.     } 
  13.  
  14.     // a list of parameters provided when triggering 
  15.     parameters { 
  16.         string(name: 'registry', defaultValue: '') 
  17.         string(name: 'namespace', defaultValue: '') 
  18.         string(name: 'image_name', defaultValue: '') 
  19.         string(name: 'image_tag', defaultValue: '') 
  20.     } 
  21.  
  22.     stages { 
  23.         stage('Verify') { 
  24.             steps { 
  25.                 echo "To check whether related project exists and specified tag is usable..." 
  26.                 sh "xxx xxx xxx" 
  27.             } 
  28.         } 
  29.  
  30.         stage('Prepare') { 
  31.             steps { 
  32.                 echo "To generate 'Dockerfile' and archive 'rootfs' directory..." 
  33.                 sh "xxx xxx xxx" 
  34.                 sh "xxx xxx xxx" 
  35.             } 
  36.         } 
  37.  
  38.         stage('Build') { 
  39.             steps { 
  40.                 echo "To build image..." 
  41.                 sh "xxx xxx xxx" 
  42.             } 
  43.         } 
  44.  
  45.         stage('Push') { 
  46.             steps { 
  47.                 echo 'To push image...' 
  48.                 sh "xxx xxx xxx" 
  49.             } 
  50.         } 
  51.     } 
  52.  
  53.     post { 
  54.         always { 
  55.             echo "Always clean up, no matter whether the building and pushing was failure or success" 
  56.             sh "xxx xxx xxx" 
  57.         } 
  58.     } 

镜像仓库管理

制作好的镜像,存储于私有镜像仓库,用户在页面可以方便的管理,也可以在自己测试环境,docker pull拉取镜像、docker run测试镜像;

本文作者:佚名

来源:51CTO

时间: 2024-10-31 11:29:54

Hulk容器服务的镜像CI解决方案的相关文章

在阿里云HPC上用容器服务一键部署和运行WRF解决方案

背景 众所周知,容器技术的出现深刻改变了软件交付的方式: 敏捷: 秒级应用启动.轻量级隔离.细粒度资源控制.低性能损耗 标准化:版本管理可追溯. 可移植性: 环境无关的交付.部署方式:可用于软件生命周期中不同运行环境.这些能力不但影响了企业软件的开发.构建和交付模式,提高了交付效率和可靠性,也对于像WRF(Weather Research Forecast)这类大型开源气象科学预报软件产生了潜移默化的影响.美国国家大气研究中心(NCAR,也是WRF的开发方)于2016年开源了自己的容器化解决方案

OneAPM CI与阿里云容器服务集成

应用监控是在生产环境使用Docker的重要条件.阿里云容器服务不但提供了核心的容器和宿主机监控能力,而且支持客户集成自己的监控解决方案,这样可以让容器服务平台融合到自己企业的IT管控之下.今天我们会以OneAPM监控为例,介绍如何轻松把3方监控方案集成到容器服务. 1. OneAPM CI 简介 Cloud Insight 集成了数十种互联网流行基础组件的监控,只需要进行最小化的配置就可以实现复杂的基础组件监控, 免除了传统基础组件监控中的复杂流程.一切就只有两步,安装探针,查看仪表盘. 2.

在阿里云容器服务上,轻松搭建Concourse CI

Concourse CI是一款CI/CD工具,它的魅力在于极简设计,被广泛应用于Cloud Foundry各个模块的CI/CD.阿里云也推出了CI工具CodePipeline,开箱即用,推荐试用. Concourse CI官方提供了标准的Docker镜像,在阿里云容器服务部署一套 Concourse CI应用是很轻松的一件事儿. 准备Docker集群 首先,在阿里云容器服务控制台创建一个集群.简单起见,这里节点数为1,网络类型为经典网络. 集群创建过程大约几分钟,成功后的状态如下图: 然后需要开

使用阿里云容器服务Jenkins实现持续集成和Docker镜像构建(updated on 2017.3.3)

持续集成作为敏捷开发重要的一步,其目的在于让产品快速迭代的同时,尽可能保持高质量.每一次代码更新,都要通过自动化测试来检测代码和功能的正确性,只有通过自动测试的代码才能进行后续的交付和部署.本文主要介绍如何将时下最流行的持续集成工具之一的Jenkins结合阿里云容器服务,实现自动测试和镜像构建推送. 接下来的演示是如何通过阿里云容器服务Jenkins实现自动测试和Docker镜像构建,实现高质量的持续集成.具体场景:每次代码提交到GitHub上的nodejs的项目中,阿里云容器服务Jenkins

容器镜像服务 Docker镜像的基本使用

容器镜像服务 Docker镜像的基本使用 快速开始!前往:容器镜像服务控制台 前言 Docker的使用条件和基础不再复述 Docker安装和Docker镜像下载的加速器文档在下方的"相关链接"中已经给出 Docker的镜像存储中心通常被称为Registry. 当您需要获取Docker镜像的时候,首先需要登录Registry,然后拉取镜像.在您修改过镜像之后,您可以再次将镜像推送到Registry中去. Docker的镜像地址是什么?我们来看一个完整的例子.(以容器服务的公共镜像为例)r

Docker监控:基于阿里云容器服务构建自己的Docker监控框架

微服务架构通过将一个复杂系统分解成一系列独立开发.部署和运维的服务,提升了整个系统的敏捷性,可以灵活的响应业务和规模的变化.而Docker技术则将服务的部署和环境完全解耦,利用Docker的可移植性和敏捷性,快速交付分布式应用,从而大大提升了部署运维效率.然而大规模分布式微服务应用,也会给系统监控带来新的挑战. 除去分布式应用自身的复杂性,微服务倡导的快速迭代和动态部署都会加剧管控的复杂性.从技术角度来看,传统的监控系统大多是针对物理机或虚拟机设计的,通常使用静态的配置项来建立应用.环境与监控指

Docker常见故障排查指南 - 阿里云容器服务

对于Docker的初学者而言,当容器或应用出现了问题不知从何入手进行排查.为此,我们准备了一个简单指南来帮助阿里云容器服务的用户进行故障排查. 由于阿里云容器服务完全兼容Docker Swarm,并支持使用原生Docker Client/API,所以很多内容对于 Docker/Docker Swarm的用户也是适用的. Docker问题分类 我们可以把Docker在使用中的问题分为如下几类, 安装故障:Docker Engine 无法正常配置使用 应用故障:应用执行状态与预期不一致 容器故障:无

阿里云容器服务简介

容器服务是阿里云在2015年12月推出的一项新产品,目前正处于公测阶段.   容器服务是一项高性能可扩展的容器管理服务,支持在一组阿里云云服务器上通过 Docker容器来部署或编排应用.用户不再需要安装.运维.扩展自己的集群管理基础设施,而是可以直接通过阿里云控制台图形化界面或API进行容器操作和生命周期管理.容器服务整合了阿里云负载均衡SLB.专有网络 VPC等云产品,为云应用部署与运维场景提供丰富的一站式功能支持.   和业内同类容器服务产品AWS EC2 Container Service

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完