artifactory

1. 背景 在 3 年前，西门子公司内部存在不同的工具来存放他们的制品 : 有的团队放在 TFS 上托管制品，但是从理论上来说， TFS 并不适合用来托管制品。 有的团队将他们的制品托管在他们的 Clear Case 中。 还有的团队创建了不同的共享文件夹，并将他们的制品存放在里面。 这样的现状带来很多问题，例如： 所有的工具都需要满足一些重要的公司要求，例如如何 保证制品的安全？ 如何将制品分享给其他项目团队？ 如何满足所有的合规性要求？ 如何降低管理成本？ 如何为开发者们提高系统的性能和可用性？ 综上所述，对于西门子公司而言，创建一个统一的中央仓库来管理制品是很有必要的。 2. 解决方案 西门子使用 JFrog Artifactory 作为单一可信源，存储西门子全球所有的制品，支持 6000 研发， 250 个项目团队， 43 个 Artifactory 节点。 当你有了好的工具，在大公司里提供制品库服务的时候，还需要其他的服务能力，包括高可用性，和 CI/CD 集成，培训，自助式服务的体验。 西门子 IT 部门花了在这方面做了很多工作，对于开发者， IT 团队提供了: 0 宕机的单一可信源制品库 自动巡检 Artifactory 首页的可用性 自动上传测试制品保证制品库的可用性，如果 3 次测验均失败，在证明 Artifactory 服务处于不健康状态。 运行模拟的制品上线

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 如今，企业面临着比竞争对手更快、更高质量地交付软件的巨大压力。只有当企业频繁发布软件更新时，其良好的特性以及对客户的影响才能增加。因此，很多企业正在采用DevOps和持续集成/持续交付方法，以提高其规划、构建、测试和发布应用程序和特性的能力，从而以高质量和规模快速推向市场。调研机构IDC公司预计，到2022年，全球DevOps软件市场规模将从2017年的39亿美元增至80亿美元。 如今，围绕持续集成、持续部署、持续交付的讨论比以往任何时候都多，但实际上，持续集成/持续交付的实际使用似乎更少。这可能是因为DevOps缺乏所需的技能集，或者企业仍然在实践传统的软件开发方法。由于缺少持续集成/持续交付和DevOps自动化实践，企业无法了解需要花费多少费用。 对于许多企业而言，DevOps是他们必须尝试的事情，因为他们的竞争对手正在这样做或者这是一种趋势。如果不了解DevOps原理和基本知识，那么这将是一个令人绝望的尝试。 在大多数情况下，客户必须将一套不同的工具组合在一起才能交付软件，这将会造成混乱。另一方面，很难选择正确的工具并了解什么是最佳实践。这就是人们开始看到DevOps公司具有提供统一工具集趋势的原因，以使客户可以立即使用完整的解决方案

引言 自从2018年从Cloud Native Computing Foundation（CNCF）出现以来，您可能已经在使用K8操作系统，随着容器云技术的发展以及落地，提高了企业运维的效率和质量，并且降低了企业运营成本，但同时带来的问题是运维的复杂度和难度，举个例子 🌰 ：由于容器的生命周期短，随时可能飘移到其他物理资源上运行，因此日志的采集和运行的监控很难像传统方式登录到服务器上查看，而运营团队需要了解有价值的数据来进行问题定位以及运营数据分析。 为了更广泛地提供这种可观察性，我们需要提供满足云原生环境下的监控能力。 JFrog 通过使用Elasticsearch和Kibana套件，以及Prometheus 和Grafana套件来监控Artifactory 制品库以及Xray 漏洞扫描工具的运行情况，下面我们一起了解JFrog 如何在云原生环境进行应用运维。 日志分析 Easticsearch是一个分布式且可扩展的搜索引擎，可用于搜索全文，结构化文本和分析。它通常用于搜索大量数据以及搜索不同类型的文档。 Kibana是Elasticsearch最常用的可视化和仪表板。Kibana使您能够通过构建可视化和仪表板的Web UI探索Elasticsearch日志数据。 下面我们将向您展示如何利用同类最佳的开源日志分析技术：Elastic

最近几年好像大家都开始对微服务着迷，与此同时单体架构也在慢慢淡出人们的视线。 当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸大了，实际情况并不总是如此。不过，对于微服务来说，人们似乎已经达成共识，认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说，微服务扩展了工程师们几十年来采用的相同原则。 一旦你开始使用微服务架构，也许你需要本文中提到的5个规则，帮助你成功运行它们。 微服务的另一面 关注点分离(SoC)是一项设计原则，规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。 微服务采用了这个概念，并将其颠覆。它们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。 挑战1：似乎很难监控整体 虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会： 使用不同的技术和/或语言。

报名链接： https://amazonaws-china.com/cn/about-aws/events/0628-eks-container/?trkCampaign=0628-eks-container&trk=Jfrog 来源： oschina 链接： https://my.oschina.net/u/4409432/blog/4320822

Enterprise Holdings. 的IT团队超过2000人，在2018年的演讲中介绍了Enterprise Holdings的DevOps是如何转型的。我们通过打造一个不只包涵了pipeline的CI/CD平台，将其称之为SDLC。在最开始的200+个应用中，我们挑选出5个来作为试点。当时的情况证明这次DevOps转型计划是成功的，我们的团队有4+位工程师和两位架构师，从2年半前就开始了整个平台的开发工作，根据业务需求确保平台可以适配各种云服务、也要适配已有的中间件，我们也在不断对CI/CD平台进行改进，以适应所有业务场景。其的目标是让开发人员更专注于具体的项目开发，让工具去解决一些通用性的问题。为了达到目前的效果，我们做了很多关于平台的需求收集及问题反馈相关的运营工作，所以在过去的一年里，我们已经将此套平台服务于70%的应用中，并且这个数字还在持续的增加。 在DevOps转型过程中，我们的角色并不是软件的开发者，但我们支撑了应用开发团队和他们所开发的应用，我们的服务工作介于应用程序与基础设施之间。在我们的角度来看，应用程序的开发应该是这样的： ·开发人员在本地开发 ·在仓库中检查源码 ·在构建服务器上构建应用 ·运行安全扫描 ·打包发布到JFrog的Artifactory ·发布应用到不同的环境测试 ·所有测试结束后，发布到生产环境 这个模式很简单，但是也很高效