大叔公开课~微服务与持续集成

闲话多说

免费报名:http://www.genshuixue.com/teacher/classCourseDetail/171117794648

.Net Core来了,带给我们的是什么?跨平台,无疑是最大的亮点!

Docker横空出世,让开发者和运维者都尝到了甜头!

Jenkins持续集成,功能包括了持续的软件版本发布与测试,让开发人员专心关注自己的代码开发,让运维人员专心写部署代码,一次性工作,从来不要反复的做一件事!

云时代来了,容器时代了,面向应用的微服务也来了,麻烦也就跟着来了,我应该如何去找到你,应用A,你被部署到了容器里,你的IP不真的不清楚,因为你是那么的善变。因为出现了这些问题,所以在解决问题的道路上出现了“服务发现”,“服务熔断”,“服务注册”等。

微软.Net Core和Docker合作,打造多应用部署,我们都应该知道的YML

想像一下,把一个大系统拆分成多个小服务,这些小服务在分别去部署,或者它们之间又可以相互通信,这对于开发来说是清晰了,对部署来说是麻烦了,对开发来说是职责分离了,应用与应用之间解耦了,以后的A应用的升级不会影响到B应用了,这大概就是微服务设计的初衷吧!

1 微服务项目图

2 Dockerfile的使用

对于容器化部署来说,我们只要关心Dockerfle和YML文件即可,其中Dockerfile用来生成应用的镜像;YML用来部署这个系统里所有的应用。

应用C里的Dockerfile,它以aspnetcore为基础,然后将自己的发布的代码复制到了镜像里,最后使用dotnet命令启动这个应用!

3 docker-compose.yml进行服务的部署

YML里会有这个系统的服务名称和每个小应用的服务名及它们使用的Dockerfile的地址,生成的镜像名,镜像运行后的容器名,监听的端口,使用的网络,运行的环境等很多配置的信息

version: '3'

services:
  a:
    image: a
    build:
      context: ./应用A
      dockerfile: Dockerfile

  b:
    image: b
    build:
      context: ./应用B
      dockerfile: Dockerfile

  c:
    image: c
    build:
      context: ./应用C
      dockerfile: Dockerfile
version: '3'

services:
  a:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "80"

事实上,对于服务的部署可能要说的还很多,这里篇幅有限,就到这吧!

Jenkins之前我也写着一些文件,在我的自动化部署分类上,大家可以进行阅读!自动化部署&持续集成系列

感谢各位的阅读!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:大叔公开课~微服务与持续集成,如需转载请自行联系原博主。

时间: 2024-10-29 12:45:11

大叔公开课~微服务与持续集成的相关文章

微服务的持续集成,四步“构建”一个代码世界

本文讲的是微服务的持续集成,四步"构建"一个代码世界,大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误. 今天我们就来聊一聊微服务的持续集成. 目录 一.持续集成之构建 二.持续集成之部署 三.持续集成之测试 四.持续集成之发布 五.总结 一.持续集成之构建 当微服务产生

云端基于Docker的微服务与持续交付实践

云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Swarm Docker Swarm mode 微服务支持(Docker集群架构体系) Docker的发展趋势和前沿成果 在Docker技术方面还是很佩服大牛的,所以赶紧写下笔记,追随大神的脚步. 阿里云资深专家易立,技术就不说了,他比其他直播间硬生生多讲了半个多点,于情于理还是万分感谢本次分享的(可惜devOp

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

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

基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

换个角度看持续交付 在<基于容器服务的持续集成与云端交付>系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付. 不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么.回到本系列第一篇文章中的容器持续交付的流程图: 这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段.持续集成阶段.持续交付阶段等等,规定了在每个阶段中该做什么

云效(原RDC)+ 容器服务完成持续集成

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品. 我会把我最近3个月的使用体会分成5个部分:使用RDC的动机.PHP项目集成.JS项目集成.JAVA项目集成.Docker类项目集成这5个分支来写 因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录: 1.RDC如何耦合进我们的业务 2.如何构建一个基于Composer的PHP项目 3.如何构建一个基于Nod

基于容器服务的持续集成与云端交付(二)- 多维度打磨交付能力

前言 在上一篇中,和大家一起讨论了传统软件交付的问题.持续交付的难点.以及为什么云端的容器交付可以协助大家快速的持续交付. 但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将Docker作为一种交付工具来对待,更多的时候是作为一个交付平台的基础设施来看待,还需要关心的是使用Docker后网络.存储.安全.性能.监控等等不同方面带来的变革. 因为交付的本质是将一套复杂的软件系统从零到一完成开发.测试.部署.上线的过程,软件的复杂度直接关系到了交付的难度,特别是现在微服务的架构方式越来越

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持

基于容器服务的持续集成与云端交付(四)- 多种发布方式

前言 哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死.而云端交付过程中也只有三个问题是严肃的. 如何重建你的系统 How to recreate your system? 如何安全地部署你的系统 How to safely change your system? 部署后的问题监控与解决 When something has gone wrong? 在前面的文章中,我们讲述了什么是云端交付,如何搭建从零搭建一个持续交付系统,而今天我们要谈的是如何安全的部署你的系统,部署

如何构建微服务架构

本文讲的是如何构建微服务架构[编者的话]"微服务"的概念兴起于四五年前,近几年尤其火热,各大厂都在进行微服务化改造和微服务建设.最近一年来我们也参与了微服务化的改造大军,这里写下一些做微服务系统设计和开发时的切身感受. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/CD 实践:开发流程中引入 CI.CD:Gitlab 和 C