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: 有趣的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

linuxea: 持续集成的7个要素 大多数公司认为他们已经在使用持续集成(CI)，但当谈到是否遵循CI的关键实践时，如：运行测试来验证每个构件，其中许多并没有。今天我们来讨论如下几点：1，我们是否每天更改或至少每天多次构建我们的应用程序代码？2，我们是否有意识到避免长时间在分支开发代码功能？3，我们是否优先考虑修改构件中出现的已知故障而并非进行新的迭代？如果上述三个问题的答案是否定的，那么你做的并不是真正意义上CI。持续交付(CD)是Devops的基础，他建立在持续集成基础之上，因此，在使用CD和Devops真正取得有效进展之前，必须正确实施CI。换句话说，我们必须解决这些问题才能在后面进行飞跃的提升。掌握持续集成的步骤为了实现业务目的，以下是必须采用的七种实践来掌握CI1.自动化构建在实施持续集成之前，开发人员在桌面进行本地构建，或者让构建人员手动集成代码。再者通过手动撸一个烦躁的步骤。但是让人疑惑的是，这种“CI”形式的确存在。简单来讲，持续集成的构建应该运行一个集中管理的控制器单元上，能够完全无人值守的运行并自动化，以便于相同的每次输入都会产生相同的输出结果。2.尽可能频繁的进行构建在测试环境中每天都会进行大量的构建工作，理想情况下除拉取外，合并，提交时候都会触发每次更改的构建，每次提交构建可以在引入错误后立即找出错误，在这样的情况下有利于修复bug持续集成(整合)中，“持续”尽可能的采用字面意思。通常，在一个公司中，当讨论到构建频率时，答案如下：1，通过某些按钮触发构建，每周X次2，每天晚上都进行构建，每周一次3，每天在某个时间段进行构建一次这些并不是真正的持续构建，他们可能是集中管理一台管理服务器，自动构建或者预订构建。但这些不提供持续集成的好处。倘若现在由于某些原因，10个开发人员在两天内进行了多达30多次代码提交，对于出现的BUG则可能需要对这些工作排序并且找出更正的原因。这样情况下生产力将会下降。3.经常提交或合并到主线在已有CI的团队中可能在每次更改时或每天至少一次对主线或者主要部分代码进行合并。例如：长时间维护一个功能分支，则无法频繁的确验证集成更改。如果分支很长一段时间没有进行合并验证，当合并时大概率会出现冲突或者错误需要解决，这延迟了项目进度。4.快速构建假如你的测试环境中的CI，每次构建在5-10分钟完成是正常的。如果构建需要更长的时间（有的构建长达三四个小时），不仅会延迟进度，也无法得到有价值的反馈。花时间优化构建。这过程中可能需要分解CI构建过程，或者组件，这些与团队密切相关，而后将整个集成应用程序的验证作为整个开发过程中的单独步骤来做。5.验证构建CI中包括验证更改和生成的报告。这种测试应该是整个构建过程的一部分，如果你是唯一验证仅基于确认软件编译结果，那这并不是真正的实践CI。大多数实践CI团队都包括CI构建中的代码扫描和单元测试，以及后续的黑白盒等。6.在类似生产环境中验证成熟的CI可确保开发，测试和预生成环境之间的一致性。最成熟的方案莫过于虚拟机和容器技术，服务器虚拟化和其他技术来确保在类似的生产环境进行验证，并且当在集成这些更改之后，就可以降低在预生产和生产中出现错误的风险。7.立即修复崩溃的构建如上所述，团队发现并快速解决问题以便他们不会向下推进也至关重要。使用CI，可以建立流程，在这些流程中，构建可以持续验证和提交，如果出现问题，则更容易修复。如果忽略了错误的构建，则问题在此后更难以找到并修复，但更糟的是这背后的文化。CI是基于质量优先的方法，如果构建中断，停止并修复。从长远来看，得益于每个参与的人。最后的文化问题这些看起来似乎很简单，但是当结合起来后，结果必然是显著的。不能说不遵循这几条的团队可能会在定期提供构建功能就会出现问题。但是如果 持续集成推进失败，团队成员将会恢复此前的方式。不仅存在流程问题，也存在文化问题，这也是多数团队陷入困境的原因之一。团队必须改变工作的方式并且确保他们的思维方式一致。CI对团队有很多好处，但不要忘记CI本身是为了正面发现问题，解决问题并不是通过CI来避免和消除问题。持续集成构建一个系统，开发人员可以快速发现BUG，有利于及早，快速的找到问题并修复。持续集成是真正的Devops转型的基本要素之一，众所周知，这是许多当前 团队的首要任务，真正使用它是为了跟上现代商业需求至关重要的一小节。