阿里云cicd（阿里云CID）
本文目录一览：
CI/CD的实践
阿里云的 Docker 镜像源添加
docker服务基本的操作
得到密钥后填入，继续
然后再点击去安装推荐插件
docker 的架构是 C/S 架构。在我们使用 docker 命令时，其实是命令使用 socket 与 docker 的守护进程进行通信，我们需要将jenkins添加到docker的用户组,才能正常执行 docker 命令
NODE
服务器上生成
把公钥添加在到git, 私钥添加到jenkins源码管理
本地文件添加DockerFile和nginx配置
构建脚本
然后构建生成一个新的镜像
镜像库就是集中存放镜像的一个文件服务。镜像库在 CI/CD 中，又称 制品库 。构建后的产物称为制品，制品则要放到制品库做中转和版本管理。常用平台有Nexus，Jfrog，Harbor或其他对象存储平台
在自己搭建的gitlab中，能部署用户可访问的前端打包文件吗？
不知道 自建的gitLab 是否有 pages服务，
但是你既然有自己的服务器，应该是可以通过 Nginx 配置 ，将路径映射到你打包后的目录中去。这个是可以实现的
nginx 静态文件服务器的配置请百度。
服务器数量比较少，怎么运维比较好？
运维人员的工作每天基本上都是在检查问题，枯燥但又重要， 要是你的某一个环节出现问题并没有及时发现问题，对于企业来说损失可能非常大，基本上运维人每天的工作我罗列了下，有这几种：
1、负责服务器的硬件配置、软件安装、机房上下架等技术维护工作
2、负责虚拟化技术产品物理机配置、管理和日常运行监控和维护
3、负责独立主机或虚拟应用产品的开通使用、日常维护、故障诊断和排除
4、提供独立主机或虚拟应用客户产品操作和应用方面的技术支持
5、监视分管的服务器，及时发现问题，并积极解决问题
现在信息化数字时代，单靠人工去检查出现错误几率会很大，而且有的运维人还不只管理两台服务器，像我们公司的运维每人至少要管理30台服务器，这样子单靠人工运维耗费的人工成本和时间是非常大的，所以还是推荐你用运维工具吧，比如云帮手（）
1.支持跨云商批量管理服务器
2.兼容性强大，兼容市面基本所有的云商云主机，兼容操作系统；
3.操作简单，可视化界面预览资源、一键修复、一键部署；
4. 可以远程登录云主机FTP桌面，处理云主机上的文件；
5.监控和资源还有告警功能，这个是挺好的，不用盯着看；
6.系统修复功能，这个是挺实用也比较必须的；
7.免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬。
你好，很高兴回答你这个问题。从运维的角度来讲，服务器的数量少并不意味着我们的运维工作就非常轻松，相反我们更应该重视此阶段的工作。
我们可以从以下几方面来开展我们的运维工作：
1.应用服务器
我们可以从当前服务器中找出 至少2个节点装Vsphere虚拟化，建立一个数据中心、集群 ；如果你的服务器有多网卡和SCSI，还可以做一些更高级的应用，如vmotion、负载均衡、高可用等。当虚拟机或服务器故障，可以 实现故障自动转移，有效的避免了单节点的故障，提供服务器的容错率 。
我们可以在新建的虚拟机部署Web、API等各种应用，而且 虚拟机可以在vCenter图形化界面下统一管理 。这一般是中小公司的在服务器方面的解决方案。
当然，我们对docker比较熟悉，可以使用一套docker解决方案，这比Vsphere更能节省一部分资源。当然这个需要的技能要求也比较高，需要我们不断积累。
2.数据库服务器
数据库服务器在此我们单独拿出来，是因为数据库对服务器性能、磁盘IO要求比较高，不太建议使用虚拟机，当然这需要根据业务的实际情况来做选择。 数据库我们需要通过一主一从、一主二从的方式实现高可用，来避免数据库单点问 题，我们还可以选择合适的proxy来进行读写分离、读负载均衡等。另外还要考虑数据的本地备份、异地备份，来确保数据可恢复。
3.系统监控
当我们在应用服务器和数据库服务器上线一套系统后， 我们需要通过监控掌握从服务器硬件、基础状态、应用、数据库等从下到上的运行状态 ，以便我们能够对告警及时做出响应。考虑到报警的及时性，我们需要监控接入多种报警渠道，如微信、钉钉、邮件、短信等。监控的目的是发现问题、解决访问，因此我们需要踏实的做好这一步，才能为我们的业务保驾护航。
好了，其实不管服务器多少，我们都需要扎实的把基础打好，这样才能以不变应万变面对各种情形。希望我的回答能够帮到你。
题主没有详细说明具体应用系统的功能，比如是否单一的Web服务？有没有微服务、分布式、集群化扩展的潜在需求？
通常来说，建议使用云服务自动化运维。云服务已经成为IT技术的核心基础设施，充分利用云服务带来的弹性和分布式优势，赋能自动化运维。
一，自动构建系统
如果需要构建应用，那么就建议配置使用CI/CD持续化集成和自动化部署，比如常用的Jenkins，配置Git代码提交时触发构建，然后自动部署。
二，日志收集处理系统
1，ELK是常见的日志收集管理系统，包括ElasticSearch, LogStash, Kibana三个服务，架构示意图如下：
2，在ELK系统中，Kibana是一个图形化展示工具，配置查询条件，运维人员随时可以搜索指定日志信息，分析处理故障。
三，服务监控
1，云监控CloudMonitor
主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。
比如配置CPU使用率到达80%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。
2，应用监控
以监控宝为例，配置服务地址，选择分布在不同地区和运营商的监测点。当监测点不能正常调用配置的服务地址时，将收到警告信息，可以选择邮件、短信、电话等通知方式。
四，潜在的系统扩展需求
1，是否集群化部署？需要AutoScaling自动伸缩吗？
小型化和集群化并不冲突。如果采用集群化部署，可以配置触发条件，满足时自动增加或者释放服务器资源。比如当CPU使用率达到75%或者内存占用率达到75%时，根据配置好的服务器和数量，自动触发。
2，是否使用Docker容器技术？
Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用，结合Docker-compose资源编排，快速实现自动部署更新，不再需要常用的Jenkins构建服务器。
机器数比较小的话，你可以用云的服务器，这样可以节省好多钱。找一个专门的运维，还不如让开发自己来搞，因为机器少运维他也应付得过来。现在都在搞云计算了，把你的机器放上阿里云或者腾讯云，你自己维护好很多，包括网络贷款都很容易扩容。上面这个我说到的只是说建议你如果你已经是自己的机器了。我建议你从我下面所说的来搞。
认为的整个过程的话一般分为三个阶段，第一的话是手工阶段，什么东西都是手工搞。
第2个阶段就是脚本阶段了，本来手工搞的东西全部脚本化。
第3个阶段就是平台化了，平台化了之后，所有东西都在页面上完成系统完成，不需要人工来干预，甚至不用运维来搞。
有一些人说既然认为就是最后的一个阶段，但是这个很不成熟。所以我就不说了。
针对你这个机器数少的，你可以手工认为，或者说用脚本认为都没问题。
在合适的阶段做合适的事情就是最好的。所以我建议你手工运维或者脚本运维。
我们项目用的 wgcloud运维监控系统 ，它前身是开源项目，后来推出的商业版，也有免费版
wgcloud运行很稳定，性能很好，部署和上手容易
wgcloud支持主机各种指标监控(cpu状态/温度，内存状态，磁盘容量/IO，硬盘smart监控，系统负载，网卡流量，硬件系统信息等)，数据可视化，进程应用监控，大屏可视化，服务接口检测，DOCKER监控，自动生成网络拓扑图，端口监控，日志文件监控，web SSH（堡垒机），指令下发执行，告警信息推送（邮件钉钉微信短信等）
可以装虚拟机代替，在同一个局域网情况下
找服务商外包服务，或者网上托管也不贵收费
服务器数量比较少，比如10台服务器，基本可以不设置运维岗位了，后端开发人员 或者架构师就能搞定。
我就是那种曾经在创业的小公司待过的开发人员，开发，运维我都干了。
但是想想如何更科学更高效的运维还是很有必要的。
运维的目的
软件系统的运行时环境：即公司的业务产线，靠它创造业务价值，这个是最核心的功能诉求。
实时监控系统: 任何时候都要对当前公司的产线的压力一清二楚，有问题功能随时解决，有性能问题及时扩容或者回收资源
降低服务器成本：在业务萎缩的情况下，准确评估哪些资源可以回收，降低服务器的支出
这个是当时我认为的运维的三个主要目的。
运维方案
开发半路出家，当时采用的是shell+python+ansible+jekins+elk的方式
首先，我会及时的更新业务产线的物理架构图，根据架构图来规划服务器的资源使用。
比如多少个web服务，数据库多少，zk,kafka,redis集群怎么分布。
集群部署一般是放在多个服务器上的，这个时候ansible就派上用场了。
jekins主要用来自动发布更新程序已经做定时回收磁盘的任务。
elk主要用来做应用的日志系统和监控告警； 可以通过看板随时知道产线的请求数量和并发数量；
以上的运维方案适用于小公司。运维工程师看到了可以补充
搞个zabbix刷
数量少。如果配置好可以虚拟化。然后跑容器
2021-05-15 从阿里云k8s到aws eks
从阿里云到aws ，从保姆式服务到自力更生
阿里云点点点就可以搭建ci/cd k8s一整套服务
aws除了买了eks外其它全要自立更生
从命令行工具aws cli ,kubectl
到写Deployment.yaml Service.yaml （全靠从阿里云抄来的yaml）
从点点点到各种命令
更新流程1-2-3 这个流程一定能成功，但是会停服
4查看pod正常启动则可以访问
5常用于pod内测试（解决不能理解的问题）
6滚动更新 （会因为性能起不起来，确实能用）
8修改yaml后滚动更新（不知道为啥没效果）
9日志查看全解决
虽然aws给了cicd的解决方案，但是太过复杂以至于没搞出来，一段时间后突然剑走偏锋，想到了一个不错的解决方案。
1.dockile打包一个新镜像 push ecr
主要包含：docker aws kubectl
2.使用aws code build 监听github webhook
在源码中添加buildspace (aws基于该文件构建) 完成3步
2.1 aws ecr login
2.2 docker build
2.3 docker psuh
2.4 kubectl rollout restart deployment
3.存在问题及解决方案
3.1打包过慢：可以继续构建自己的maven image,里面下好需要的jar
3.2重复拉去限制： docker 目前设置了重复拉去限制，频繁更新会导致拉取失败，同样也可以自己打个image推到ecr
3.3滚动更新客户端感知明显：
项目为spring boot 项目：从2点出发解决。总结，合理更新基础包，少走弯路
3.3.1.k8s活检 支持 spring boot 2.3.x actuator
3.3.2.springboot 优雅停止 springboot 2.3.x 支持
3.4 oom kill
还是2个层面解决问题：
3.4.1.depolyment 限定cpu,内存大小
3.4.2 jvm限定：
3.4.2.1 jdk8老版本需要启动时设置堆栈空间 -Xms 1024M -Xmx1024M（事实上依然存在OOM异常，所以才发现了第二种方案）
3.4.2.2 jdk8新版本已经特意支持容器部署，只需要-XX:+UseContainerSupport
3.5 kubectl操作eks
3.5.1 安装aws
3.5.2 安装eks
3.5.3 安装kubectl
3.5.4 认证 aws eks --region region-code update-kubeconfig --name cluster_name
3.6 eks 挂载efs
官方教程
官方教程有个问题，就是只部署了一个efs,如果想在eks中部署多个efs,只需要在通过yaml创建多个pv,pvc即可，该教程中无pvc与pc的关联配置，所以系统默认选择空闲空间使用。如果想创建关联关系，可在pvc中添加labels
发表评论
暂时没有评论，来抢沙发吧~