linuxea:nexus3排序清理docker镜像列表 nexus3的出现可以替代很多产品，nexus3整合了常用的功能，比如docker镜像仓库等。一般我们在配置docker仓库的时候，在blob stores中创建的新的stores来存储镜像。这样方便管理早期的nexus-cli已经没有维护，nexus-cli删除的镜像并没有按照时间的顺序进行保留 。需要在13rentgen的仓库中下载修复版的，所以你需要下载最新的进行使用登录nexus下载最新的修复版本https://github.com/13rentgen/nexus-cli/releases/tag/v1.1.0这里演示用的是旧的版本[root@nexus ]# ./nexus-cli --version Nexus CLI version 1.0.0-beta登录nexus[root@nexus ~]# nexus-cli configure Enter Nexus Host: http://127.0.0.1:38081 Enter Nexus Repository Name: docker-host Enter Nexus Username: admin Enter Nexus Password: yxt@..123!com列出镜像[root@nexus ~]# nexus-cli image ls删除命令nexus-cli image delete -name IMAGE_NAME -keep X，-keep X 表示保留几个tag如果是单个删除，那么命令如下nexus-cli image delete -name dnotask1 -keep 10 nexus-cli image delete -name outage2 -keep 10 nexus-cli image delete -name 1speed -keep 10 nexus-cli image delete -name mongo2 -keep 10 nexus-cli image delete -name mongo1 -keep 10清理脚本#!/bin/bash # Copyright 2022 marksugar, personal # 2022 linuxea.com # Author: mark <usertzc#163.com> USER=admin PASS="password" REPO=docker-host HOST="http://127.0.0.1:38081" CLEAN_DISK_NAME=/data/ touchnet(){ local recode=`curl -o /dev/null -s --connect-timeout 3 $1 -w %{http_code}` if [ "$recode" == "200" ]; then return 1 fi } Create_CRE(){ # protect file since it contains secrets touch ~/.credentials && chmod 600 ~/.credentials # update file using environment variables cat << _EOF > ~/.credentials # Nexus Credentials nexus_host = "${HOST}" nexus_username = "${USER}" nexus_password = "${PASS}" nexus_repository = "${REPO}" _EOF } touchnet ${HOST} if [ `echo $?` == "1" ]; then [ -f ~/.credentials ] || Create_CRE ; else echo "Cannot communicate with the ${HOST}";exit -1; fi PATHS=yxt-vehicle PATH_NAME="dnotask1 outage21speed mongo2 mongo1" TAKE_NUM=10 type nexus-cli > /dev/null 2>&1 && echo " nexus-cli is ok" || { echo "error nexus-cli is not install";exit -1 ;} if [ `df -hT ${CLEAN_DISK_NAME} | tail -1| awk '{print $6}'| awk -F% '{print $1}'` -gt 80 ];then for i in `echo ${PATH_NAME}`;do echo -e "\033[34m $i Start cleaning, keep the last 10 \033[0m" && nexus-cli image delete -name ${PATHS}/${i} -keep ${TAKE_NUM} ;done fi清理完成后进行删除Tasks --> create task --> delete unused manifests and images Task执行完就消失了Tasks --> create task ---> compact blob store Task而后指定store清理Compact blob store。

linuxea:jenkins清理workspace目录插件 清理workspace插件安装workspace cleanupmanage jenkins -> manage plugins -> 在可选插件框内输入workspace cleanup，并选中 --> install without restart而后在流水线语法里面，选择cleanws--> 高级，选择所有，而后生成流水线脚本生成cleanWs()而后将此语句放在post中post { always{ script { ..... cleanWs() } } failure{ script{ ..... cleanWs() } } }而后在java-maven-20211103_cd项目中运行结果中显示[Pipeline] cleanWs [WS-CLEANUP] Deleting project workspace... [WS-CLEANUP] Deferred wipeout is used... [WS-CLEANUP] done [Pipeline] }对应的目录也会清空[root@linuxea-172_16_100_48 ~]# ls /data/jenkins-latest/jenkins_home/workspace/11月/java-maven-20211103-cd [root@linuxea-172_16_100_48 ~]#

linuxea: 有趣的devops 并不是每个公司都适合devops，但这并不能说devops不好，其中对人员的要求和新技术的引入而引起的问题远比现实复杂。devops在当下不是一个难以实现的问题，但在很多时候它出现引起了很多误解。？？9012年后，许多公司对devops热衷，寻求不断被放大。我不断的在听到大家谈论devops，但似乎与原本的初衷并不一致。devops定义是改善开发到生产周期，缩短开发周期，通过devops更快的部署 ，通常而言，如下代码所示：1/6 sonarqube: stage: code-check script: - sonarqube - date 2/6 code_quality: <<: *job_docker_group script: - code_quality - date 2/6 code_quality_Increment: <<: *job_docker_group script: - code_quality_Increment - date # Static Application Security Testing 3/6 SAST: <<: *job_docker_group script: - SAST - date 4/6 dependency-scanning: <<: *job_docker_group script: - dependency_scanning - date 5/6 dependency-check: stage: code-check script: - dependency_check - date 6/6 license_management: <<: *job_docker_group script: - license_management - date # Dynamic Application Security Testing 1/2 DAST_ZAP_JSON: <<: *zap_docker_group script: - DAST_ZAP_JSON - date 2/2 DAST_ZAP_HTML: <<: *zap_docker_group script: - DAST_ZAP_HTML - date deploy: stage: deploy-test environment: name: staging url: https://www.linuxea.com only: - master script:当然，这只是部分信息。除了开发过程外i，能够自动处理的可控范围内的问题，不会影响到用户，并且能够进行有效且高质量的监控。。现实情况：手动测试或者不测试，亦或者单独的伪自动化测试监控没有导向的事情不改善工作流程继续在迭代中执行上述操作等并尝试在出现火灾的时候进行救火devops均在解决这些等问题，从而来完成更高质量的的产品。最终的目的是提供生产力。在此基础上，仍然需要与各部门良好的协作和沟通，以及对系统和产品的熟悉，缩短开发周期和质量测试。这些都包含在自动化中。devops职位的分析在招聘网站的devops这些招聘信息与devops有很直接的关系吗？后端架构设计和研发平台构建devops需要建设CMDB,发布，部署，监控，日志系统，并且需要服务优化，缓存，存储集群设计和落地？CMDB建设，包含部署设计，监控，优化等，在我理解中，有运维开发和资深运维来做。这不是自动化运维的职责内容吗？其中甚至没有提到持续集成和持续交付。看到这里，你大致可以明白，devops信息中实际需要运维开发，或者资深运维工程师，或者云运维工程师，在或者自动化运维工程师，甚至没有考虑到需要持续集成和持续交付。很明显，他们理解错了。如果认为devops就是开发和运维，那是错误的，devops在开发运维之上。当谈论到devops时候，往往意味着：开发和运营的密切关系至少应该是熟悉彼此，这样开发知道他们正在编写的系统，并和运维部署的代码。了解这些才能够在不影响系统的情况下进行调整出更好的方式。在短时间内开发，并且快速部署，在出错后尽快修复这其中就包含了自动化，自动化包含测试和运维，并且最终放在管道中运行。但是这些取决于基础架构是否完善。从哪里开始偏离了？devops方法是抽象和复杂的概念，它不是一个工具那么简单。采用什么工具和技能，并将其命名为devops。这些工具使用和所需的技能附加到职位描述。现在devops一词开始描述知道如何进行开发和自动化的人。要知道devops不是一件事情，dev 同 ops，而不是dev和ops。在更多时候devops是一个团队在做的事情，并不是某一个人做的。不要采用流行的一个单词，而是背后的流程与方法的实际理念。不管如何，我们是将产品最终交付到生产。另外，不要认为使用了cmdb,使用了容器技术，使用了kubernetes,ansible，就认为在做devops。延伸阅读Devops

linuxea: 连续测试的5个要素 我们在做持续集成的时候，或者说是在做连续测试的时候，目的是为了让代码健康，健壮有效。其中，持续交付CD和持续部署能够让运维人员快速的随时随地的将代码推送到线上。而随着devops推进中，生产环境中开发人员需要自己解决代码bug问题，开发人员需要立即知道他们正在进行修改的代码会有那些问题。连续测试唯一保证代码良好的方式就是测试他们，这也是我们进行持续测试原因。在进行这种转变或者参与的团队中，性能测试和自动化测试从早先的测试工作转变为促进测试到开发人员个人测试，维持提供支持和协作。每个人都构建他们的代码，每个人也进行不断的测试自己的代码。但持续测试成为新的常态中。测试将变得更加灵活，测试人员或者开发人员配置了功能测试和测试工具，并且能够对任何新的修改或者更新进行单元测试。并且随测试到预生产环节，在到生产环节，甚至到上线后的监控等。团体只需要最短的时间来怎么代码的可用性并且可以接收新流量。连续测试的过程中会出现很多未曾出现的问题，必然是充满挑战。我们必须确保如下几点：尽早的定义好测试我们需要有明确的需求来定制测试，并且使用行为驱动开发BDD,验收测试驱动开发ATDD和使用工具基于模型的测试，以便于清晰的记录和传达所有需求。为了避免浪费不必要的时间和延误。至少需要明确需求后定义测试用例和测试脚本，以便于在生产的每个阶段都能够进行连续测试代码。优化测试流程和测试覆盖率仅测试需要测试的内容，删除不必要的重复项，对时间较久的测试环节采用旁路测试，在不影响管道运行的情况下精简。测试最大的覆盖范围就需要可视化的模型。早期和后期测试在开发周期早期准备，开发人员/测试人员准备好测试工具和用例或者脚本，包括但不局限自动化测试，功能测试，性能测试，监控，安全测试等。必须满足易于开发，方便使用和采用。生产环境中仍然需要后期跟踪，包括代码检测，持续监控，用户监控，蓝绿发布等。环境一致性提供虚拟化测试环境的能力对于实现持续测试至关重要。通过一些列工具ci/cd，在被需要提供的情况下，提供完整的测试环境。这些环境中应该包括按需测试的数据，以确保团队可以使用与生产环境中类似的参加执行全面测试。这些环境的构建是暂时性的。在使用完成后就会被释放。获取真实的测试数据如果不能够获取真是的测试数据可能会导致应用程序发布更新出现延迟。新的更新大多建立在旧的代码智商，要尽可能的接近应用程序在生产中遇到的内容。如果缺乏某些特征，则测试不太可能主动发现需要潜在问题和bug。如何提取这些数据，也是一个值得讨论的话题。对于这些生产中的真实数据，通常来说都需要限制。在被采用的时候屏蔽一些敏感信息，同时还要保持生产数据测试所需的特性。最后持续交付和持续测试需要时间才能成功实施。在团队中，基于数据的持续反馈和正确的工具集可以较少不必要的麻烦。其他阅读Devopsdocker

linuxea: 自动化测试和连续测试有何差异？ 测试团队一直在自动化测试上面花费的大量的时间和尽力。这样的开销似乎并不符合预期。另外，应用程序的架构，开发的使用方式也在不断的发生变化，这样一来也增加了测试的复杂性和软件故障。鉴于当下应用程序交付的复杂性和交付速度的增加，软件测试人员如何辅助控制业务风险？--进入连续测试。连续测试？？持续测试是将自动化测试作为软件交付管道的一部分的执行过程。便于尽快获得与软件发布相关业务风险的反馈。自动化测试皆在生成一个应用程序定义好或相关的"通过"/"失败"的数据点。另外，持续测试侧重于业务风险，并提供有关软件是否可以继续发布的“见解”。要实现上述，我们必须从“我们是否进行测试某个功能？”我们是否进行了测试？“转到”即将发布的应用程序的风险是否在可接受的范围内。“为什么需要持续测试？？当下的测试内容更多，使用传统工具和方法作用于自动化测试上实现更困难。1, 应用程序体现结构分散和复杂，包括云，API，微服务等，并且这些在业务中通常都是不同的协议和技术组合。2，对于Devops中的持续交付中，更多的应用程序从每周发布一两次，到每天发布无数次。因此，用于测试设计，维护和执行时间也会大大缩小。3，软件程序故障也就是业务故障，如果影响到用户体验，即使看起来微不足道的小故障也会产生不可预计的后果。因此，与应用相关的风险仍然是非技术性业务支撑团队需要关注的点。自动化测试与连续测试不同？连续测试与自动化测试最大的区别可分为：风险，广度，时间风险在当下企业中，应用程序涉及到的业务范畴非常广，例如：一个购物商城不单单只有我们看到的货架种类，推荐消费等，还有积分处理，账单处理，物流信息等。向用户提供越多的功能同时也意味着的潜在故障点的数量，种类和复杂性。如果测试用例中没有考虑到业务风险，那么测试结果将无法评估风险中所需的洞察力。如果测试皆在提供产品是否实现需求的低层次信息，而不是评估发布的版本是否存在高风险。如果没有，那么你的测试与业务风险不一致。在进行低粒度测试的同时仍然需要更多的措施来评估或者阻止高风险的发生。广度即使一些微不足道的故障，也会带来不必要的麻烦。特别是在用户体验差强人意的时候，亦或者某些部分出现问题的时候。单单从单元测试和UI测试通过并不是说这些修改会影响到用户整体体验。为了更好的保护用户的最终体验，需要足够广泛的测试来检测应用程序更改没有在无意中影响到用户所依赖的功能。时间当下，软件迭代的速度也成为了许多团队的竞争优势，很多都在转向敏捷和devops以加速其交付流程。当自动化测试出现，测试根据瀑布式开发过程构建和更新。这种条件下，在测试没有完成之前，当下进度将会暂停。这并不敏捷。测试必然需要和开发并行开始，否则，产品不太可能在极短的时间内完成迭代，并进行测试宣告完成。如果已经开始devops并且正在执行持续交付，则可能每个小时或更频繁的发布应用软件。这种情况下，每个阶段的过程反馈不能只是快速，几乎是瞬间完成的。如果质量不是应用程序首要考虑因素(例如：生产中发生缺陷影响较小)，则在每个版本运行一些单元测试和冒烟测试就足够了。但是，如果企业希望最大限度的降低故障，则需要一些方法来实现必要的风险覆盖水平并快速测试。对于测试，有几个重要的影响：测试必须成为开发过程的一部分，而不是在开发完成时处理”尿不湿“的任务几乎在使用相关功能后，测试必须准备好并运行团队必须有办法确定在交付管道中的不同阶段进行正确有效的测试，如：烟雾测试，集成后的API和消息层测试，系统级别的端对端测试等等。每组测试必须足够快的执行，以避免软件交付的某个阶段产生瓶颈需要一种稳定的测试环境方法来避免频繁更改造成的大量报警自动化测试不等于连续测试自动化测试不等于连续测试，连续测试大于自动化测试。即使是使用传统测试自动化早已成熟的团结，当采用交付方法时候，也会出现很多问题，比如：无法足够快或足够频繁的创建和执行测试持续应用程序更改会导致大量的错误报告，这些大多可能都是误报，需要看似永无止境的测试维护量无法即时了解发布版本是否存在风险太大而无法通过交付管道最后，我想说没有任何工具或者技术可以立即做好连续测试，与敏捷和Devops一样，连续测试需要在整个人员，流程，技术方面进行变革。然而，当目前技术不能够完成任务，尝试做一些人员和流程的变化。这仍然可能会导致失败。其他阅读Devopsdocker